轉自：http://gad.qq.com/program/translateview/7160166
譯者：趙菁菁（軒語軒緣） 審校：李笑達（DDBC4747）
對於任何追求UE4性能最佳、同時又想保持極高質量視覺效果的人來說，本文有一些可遵循的一般性建議和原則。
局限性
為了性能，你通常受CPU時間（通常和游戲設置相關）和GPU時間限制（渲染場景花費的時間）。CPU創建由GPU渲染的場景會耗費一些時間。
通常情況下，當你發現游戲的運行速度不像你想要的那么快時，第一步是找出你現在受以上哪個環節的約束，然后確定需要修改的資源或設置來修正問題。UE4的一些內置工具就是為了實現這個目標而存在的，我建議好好掌握這些工具，特別是CPU和GPU分析器。
了解可用工具
控制台指令
UE4中有很多可用工具，它們可以用來分析性能和幀率，許多工具采用控制台指令形式，可用在控制台輸入這些程序指令，控制台可以在游戲中通過按波浪鍵顯示，也可以在編輯器的顯示菜單里找到。這里圈出的是幾個特別有用的指令（這些可以按“stat__”也就是“stat unitgraph”或者“stat fps”的形式在控制台輸入）。
先是Stat的“Engine”組：
這里讓我們仔細看看從“Detailed”Stat組得到的信息（自動選中上面圈出的多數其他stat組）：
- 這是當前幀率（每秒幀數）和幀時間（每幀毫秒數）。
- 這是幀時間
- 這被分解成兩組：
- i. Frame（幀）：幀花費的總時間。
- ii. Game（游戲）：這是一個任意的CPU邏輯，它不與渲染直接關聯。如果該組很慢，通常的情況是程序員有需要修正的內容，但是它可以是與藝術相關的，比如：屏幕上有太多顆粒。內置在CPU分析器中的Frontend工具可以用來研究CPU性能並且觀察正運行緩慢代碼。特定的、與復雜任務相關的游戲設置只能在CPU上執行，像A.I.和Navigation的設置。
- iii. Draw（繪圖）：這是一個與GPU上渲染設置相關的CPU邏輯。它包括圖形API和繪圖調用的設置，或者如果渲染代碼已經以非最佳的方式修正了，它就可能與渲染代碼相關。
- iv. GPU：GPU渲染幀花費多長時間。它包括：執行圖形API調用、繪圖調用、着色器和后過程着色器的執行、獲取紋理……這里的問題通常與資源相關，它可能是場景中類似着色器這樣非常復雜的東西，或者場景中有許多不同的網格，結果就是每幀中發生太多的繪制調用。這可能會讓一個專業美工或程序員找到問題根源，但是通常情況下需要一些決策——為了達到預期性能，應該做哪些藝術權衡。這里能幫到您的最棒的工具是GPU分析器和着色器復雜性視圖，這些會在之后進行討論，同時下面還會討論“Advance”目錄中顯示的特定stats。
- 這里有兩個度量
- i. 第一個是這個幀的當前幀時間（左）
- ii. 第二個是在最后幾秒的最差幀時間（右）
- 注意GPU和CPU（游戲&繪制）是同時執行的，所以幀花費的總時間不是它們時間的總和，但是任一項拖了后腿都可能是幀率降低的原因。
- 這被分解成兩組：
- 這是游戲、繪圖和GPU的幾個幀里的幀時間圖。
- 這是圖中的峰值——當一個特定過程（游戲、繪圖或者GPU）的執行花費了很長時間時。它用毫秒標記了那個頂峰的最慢幀的時間。
這也是stats的一個“Advanced”組，它有更詳細的內容需要說明。
在“Advanced”組中的大多數項是特別針對像Lighting或者AI Behavior這樣特定系統的，所以這樣的系統也包含專門針對“Advanced”組的stats。這里讓我們看一些特殊興趣點的例子：
場景渲染指令和繪制調用
場景渲染是特別方便的，因為它顯示了你的場景中繪制調用發生的次數，取決於你的繪圖API，這可能是一個極其重要的數字（例如：在手機OpenGL平台上，繪制調用代價太高了以至於開發者經常將大多數的環境並入一個靜態網格中來讓它作為一個單一的繪制調用）。
初始視圖指令和選擇
在驗證場景剔除時這個stats組很有用。“剔除”就是當你選擇性地不運行或渲染部分場景，這些場景當前視圖中不會使運行加速。通過參考Frustum Culled初始量值，你可以查看渲染系統決定不繪制的初始量的數量，因為這些量是不可見的。相反，可見的動態初始量部分顯示了被定義為可見初始量的數量。
另一個可視化的方式就是使用調試攝像頭，你可以在玩游戲的時候通過控制台命令“ToggleDebugCamera ”轉至調試攝像頭。在那里，如果你點擊“F”鍵來停止渲染並且把調試攝像頭移到另一個角度，你可以清晰地看到哪個初始量被渲染了、哪些被修改了。
在上面的屏幕截圖中你可以看到預覽窗口中的角色攝像的原始視圖，該視圖是在Play模式中通過在場景大綱中選擇攝像頭呈現的。ToggleDebugCamera用來停止渲染，在移動攝像頭到另一邊查看剔除的初始量時，要保證攝像位置的剔除是穩定的。
性能可視化工具
線框視圖模式可以告訴你場景和獨立網格中有多少頂點和三角形，要實現這個模式，你可以在編輯器等級視口的可視化模式菜單中找到，或者在游戲運行期間按F1鍵，或者在控制台輸入“viewmode wireframe”命令：
如果你的網格有三角形/頂點的富余，而且遠比攝像頭的充足時，線框就會變成實線。如果你的網格不總是實線的，這意味着你有可能需要比渲染更高的復雜性，你就應該減少網格中的多邊形數量。
着色器復雜性可視化
當你的場景中存在很多材質時，可能很難確定哪些是復雜的。幸運的是，UE4中有一個內置視圖：着色器復雜性。通過編輯器關卡視窗中的可視化模式菜單可以找到它，還可以在游戲運行時通過按F5找到它，或者進入“viewmode shadercomplexity”控制台指令：
這里的暗綠色區域比淺綠色區域含有更復雜的着色程序邏輯，紅色和白色區域也仍有更加復雜的着色邏輯。着色復雜性最大的原因通常是：當多重透明材質重疊時，需要為所有重疊區域計算着色。
當你已經確定了一個紅色區域，你可以右擊對象來編輯那個角色，在這種情況下——一個靜態網格：
從這個靜態網格編輯器中，你可以在Details面板中看到網格正使用的材質：
單擊放大鏡就可以在內容瀏覽器中選擇材質資源，你可以雙擊它來打開材質編輯器：
在材質編輯器中，你可以推動stats按鈕來打開stats的材質標簽。在這里你可以看到材質對應的着色器的說明數量。但是說明數量不是與性能的影響一一對應的（因為一些說明比其它更昂貴）了，於一個材質的復雜度來說，說明的總數是一個很好的表征，總體來講，減少說明的數量可以產生更好的性能。
着色器在其它領域的性能也可以是受約束的——如紋理緩存。如果你在你的材質中用了許多紋理，那么就可能沒有足夠的空間來立刻將它們寫入緩存，所以它們最終會被調入、調出內存，這樣是非常慢的。因為這個原因，有可能的話最好減少每個材質的紋理取樣器。在材質編輯器的stats窗口和說明數量中，你可以看到材質目前正使用的紋理取樣器的數量。
另一方面，着色器在紋理檢查中性能也受約束。比如說如果你正在使用一個大型紋理，但是它距離攝像頭很遠，相對只有一小部分紋理是會被取樣的，但是為了給它取樣，要讀比實際用到的多得多的紋理。這里錐形紋理技術（mip map）就起作用了，因為錐形紋理在紋理的連續區域內包含的紋理更小，所以只有紋理的小得多的部分需要被讀入來得到采樣。這樣一來，保證在所有紋理中充分利用錐形紋理技術是很重要的。
光線復雜度視圖模式
光線復雜度視圖模式 顯示了影響你的幾何圖形的非靜態光線的數量，它可以通過編輯器等級視口的可視化模式菜單得到，或者在游戲運行中按F9鍵：
這對於追蹤光線代價是很有用的——光影響外觀越多，它產生陰影的代價就越大。
一個光線可以被剔除的方式有很多，包括半徑削減、z型交叉、攝像頭背對光源、光函數是0等等，所以光會在不同陰影中出現是非常有可能的。光線復雜度視圖模式在將代價與顏色亮度聯系起來的方面是做得最好的。
減少半徑削減或者光線的錐形角度可能會有幫助。打光性能是非常依賴角度的，所以它極大程度上取決於玩家的攝像頭在哪里，由於這個原因，最好在不同角度研究光復雜度。
靜止光線重疊視圖模式
靜止光線重疊視圖模式用紅色顯示了哪些靜止光線正被迫移動。
靜止光線一次最多只允許4次重疊。一旦你有了大於等於5個的靜止光線重疊，擁有最小半徑的那個靜止光線會開始投射動態陰影，這會產生很高的性能代價。
其他Stats視圖
在Window>Statistics菜單中有一些其他統計數據視圖：
紋理Stats
這個工具顯示了在當前關卡下使用的所有紋理，它們的分辨率、使用次數和游戲中出現的時間。如果你的場景中有高分辨率的紋理並且沒有被很多使用次或者不常見，它們不僅會占據很多不必要的內存，而且也會造成GPU處理緩慢，增加GPU渲染場景花費的時間。
初始量Stats
這里你可以看到許多有用信息，開始是在你的骨骼網格、靜態網格和場景中有多少三角形初始量。如果你在你的場景中定義了一個對象，它的三角形數量很多，試着在線框層次上觀察這個角色。
可視化用來觀察線框在一個正常的觀察距離外是否保持着實線（或接近實線），這意味着在你的網格中你有比你需要的更多的細節，你可以使用DCC工具或者UE4支持的網格簡化工具來減少網格中的頂點數量。
初始量Stats視圖也包括數量，這個數量是在當前關卡上使用的數量；還包括實例部分，就是網格中類似着色器和繪制調用這樣的元素的數量，主要就是繪制這個對象實例復雜度的度量。如果兩個值數量值很高（在你的關卡設置了許多相同對象），實例部分值也很高（對象渲染復雜），那么這可能導致渲染時大量的繪制調用或者圖形API狀態發生變化，這會顯著增加GPU渲染場景的時間。基本上，如果數量×實例部分與場景中其他對象相比是一個相對大的數，這個對象就是應該優化的區域。達到這個目標的一個潛在方法是把單一角色用高多邊形數量分解成多個角色，允許他們被單獨選擇，因此你就有機會一次性繪制比整個多邊形數量少的圖像了。但是這主要只對CPU加載有影響，所以如果你的游戲不是CPU受限的，那么最好把你的優化時間集中在其它任務上。
只有一種不適用的情況：當使用實例化的靜態網格特征時，你可以使用這個特征在你的關卡周圍設置許多相同靜態網格的拷貝，但是在渲染時應把它們合並為一個單獨的繪制調用。這可以提升性能，但也意味着那些網格不能被單獨選擇，所以如果它們中的任何一個在屏幕上可見，它們都會被渲染。
分析器
也許在優化性能時應該熟悉的兩個最重要的工具是CPU分析器和GPU分析器。
CPU分析器
CPU分析器作為一個獨立應用運行，可以從Session前端或者Unreal前端獲取到，Session前端可以在Unreal編輯器的窗口菜單中找到。這里我將會討論如何使用Unreal前端，因為兩者的界面幾乎是完全相同的。
首先你應該啟動你的游戲，最好是作為一個獨立應用程序運行，但是你也可以在Unreal編輯器中分析運行（在編輯器中分析意味着會有很多的編輯器菜單邏輯和其他代碼在你的分析記錄中出現，所以最好把它作為一個獨立游戲來分析）。
分析的最好配置就是測試建立，因為所有不必要的調試輸出都可以被省略，而且它含有全部的代碼優化，並且使用烘焙的優化內容。你可以讀到更多關於不同建立配置的信息。你也會需要烘焙來讓你的內容作為獨立游戲來運行，這可以通過Unreal編輯器的File Menu > Cook Content for*Platform*完成，或者你可以為其他平台給你的內容打包。
無論是何種原因，如果你不能完成測試建立或者烘焙你的內容，你可以完成一個開發編輯器建立，帶着游戲選項運行，這會為很好地為你顯示不同特征的相對性能代價，但是一個含有烘焙內容的測試建立對於得到最終數據是最佳選擇。
當啟動你的游戲時，啟用游戲和Unreal前端之間的內部過程通信，通過使用命令行上的messaging選項是很必要的。Unreal前端不僅支持在相同機器上運行的UE4應用分析，也支持在網絡中分析。
在你完成啟動游戲之后，你可以運行UnrealFrontend.exe，這可以在UE4/Engine/Binaries 文件夾中找到。你可以看到如下的界面，先在導航找到Session前端標簽，之后找到分析器標簽。
一旦你選擇了一個session和一個實例，數據抓取按鈕就會變得可用，你可以立即點擊它開始數據抓取，再點擊一次停止。當你停止的時候，你可以看到一個對話框詢問你是否想要把抓取結果傳遞到這台機器上：
在這里，它會把文件傳到你的機器上（如果你不是在網上分析的話就本地拷貝），你會看到這個彈出框：
當完成時，會詢問你是否想要加載：
當分析器已經加載了，它長成這樣：
我會詳細解釋各個部分：
- 這是一個渲染線程vs游戲線程的簡圖，根據CPU邏輯與渲染的關系，一眼你就會知道你是否是CPU受限的，或者它是否是與游戲相關的且花費最多性能的邏輯。
- 這個區域顯示了抓取期間的整個CPU加載的簡圖。在這里，你可以沿着時間線單擊任何部分來觀察對應幀的CPU分析，或者你可以單擊、拖拽來選擇幀的范圍並且查看均值。根據你這里的選擇，函數時間（3）的層級列表中的分析數據會改變。
- 這是調用的不同函數和所花時間的層級列表，花費時間最長的函數排在頂端。花費最多時間的函數以紅色顯示，其它用黑色顯示。你可以通過單擊左側三角來展開對應層，你可以看到這個函數調用過程的分解以及執行花費的時間。
a.
b. 注意這里的CPU停轉是CPU閑置等待其它線程結束的時間。
- 如果你在函數時間（3）的層級列表中選擇了特定的函數，你可以看到這里的顯示變化，這里顯示了什么函數調用了這個函數，以及該函數調用了哪些函數，同時可以看到這些調用和被調用函數執行時間的比例。
- 左側面板展示了stats和stat組。頂層是stat組，你可以展開它查看內部的獨立stat。這些stat可以是整型、浮點型數字或者內存，你可以控制哪些顯示在stat過濾器面板（6）中。如果你鼠標停留在一個stat上，會彈出該stat的分析信息（8）。
- 在這里你可以通過搜索想要的stat、改變分組和排序、隱藏/顯示不同類型的stat（浮點/整型/內存）以及啟用/禁用層級視圖控制stat面板的顯示（5）。
- 這些控件用於顯示函數時間的層級列表和所選函數的分解信息（4）
a. 類型——如果在圖像視圖中你只選擇了一幀（2），你唯一的選擇就是顯示信息那幀，但是如果你選擇了一系列幀，你可以選擇是否顯示平均時間或者花費的最長時間。
b. 視圖模式——這會改變函數時間分層的層級列表視圖（3），或者改變單純的函數列表，里面包括這些函數的子程序包括的或排除的時間。
c. 向前、向后按鈕可以讓你在圖像視圖的不同部分之間跳轉（2）。所有你可以看到一系列信息，之后縮小你的選擇范圍直到一個幀，然后用這些按鈕來在兩者之間切換。下拉箭頭顯示了之前的選擇。
d. 這里的火焰按鈕是用來展開你當前選擇函數的時間層級列表的（3），用來查找花費最多時間的路徑，它也會用一個小火焰圖標來標識該路徑。
8. 鼠標在stat面板（5）的一個stat上面停留時，會顯示關於該stat的分析信息，最重要的是最小值、平均值和最大值：
GPU分析器
有一個與研究GPU性能的類似工具。
首先，如果你想要啟動你的游戲，最好先作為一個獨立應用來啟動，但是你也可以在Unreal編輯器中分析它的運行（因為編輯器UI渲染等也會在你的分析文件中顯示，所以最好單獨分析游戲）。
分析的最好配置就是測試建立，它含有全部的代碼優化，並且使用烘焙的優化內容。你可以讀到更多關於不同建立配置的信息。你也會需要烘焙來讓你的內容作為獨立游戲來運行，這可以通過Unreal編輯器的File Menu > Cook Content for*Platform*完成，或者你可以為其他平台給你的內容打包。
如果因為無論任何原因你不能完成測試建立或者烘焙你的內容，你可以完成一個開發編輯器建立，帶着游戲選項運行，這會為很好地你顯示不同特征的相對性能代價，但是一個含有烘焙內容的測試建立對於得到最終數據是最佳選擇。
在這個游戲中，你可以在控制台輸入profilegpu來啟動GPU分析器，或者按Ctrl+Shift+,來啟動，這會打開GPU觀察器：
這里你可以看到一張形象圖，里面有渲染場景的步驟，在頂部可以看到它們在GPU上花費多少時間，在底部你可以在文本列表中看到相同的信息。在圖或者列表中任選一個入口都會在兩地方同時選定選中對象，如果鼠標在圖上停留，會顯示GPU的任務名稱。
這個命令不僅打開了觀察器，同時也向日志文件和輸出日志輸出了相同信息（也有一些額外信息）。你可以從窗口菜單中打開輸出日志：
輸出日志標簽中的輸出內容如下：
你可以在輸出日志中看到這里也有百分比信息，還有繪制、初始量和頂點的數量。
為你的內容做計划和預算
優化的最初階段之一應該是為你的內容計划性能預算。為制作內容制定指導方針是必要的，所以當美工為游戲制作不同角色和環境時，它們的性能和內存特征變化不大，一些內容的合並會以一個不好的幀率運行，因為一些合並未充分利用潛在可用的CPU和圖形性能。
特殊的性能提升建議
合並網格
如之前在線框可視化解釋中提到的，減少三角形和頂點的數量永遠都是提高性能的方法，但是很多時候，一個單獨網格比多個網格刻畫集合圖形的性能要好得多（一個有1000個頂點的網格可能比10個有100個頂點的網格的更新和渲染都快）。這是因為不僅這些網格可能會分別單獨調用GPU來繪制，也因為UE4會為每個網格單獨保存和更新變換信息，而且可能檢查這些獨立網格間的碰撞。所以，如果沒有功能性的原因來設置單獨網格的話，你應該考慮在把它們引入UE4之前在DCC工具中選擇合並它們。
關於合並網格反對的說法是：一個單獨的網格可能不能被部分剔除，所以如果它的任何一部分是可見的，整個網格都會渲染。由於這個原因，可能把你的整個關卡都合並成一個單獨網格可能不是一個好主意，但是讓每一個三角形都成為一個單獨網格同樣也不是最理想的，所以在兩種極端中取得平衡至關重要。
由大量網格組成的單一對象
使用由很多獨立網格組成的對象（比如說一輛車的每個獨立部分由成百成千的單獨網格組成）對於引擎來說可能任務非常繁重，如果引擎在仿真時把每個網格當做獨立對象，而且為每個網格單獨運行引擎系統（例如：在你的對象中為幾千個網格進行單獨的挽歌物理仿真）。
像這樣對許多網格組件進行父處理並且把它們作為一個對象處理比較好，但是我們有一些建議提供給你，來避免在這些事情上浪費不必要的CPU和GPU的周期。
首先，如果你的對象中有許多網格並且經常不可見，試着不要在移動場景中建立這些網格直到它們可見。即使網格沒被渲染，每當一個父級網格組件的變換改變時，每個子網格組件的變換都會被更新，而且在網格需要可見前不要調用Components.Add()方法，這樣可以節省許多處理器周期。
同樣道理也適用於在游戲系統中注冊不可見的網格，如果網格不可見，它的物理形態等可能不需要每幀都更新，所以，在網格需要變為可見之前不要在不可見網格組件上調用RegisterComponent()方法。
避免在由相同對象組成的、或不需要相互碰撞的網格間運行碰撞檢測。
對於那些不需要碰撞的子網格組件，把它們的碰撞情況設置為無：
ChildMeshComponent>SetCollisionProfileName(UCollisionProfile::NoCollision_ProfileName);
如果你的角色一點也不需要碰撞，那么就在你的父級網格組件上設置相同的內容，否則就在父級上啟用碰撞，但是給它一些能表示它和它的孩子的碰撞說明。
如果包含你的角色的網格組件是接觸的或重疊的，它們就會產生重疊時間。如果你不在意這些事件，禁用它們會提升性能：MeshComponent>bGenerateOverlapEvents = false;
屏幕剔除系統用網格組件的邊界來確定該網格是否應該在這一幀中渲染。對於那些含有許多網格組件的對象來說，即使對象部分在屏幕外，為每個獨立子對象檢查邊界的代價也可能比單純渲染所有網格組件的代價要大。試着設置子網格組件使用它們父級組件的邊界，來測試觀察性能是否沒有提升。
ChildMeshComponent>bUseAttachParentBound = true;
給所有這些網格單獨打光是不必要的繁重任務——在CPU配置文件中渲染線程部分中“更新間接照明緩存”的毫秒數值很高。通過在你對象的根組件中設置bLightAttachmentsAsGroup為true，你可以選擇在你的對象的每個網格中使用相同的間接照明緩存信息，這會節省獨立更新網格的時間。
推薦的光線性能設置
動態對象的每個對象陰影可以通過不選關卡平行光中的bUseInsetShadowsForMovableObjects 的flag來禁用，這會提升性能。
在你的關卡的平行光屬性中，經常減少動態陰影級聯的數量不會對陰影外觀產生非常大的影響，但是會提升性能，我認為默認的是5，但是減少至大約3的樣子就會產生大致差不多的效果。
動態陰影
動態陰影的代價可能很大，尤其是全局動態陰影。這是因為三角形必須得為動態陰影映射重新渲染。如果你在移動光源上需要許多動態陰影來使多邊形盡可能少，如果你想要更多多邊形，那就試着少用帶有動態陰影的可移動光線。
記住，設置了4個以上的重疊固定光線會迫使半徑最小的那個變成可移動的，這樣就會開始投射動態陰影。本文他處討論的固定光重疊可視化是確保沒有過多重疊的好方法。
限制后過程效果
后過程效果同樣是代價很大的，禁用你不需要的效果也可以很大地提升性能。一些可以考慮禁用的后過程效果包括鏡頭閃光、土地深度和屏幕空間反射。為了提升性能，你可能也想要以低質量運行屏幕空間抗混疊，以更小的散景尺寸運行散景DOF，因為這里的尺寸與性能是負相關的（更大的散景意味着更差的性能）。
如果最終你可以在其它系統中取得足夠的性能提升，你可以之后選擇性地把這些效果重新啟用。
高存儲低質量影響
● 在后過程設置中禁用scene color fringe
● 禁用 ambient cubemap，用 LightmassEnvironmentColor代替
● 通過設置強度在后過程設置中禁用imagebased lens flares 。
在單一鏡頭中限制貼花數量
如果在攝像頭中同時有許多彼此接近的貼花，有時這樣的代價是很大的。如果你有比如說50個貼花正同時被渲染，這對於性能可能有消極影響。試着稀釋或擴散這些貼花，那么就不會有那么多貼花同時被渲染了。
以更低分辨率和更少變形渲染
如果你想要試着以稍低的分辨率和稍少的變形進行渲染來節省性能，試着做、看看它看起來和運行起來效果如何是非常簡單的。
當游戲運行時，你可以打開控制台輸入“r.screenpercentage 90”，其中90是全憑尺寸和渲染的百分比。
更永久的設置方法是：選中你的后步驟列表里的“覆寫屏幕百分比”框，之后將屏幕百分比設置成想要的百分比（小於等於100）。
場景捕捉對象
場景捕捉對象（如場景捕捉立方體）的默認設置是捕捉每幀。捕捉這些基本涉及到從不同視角渲染整個場景（對於一個場景捕捉立方體來說，會這做6次，每次渲染立方體的一個面），還有從玩家的視角來渲染。這樣的代價明顯是很大的（如果一個場景中有許多這樣的對象尤其如此），所以，除非每幀都抓取它們是你的游戲的一個重要特點，抓取應該被禁用。
總體來講，同樣的原因，限制場景抓取物件的總數量是有道理的。
其它涉及事項：
設置最大和最小幀率
可以在DefaultConfig.ini.文件中設置來控制這個變量，默認如下：
[/Script/Engine.Engine]bSmoothFrameRate=true MinSmoothedFrameRate=22
MaxSmoothedFrameRate=62
禁用遮擋剔除
對於一些特定類型的游戲，遮擋剔除可能會花費比它本身所節省的時間更多。比如：在打斗游戲中，通常場景中的所有內容都應該是被渲染的，不常見的情況是許多幾何圖形被其他對象遮擋，在這些情況下，使用全局預計算可見復選框也許有幫助？