年後替換了ogre的主要渲染流程,一直沒有機會梳理,如今都已經有一些淡忘了.當時想替換它的渲染流程有兩個 原因,第一是美術對實時燈光的需求越來越大,包括是場景,特效都會有實時燈光的需求,而以前的是前向渲染,對 燈光複雜度高的場景支援不好(燈光數,場景複雜度與燈光複雜度成幾何倍數關係).第二是ogre的通用性帶來了很 多效率上的浪費,比如說pass的設定會有大量的不必要判斷,rs切換浪費.於是我將他替換為後向渲染來支援燈光 複雜度,將渲染物件分類來達到rs切換的不浪費,並且將renderable的組織方式由stl容器組合變成了renderable 內部串聯的list方式.
在修改的過程中有些地方讓我猶豫很久,比如說做direcitonal light的陰影時.我現在是將directional lighting,ambient 和 shadow 放在乙個全螢幕pass上的,而沒有將它們分開為2個全螢幕pass,乙個lighting,乙個shadow,ambient.這樣做的目的主要是為了節約pixel fill.但是如果有些物體接受lighting,但不被shadow的話,第一種方式就會有問題,因為就算我知道哪個pixel是不被shadow的,我也拿它沒辦法.why?這樣來說，我能想到判斷pixel不被shadow的辦法有兩種，第一是stencil buffer,但是它會完全去掉direction light的計算，這個是不能接受的．第二是在gbuffer上打標記，但是我們的gbuffer已經很擁擠了，我無法再將它擠進去．如果增 加gbuffer的數量，那合併directional lighting,ambient 和 shadow的意義就沒有了．當然還有個方法來處理 那種不接受shadow的renderable,就是它不走後向渲染，走前向渲染．這個方法比較適合不接受光照的物體．還 有乙個地方思考了很久，就是對透明物體的處理，這個是後向渲染的死穴．很多書對後向的透明處理有一些獨特 的解決方案，比如說shaderx7裡面就用交叉行來儲存前後混合物體的gbuffer,但是這些方式都只能用於很特殊的 地方，有使用環境的限制．最直接的方式就是後向不處理透明，透明直接走前向．不知道有沒有其他更好的方式 ，希望大家多多指導一下．
現在還是有一些問題有待解決，比如說overdraw過大，rs的切換，和render device event還是有點多
頁面渲染流程
1.瀏覽器把獲取到的html 解析成1個dom樹，html中的每個tag都是dom樹中的1個節點，根節點就是我們常用的document物件。dom樹里包含了所有html標籤，包括display none隱藏，還有用js動態新增的元素等。2.瀏覽器把所有樣式 使用者定義的css和使用者 解析成樣式結構...
OpenGL渲染流程
管線這個術語描述了opengl渲染的整個過程。opengl採用cs模型 c是cpu，s是gpu，c給s的輸入是vertex資訊和texture資訊，s的輸出是顯示器上顯示的影象。下面這2個圖比較清楚的講解了opengl的渲染管線。相信沒有opengl基礎的應該看不懂，下面會簡單的介紹這個流程，再看下...
Shader 渲染流程
gpu graphics processing unit，影象處理器，gpu上有成千上萬核，這些核並行執行 cpu central processing unit，處理器，cpu通常有單核 雙核 四核和八核，但這些核只能序列操作。渲染流水線的工作任務在於由乙個三維場景出發 生成 或渲染 一張二維影象...