Rhino/Grasshopper的DataTree
◤概要
DataTree是Grasshopper中在處理資料結構的一種特殊的形式。本篇會介紹DataTree在GH環境與開發環境的使用方式。希望讓讀者有脈絡的知道這個主題。
在Grasshopper SDK中它是一個特別的Class。換言之，這個資料格式若非經過特別的動作，無法在其他平台上直接使用。
不過我們也不用太緊張，因為它的功能就是用來儲存與傳遞資料而已，並且視情形將資料分配成我們需要的狀態。所以這並不是甚麼新的概念，如果將視線轉往其他的程式語言，他們也都有屬於自己儲存資料的方式。例如現在很熱門的Python有Array, dictionary等，C#有List與Array等。
熟悉DataTree可以讓我們用更少的力氣在Grasshopper中做到一樣的事情。初學者在用Grasshopper時經常會為了將一件事情重複做，而直接將某一段script(一群component)直接複製一群。這個行為雖方便卻也讓整個script缺乏彈性，比如說: 「萬一我需要將同樣的事情再做另一次，那是不是需要再複製另外一包了呢?」、或「萬一我的資料量減少了，那剛剛做的事情是不是就等於白費了呢?」這些行為都會增加電腦運算跟使用者的負擔。若將眼光放遠，熟悉DataTree也就是一種培養對「資料結構」的敏感度的方式，勤於檢視與整理資料，藉此提高使用Grasshopper的效率。
.png) |
| picture credit : MODELAB 1.5.2 What is a Dataree? https://modelab.gitbooks.io/grasshopper-primer/content/1-foundations/1-5/2_what-is-a-data-tree.html |
◤ 那既然在Grasshopper誕生前，就已經有其他資料儲存方式，為何當時還要發展DataTree呢?
先講結論，DataTree的出現，來自於希望針對設計社群提供友善的資料儲存方式。換句話說，與許多設計和工程的交集一樣，這是為了降低在參數化環境多變的資料型態中存取資料的難度，所發展出來的一種獨特形式。
不論經常使用或是剛剛開始學習的人，一定都會注意到，Grasshopper的電池(component)實際上在就是在變化資料的「*維度與數量」。例如: 「我輸入一大堆的Polyline，經由 loft 的電池，之後得到一個 Surface」，在這個情形中，Polyline 的資料數量必大於 Surface，另外這時資料的內容也發生質變，由 Polyline 轉為 Point3d (詳見RhinoCommon)。這樣的轉換在Grasshopper中可以概略歸納(存在少數例外)為:
1:1 (一對一)
1:N (一對N)
N:1 (N對一)
N:N (N對N)
1:1 (一對一) => 輸入與輸出的資料維度「可能」改變，資料數量「不變」。例如:「Substraction (減法)」，不論輸入的資料有多少筆，任何一個時刻Substraction做的事都是拿 A 與 B 輸入相減得到 A-B，任何一個時刻都只會處理三筆資料的存取。
1:N (一對N) => 輸入資料的維度「可能」改變，資料數量「放大」。例如:「Range (在給定數值Domain內做等差分割)」或「Divide Curve (等分曲線)」，它們都輸入單一資料、例如domain或integer，然後輸出一個list的資料、如float或是Point3d，任何一個時刻它們做的事情都放大了資料的數量並且可能改變維度。
N:1 (N對一) => 輸入資料的維度「可能」改變，資料數量「減少」。例如:「Loft(連續斷面構成曲面)」或「Polyline (連續點構成曲線)」，任何一個時刻，它們都輸入一個list資料、例如Curve或Point3d，然後輸出單一筆幾何資料、如Surface或是Polyline，任何一個時刻它們做的事情都減少資料的數量並且可能改變維度。
N:N (N對N) => 輸入資料的維度「可能」改變，資料數量「可能」改變。通常這一類的component用於資料的整理(data management)。例如:「Shift(將給定的資料做index的位移)」、「Reverse(反向排序資料)」或「Spilt(在指定的index將資料分成兩筆)」，任何一個時刻，它們都輸入一筆list的資料，然後也輸出一個list的資料，它們做的事情可能會改變資料的數量。
Grasshopper在使用過程中最資料的頻繁轉換，讓當初的設計者歸納出以上幾種使用情境，並且設計了DataTree，讓它可以同時處理「individual values」、「lists of values」、與「lists of lists of value」的儲存。並且到今天依然在絕大多數的情形適用。
◤ DataTree作為過程的具體形式: 透過資料儲存紀錄設計過程
使用Grasshopper的經驗中，一定有component的數量一多，一接上 panel 後就路徑爆長的情況。(沒有的話那你等等可以試試看)。這是因為DataTree的設計上考慮資料儲存的「延續性(consistency)」大於「經濟性(economics)」，所以每經過一個compoenent，不論資料的維度貨數量是否改變，DataTree都會自動往上加入一個階層。
這個設計持續保有資料之間的關係(順序和位階)。參數式設計或衍生式設計的概念之一即為透過組織不同的設計演算法，運用不同的參數設定，達到對設計問題的收斂。某種程度來說，設計行為就是概念與思想的累積。所以我們可以試想，如果資料之間的關係無法保留，那變意味設計者無法延續在迭代修改演算法(白話: 接電池) 的過程中的概念傳遞，那將會非常可怕。
◤ DataTree的表示方式
{0:1:2:3}[9] // {路徑}[項目]
 |
| picture credit : 達爾文所繪，加拉巴哥群島的雀科鳴鳥 https://en.wikipedia.org/wiki/Taxonomy_(biology)#/media/File:Darwin's_finches_by_Gould.jpg |
#/media/File:Darwin's_finches_by_Gould.jpg){kind=link}
DataTree與生物分類學的「界、門、綱、目、科、屬、種」非常類似。當兩個不同種的生物所受的分類命名相同項目越接近底層的「種」，那代表它們在物種上的關係越接近。運用DataTree來舉例:
A生物=> {Animalia;Mammalia;Hominidea;Homo}
B生物=> {Animalia;Mammalia;Hominidea;Pan}
C生物=> {Animalia;Mammalia; Cervidea;Rangifer}
A與B 比 A與C 更親近，因為A與B共享更多的分類(路徑)屬性。
雖然DataTree比Grasshopper的其他部分來的相對困難，也很容易混淆。但直到目前為止，它依然在絕大多數的設計情境都運作得不錯，在可見的未來裡Grasshopper依然會使用這個方式來存取資料。所以我們若將眼光放遠，熟悉DataTree也就是一種培養對「資料結構」的敏感度的方式，勤於檢視與整理資料，藉此提高使用Grasshopper的效率，甚至也有助於加快未來在其他語言環境的上手速度。(完)
【引用請註明出處】
留言
張貼留言
please leave a message