基於圖形介面寫程序實時渲染3D空間有哪些優化性能的方法?

能不畫就不畫 // occlusion culling / LOD
能不更新就不更新
能簡化就簡化 // LOD
能一次畫的不要分多次畫 // batching / instancing / indirect drawing
相似的東西在一起畫 // sorting
能非同步的非同步
能並行的並行
能預計算的預計算
能給GPU算的給GPU算
時間經常可以用空間換
多讀書，演算法本身也可以優化
再不行可以降解析度渲染再拉大
實在不行了就砍效果砍功能

謝邀。

這個問題問得很大。真要寫絕對夠出一本書，甚至是一系列。

所以這裡就精神論一下，只談優化思路。

首先，渲染的最終目的是出圖。從這個角度出發：

無論是多大解析度，像素數總是有限的。所謂出圖，就是確定每個像素的顏色取值。

顯然，渲染性能反比於為了確定一個像素的顏色所需要進行的平均工作量。因此，必須想辦法減少渲染單一像素的開銷：

首先渲染方程決定了計算的複雜度。從而會影響性能。在滿足畫面品質要求的情況下，使用儘可能簡單的渲染方程，或者儘可能對方程當中相對固定的部分進行預計算，可以減少計算複雜度；
減少影響特定像素顏色的因素的個數，這是另外一個重要的點。比如，當場景當中有半透明物體的時候，對於其所覆蓋的像素，我們不僅要計算半透明物體的顏色，還需要計算其後面的物體的顏色才能確定最終顏色。另外，對於帶有強鏡面反射性質的物體表面，我們還要考慮其所反射的物體的顏色才能確定其最終顏色。這些都是巨大的性能損耗；

除了單一像素渲染的開銷之外，另外一個對性能有重大影響的方面就是渲染的並行度。理論上，如果一幀畫面的所有像素都是同時並行渲染的，那麼渲染時間應該只是由其中工作量最大的那個像素決定，而與畫面的解析度無關。

但是事實上顯然不是這樣。這是因為無論是CPU、還是GPU、亦或是作為數據提供和存儲的場地的內存，它們的帶寬都不是無限的。所以組成一幅畫面的數據只能夠按照一定的大小一批一批地進入渲染管道，直至渲染完成。

因為CPU/GPU/內存的帶寬資源都是有限且固定不變的，所以根據渲染數據流對三者帶寬的消耗情況，會在不同的地方出現瓶頸。一般來說，CPU的帶寬最小，所以諸如貼圖等對數據帶寬要求很高的數據對象，最好不要流過CPU。我們要將控制流和數據流分開，讓CPU主要專註在控制流上，而讓數據流盡量不要通過CPU。

GPU的帶寬一般相較於CPU在10倍以上。且GPU的後端就是顯示輸出，所以我們必須讓數據流經過GPU。但是，GPU當中流過的數據流其實也有好幾種：

頂點和索引數據流（元數據流）
貼圖和渲染對象（RT）數據流

而且，由於GPU當中的渲染管線是按照VS-PS這樣的方式，後段的貼圖和渲染對象數據流其實受制於前段的頂點與索引數據流，所以兩者的比例關係就會對性能產生很大的影響。

由於當代GPGPU當中共用一套處理核心來處理這兩種數據流，這就使得GPGPU在對頂點和索引數據流的處理能力與對貼圖和渲染數據流的處理能力之間有著某種比例關係。比如，在採用Triangle-Strip方式來描述模型的時候，從第三個頂點起，每處理一個頂點就會生成一個三角面。而三角面會被Rasterlizer離散成為一定數量的像素，然後進行像素顏色的計算。

當三角面很大的時候，一個三角面會離散出很多個像素。這可能會使得貼圖和渲染對象（RT）數據流流量猛增，但是反過來壓迫頂點和索引數據流的處理，使其不能達到飽和處理能力；而頂點和索引數據流的處理受到壓迫，最終又會使得GPU無法在短時間內攢齊足夠的像素投入後端渲染，從而導致性能的低下；

而當三角面很小的時候，一個三角面可能只能離散出很少的幾個像素。為了充分利用GPU和內存的處理帶寬，GPU可能不得不等待更多的三角面的離散完成，湊齊足夠的像素數才能進入後段的處理。這同樣會導致性能的低下。

所以我們要控制好三角面的大小，也就是控制好頂點與像素的比例。對於較遠處的模型要通過LOD等方式避免產生大量的小三角形。

貼圖在內存上的排布同樣十分重要。GPGPU雖然帶寬很高，但是對內存的訪問延遲也很大。所以當貼圖沒有被緩存在GPGPU的L1/L2緩存當中的時候，會引起相當顯著的等待數據的情況。為了充分利用L1/L2緩存所提供的低延遲特性，我們應該安排好貼圖的以下幾個方面：