G.F wrote:
可能是因為三角形容易...(恕刪)
幾個原因:
1. 傳統pipeline填色走的是scanline方式, scanline的方式如果用方程式的畫會造成很多麻煩, 例如, 如果畫出來的東西是個凹多邊形, 那麼得用別的演算法來計算邊界點, 如果是星型怎麼半呢? 中間的那塊區域到底要不要畫? 這很難用硬體去做, 很難做到在短時間內搞定. 三角形就不一樣了, 一個triangle based gouraud shading填色單元可以直接用內插法取得邊界線的座標, 直接以line畫出, 1T就搞定.
2. 三角形能輕易的組合成任何形狀, 線條不行, 如果你想用線條組合成圓形, 你會需要一個公式, 如果你想畫不規則形狀, 那又得要一個公式, 也或許根本不可能存在這樣的公式, 這種方式在傳統TnL上根本沒辦法硬體加速, 且無法輕易的填色(得做BFS填色)
ps. TnL => Transformation and Lighting
3. 線條以及點能做到的, 三角形都做得到, 三個頂點中兩個頂點相同就是線, 三個頂點同就是點, 可以輕易的決定3D物件精細度, 只要你三角形的頂點距離越進, 總量越多, 模型就越細. 當然或許會有人說靠texture不就得了? 並不是, texture只能針對物件內容做美化, 但是事實上人眼對於物體的邊界輪廓線是很敏感的, 這靠texture解決不了, 得靠細緻的polygon才行, 而這時候只要三角形數量夠多, 每個三角形夠小, 輪廓線就會很漂亮.
4. 三角形可以清楚的定義法向量, 決定backface的polygon是哪些, 可以直接裁掉, 增加效率. 有個統計數字是, 遊戲場景中平均每個畫面會有40%的polygon是面向camera背面的, 想想看, 這樣效率會差多少呢? 法向量的另一個用途就是光影效果. 三角形可以輕易的定義正面反面, 內部外部, 所以只要給予每個三角形對應的法向量, GPU就可以算出光線打在這個polygon的時候, 根據ViewDirection跟LightVector的內積決定最後呈現的顏色. 但是點無法做到這點, 就不提了. 線雖然也可以定義法向量, 但是當你用線條包出一個範圍的時候, 中間內部的光影要從何算起呢? 線條包圍起來的範圍是要填內還外呢? 怎麼分析? 這計算複雜度太高了! 三角形的好處就在這了! 不管是OpenGL的右手系座標還是D3D的左手系座標, 有三個點就可以透過三個點的順序決定法向量朝哪!也可以輕鬆的內插出範圍內的點法向量該為何! 例如:
A
B C
這三個點, 順序是A->B->C, 那麼當設定為順的時候, 法向量就是AB cross BC, 設定為逆的時候, 法向量就是CB cross BA.
D3D跟OpenGL也都有API去設定現在是逆時鐘取法向量還是順時鐘取法向量, 如此一來model就不需要提供法向量也可以做back face culling了. 當model有提供法向量的時候最常見的應用就式利用法向量來改變視覺效果, 例如把一個原本看起來只有平面的東西變成看起來像是立體的, 這就是Bump Map的技巧(利用lighting).
5. shader問世之後, 雖然每個頂點都可以任意的用vertex program跟fragment program去configure路徑以及顏色, 但是還是脫離不了上述的第一點. 三角形式能簡單定義內、外區域的形狀 可以輕易的進行著色.
此外, GF大提到的"註1：每一個三角形需要三個頂點，但每「兩個」三角形只需要四個頂點，所以GPU的三角形組合速度是以每四個頂點形成兩個三角形來計算的"
其實得看情況, 應用程式得自己決定畫兩個三角形要用什麼方式, 如果說是個QUAD, 那麼兩個三角形下六個頂點或者兩個三角形下四個頂點都可以, 前者是TRIANGLE_LIST mode, 後者是TRIANGLE_STRIP mode或者TRIANGLE_FAN mode.
但如果兩個三角形只有一個共用點的時候, 就一定得下六個頂點下去囉! 所以說GPU三角形組合速度並非完全是以四個定點形成兩個三角形算的, 只是通常GPU spec上定義的效能往往就是基於這種模式, 因為這種模式下節點共用, 資料量小, 可讓polygon rate衝很高, 再搭配index mode streaming減少資料流頻寬, polygon rate又可以衝更高, 甚至會直接加上那統計出來的40%假設會被cull掉的polygon, 那數字又會更漂亮("有些"廠商就是這麼定義polygon rate的唷)!
事實上大家都正在研究方程式繪圖沒錯, 而向量繪圖似乎是被第一個開刀的, 例如Bezier曲線呀, SPLINE呀什麼的, 在Adobe Flash 8就已經有用到GPU加速了, 現有的GPS軟體也開始慢慢往這個方向走, 原本都是向量圖形, 都開始在找方法用硬體來加速了. FireFox新版也即將加入GPU加速的功能, 據聞Adobe在那之後將會釋放Flash源碼, 可能之後就是一場GPU廠的向量繪圖大戰囉!
有興趣的話可以參考一下幾個OpenSource的project, 例如AGG,GNASH,Glitz等等, 這些software都有提出如何對曲線封閉空間做scanline填色的演算法, 不過還沒有辦法有效切割成pipeline做分工, 而且動到的繪圖架構還不少, 這些都得好好研究囉! 不過到是有一家廠商已經把魔爪伸出來很久了, 把向量繪圖整個包成GPU加速的library, 並且已經在XBOX, NDS, PSP等機器上賣囉~ 兩大GPU廠事實上目前對向量曲線方程式加速的方法....嘿嘿, 搜尋一下google會發現他們目前用的招數喔! 在其他協力廠商發的新聞稿中就已經可以聞到煙硝味了:p
murafrank wrote:
GPU平行運算
仔細看一下遊戲圖，右上角的房子跟右下角的槍其實沒什麼關連，它們根本就是兩組多邊形的骨架，也有各自的貼圖，在遊戲中這兩樣東西也不會互動，如果能把槍和房子的運算分離開來，GPU內裝兩組運算單元，那不就可以同時運算畫面的不同部分，加快運算速度了？最後輸出畫面時再組合回去就好了。
...(恕刪)
這個說明不太對.
傳統polygon繪圖架構是一個個三角形依序處理. 跟3D物體位置無關, 也沒有分開畫再組合這種事.
所有運算單元都畫同一個三角形, 一個貼圖的三角形在畫面上可能由很多個pixel組成, 假設有12個pixel,
如果只有1組運算單元就要花12 cycle
如果只有2組運算單元就要花6 cycle
簡單的說有N組運算單元就能一次處理N個pixel
內文搜尋
從 APP 打開
X