- CADmium เป็นโครงการที่มุ่งสร้าง โอเพนซอร์ส 3D parametric CAD ที่ทำงานในเบราว์เซอร์ แต่ปัจจุบันยุติการพัฒนาแล้ว และเหลือเพียงที่เก็บ GitHub ในสถานะ archive
- แกนหลักของแนวคิดการออกแบบคือการประกอบใหม่ระหว่าง ตัวแก้ข้อจำกัด 2D, b-rep kernel, การติดตาม history, 3D UI และรูปแบบไฟล์ โดยยังคงประสบการณ์ที่ผู้ใช้ CAD เดิมคุ้นเคย
- สำหรับการแก้ข้อจำกัด 2D มีแนวคิดจะใช้การทำให้ลู่เข้าแบบวนซ้ำ คล้ายการจำลองฟิสิกส์ spring-mass-damper แทนการแก้เมทริกซ์ขนาดใหญ่ในครั้งเดียว
- สำหรับ b-rep kernel มีแผนจะใช้ Truck ซึ่งเป็นโอเพนซอร์สบน Rust และมองว่าเหมาะกับการรันในเบราว์เซอร์ด้วย WebAssembly และ JavaScript bindings
- รูปแบบไฟล์มุ่งไปที่ ฟอร์แมตเน้นข้อความ ที่อิงกับ JSON และ JSON Lines เพื่อรองรับ CLI, git-diff, การแก้ไขด้วยสคริปต์ รวมถึงระบบนิเวศของการทำงานร่วมกันและเครื่องมือเสริม
สถานะและเป้าหมายของโครงการ
- CADmium เป็นโครงการที่ตั้งใจจะสร้าง โปรแกรม CAD โอเพนซอร์ส ตัวใหม่
- ขณะนี้โครงการ ยุติแล้ว และที่เก็บ GitHub เปิดให้อยู่ในสถานะ archive
- ไม่มีการดูแลการแจกจ่ายต่อ
- ไม่รับ PR
- ยังมี Discord อยู่ แต่ไม่ใช่ชุมชนที่ active แล้ว
- องค์ประกอบ 5 อย่างของ 3D parametric CAD ที่ตั้งเป้าไว้มีดังนี้
- ตัวแก้ข้อจำกัด 2D
- b-rep kernel
- ตัวติดตาม history
- ส่วนติดต่อผู้ใช้ 3D
- รูปแบบไฟล์
แนวทางของตัวแก้ข้อจำกัด 2D
- วิธีดั้งเดิมคือรวบรวมตัวแปรไม่ทราบค่าทั้งหมดเป็นเวกเตอร์ขนาดใหญ่ แล้วแทนแต่ละข้อจำกัดเป็นสมการเชิงเส้น จากนั้นแก้เป็นสมการเมทริกซ์ขนาดใหญ่
- วิธีนี้มีข้อจำกัดว่าหากต้องหาผกผันเมทริกซ์ เมทริกซ์จะต้องเป็น สี่เหลี่ยมจัตุรัส
- หากมีข้อจำกัดมากเกินไป เมทริกซ์อาจยาวเกินและแก้ไม่ได้
- แม้ข้อจำกัดที่ซ้ำกันจะเข้ากันได้ ก็ยังอาจเกิดปัญหา over-constrained
- หากข้อจำกัดน้อยเกินไป ระบบจะใส่สมมติฐานเพื่อหาเฉลย แต่สเก็ตช์อาจกระเด็นไปไกลจากที่ผู้ใช้คาดไว้
- เมื่อจำนวนตัวแปรเพิ่มขึ้น สมการเมทริกซ์ขนาดใหญ่จะช้าลง จึงเกิดแนวปฏิบัติให้สเก็ตช์แต่ละชิ้นเล็กและเรียบง่าย
- ทางเลือกของ CADmium คือมองปัญหาข้อจำกัด 2D เป็น การจำลองฟิสิกส์
- แต่ละจุดมีมวลและความเร็ว
- แต่ละข้อจำกัดทำงานเหมือนสปริงที่ออกแรงกับจุดที่เชื่อมอยู่
- มีแรงเสียดทานที่แปรผันตามความเร็ว
- เดินการจำลองด้วยช่วงเวลาสั้น ๆ ให้ค่อย ๆ ลู่เข้า
- แทนที่จะแก้ปัญหาทั้งหมดในคราวเดียว ระบบจะทำการเปลี่ยนแปลงเล็ก ๆ ซ้ำ ๆ เพื่อดันพลังงานศักย์ของสปริงให้เข้าใกล้ 0
- เวลาในการประมวลผลของแต่ละช่วงเวลาจะแปรผันเชิงเส้นกับจำนวนสปริงและจำนวนตัวแปร จึงอาจรองรับสเก็ตช์ที่ซับซ้อนกว่าได้
- แนวทางแบบจำลองนี้เหมาะกับการทำงานแบบขนาน และอาจนำไปรันบน compute shader ได้
- ในกรณี over-constrained หากระบบสอดคล้องกันในตัวก็จะยังแก้ได้ตามปกติ และหากไม่สอดคล้องกัน สปริงจะหาจุดประนีประนอม
- ในกรณีข้อจำกัดไม่พอ ระบบจะหาคอนฟิกูเรชันที่ถูกต้องที่ใกล้ที่สุด แทนที่จะปลิวออกไปไม่สิ้นสุด
- วิธีนี้ยังอาจรองรับข้อจำกัดแบบอสมการได้ด้วย
- จำกัดความยาวให้มากกว่า 1cm และน้อยกว่า 2cm
- จำกัดมุมของสเก็ตช์ให้อยู่ระหว่าง 10 ถึง 30 องศา
- ยังต่อยอดไปสู่แรงประเภทอื่นได้ เช่น จัดการพื้นที่ของรูปหลายเหลี่ยมปิดด้วยแรงดัน
- เป้าหมายพื้นฐานยังคงเป็นประสบการณ์ที่ผู้ใช้ CAD ส่วนใหญ่รู้สึกคุ้นเคย แต่เห็นว่าการแก้ข้อจำกัด 2D ยังมีพื้นที่ให้ใส่ แนวคิดใหม่
b-rep kernel และ Truck
- ใน mechanical CAD ผู้ใช้ต้องจัดการกับ ขอบและผิวหน้า ของชิ้นส่วนโดยตรง
- parametric CAD ใช้วิธี Boundary Representation หรือ b-rep ซึ่งแสดงขอบเขตของชิ้นส่วนเป็นโครงสร้างข้อมูลโดยตรง
- ลูกบาศก์แสดงเป็น Solid ที่มี Face 6 ด้าน
- แต่ละ Face มี Edge 4 เส้น
- แต่ละ Edge มี Point 2 จุด
- สำหรับผิวโค้ง มักใช้ผิว NURBS ซึ่งช่วยควบคุมรูปทรงอิสระและแทนเส้นโค้งภาคตัดกรวยได้อย่างแม่นยำ
- แค่การแทนรูปทรงด้วย b-rep ก็ยากอยู่แล้ว และความซับซ้อนจะเพิ่มขึ้นมากเมื่อทำ boolean operations อย่าง Union, Intersection และ Subtraction
- ไลบรารีที่จัดการข้อมูลประเภทนี้และการดำเนินการแบบบูลีนก็คือ b-rep kernel
- บริษัท CAD เชิงพาณิชย์รายใหญ่สร้าง kernel ของตนเองมานานหลายสิบปี และโดยทั่วไป kernel แบบ proprietary นั้นดีแต่มีราคาแพง
- ฝั่งโอเพนซอร์ส OpenCascade ถูกมองว่าเป็น b-rep kernel โอเพนซอร์สยอดนิยมเพียงตัวเดียว
- ใช้ได้ฟรี แต่ถูกประเมินว่าหยาบและไม่ค่อยเสถียรนัก
- มีการชี้ว่าหน้าคำแนะนำการ build อย่างเป็นทางการดูเหมือนสภาพแวดล้อม Windows ยุคเก่า
- Truck เป็น โอเพนซอร์ส Rust b-rep kernel ที่กำลังพัฒนาอยู่
- มี GitHub repository เปิดเผยสู่สาธารณะ
- เขียนด้วย Rust และรองรับการคอมไพล์เป็น WebAssembly ได้ดี
- รันได้ทั้งบนระบบปฏิบัติการและในเบราว์เซอร์
- มี JavaScript bindings และ ตัวอย่าง
- ไม่ได้หมายความว่า Rust ดีกว่า C++ แบบครอบจักรวาล แต่สำหรับโครงการโอเพนซอร์สมีข้อดีสำคัญหลายอย่าง
- เครื่องมือ build ทรงพลัง ใช้งานสะดวก และมีเอกสารดี
- มีระบบจัดการแพ็กเกจแบบรวมศูนย์
- มีการรับประกันความปลอดภัยหน่วยความจำมากกว่า จึงทำ parallelization ได้ง่ายและปลอดภัยขึ้น
- ข้อความ error จากคอมไพเลอร์เป็นมิตร ทำให้ refactor ได้ง่าย
- Truck เป็นโครงการอายุราว 4 ปี และถูกมองว่ามีฟังก์ชันพื้นฐานพร้อมแล้ว
- อ่านและเขียนไฟล์
.step
- การทำ triangulation ของผิวตามค่า tolerance คงที่
- รองรับ NURBS
- Intersection หรือ Union ของ Solid สองชิ้น และการทำ Not กับ Solid เดี่ยว
- Truck มีขนาดเล็กและเบา และกำลังพัฒนาโดยบริษัทชื่อ Ricos
- ยังมีความเป็นไปได้ที่จะรองรับ T-Splines แทน B-Splines ที่เป็นตัว B ใน NURBS
- มีการระบุว่าสิทธิบัตร T-Splines ของ Autodesk เพิ่งหมดอายุไปเมื่อไม่กี่สัปดาห์ก่อน
- จึงมองว่าในทางทฤษฎีสามารถเพิ่มการรองรับให้ Truck ได้
แนวคิดเรื่องการติดตาม history และ version control
- parametric CAD จะเก็บ Feature History ของการออกแบบไว้
- สร้างชิ้นส่วนโดยสะสมการทำงานอย่างสเก็ตช์ การ extrude และการ revolve
- ผู้ใช้สามารถย้อนกลับไปแก้ค่าที่ขั้นก่อนหน้า แล้วรันฟีเจอร์อีกครั้งเพื่อได้ชิ้นส่วนแบบใหม่
- เมื่อป้อนตัวแปรเข้าไปในโมเดลและเปลี่ยนค่า ชิ้นส่วนจะอัปเดตตาม ทำให้โมเดลเป็นแบบ parameterized
- แนวทางนี้ประสบความสำเร็จ แต่ก็มีจุดอ่อนอย่าง Topological naming problem และยังมี บทวิจารณ์ ต่อกระบวนทัศน์ของ parametric CAD เอง
- แนวทางหนึ่งเพื่อลดความเปราะบางคือ Resilient Modeling Strategy
- chamfer และ fillet ใช้ edge หมดไป จึงควรวางไว้ท้ายสุด
- detail feature อ้างอิง core feature ได้ แต่ไม่ควรอ้างอิงกันเอง
- หากโปรแกรม CAD บังคับใช้แพตเทิร์นเหล่านี้ แม้ตอนแรกจะรู้สึกเป็นข้อจำกัด แต่ก็อาจช่วยให้การนำแบบกลับมาใช้ใหม่และการย้ายต่อทำได้ง่ายขึ้น
- ยังมีแนวคิดจะเพิ่ม feature history ให้กับสเก็ตช์ด้วย
- CAD ปัจจุบันมักวาดฟีเจอร์พื้นฐานอย่างวงกลมหรือสี่เหลี่ยม แล้วค่อยคัดลอกหรือปรับแต่งด้วย mirror, linear pattern, sketch fillet เป็นต้น
- กราฟความพึ่งพาแบบนี้มักเข้าใจยากสำหรับคนที่ไม่ได้เป็นผู้สร้าง จนบางครั้งลบทิ้งแล้วเริ่มสเก็ตช์ใหม่ยังเร็วกว่า
- หากเก็บและแสดง sketch feature ใน feature tree ก็อาจนำแนวคิด RMS มาใช้กับสเก็ตช์เดี่ยวได้
- อีกแนวคิดคือบันทึกทุกเหตุการณ์ของผู้ใช้เป็น append-only log
- หาก log เป็นแหล่งความจริงหนึ่งเดียวของไฟล์ ก็สามารถสร้าง Feature History ณ จุดใดจุดหนึ่งกลับมาใหม่ผ่าน time slider ได้
- ทำให้ Undo/Redo ได้ไม่จำกัดแม้ปิดไฟล์แล้วเปิดใหม่
- ยังสามารถแตกแขนงจากเวอร์ชันเก่าไปอีกทิศทางหนึ่ง เพื่อสร้างต้นไม้ของการลองออกแบบแบบเดียวกับ git history
- เป้าหมายคือแอป CAD ที่กู้คืนทุกสถานะเอกสารที่ถูกต้องได้อย่างง่ายดาย
- ทุกการลองผิดลองถูก
- ทุกผลลัพธ์ “final”
- ทุกสถานะในอดีตที่ตอนนั้นยังไม่รู้ว่าจะต้องใช้
- หากมีโครงสร้างแบบนี้ ก็จะเก็บรูปแบบหลายเวอร์ชันของชิ้นส่วนไว้ได้ และยังบันทึกสถานะการออกแบบตอนรันกระบวนการปลายน้ำอย่าง toolpath generation หรือ FEA ได้ด้วย
- แนวคิดนี้ต่อยอดไปถึงว่า ถ้าสร้าง git สำหรับงานออกแบบเครื่องกลได้ ก็อาจสร้าง GitHub สำหรับงานออกแบบเครื่องกลได้เช่นกัน
ส่วนติดต่อผู้ใช้ 3D บนเบราว์เซอร์
- CADmium มุ่งสู่การทำ CAD บนเบราว์เซอร์
- Onshape เปิดทางไว้ก่อนแล้ว แต่ในทางปฏิบัติอธิบายว่าใช้วิธีรันบน cloud instance ที่เปิดใช้ GPU บน AWS แล้วสตรีมผลลัพธ์มาที่เบราว์เซอร์
- หากอินเทอร์เน็ตหลุด แม้แต่การหมุน viewport ก็ยังทำไม่ได้
- เนื่องจาก Truck สามารถคอมไพล์เป็น WebAssembly ได้ CADmium จึงมีแนวโน้มจะเป็นแอปแบบ Local-First ที่ทำทุกอย่างภายในเบราว์เซอร์
- เทคโนโลยีสแต็กที่ใช้มีดังนี้
- Three.js: 3D viewport
- Svelte: การจัดการ state และ reactivity
- Threlte: ตัวเชื่อมระหว่าง Svelte กับ Three.js
- การส่งข้อความระหว่าง UI กับ b-rep kernel
- Electron: การรันแบบ local
- TypeScript, TailwindCSS, Vite และอื่น ๆ
- สแต็กนี้ทำให้สามารถเขียนทั้งแอปด้วยแนวทาง reactive และ declarative เพื่อเชื่อมจากการเปลี่ยนข้อมูลไปจนถึงการอัปเดต mesh
- แอป 3D CAD เป็นหนึ่งใน UI ที่ซับซ้อนที่สุด ดังนั้นหากทีมเล็กจะทำผลิตภัณฑ์ที่ดี เฟรมเวิร์กจำเป็นต้องช่วยรับภาระงานส่วนใหญ่
- เนื่องจากมีการสร้าง proof of concept ที่ทำงานได้ด้วยสแต็กนี้แล้ว จึงมองว่านี่ไม่ใช่ข้อจำกัดหลักของ CADmium
รูปแบบไฟล์ JSON และระบบนิเวศ CLI
- CADmium ตั้งใจจะใช้ JSON กับทุกสิ่ง
- สำหรับ Operation Log มีแผนจะใช้ JSON Lines
- เมื่อออกแบบชิ้นส่วนเสร็จแล้ว ก็มองว่าควรส่งออกไปยังฟอร์แมตแลกเปลี่ยนที่ง่ายกว่าได้
- ตัวอย่างฟอร์แมตคือโครงสร้าง JSON ที่มีอาร์เรย์
steps เก็บงานอย่าง sketch, extrude เป็นต้น
- มีตัวอย่างการใช้งาน CADmium CLI เพื่อแปลงไฟล์
.cadmium เป็น .step หรือ .stl
$ CADmium export my_part.cadmium --format stl
- องค์ประกอบ 2 อย่างที่จำเป็นต่อการสร้าง ecosystem คือ
- รูปแบบไฟล์ที่เรียบง่ายและเข้าใจง่าย
- CLI โอเพนซอร์สที่จัดการฟอร์แมตนั้นได้
- มีตัวอย่างการใช้งานที่แก้ค่าความลึกของการ extrude หรือรัศมี fillet ผ่าน text editor
- ยังอาจทำงานอย่างเปลี่ยนสกรู M5 ทั้งหมดเป็น M6 ด้วยสคริปต์ได้ โดยไม่ต้องอ่านสเปกซับซ้อนอย่าง ISO 10303-21
- หากวันหนึ่งมี GitHub สำหรับงานออกแบบเครื่องกลที่ถูกสร้างขึ้นและใช้งานจริง ก็อาจจินตนาการถึง GitHub Copilot สำหรับงานออกแบบเครื่องกลได้เช่นกัน
- มีมุมมองว่าโมเดลภาษาขนาดใหญ่ทำงานได้ดีที่สุดกับฟอร์แมตแบบข้อความที่เรียบง่ายและเปิดกว้าง มากกว่าฟอร์แมตไบนารี proprietary ที่ซับซ้อน
ความช่วยเหลือที่ต้องการและหัวข้อที่พักไว้ก่อน
- แม้ยังไม่รู้ว่าแนวคิดใดจะสำเร็จหรือจะล้มเหลว แต่ก็มองว่านี่เป็นพื้นที่ที่กลุ่มเล็ก ๆ อาจสร้างผลกระทบใหญ่ต่อภาคการผลิตได้
- ความช่วยเหลือที่ต้องการมีดังนี้
- การเขียน Rust และการปรับปรุงทั่วไป
- computational geometry สำหรับการทำ patch ให้ Truck
- การสนับสนุน Three.js
- camera controller ตัวใหม่
- แสงที่ดีกว่า
- post-processing
- การหาโอกาสด้านทุนสนับสนุนหรือผู้สนับสนุนที่มีทรัพยากร
- ส่วนที่ยังไม่ทำตอนนี้ แต่คิดว่าอยากกลับมาดูในอนาคต มีดังนี้
- venture capital
- toolpath generation หรือ CAM
- Finite Element Analysis หรือ FEA
- เซิร์ฟเวอร์ Discord ของ CADmium ยังมีอยู่ แต่ตามประกาศสถานะโครงการแล้วไม่ได้ active อีกต่อไป
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
คาดหวังอย่างมากกับสิ่งที่ Matt กำลังทำอยู่ โลกนี้ต้องการ CAD แบบพาราเมตริกโอเพนซอร์ส ที่มี UI/UX ใช้ง่ายเท่า SolidWorks อย่างยิ่ง
เหตุผลใหญ่ที่สุดที่จนถึงตอนนี้ยังทำได้ไม่ดี คือไม่มีเคอร์เนลพาราเมตริกที่ทรงพลังพอ และ Truck ที่ Matt ใช้อยู่ก็ดูเหมือนเป็นโปรเจกต์ที่ตรงกับสิ่งที่ต้องการพอดี ก่อนหน้านี้ OpenCascade แทบจะเป็นตัวเดียวที่ใกล้เคียง แต่ยังขาดฟีเจอร์สำคัญและมีบั๊กกับความไม่เสถียรสูง
ถ้า Truck กับ CADmium ทำให้ fillet เสถียรได้ ก็อาจกลายเป็นผู้สืบทอดที่เหมาะสมของ OpenCascade และเป็นแพลตฟอร์มที่จะสร้างอนาคตของ CAD แบบพาราเมตริกโอเพนซอร์สได้
ช่วงหลังย้ายไปใช้ Alibre Atom3D ซึ่งไม่ใช่โอเพนซอร์ส แต่จ่ายครั้งเดียว 200 ดอลลาร์ก็พอ ตราบใดที่โฮสต์ OS ไม่เปลี่ยนไปมาก ก็ยังเปิดงานออกแบบต่อไปได้ และทำงานอยู่บนเคอร์เนล ACIS
พอเห็นคำว่า "browser-first" และข้อความใน README ว่า "สร้างรายได้ด้วยเวอร์ชันโฮสติ้งแบบเสียเงิน" ก็อ่านแล้วรู้สึกว่าโปรเจกต์นี้อาจค่อย ๆ เลือนหายไป หรือเติบโตจนกลายเป็นผลิตภัณฑ์แบบ open-core ที่บังคับสมัครสมาชิก เพิ่ม dependency สำหรับการติดตั้งและฟีเจอร์ด้านความปลอดภัยมากขึ้น จนการรันแบบ local จริง ๆ ทำได้ยากขึ้นเรื่อย ๆ
ได้ลองใช้เวอร์ชัน weekly กับธีม OpenDark แล้วดูค่อนข้างประณีตทีเดียว ฝั่ง CAD โอเพนซอร์สดูเหมือนกำลังเข้าสู่ช่วงเวลาที่น่าสนใจจริง ๆ
ยิ่งได้ลองใช้แพลตฟอร์ม CAD หลาย ๆ ตัว ก็ยิ่งรู้สึกว่าแอปพลิเคชันเฉพาะทางที่ปรับให้เข้ากับขอบเขตปัญหาแคบ ๆ มีประโยชน์กว่ามากเมื่อเทียบกับ CAD อเนกประสงค์ การส่งออก SVG/DXF/DWG เป็นข้อดี แต่ซอฟต์แวร์เขียนแบบที่พยายามรองรับทั้งชิ้นส่วนเครื่องจักรสำหรับการผลิตจำนวนมาก งานก่อสร้างครั้งเดียว ทางหลวง ท่อส่งยาว 50 ไมล์ วงจรไฟฟ้า การวางแผนจราจรในเมือง ไปจนถึงงานศิลปะ ผมมองว่ามันเดินผิดทาง
แม้แต่ซอฟต์แวร์ออกแบบถนนมาตรฐานอุตสาหกรรมที่ใช้อยู่ ก็ยังไม่มีอ็อบเจ็กต์โมเดลที่ชื่อว่า "ถนน" องค์ประกอบแนวราบ แนวดิ่ง และหน้าตัดไม่ควรถูกแยกจากกันได้ และกฎการโต้ตอบกันก็ชัดเจน แต่กลับถูกนิยามแยกเป็นอิสระจากกัน นักออกแบบควรใช้เวลาน้อยลงกับการสั่งคอมพิวเตอร์ว่าจะแสดงผลอย่างไร และคิดถึงผลลัพธ์จริงให้มากขึ้น
สงสัยว่าทำไมเวลาพูดถึงเครื่องมือ CAD หรือโอเพนซอร์สใน HN ถึงแทบไม่มีใครพูดถึง QCAD
1 - https://www.qcad.org/
ในฐานะหนึ่งในผู้ดูแล Solvespace ขอเสริมบางอย่างว่า constraint แบบ 2D อย่างเดียวไม่พอ และ constraint แบบ 3D ดีกว่า ถ้าเขียนด้วย C++ ผมคงบอกให้เอา constraint solver ของ Solvespace ไปใช้เหมือนที่ Dune3D ทำ แต่ถ้าชอบ Rust ก็ลองดูงานที่ Michael F Bryan เขียนด้วย Rust และเขียนบล็อกไว้ได้
https://adventures.michaelfbryan.com/posts/constraints-part-...
ในส่วน geometry kernel มีบั๊ก 3 ประเภทในเคอร์เนลของ Solvespace ที่อยากแก้ และถ้าแก้ได้ ก็น่าจะจัดการ boolean operation ได้ค่อนข้างเสถียร แต่ไม่มีเวลา เคอร์เนลของเรามีไม่ถึง 6,000 บรรทัด จึงน่าจะมีอะไรให้เรียนรู้อีกมาก ถ้าอยากคุยเรื่องนี้ ติดต่อได้ที่ gmail ด้วย ID เดียวกัน ผมไม่ได้ดู Truck มาพักหนึ่งแล้ว และคิดว่ามันค่อนข้างหยุดนิ่ง นี่เป็นปัญหาที่ยากจริง ๆ แม้แต่ในโลกเชิงพาณิชย์ก็มีตัวเลือกน้อย แค่การทำ triangulation ให้กับ NURBS shell ที่ถูก trim ก็ยังยุ่งยากแล้ว
history/feature tree เกี่ยวข้องอย่างใกล้ชิดกับ ปัญหา topological naming ของ FreeCAD Solvespace จัดการโดยสร้างแต่ละ entity จากชุดของสิ่งที่รู้จักอยู่แล้ว ถ้าพยายามสร้างใหม่ มันจะไม่สร้าง entity ใหม่ แต่จะคืน handle ของ entity เดิมแทน กล่าวคือ entity ทุกตัว "มาจากอะไรบางอย่าง" และจำความสัมพันธ์นั้นไว้ ในส่วนที่เราจัดการ topological naming มันทำงานได้สมบูรณ์แบบ แต่ไม่ได้ครอบคลุมทุกส่วนของ Solvespace เรื่องนี้ต้องใส่เข้ามาตั้งแต่ต้น ไม่ใช่สิ่งที่จะมาต่อเติมทีหลังได้ง่าย ๆ
แล้วก็อยากได้ลิงก์ว่าจะลองใช้ CADmium ได้ที่ไหน
[1] https://github.com/thekakkun/rust_slvs
Github:
https://github.com/MattFerraro/CADmium
มีลิงก์อยู่ที่นี่:
https://mattferraro.github.io/CADmium/
ผมมองว่านี่เป็นงานที่น่าทึ่งจริง ๆ หวังว่า CAD เชิงกายภาพแบบโอเพนซอร์ส จะไปถึงระดับเดียวกับที่ EDA แบบโอเพนซอร์สไปถึงได้
มีความเชื่อกันว่าสเก็ตช์แต่ละอันควรเล็กและเรียบง่าย เพราะการแก้สมการเมทริกซ์แบบนี้จะช้ามากเมื่อจำนวนตัวแปรไม่ทราบค่าเพิ่มขึ้น แต่พอลองขุดดูค่อนข้างลึกแล้ว จริง ๆ มันไม่ใช่ปัญหาใหญ่
ปัญหาประสิทธิภาพด้าน constraint ของ FreeCAD ส่วนใหญ่มาจากอัลกอริทึมการจัดวาง GUI ที่ซ้ำซ้อนและไม่จำเป็น และพังได้แม้มี constraint แค่ไม่กี่ร้อยรายการ Sparse QR decomposition ของ Eigen อยู่ที่ประมาณ 18 วินาทีสำหรับ constraint 2200 รายการ ซึ่งก็ไม่แย่ มีไลบรารี sparse QR decomposition ที่จัดการ constraint 5 แสนถึง 1 ล้านรายการได้ในราว 18 วินาทีด้วย ยากจะจินตนาการสถานการณ์ที่สเก็ตช์ CAD จะมี constraint เกินหลายพันรายการ
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
ใช้อยู่กับ assembly constraint ของ FreeCAD และ Ondsel ES
ผมเคยเรียน CAD ด้วย Autodesk Inventor เมื่อนานมาแล้ว และซอฟต์แวร์โมเดลลิงฟรีตัวเดียวที่ลองเล่นไม่กี่ชั่วโมงแล้วเข้าใจได้คือ Onshape ดูเหมือนว่า usability จะเป็นปัญหาใหญ่มากในวงการนี้
ตัวอย่างเช่น FreeCAD ดูเหมือนจะมีวิธีทำสิ่งเดียวกันเป็นพันล้านวิธี แต่สุดท้ายวิธีจริง ๆ มีอยู่แค่วิธีเดียว และบาง tutorial ก็ทิ้งโมเดลที่ไม่ถูกต้องไว้
เป็นงานที่ยอดเยี่ยม และดูเป็นปัญหาที่ยาก
Repo: https://github.com/MattFerraro/CADmium
แทบจะใช้แค่ workbench Part Design, Sketcher, Spreadsheet เท่านั้น ทั้งสามตัวนี้โดยรวมทำงานร่วมกันได้ดี ความสามารถในการทำงานข้าม workbench แย่จนไม่กล้าขยายไปใช้อย่างอื่น บางครั้งก็ใช้ Part workbench ด้วย แต่ถ้าจะใช้ใน Part Design ต้องแปลงรูปแบบภายในสองรอบ ทำให้ยุ่งยากมาก
หวังว่าสักวันหนึ่ง โปรเจกต์ CAD โอเพนซอร์สสักตัวจากหลาย ๆ ตัวจะมาแทน FreeCAD ได้
แม้จะไม่ค่อย practical แต่โมเดลก็ยังทำงานบนมือถือได้ด้วย
Fusion360 ก็พอใช้ได้ แต่เมื่อเทียบกับแพ็กเกจเชิงพาณิชย์ที่ผมเคยใช้ ประสบการณ์ผู้ใช้ค่อนข้างแย่มาก
สิ่งที่อยากได้จาก CAD ฟรีคือให้ใครสักคนเอา ความแข็งแกร่งและความเร็วของ Creo มา แล้วผสานกับความเป็นมิตรของ SolidWorks ช่วงแรกฟีเจอร์จะค่อนข้างจำกัดก็ไม่เป็นไร
กระบวนการคือทำตาม tutorial ที่พาไปได้ถึง 80% แล้วพยายามต่อส่วนที่เหลือเข้าไปให้ได้ จากนั้นก็รู้ว่า tutorial พื้นฐานนั้นจัดโครงสร้างโปรเจกต์ไว้ในแบบที่ทำให้ทำอีก 20% ที่เหลือให้จบไม่ได้ พอพยายามแก้ขั้นตอนก่อนหน้า ทั้งโปรเจกต์ก็พัง แล้วก็วนซ้ำแบบนี้
ใน CAD โดยทั่วไป ลำดับการทำงาน สำคัญขนาดนั้นเลยหรือ? ผมนึกว่าเป็นวัตถุเรียบง่าย และ FreeCAD จะยากสักแค่ไหนกัน เลยกระโดดเข้าไปลอง แต่จริง ๆ แล้วมันยากมาก
การที่มีผู้เล่นหน้าใหม่เข้ามาในวงการนี้ และโดยเฉพาะการพยายามสร้างเคอร์เนลใหม่ เป็นเรื่องน่าสนใจ แต่ดูแล้วโอกาสสำเร็จน่าจะต่ำ เคอร์เนลระดับบนสุดของอุตสาหกรรมได้รับเงินสนับสนุนจากบริษัทรถยนต์และอวกาศ และเป็นสิ่งที่ ผู้จบปริญญาเอกด้าน CAGD กับโปรแกรมเมอร์ พัฒนากันมาหลายสิบปี แค่ไปให้ถึงชุดฟีเจอร์พื้นฐานที่แข่งขันได้ก็คงใช้เวลานานแล้ว
อีกอย่าง ยังสงสัยด้วยว่ากำลังจะแก้ปัญหาอะไรให้ผู้ใช้ CAD ผู้ใช้ CAD ไม่ได้จำเป็นต้องต้องการโอเพนซอร์สเสมอไป แน่นอนว่าย่อมมีข้อจำกัดด้านงบประมาณ แต่ในวงการนี้ โอเพนซอร์สอาจไม่ใช่ฟีเจอร์ที่ผู้ใช้มองเห็นได้โดยตรงเหมือนในเครื่องมือสำหรับนักพัฒนา Plasticity แสดงให้เห็นแล้วว่าแม้จะไลเซนส์ Parasolid ก็ยังทำเงินได้ในระดับราคาต่ำ
ใช้เครื่องมือ parametric CAD มานานกว่า 30 ปีแล้ว และ Onshape เป็นทางออกที่ค่อนข้างน่าทึ่งสำหรับหลายปัญหาที่มีใน Creo หรือ SolidWorks สภาพแวดล้อมเหมือน Google Docs สำหรับ CAD แบบทำงานร่วมกัน ที่ข้อมูลไม่หาย มี undo ได้ไม่จำกัดเพราะสร้างขึ้นบนฐานข้อมูลตั้งแต่แรก ไม่ใช่ระบบไฟล์ เปลี่ยนชีวิตได้เลยทีเดียว เพียงแต่ฟีเจอร์การทำโมเดลยังอยู่ระหว่างไล่ตามเครื่องมืออื่น ๆ
ข้อเสียใหญ่ของ Onshape, Creo และ SolidWorks คือโครงสร้างที่เริ่มจากสเก็ตช์ 2D แล้วค่อย extrude, revolve, loft ไปเป็นวัตถุ 3D เครื่องมือ 3D เป็นเหมือนฟีเจอร์เสริมของโครงสร้างพื้นฐาน และเกือบจะเป็นสิ่งที่คิดเพิ่มทีหลัง Plasticity, Rhino, Alias นั้น ให้ความสำคัญกับ 3D ก่อน มากกว่า
FeatureScript ของ Onshape นั้นเจ๋งและทรงพลังมาก แต่สำหรับผู้ใช้ CAD ที่จะสร้างเครื่องมือของตัวเอง ยังไม่ดีเท่า Grasshopper ของ Rhino
CADmium ควรโฟกัสว่าจะแก้ปัญหาผู้ใช้แบบไหน และในตลาดใดจึงจะเป็นเครื่องมือ CAD ที่ดีกว่าทางเลือกทั้งแบบเสียเงินและฟรี ต่อให้ยังอยู่ช่วงพัฒนาแรกเริ่ม ก็ไม่เร็วเกินไปที่จะทำความเข้าใจความต้องการของผู้ใช้ โอเพนซอร์สไม่ใช่เป้าหมายในตัวมันเอง
ถ้ามีเครื่องมือสมัยใหม่ บทเรียนจากเอนจินเก่า ๆ และไม่มีหนี้จากการเข้าสู่ตลาด ทีมเล็ก ๆ ก็สามารถสร้างสิ่งที่ทัดเทียมหรือดีกว่าซอฟต์แวร์อายุ 30 ปีได้
ผมคิดว่าทีมเล็กที่ทุ่มเทสามารถสร้าง parametric kernel และแพ็กเกจ CAD ใหม่ได้ โดยเฉพาะถ้าเป็นโอเพนซอร์สก็ยิ่งเป็นไปได้
ผู้ใช้ CAD จะได้ประโยชน์มากจาก ทางเลือกโอเพนซอร์ส ที่ดี
ในทางกลับกัน มีเหตุผลมากมายที่ควรหลีกเลี่ยงซอฟต์แวร์กรรมสิทธิ์ และถ้าเป็น SaaS ก็ยิ่งหนักกว่า เพราะทุกวันนี้กำลังไปทาง SaaS กันมากขึ้นเรื่อย ๆ และกรณีนี้ก็เช่นกัน ซอฟต์แวร์ CAD เป็นวงการที่ผู้ใช้จำนวนมากเคยเจ็บมาแล้ว หลังจากทุ่มเวลาเรียนและใช้งานไปหลายร้อยชั่วโมง แล้วระบบกรรมสิทธิ์กลับเปลี่ยนเงื่อนไขการให้บริการ
รู้ว่าคงเป็นคนส่วนน้อย แต่สำหรับผม โอเพนซอร์สเป็นเป้าหมายสูงสุดในตัวมันเอง ผมใช้แต่ซอฟต์แวร์โอเพนซอร์สมาตั้งแต่นานมากแล้ว
ถึงอย่างนั้นก็ยังไม่ค่อยเข้าใจส่วนที่ว่าโอเพนซอร์สเป็นเป้าหมายไม่ได้ มันคล้ายความสัมพันธ์ระหว่าง KiCAD กับ Altium ถ้าสามารถให้ 90% ของสิ่งที่ Onshape มีในรูปแบบโอเพนซอร์สได้ ผมคิดว่าผู้คนก็ใช้ได้
เข้าใจมุมมองเรื่องต้นทุน ไลเซนส์ SolidWorks อยู่ราว ๆ 3,000–5,000 ดอลลาร์ บริษัทส่วนใหญ่จึงน่าจะยอมจ่ายเงินใช้เครื่องมือที่ผ่านการพิสูจน์แล้ว
อนึ่ง Onshape ถูกสร้างขึ้นด้วยเงินน้อยกว่า 10 ล้านดอลลาร์จนมี MVP ภายใน 3 ปี ผมไม่คิดว่าการสร้างโปรแกรม CAD ใหม่ทุกวันนี้จำเป็นต้องใช้กำลังคนระดับปริญญาเอกสะสมเป็นสิบ ๆ ปีเสมอไป
สรุประบบนิเวศของเคอร์เนล CAD ได้ยอดเยี่ยม
โดยเฉพาะประโยคที่ว่า “เคอร์เนล B-rep แบบโอเพนซอร์สตัวเดียวที่ได้รับความนิยมคือ OpenCascade ซึ่งเป็น Pontiac Aztek แห่งวงการเคอร์เนล B-rep มันหน้าตาไม่สวย มีแค่ฟีเจอร์พื้นฐาน และอาจพังได้ แต่ก็วิ่งได้ และหาได้ฟรี” ชอบมาก
ถูกต้องจริง ๆ
ถ้าเป็นแบบ local-first ก็สงสัยว่าทำไมต้องทำในเบราว์เซอร์
Solvespace มีข้อดีตรงที่เป็นไฟล์ดาวน์โหลด/รันไฟล์เดียว
อีกอย่าง ตัวแก้ constraints ยังถูกใช้ในโปรเจกต์อย่าง CADsketcher และ Dune 3D ด้วย: https://github.com/dune3d/dune3d
ผู้เขียนบอกว่า wrapper code ไม่ได้ expose ฟังก์ชันทั้งหมดที่ต้องการ จึงใช้ตัวแก้ของ Solvespace โดยตรง และเพื่อให้เร็วพอกับชนิดของสมการที่สร้างขึ้น ต้อง patch ตัวแก้ให้แก้สมการเชิงสัญลักษณ์ในจุดที่ทำได้
สงสัยด้วยว่าเกี่ยวข้องกับ https://github.com/jay3sh/cadmium หรือไม่
ในฐานะ CAD kernel ก็ไม่ได้พูดถึง Manifold ด้วย: https://github.com/elalish/manifold/wiki/Manifold-Library เข้าใจว่ามีข้อเสียหลายอย่างแบบเดียวกับ OpenCASCADE แต่ก็ดูควรค่าแก่การพูดถึง
kernel นี้เคยถูกคุยกันที่นี่มาก่อนด้วย: https://news.ycombinator.com/item?id=35071317
ประวัติทั้งหมดและความสามารถในการแก้ไขดูน่าสนใจและมีอนาคตเป็นพิเศษ ถ้าสามารถแสดงประวัตินั้นใน panel ที่เปิดปิดได้ และเพิ่มสามเหลี่ยมสำหรับกาง/พับเพื่อซ่อนองค์ประกอบที่ทำเสร็จแล้ว เพื่อให้โฟกัสกับงานปัจจุบันได้ สำหรับผมคงเหมือนฝันเป็นจริงเลย แต่มีเงื่อนไขว่าต้องเข้าใจฝั่ง 3D ได้ด้วย ที่ผ่านมาลอง BRL-CAD, FreeCAD, Solvespace, Alibre Atom ฯลฯ แล้วล้มเหลวหมด สำเร็จเฉพาะเครื่องมือแบบ code-based ที่คล้าย OpenSCAD เท่านั้น
เมื่อคุณต้องออกแบบชิ้นส่วนที่บ้าน แก้ไขที่ที่ทำงาน แล้วไปสร้างด้วยอุปกรณ์ที่มีใน makerspace การไม่ต้องติดตั้งอะไรเลยถือเป็นข้อดีมาก
เคยพิจารณาเปลี่ยนโค้ดเมชสามเหลี่ยมของ Solvespace เป็น Manifold แต่ปริมาณงานเยอะ และสิ่งที่ต้องการจริง ๆ คือแก้บั๊ก NURBS เพื่อลดการพึ่งพาโค้ดเมช
อนึ่ง ตัวแก้ constraints ของ Solvespace ยังถูกใช้ใน workbench Assembly 3 ของ FreeCAD ด้วย ช่วงนี้เริ่มแพร่ไปหลายที่แล้ว
เห็นด้วยว่าแอป 3D CAD มี UI ที่ซับซ้อนที่สุดอย่างหนึ่ง
แต่ผมยังสงสัยกับคำกล่าวที่ว่า หากทีมเล็กจะทำ 3D CAD ที่ดี framework ต้องช่วยทำงานแทนให้มาก ๆ ไม่แน่ใจว่า UI framework ทั่วไปจะเป็นคำตอบระยะยาวของ 3D CAD ได้หรือไม่
UX ที่ดีบางครั้งต้องพิจารณาโมเดล 3D แบบพาราเมตริก, การประมาณด้วยเมช, การฉายเป็นเส้นและ patch หลังจาก hidden surface removal, พิกเซลใน frame buffer และ UI widget ไปพร้อมกัน framework มักตั้งสมมติฐานมากเกินไปว่าข้อมูลแบ่งแยกได้ง่ายและมีขนาดจำกัด
มันน่าจะช่วยในการทำ prototype ได้ แต่พอโปรเจกต์ใหญ่ขึ้น สุดท้ายในส่วนปฏิสัมพันธ์ของ viewport 3D หลักก็คงต้องทิ้ง framework แล้วใช้โค้ดของตัวเองเป็นส่วนใหญ่เชื่อมระหว่าง OpenGL หรือสิ่งที่คล้ายกันกับ event เมาส์/คีย์บอร์ด
framework สำหรับปุ่มหรือรายการก็คงโอเค แต่แม้แต่องค์ประกอบแบบนั้น ใน 3D CAD ก็ยัง dynamic กว่าแอปทั่วไปมาก
หวังจริง ๆ ว่า CADmium จะช่วยให้หลุดจาก OpenSCAD ได้ ใน OpenSCAD ตอนแรกไม่ต้องคิดอะไรมาก แค่ใช้ภาษาง่าย ๆ สร้างโมดูลซ้อนบนโมดูล
ปัญหาคือ OpenSCAD ไม่มี ตัวแก้ มีตัวแปร แต่ไม่มี constraints พอแก้ไปแก้มา จู่ ๆ ก็ต้องใช้สมองเยอะเพื่อแก้ constraints เอง และใส่ข้อผิดพลาดได้ง่าย
ถึงอย่างนั้นปัญหาก็ยังไม่หนักพอให้ย้ายไปเครื่องมืออื่น เพราะในขั้นเริ่มโมเดล ผมมองว่า OpenSCAD ง่ายกว่าเครื่องมือใด ๆ ที่เคยใช้มามาก
https://github.com/Ondsel-Development/OndselSolver
ถูกใช้ใน FreeCAD และ Ondsel ES
ตอนแรกผมเริ่มจาก OpenSCAD แต่พอสร้างวัตถุ 3D จริง ๆ FreeCAD ให้ productivity สูงกว่ามาก บางครั้งอยากเริ่มจากสี่เหลี่ยม ลบเส้นหนึ่งเส้น แล้วเพิ่มครึ่งวงกลม แต่ก่อนเริ่ม sketch เราอาจยังไม่รู้เรื่องนั้น
ใน OpenSCAD รู้สึกว่าต้องรู้ล่วงหน้าว่าต้องใช้ primitive รูปทรงแบบไหนและแก้ไขอย่างไรให้แม่นยำ และการที่มันแนะนำ primitive 3D มากกว่าจะใช้การ extrude/rotate กับ 2D ก็เป็นสิ่งที่โดยส่วนตัวรู้สึกขัดใจ
ดีใจที่เห็นคนอื่นลงทุนทั้งเวลาและความสามารถให้กับ CAD แบบโอเพนซอร์ส ที่ Ondsel เราเชื่อว่า CAD แบบโอเพนซอร์ส สำคัญมาก และยินดีที่ได้เห็นนวัตกรรมในด้านนี้