Code+CAD的選擇

何謂Code+CAD？這代表用程式碼進行CAD（Computer-Aided Design）設計。現今可用工具多，也更為成熟，像是OpenSCAD、JSCAD、CadQuery，或是CAD軟體中的外掛設計。

OpenSCAD與它的衍生

從2015年底的第一個OpenSCAD建模作品起，至今我玩了近六年的Code+CAD，最初（可參考先前專欄〈3D建模與程式設計〉）單純就是手拙、用不好CAD軟體，轉而想透過程式碼描述、記錄建模過程，後來選擇OpenSCAD並持續把玩了這些年。

雖然OpenSCAD一直是我的主力，但這些年來，對於Code與CAD的結合，選擇已不只OpenSCAD。

最初選擇OpenSCAD的理由之一，是它本身的語法不多，是一門領域特定語言，著重在構造實體幾何（Constructive solid geometry，CSG），也就是可以使用交集、減集等邏輯運算符，將不同物體組合成複雜的曲面或者物體，對於建模新手、卻是程式設計熟手的我來說，是個很容易上手的建模方法。

對於開發者而言，透過程式建模有很大的吸引力，特別是在嘗過OpenSCAD入門的甜頭之後，只不過在這之後，有不少人會想尋找OpenSCAD的替代品，因為若模型的複雜度達到一定程度，想透過OpenSCAD來設計的難度就會急劇上升，這是因為它採用了函數式設計的典範，對於許多開發者來說，想靈活應用會有其難度。

雖然急劇攀升的難度，對我來說是練功的好對象，也因此催生了我的dotSCAD程式庫，但這個難度，讓其他開發者試圖建立了OpenSCAD的衍生工具，目的之一通常是為了能使用命令式的典範，另一個理由是想要利用某個語言既有的技術生態系。

其中之一是SolidPython，它是個Python程式庫，呼叫API時採用的語意，特意對應了OpenSCAD的語法、函式及模組，目的是為了能轉譯出對應的OpenSCAD程式碼。也就是說，還是需要使用OpenSCAD來預覽與產生模型，優點是開發者可以使用任何Python語法或程式庫，運算出模型資料後，再用模型資料來呼叫SolidPython，缺點是，若大量呼叫了SolidPython，轉譯出來的OpenSCAD程式會極為複雜，也容易有效能上的問題。

另一個選擇是OpenJSCAD，後來改名為JSCAD，生態圈相對於SolidPython活躍許多，可用JavaScript來撰寫程式，環境是基於Node.js而成，使用者介面主要提供的是模型預覽，主要是透過瀏覽器，然而，近來也有開發中的桌面版本。JSCAD主要是提供一套API用來呼叫底層的幾何程式庫，而呼叫API時的語意，模仿OpenSCAD的語法、函式及模組。

還有個特別的選擇是BlocksCAD，它是模仿了OpenSCAD，但更多是受到Scratch的影響，可透過程式積木來撰寫程式，某些程度上是推廣「人人都能寫程式」下的產物，但這也是選擇，特別是針對沒有程式基礎，又想寫程式玩玩模型的人來說。

OpenSCAD的競爭者

為何SolidPython、JSCAD被我視為OpenSCAD的衍生物？是因為它們在API上特意模仿了OpenSCAD的語法、函式或模組，對於被OpenSCAD受限，然而熟悉Python或JavaScript的開發者來說，可以很快地轉換至SolidPython、JSCAD；如果是曾經從事過3D繪圖、遊戲引擎的開發者，應該也很能立即上手SolidPython、JSCAD。

由於OpenSCAD很成功，後來出現競爭者，它們不模仿OpenSCAD，而是建立了自己的一套典範與方法，其中常見的是AngelCAD。之所以如此，是因為作者經常去OpenSCAD官方論壇挖牆角，告訴提問者若用AngelCAD，要解決他的問題會有多簡單。

AngelCAD使用的語言是AngelScript，現在應有很多開發者沒聽過這個腳本語言。它與C++有較密切的關係，例如，只要註冊C/C++實現的函式，就能直接在AngelCAD中呼叫；因為AngelScript相對而言比較冷門，這也意謂著，想使用AngelCAD前，必須先學習AngelScript，進入的門檻相對就高了一些。

若熟悉Python，或許可以關注CadQuery。因為，它有自己的一套API呼叫底層的幾何程式庫，官方文件齊全，搭配的編輯器竟然少見地具有除錯器，突顯它更進一步考量開發者在CAD方面的需求。

或許有些開發者會想說，Code+CAD這種選擇，跟3D繪圖、遊戲引擎之類的程式設計有何不同？的確，部份在實作原理是重疊的，但最大不同在於，遊戲之類的3D作品，最後還是在虛擬世界中展現，元件之間彼此遮遮掩掩，最後的外形看來沒問題就夠了；然而，Code+CAD的作品，必須能夠透過3D列印之類的技術，來呈現在實體世界。例如，在螢幕上畫個點、線、面很簡單，因為不需要大小、寬度、厚度，然而，要能成為實體世界的模型，卻需要想辦法設計出合理的大小、寬度、厚度。

不過，因為有部份在實作原理上是重疊的，確實我們也可以透過3D繪圖、遊戲引擎之類的程式庫來從事建模，然後將頂點、面等幾何資訊匯出為模型檔，有些程式庫需要外掛來達到這個目的，有些則會內建，例如，若使用Three.js繪圖，就有STLExporter可以匯出STL。

CAD軟體附屬的程式建模

其實Code+CAD需求一直都存在CAD軟體，只不過通常作為輔助角色，而在這類CAD軟體，大部份建模工作由人工完成，對於重複、規律或需精確、複雜數學運算的建模，才透過巨集或程式碼實現。

例如，在FreeCAD中，我們可使用Python，也可結合OpenSCAD，有個專用的OpenSCAD Workbench面板，能匯入或者直接撰寫OpenSCAD程式碼，而Blender、Rhino可以使用Python進行程式建模，SketchUp可以結合Ruby等。

由於在CAD軟體中，程式開發只是輔助角色，因此想在這類CAD軟體中撰寫程式，往往得先熟悉CAD軟體本身的使用，才能知道撰寫程式時，各自API代表了CAD軟體中的哪個對象。因為需要程式碼輔助的CAD軟體，往往也是功能強大，這表示API往往也較為複雜，入門的門檻相對來說比較高。

而且，在CAD軟體中，程式碼方面的功能實現，多半是以外掛方式存在。一般CAD軟體的目標使用者通常不會撰寫程式，當CAD軟體本身功能無法滿足需求，他們會尋找是否有外掛程式可用，也就是說，若你是某個CAD軟體的重度使用者，熟知該軟體的需求（或不足），正好你會寫程式，就可以試著尋找相關文件，瞭解如何撰寫程式滿足需求。

無論是商業或是開放原始碼的CAD軟體，優秀、受歡迎的外掛可以形成一個市場，例如，商業CAD軟體通常也會提供官方的外掛市集，開放原始碼的Blender也有外掛市集，提供使用者搜尋付費或非付費的外掛，因此，雖然入門的門檻會比較高，然而，若你熟悉某個CAD軟體的需求，撰寫外掛是有可能收到實質的金錢回饋。

Code is the future of CAD

若你是純粹開發者，有興趣撰寫程式碼來玩玩3D建模，個人的建議是：除了我專精的OpenSCAD之外，若熟悉JavaScript，可試著使用JSCAD；如果偏好Python，可以玩玩CadQuery，它們都是直接從程式碼下手。如果你同時想玩玩CAD軟體，可以試試方才談到的CAD軟體，它們都能輔以程式設計。

關於這類應用發展態勢，我最近發現有個CadHub，試著整合OpenSCAD、JSCAD、CadQuery等，想建立Code+CAD社群，這表示愛好者越來越多，我特別喜歡CadHub公布的一句話「Code is the future of CAD」，在CadHub上，目前條列溝通、可Hack、版本控制、軟體產業的成長等理由，某些程度也正好符合我這些年來的觀察呢！