遊戲引擎中三大及時光照渲染方法介紹(以unity3d為例)
重要:在目前市面上常見的遊戲引擎中,主要採用以下三種燈光實現方式:
頂點照明渲染路徑細節 Vertex Lit Rendering Path Details
正向渲染路徑細節 Forward Rendering Path Details
延遲光照渲染路徑的細節 Deferred Lighting Rendering Path Details
以unity3d為例,以下將詳細講解三種燈光渲染方式的實現、原理及缺陷。
頂點照明渲染路徑細節 Vertex Lit Rendering Path Details
Vertex Lit path generally renders each object in one pass, with lighting from all lights calculated at object vertices.
頂點照明渲染路徑通常在一個通道中渲染物體,所有光源的照明都是在物體的頂點上進行計算的。
It's the fastest rendering path and has widest hardware support (however, keep in mind: it does not work on consoles).
頂點照明渲染路徑是最快的渲染路徑並且有最廣泛的硬體支援(然而,請記住:它無法工作在遊戲機上)。
Since all lighting is calculated at vertex level, this rendering path does not support most of per-pixel effects: shadows, normal mapping, light cookies, highly detailed specular highlights are not supported.
由於所有的光照都是在頂點層級上計算的,此渲染路徑不支援大部分的逐畫素渲染效果:如,陰影、法線貼圖、燈光遮罩、高精度的高光。
正向渲染路徑細節 Forward Rendering Path Details
Forward Rendering path renders each object in one or more passes, depending on lights that affect the object. Lights themselves are also treated differently by Forward Rendering, depending on their settings and intensity.
根據影響物體的光源的不同,正向渲染路徑用單個或多個通道來渲染物體。在正向渲染中,光源本身也會根據他們的設定和強度受到不同的對待。
Implementation Details 實現細節
In Forward Rendering, some number of brightest lights that affect each object are rendered in fully per-pixel lit mode. Then, up to 4 point lights are calculated per-vertex. The other lights are computed as Spherical Harmonics (SH), which is much faster but is only an approximation. Whether a light will be per-pixel light or not is dependent on this:
在正向渲染中,影響物體的最亮的幾個光源使用逐畫素光照模式。接下來,最多有4個點光源會以逐頂點渲染的方式被計算。其他光源將以球面調和(Spherical Harmonics)的方式進行計算,球面調和技術計算很快但只能得到近似值。根據以下的規則判斷一個光源是否為逐畫素光源:
- Lights that have their Render Mode set to Not Important are always per-vertex or SH.
渲染模式被設定為不重要(Not Important)的光源以逐頂點或球面調和的方式進行計算 - Brightest directional light is always per-pixel.
最亮的方向光源為畫素光源 - Lights that have their Render Mode set to Important are always per-pixel.
渲染模式被設定重要(Important)的光源為畫素光源 - If the above results in less lights than current Pixel Light Count Quality Setting, then more lights are rendered per-pixel, in order of decreasing brightness.
如根據以上規則得到的畫素光源數量小於質量設定中的畫素光源數量(Pixel Light Count),為了減少亮度,會有更多的光源以逐畫素的方式進行渲染
Rendering of each object happens as follows:
用以下的方法渲染每個物體:
- Base Pass applies one per-pixel directional light and all per-vertex/SH lights.
基礎通道渲染一個逐畫素方向光和所有的逐頂點/球面調和光。 - Other per-pixel lights are rendered in additional passes, one pass for each light.
其他逐畫素光在附加的通道中進行渲染,每個光源都需要一個通道
For example, if there is some object that's affected by a number of lights (a circle in a picture below, affected by lights A to H):
例如,如果有一個物體受到若干光源的影響(下圖中的圓圈,受到光源A到H的影響)
Let's assume lights A to H have the same color & intensity, all all of them have Auto rendering mode, so they would be sorted in exactly this order for this object. The brightest lights will be rendered in per-pixel lit mode (A to D), then up to 4 lights in per-vertex lit mode (D to G), and finally the rest of lights in SH (G to H):
假設光源A到H都有相同的顏色和強度,且它們的渲染模式都為自動的(Auto),那麼它們嚴格的按照其名字排序。最亮的光源以逐畫素光照模式的方式進行渲染(A到D),然後最多有4個光源以逐頂點光照模式進行渲染(D到G),其他光源以球面調和的方式進行渲染(G到H)。
Note that light groups overlap; for example last per-pixel light blends into per-vertex lit mode so there are less "light popping" as objects and lights move around.
注意不同的光照組間有重疊,如,最後一個逐畫素光源也以逐頂點光照模式的方式渲染,這樣能減少當物體和燈光移動時可能出現的"光照跳躍"現象。
Base Pass 基本通道
Base pass renders object with one per-pixel directional light and all SH lights. This pass also adds any lightmaps, ambient and emissive lighting from the shader. Directional light rendered in this pass can have Shadows. Note that Lightmapped objects do not get illumination from SH lights.
基礎通道用一個逐畫素方向光和所有球面調和光渲染物體。此通道還負責渲染著色器中的光照貼圖,環境光和自發光。在此通道中渲染的方向光可以產生陰影。需要注意的是,使用了光照貼圖的物體不會得到球面調和光的光照。
Additional Passes 附加通道
Additional passes are rendered for each additional per-pixel light that affect this object. Lights in these passes can't have shadows (so in result, Forward Rendering supports one directional light with shadows).
附加通道用於渲染影響物體的其他逐畫素光源。這些通道中渲染的光源無法產生陰影(因此,前向渲染支援一個能產生陰影的方向光)。
Performance Considerations 效能注意事項
Spherical Harmonics lights are very fast to render. They have a tiny cost on the CPU, and are actually free for the GPU to apply (that is, base pass always computes SH lighting; but due to the way SH lights work, the cost is exactly the same no matter how many SH lights are there).
渲染球面調和光很快。它們只花費很少的CPU計算時間,並且實際上無需花費任何GPU計算時間(換言之,基礎通道會計算球面調和光照,但由於球面調和光的計算方式,無論有多少球面調和光源,計算它們所花費的時間都是相同的)。
The downsides of SH lights are:
球面調和光源的缺點有:
- They are computed at object's vertices, not pixels. This means they do not support light Cookies or normal maps.
它們計算的是物體的頂點而不是畫素。這意味著它們不支援投影遮罩和發現貼圖。 - SH lighting is very low frequency. You can't have sharp lighting transitions with SH lights. They are also only affecting the diffuse lighting (too low frequency for specular highlights).
球面調和光只有很低的頻率。球面調和光不能產生鋒利的照明過渡。它們也只會影響散射光照(對高光來說,球面調和光的頻率太低了)。 - SH lighting is is not local; point or spot SH lights close to some surface will "look wrong".
球面調和不是區域性的,靠近曲面的球面調和點光和聚光可能會"看起來不正確"。
In summary, SH lights are often good enough for small dynamic objects.
總的來說,球面調和光的效果對小的動態物體來說已經足夠好了。
延遲光照渲染路徑的細節 Deferred Lighting Rendering Path Details
Deferred Lighting is rendering path with the most lighting and shadow fidelity:
延遲光照是一種當前最高階的能實現光線和陰影保真的渲染路徑
- There's no limit how many lights can affect any object.
對於能影響任何物體的光線數量沒有上限 - All lights are evaluated per-pixel. Which means that they all interact properly with normal maps etc.
完全採用以每畫素的方式評估光線,這等於意味著全部將以正常貼圖的方式正確的和物體互動 - All lights can have Cookies.
所有光線都能擁有資訊快取 - All lights can have Shadows.
所有的光線都能產生陰影
Deferred Lighting's advantages 延遲光照的優點:
- Lighting cost is proportional to light size on screen. Does not matter how many objects it shines on. Small lights = cheap!
光照的開銷與螢幕的光線尺寸成正比,不用擔心光線所照射的物品的數量,少量光線 等價於 廉價的花費 - Consistency. All lighting for all lights is computed per-pixel; there are no lighting computations that break down on large triangles etc.
一致性,所有的光線的光照採用按畫素為計算分割單位來計算。比如,不會有在大規模三角形情況下光照計算使計算效能發生崩潰的情況發生。
Disadvantages 缺點:
- No real anti-aliasing support.
沒有實時抗鋸齒支援 - Deferred Lighting can't handle semi-transparent objects. Those are rendered using Forward Rendering.
延遲光照不能處理半透明物體,也不能用在哪些使用前向渲染的物體之上 - Limited lighting model support (Blinn-Phong). All lighting is computed the same way; you can't have drastically different lighting models on different objects.
有限的光照模式支援(Blinn-Phong)。所有光照以同樣的方式計算,你不能夠在不同的物體上採用完全不同的光照模式 - No support for "receive shadows" flag and limited support light Culling Masks.
沒有對接收陰影特徵的支援和對光線遮罩剔除有限的支援
Requirements for Deferred Lighting 延時光照的需求
- Requires Unity Pro.
需要Unity專業版 - Graphics card with Shader Model 3.0 (or later), support for Depth render textures and two-sided stencil buffer. Most graphics cards made after 2004 support it: GeForce FX and later, Radeon X1300 and later, Intel 965 / GMA X3100 and later.
顯示卡支援Shader Model 3.0(或更高),深度紋理渲染和雙面模板緩衝特性。許多2004年後的顯示卡都支援:如Geforce Fx或更高,Radeon X1300或更高 Intel 965/ GMA X3100 或更高 - Currently does not work on mobile platforms.
目前在移動平臺不支援。
Performance Considerations 效能注意事項
Cost of realtime lights in Deferred Lighting is proportional to number of pixels the light shines on; and not dependent on scene complexity. So small point or spot lights are very cheap to render. Point or spot lights that are fully or partially occluded by some scene objects get their pixels skipped on the GPU, so they are even cheaper.
延遲光照中實時光線的開銷和光線照亮的畫素值的數量成正比。而不取決於場景的複雜性。微小的點光源和聚光燈光源非常容易渲染。點光源或者完全或者部分被場景物體遮擋的聚光燈光源所照射的畫素則被GPU所跳過,因此更加廉價。
Of course, lights with shadows are much more expensive than lights without shadows. In Deferred Lighting, shadow casters still need to be rendered once or more for each shadow-casting light. And the lighting shader that applies shadows is also more expensive than one without shadows.
當然,擁有陰影的光源比沒有陰影的光源要昂貴許多。使用延遲光照,光影投射器仍然需要為每個陰影投射渲染一次或者多次。而且產生陰影的光線著色器也比不產生陰影的光線著色器要昂貴許多。
Implementation Details 實現細節
When Deferred Lighting is used, rendering process in Unity happens like this:
當延遲光照生效時,在Unity中發生的渲染過程如下:
- Base Pass: objects are rendered, producing screen-space buffers with depth, normals, and specular power.
基本渲染:被渲染的物件產生帶有深度,法線,和反射量的螢幕空間緩衝 - Lighting pass: lighting is computed using the previous buffers. Lighting is computed into another screen-space buffer.
光照渲染:使用上一步的緩衝計算出光照。結果放入另一個螢幕空間快取 - Final pass: objects are rendered again. They fetch computed lighting, combine it with color textures and add any ambient/emissive lighting.
最後渲染:物體再次渲染。取來已經計算好的光線和顏色紋理混合在一起,然後再加上環境光以及散射光照。
Objects with shaders that can't handle Deferred Lighting are rendered after this process is done, using RenderTech-ForwardRendering path.
不能採用延遲光照技術的帶陰影的物體在延遲光照渲染完後使用前向渲染路徑處理。
Base Pass 基本渲染階段
Base pass renders each object once. View space normals and specular power are rendered into single ARGB32 Render Texture (normals in RGB channels, specular power in A). If platform & hardware supports reading Z buffer as a texture, then depth is not explicitly rendered. If Z buffer can't be accessed as a texture, then depth is rendered in additional rendering pass, using shader replacement.
基本渲染將每個物體都渲染一次。檢視空間法線和高光強度被渲染進單一的ARGB32渲染紋理(法線在RGB通道,高光強度在A通道)中。如果平臺和硬體支援將Z緩衝按紋理讀取,那麼深度不會被明確的渲染。如果Z緩衝不能被以紋理的方式訪問,那麼深度將在額外的渲染處理中被使用著色器替代技術渲染。
Result of the base pass is Z buffer filled with scene contents and Render Texture with normals & specular power.
基本渲染的結果是被螢幕內容填滿的Z緩衝和帶有法線和高光強度的渲染紋理。
Lighting Pass 光照渲染階段
Lighting pass computes lighting based on depth, normals and specular power. Lighting is computed in screen space, so it's independent of scene complexity. Lighting buffer is single ARGB32 Render Texture, with diffuse lighting in RGB channels and monochrome specular lighting in A channel. Lighting values are encoded using logarithmic encoding to provide extended dynamic range than usually possible with ARGB32 texture.
光照渲染基於深度,法線和高光強度計算光照。光照是被螢幕空間被計算的,因此和螢幕複雜性無關。光照緩衝是一個單一的ARGGB32渲染紋理,紋理的RGB通道帶有漫反射的光照資訊,在A通道帶有單一特定顏色的光照。光照值採用對數值編碼以產生比通常ARGB32紋理所能達到的動態擴充套件範圍。
Lighting model is fixed to Blinn-Phong.
光照模式固定為Blinn-Phong。
Point and Spot lights that do not cross camera's near plane are rendered as 3D shapes, with Z buffer test against scene enabled. This makes partially or fully occluded Point and Spot lights very cheap to render. Directional lights and Point/Spot lights that cross the near plane are rendered as fullscreen quads.
不能跨越臨近平面的點光源和聚光燈光源被作為帶有開啟測試場景的Z緩衝3D形狀渲染,這部分和完全遮蔽的點光源和聚光燈光源可以非常廉價的渲染。 跨越臨近區域的平行光或者點光源能作為全屏四邊形。
If a light has shadows enabled, they are rendered and applies in this pass as well. Note that shadows are not "free"; shadow casters need to be rendered and a more complex light shader needs to be applied.
如果一個帶有陰影的光源生效,在這個處理過程中會被很好的渲染。注意陰影並不免費,陰影投射器需要開銷來渲染,同時一個更加複雜的光線著色器需要應用。
Final Pass 最後渲染階段
Final pass produces final rendered image. Here all objects are rendered again; with shaders that fetch the lighting, combine it with textures and add any emissive lighting.
Lightmaps are also applied in the final pass. Close to the camera, realtime lighting is used, and only baked indirect lighting is added. This crossfades into fully baked lighting further away from the camera.
最終渲染階段產生最後渲染後的影象,到這一步,所有的物件都將被再次渲染,其中著色器將混合前一步生成的光源和紋理以及所有自發光照明。
在最後渲染階段光照貼圖也被應用。靠近相機,使用實時光照,並僅烘焙間接光照。
其他:lightingmap 烘焙貼圖不在及時光的技術範圍內。烘焙燈光是通過貼圖記錄光照資訊來模擬固定的光照效果,場景中本身不包含及時燈光。
Rendering Paths Comparison 渲染路徑比較
Deferred Lighting 延時光照 | Forward Rendering 正向渲染 | Vertex Lit 頂點光照 | |
Features 功能 | |||
Per-pixel lighting (normal maps, light cookies) 每畫素計算光照(法線貼圖、燈光cookies) | Yes | Yes | - |
Realtime shadows 實時陰影 | Yes | 1 Directional Light(一盞平行光) | - |
Dual Lightmaps 雙光照貼圖 | Yes | - | - |
Depth&Normals Buffers 深度與法線緩衝區 | Yes | Additional render passes 額外渲染通道 | - |
Soft Particles 軟粒子 | Yes | - | - |
Semitransparent objects 半透明的物體 | - | Yes | Yes |
Anti-Aliasing 抗鋸齒 | - | Yes | Yes |
Light Culling Masks 燈光剔除蒙板 | Limited | Yes | Yes |
Lighting Fidelity 光照保真度 | All per-pixel 全部畫素 | Some per-pixel 某些畫素 | All per-vertex 所有頂點 |
Performance 效能 | |||
Cost of a per-pixel Light 每畫素光照的花費 | Number of pixels it illuminates 照亮的畫素數 | Number of pixels * Number of objects it illuminates 畫素數*照亮的畫素數 | - |
Platform Support 支援平臺 | |||
PC (Windows/Mac) 桌上型電腦 | Shader Model 3.0+ | Shader Model 2.0+ | Anything |
Mobile (iOS/Android) 移動裝置 | - | OpenGL ES 2.0 | OpenGL ES 2.0 & 1.1 |
Consoles (遊戲)平臺 | 360, PS3 | 360, PS3 | - |
相關文章
- LIBGDX遊戲引擎平臺介紹與搭建遊戲引擎
- 蟻群演算法介紹(以TSP問題為例)演算法
- 遊戲中的意識流(下)——以Supercell系列遊戲為例遊戲
- 遊戲中的意識流(上)——以Supercell系列遊戲為例遊戲
- 如何使用遊戲引擎進行實時渲染和內容建立遊戲引擎
- 實時渲染KeyShot Pro 新功能介紹
- 三大主流前端框架介紹及選型方法前端框架
- JDK中內嵌JS引擎介紹及使用JDKJS
- python遊戲引擎ppb介紹(2)精靈、場景與座標Python遊戲引擎
- 【CameraPoseRefinement】以BARF為例介紹三維重建中的位姿最佳化
- Lombok介紹及使用方法Lombok
- 以畫素風遊戲為例,分析戲劇性畫面的營造遊戲
- 莉莉絲遊戲引擎渲染專家凱丁:從MMO到獨立遊戲,再到引擎技術遊戲引擎
- CSRF簡單介紹及利用方法
- 大型專案研發經驗分享:以3A遊戲為例遊戲
- 開發者以Band of Defenders為例談遊戲的系統建造遊戲
- systemctl介紹,以influxdb為例把可執行檔案新增到systemctl的實驗UX
- python3切片使用方法及一些技巧介紹+leetcode題例PythonLeetCode
- 以《劍與遠征》為例,淺析新型掛機放置遊戲的遊戲特色特點遊戲
- Unity3D 5.6 剛體的介紹,---rigidbodyUnity3D
- Shodan搜尋引擎介紹
- 搜尋引擎框架介紹框架
- tcpdump抓包及tshark解包方法介紹TCP
- MongoDB Sharding Balancer介紹和設定方法舉例MongoDB
- 關於遊戲中的實時渲染遊戲
- 2024 OEGC巨量引擎遊戲大會:展望未來遊戲增長新引擎GC遊戲
- Scrapy 框架介紹之 Puppeteer 渲染框架
- 為什麼基本型別可以呼叫方法——以字串為例型別字串
- 簡單介紹Lua中三種迴圈語句的使用
- 遊戲心理學研究:以《博德之門3》為例,淺談遊戲中的閱讀體驗遊戲
- 遊戲與遊戲引擎遊戲引擎
- 前端跨域有哪些種方法及介紹?前端跨域
- ArrayList相關方法介紹及原始碼分析原始碼
- 四種大資料分析方法介紹!大資料
- 14.1 InnoDB 儲存引擎介紹儲存引擎
- 全景光照在遊戲中的應用遊戲
- 以企業級實時資料平臺為例,瞭解何為敏捷大資料敏捷大資料
- Rust Vulkan 逐幀渲染流程介紹Rust
- 如何介紹你的遊戲,以使玩家覺得遊戲很酷?遊戲