這段時(shí)間一直都在忙著寫CoagelEngine，沒時(shí)間上來更新。花了一個(gè)月的時(shí)間，現(xiàn)在基本把渲染器的框架寫好了。渲染器是用Visitor模式實(shí)現(xiàn)的。同時(shí)API無關(guān)，理論上來說同樣可以支持Directx，不過我沒用過DX，現(xiàn)在只實(shí)作了GLRender。通過在場景的主節(jié)點(diǎn)Root（唯一）上調(diào)用Root->accept（GLRender*），就可以自動(dòng)的渲染整個(gè)場景，GLRender會遍歷整個(gè)場景圖，智能的判斷需要渲染的物體是什么類型，比如是Camera，TriMesh，TriStrip，BSpline等等。

場景中的每個(gè)節(jié)點(diǎn)都可能在程序運(yùn)行時(shí)刻改變，比如Camera會相應(yīng)鍵盤和鼠標(biāo)來改變當(dāng)前的視點(diǎn)，地形和復(fù)雜幾何體會根據(jù)視點(diǎn)不同改變Lod等級，粒子系統(tǒng)會根據(jù)時(shí)間改變，骨骼動(dòng)畫等等，為了實(shí)現(xiàn)對這種功能的支持，我開始的設(shè)計(jì)是在每個(gè)節(jié)點(diǎn)上維護(hù)一個(gè)CallBack的鏈表（也可以是vector），當(dāng)Render訪問到這個(gè)節(jié)點(diǎn)的時(shí)候，先執(zhí)行CallBack，然后再往下遍歷，或者是渲染當(dāng)前節(jié)點(diǎn)。但是后來在實(shí)作紋理調(diào)度機(jī)制時(shí)發(fā)現(xiàn)這種方法有會使程序的結(jié)構(gòu)變得很混亂，最后確定用另外一個(gè)Visitor來實(shí)現(xiàn)兩次遍歷。也就是說，先用一個(gè)UpdataVisitor來遍歷場景圖，改變所有的節(jié)點(diǎn)，然后再用RenderVisitor來渲染。這種方法可以提供更優(yōu)雅的程序結(jié)構(gòu)，但是會有一定的性能損失。不過通過對整個(gè)場景圖的良好的組織和限制，這種損失可以被限制在一個(gè)可接受的范圍。

紋理調(diào)度策略：我希望能實(shí)作出比較合理的紋理調(diào)度策略，并且這種策略也可以用到其它的數(shù)據(jù)調(diào)度上。目前的設(shè)計(jì)是這樣的。有一個(gè)texture Class來管理紋理，然后用一個(gè)textureGroup來管理多個(gè)texture class。當(dāng)我要把1 個(gè)或多個(gè)紋理附給一個(gè)物體時(shí)，我就把一個(gè)texture group傳給這個(gè)物體。但是這個(gè)時(shí)候，系統(tǒng)并沒有初試化這些紋理，也就是說，紋理還在系統(tǒng)內(nèi)存中，而不在顯存中。只有當(dāng)一個(gè)物體
確實(shí)需要被渲染時(shí)，才將它帶的紋理傳到顯存中。當(dāng)這個(gè)物體被從場景圖中刪除時(shí)，textureGroup也被刪除。本來最初的計(jì)劃是每個(gè)texture class只能屬于一個(gè)特定的texture group。但是這樣就不能實(shí)現(xiàn)不同
texturegroup中texture的共享。比如場景中的一面墻和很遠(yuǎn)處的另一面墻具有同樣的外觀，如果不能共享紋理，就會造成同樣的紋理需要被創(chuàng)建兩次，浪費(fèi)了系統(tǒng)時(shí)間和顯存。因此用smartPoint來管理texture class是一個(gè)更合理的選擇。只有當(dāng)所有需要這個(gè)texture class的group都被刪除時(shí)，這個(gè)texture才被刪除。

轉(zhuǎn)載于:https://www.cnblogs.com/badkeeper/articles/167868.html

總結(jié)

以上是生活随笔為你收集整理的好长时间没更新了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。