Parametrik modelleme

  • Konuyu başlatan Konuyu başlatan Er Presidente
  • Başlangıç tarihi Başlangıç tarihi

Er Presidente

Guest
"parastrubbolite" hakkındaki ebedi tartışmaya atıfta bulunan fb hakkında bazı görüşleri değiştirmenin zevkine sahiptim.
Kaybedecek biraz zamanım var, elimi eski bir projeye bir "breed" olarak koydum ve kendimi "parametreize etmeye" koydum.
Benim için yeni bir deneyim, her zaman parametrik modül ile çalışmış olsam bile ve (bir dizi bağırsak rahatsızlıktan bir parça, yan etkisi ortadan kalkamaz:) Yaklaşım ve çalışma felsefesine odaklanma fırsatım vardı.

Umarım ozzy katılmak istiyor ve kısa ve tutarlı olmaya çalışacağım (her zamanki gibi!).

Merhaba.
 
Nasıl? Parastrubboli'ye mi dönüyorsunuz??

Sonra, bundan sonra, her şey mümkün olur! Ayrıca uzaylılar yeryüzünde aşağı iniyor !!!





Gerçeğin. .
Güzel parastruder, o?”
 
Nasıl? Parastrubboli'ye mi dönüyorsunuz??

Sonra, bundan sonra, her şey mümkün olur! Ayrıca uzaylılar yeryüzünde aşağı iniyor !!!





Gerçeğin. .
Güzel parastruder, o?”
Annem!
Bir yandan, bir model yapmak (özellikle ithal edilen bir adım) ödüllendirilir, ancak diğer bir kabusda!
İlk hipotezimi doğrulayan kendi kesin fikrimi yaptım, parametreyi daha “bilinçli” ve daha az “alienant” yapan yeni bir şeye ihtiyacım var.

Sadece konuyu tanıtmak için kafada bir fikrim var, parametrik iki "areas", "vincolation" ve bunun yerine "parametrization" olarak bölünmüş olmalıdır.
Uygulamanın boyutsal kontrolü olmalıdır, parametreizasyon modelinin "yaşam" olması gerekir.

Onları ayrı düşünüyorum çünkü düşündüğüm şey için, ilk aşama (win) zaten tasarımcılar olarak bildiğimiz araçlarla yapılmalıdır, q&t (bölümler ve toleranslar).
Bir tasarımcı olarak, bir parçayı nasıl bağlayacağını düşünmem zor olmazdı ve onu sadece domuzları memnun etmek için farklı bir şekilde bağlamayı öğrenmeliyim, q&t temelinde kurallar evrensel olarak geçerli ve bilinmektedir.

Parametreizasyonunu farklı kılan şey, hangi kotaların (wins) değişebilir (ve hangi sınırlarla) "agresif" modeller veya modeller aileleri üretmek için değişebilir.
 
Bir tasarımcı olarak, bir parçayı nasıl bağlayacağını düşünmem zor olmazdı ve onu sadece domuzları memnun etmek için farklı bir şekilde bağlamayı öğrenmeliyim, q&t temelinde kurallar evrensel olarak geçerli ve bilinmektedir.
Çizimler ve işleme alıntılanmalıdır (ve bu olasılığı olan kadrolar için tolere edilmelidir) aynı şekilde parça m.u. Konuştuğunuz fark olmazdı.
Bunu elde etmek için, yarı finanse edilen ham'den daha iyi bir parça modelseniz ve kazı kuvvetine devam edin ve hiçbir zaman malzeme eklemeyin.

Daha sonra, bu şartlarda nedenle uğraşmak imkansız olan parçalar arasındaki bağlantılarla ilgili modelleme teknikleri var, ancak bazı durumlarda büyük rahatlıklar vardır.
 
"parastrubbolite" hakkındaki ebedi tartışmaya atıfta bulunan fb hakkında bazı görüşleri değiştirmenin zevkine sahiptim.
Kaybedecek biraz zamanım var, elimi eski bir projeye bir "breed" olarak koydum ve kendimi "parametreize etmeye" koydum.
Benim için yeni bir deneyim, her zaman parametrik modül ile çalışmış olsam bile ve (bir dizi bağırsak rahatsızlıktan bir parça, yan etkisi ortadan kalkamaz:) Yaklaşım ve çalışma felsefesine odaklanma fırsatım vardı.

Umarım ozzy katılmak istiyor ve kısa ve tutarlı olmaya çalışacağım (her zamanki gibi!).

Merhaba.
Size zaten her şeyi söyledim...:-)
 
m m m m

Sadece konuyu tanıtmak için kafada bir fikrim var, parametrik iki "areas", "vincolation" ve bunun yerine "parametrization" olarak bölünmüş olmalıdır.
Uygulamanın boyutsal kontrolü olmalıdır, parametreizasyon modelinin "yaşam" olması gerekir.

Onları ayrı düşünüyorum çünkü düşündüğüm şey için, ilk aşama (win) zaten tasarımcılar olarak bildiğimiz araçlarla yapılmalıdır, q&t (bölümler ve toleranslar).
.
Bahsettiği diğer önemli yönü: özellikler hikayesi. Bu kısmen alıntı ve parametrelemeden kopmuş bir gerçek, ancak her zaman m.u'da işleme benzer bir modelleme akışına sahip olmak çok önemlidir.
Ayrıca işlem döngüsünü genişletmek için de kullanabilirsiniz, çeşitli modelleme adımlarının adımlarını yeniden yöneterek.
Bunlar artık geleneksel parametrik kadroları kullananlar için "assimilate" kavramlardır, ancak belki de bağlamsallara alışkın olanlar için yenilerdir.
 
I'm intruding and quoting avcı. "parametrik" yazılım (daha önce modelleme/tasarım sırasında üretimlerini optimize etmek yerine), bir nesneyi temsil etmek için bir yol bulmaya hizmet etmiyor. Bu ilke, genellikle oldukça sezgisel nesneler elde etmek için beyin operasyonlarına yol açar, ancak ne yazık ki bu nesneler temel özellikler prensibi ile iyi evlenmez.

Buna ek olarak, parametreleme (aslında özel değil, bazı parametrik besleyici örnekleri vardır... Gerçekler, nesneleri hızlı bir şekilde değiştirmek ve cascade'ye değişiklikler oluşturmak için faydalıdır, ancak bu yukarıda ortaya çıkan temel konseptin bir tarafıdır.
 
Son düzenleme:
İlk hipotezimi doğrulayan kendi kesin fikrimi yaptım, parametreyi daha “bilinçli” ve daha az “alienant” yapan yeni bir şeye ihtiyacım var.

Sadece konuyu tanıtmak için kafada bir fikrim var, parametrik iki "areas", "vincolation" ve bunun yerine "parametrization" olarak bölünmüş olmalıdır.
Uygulamanın boyutsal kontrolü olmalıdır, parametreizasyon modelinin "yaşam" olması gerekir.

Onları ayrı düşünüyorum çünkü düşündüğüm şey için, ilk aşama (win) zaten tasarımcılar olarak bildiğimiz araçlarla yapılmalıdır, q&t (bölümler ve toleranslar).
Bir tasarımcı olarak, bir parçayı nasıl bağlayacağını düşünmem zor olmazdı ve onu sadece domuzları memnun etmek için farklı bir şekilde bağlamayı öğrenmeliyim, q&t temelinde kurallar evrensel olarak geçerli ve bilinmektedir.

Parametreizasyonunu farklı kılan şey, hangi kotaların (wins) değişebilir (ve hangi sınırlarla) "agresif" modeller veya modeller aileleri üretmek için değişebilir.
Bağlanma ve parametreleme benim görüşümde çok zor. İki şey genellikle ve kısıtlamaları koyduğunuzda genellikle “önemli” olası veya olası değişiklikler ve gelecekte "parametreize" ne denemeye çalışırsınız. Örneğin, değişken oluşturmak için giderseniz ve bu zaten bir sorun olan bir bağla dolaşmaya başlar.
Ayrıca konuşma karmaşık hale gelir ve en üst ve iskeletler arasında koyduğunuzda biraz değil. Bu (benim görüşüm) parametrikin gerçek gücüdür, ancak sık sık baş ağrısı nedenidir.
Çizimler ve işleme alıntılanmalıdır (ve bu olasılığı olan kadrolar için tolere edilmelidir) aynı şekilde parça m.u. Konuştuğunuz fark olmazdı.
Bunu elde etmek için, yarı finanse edilen ham'den daha iyi bir parça modelseniz ve kazı kuvvetine devam edin ve hiçbir zaman malzeme eklemeyin.

Daha sonra, bu şartlarda nedenle uğraşmak imkansız olan parçalar arasındaki bağlantılarla ilgili modelleme teknikleri var, ancak bazı durumlarda büyük rahatlıklar vardır.
Sadece parçalar arasındaki bağlantılar bu tür bir uygulama imkansız hale getirmez, ancak büyük meclislerin yönetimi için mümkün olan ikinci bir aracın her binincisini spekülasyon yapmak için kullandım. Bu şekilde, her zaman özelliklerini kullanırım + çalışma döngüsüne eşit bir model ağacının olması için yeniden inşa edilmem.
 
Bana göre "parametrik" ve "yönetmen" (veya "başlangıç temelli" ve "explicit" istediğiniz iki set kısmen örtüşür. Birçok şey her iki sistemle (ve bazı verimlilikle) uygulanabilir, bazıları özellikle bir veya diğer enstrüman gerektirir.
 
Bana göre "parametrik" ve "yönetmen" (veya "başlangıç temelli" ve "explicit" istediğiniz iki set kısmen örtüşür. Birçok şey her iki sistemle (ve bazı verimlilikle) uygulanabilir, bazıları özellikle bir veya diğer enstrüman gerektirir.
İdeal, parametreli olarak sadece bazı özellikleri yönetme olasılığını içeren açık bir yazılım olacaktır. Örneğin: böyle bir şişe için bir tasarım nesnesini hayal ediyoruz: http://www.piliscomp.com/~motorola/.../product/34fe074c6b7bfda4a2a0a48f9815f584.jpg (Proe wf2'nin gelişmiş yüzeylerini kullanarak her şeyi modelledim, ancak model, resmi olarak hala parametrik, parametreli olarak değiştirmek neredeyse imkansızdı).

"style" kısmı uygun, "explicit" (rhino? Cocreate? Uzaylılık 2009sp2?) Gaz veya fiş bağlantı için yer alırken, parametrik (kıtılmış çapı, adım vb.) uygun olacaktır.

Çeşitli hilelerle (örneğin, proe type parametric) bir proe tipinde "design" geometrisini ithal etmek, ancak açık ve parametrik arasındaki iletişim hala oldukça zordur (aynı zamanda iki farklı modelleme ortamı da içerir).
 
"style" kısmı uygun, "explicit" (rhino? Cocreate? Uzaylılık 2009sp2?) Gaz veya fiş bağlantı için yer alırken, parametrik (kıtılmış çapı, adım vb.) uygun olacaktır.

Çeşitli hilelerle (örneğin, proe type parametric) bir proe tipinde "design" geometrisini ithal etmek, ancak açık ve parametrik arasındaki iletişim hala oldukça zordur (aynı zamanda iki farklı modelleme ortamı da içerir).
Benzer bir yaklaşım onu takip eder. Yazılım benzersizdir, ancak gerçekte mekanikler için modüller ve yüzeyler için aslında iki farklı şey vardır, ayrı olarak satın alırlar ve kendilerini eklentiler olarak yüklerler. Yine de uygun olan şey, iki paket "kommutlama", görsel değişiklikler sadece mevcut özelliklerin setini değiştirirken, tüm arayüzün geri kalanı değişmeden kalır.
 
Benzer bir yaklaşım onu takip eder. Yazılım benzersizdir, ancak gerçekte mekanikler için modüller ve yüzeyler için aslında iki farklı şey vardır, ayrı olarak satın alırlar ve kendilerini eklentiler olarak yüklerler. Yine de uygun olan şey, iki paket "kommutlama", görsel değişiklikler sadece mevcut özelliklerin setini değiştirirken, tüm arayüzün geri kalanı değişmeden kalır.
Proe tarzı yüzeyler de çok büyük çalışır. Bununla birlikte, izlenimim şu ki, bunlar bir parametrik bağlamda "parametre" elementleridir (proe kullananlar için: "external copy geometrisi nasıl bağımlı değildir".

stefano’nun dediği gibi (eğer kötü anlamasaydım) tam tersi yapmak ilginç olurdu: "bölgeler" parametrik oluşturmak için gerekli referansları belirtmek için sadece gerekli olduğunda (teknik zorluk burada olduğunu düşünüyorum).
 
Proe tarzı yüzeyler de çok büyük çalışır. Bununla birlikte, izlenimim şu ki, bunlar bir parametrik bağlamda "parametre" elementleridir (proe kullananlar için: "external copy geometrisi nasıl bağımlı değildir".

stefano’nun dediği gibi (eğer kötü anlamasaydım) tam tersi yapmak ilginç olurdu: "bölgeler" parametrik oluşturmak için gerekli referansları belirtmek için sadece gerekli olduğunda (teknik zorluk burada olduğunu düşünüyorum).
Bu kadar futuristik değil. Katı kenarı çok iyi bir profil veya alt-wine özelliği bırakabilirim, bir sorun yok ve bunu yapmak için adım ve yenidenportaj yapmak zorunda değilim.
Problemler, modelin olası bir yenilenmesinde ortaya çıkabilir, ancak bir kişinin daha fazla özgürlüğe sahip olmak istemediği şeylerdir.
 
Amacım, evrensel olarak tanınan ve yönetilebilir bir modelin parametrelendirilmesine nasıl sahip olduğunu tartışmaktı, parametrik ve bağlamsal arasındaki sonsuz çatışmada çok fazla değil.

p.s.: Ben denizdeyim, böylece sizi bir internet noktasından okudum, hepinize merhaba
 
Amacım, evrensel olarak tanınan ve yönetilebilir bir modelin parametrelendirilmesine nasıl sahip olduğunu tartışmaktı, parametrik ve bağlamsal arasındaki sonsuz çatışmada çok fazla değil.

p.s.: Ben denizdeyim, böylece sizi bir internet noktasından okudum, hepinize merhaba
Bağımsız bir yazılım parametresi anlamına mı geliyorsunuz? Bu tür bir paraşüt adım mı?
 
Proe tarzı yüzeyler de çok büyük çalışır. Bununla birlikte, izlenimim şu ki, bunlar bir parametrik bağlamda "parametre" elementleridir (proe kullananlar için: "external copy geometrisi nasıl bağımlı değildir".
Bu benim söylediklerim değil. Yüzeylerle modelleme (catea, ama aynı zamanda alias, rhino) parametrelemeyi görmezden gelmek anlamına gelmez. Her yüzeyin kendi tarihi vardır (örneğin alias ile birlikte), ve yüzeyin tüm hikayesini güncellemek mümkündür. Elbette kavramlar işleme özelliklerinden farklıdır, ancak prensip aynı.
Bağımsız bir yazılım parametresi anlamına mı geliyorsunuz? Bu tür bir paraşüt adım mı?
Eğer başkan ne anlama geliyorsa, zaten başka bir yerde konuştuğunu düşünüyorum. Fikir iyi görünüyor, ancak aslında tarafsız formatlarda tarihi kaybetmek, müşterilere veya tedarikçilere sağlanan "gizli" dosyaları tutmak için faydalı olabilir. .certo, herhangi bir "export özelliği" fonksiyonunu kapatabilirsiniz
 
Son düzenleme:
Eğer başkan ne anlama geliyorsa, zaten başka bir yerde konuştuğunu düşünüyorum. Fikir iyi görünüyor, ancak aslında tarafsız formatlarda tarihi kaybetmek, müşterilere veya tedarikçilere sağlanan "gizli" dosyaları tutmak için faydalı olabilir. .certo, herhangi bir "export özelliği" fonksiyonunu kapatabilirsiniz
Buna ek olarak, formatların gerçek bir içilebilirliği, kullanıcılar için çok faydalı olsa da, yazılım evinin ekonomik çıkarlarına son derece zararlı olacaktır, bu yüzden zor bir şekilde uygulanmalıdır (örneğin, odf'a karşı yürütülen savaşın aksine).
Ama stefano’ya, tartışmanın çeşitli geri dönüşlerde dağıldığı ve daha önce söylediği şeylerin tekrarlanmasıyla ilgili daha açık olmasını rica ediyorum.
 
Kişisel düşüncelerimi ifade ediyorum.

3 sw modelleme kullandım, her zaman makinelerin inşaatı için parçalar çizin. Garip stil veya şekiller yok, her zaman mekanik kalıp parçaları, bakıcılar, işlevsellik amaçlı parçalar çalıştı.

3 kullanılmış bir sürü, tüm parametrik, her zaman özelliklere dayanan "küresellik" kavramından nefret ettim.

Benim izlenimim, tüm bu yazılımların mükemmel, olağanüstü, ürünün geliştirilmesi veya iyileştirilmesi durumunda, ancak "beyaz sayfa"dan başlayarak tasarıma geldiğinde ortaya çıkıyor.
Klasik bir örnek yapıyorum. Eğer dişliler inşa edersem, sonsuz vidalar koyalım, parametrikten en yüksek avantajı alıyorum. Bir kez incelenmiş ve ilk azaltıcıyı hazırladık, 32 büyüklüğün, diğer miktarları almak için çok basit olduğunu söylüyoruz, "homothetic" oldukları gibi. İnşaat aynıdır, kotaları değiştirir.

Ama "beyaz sayfa"dan başlamak zorunda olsaydım, bu kapasite benim için işe yaramaz.
Daha sonra nasıl değişeceğini düşünmek zorunda kalmadan çizmek zorundayım.
Bu sayfanın sonsuza kadar metal mi kalacağını düşünmekten endişe edemiyorum ya da yarın kaynaklanmış bir takviye eklemek zorundaysam, aslında yan yanan yanan.
Bir çember ya da bir dikdörtgen çizerek bir ağaç inşa etmeye karar vermek için zaman ve zihinsel kaynakları (daha sınırlı) boşa harcamak zorunda değilim, bir seçeneğin diğerine kıyasla bazı avantajları ve bazı dezavantajları olduğunu bilmek.

Ağaçların cam işlemenin bir yolu olması gerektiğini iddia etmek, aynı zamanda bir aptaldır. Yukarıda bahsettiğim "optimizasyon" vakalarında doğru. Ürünle ilgili her şeyi zaten biliyorum, onu optimize etmek zorundayım ve bu nedenle, kontenjanlar arasındaki ilişkilerin seçiminde zihinsel kaynakları hizmet edebilirim.
Ama bileşeni "invent" yapmak zorundaysam, hangi adımların yapılması gerektiğini düşünerek zaman geçirebilirim. Önemli olan, bileşeninin uygulanabilir olmasıdır ve bana hizmet ettiği gibi fark edilir.
Hatta, o zaman masadaki izlerini izlemek ya da tersi için anlam ifade etmeyecek olan kotaların yapıcı çizilmesi gerekiyor.

Belirli bir özellik düzeni ile bir bileşeni fark ediyorum.
Ardından, tasarımın başlangıcında, bu bileşenin yapımını incelemeye ihtiyacım var, bazı özellikleri büyük ölçüde değiştiriyor ve diğerlerini tutuyorum. Ve bu durumlarda bunu yeniden tanımlamak zorundayım, çeşitli nedenlerle, doğrudan değişime dahil olmasa bile başarısız olur. Ancak, belki de kendi spontan inisiyatiflerinden, değiştirilmiş özelliklerdeki referanslar ve bu nedenle... meclislerdeki başarısızlıkları çözmek için saatler, kısıtlamalar başarısız olduğunda, kısıtlamaların başarısız olması nedeniyle bir ışın veya revize edilmiş bazı özellikleri ortadan kaldırdınız.
 

Forum İstatistikleri

Konular
58,521
Mesajlar
499,056
Kullanıcılar
104,110
Son Üye
ChristianR

Çevrimiçi Üyeler

Şu anda çevrimiçi üye yok.
Geri
Üst