好长时间没更新了
這段時(shí)間一直都在忙著寫(xiě)CoagelEngine，沒(méi)時(shí)間上來(lái)更新。花了一個(gè)月的時(shí)間，現(xiàn)在基本把渲染器的框架寫(xiě)好了。渲染器是用Visitor模式實(shí)現(xiàn)的。同時(shí)API無(wú)關(guān)，理論上來(lái)說(shuō)同樣可以支持Directx，不過(guò)我沒(méi)用過(guò)DX，現(xiàn)在只實(shí)作了GLRender。通過(guò)在場(chǎng)景的主節(jié)點(diǎn)Root（唯一）上調(diào)用Root->accept（GLRender*），就可以自動(dòng)的渲染整個(gè)場(chǎng)景，GLRender會(huì)遍歷整個(gè)場(chǎng)景圖，智能的判斷需要渲染的物體是什么類型，比如是Camera，TriMesh，TriStrip，BSpline等等。
場(chǎng)景中的每個(gè)節(jié)點(diǎn)都可能在程序運(yùn)行時(shí)刻改變，比如Camera會(huì)相應(yīng)鍵盤(pán)和鼠標(biāo)來(lái)改變當(dāng)前的視點(diǎn)，地形和復(fù)雜幾何體會(huì)根據(jù)視點(diǎn)不同改變Lod等級(jí)，粒子系統(tǒng)會(huì)根據(jù)時(shí)間改變，骨骼動(dòng)畫(huà)等等，為了實(shí)現(xiàn)對(duì)這種功能的支持，我開(kāi)始的設(shè)計(jì)是在每個(gè)節(jié)點(diǎn)上維護(hù)一個(gè)CallBack的鏈表（也可以是vector），當(dāng)Render訪問(wèn)到這個(gè)節(jié)點(diǎn)的時(shí)候，先執(zhí)行CallBack，然后再往下遍歷，或者是渲染當(dāng)前節(jié)點(diǎn)。但是后來(lái)在實(shí)作紋理調(diào)度機(jī)制時(shí)發(fā)現(xiàn)這種方法有會(huì)使程序的結(jié)構(gòu)變得很混亂，最后確定用另外一個(gè)Visitor來(lái)實(shí)現(xiàn)兩次遍歷。也就是說(shuō)，先用一個(gè)UpdataVisitor來(lái)遍歷場(chǎng)景圖，改變所有的節(jié)點(diǎn)，然后再用RenderVisitor來(lái)渲染。這種方法可以提供更優(yōu)雅的程序結(jié)構(gòu)，但是會(huì)有一定的性能損失。不過(guò)通過(guò)對(duì)整個(gè)場(chǎng)景圖的良好的組織和限制，這種損失可以被限制在一個(gè)可接受的范圍。
紋理調(diào)度策略：我希望能實(shí)作出比較合理的紋理調(diào)度策略，并且這種策略也可以用到其它的數(shù)據(jù)調(diào)度上。目前的設(shè)計(jì)是這樣的。有一個(gè)texture Class來(lái)管理紋理，然后用一個(gè)textureGroup來(lái)管理多個(gè)texture class。當(dāng)我要把1 個(gè)或多個(gè)紋理附給一個(gè)物體時(shí)，我就把一個(gè)texture group傳給這個(gè)物體。但是這個(gè)時(shí)候，系統(tǒng)并沒(méi)有初試化這些紋理，也就是說(shuō)，紋理還在系統(tǒng)內(nèi)存中，而不在顯存中。只有當(dāng)一個(gè)物體
確實(shí)需要被渲染時(shí)，才將它帶的紋理傳到顯存中。當(dāng)這個(gè)物體被從場(chǎng)景圖中刪除時(shí)，textureGroup也被刪除。本來(lái)最初的計(jì)劃是每個(gè)texture class只能屬于一個(gè)特定的texture group。但是這樣就不能實(shí)現(xiàn)不同
texturegroup中texture的共享。比如場(chǎng)景中的一面墻和很遠(yuǎn)處的另一面墻具有同樣的外觀，如果不能共享紋理，就會(huì)造成同樣的紋理需要被創(chuàng)建兩次，浪費(fèi)了系統(tǒng)時(shí)間和顯存。因此用smartPoint來(lái)管理texture class是一個(gè)更合理的選擇。只有當(dāng)所有需要這個(gè)texture class的group都被刪除時(shí)，這個(gè)texture才被刪除。
場(chǎng)景中的每個(gè)節(jié)點(diǎn)都可能在程序運(yùn)行時(shí)刻改變，比如Camera會(huì)相應(yīng)鍵盤(pán)和鼠標(biāo)來(lái)改變當(dāng)前的視點(diǎn)，地形和復(fù)雜幾何體會(huì)根據(jù)視點(diǎn)不同改變Lod等級(jí)，粒子系統(tǒng)會(huì)根據(jù)時(shí)間改變，骨骼動(dòng)畫(huà)等等，為了實(shí)現(xiàn)對(duì)這種功能的支持，我開(kāi)始的設(shè)計(jì)是在每個(gè)節(jié)點(diǎn)上維護(hù)一個(gè)CallBack的鏈表（也可以是vector），當(dāng)Render訪問(wèn)到這個(gè)節(jié)點(diǎn)的時(shí)候，先執(zhí)行CallBack，然后再往下遍歷，或者是渲染當(dāng)前節(jié)點(diǎn)。但是后來(lái)在實(shí)作紋理調(diào)度機(jī)制時(shí)發(fā)現(xiàn)這種方法有會(huì)使程序的結(jié)構(gòu)變得很混亂，最后確定用另外一個(gè)Visitor來(lái)實(shí)現(xiàn)兩次遍歷。也就是說(shuō)，先用一個(gè)UpdataVisitor來(lái)遍歷場(chǎng)景圖，改變所有的節(jié)點(diǎn)，然后再用RenderVisitor來(lái)渲染。這種方法可以提供更優(yōu)雅的程序結(jié)構(gòu)，但是會(huì)有一定的性能損失。不過(guò)通過(guò)對(duì)整個(gè)場(chǎng)景圖的良好的組織和限制，這種損失可以被限制在一個(gè)可接受的范圍。
紋理調(diào)度策略：我希望能實(shí)作出比較合理的紋理調(diào)度策略，并且這種策略也可以用到其它的數(shù)據(jù)調(diào)度上。目前的設(shè)計(jì)是這樣的。有一個(gè)texture Class來(lái)管理紋理，然后用一個(gè)textureGroup來(lái)管理多個(gè)texture class。當(dāng)我要把1 個(gè)或多個(gè)紋理附給一個(gè)物體時(shí)，我就把一個(gè)texture group傳給這個(gè)物體。但是這個(gè)時(shí)候，系統(tǒng)并沒(méi)有初試化這些紋理，也就是說(shuō)，紋理還在系統(tǒng)內(nèi)存中，而不在顯存中。只有當(dāng)一個(gè)物體
確實(shí)需要被渲染時(shí)，才將它帶的紋理傳到顯存中。當(dāng)這個(gè)物體被從場(chǎng)景圖中刪除時(shí)，textureGroup也被刪除。本來(lái)最初的計(jì)劃是每個(gè)texture class只能屬于一個(gè)特定的texture group。但是這樣就不能實(shí)現(xiàn)不同
texturegroup中texture的共享。比如場(chǎng)景中的一面墻和很遠(yuǎn)處的另一面墻具有同樣的外觀，如果不能共享紋理，就會(huì)造成同樣的紋理需要被創(chuàng)建兩次，浪費(fèi)了系統(tǒng)時(shí)間和顯存。因此用smartPoint來(lái)管理texture class是一個(gè)更合理的選擇。只有當(dāng)所有需要這個(gè)texture class的group都被刪除時(shí)，這個(gè)texture才被刪除。
轉(zhuǎn)載于:https://www.cnblogs.com/badkeeper/articles/167868.html
總結(jié)
- 上一篇： 推荐一份完整的python教学视频
- 下一篇： AP微观经济学课程知识点总结