python与建筑_有哪些关于 Python 在建筑中的应用和教程？

2018.02.09更新 (發現距離上一次更新馬上就要兩年了……）

嗯，兩年間發生了很多事。我也莫名其妙跑到ETH來了。

做起了Fab的優化，python已經完全不能滿足效率和複雜度的要求，走上了C++的不歸路。也真正走上了建造技術的道路。（當然，我的終極目標還是做藝術的。但願殊途同歸吧~）

Rhino也即將發佈 v6的正式版。GH聽說在進行代碼重構，但由於目前還在繈褓階段，所以跟隨Rhino v6發佈的還是增補版本。python流行程度上升，由於其簡潔的語法系統、強大的輔助包系統以及其膠水特性，漸漸成為各非計算機專業領域的主流平台。

這次更新主要介紹一個機構和一個平台。

這個其實最開始的答案裡面貼過鏈接，不過最近兩年有成為該領域世界中心的趨勢，所以再介紹一下。

瑞士政府出資，聯合瑞士各家大學2014年設立的機構，旨在加強數字化建造領域的產研結合。由於瑞士錢多，所以基本上網羅了全歐洲甚至全世界很大一批第一梯隊人才和領軍人物。

真正的多學科交叉，包括但不限於建築、結構、計算機、控制、機器人、材料等。

第一輪4年計劃已經完結，今年開始第二輪。

具體做的東西和內容我就不搬了，感興趣的可以去網站看。

由Block Research Group 開發的Python平台。旨在以Rhino為中心對接各種軟硬件工具包和代碼庫，包括但不限於 FEM，Robotics等系統。開源模塊化，可直接從github下載。

這個平台也是目前NCCR各個實驗室在慢慢遷移的平台，不同Chair負責不同模塊，期望在未來達到多軟件之間的協同工作。

也許下次更新又是兩年後喲。（唉， 人生能有幾個兩年後……）

2016.02.18更新

最近在做一些computation和optimization的內容，發現grasshopper裡面的python奇慢無比，借google調查了一下，有些結論。

首先說Rhino，根據論壇上McNeel公司的人的說法：Rhino is not a "multi-threaded" application. It does split off a few minor processes to other cores but nothing major. That's because modeling is a serial process. Modeling has to be done 'in order'.

所以RhinoSDK基本上不提供multi-thread的用法。

GH基於Rhino，按論壇上的說法也是基本上不支持multi-thread的。

但是用沒有用呢，我是沒看過比較好的實例。

個人感覺原因是：

普通的geometric operation靠現在的CPU計算能力基本上是可以滿足的，最多等5min。所以剛需並不高。

確實需要並行計算的是更大型的計算量，比如optimization。GH自帶的galapagos, 還是第三方比如octopus或者goat這種優化解算器。而這些又都是打包好的模塊，無法在python裡面用上面文章裡面的並行計算模塊調用…… （所以python裡面的並行真的很雞肋啊）

單純的optimization又不需要依賴于Rhino平台，直接在Rhino外面操作即可。

那是不是設計geometry的optimization就沒辦法做了呢？

其實不是的，雖然目前沒有見到特別好的解決方案，之前做research的一個組用的方法是：

在Rhino外面操作，然後把geometry通過obj導入回來，或者實時傳遞點坐標在Rhino裡面重建Mesh。

最後，我同時在嘗試遷移至Dynamo平台。

原答案： 一堆感謝不點讚，你們這些壞人！ ———————————————

正式答題。這應該是我在知乎上第一個涉及專業相關的問題，慢慢答。

（其實昨日看成在建築方面的“應用”……一激動遂Mark之。剛才仔細一看是問“教程”……那麼敝人就兼顧著都說一點，簡單介紹一下這方面內容在建築中的前沿領域都在做什麼。）

首先，Python的語言教程其實很多，像 @马逸东西 说的Codecademy。

另外還有Udacity和Coursera上面的。現在MOOC類課程很多，隨便找一下就有。側重點有些是語言本身的性質，有些偏應用。（Udacity作為工業界類MOOC，實用性非常強。）

其他的基本教程直接從@马逸东西 的答案里找即可。

既然是建築相關，一般離不開Rhino。

下面來說一下Python和Rhino的關係。

Python其實有很多版本，Rhino因為是win平台起家而且用了很多.NET的內容，在python的選擇上自然也是依託.NET的IronPython。

所以，大家說的Rhino中的Python，其實就是IronPython。

這個在安裝Rhino的時候會安裝一個，也可以自己下載最新版本然後替換。

Rhino裡面的Python用法有二：其一為不藉助grasshopper的pythonscript，有簡單的IDE可以debug和step；其二為Grasshopper裡面的python component，只有一個寫script的小窗口，只能test，不能debug。（至於怎麼用external editor寫code，這又是另外一個故事了，暫且按下不表。）

Ghsshopper裡面的寫script的原生component有兩個，C#和VB，是David Rutten直接寫的，與GH和Rhino整合非常好。Python這貨，其實是個領養的娃娃。由於不會賣萌，初期很不受待見。後來修修補補才差不多，但還是有點不堪大用。

rhinoscriptsyntax和Rhino是兩套東西，一個用GUID，一個用實體的Geometry。這兩個娃什麼區別呢？GUID呢，全稱其實是globally unique identifier，可以理解為一個geometry的名字。就像你叫小明，你哥哥叫小萌，比你多個草字頭，代表不是一個人。但你們的媽媽可以一邊喊“小萌快回來吃飯啦”，一邊跑去揪著你的耳朵把你拎回家來。兩種操作，結果都是你們回來吃飯了。（誰讓媽媽喊你回來你不聽話，活該！）

用名字當然很簡單，省時省力，但有些人沒有名字，只能動手……於是就會出現兩種混用的情況。會很亂，也非常容易出錯。

另外就是如果和GH的component混用，GH自帶的數據結構處理起來也比較麻煩。一般的做法是全都flat過再接入。出來的也是list的數據類型。這樣對很多初學者來說，會一定程度上限制class的用法。我見過的即使是ETH內部人寫的script，也都是function為主，很少用class。

但是最麻煩的問題還不是這個。

由於GH其實是個圖形編程平台，其實大部分的建模都可以用GH的component本身解決。即使像“循環”這類問題，也有HoopSnake和Anemone可以一定程度上解決，只要你邏輯能理清。

所以最需要coding的問題是component解決不了而有沒有人開發相關插件的問題。這個在research裡面很常見。比如上學期上一門optimisation的課，裡面要實現一個Michell Truss 的參數化控制，於是就有了這個東西：

（另外半邊是Kramaba的優化，中間粉色的是Goat的optimiser，不重要。）

結果就是一個可以改變參數批量化產生各種Michell Truss的東西：

這還只是比較簡單的用法，整個script從構思到實現大概用時半天多。但真正複雜的項目一個是規模大，一個是用到的數學多。而作為一個好用的程序語言，最重要的一方面就是有足夠多的外接library提供各種函數可以用。

可python最重要的一個數學函數庫NumPy在IronPython里不能調用……不能調用……不能調用……（現在可以在x86的Rhino裡面用了，所以裝了x64版本Rhino的孩子們，再去裝一個吧 。O(∩_∩)O）於是當初就是各種問題，各種不好用。

C#就沒有這個問題，本身支持也好。GSD那邊MDes項目的Technology項目主要就是用C#，估計也跟其教授當初開始涉足這方面時候Python太挫有關……

############### 我是分割線 #############

但是，python由於其語言本身簡潔有力，很多好的特性，其發展是很有前景的。而且ETH的Gramazio Kohler Research （就是那個各種機械臂的dfab，現在併入國家出錢支持的NCCR。）以及Block Research Group里，用python的也不少。（我是不會告訴你們最出名的那個搭建磚墻的項目的原始code就是python寫的，見下。）

因為代碼量真的小很多……而且支持越來越完善。故大家現在依然在用。

但是……（對，“但是君”又來了……）他們大多數都是在用純的pythonscript，更有甚者因為是做結構優化和計算，只要輸出點陣文件即可，所以連rhino環境都不用。

比如這個算用Force Density算網格的（用Mathematica也可以實現，但Rhino裡面的python真的是不可以呢。）：

The force density method « BLOCK blog

瑞士這是在國家出錢做建造，美帝都望塵莫及，我們目前是真心是追不上啊……

這些是我目前了解的建築方面最前沿的應用。但是教程呢，是真心沒有的。出教程的都是已經成熟的內容，前沿research大家都在摸索，要教程難道要上帝視角么……

其他周邊方向，比如結構分析和計算，就和建築離得比較遠了。

至於其他領域應用，比如CAM之流，故事就很多了……@马逸东西同學談的比較廣，有些細節和客觀事實有待推敲，但大體方向上問題不大。

P.S.

最後多說兩句。建築引入這套參數化思想和系統已經有10年有餘。開始都在專注與形式的複雜性，結果造出了很多結構奇葩的建築。現在已經進入一個可以把結構納入設計交互流程里來的時代，各種實時結構分析和優化軟件也如雨後春筍般出現。（其實也是因為computation ability提高的緣故。）

未來的發展肯定是具有物理特性的計算機模型。電腦里的建築也不再會是一個形式而已。個人覺得未來的建築師會越來越需要了解一定的結構知識。不一定會算，但要懂。

懂，你懂麼？（^_^）