有句老話說:「程式是照你寫的跑,不是照你想的跑」,然而有時候程式照開發者想的跑時,它不見得是正確的,程式不照寫的跑時,也不見得是錯誤的,如果沒有認清楚問題的本質,那執行結果的對或錯,都只是開發者腦中的幻想罷了。

為了實現路徑擠出

3D建模時,經常有個需求:給定一個2D圖案,依照指定的隨意路徑產生3D模型。例如,給定2D圖案與路徑,建立一條水管狀模型,在3D建模領域中,這功能稱為路徑擠出(path extrude),比較專業點的建模軟體中,應該都會提供這類功能,不過,有時擠出結果不是建模師想要的,甚至以為是個程式臭蟲,這是因為許多人對路徑擠出存在著幻想,我一開始也是如此!

OpenSCAD本身沒有隨意路徑擠出的模組,因而當初在為其建立程式庫時,隨意路徑擠出自然就成為實現目標之一,可惜的是,網路上幾乎沒有文件,討論如何用程式碼來實現路徑擠出,既然如此,那就從簡單的需求開始吧!

OpenSCAD本身有個線性擠出(linear_extrude)模組,名為線性,基本上就是將2D圖案沿著直線擠出,這只要有兩個2D圖案分別作為底面與頂面,就可以自行實現。

這麼說來,更複雜的擠出,可視為多個2D圖案形成的多個面,依需求調整面的法向量,並移動至指定座標點上,接下來,只要有個模組能掃掠(Sweep)這些面,就可以建立3D模型,這過程就像是為燈籠骨架貼上外皮。

也就是說,擠出的本質就是將2D變3D,既然如此,就必須提供額外資訊,有這些額外資訊才能構成3D模型。對線性擠出來說,必須多一個頂面,對於複雜的擠出,就依需求看要額外提供哪些面,3D建模領域中,2D圖案形成的面稱為斷面或切面,而隨意路徑擠出的問題就在於:這些斷面的來源會是什麼?

「為了不令問題一開始過於複雜,得先簡化問題。」假設斷面來源是使用者提供,畢竟有些以滑鼠操作為主的3D建模軟體,確實也是對使用者手動提供的斷面進行掃掠,這類功能有時也稱為放樣成形(loft),在OpenSCAD要實現這個功能並不難,只要將每個斷面上的座標點,視為最後3D模型的頂點,依序連接就可以了(參考https://bit.ly/31nY75d)。

自動產生斷面

手動提供斷面資訊,在以滑鼠操作為主的建模軟體中還算可行,然而在OpenSCAD中,使用者須明確提供斷面上的座標點,但這太過麻煩了,現在問題就清楚地座落到:怎麼從路徑自動產生斷面?「雖然是個子問題,然而還是可以再拆解出更小的子問題」,一是路徑是在斷面上哪個位置?二是路徑與斷面怎麼相交?

在3D建模軟體中,若提供路徑擠出,兩個問題或許都會提供可設定的選項。

在OpenSCAD中實現時,對於選項一,我假設2D圖案的原點就是路徑經過的點,依此實現了cross_sections函式(https://bit.ly/2I7gWlC),可由使用者提供斷面旋轉角度,自行決定路徑與斷面怎麼相交,這解決了選項二的問題,而該函式最後傳回自動產生的多個斷面。

提供斷面旋轉角度,總是比提供斷面座標來得簡單多了,而且在使用者的路徑是來自於某個數學公式時,公式本身若有角度相關的參數,就可以提供函式使用,自然地,在這個函式作為基礎下,像是圓路徑、阿基米德螺旋,或是球體路徑等可用數學公式描述的路徑,在先前假設的前提下,就可以精確地建立路徑擠出的結果。

當然,2D圖案原點是路徑經過斷面的點,不過就是選項之一,路徑可能經過斷面上的頂點或邊,基於不同的選項,可以撰寫不同的函式,我確實也實現了幾個常用的函式,像是paths2sections(https://bit.ly/2ZcXYj0),就可以用多條經過斷面頂點的路徑,來決定斷面如何產生。

只有點座標的時候

該是來處理使用者只提供路徑時的問題了,因為使用者只提供構成路徑的座標點資訊,於是,我假設2D圖案的原點是路徑經過斷面的點,斷面始終於與路徑正交,從而將問題簡化為:如何自動產生與路徑正交的斷面?

既然是正交,我想到路徑上的兩個點形成的向量,可以作為斷面法向量,而有向量就有了旋轉斷面的依據,於是也就有了路徑擠出的第一個版本。

第一個版本在大部份的情境之下,都可以運作,然而,在半年後被提出了ISSUE(https://bit.ly/2IPGe98),在擠出的過程當中,若路徑沿著Z軸,會發生模型斷面扭轉180度的結果,這一度被認為是個臭蟲,Blender也曾有過這個問題(https://bit.ly/2KHBcMq),發生的原因在於,只採用歐拉角繞XYZ軸來旋轉斷面,未提供斷面本身繞法向量旋轉的資訊,因此,路徑擠出的第二個版本,解決方式自然就是能繞法方量來旋轉斷面,這解決了模型斷面扭轉的問題。

然而,過沒多久時間之後,又有人提出了另一個ISSUE(https://bit.ly/2F0VkVO),因為在盤旋(helix)路徑時,第一個版本與第二個版本的路徑擠出結果不同,他認為,第一個版本才是他「想要的正確結果」,這突然讓我想到,其實,兩個版本的實現都是正確的,畢竟「問題的本質」在於,使用者只提供了路徑上的座標點!

提供足夠的資訊是必要的,如果有斷面就要提供足夠斷面,若有公式就提供必要的參數,這樣才能正確地進行路徑擠出,然而若真的只有提供路徑上的座標點呢?那麼,就只能從這些點中猜測,使用者想要的是什麼樣的路徑擠出,猜測的方式可以是使用歐拉角針對XYZ軸來旋轉,或者是令斷面的轉動是針對特定軸旋轉。

在採用歐拉角而最後的模型產生扭轉時,第一個版本是錯的嗎?其實,它的行為是對的,只不過不是使用者腦袋中想要的,使用者覺得它是錯的,是因為腦中存在著未提供給路徑擠出模組的資訊;相對地,第二個版本在針對特定軸旋轉而盤旋結果非預期時,也是使用者沒將腦中的資訊提供給模組,然後就以為模型結果錯了,然而那是模組的正確行為;最終,我在模組上提供了個參數,請使用者自行指定該怎麼「猜」,也就是要明確指定歐拉角或是特定軸旋轉。

簡化、分解、理解問題的本質

只要提供路徑,就能從2D圖案產生3D模型,因此,隨意路徑擠出的這個功能容易令人產生幻想,甚至令我忽略了一開始是怎麼簡化、分解問題,提供子問題必要資訊,來逐一解決各個子問題的過程,也忘了隨意路徑擠出的問題本質,正是沒有提供足夠資訊!

也許大部份開發者不會接觸3D程式,也從不會實現路徑擠出這類功能,然而,現實的軟體開發中,有不少特性或功能,其實就像路徑擠出這樣,容易令人存在幻想吧!

「程式是照你寫的跑,不是照你想的跑」的前提是,清楚地理解問題的本質,否則,想的是對是錯,從一開始就無法定義,那又何以判斷寫出來的執行結果是否正確呢?

作者簡介


Advertisement

更多 iThome相關內容