- CADmium menargetkan CAD parametrik 3D open source yang berjalan di browser, tetapi saat ini telah dihentikan dan repositori GitHub-nya diarsipkan
- Pusat perancangannya ada pada solver kendala 2D, kernel b-rep, pelacakan histori, UI 3D, dan format file yang dirangkai ulang sambil tetap mempertahankan pengalaman yang familier bagi pengguna CAD yang sudah ada
- Penyelesaian kendala 2D dirancang dengan pendekatan konvergensi iteratif seperti simulasi fisika pegas-massa-peredam, alih-alih menyelesaikan satu matriks besar sekaligus
- Untuk kernel b-rep, proyek ini ingin memanfaatkan Truck, proyek open source berbasis Rust, dan menilainya cocok untuk berjalan di browser berkat WebAssembly dan binding JavaScript
- Format file diarahkan menjadi format berbasis teks dengan JSON dan JSON Lines, dengan mempertimbangkan CLI, git-diff, penyuntingan lewat skrip, serta ekosistem kolaborasi dan alat bantu
Status dan tujuan proyek
- CADmium adalah proyek yang berupaya membuat program CAD open source baru
- Saat ini proyek telah dihentikan, dan repositori GitHub tersedia dalam status arsip
- Rilis tidak lagi dipelihara
- PR tidak diterima
- Discord masih ada, tetapi tidak aktif
- Ada 5 komponen CAD parametrik 3D yang menjadi target
- Solver kendala 2D
- Kernel b-rep
- Pelacak histori
- Antarmuka pengguna 3D
- Format file
Pendekatan solver kendala 2D
- Pendekatan yang ada biasanya menggabungkan semua variabel tak diketahui ke dalam vektor besar, mengekspresikan tiap kendala sebagai persamaan linear, lalu menyelesaikannya sebagai persamaan matriks raksasa
- Pendekatan ini memiliki batasan bahwa matriks harus persegi untuk dapat dicari inversnya
- Jika kendala terlalu banyak, matriks bisa menjadi terlalu panjang dan gagal diselesaikan
- Kendala yang redundan bisa menimbulkan masalah over-constrained meskipun sebenarnya kompatibel satu sama lain
- Jika kendala terlalu sedikit, sistem akan menyisipkan asumsi untuk mencari solusi, tetapi elemen sketsa bisa terpental jauh dari yang diharapkan pemodel
- Semakin banyak variabel tak diketahui, semakin lambat persamaan matriks besar ini, sehingga muncul kebiasaan menjaga tiap sketsa tetap kecil dan sederhana
- Alternatif CADmium adalah memperlakukan masalah kendala 2D seperti simulasi fisika
- Tiap titik memiliki massa dan kecepatan
- Tiap kendala bertindak seperti pegas yang memberi gaya pada titik-titik yang terhubung
- Ada gaya gesek yang sebanding dengan kecepatan
- Simulasi dijalankan dalam langkah waktu kecil hingga konvergen
- Alih-alih menyelesaikan seluruh masalah sekaligus, sistem mengulang perubahan kecil untuk mendorong energi potensial pegas menuju 0
- Waktu eksekusi tiap langkah waktu berbanding lurus dengan jumlah pegas dan jumlah variabel tak diketahui, sehingga berpotensi menangani sketsa yang lebih kompleks
- Pendekatan simulasi ini cocok untuk paralelisasi, dan bahkan berpotensi dijalankan di compute shader
- Pada masalah over-constrained, jika sistem tetap konsisten secara internal maka ia tetap terselesaikan, dan jika tidak konsisten maka pegas-pegas akan mencari titik kompromi
- Pada masalah under-constrained, sistem mencari konfigurasi valid terdekat alih-alih melayang tak terbatas
- Pendekatan ini juga dapat mendukung kendala pertidaksamaan
- Membatasi panjang agar lebih besar dari 1 cm dan lebih kecil dari 2 cm
- Membatasi sudut sketsa antara 10 derajat dan 30 derajat
- Ia juga dapat diperluas ke gaya lain, misalnya memperlakukan luas tertentu dari poligon tertutup sebagai gaya tekanan
- Tujuan dasarnya tetap menghadirkan pengalaman yang terasa familier bagi sebagian besar pengguna CAD, tetapi dengan ruang untuk menerapkan ide baru pada penyelesaian kendala 2D
Kernel b-rep dan Truck
- Dalam CAD mekanik, pengguna harus berinteraksi langsung dengan tepi dan permukaan suatu komponen
- CAD parametrik menggunakan Boundary Representation atau b-rep, yaitu pendekatan yang langsung merepresentasikan batas komponen sebagai struktur data
- Kubus direpresentasikan sebagai Solid dengan 6 Face
- Tiap Face memiliki 4 Edge
- Tiap Edge memiliki 2 Point
- Untuk permukaan lengkung, permukaan NURBS umum digunakan karena memungkinkan kontrol bentuk bebas dan representasi akurat kurva kerucut
- b-rep sendiri sudah sulit hanya untuk representasi bentuk, dan tingkat kesulitannya naik tajam saat mengimplementasikan boolean operations seperti Union, Intersection, dan Subtraction
- Pustaka yang menangani data ini dan operasi boolean disebut kernel b-rep
- Perusahaan CAD proprietari besar membangun kernel mereka sendiri selama puluhan tahun, dan kernel proprietari dinilai bagus tetapi mahal
- Di sisi CAD open source, OpenCascade dianggap sebagai satu-satunya kernel b-rep open source yang populer
- Gratis, tetapi dinilai kasar dan bisa tidak stabil
- Tampilan petunjuk build resminya dikritik karena terlihat seperti lingkungan Windows lama
- Truck adalah kernel b-rep Rust open source yang sedang dikembangkan
- Repositori GitHub tersedia untuk umum
- Ditulis dalam Rust dan sangat baik dalam mendukung kompilasi WebAssembly
- Dapat berjalan di sistem operasi maupun browser
- Menyediakan binding JavaScript dan contoh
- Ini bukan berarti Rust secara kategoris selalu lebih baik daripada C++, tetapi bagi proyek open source ia punya banyak kelebihan penting
- Alat build kuat, praktis, dan terdokumentasi dengan baik
- Ada manajemen paket yang terpusat
- Ada lebih banyak jaminan keamanan memori, sehingga paralelisasi lebih mudah dan aman
- Error kompilernya ramah, sehingga refactoring lebih mudah
- Truck adalah proyek berusia sekitar 4 tahun dan dinilai sudah memiliki fungsi-fungsi dasar
- Membaca dan menulis file
.step
- Triangulasi permukaan dengan toleransi tetap
- Dukungan NURBS
- Intersection atau Union untuk dua Solid, serta operasi Not untuk satu Solid
- Truck kecil dan ringan, dan dikembangkan oleh perusahaan bernama Ricos
- Ada pula kemungkinan mendukung T-Splines alih-alih B-Splines, yang menjadi huruf B pada NURBS
- Paten T-Splines dimiliki Autodesk, tetapi disebut telah kedaluwarsa beberapa minggu lalu
- Secara teoretis, dukungan untuk itu bisa ditambahkan ke Truck
Gagasan pelacakan histori dan kontrol versi
- CAD parametrik menyimpan Feature History dari desain
- Operasi seperti sketch, extrude, dan revolve ditumpuk untuk membuat komponen
- Kita bisa kembali ke langkah sebelumnya, mengubah nilai, lalu menjalankan ulang fitur untuk mendapatkan komponen yang berbeda
- Jika variabel dimasukkan sebagai input ke model dan nilainya diubah, komponen ikut diperbarui, sehingga model menjadi terparametrisasi
- Pendekatan ini sukses, tetapi memiliki kelemahan seperti Topological naming problem, dan bahkan paradigma CAD parametrik sendiri juga mendapat kritik
- Salah satu pendekatan untuk mengurangi kelemahan itu adalah Resilient Modeling Strategy
- Chamfer dan fillet ditempatkan di akhir karena mengonsumsi edge
- Detail feature boleh merujuk ke core feature, tetapi tidak saling merujuk satu sama lain
- Jika program CAD memaksa pola-pola seperti ini, awalnya mungkin terasa membatasi, tetapi desain bisa menjadi lebih mudah dipakai ulang dan dipindahkan
- Ada pula gagasan menambahkan feature history ke sketsa
- Dalam CAD modern, fitur dasar seperti lingkaran dan persegi digambar lalu digandakan atau dimodifikasi dengan mirror, linear pattern, sketch fillet, dan sebagainya
- Grafik ketergantungan seperti ini sulit dipahami oleh orang selain pembuatnya, sehingga sering kali lebih cepat menghapus sketsa dan memulai ulang
- Jika fitur sketsa juga disimpan dan ditampilkan di feature tree, gagasan RMS dapat diterapkan bahkan pada satu sketsa saja
- Ada juga ide untuk merekam semua peristiwa pengguna sebagai append-only log
- Jika log menjadi satu-satunya sumber kebenaran file, feature history tertentu bisa direkonstruksi dengan penggeser waktu
- Undo/Redo tanpa batas menjadi mungkin bahkan setelah file ditutup dan dibuka kembali
- Kita bisa bercabang dari versi lama ke arah berbeda dan membuat pohon percobaan desain seperti histori git
- Tujuannya adalah aplikasi CAD yang memungkinkan semua status dokumen yang valid dipulihkan dengan mudah
- Semua proses trial and error
- Semua hasil “final”
- Semua status lama yang dulu belum terasa penting
- Dengan struktur ini, berbagai varian komponen bisa dipertahankan, dan status desain saat menjalankan proses hilir seperti toolpath generation atau FEA juga bisa dicatat
- Gagasannya berlanjut ke pemikiran bahwa jika bisa membuat git untuk desain mekanik, mungkin kita juga bisa membuat GitHub untuk desain mekanik
Antarmuka pengguna 3D berbasis browser
- CADmium mengarah pada cara melakukan CAD di browser
- Onshape membuka jalan, tetapi dijelaskan bahwa pada praktiknya ia berjalan di instance cloud AWS ber-GPU dan hasilnya di-stream ke browser
- Jika koneksi internet putus, bahkan memutar viewport pun tidak bisa dilakukan
- Karena Truck dapat dikompilasi ke WebAssembly, CADmium dapat menjadi aplikasi Local-First yang menangani semua proses langsung di dalam browser
- Stack teknologi yang digunakan adalah sebagai berikut
- Three.js: viewport 3D
- Svelte: manajemen status dan reaktivitas
- Threlte: penghubung Svelte dan Three.js
- Penyampaian pesan antara UI dan kernel b-rep
- Electron: eksekusi lokal
- TypeScript, TailwindCSS, Vite, dan lainnya
- Stack ini memungkinkan seluruh aplikasi ditulis dengan pendekatan reaktif dan deklaratif, sehingga perubahan data dapat tersambung hingga ke pembaruan mesh
- Aplikasi CAD 3D adalah salah satu UI paling kompleks, sehingga agar tim kecil bisa membuat produk yang baik, framework harus mengambil alih banyak pekerjaan
- Karena proof of concept yang berjalan dengan stack ini sudah dibuat, bagian ini dinilai bukan faktor pembatas CADmium
Format file JSON dan ekosistem CLI
- CADmium ingin menggunakan JSON untuk semuanya
- Untuk Operation Log, proyek ini berencana memakai JSON Lines
- Setelah komponen selesai dirancang, hasilnya seharusnya dapat diekspor ke format pertukaran yang lebih sederhana
- Contoh formatnya adalah struktur JSON dengan array
steps yang memuat operasi seperti sketch dan extrude
- Ada contoh penggunaan CADmium CLI untuk mengubah file
.cadmium menjadi .step atau .stl
$ CADmium export my_part.cadmium --format stl
- Dua elemen yang dibutuhkan untuk membangun ekosistem adalah sebagai berikut
- Format file sederhana yang mudah dipahami
- CLI open source yang bisa menangani format tersebut
- Ada contoh penggunaan mengubah kedalaman extrude atau radius fillet lewat editor teks
- Ada juga kemungkinan penggunaan seperti mengganti semua baut M5 menjadi baut M6 lewat skrip tanpa harus membaca spesifikasi rumit seperti ISO 10303-21
- Jika suatu hari GitHub untuk desain mekanik benar-benar dibuat dan digunakan, maka GitHub Copilot untuk desain mekanik juga bisa dibayangkan
- Model bahasa besar dinilai bekerja paling baik pada format berbasis teks yang sederhana dan terbuka, dibanding format biner proprietari yang kompleks
Bantuan yang dibutuhkan dan area yang ditunda
- Belum bisa diketahui ide mana yang akan berhasil atau gagal, tetapi dinilai ada peluang bagi kelompok kecil untuk memberi dampak besar pada manufaktur di bidang ini
- Bantuan yang dibutuhkan meliputi
- Pemrograman Rust dan peningkatan umum
- Geometri komputasi untuk patch Truck
- Dukungan Three.js
- Pengontrol kamera baru
- Pencahayaan yang lebih baik
- Post-processing
- Mencari peluang hibah atau sponsor kaya
- Area yang untuk sekarang belum ditangani tetapi ingin ditinjau lagi nanti adalah sebagai berikut
- Modal ventura
- toolpath generation, yaitu CAM
- Finite Element Analysis, yaitu FEA
- Server Discord CADmium masih ada, tetapi menurut pemberitahuan status proyek, tidak aktif
1 komentar
Opini Hacker News
Sangat menantikan apa yang sedang dibuat Matt. Dunia sangat membutuhkan CAD parametrik open-source dengan UI/UX yang semudah SolidWorks
Alasan terbesar sejauh ini hal itu belum berhasil adalah karena belum ada kernel parametrik yang cukup kuat, dan Truck yang digunakan Matt terlihat seperti proyek yang tepat untuk kebutuhan itu. Sebelumnya OpenCascade hampir menjadi satu-satunya yang mendekati, tetapi kurang fitur penting serta banyak bug dan ketidakstabilan
Jika Truck dan CADmium bisa mendapatkan fillet yang stabil, keduanya bisa menjadi penerus OpenCascade yang layak sekaligus platform untuk membangun masa depan CAD parametrik open-source
Baru-baru ini saya pindah ke Alibre Atom3D; memang bukan open-source, tetapi cukup bayar sekali 200 dolar. Selama OS host tidak berubah besar-besaran, desain tetap bisa dibuka, dan berjalan di atas kernel ACIS
Melihat frasa "browser-first" dan "monetisasi dengan versi hosting berbayar" di README, proyek ini terbaca seperti sesuatu yang akan meredup, atau ketika membesar menjadi produk open-core yang wajib berlangganan, dengan dependensi instalasi dan fitur keamanan yang bertambah sehingga eksekusi lokal yang benar-benar lokal makin sulit
Saya mencoba versi mingguan dan tema OpenDark, dan tampilannya cukup rapi. Ini tampak seperti masa yang benar-benar menarik untuk CAD open-source
Semakin banyak saya mencoba platform CAD, semakin kuat kesan bahwa aplikasi khusus yang disesuaikan untuk ranah masalah yang sempit jauh lebih berguna daripada CAD serbaguna. Output SVG/DXF/DWG memang kelebihan, tetapi menurut saya perangkat lunak gambar yang berusaha menangani semuanya—komponen mesin produksi massal, bangunan sekali pakai, jalan raya, pipa sepanjang 50 mil, sirkuit, perencanaan transportasi kota, sampai seni—sudah salah arah
Bahkan ketika memakai perangkat lunak desain jalan standar industri, tidak ada objek "jalan" dalam model objeknya. Komponen horizontal, vertikal, dan penampang tidak bisa dipisahkan satu sama lain dan aturan interaksinya juga jelas, tetapi masing-masing didefinisikan secara independen. Perancang seharusnya menghabiskan lebih sedikit waktu memberi tahu komputer bagaimana sesuatu harus ditampilkan, dan lebih banyak memikirkan hasil akhirnya sendiri
Saya penasaran mengapa QCAD hampir tidak pernah disebut di HN ketika topiknya alat CAD atau open-source
1 - https://www.qcad.org/
Sebagai salah satu maintainer Solvespace, saya ingin menambahkan beberapa hal: constraint 2D saja tidak cukup, dan constraint 3D lebih baik. Jika menulis dengan C++, saya akan menyarankan memakai constraint solver Solvespace seperti yang dilakukan Dune3D, tetapi jika menyukai Rust, Anda bisa melihat pekerjaan yang ditulis Michael F Bryan dalam Rust dan dibahas di blognya
https://adventures.michaelfbryan.com/posts/constraints-part-...
Untuk kernel geometri, ada 3 jenis bug di kernel Solvespace yang ingin saya perbaiki, dan jika itu saja dibereskan, operasi boolean semestinya bisa ditangani cukup stabil, tetapi saya belum punya waktu. Kernel kami kurang dari 6 ribu baris, jadi akan banyak yang bisa dipelajari. Jika ingin menghubungi saya tentang topik ini, kirim email ke gmail dengan ID yang sama. Saya sudah lama tidak melihat Truck dan sempat mengira proyek itu agak mandek. Ini masalah yang benar-benar sulit, sehingga bahkan di dunia komersial pun pilihannya sedikit. Bahkan melakukan triangulasi pada trimmed NURBS shell saja rumit
History/feature tree sangat berkaitan erat dengan masalah topological naming di FreeCAD. Solvespace menanganinya dengan membuat setiap entitas dari sekumpulan hal yang sudah diketahui. Jika mencoba membuatnya lagi, ia tidak membuat entitas baru, melainkan mengembalikan handle entitas yang sudah ada. Artinya setiap entitas "berasal dari sesuatu" dan hubungan itu diingat. Pada bagian tempat kami menangani topological naming, ini bekerja sempurna, tetapi tidak semua bagian Solvespace tercakup. Hal seperti ini harus dimasukkan sejak awal, bukan sesuatu yang mudah ditempelkan belakangan
Dan saya penasaran di mana CADmium bisa dicoba; apakah ada tautannya?
[1] https://github.com/thekakkun/rust_slvs
Github:
https://github.com/MattFerraro/CADmium
Ada tautannya di sini:
https://mattferraro.github.io/CADmium/
Menurut saya ini pekerjaan yang benar-benar menakjubkan. Saya berharap CAD fisik open source bisa mencapai level yang sudah dicapai EDA open source
Katanya ada anggapan umum bahwa menyelesaikan persamaan matriks semacam ini menjadi terlalu lambat ketika jumlah variabel tak diketahui bertambah, sehingga tiap sketsa harus kecil dan sederhana. Namun setelah menguliknya cukup dalam, sebenarnya itu bukan masalah besar
Masalah performa constraint di FreeCAD terutama berasal dari algoritma penataan GUI yang redundan dan tidak perlu, dan bisa runtuh hanya dengan beberapa ratus constraint. Dekomposisi sparse QR milik Eigen memakan sekitar 18 detik untuk 2.200 constraint, jadi tidak buruk. Ada juga pustaka dekomposisi sparse QR yang dapat menangani 500 ribu–1 juta constraint dalam sekitar 18 detik. Sulit membayangkan ada situasi ketika sketsa CAD memiliki lebih dari ribuan constraint
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
Ini digunakan untuk constraint assembly di FreeCAD dan Ondsel ES
Dulu sekali saya belajar CAD dengan Autodesk Inventor, dan satu-satunya perangkat lunak pemodelan gratis yang bisa saya pahami setelah beberapa jam mencoba adalah Onshape. Di bidang ini, usability tampaknya benar-benar menjadi masalah besar
Misalnya, FreeCAD terasa punya miliaran cara untuk melakukan hal yang sama, tetapi pada akhirnya cara yang benar hanya satu, dan beberapa tutorial malah meninggalkan model yang tidak valid
Ini karya yang keren, dan tampaknya masalah yang sulit
Repo: https://github.com/MattFerraro/CADmium
Saya hampir hanya memakai workbench Part Design, Sketcher, Spreadsheet. Ketiganya secara umum bekerja cukup baik bersama. Interoperabilitas antar-workbench buruk, jadi saya takut memperluas ke bagian lain. Kadang saya juga memakai workbench Part, tetapi agar bisa dipakai di Part Design harus melewati konversi format internal dua kali, sehingga sangat merepotkan
Saya berharap suatu hari salah satu dari banyak proyek CAD open source akan menggantikan FreeCAD
Memang tidak praktis, tetapi modelnya bahkan berjalan di ponsel
Fusion360 juga bisa dipakai, tetapi dibanding paket komersial yang pernah saya gunakan, pengalaman penggunanya cukup mengerikan
Yang saya harapkan dari CAD gratis adalah ada yang membawa ketangguhan dan kecepatan Creo lalu menggabungkannya dengan keramahan SolidWorks. Tidak apa-apa kalau pada awalnya fiturnya cukup terbatas
Prosesnya seperti ini: mengikuti tutorial yang membawa saya sampai 80%, mencoba menambal sisanya entah bagaimana, menyadari bahwa tutorial dasar itu menyusun proyek dengan cara yang tidak memungkinkan menyelesaikan 20% sisanya, lalu saat mencoba memperbaiki langkah sebelumnya seluruh proyek runtuh. Itu berulang terus
Dalam CAD, apakah biasanya urutan kerja memang sepenting itu? Saya masuk dengan pikiran bahwa ini objek sederhana dan FreeCAD masa sesulit apa, tetapi ternyata sangat sulit
Menarik bahwa ada pendatang baru di bidang ini, terutama karena mereka mencoba membuat kernel baru, tetapi peluang suksesnya tampak kecil. Kernel kelas atas di industri ini dikembangkan selama puluhan tahun oleh doktor CAGD dan programmer dengan dukungan pendanaan dari perusahaan otomotif dan dirgantara. Untuk mencapai kumpulan fitur dasar yang kompetitif saja akan memakan waktu lama
Selain itu, saya juga mempertanyakan masalah pengguna apa yang ingin mereka pecahkan. Pengguna CAD tidak selalu membutuhkan open source. Memang ada kendala anggaran, tetapi di bidang ini open source mungkin bukan fitur yang langsung terlihat oleh pengguna seperti pada developer tools. Plasticity menunjukkan bahwa dengan melisensikan Parasolid pun tetap bisa menghasilkan uang di kisaran harga rendah
Saya sudah memakai alat CAD parametrik selama lebih dari 30 tahun, dan Onshape adalah solusi yang cukup luar biasa untuk banyak masalah yang ada di Creo atau SolidWorks. Lingkungan seperti Google Docs untuk CAD kolaboratif, dengan data yang tidak hilang, undo tak terbatas yang sejak awal dibuat berbasis database alih-alih sistem file, benar-benar bisa mengubah hidup. Namun, fitur pemodelannya masih dalam proses mengejar alat lain
Kelemahan besar Onshape, Creo, dan SolidWorks adalah strukturnya dimulai dari sketsa 2D lalu diekstrusi, diputar, atau di-loft menjadi objek 3D. Alat 3D lebih seperti fitur tambahan dan pemikiran belakangan dari struktur dasarnya. Plasticity, Rhino, dan Alias jauh lebih 3D-first
FeatureScript milik Onshape sangat keren dan kuat, tetapi untuk pengguna CAD yang ingin membuat alatnya sendiri, itu tidak sebaik Grasshopper milik Rhino
CADmium perlu berfokus pada pasar mana yang akan membuatnya menjadi alat CAD yang lebih baik daripada alternatif berbayar maupun gratis, serta masalah pengguna apa yang akan dipecahkan. Meski masih awal dalam pengembangan, tidak pernah terlalu dini untuk memahami kebutuhan pengguna. Open source bukan tujuan dengan sendirinya
Dengan alat modern, pelajaran dari engine lama, dan tanpa utang masuk, tim kecil pun bisa membuat sesuatu yang setara atau lebih baik daripada perangkat lunak berusia 30 tahun
Saya rasa tim kecil yang berdedikasi bisa membuat kernel parametrik dan paket CAD baru. Apalagi jika open source
Pengguna CAD bisa sangat diuntungkan oleh alternatif open source yang baik
Sebaliknya, ada banyak alasan untuk menghindari perangkat lunak proprietari, dan alasannya lebih kuat jika berbentuk SaaS. Sekarang arahnya makin banyak ke SaaS, dan kasus ini juga demikian. Perangkat lunak CAD adalah bidang di mana banyak pengguna sudah menghabiskan ratusan jam untuk belajar dan menggunakannya, lalu tersengat ketika sistem proprietari mengubah ketentuan yang ditawarkan
Saya tahu mungkin jumlahnya kecil, tetapi bagi saya open source adalah tujuan mutlak dengan sendirinya. Saya sudah sangat lama hanya memakai perangkat lunak open source
Namun saya masih kurang paham bagian bahwa open source tidak bisa menjadi tujuan. Mirip hubungan antara KiCAD dan Altium. Jika 90% dari apa yang ditawarkan Onshape bisa disediakan secara open source, menurut saya orang-orang bisa menggunakannya
Saya memahami sudut pandang biaya. Lisensi SolidWorks kira-kira berada di kisaran 3.000–5.000 dolar, jadi sebagian besar perusahaan akan membayar untuk memakai alat yang sudah terbukti
Sebagai catatan, Onshape dibuat dengan biaya kurang dari 10 juta dolar hingga menghasilkan MVP dalam 3 tahun. Saya tidak melihat bahwa membuat program CAD baru sekarang harus selalu membutuhkan tenaga doktor selama puluhan tahun
Ringkasan ekosistem kernel CAD-nya sangat bagus
Saya terutama suka kalimat, "Satu-satunya kernel B-rep open source yang populer adalah OpenCascade, dan itu adalah Pontiac Aztek-nya dunia kernel B-rep. Jelek, hanya punya fitur dasar, dan bisa saja rusak, tetapi tetap bisa berjalan dan bisa didapat gratis"
Benar-benar tepat
Kalau mengutamakan lokal, saya penasaran kenapa harus dilakukan di browser
Solvespace punya keunggulan berupa satu berkas unduh/eksekusi tunggal
Selain itu, constraint solver-nya dipakai di proyek seperti CADsketcher dan Dune 3D: https://github.com/dune3d/dune3d
Penulisnya mengatakan bahwa karena wrapper code tidak mengekspos semua fungsi yang dibutuhkan, ia memakai solver Solvespace secara langsung, dan harus mem-patch solver agar menyelesaikan persamaan secara simbolik di tempat yang memungkinkan supaya cukup cepat untuk jenis persamaan yang dihasilkannya
Saya juga penasaran apakah ini terkait dengan https://github.com/jay3sh/cadmium
Manifold juga tidak disebut sebagai kernel CAD: https://github.com/elalish/manifold/wiki/Manifold-Library Saya paham ini punya banyak kekurangan yang sama seperti OpenCASCADE, tetapi tetap tampaknya layak disebut
Kernel ini dulu juga pernah dibahas di sini: https://news.ycombinator.com/item?id=35071317
Riwayat penuh dan kemampuan untuk mengeditnya terlihat sangat menarik dan menjanjikan. Kalau riwayat itu bisa ditampilkan dalam panel yang bisa dibuka-tutup, lalu ditambahkan segitiga ekspansi untuk menyembunyikan elemen yang sudah selesai agar bisa fokus pada pekerjaan saat ini, bagi saya itu seperti mimpi yang terwujud. Namun dengan syarat saya bisa memahami sisi 3D-nya. Sejauh ini saya gagal di semua yang pernah saya coba seperti BRL-CAD, FreeCAD, Solvespace, Alibre Atom, dan yang berhasil hanya alat berbasis kode yang mirip OpenSCAD
Saat harus merancang komponen di rumah, memodifikasinya di kantor, lalu membuatnya dengan peralatan yang tersedia di makerspace, tidak perlu memasang apa pun adalah keuntungan besar
Saya pernah mempertimbangkan mengganti kode mesh segitiga Solvespace dengan Manifold, tetapi pekerjaannya banyak, dan yang benar-benar dibutuhkan adalah memperbaiki bug NURBS agar lebih sedikit bergantung pada kode mesh
Sebagai catatan, constraint solver Solvespace juga dipakai di workbench Assembly 3 milik FreeCAD. Belakangan ini makin menyebar ke mana-mana
Saya setuju bahwa aplikasi CAD 3D termasuk salah satu UI paling kompleks
Namun saya skeptis terhadap pernyataan bahwa agar tim kecil bisa membuat CAD 3D yang bagus, framework harus mengambil alih banyak pekerjaan. Saya ragu framework UI serbaguna bisa menjadi solusi jangka panjang untuk CAD 3D
UX yang baik terkadang harus mempertimbangkan model 3D parametrik, aproksimasi mesh, proyeksi menjadi garis dan patch setelah hidden surface removal, piksel di frame buffer, dan widget UI secara bersamaan. Framework membuat terlalu banyak asumsi bahwa informasi mudah dipisahkan dan ukurannya juga terbatas
Untuk membuat prototipe mungkin membantu, tetapi ketika proyek membesar, pada akhirnya untuk interaksi viewport 3D inti saya rasa framework akan ditinggalkan, dan sebagian besar celah antara OpenGL atau sejenisnya dengan event mouse/keyboard akan diisi oleh kode sendiri
Framework untuk tombol atau daftar mungkin baik-baik saja, tetapi bahkan elemen seperti itu pun di CAD 3D jauh lebih dinamis dibanding aplikasi rata-rata
Saya sangat berharap CADmium bisa membuat saya lepas dari OpenSCAD. Di OpenSCAD, pada awalnya tidak perlu berpikir terlalu besar; cukup menumpuk modul di atas modul dengan bahasa yang sederhana
Masalahnya, OpenSCAD tidak punya solver. Ada variabel, tetapi tidak ada constraint. Saat melakukan perubahan, tiba-tiba kita harus banyak berpikir untuk menyelesaikan constraint secara manual, dan mudah memasukkan kesalahan
Meski begitu, masalahnya belum separah itu sampai saya pindah ke alat lain. Sebab pada tahap memulai model, menurut saya OpenSCAD jauh lebih mudah daripada apa pun yang pernah saya pakai
https://github.com/Ondsel-Development/OndselSolver
Ini digunakan di FreeCAD dan Ondsel ES
Awalnya saya mulai dengan OpenSCAD, tetapi saat membuat objek 3D nyata, FreeCAD jauh lebih produktif. Kadang saya ingin mulai dari persegi, menghapus satu garis, lalu menambahkan setengah lingkaran, tetapi sebelum mulai membuat sketsa saya belum tahu itu
Di OpenSCAD rasanya kita harus tahu terlebih dahulu primitive geometri yang diperlukan dan cara modifikasi yang tepat, dan secara pribadi saya juga kurang suka karena ia cenderung mendorong primitive 3D alih-alih menerapkan ekstrusi/rotasi pada 2D
Senang melihat orang lain menginvestasikan waktu dan bakat mereka ke CAD open source. Di Ondsel, kami percaya bahwa CAD open source sangat penting, dan kami senang melihat inovasi di area ini