理論計算機圖形渲染技術是否已經到了沒有什麼可以研究的地步了?

Offline渲染的各種技術理論已經完備,實時渲染技術除了實時GI之外已經沒有研究價值?


謝邀。我表達一下我的看法。

分水嶺從Rendering equation開始。

rendering equation出來之前,渲染都是在瞎搞。因為無目標,無建模。

Jim Kajiya在1986年搞了一個rendering equation,告訴你rendering是什麼東西,目標是什麼,是什麼形式,以後大家都這麼就行了。(有一次在電梯遇到這位老前輩,光芒太耀眼,都不敢跟他打招呼。)

L_o(mathbf{x}, omega_o, lambda, t)=L_e(mathbf{x}, omega_o, lambda, t)+int_{Omega}f_r(mathbf{x}, omega_i, omega_o, lambda, t)L_i(mathbf{x}, omega_i, lambda, t)(omega_i cdot mathbf{n})domega_i

其中fr是BRDF,Le是emit,Li是輸入光,Lo是輸出光,omega_i是入射角,omega_o是出射角,n是normal,lambda是波長,t是時間,x是所在點。

rendering equation出來之後,渲染的框架已定,就剩下一個問題,如何解得更快。除了升級硬體之外,要解得更快,要麼用近似,要麼另闢蹊徑。

在實時計算中,幾乎都省略的時間這個參數,並且不考慮全頻譜。所以最多就是RGB三個通道計算顏色。第二,那個積分沒法搞,所以變成幾個簡單光源的疊加,或者預積分的cubemap採樣。第三,emit就只是簡單的加上去,所以後面的討論都會略去這個。

一下舉兩個實際例子,讓讀者可以更容易感受到什麼叫解rendering equation。

Light map大家都熟悉。它其實就是在offline把每個點的顏色都算好,運行時直接當紋理貼上就可以了。相當於把rendering equation用查找表的方式來解。由於場景不能變,傳統light map之路已經死了。

Precomputed Radiance Transfer是個典型的近似方法。第一步,它把BRDF幹掉,變成純diffuse,再把積分變成根據visibility的疊加。也就是:

L_o(mathbf{x}, omega_o)=frac{
ho}{pi}int_{Omega}L_i(mathbf{x}, omega_i)V(mathbf{x}, omega_i)(omega_i cdot mathbf{n})domega_i

第二步,把L_i和V(omega dot n)都表達成SH,就成了

L_o(mathbf{x}, omega_o)=frac{
ho}{pi} sum SH(L_i(mathbf{x}, omega_i)) SH(V(mathbf{x}, omega_i)(omega_i cdot mathbf{n}))

Li項只和環境光有關,V項只和mesh有關。所以兩個分別預計算,在運行時sum一下就行了。

這樣一處理,就能在realtime對靜態場景用上低頻的環境光和點光源。還能支持diffuse,擴展到低頻的glossy,shadow和一些GI也能。這已經是以前所不可想像的了。所以PRT成為渲染髮展過程中的一個里程碑。Peter-Pike Sloan也因此一戰成名。

後來PRT被推廣到了per-pixel級別、擴展出了可以處理中高頻光源、支持更多GI效果、甚至物體可動。。。但由於這樣的近似表達能力有限,這條路基本被做死了。

Global Illumination with Radiance Regression Functions 就是個另闢蹊徑的方式。既然rendering equation計算量那麼大,直接解沒希望,那麼就當做個隱函數吧。

L_o(mathbf{x}, omega_o)=f(mathbf{x}, omega_o)

可是怎麼解呢?RRF的方式是通過這幾年非常熱的機器學習。通過在offline時候提供無數高質量渲染的結果來訓練,讓神經網路可以在運行時快速估值。這可以做到高速度(上百FPS)和高質量(接近offline渲染質量)的最佳組合。但這方面還有很多需要改進的地方,目前還沒徹底展開。

縱觀這幾年的siggraph,已經很久沒有offline rendering的新方法了,因為舊的方法已經涵蓋了各個方面,有沒有時間壓力。realtime rendering新方法也越來越少,發展遇到了一個嚴重瓶頸。究其原因,是能解決的問題早已被解決,未解決的問題誰都搞不定。其實真正未解決的只有一個聖杯級別的問題,那就是實時全效果GI,也就是如何更好更快地解rendering equation。要在這方面有突破,需要很多時間精力金錢。風險太大,誰都不想碰也不敢碰。所以我說目前沒有什麼可以研究的。甚至更悲觀的是,這個問題有可能永遠無法在現有體系內解決。

但願在未來的幾年,有人又突然發現了一條新路,又有人可以衝上去研究個幾年。


我嘗試抱著積極的態度談一下對這個問題的看法。首先這個問題挺大,不好一概而論的說這個問題是不是已經做到頭了。我覺得可以大概分成光傳輸模擬(Theory of Light Transport Simulation)的理論,離線渲染和實時渲染的演算法和應用來談談。

首先,對於光線傳輸的模擬的基礎理論,的確可以認為差不多是做到頭了。Eric Veach一篇97年的PhD thesis (https://graphics.stanford.edu/papers/veach_thesis/thesis.pdf) 談到的理論至今還是許多最新論文的基石。例如光線路徑的公式(Light Path Formulation),多重重要性採樣(Multiple Importance Sampling)還有Markov Chain的應用等。其他渲染所涉及到的基礎理論例如光在介質中傳播(Participating Media),Photon mapping那些基於Density Estimation那套東西的理論,各種材質的建模(Appearance Modeling),還有最基本的數學工具Sampling Reconstruction都被搞得很成熟了。現在的渲染早已不是拼基礎理論的方向,我認為也很難再出一些能顛覆我們認知的基礎理論再被發明或者發現。這些方向的成果也大多都是站在物理學、數學、統計學等的肩膀上完成的。但我認為渲染就是一個不能止步於基礎理論的方向。儘管各種理論都已經成熟,但是rendering equation積分的維度太高,中間brdf項還有蛋碎的delta或者near delta distribution,所以效率和健壯性都是很大的挑戰,有挑戰和不足自然就還有工作可以做。

我用自己的渲染器隨便舉個例子,那個大玻璃窗上一堆噪點就是因為玻璃的反射分布是一個奇點(delta distribution)。因為從窗外射入窗內的房間,再由窗戶反射出來到眼睛的光經過了兩次這種delta distribution的洗禮,沒有辦法被很好的採樣,就噪點了。。這是常說的Specular-Diffuse-Specular路徑,類似比較難搞的場景還有不少。。(例如點光源的焦散,visibility很差的光源等)

然後對於離線渲染來說,research的確相對於其他方向例如vision,animation來說不太好做。但我倒是覺得最近幾年有些paper還是很不錯和比較能開我的腦洞的。就不提熱門的VCM了。我還很喜歡這一篇2013年的Path Space Regularzation,作者天才的把Photon mapping裡面那種merge臨近光子的思想用到了採樣光線路徑方向上。這樣做的好處是第一實現起來簡單,不像PM、VCM有額外的內存開銷,而且可以證明的是引入的Bias也更小(這是個有偏一致的演算法)。因為是Analytical的所以實現的成本還是很小。

還有2012年渲染Participating Media的Joint Importance Sampling. 它提出了一個explicit的在Volume裡面建立特定長度的光線路徑的方法,比傳統直接重要性採樣phase function或者transmittance來建立光線路徑的做法收斂要快不少。而且將這個方法結合到Path Tracing里去是有Analytical的方程的。。十幾行代碼也就搞定了,太開心。

還有去年SIGGRAPH的UPBP. 基本就是Participating media版本的VCM,將不同的volume estimator用多重重要性採樣結合起來,能比較robost的渲染不同屬性的volume。

再例如去年的 http://lightrig.de/publications/p2014/HSLT/HSLT_preprint.pdf ,把robotics里的Generalized Coordinates用來表示光線路徑而且得到了更快的收斂結果,當時真的開了我的腦洞。期待這方面後續的research。

其他人提到的用神經網路和其他ML的方法我也覺得暫時在純YY的實驗性階段。。但是綜上我想說的是rendering從efficiency和robustness的角度來看還是有很多東西可以研究的。

最後,對於實時渲染來說,學術圈很少做這方面的研究的東西。像我之前這個答案 - 現階段應該怎麼學習計算機圖形學呢? - 文刀秋二的回答 說的,都是各種smart hacks,對真正學術理論的貢獻比較小。Physically based shading就那麼幾個公式在網上還都是現成的,是個遊戲引擎都可以用。做這方面工作的大多是遊戲公司以及顯卡公司,這類東西通常非常的practical和hacky,今天搞出來一個東西明天就馬上想能加到遊戲引擎里去那種,例如VXGI,HBAO+,TXAA等。而因為所有這些技術都是完全依賴GPU的,顯卡公司當然有絕對的研究優勢去運用新的硬體feature發明新的演算法。再加上現在圖形API的成熟,很多效果都高度受制於硬體的性能和feature,從這個角度來說實時渲染就是被顯卡公司驅動的也不為過(當然還有Epic這類引擎公司)。總之實時渲染是跟著industry走的,學校要有研究大多也是和NV這種公司有合作,而industry關注的面往往比渲染多很多,甚至有4k,跨平台,VR,新的圖形API。

以上全是個人觀點,完全不代表我的Employer


渲染應該說本身就已經是比較成熟的領域了,我認為是在理論上是沒什麼可研究的了。離線渲染本質是用各種採樣方法快速求解渲染方程。而實時渲染基本上是提出各種可以在GPU運行框架內執行的近似演算法,所以本質上收到了光柵化渲染框架的限制,你看人家Morgan Mcquire做了那麼多實時渲染的work,有些是很clever,但是總體來說其實都很trivial。可編程GPU管線已存在多年,能被利用的特性都已被充分挖掘。

所以現在很多做Rendering的researcher都在搞什麼呢,歐洲那幫人還是整天在推數學研究更快的採樣方法,還有一小撥人隔幾年灌一篇BVH的paper,基本上都是些在特定情況下實現marginal性能提升的文章。美國其實並沒有太多活躍的人在做rendering。

在一個成熟的領域做research要怎麼做?當然是加assumption。你XX演算法很好是吧,嗯,但是現在有這種情況Y,你看也很常見吧,用我的改進之後在這些地方就能快很多,雖然還有更多地方其實變慢了,但是沒關係,我們現在就是要看這種情況。你不能否認這是我的contribution所以你不能拒我。至於這東西對工業界到底有沒有用,關我屁事,我能發paper就好了。

Siggraph近些年基本沒有什麼靠譜的rendering文章。當然了,整個圖形學領域其實都越來越向扯淡的方向發展。大部分paper完全不值一看。越來越多的work變得跟vision之類的work一樣,調調參數硬把一個demo hack出來就可以發論文了,其實那個方法換了任何一個其他場景都不能很好的work。要讓他對一個新場景work,要麼要加新的條件判斷去hack,要麼調參數掩蓋缺陷。

所以我已經懶得搞純graphics的東西了,現在在做的事情是為高性能實時渲染提供編譯器/系統工具支持。

另外我也不看好在rendering裡面扯一些機器學習的東西,能用數學模型描述清楚的東西卻用模糊的方法去解決本質上是不太科學的。當然你總是可以說渲染不在於絕對數值正確,而是如何把人糊弄過去。因為我們不知道如何糊弄,所以寄希望於機器學習來神奇地完成這個任務。雖然涉及到感知的事情確實不好處理,但寄希望於機器學習更加讓人不安。或許某一天在這方面能有突破,但我不會建議在這方面耗盡青春,因為希望比較渺茫而且你很難在這個過程中學到有意義的東西。


來搞simulation吧少年。


gmm大神的回答已經很完善了,我來補充一下offline的東西,其實仔細看這幾年SIGGRAPH論文關於light transport的東西,更新很少,或者說創新點不夠多。一些號稱比較火的演算法,比如VCM,在實際應用中依然是殘廢的。今年有一篇用online learning 學習light transport分布的論文,實際看下來也存在很多問題:學習時間過長,應對問題太少等等。

我覺得GI的真正問題在於沒有很好的一種方法 或者 方法組合,來解決大部分場景中的光學問題,比如說progressive photon mapping適合渲染焦散,但在其他場景殘廢,BDPT對大部分效果都有很好的魯棒性,但是對SDS路徑無解,MLT適合各種複雜光照,但是參數和適應性太小。因為實際上光傳輸屬於最難模擬的一類自然現象,複雜程度太高.未來對於光線追蹤來說唯一的辦法可能就是多種辦法的結合。

所以現在對於圖形學迫切需要的是新路子,根本革新。個人看好機器學習和蒙特卡洛方法的結合


(第一不分先講背景:技術一點的內容在下面)

大學時,有一段時間對渲染非常感興趣。當時在開發一個類似谷歌地球的東西,有好多好玩的小功能。主要是用3D自由攝像頭和時間線來控制探索歷史變遷什麼的。雖然跟專業的關係不大,但是正好可以結合一些數學+地圖+歷史+編程的愛好。所以投資了好多時間。

時間久了,很多東西都忘掉了。只記得那些大致的小發現或小方法。(有一段時間在谷歌搞WebGL相關的,街頭實拍什麼的,但是那個項目不怎麼需要動腦子)

前兩天,突然發現知乎上有一大堆渲染類話題。一下子,各種回憶都突然想起來了。然後很想寫這方面的回答。花了整個周末把之前的代碼找出來,結果已經找不到了。(硬碟太多,很多都已經掛了不能再用)。

所以今天給自己休假一天,盡量把一些當時的原理找回來重新實現。

同時,希望對大家有所幫助。

(為何跟話題有關,最後再寫個總結針對這個問題,可能更清楚一些)

---

首先,我的渲染邏輯和思路跟大家都不太一樣。差距較大。

1)我比較喜歡從設備硬體基礎功能(底層輸入)出發。因為我喜歡控制裡面每一個細節。隨我來說GPU的shader language(渲染語)就是萬能的。

2)現在的主流行業思維是"bottom-up"。調用各種成熟的高級功能;把3d世界裡所有對象都渲染出來,再想辦法簡化速度化。最後變成一張渲染結果。我比較喜歡「top-down」,這張圖上每一個像素最後到底該渲染什麼顏色,讓每一個像素去探索世界好了。

3)什麼三角形組成的polyhedra、polygon之類的,我一點都不感興趣。雖然也比較熟悉,但是從一開始就有極大發自內心排斥感。一個像素並不需要知道世界上所有三角形在哪兒。

4)時間time(比如動畫)也只是多了一個數據維度,並不需要每次重新畫。跟換一個3D角度一樣,甚至更容易。(雖然這一篇不太涉及得到,以後再寫)。

5)不太在乎亮光,影子效果這種玩意。或者說我的重點放在渲染能力及效率,而不在美感方面。

(對顏色什麼的也不是特別敏感,或者感覺次要)

有點類似raycasting,但是要考慮到最現實的那些問題。如何去畫任意複雜形狀的東西?我並不想畫什麼簡單玻璃球形之類的呢?

---

OK, 為了這個演示,準備了一個python小庫lib.py:

也就這麼一點。不詳細解釋了。反正就是簡單利用一個shader畫(Draw)一張圖得了。

Python可以簡略一些,這方面。每次調用Draw,假設所有像素(屏幕)在 [-1,-1]:[1,1]之間一個正方形空間。

之後的工作,那就是Fragment Shader來負責。重點放在Fragment Shader。每個像素被並行處理。Vertex Shader(+Geometry Shader)那一套暫時不管了,我只想要一個每個像素獨立並行計算顏色的空間。

如果讀者不熟悉:我比較喜歡的這個 Fragment Shader 所負責的就是:一個像素到底顯示什麼顏色。唯一的輸入就是它在屏幕上的位置。GPU能夠將所有像素同時一起算出來,所以這種事情不太適合CPU。當然了,處理一個像素的計算能力相當弱,要慎重。照樣可以干很多事情了。

運行腳本是這樣的:

盡量用最簡單的,這個while loop可以一秒畫一百張,也可以畫一張直接保存圖片再退出。這一些不是很重要。(這裡的Draw是以2.5的距離慢慢隨機旋繞 [0,0], 重複每秒渲染100次左右)

Uniform(不變數)是什麼?是發給所有像素Fragment Shader的共同變數。不變是因為任何像素都看到一樣的值。這樣做會方便一些。比如攝像頭位置(rayOrigin),攝像角度之類的。要不然所有像素到底怎麼知道渲染什麼?比較重要。隨便提供什麼Uniform都可以輸入給Fragment Shader。

我的Fragment Shader一般怎麼寫?這裡得先解釋思路。

-----

比較喜歡「立方體」cube。因為一切計算都更簡單。其實整個思路建立在立方體上面。

我們第一個目標是渲染一個立方體:

Simple Fragment Shader:

上面載入所有uniform。

中間是一個函數。從一個像素[-1.1]^2的位置,算出它在3D世界裡的一條線rayDirection。

這一段就跟raycasting/raytracing一樣。

(camera origin就是我的那個rayOrigin)

我們這個像素的一條線發出來了,碰到什麼?這不就解決了嗎?

碰到了以後,通過distanceTravelled就可以獲得與對象相交的位置。

「gl_FragColor」是Fragment Shader主要固定輸出;也就是這個像素的最後顏色。

(這裡,為了簡化,就直接把對象相相交點的位置轉換成顏色。不太擅長這個。計算機顏色是三四個0-1的權重,一個四維向量,然而對象位置也是一個-1到1的向量。比起同一顏色好一些。如果這條線沒碰到任何對象,那就塗為黑色:0)

探測一個立方體是這樣:

原理很簡單:

解釋:任意一條線必須跟正方形的四個邊相交。(除非parallel,現實中可忽略)

然後相交的次數決定這條線是否進入了正方形。

(把這個概念放到三位、四位、還是一樣)

所以有這樣的一張圖:

(把這些代碼加起來)

-----

好了,那下一步;(實際上一直在旋繞,只要截圖)

如何顯示任意形狀?

這裡就得介紹一個cubetree(立方體樹)的概念:

每一個立方體都可以分為八個小立方體。其中每一個可以再次切小。切小切削到比一個像素還要小,根本看不出來是立方體所組成的。

代碼:

我知道有點複雜。可是我用了類似的演算法渲染過各種東西。已經差不多最簡化了。

意思是這樣;一旦發現了一個立方體,再調查該立方體裡面的八個部分(樹根)。

一條線一直從攝像頭往前走,經過大的小的立方體。什麼時候遇到空的立方體,就可以直接放棄了走到下一個了。大概這樣:

只不過是把這個思維做成三維以上。

走到了某個立方體,對方可以宣布自己是空的,然後直接掠過,往前跳過。也可以宣布自己裡面有東西,拆開走更小步。結果真的沒碰到東西,那就可以去下一個立方體了。

比如這樣:

每一個立方體都報告自己是否與一個對象重疊。(比如一個球表)

(分別是4層,8層,12層)

(13層以上沒什麼用,因為已經比一個像素還小;畢竟是倍數詳細化的)

這樣算,也挺快的,比一百萬個三角形都快。因為已經是O(logN)。

每個像素都能快速扎到對象邊界,有點類似binary search(把這個方法做到一維空間也就是binary search好嗎?)只不過是每一個像素獨立進行自己的search。

當然不僅限於球形什麼的。還可以快速渲染fractal。

(這裡是個最簡單的sponge fractal;其他fractal都一樣快。還不需要Distance Estimation微積分什麼的。可以直接讓立方體自己測試)

代碼:

(唯一的區別就是大小cube是否存在-是否與fractal重疊-的那一段代碼)

這還不是特別優化的代碼,怎麼這麼快?這個ray還能選擇性測試前面的大小立方體。所以根本不需要1024*1024*1024這麼多小立方體。因為樹根結構,每一條線(每個像素)只需要測試自己經過的30-120個。當然有用!

(唯一的區別就是cube是否存在的那個函數代碼)

用這種方法渲染fractal也很好玩。以後再專門寫一篇。

(現實這種複雜一點的fractal也可以,但是要hack一下代碼。當然不是這個小程序做的圖,但是差不多,只不過顏色沒那麼精緻。顏色反射這方面我沒有研究很多。)

-----

這大概是幾個基本的概念。一兩天也只能做到這裡。

當然可以用這種方法來渲染更複雜的model。以前開發的東西就是這樣的。

把polygon model轉換成立方體樹根就比較難了。這裡還沒來得及重新實現。甚至沒介紹4D texture的用途,如何把樹根寫成texture,等等。反正,轉換了之後,一切都很簡單。整個scene或animation都可以用最簡略(壓縮)的同一個樹根來描述。

為何比普通渲染流程強?因為無論場景有多複雜(無論多少個對象),時間需求都差不多。近的遠的若干個對象的形狀,都是O(logN)的效率來渲染。徹底利用了GPU那種並行計算的能力。多餘的計算也沒多少。

當然還有很多問題存在;可是一切普通fragment shader能幹的(什麼顏色影子之類的),一樣能補充進去。關鍵是把一個立體空間簡化成了一個數根結構,更適合渲染。

到底有多少公司或產品在用這種方式?並不是很多。這種軟體做法,減少渲染效率,如果加油開發;能夠改變好多。有點類似binary search/sort方法對於快速search的貢獻。

軟體方面還可以提高那麼多,感覺很明顯了。

(單獨用fragment shader來做渲染,也不是很理想。主要因為目前的硬體支持。因為這種樹根需要搜索texture。GPU的設計不太包容這種幾百次反覆搜索texture和pointer的做法。一般GPU最多一百次調用texture。有些workaround/loophole可利用,以後再講,可是整體GPU結構不夠支持這種演算法。我一樣感覺這就是未來的渲染路線之一。不管是軟體還是硬體,這個演算法不可缺少)

(好多細節沒來得及解釋了,道歉,今天寫的這一篇有點急。 看一看代碼的comments吧?)


如果要求完全物理真實,速度再提高一千倍也未必夠用,所以還有發展空間,與其說繪製理論完善,不如說現有數學工具已經被用盡。

通用性的Light Transport Simulation已經二十年沒有實質性進步了,速度提升更多是受益於硬體能力提升,受目前數學工具所限,演算法不可能有大的提高。另外,複雜如光傳輸模擬,總能設計複雜的場景讓演算法不那麼有效。


何止是渲染方面,想到實驗室灌的siggraph papers,自己正在做的project,心中淚流滿面,大罵這tm都有什麼用。。。感覺圖形學整體發展遇到瓶頸,大家都在玩new idea灌水。。


還早啊,諸君看看現在渲染技術還真的停留在eye-candy,有哪家敢拍著胸脯說我畫出來的和你看到的就是一模一樣的?!哪家傢具廠商敢拿著電腦和客戶說,這套傢具就是這個效果!!!我相信客戶絕對會劈死他:p.

由於硬體的飛速發展,現在在渲染這一塊技術和科研已經緊緊綁定在一起,我個人覺得的真實感繪製的研究原點已經越來越嚮應用物理學靠近,比如材料學。幾乎每種材料的渲染研究都可以成為學術界的方向。大家也可以在越來越短時間內求解非線性模型,各種高大上的物理方程很多無需簡化就可以扔給計算機(當然,這話誇張了,當然你明白我意思)。

以後真實感繪製所需要的計算能力會越來越巨大-快速迭代的非線性求解能力,超高維度的線性運算,超過現有精度的高精度運算等等等等,都是發展繪製技術的基石。


計算機圖形渲染技術本質上是一種工程技術,所謂的理論,很大程度上是為了顯得高大上一定硬做一個提個公式,個人認為rendering equation也是如此,看看siggraph的論文有多少真的嚴格基於這個公式來推導的,更多地不過是為了顯得有深度而硬搬上去的,如果你導師讓你做一篇關於全局光照論文,你多少會去關注這個公式?如果目標是快,那就是如何提高現有演算法速度,如果是目標是像,找找現有論文是不是近似做得太多了,加上點?

計算機圖形學關注就是如何在計算機上表現現實世界中的事物,不管是真實感渲染(電影,遊戲),還是非真實感渲染(油畫,水墨),如何做得看上去像是第一要務,很多論文提到的理論,尤其是真實感領域,更多的是如何將自然界基於物理規律的真實效果用計算機模擬出來,無論是光線跟蹤,光子映射,全局光照都是如此,涉及到理論的探討都在於如何選擇合理的參數來模擬物理規律,但這本質上還是一種工程技術。比如說《冰雪奇緣》中雪的效果,這篇論文還發了siggraph,通篇的焦點在於如何將雪的物理特性用參數表達出來並且像。我也讀過另外一篇雪的效果,也是類似的做法,不過選擇的參數和方法完全不同。


一百多年前,物理學也有與你類似的觀點。那時候的物理學家認為,物理學的研究已經到了沒有什麼可研究的地步,直到後來出現了愛因斯坦。

我不懂圖形學,妄言:一門學科給你這樣的感覺,只是遇到了一個瓶頸,一旦解決這個瓶頸。後面又會大有搞頭。


推薦閱讀:

TAG:OpenGL | OpenGLES | 計算機圖形學 |