多光源有幾個思路：
1.Uber Shader，這是比較常見的做法，就是把所有的光照計算合併成一個大的shader，最後點光源，平行光源，聚光燈全部在這個shader裡處理，缺點是一個pass裡要處理的內容非常多，而且一旦光照條件發生變化（比如添加了新的光源或者某個光源被剔除），則需要重新編譯該shader，當然一般而言遊戲引擎裡shader都會預編譯快取的，這是three.js和babylonJS等引擎的常見做法，鑑於Uniform數量有硬體限制等，Uber Shader一般也會潛在地限制最大光源數量
2.Z-Prepass加多次遍歷，這個方法的好處是比較靈活，早期在idSoftware的引擎裡有應用，簡單地說就是先關閉color attachment的寫入（單純寫depth attachment要快2-4倍），只寫一個簡單的深度pass，然後有了深度，再關閉深度寫入進行正常的光源遍歷，找出每個物體的光源列表，然後每盞光源以模型為幾何體執行一次光照計算（blend mode設定成add,one,one），最終把結果疊加起來，缺點是隨著物體的增加draw call會大幅增加（儘快很多會被early z culling）
3.Deferred Rendering，這是近年來PC遊戲引擎的主流做法，先繪製一個GBuffer，把光照計算需要的所有資訊先寫進texture，然後用光源的包圍盒進行光照計算，一盞燈一個pass，但是不再區分物體，優點是光照計算量和場景複雜度無關（只和光源數量相關），缺點是GBuffer的繪製比較慢，需要消耗大量的頻寬（早期也有很多引擎在努力減小這個部分的開銷，這兩年對GBuffer的壓縮倒是比較少了，畢竟顯示卡越來越好了，但在移動平臺上仍然會有效能問題），初次外延遲渲染一般來說需要multiple render target的支援（雖然沒有也能做，但是效率會很差）
近年來也有很多針對z-prepass和deferred rendering繪製管線的變種，包括了deferred lighting（把光照和最終著色進一步拆分開），forward+, tile-based deferred rending， clustered shading（把GBuffer/ShadingBuffer分塊，每塊單獨和燈光列表求交，進一步提高燈光的剔除效率並且省掉燈光包圍盒的draw call）
多光源有幾個思路：
1.Uber Shader，這是比較常見的做法，就是把所有的光照計算合併成一個大的shader，最後點光源，平行光源，聚光燈全部在這個shader裡處理，缺點是一個pass裡要處理的內容非常多，而且一旦光照條件發生變化（比如添加了新的光源或者某個光源被剔除），則需要重新編譯該shader，當然一般而言遊戲引擎裡shader都會預編譯快取的，這是three.js和babylonJS等引擎的常見做法，鑑於Uniform數量有硬體限制等，Uber Shader一般也會潛在地限制最大光源數量
2.Z-Prepass加多次遍歷，這個方法的好處是比較靈活，早期在idSoftware的引擎裡有應用，簡單地說就是先關閉color attachment的寫入（單純寫depth attachment要快2-4倍），只寫一個簡單的深度pass，然後有了深度，再關閉深度寫入進行正常的光源遍歷，找出每個物體的光源列表，然後每盞光源以模型為幾何體執行一次光照計算（blend mode設定成add,one,one），最終把結果疊加起來，缺點是隨著物體的增加draw call會大幅增加（儘快很多會被early z culling）
3.Deferred Rendering，這是近年來PC遊戲引擎的主流做法，先繪製一個GBuffer，把光照計算需要的所有資訊先寫進texture，然後用光源的包圍盒進行光照計算，一盞燈一個pass，但是不再區分物體，優點是光照計算量和場景複雜度無關（只和光源數量相關），缺點是GBuffer的繪製比較慢，需要消耗大量的頻寬（早期也有很多引擎在努力減小這個部分的開銷，這兩年對GBuffer的壓縮倒是比較少了，畢竟顯示卡越來越好了，但在移動平臺上仍然會有效能問題），初次外延遲渲染一般來說需要multiple render target的支援（雖然沒有也能做，但是效率會很差）
近年來也有很多針對z-prepass和deferred rendering繪製管線的變種，包括了deferred lighting（把光照和最終著色進一步拆分開），forward+, tile-based deferred rending， clustered shading（把GBuffer/ShadingBuffer分塊，每塊單獨和燈光列表求交，進一步提高燈光的剔除效率並且省掉燈光包圍盒的draw call）