- 渲染管線
目前繪製總共有光柵化和光線追蹤（Ray Tracing)兩種主流方式。
-
- 光柵化
將3D模型的三角形轉換爲2D屏幕上的像素或者點。對這些像素作進一步處理或“着色”，最後將其顯示在屏幕上。
優點：渲染速度比光線追蹤快很多
侷限：處理陰影相對於光線追蹤的自然而言的生成陰影顯得不直觀，真實感不強，並且需要很多運算。另外，光柵化並非基於對物理光線的追蹤計算，對現實複雜的光照效果的就無能爲力了，比如無法做反射和折射，和陰影等物理現象
-
-
- GPU Rendering Pipeline繪製管線/渲染管線
-
輸入：Scene objects, Light Sources, Cameras, Program object( shaders for programmable pipeline stage）
輸出：pixels stored in framebuffer（幀緩衝中的像素值）
- 傳統OpenGL渲染管線（不一定能用到）：
頂點着色器->形狀(圖元）裝配->幾何着色器->光柵化->片段着色器->Alpha測試與混合
頂點着色器：以一個單獨的頂點作爲輸入，把3D 物體座標座標轉化爲裁剪座標(待考證），以及允許我們對頂點屬性進行一些基本處理。
圖元裝配：將頂點着色器輸出的所有頂點作爲輸入，並將所有的點裝配成指定圖元的形狀
幾何着色器：把圖元形式的一系列頂點的集合作爲輸入，可以通過產生新頂點構建新的圖元來生成其他形狀
光柵化：將幾何圖元映射到屏幕上相應的像素，生成供片段着色器使用的片段，在片段着色器之前會進行裁剪，丟棄掉視圖以外的像素，提升執行效率
片段着色器：片段着色器爲幾何中的每個片段運行。工作是確定每個片段的最終顏色。
Alpha測試與混合:這個階段檢測片段的對應的深度（和模板(Stencil)）值，用它們來判斷這個像素是在其它物體的前面還是後面，決定是否應該丟棄。這個階段也會檢查alpha值（透明度）並對物體進行混合(Blend)。所以，即使在片段着色器中計算出來了一個像素輸出的顏色，在渲染多個三角形的時候最後的像素顏色也可能完全不同。
- 完整openGL渲染管線：
![]()
Vertex Specification(頂點規範）：應用程序設置頂點的有序列表併發送到管道，提交頂點數據需要創建一個頂點流，然後告訴GPU如何解釋該流
頂點流：流數據定義頂點數據
原始：解釋頂點流的方式
Vertex Shader:以一個單獨的頂點作爲輸入，把3D 物體座標座標轉化爲裁剪座標(已考證），輸入頂點與輸出頂點1：1映射，以及允許我們對頂點屬性進行一些基本處理。但必須輸出頂點的位置
Tesselation:可選階段，圖元被細分，劃分更加平滑的三角網格。有兩個shader以及一個固定功能階段組成（Tesselation Control Shader/Tesselation evaluation shader , Tesselation primitive generator) (細分控制着色器/細分估計着色器， 細分圖元生成器）
Geometry shader:可選階段，輸入圖元，輸出零個或者多個圖元（可以生成新的幾何圖元）
Vertex Post_processing(頂點後處理）：固定功能階段，主要經歷以下步驟：1.Transform feedback:將頂點處理階段輸出的值記錄到緩衝區對象中2.裁剪：收集先前階段生成的圖元，然後裁剪到視錐體中 3.透視分割：將剪輯空間位置轉換爲NDC 4.視口轉換：將NDC座標轉換爲窗口空間。
主要功能是Clippling，裁剪丟棄掉視錐體之外的圖元：
圖元裝配：同上（傳統opengl)，收集先前階段輸出的一系列頂點數據，並將其組合成一系列圖元；face剔除:可以根據窗口空間中三角形的朝向來選擇三角形圖元,避免渲染揹着視點的三角形圖元
光柵化：將圖元轉化爲多個片段，以及通過頂點屬性插值得到片段的屬性
幾何着色器：每個片段都有以窗口座標，以及其他通過插值得到的屬性值，輸出（深度值，模板值，零個或者多個顏色值），工作是確定每個片段的最終顏色。
Per_Sample Operations:對片段進行Pixel ownership test , Scissor test, Stencil test, Depth test.最後進行Color blending.將片段寫進framebuffer.
- 簡化三階段：應用階段、幾何階段、光柵化階段
應用階段
在CPU中執行，一個在應用程序階段的算法通常可以減少被渲染的三角形數量。在應用程序階段的最後，將被渲染的幾何數據輸入到幾何階段。此外，碰撞檢測、動畫、變形等通常也可以在應用階段執行。
幾何階段
可以被細分爲如下幾個功能階段：模型/視點變換、頂點着色、圖元裝配、投影、剪裁、屏幕映射等，經過幾何階段變換且投影過的頂點以及它們相關的着色數據輸入到光柵化階段。
光柵化階段
可分爲：建立三角形階段、遍歷三角形階段、像素着色階段以及融合階段。光柵化階段對所有剪切區域內的圖元生成片元數據，然後對每個生成的片元都執行一個片元着色器，最後經過深度測試等逐片元操作後被顯示到屏幕窗口上。
-
-
- 座標系統和座標變換
-
- 局部空間座標系/物體空間座標系：對象所在的座標空間
- 世界空間座標系：一個全局的座標。所有的物體/模型需要經過旋轉、平移、縮放從局部世界座標轉換到世界空間座標。
- 攝像機/觀察空間/視點座標系：從攝像機的視角所觀察到的空間，包括平移/旋轉
- 裁剪座標系：通過投影矩陣將指定的座標範圍以內的座標轉換成裁剪空間內的座標，在[-1, 1]範圍內，同時範圍以外的座標將被轉換成[-1, 1]以外的座標，從而被裁剪掉。
- 標準化座標系
- 屏幕座標系：即每個像素點的座標，它是由視口變換得來的。
座標變換：物體座標系通過模型變換（modeling transformation，位移、縮放、旋轉）到世界座標系，世界座標系通過視點變換（viewing transformation）到攝像機/視點座標系，視點座標系通過投影變換（projection transformation）到裁剪座標系，透視除法，進入NDC座標系（標準化設備座標系），目的是將座標值控制在-1到1之間，再通過視口變換（viewport transformation）將座標轉換到屏幕二維座標。
-
-
- 齊次座標系優勢
-
- 使用齊次，可以將三維空間一個點和其方向區別開，例如(1,1,1)在三維中可能表現在一個點 或者一個方向，但是在齊次中，可以會用w進行表現，如果w爲非零表示點，w爲零表示方向 （表示點和方向方便）
- 有齊次後，對物體做任何的干預變換，任何的仿射變換（平移旋轉縮放透視投影）都可以通 過矩陣乘向量的方式計算，如果是三維，操作可能就有很多個，例如平移是矩陣加向量，旋轉 是矩陣乘向量（可以做預計算）
- 光線追蹤
- 主要思想：從視點向成像平面上的像素髮射光線，找到與該光線相交的最近物體的交點，如果該點處的表面是散射面，則計算光源直接照射該點產生的顏色；如果該點處表面是鏡面或折射面，則繼續向反射或折射方向跟蹤另一條光線，如此遞歸下去，直到光線逃逸出場景或達到設定的最大遞歸深度。
- 侷限：通常將每條光線當作獨立的光線，需要每次都要重新計算，現有計算資源，無法實現
- 升級版：路徑追蹤：從視點發出一條光線，光線與物體表面相交時，根據表面的材質屬性繼續採樣一個方向，發出另一條光線，如此迭代，直到光線逃逸出場景或達到設定的最大遞歸深度。然後用蒙塔卡洛方法，計算光線貢獻，作爲顏色值。
簡短： 路徑追蹤 = 光線追蹤 + 蒙特卡洛方法
-
-
- Ray tracing pipeline on GPU
-
- GPU device code(也叫”shader”,着色器)
顯卡上執行的程序在圖形學中叫着色器，CUDA也是執行在GPU上的，叫kernel
進行光線跟蹤需要有五個shader,這五個shader都是執行在GPU上面的，分別是：
Ray generation shader:生成光線
Intersection shader:光線和平面求交
Miss shader:如果光線和場景沒有求到交點應該進行什麼操作
Closet-hit shader:如果光線和物體求到最近的交點之後應該進行什麼操作
Any-hit shader:光線和物體任何求到任何一個交點之後應該進行什麼操作
- CPU host code(也叫 graphics API)
首先由ray generation shader生成光線，遍歷場景，由intersect shader進行找到光線與幾何物體相交進行相交測試，若找不到最近的相交加速結構或者沒有相交，則重新進行相交測試，當找到最近的交點，使用is opaque（一種內置結構）判斷是否透明，若不是則爲需要節點跳到[2]，若透明使用any hit shader判斷交點是否要使用)，若不需要該點則重新相交測試，否則跳到[2]
[2]在這個交點使用closet-hit shader(這個shader是光線的屬性，每個光線有不同的closet-hit shader)，如果光線與所有幾何物體不相交，那麼執行miss shader（該shader由指定的每根光線）
-
- 加速結構
主要包括基於空間的劃分和基於物體的劃分方式
- 基於空間的劃分（存在的問題：如果一個物體屬於不同節點，如何處理）
一個物體可能屬於多個子空間。四叉樹、八叉樹、kd樹，BSP(Binary Space Partition)，主要應用在KNN Search或ray tracing，也可以用於碰撞檢測/鄰域搜索
四叉樹、八叉樹：每次劃分過程都對空間進行均勻的四(或八)等分，不考慮物體的分佈
優點：劃分簡單，算法複雜度低，建樹快(四叉樹用於二維空間、八叉樹用於三維空間)
缺點：沒有考慮物體的分佈，物體在子空間中的分佈不均勻，查找效率較低，在建樹完成後樹中會有很多空節點，浪費空間
kd樹（重點）：進行空間劃分時，可以自由選取劃分軸、劃分位置以及終止條件。一般根據物體的分佈來進行空間劃分
優點：可以根據物體的分佈來進行空間劃分，物體在空間中的分佈較均勻查找效率高
缺點：劃分過程考慮因素多，算法效率較低，建樹慢，更新代價高
BSP樹：二叉空間分割樹，是一種常用來判別對象可見性的空間數據結構，每個節點表示一個有向超平面，將當前空間劃分爲前向和背向兩個子空間，與kd樹類似，但劃分軸可以不垂直於座標軸，也不關心面的位置在什麼地方，只要能夠把空間劃分成兩個子空間
優點：比kd樹更靈活，查找效率更高
缺點：劃分過程還需考慮劃分軸的方向，算法效率低，建樹慢，更新代價高
總結：KD樹與BSP樹的建樹耗時大，使得這兩種方法都不適合動態場景
- 基於物體的劃分
空間之間可能有重疊。包圍球、AABB、OBB、凸包、BVH（BB(Bounding Box)=BV(Bounding Volume)
包圍球：使用球體來包圍物體
優點：相交測試快，當物體發生旋轉時，不需要更新
缺點：包圍緊密度低，當物體發生形變時，需要重新計算
AABB（重點）： Axis Aligned Bounding Box，使用平行於座標軸的長方體來包圍物體
優點：是座標軸對齊的包圍盒，相交測試快，當物體發生形變之後，僅需對變形了的基本幾何元素相應的包圍盒再計算一次
缺點：緊密性較差，對傾斜對角方向放置的瘦長型對象，會留下非常大的邊角空隙，導致大量不必要的包圍盒相交測試，不能隨物體旋轉
OBB：使用不一定平行於座標軸的長方體來包圍物體，與AABB不同的是，它不一定平行於座標軸，由物體的幾何特點來決定它的朝向
優點：緊密性較好，可以大大降低參與相交測試的包圍盒的數目，整體性能優於AABB和包圍球，當物體發生旋轉運動後，僅需對OBB進行相同的旋轉
缺點：計算複雜，重建代價較大
凸包：使用凸幾何體來包圍物體
優點：緊密性非常好
缺點：相交測試非常複雜，計算代價大，凸包計算很難，碰撞檢測很難。
BVH（重點）：層次包圍盒/體，核心思想：用體積略大而幾何特徵簡單的包圍盒來近似地描述複雜的幾何對象，進一步提高求交效率。常用於層次視錐體裁剪，整個物體是根節點，依次迭代地將物體二等分放入左右孩子節點當中，樹中所有節點都使用包圍球。樹中同一層的所有包圍盒集合起來與整個物體的形狀類似
優點：緊密性好，相交測試快，相比於kd樹更新速度快
缺點：計算代價大
總結：使用BV的準則/目標：
1.包圍核應把物體包的越緊越好
2.包圍核更新代價越低越好
3.包圍核在做碰撞檢測的時候，計算過程儘量簡單
-
-
- 採樣問題-走樣
-
光線追蹤屬於點採樣，每個像素投射一條光線，引發走樣失真
解決方法：超採樣（supersampling),儘可能多采樣，使用平均結果（可以降低反走樣，但不能消除它）
- 均勻採樣
優點：所有區域都能被均勻採集到
缺點：存在不必要的採樣
- 隨機採樣
優點：隨機生成樣本，避免了均勻採樣的規律性
缺點：有些區域存在不必要的採樣，有些必要採樣的區域可能沒有采樣到，不可控
- 泊松採樣
優點：產生隨機的樣本，兩兩樣本之間不會太近
缺點：耗時相對更長
- 自適應超採樣
優點：不需要超採樣所有的像素，採樣在邊角和中心，能夠有效地減少走樣
缺點：耗時長
- Jittered採樣：將像素分成網格，在每個網格內使用泊松採樣
沒有提高採樣率，但移除了規律性
- 反走樣技術
-
- 產生走樣原因
-
如果在數學上想要避免走樣，那麼採樣必須滿足奈奎斯特（Nyquist）採樣定理（如果想重建原始圖像，採樣頻率應該是採樣信號最大頻率的2倍之上），才能在數學上有可能把原始的信號完美地重建出來。而圖形學上常使用點採樣（用點採樣渲染場景就不可能避免反走樣問題），本身就不能夠滿足奈奎斯特採樣定理，所以圖形學上有很多反走樣的方法。
簡單點：（重建與採樣頻率不匹配，採樣頻率太低）
造成走樣的兩個主要原因有：1、對幾何函數的採樣不足，也就是常見的邊緣鋸齒（也叫幾何走樣），一般發生在光柵化階段。2、對渲染方程的採樣不足，因爲渲染方程也是一個連續函數，對某些部分（比如法線，高光等）在空間變化較快（高頻部分）採樣不足也會造成走樣，反映在視覺上一般是圖像閃爍或者噪點，這類稱之爲着色走樣（Shading Aliasing），一般發生在着色階段。
-
-
- 反走樣方法
-
基於幾何的反走樣方法，分爲三類：基於屏幕的反走樣方法（基於超採樣的反走樣方法）、基於時間的反走樣方法（Temporal antialiasing,TAA） 、基於形態學的反走樣方法。
基於屏幕的反走樣方法：
SSAA（Supersampling Anti-Aliasing）超級採樣反走樣方法：通過以更高的分辨率來採樣圖形，然後再顯示在低分辨率的設備上，從而減少失真。
特點：提高了存儲空間和計算量，代價昂貴，但簡單，高質量
MSAA（Multi-Sampled Anti-Aliasing）多采樣反走樣方法：是對SSAA的改進，改進之處在於執行片元着色器的次數並沒有明顯增加，對邊緣部分卻進行了很好的反走樣，隨機採樣。對於每個像素，不要僅用一箇中間點來判斷三角形是否覆蓋，而是取4個頂點來分別判斷：
基於時間的反走樣方法：將樣本分散到多個幀中
基於形態學的反走樣方法：MLAA（Morphological antialiasing）形態抗鋸齒
簡單總結：對於靜態場景可以用歷史數據，動態場景利用Motion Vector來使用歷史幀
-
-
- 走樣的場景
-
紋理映射 光線追蹤 shadow map
- 光照
- 微表面模型
眼睛上看起來光滑的平面，實際上是由很多微小的平面構成，這些微小的平面對於光的波長來說是不平的。但是每一個微小的平面，對於光的波長來說，是一個絕對光滑的平面，即完美地符合反射定理。所以對於每一個微平面來說，一束入射光會在微平面反射形成反射光或進入介質形成折射光。而對於整個宏觀的平面來說，一束入射光被反射出來的光就有了不同的朝向，就產生了反射的光；而進入物體的折射光，在物體內部進行多次反射後從某一點反射出物體的表面，就產生了次表面散射的光
specular、diffuse、次表面散射形成的原理：
- specular：入射光在表面直接反射的光
- diffuse：入射光在表面經摺射、吸收、散射、多次反射而形成的光
- 次表面散射：在某一個點入射的光，折射進入物體內部後經多次反射從物體表面的另一個點反射出來的光
- 輻射度量學
Radiant flux (Ф, 輻射通量): flow of radiant energy over time (unit: W)
Irradiance (E = d Ф/d A, 輻射照度): density of radiant flux with respect to area (unit: W/m2)
Radiant intensity (I = d Ф/d ω, 輻射強度): flux density with respect to solid angle (unit: W/sr)
Radiance (L = d2 Ф/dAd ω, 輻射亮度): density of radiant flux with respect to both area and solid angle (unit: W/(m2sr))
f(l,v) = radiance/Irradiance
-
- BRDF
定義：雙向反射分佈函數 ，定義爲出射輻射率的微分（differential outgoing radiance）和入射輻照度的微分（differential incoming irradiance）之比，描述了入射光線經過某個表面反射後如何在各個出射方向上分佈，給定了入射方向和出射方向能量的相對量
1.對於給定的方向，BRDF給出了來自每個入射方向的光對出射光的相對貢獻。
2.給定一束來自某個方向的光線，BRDF給出了反射光和散射光在表面上所有出射方向上的相對分佈。
BRDF描述了兩種不同的物理現象
表面反射－鏡面反射 次表面散射－漫反射
BRDF模型分爲兩大類
- 經驗模型（簡單的、常用於實時渲染、朗伯特模型、馮氏模型）
- 基於物理的模型:
Lambertion（朗伯特模型）：用作理想的漫反射模型（光均勻的反射到各個方向）。
馮氏模型：從物體上的一點發射到觀察者眼睛的光能包括三個部分：環境光、漫反射、高光反射。
-
- 直接光照與間接光照（全局光照）
全局光照（直接光照+間接光照）：考慮環境中所有物體表面和光源相互作用的照射效果，模擬真實光照規律，真實感強，計算代價高
直接光照：只考慮光源到物體表面的照射效果，物體表面的顏色只由它本身的材質/位置/光屬性等影響，不能產生陰影和多重反射效果，真實感弱，計算代價低
-
- 延遲渲染Deferred Rending/Shadering
在出現延遲渲染之前，已經出現的渲染方法：
- per-vertex shading：在per-vertex shading中，光照計算髮生在三角形圖元的頂點處，即光柵化錢的vertex shader中。在光柵化之後，片元的顏色值由三角形圖元的三個頂點的顏色值經過差值得到。
優點：優於頂點數量少，故其計算量小
缺點：在vertex shader中計算光照，通過光柵化之後得到的是線性插值後的光照效果，而實際上光照效果應該是非線性的，所以得到的結果不夠真實。
- per-pixel shading：在per-pixel shading中，光照計算髮生在光柵化後生成的每個片元上，即光柵化之後的fragment shader中。
優點：把光照計算放在片元中，而不是差值生成，保證光照正確。
缺點：在fragment shader中是對場景中的所有片元都盡心光照計算，而物體之間存在遮擋關係，最終顯示在屏幕上的只有離屏幕最近的片元，被遮擋的片元無法通過深度測試而被拋棄，這部分多餘的光照計算導致計算資源的浪費。
- 延遲渲染（兩個pass過程）
幾何處理階段：先對場景進行渲染，然後將能通過深度測試的片元信息存儲在G_buffer中；
光照處理階段: 只需渲染出一個屏幕大小的二維矩形，使用第一步在G_Buffer中存儲的數據對每個片段計算場景的光照
優點：1.只渲染可見的片段，節省計算量 2.將光源的數目和場景中的物體的數目在複雜度上完全分開，可以處理大量的光源，保持一定幀率，降低複雜度
缺點：1.G_Buffer保存了多個紋理，內存開銷大 2.讀寫G_buffer的內存帶寬是性能瓶頸
3.透明物體渲染不能解決 4.對多重採樣抗鋸齒MSAA支持不友好
改進方向：1.最小化G_Buffer結構（Light Pre_Pass) 2.分塊延遲渲染（Tile_Based Deferred Rendefing
- 高級紋理
- 紋理映射Texture Mapping（增加顏色質量）
思想：用少量的信息表示複雜的幾何表面信息
特性：1.複用性 2.向GPU傳輸少量數據，讓其儘可能多運算
問題：紋理走樣（紋理分辨率低或者紋理分辨率高會出現的問題）也可以說是像素的大小和紋素的大小不匹配引發的問題/
解決方法：
1.若紋理過小（分辨率低，像素大小<紋素大小），會導致走樣失真（屏幕空間的幾個像素點對應在紋理貼圖的座標上都是集中在一個像素大小之內），通過雙線性插值解決
2.若紋理過大（分辨率高，像素大小>紋素大小（屏幕空間的一個像素對應了紋理貼圖上的一片範圍的點））， 反採樣會很麻煩，其實就是欠採樣：
- Supersampling：一個像素內多采集樣本點
- 通過Mip-map =>目的：將像素大小大於紋素的大小反轉成像素大小小於紋素情況
基本思想（方法）：提前對紋理進行濾波，相當於低通濾波器(把高頻過濾）
-
- 高級紋理映射技術Model geometry：增加渲染質量
- BumpMap ：Bump技術通過一張稱爲高度圖的灰度圖來存儲物體表面每一點（像素）的高度信息，在對物體表面某一點（像素）進行光照計算前，先在高度圖中查找與該表面位置相對應的高度，然後根據高度信息重新計算該點處的法線向量，最後對這一點進行光照計算。
缺點：1.只能用於漫反射表面，不能表現鏡面高光
2.沒有改變物體幾何信息，因此物體邊緣並不會有凹凸效果
- Normal Map 將物體表上面的法線信息以X,Y,Z的形式代替RGB值存儲在紋理中，根據物體法線貼圖中的法線向量來進行光照計算。
優點：法線貼圖要快得多，消耗的資源也更少，因爲幾何圖形不變。
缺點：1.法線貼圖的主要限制是，它只會擾動表面的法線，物體邊緣不會有凹凸效果
2.當視角接近平行時，無凹凸感（Bump Mapping也是）
（保存低分辨率的模型，通過高分辨率的法線貼圖擾動，得到高分辨率模型）
- Parallax Mapping：根據觀察方向和高度貼圖修改紋理座標，使一個fragment的表面看起來比實際的更高或者更低（同法線貼圖一樣，區別是除了存儲法線信息，還存儲了與之對應的BumpMapping高度圖）
缺點（和NormalMapping一樣）：1.當視角接近平行時，無凹凸感 2.邊緣仍是平滑的:
優點：會根據視角調整紋理映射的偏移，從而產生遮擋效果。 - DisplacementMapping 類似於法線貼圖，位移貼圖的每一個紋素中存儲了代表對應頂點的位移的向量。根據Displacement Mapping中採樣的結果，對頂點高度進行移位，真正改變了頂點信息，由此產生凹凸效果。
優點:能產生真正得凹凸表面，這是邊緣和陰影也是凹凸的。
缺點：平面必須由很多頂點組成才能獲得真實感，由此將帶來巨大的計算量，增加負荷。
總結：BumpMap和Normal Map最大的缺點：在物體的邊緣部分是看不到真正的凸起（無法做自遮擋，自陰影）無法得到突起的陰影
-
- Shadow Mapping（陰影貼圖）
基本原理：確定場景中某個着色點是否對視點可見，在光源下不可見。
基本流程：兩次渲染
- 將場景的深度值預先渲染到以光源位置爲原點、光線發射方向爲觀察方向的投影座標系中，形成深度紋理。
2、再次渲染場景的過程中，將每個片段（像素）變換到前述眼座標系中，並縮放到[0，1]的範圍內以便查詢紋理。
3、以當前片段在眼座標中的S、T座標查詢深度紋理獲得深度值，將此深度值與當前片斷的Z座標進行比較，若Z座標大於深度值，則當前片斷在陰影中；否則不在。
存在問題：
- 走樣問題（採樣率不足）：原因：shadow mapping還是基於texture mapping技術,會遇到與之相同的走樣問題（看紋理映射）
- 深度比較時的問題（精度問題）：原因：深度紋理的分辨率有限
- 整個場景需要繪製兩遍，很耗時的操作
- 硬陰影和軟陰影
- 硬陰影：陰影是半影和全影組成，當光源爲點光源時，就不會存在半影，這種陰影就稱爲硬陰影，現實中，光源都是有大小的，不錯在硬陰影，，但在圖形學中很常見1.陰影要麼在內部或在外部 2.由點光源生成(本影3.實踐中不存在，但易產生
- 軟陰影：當光源時面光源或體光源時，會存在半影和全影,更加現實和普遍
- 幀緩衝
幀緩衝由像素的矩形陣列組成，每個像素都可以在圖像的該點上顯示一個很小的顏色正方形，主要有：顏色緩衝 深度緩衝 模板緩衝（Stencil buffer)
顏色緩衝主要存儲每一個像素的RGB顏色值，同時也可能存alpha值。多個顏色緩衝可能存在一個幀緩衝中
深度緩衝：存儲每個像素的深度值，其取值範圍爲[0，1],使用深度值可以用於深度測試，遮擋剔除，模擬透明物體，混合圖片等
模板緩衝：存儲模板，用於模板測試
幀緩存目的：記錄當前所看到的最近的片元
方式：存儲片元，發現有更近的，放入，已有的，拋棄
- 敏捷開發總結
基本思想：敏捷開發以用戶需求爲核心，採用迭代、循序漸進的方法進行軟件開發。
將軟件開發週期分爲若干個迭代週期。每個迭代週期以實現某些用戶功能爲目標，每個迭代週期都有需求分析，架構設計，編碼和測試。通過持續交付可用軟件頻繁從用戶那裏獲得反饋，以消除各種不確定性；
自己在敏捷團隊中的不足/原因/改進：
- 前期對工作量估計不準，投點不準，任務有時需要熬夜去完成，不能對工作任務做合理拆分打包
原因：前期剛接觸項目組，對項目不瞭解，對項目困難度有了錯誤認識，忽略了項目執行過程中的一些不確定因素，對任務投點不準。另外，平時對工作日誌的記錄不是很準確，一般只是記錄個大概完成時間，造成了歷史數據失去了可靠的參考性。最後，團隊成員討論不充分，由於學生總是儘可能放寬適合自己的要求，導致團隊成員對任務投點時，只是大概說一下自己的看法理由，有時投完點就各自領任務。
改進：1.要準確詳細記錄自己的工作日誌，不能把它當成應付工作，隨便填寫，不能只把它只當成”數據“，記錄下來就要充分發揮其作用。要追求真實可靠，堅信今天你欺騙數據，明天數據也會欺騙你。
- 團隊要充分討論再投點：項目組人員能力肯定參差不齊，對任務的估計也不會完全相同，因此成員要充分討論任務的實施細節，實施難點，讓成員充分認識任務困難度，然後再獨立估計，並講述理由。爲了防止流於形式，建議有監督人員參與，對討論做記錄
- 對用戶需求理解有偏差，考慮不充分就開發，當需求改動時或結果不符合用戶的預期要求就得推倒重
原因：沒有養成基於測試用例的開發驅動習慣，拿到任務時，總想着先把功能實現了之後纔去補測試用例，這樣也違背了編寫測試用例的初衷
改進：首先養成測試用例先行的項目開發思維，及時編寫測試用例讓用戶儘可能看到最終的大概項目效果，這樣也可以提前規避風險，防止對用戶需求理解有偏差，理解有歧義，讓已做的工作付之東流。
- 項目研發進度不一致，對自己完成任務以外的其他工作了解不夠
原因：缺少一定量的工作進度彙報，大家只會對自己的工作有了解，對項目其他成員的工作知之甚少
改進：團隊是一個整體，每個項目成員都應該對項目有着一定的認識，平時，成員內部可以有個簡短的工作進度彙報，一方面起個互相監督的作用，另一方面也可以讓其他成員對你所做的工作有一定的瞭解，這樣也可以防止當成員發生改動時，工作無人能去做的局面。
總結：敏捷開發追求的不僅僅是快速，更是提前規避風險。
附加：
Scurm:敏捷是一種指導思想或開發方式,沒有明確告訴我們到底採用什麼樣的流程進行開發，在敏捷的理念下.衍生出了很多不同敏捷軟件開發方法，Scrum是敏捷開發的具體方式，起源於軟件開發項目，但它適用於任何複雜或創新性的項目。用於開發和維持複雜產品的框架 ，是一個增量的、迭代的開發過程，使用產品Backlog來管理產品需求，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱爲一個Sprint在Sprint中，從產品Backlog中挑選最高優先級的需求進行開發，挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，稱爲Sprint backlog，在每個迭代結束時，遞交潛在可交付的產品增量。
敏捷軟件開發法和瀑布法之間的區別:
1.其中之一就是質量和測試方法。在瀑布模型中，構建階段之後總是有單獨的測試階段; 但是，在敏捷軟件開發測試中，與編程相同的迭代完成。
由於測試是在每一次迭代中完成的-開發一小部分軟件，用戶可以經常使用這些新的軟件並驗證其價值。用戶知道更新後的軟件的真實價值後，可以對軟件的未來作出更好的決策。在每次迭代中進行一次價值回顧和軟件重新計劃會話 - Scrum通常只有兩個星期的迭代循環 - 幫助團隊不斷調整自己的計劃，以最大限度地提高其價值。 遵循與PDCA循環類似的模式，因爲工作已經計劃、完成、檢查（在審查和回顧中），並且任何商定的變更都會被運行。這種疊方法支持產品更甚於項目思維。這在整個開發過程中提供更大的靈活性; 而在項目中，需求是從一開始就定義和鎖定的，以後很難改變它們。迭代開發允許軟件產品根據業務環境或市場需求的變化而發展。由於敏捷軟件開發的迭代方式較短，因此與精益創業概念有着密切的聯繫。
2.敏捷開發區別於瀑布式的特徵很明顯，敏捷開發是以一種迭代的方式推進的，而瀑布模型式是最典型的 預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行，步驟 成果作爲衡量進度的方法，例如需求規格，設計文檔，測試計劃和代碼審閱等等。敏捷開發過程中，軟 件一直處於可使用狀態，它將項目分成若干相互聯繫、可以獨立運行的子項目，因此，每個階段軟件都 是可見的，客戶可以直觀的體驗並提出意見。如果按照瀑布式流程，客戶可能在簽訂開發合同3個月 後，看到的還只是各種文檔（需求文檔、設計文檔、詳細設計文檔等等），客戶心理或許會不踏實。瀑 布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以 調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。在 瀑布式開發中，需求修改的時間越靠後，成本越大，所以需求分析人員的壓力很大。由於敏捷開發是迭 代式的，，並且迭代週期較短，因此很容易相應新需求或是對舊需求的修改。瀑布式開發有很多文檔，
但敏捷開發不是沒有文檔，而是輕文檔。在敏捷開發過程中，適量的文檔還是很有幫助，有助於整理思 路，加快溝通和討論，比如概念設計文檔、架構圖、SWOT分析文檔等等，這些文檔在每個產品版本開 始之前會有產生，在每個迭代的過程中根據業務人員和市場的反饋也會有一些變更。通過實踐證明，這對產品的思路、溝通討論都非常有幫助。而且這些文檔，大多是幾頁PPT，書寫和維護工作都很小。 相比迭代式的增量開發，相同的是兩者都強調在較短的開發週期提交軟件。基於Scrum的迭代增量開 發一般會在一個比較長的一個迭代週期頻率下不斷交付，同時迭代中不允許有變化的需求，這樣就有一 些場景讓這種迭代很困難，例如緊急的技術支持、臨時增加的非常高的優先級的需求等等，另外項目的 估算非常難，導致不容易承諾。相比較，敏捷方法的週期可能更短，並且更加強調隊伍中的高度協作。 敏捷開發的原則之一是擁抱變化需求時刻在變，人們對於需求的理解也時刻在變，項目環境也在不停的 變化，因此你的開發方法必須要能夠反映這種現實，敏捷開發方法就是屬於適應性的開發方法，而非預 設性。另外，敏捷開發更適用於小型團隊，在一個辦公室工作，屬於那種通信基本靠吼的狀態，當然團 隊成員之間的交互會更方便。另外敏捷開發強調用戶（或用戶代表）要與開發團隊在一起工作，便於及 時溝通交流。重視交互也應該可以算是最明顯的區別之一。這樣還有一個好處，就是有利於團隊中知識 的迅速傳播。即使有人離開團隊，另外的人也能完成相應的工作。因此，“人與交互”被列爲敏捷開發價
值觀之一，並排在第一位。
瀑布模型：瀑布模型的線性特徵也是它問題的根源。瀑布模型總是試圖做好一件事情之後才做下一件事，但是錯誤 是不可避免的。可以看出，在整個開發過程中，只有在最後的部署階段才能讓客戶看到這個軟件。而通 常需求分析階段是最容易出現錯誤的階段，所以很可能最開始的錯誤會一直流傳到最後纔會被發現，這 意味着我們必須要更改所有的活動以求改正錯誤，同樣的問題還會出現在需求變更時。 增量模型問題：在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的 能力大大優於瀑布模型和快速原型模型，但也很容易退化爲邊做邊改模型，從而使軟件過程的控制失去 整體性。 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析，這種模型將功能細化後分別開
發的方法較適應於需求經常改變的軟件開發過程。
敏捷開發的缺點:
1．採用敏捷開發，對開發團隊的人員素質要求比較高
敏捷開發的首要任務是快速，目前提出的"全棧軟件工程師"，它要求軟件開發工程師在開發的各方面，即從需求，設計，編碼，軟件測試一直到系統搭建都要求是行家裏手，這樣可以減少因彼此溝通帶來的時耗，這才能保證他在一個Sprint中能獨立完成產品中某個特定的任務。顯然這樣的軟件開發工程師的素質一定要求很高的，而在軟件開發行業中，人員流動率高，新手多的情況下，要做到這一點是比 較困難的。
2．採用敏捷開發，開發工程師與軟件測試工程師混爲一體，彼此分工不明晰
敏捷開發要求軟件開發工程師會軟件測試，軟件測試工程師會軟件開發，這實施起來是比較困難的。因爲軟件開發和軟件測試工程師關注的重點是不同的：開發關注技術實現比較多，一般都採用正向思維；而軟件測試關注業務比較多，多采用逆向思維。所以一個產品要保證有高的品質，就必須要有獨立的軟件測試工程師，因此測試和開發要有比較清晰明確的分工。正如古話所說："聞道有先後，術業有專攻"。
3．採用敏捷開發，是"短平快"的開發方式，由於產品發佈週期短，所以產品的軟件測試、維護、升級等操作的頻率也增加了這必然增大開發工程師、軟件測試工程師以及運行維護工程師的工作壓力，在這樣高壓的環境下工作很容易出錯，從而影響產品的質量。
4．採用敏捷開發，不利於文檔的建立和修改
敏捷開發有一句口號"擁抱變化"。然而客戶需求的變更是經常變化的，正如當今社會流行的"唯一不變的是變化"。爲了縮短版本發佈週期，特別是在版本發佈之前，當客戶的需求發生變更時，敏捷開發團隊僅僅是修改代碼而沒有時間修改所對應的文檔，這就造成了產品和文檔的開發不一致性這就給產品的後期優化、調整或二次開發，帶來了極大的麻煩，在人員頻繁流動中更是災難性的。