渲染是3d引擎不可缺少的模組，這兩天在思考如何把這個部分設計好。
首先明確需求，最起碼的因該是把圖形api進行抽象風裝，這樣引擎只呼叫經過抽象的渲染介面，這樣便於擴充套件到其他圖形api上，簡單來說就是把gl/gles/d3d的通用的api抽象出來到crenderbase上，再由此派生crendergl,crendergles,crenderd3d等分別實現，完成底層渲染api的分離。這是最起碼要做到的，接下來就是一些具體的渲染工作到底是放在crender裡面還是放在具體到centity上，比如網格的渲染等。
這時有兩個不同的設計思路，這兩種思路戶為互補，又很難並存。一種是保持centitymesh這樣的幾何實體實現簡單，裡面只包括對幾何資料必要的操作，渲染則放到crender裡面，也就是有這樣的函式crender::rendermesh(...); 這樣做的好處是所有渲染相關的東西完全被放到了crender裡面，看起來結構較為單純，當然它也有問題，這就是下面要提到的另一種思路。另一種思路是則是保持crender的單純，他的最主要的工作就是對底層api進行隔離和不同圖形api的統一風裝，entitymesh自己寫渲染函式並呼叫crender的方法，也就是這樣的函式centitymesh::render(...); 這樣做的好處是在centitymesh這個角度看和他相關的都被完整地寫在了自己的類裡面，如果哪天不要centitymesh了直接把這個類刪掉就行了，不影響其他，而第一種思路除了刪掉centitymesh類以外還要對應刪掉crender::rendermesh函式，當各種實體之間互相呼叫關係比較複雜的時候，很可能會不那麼容易刪的徹底且仍然看來其來設計良好。這也是第二種方法的好處。
第一中方法在不少的商業引擎裡面可以看到，而結合我的引擎，我使用的是第二種方法，總的思路是保持crender的單純，這是引擎底層寫好了一般不動，同時盡量保持centitymesh這樣實體類的內聚與模組化，新增刪除這樣的實體類盡量保證其對外影響最小。
如何理解3D渲染引擎
框架的支援 3d引擎只是動力 在外層需要有完整的框架負責輸入輸出，網路通訊等，平台差異性 物件導向設計 外掛程式擴充套件機制，主要是功能擴充套件，引擎只負責3d效果的展出，實際的產品應用要考慮輸入輸出 網路通訊 其他媒介的支援 其中輸入輸出主要是滑鼠鍵盤，kinect等體感式外設 網路通訊主要是遊戲...
簡述3D引擎的渲染優化
文章出處 一 如何進行有效的效能評測 對於任何乙個3d應用程式來說，追求場景畫面真實感是乙個無止盡的目標，其結果就是讓我們的場景越來越複雜，模型更加精細，這必然給圖形硬體帶來極大的負荷以致於無法達到實時繪製幀率。因此，渲染優化是必不可少的。在渲染優化之前，我們需要對應用程式效能進行系統的評測，找出瓶...
3D渲染管線流程
首先用一張圖來回顧一下渲染管線的各個階段，目前為止我們接觸的著色器有頂點著色器和畫素著色器，而接觸到的渲染管線階段有 輸入裝配階段 頂點著色階段 光柵化階段 畫素著色階段 輸出合併階段.可以看到，幾何著色器是我們在將頂點送入光柵化階段之前，可以操作頂點的最後乙個階段。它同樣也允許我們編寫自己的著色器...