- CADmium, tarayıcıda çalışan açık kaynaklı 3D parametrik CAD olmayı hedefliyordu, ancak şu anda durduruldu ve GitHub deposu arşiv olarak bırakıldı
- Tasarımın merkezinde, mevcut CAD kullanıcılarına tanıdık gelen deneyimi korurken 2D kısıt çözücü, b-rep çekirdeği, geçmiş takibi, 3D arayüz ve dosya formatını yeniden bir araya getirme fikri yer alıyordu
- 2D kısıt çözümü için, devasa bir matrisi tek seferde çözmek yerine yay-kütle-sönümleyici fizik simülasyonu gibi yinelemeli yakınsama yaklaşımı düşünülüyordu
- b-rep çekirdeğinde Rust tabanlı açık kaynak Truck kullanılması planlanıyordu ve WebAssembly ile JavaScript binding'leri sayesinde bunun tarayıcı çalıştırmasına uygun olduğu düşünülüyordu
- Dosya formatı olarak JSON ve JSON Lines tabanlı metin odaklı bir biçim hedefleniyordu; CLI, git-diff, betiklerle düzenleme, iş birliği ve yardımcı araç ekosistemi buna göre düşünülüyordu
Proje durumu ve hedefler
- CADmium, yeni bir açık kaynak CAD programı yapma girişimiydi
- Proje şu anda durdurulmuş durumda ve GitHub deposu arşiv olarak sunuluyor
- Yayınlar artık sürdürülmüyor
- PR kabul edilmiyor
- Discord hâlâ duruyor, ancak aktif değil
- Hedeflenen 3D parametrik CAD bileşenleri 5 parçadan oluşuyordu
- 2D kısıt çözücü
- b-rep çekirdeği
- geçmiş izleyici
- 3D kullanıcı arayüzü
- dosya formatı
2D kısıt çözücü yaklaşımı
- Geleneksel yaklaşım, tüm bilinmeyenleri büyük bir vektörde toplayıp her kısıtı doğrusal denklem olarak ifade ederek dev bir matris denklemi çözmeye dayanır
- Bu yöntem, ters matris alınabilmesi için matrisin kare olması gerektiği kısıtına sahiptir
- Kısıt çok fazlaysa matris uzayarak başarısız olabilir
- Tekrarlayan kısıtlar birbiriyle uyumlu olsa bile aşırı kısıtlama sorunu çıkabilir
- Kısıt çok azsa çözüm bulmak için varsayımlar eklenir, ancak bu da modelleyicinin beklentisinin aksine sketch öğelerinin uzağa fırlamasına yol açabilir
- Bilinmeyen sayısı arttıkça büyük matris denklemleri yavaşlar; bu yüzden tek tek sketch'leri küçük ve basit tutma pratiği oluşmuştur
- CADmium'un alternatifi, 2D kısıt problemini bir fizik simülasyonu gibi ele almaktı
- Her noktanın bir kütlesi ve hızı vardır
- Her kısıt, bağlı noktalara kuvvet uygulayan bir yay gibi davranır
- Hızla orantılı bir sürtünme kuvveti vardır
- Simülasyon küçük zaman adımlarıyla ilerletilerek yakınsama sağlanır
- Tüm problemi tek seferde çözmek yerine, küçük değişiklikler tekrar tekrar uygulanarak yayların potansiyel enerjisi 0'a yaklaştırılır
- Her zaman adımındaki çalışma süresi yay sayısı ve bilinmeyen sayısıyla doğrusal orantılıdır; bu da daha karmaşık sketch'leri ele alma ihtimali sunar
- Simülasyon yaklaşımı paralelleştirmeye uygundur ve compute shader üzerinde çalıştırılma ihtimali de vardır
- Aşırı kısıtlama durumunda sistem kendi içinde tutarlıysa normal şekilde çözülür, tutarsızsa yaylar bir uzlaşma noktası bulur
- Yetersiz kısıtlama durumunda sistem sonsuza savrulmak yerine en yakın geçerli yapılandırmayı bulur
- Bu yaklaşım eşitsizlik kısıtlarını da destekleyebilir
- Uzunluğu 1 cm'den büyük ve 2 cm'den küçük olacak şekilde sınırlamak
- Sketch açısını 10 ile 30 derece arasında sınırlamak
- Kapalı bir çokgenin belirli alanını basınç kuvveti olarak ele almak gibi başka kuvvetlerle de genişletilebilir
- Temel hedef, çoğu CAD kullanıcısına tanıdık gelecek bir deneyimdi; ancak 2D kısıt çözümünde yeni fikirler uygulama alanı olduğu düşünülüyordu
b-rep çekirdeği ve Truck
- Makine CAD'inde kullanıcıların parçaların kenarları ve yüzeyleriyle doğrudan çalışması gerekir
- Parametrik CAD, parçanın sınırını veri yapısıyla doğrudan ifade eden Boundary Representation, yani b-rep yaklaşımını kullanır
- Bir küp, 6 Face içeren bir Solid olarak ifade edilir
- Her Face'in 4 Edge'i vardır
- Her Edge'in 2 Point'i vardır
- Eğrisel yüzeylerde NURBS yüzeyleri yaygın olarak kullanılır; bunlar serbest biçimli şekil kontrolü ve konik kesitlerin hassas ifadesini mümkün kılar
- b-rep, yalnızca şekli temsil etmek açısından bile zordur; boolean operations olan Union, Intersection ve Subtraction'ı uygulamak ise zorluğu ciddi biçimde artırır
- Bu verileri ve boolean işlemlerini yöneten kütüphanelere b-rep çekirdeği denir
- Büyük ticari CAD şirketleri kendi çekirdeklerini onlarca yılda geliştirdi; ticari çekirdekler iyi kabul edilse de pahalı bulunur
- Açık kaynak CAD tarafında OpenCascade, popüler sayılan tek açık kaynak b-rep çekirdeği olarak görülür
- Ücretsizdir, ancak kaba ve kararsız olabildiği değerlendirilir
- Resmî build talimatları ekranının eski bir Windows ortamı gibi görünmesi eleştirilir
- Truck, yeni geliştirilen açık kaynaklı bir Rust b-rep çekirdeğidir
- GitHub deposu açıktır
- Rust ile yazılmıştır ve WebAssembly derlemesini iyi destekler
- Hem işletim sisteminde hem tarayıcıda çalışabilir
- JavaScript binding'leri ve örnekler sunar
- Bu, Rust'ın C++'tan kategorik olarak daha iyi olduğu anlamına gelmez; ancak açık kaynak projeler için önemli avantajları olduğu düşünülür
- Build araçları güçlü, kullanışlı ve iyi belgelenmiştir
- Merkezi paket yönetimi vardır
- Bellek güvenliği garantileri daha fazladır; bu da paralelleştirmeyi daha kolay ve güvenli kılar
- Derleyici hataları anlaşılırdır ve refactoring'i kolaylaştırır
- Truck yaklaşık 4 yıllık bir projedir ve temel özellikleri şimdiden sağladığı değerlendirilir
.step dosyalarını okuma ve yazma- Sabit tolerans ölçütüyle yüzey üçgenleme
- NURBS desteği
- İki Solid için Intersection veya Union, tek bir Solid için Not işlemi
- Truck küçük ve hafiftir; Ricos adlı bir şirket tarafından geliştirilmektedir
- NURBS'teki B harfinin ifade ettiği B-Splines yerine T-Splines desteği de mümkün olabilir
- T-Splines patenti Autodesk'e aitti, ancak birkaç hafta önce sona erdiği belirtiliyor
- Teorik olarak Truck'a destek eklenebileceği düşünülüyor
Geçmiş takibi ve sürüm yönetimi fikri
- Parametrik CAD, tasarımın Feature History kaydını tutar
- Sketch, extrude ve revolve gibi işlemler biriktirilerek parça oluşturulur
- Önceki adımlara dönüp değerler değiştirilerek işlemler yeniden çalıştırılabilir ve farklı bir parça elde edilebilir
- Modele değişkenler girdi olarak verilirse ve bu değerler değiştirilirse parça güncellenir; böylece model parametreleştirilmiş olur
- Bu yaklaşım başarılı oldu, ancak Topological naming problem gibi zayıf noktaları vardır ve parametrik CAD paradigmasının kendisine yönelik eleştiriler de bulunur
- Bu zayıflıkları azaltmak için Resilient Modeling Strategy gibi yaklaşımlar ortaya çıktı
- chamfer ve fillet, edge tükettiği için en sona yerleştirilir
- Detail feature'lar Core feature'lara referans verebilir, ancak birbirlerine referans vermezler
- CAD programı bu kalıpları zorunlu kılarsa başlangıçta kısıtlayıcı gelebilir, ama tasarımların yeniden kullanımı ve taşınmasını kolaylaştırabilir
- Sketch'lere de feature history ekleme fikri vardı
- Günümüz CAD'lerinde daire, dikdörtgen gibi temel feature'lar çizilir; ardından mirror, linear pattern, sketch fillet gibi araçlarla kopyalanır ve değiştirilir
- Bu bağımlılık grafikleri, onları oluşturan kişi dışındakiler için anlaşılması zor olabilir; çoğu zaman sketch'i silip baştan başlamak daha hızlıdır
- Sketch feature'ları da feature tree içinde saklanıp gösterilirse RMS fikirleri tek bir sketch'e de uygulanabilir
- Tüm kullanıcı olaylarını append-only log olarak kaydetme fikri de vardı
- Log dosyası tek doğruluk kaynağı olursa, bir zaman kaydırıcısıyla belirli bir Feature History yeniden oluşturulabilir
- Dosya kapatılıp yeniden açıldıktan sonra bile sınırsız Undo/Redo mümkün olabilir
- Geçmiş bir sürümden farklı yöne dallanarak git history benzeri bir tasarım denemeleri ağacı kurulabilir
- Hedef, tüm geçerli belge durumlarının kolayca geri getirilebildiği bir CAD uygulamasıydı
- tüm deneme-yanılmalar
- tüm “nihai” çıktılar
- ihtiyaç olduğu fark edilmeyen geçmiş durumlar
- Bu yapı, parçanın farklı varyasyonlarını korumayı ve toolpath generation veya FEA gibi sonraki süreçler çalıştırıldığında tasarımın hangi durumda olduğunu kaydetmeyi mümkün kılabilir
- Buradan, makine tasarımı için bir git yapılabiliyorsa, makine tasarımı için bir GitHub da yapılabilir fikrine uzanılır
Tarayıcı tabanlı 3D kullanıcı arayüzü
- CADmium, CAD'i tarayıcıda yapma yaklaşımını benimsiyordu
- Onshape bu alanın önünü açtı, ancak gerçekte AWS üzerindeki GPU etkin bulut instance'larında çalışıp sonucu tarayıcıya stream eden bir sistem olarak açıklanıyor
- İnternet bağlantısı kesilirse viewport'u döndürmek bile mümkün olmaz
- Truck WebAssembly'ye derlenebildiği için CADmium'un tarayıcı içinde her şeyi işleyen local-first bir uygulama olabileceği düşünülüyordu
- Kullanılan teknoloji yığını şuydu
- Three.js: 3D viewport
- Svelte: durum yönetimi ve reactivity
- Threlte: Svelte ile Three.js bağlantısı
- UI ile b-rep çekirdeği arasında mesajlaşma
- Electron: yerel çalıştırma
- TypeScript, TailwindCSS, Vite vb.
- Bu yığın, tüm uygulamanın reaktif ve deklaratif biçimde yazılmasını sağlayarak veri değişimini mesh güncellemelerine kadar bağlar
- 3D CAD uygulamaları en karmaşık UI türlerinden biridir; bu yüzden küçük bir ekibin iyi bir ürün çıkarabilmesi için framework'lerin çok iş üstlenmesi gerekir
- Bu yığınla çalışan bir proof of concept üretildiği için, CADmium'un darboğazının bu taraf olmadığı düşünülüyordu
JSON dosya formatı ve CLI ekosistemi
- CADmium her şey için JSON kullanmayı hedefliyordu
- Operation Log için JSON Lines planlanıyordu
- Bir parça tasarlandıktan sonra daha basit bir değişim formatına aktarılabilmesi gerektiği düşünülüyordu
- Örnek biçim,
steps dizisinde sketch, extrude gibi işlemleri taşıyan bir JSON yapısıydı
.cadmium dosyasını .step veya .stl biçimine dönüştüren CADmium CLI kullanım örneği veriliyordu
$ CADmium export my_part.cadmium --format stl
- Bir ekosistem kurmak için gerekli iki unsur şöyle tanımlanıyordu
- anlaşılması kolay, basit bir dosya formatı
- bu formatla çalışabilen açık kaynak bir CLI
- Metin düzenleyicide extrude derinliğini ya da fillet yarıçapını değiştirme gibi kullanım örnekleri vardı
- ISO 10303-21 gibi karmaşık spesifikasyonları okumadan, betikle tüm M5 vidalarını M6 vidalarıyla değiştirme gibi senaryoların da mümkün olacağı düşünülüyordu
- Makine tasarımı için GitHub yapılır ve gerçekten kullanılırsa, makine tasarımı için bir GitHub Copilot da hayal edilebilirdi
- Büyük dil modellerinin, karmaşık ticari ikili formatlardan çok basit ve açık metin tabanlı biçimlerde en iyi şekilde çalıştığı değerlendirilir
Gereken yardım ve ertelenen alanlar
- Hangi fikirlerin başarılı olup hangilerinin başarısız olacağı bilinmiyor, ancak bu alanda küçük bir grubun üretim üzerinde büyük etki yaratma fırsatı olduğu düşünülüyor
- İhtiyaç duyulan yardımlar şunlardı
- Rust programlama ve genel iyileştirmeler
- Truck yamaları için hesaplamalı geometri
- Three.js desteği
- yeni kamera denetleyicisi
- daha iyi aydınlatma
- post-processing
- hibe fırsatları veya varlıklı sponsorlar bulma
- Şimdilik ele alınmayan ama ileride dönülmek istenen alanlar şunlardı
- girişim sermayesi
- toolpath generation, yani CAM
- Finite Element Analysis, yani FEA
- CADmium Discord sunucusu duruyor, ancak proje durum açıklamasına göre aktif değil
1 yorum
Hacker News yorumları
Matt’in geliştirdiği şey konusunda büyük beklentim var. Dünyanın, SolidWorks kadar kullanımı kolay bir UI/UX’e sahip açık kaynak parametrik CAD’e ciddi biçimde ihtiyacı var.
Şimdiye kadar bunun iyi yapılamamasının en büyük nedeni yeterince güçlü bir parametrik çekirdeğin olmamasıydı; Matt’in kullandığı Truck ise tam da gereken proje gibi görünüyor. Daha önce OpenCascade buna yaklaşan neredeyse tek seçenekti, ama önemli özellikleri eksik; hataları ve kararsızlığı da fazla.
Truck ve CADmium kararlı fillet desteğine kavuşursa, OpenCascade’in doğru dürüst halefi ve açık kaynak parametrik CAD’in geleceğini kuracak platform olabilir.
Yakın zamanda Alibre Atom3D’ye geçtim; açık kaynak değil ama yalnızca bir kez 200 dolar ödüyorsunuz. Ana işletim sistemi büyük ölçüde değişmediği sürece tasarımlarınızı açmaya devam edebiliyorsunuz ve ACIS çekirdeği üzerinde çalışıyor.
“Browser-first” ifadesi ve README’deki “ücretli barındırılan sürümle gelir elde etme” cümlesi, bana bu projenin ya sönümleneceği ya da büyüdükçe open-core, abonelik zorunlu bir ürüne dönüşeceği; kurulum bağımlılıkları ve güvenlik özellikleri arttıkça gerçek anlamda yerel çalıştırmanın giderek zorlaşacağı izlenimini veriyor.
Haftalık sürümü ve OpenDark temasını denedim; oldukça şık görünüyor. Açık kaynak CAD tarafı gerçekten ilginç bir döneme girmiş gibi.
CAD platformlarını daha fazla denedikçe, dar bir problem alanına uyarlanmış özel uygulamaların genel amaçlı CAD’den çok daha kullanışlı olduğu hissim güçleniyor. SVG/DXF/DWG çıktısı bir avantaj; ama seri üretim makine parçalarından tek seferlik mimariye, otoyollara, 50 millik boru hatlarına, devrelere, kentsel ulaşım planlamasına ve sanata kadar her şeyi yapmaya çalışan çizim yazılımlarının yönünün yanlış olduğunu düşünüyorum.
Sektör standardı yol tasarım yazılımı kullanıyor olmamıza rağmen nesne modelinde “yol” diye bir şey yok. Yatay, düşey ve kesit bileşenleri birbirinden ayrılamaz ve etkileşim kuralları da açık olmasına rağmen her biri bağımsız tanımlanıyor. Tasarımcılar bilgisayara bir şeyi nasıl göstereceğini söylemeye daha az, ortaya çıkacak sonucun kendisini düşünmeye daha çok zaman ayırmalı.
CAD araçları veya açık kaynak konuşulduğunda HN’de QCAD’den neredeyse hiç bahsedilmemesinin nedenini merak ediyorum.
1 - https://www.qcad.org/
Solvespace’in bakımcılarından biri olarak birkaç şey ekleyeyim: Yalnızca 2D kısıtlar yeterli değil; 3D kısıtlar daha iyi. C++ ile yazıyor olsaydınız, Dune3D’nin yaptığı gibi Solvespace’in kısıt çözücüsünü alıp kullanın derdim; ama Rust seviyorsanız Michael F Bryan’ın Rust ile yazıp blogunda anlattığı çalışmaya bakabilirsiniz.
https://adventures.michaelfbryan.com/posts/constraints-part-...
Geometri çekirdeği tarafında Solvespace çekirdeğinde düzeltmek istediğim 3 tür hata var; sadece onları çözebilsek boolean işlemlerini epey kararlı biçimde halledebiliriz, ama zamanım olmadı. Çekirdeğimiz 6 bin satırdan az, dolayısıyla öğrenilecek çok şey vardır. Bu konuda iletişime geçmek isterseniz aynı ID’deki gmail adresine e-posta atabilirsiniz. Truck’a bir süredir bakmadım ve biraz duraklamış olduğunu düşünüyordum. Bu gerçekten zor bir problem; ticari dünyada bile seçenek az. Kesilmiş NURBS kabuklarını üçgenlere bölmek bile zahmetli.
Geçmiş/özellik ağacı, FreeCAD’in topolojik adlandırma sorunu ile yakından ilişkili. Solvespace her varlığı bilinen şeyler kümesinden oluşturarak işler. Yeniden oluşturmaya çalıştığında yeni bir varlık yaratmak yerine mevcut varlık handle’ını döndürür. Yani her varlık “bir şeyden gelmiştir” ve bu ilişkiyi hatırlar. Topolojik adlandırmayı ele aldığımız kısımda kusursuz çalışıyor, ancak Solvespace’in tüm bölümleri kapsanmıyor. Bu baştan konulması gereken bir şey; sonradan kolayca eklenebilecek bir özellik değil.
Ayrıca CADmium’u nerede deneyebileceğimize dair bağlantıyı merak ediyorum.
[1] https://github.com/thekakkun/rust_slvs
Github:
https://github.com/MattFerraro/CADmium
Bağlantı burada:
https://mattferraro.github.io/CADmium/
Bence gerçekten şaşırtıcı bir çalışma. Açık kaynak EDA'nın ulaştığı seviyeye açık kaynak fiziksel CAD'in de gelmesini isterim.
Bu tür matris denklemlerini çözmenin, bilinmeyen sayısı arttığında çok yavaşladığı ve bu yüzden tek tek eskizlerin küçük ve basit olması gerektiğine dair yaygın bir kanı oluştuğu söylenmişti; ama epey derine indiğimde bunun gerçekte büyük bir sorun olmadığını gördüm.
FreeCAD'in kısıt performansı sorunları çoğunlukla yinelenen ve gereksiz GUI yerleşim algoritmalarından kaynaklanıyor; sadece birkaç yüz kısıtla bile çöküyor. Eigen'in seyrek QR ayrıştırması 2200 kısıtta yaklaşık 18 saniye sürüyor, fena değil. 500 bin–1 milyon kısıtı yaklaşık 18 saniyede işleyen seyrek QR ayrıştırma kütüphaneleri de var. Bir CAD eskizinde birkaç binden fazla kısıt olacağı bir durum hayal etmek zor.
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
FreeCAD ve Ondsel ES'te montaj kısıtları için kullanılıyor.
CAD'i uzun zaman önce Autodesk Inventor ile öğrenmiştim; birkaç saat kurcaladıktan sonra anlayabildiğim tek ücretsiz modelleme yazılımı Onshape oldu. Bu alanda kullanılabilirlik gerçekten büyük bir sorun gibi görünüyor.
Örneğin FreeCAD'de aynı işi yapmanın milyarlarca yolu varmış gibi, ama sonunda gerçek yöntem tekmiş gibi hissettiriyordu; bazı eğitimler de elde hatalı bir model bırakıyordu.
Harika bir iş ve zor bir problem gibi görünüyor.
Repo: https://github.com/MattFerraro/CADmium
Neredeyse sadece Part Design, Sketcher, Spreadsheet çalışma tezgâhlarını kullanıyorum. Bu üçü genel olarak birlikte iyi çalışıyor. Çalışma tezgâhları arasındaki birlikte çalışabilirlik kötü olduğu için başka taraflara açılmaya korkuyorum. Ara sıra Part çalışma tezgâhını da kullanıyorum, ama Part Design'da kullanmak için iç format dönüşümünden iki kez geçirmek gerektiğinden çok zahmetli.
Açık kaynak CAD projelerinden birinin bir gün FreeCAD'in yerini almasını umuyorum.
Pratik değildi ama model telefonda bile çalışıyordu.
Fusion360 da kullanılabiliyor, ama kullandığım ticari paketlerle karşılaştırınca kullanıcı deneyimi oldukça berbat.
Ücretsiz CAD'den istediğim şey, birilerinin Creo'nun sağlamlığını ve hızını getirip bunu SolidWorks'ün kullanıcı dostuluğuyla birleştirmesi. Başta özellikleri epey sınırlı olsa da sorun değil.
Süreç hep şöyleydi: beni %80'e kadar götüren bir eğitimi izlemek, kalanını bir şekilde eklemeye çalışmak, sonra o temel eğitimin projeyi kalan %20'yi tamamlanamaz kılacak biçimde kurduğunu fark etmek, önceki adımları düzeltmeye çalışırken tüm projenin dağılması. Bunu tekrar tekrar yaşadım.
CAD'de genelde işlem sırası bu kadar önemli midir? Basit bir nesne, FreeCAD ne kadar zor olabilir ki diye düşünüp atladım; gerçekte ise çok zormuş.
Bu alana yeni girenlerin çıkması ve özellikle yeni bir çekirdek yapmaya çalışmaları ilginç, ancak başarı olasılığı düşük görünüyor. Sektörün en üst düzey çekirdekleri, otomotiv ve havacılık-uzay şirketlerinin finansmanıyla CAGD doktoralıları ve programcılar tarafından onlarca yılda geliştirilmiş şeyler. Temel düzeyde rekabetçi bir özellik kümesine ulaşmak bile uzun zaman alacaktır
Ayrıca hangi kullanıcı sorununu çözmeye çalıştıkları da belirsiz. CAD kullanıcılarının mutlaka açık kaynağa ihtiyacı yok. Bütçe kısıtları olabilir, ama bu alanda açık kaynak, geliştirici araçlarında olduğu gibi kullanıcıya doğrudan görünen bir özellik olmayabilir. Plasticity, Parasolid lisanslayarak da düşük fiyat aralığında para kazanılabileceğini gösterdi
Parametrik CAD araçlarını 30 yılı aşkın süredir kullanıyorum; Onshape, Creo veya SolidWorks'te bulunan birçok sorunu çözen oldukça şaşırtıcı bir çözüm. Verinin kaybolmadığı, dosya sistemi yerine en baştan veritabanı tabanlı yapılmış sınırsız geri alma özelliği olan, iş birliğine yönelik CAD için Google Docs benzeri bir ortam, hayat değiştirici düzeyde. Ancak modelleme özellikleri hâlâ diğer araçları yakalamaya çalışıyor
Onshape, Creo ve SolidWorks'ün büyük dezavantajı, 2D eskizden başlayıp bunu 3D nesneye ekstrüde etme, döndürme veya loft etme yapısına dayanmaları. 3D araçlar, temel yapının bir eklentisi ve neredeyse sonradan düşünülmüş bir unsur gibi. Plasticity, Rhino ve Alias ise çok daha 3D öncelikli
Onshape'in FeatureScript'i çok havalı ve güçlü, ancak CAD kullanıcılarının kendi araçlarını yapması açısından Rhino'nun Grasshopper'ı kadar iyi değil
CADmium'un hangi pazarda ücretli ve ücretsiz alternatiflerden daha iyi bir CAD aracı olacağına, çözeceği kullanıcı sorununa odaklanması gerekiyor. Geliştirmenin erken aşamasında olsa bile kullanıcı ihtiyaçlarını anlamak için asla çok erken değil. Açık kaynak, tek başına bir hedef değil
Modern araçlar, eski motorlardan çıkarılan dersler ve giriş borcunun olmamasıyla küçük bir ekip de 30 yıllık yazılımla aynı seviyede veya ondan daha iyi bir şey yapabilir
Küçük ve adanmış bir ekibin yeni bir parametrik çekirdek ve CAD paketi yapabileceğini düşünüyorum. Özellikle açık kaynaksa bu daha da mümkün
CAD kullanıcıları iyi bir açık kaynak alternatiften büyük fayda sağlayabilir
Buna karşılık tescilli yazılımdan kaçınmak için birçok neden var; SaaS ise bu nedenler daha da güçlü. Çünkü günümüzde giderek daha fazla SaaS'a gidiliyor ve bu örnek de öyle. CAD yazılımı, birçok kullanıcının zaten yüzlerce saat harcayıp öğrendikten ve kullandıktan sonra tescilli sistemin sunum koşullarını değiştirip onları yaktığı bir alan
Azınlıkta olacağımı biliyorum, ama benim için açık kaynak başlı başına mutlak bir hedef. Çok uzun zamandır yalnızca açık kaynak yazılım kullanıyorum
Yine de açık kaynağın hedef olamayacağı kısmından pek emin değilim. KiCAD ile Altium arasındaki ilişkiye benziyor. Onshape'in sunduklarının %90'ı açık kaynak olarak sunulabilirse insanların kullanabileceğini düşünüyorum
Maliyet perspektifini anlıyorum. SolidWorks lisansı kabaca 3 bin–5 bin dolar seviyesinde, bu yüzden çoğu şirket kanıtlanmış araçlara para ödeyip kullanacaktır
Bu arada Onshape, 3 yıl içinde bir MVP çıkarana kadar 10 milyon doların altında bir maliyetle geliştirildi. Günümüzde yeni bir CAD programı yapmak için mutlaka onlarca yıllık doktoralı insan emeği gerektiğini düşünmüyorum
CAD çekirdeği ekosistemini harika özetlemiş
Özellikle şu cümleyi sevdim: "Tek popüler açık kaynak B-rep çekirdeği OpenCascade; B-rep çekirdekleri dünyasının Pontiac Aztek'i. Çirkin, yalnızca temel özelliklere sahip ve bozulabilir, ama yürüyor ve ücretsiz edinebiliyorsunuz"
Gerçekten doğru
Yerel öncelikliyse neden tarayıcıda olması gerektiğini merak ediyorum
Solvespace’in tek bir indirme/çalıştırılabilir dosya olma avantajı var
Ayrıca kısıt çözücüsü CADsketcher ve Dune 3D gibi projelerde kullanılmış: https://github.com/dune3d/dune3d
Yazar, ihtiyaç duyduğu tüm işlevleri sarmalayıcı kod açığa çıkarmadığı için Solvespace’in çözücüsünü doğrudan kullandığını ve ürettiği denklem türleri için yeterince hızlı hale getirmek üzere, uygulanabildiği yerlerde denklemleri sembolik olarak çözmesi için çözücüye yama yapmak zorunda kaldığını söylüyor
https://github.com/jay3sh/cadmium ile bir ilişkisi olup olmadığını da merak ediyorum
CAD çekirdeği olarak Manifold’dan da bahsedilmemiş: https://github.com/elalish/manifold/wiki/Manifold-Library OpenCASCADE ile aynı dezavantajların çoğuna sahip olduğunu anlıyorum ama yine de bahsetmeye değer görünüyor
Bu çekirdek daha önce burada da tartışılmıştı: https://news.ycombinator.com/item?id=35071317
Tam geçmiş ve düzenlenebilirlik özellikle ilginç ve umut verici görünüyor. O geçmişi açılıp kapanabilen bir panelde listeleyip, tamamlanmış öğeleri gizleyen açılır üçgenler ekleyerek mevcut işe odaklanabilmek benim için bir hayalin gerçekleşmesi olurdu. Tabii 3D tarafını anlayabilirsem. Şimdiye kadar denediğim BRL-CAD, FreeCAD, Solvespace, Alibre Atom vb. araçların hepsinde başarısız oldum; başarılı olduğum tek şey OpenSCAD benzeri kod tabanlı araçlardı
Evde bir parça tasarlayıp, işte düzenleyip, maker alanında mevcut ekipmanla üretmeniz gerektiğinde bir şey kurmak zorunda kalmamak büyük avantaj
Solvespace’in üçgen mesh kodunu Manifold ile değiştirmeyi daha önce değerlendirdim, ama iş yükü büyük; asıl gereken NURBS hatalarını düzeltip mesh koduna daha az bağımlı hale gelmek
Bu arada Solvespace kısıt çözücüsü FreeCAD’in Assembly 3 çalışma tezgâhında da kullanılıyor. Son zamanlarda pek çok yere yayılıyor
3D CAD uygulamalarının en karmaşık UI’lardan biri olduğuna katılıyorum
Ancak küçük bir ekibin iyi bir 3D CAD yapabilmesi için framework’ün işin büyük kısmını üstlenmesi gerektiği sözüne şüpheyle yaklaşıyorum. Genel amaçlı bir UI framework’ünün 3D CAD için uzun vadeli çözüm olup olamayacağından emin değilim
İyi UX bazen parametrik 3D modeli, mesh yaklaşımını, gizli yüzey kaldırıldıktan sonra çizgilere ve yamalara izdüşümü, framebuffer’daki pikselleri ve UI widget’larını aynı anda düşünmeyi gerektirir. Framework’ler bilginin kolayca bölünebildiği ve boyutunun sınırlı olduğu varsayımını fazla yapıyor
Prototiplemede yardımcı olur, ama proje büyüdüğünde çekirdek 3D viewport etkileşimlerinde eninde sonunda framework’ü bırakıp OpenGL veya benzeri bir şey ile fare/klavye olayları arasının çoğunu kendi kodunuzla dolduracağınızı düşünüyorum
Düğmeler veya listeler gibi şeyler için framework’ler sorun değil; ama bu öğeler bile 3D CAD’de ortalama bir uygulamaya göre çok daha dinamik
CADmium’un beni OpenSCAD’den uzaklaştırmasını gerçekten umuyorum. OpenSCAD’de başta çok düşünmeniz gerekmez; basit bir dille modüllerin üstüne modüller yığarsınız
Sorun, OpenSCAD’de çözücü olmaması. Değişkenler var ama kısıtlar yok. Değişiklik yaptıkça bir anda kısıtları elle çözmek için epey kafa yormanız gerekir ve hata eklemek kolaylaşır
Yine de sorun başka bir araca geçecek kadar ciddi değil. Çünkü bir modele başlama aşamasında OpenSCAD’in şimdiye kadar kullandığım her şeyden çok daha kolay olduğunu düşünüyorum
https://github.com/Ondsel-Development/OndselSolver
FreeCAD ve Ondsel ES’de kullanılıyor
Başta OpenSCAD ile başlamıştım ama gerçek 3D nesneler oluştururken FreeCAD çok daha üretkendi. Bazen bir dikdörtgenden başlayıp bir çizgiyi silmek ve yarım daire eklemek istersiniz; ama eskize başlamadan önce bunu bilemeyebilirsiniz
OpenSCAD’de gerekli şekil primitiflerini ve tam olarak nasıl değiştireceğinizi önceden bilmeniz gerekiyormuş gibi geliyor; ayrıca 2D’ye ekstrüzyon/döndürme uygulamak yerine 3D primitifleri teşvik etmesi de kişisel olarak beni rahatsız etti
Başkalarının açık kaynak CAD’e zaman ve yetenek yatırdığını görmek güzel. Ondsel’de açık kaynak CAD’in çok önemli olduğuna inanıyoruz ve bu alandaki yenilikleri görmek sevindirici