關于無限LOD地形的構想
前敘
----
從沒好好寫過一篇文章，現(xiàn)在也來好好寫寫
首先：具備了單個地形塊Lod四叉裁減的能力就可以考慮做無限大地圖和地形塊的動態(tài)內存管理能力了
但是首要條件是現(xiàn)搞定單個地形塊的四叉裁減，這個很基本也很是前提條件
無限地圖的實現(xiàn)構想如下：
多個Tile的四叉剪裁
------------------
角色在移動的過程中，自身包括周圍的一共9個Tile都是在可視范圍內的，9個tile以外視錐看不到
視錐只和相交的Tile去做四叉剪裁，最多能看到四個Tile的內容，再分別進行可見Tile的剪裁
剪裁以后可見的Block送入到管線里面去渲染，四叉剪裁范圍比較固定最多四個257x257的Tile，
范圍很小，剪裁效率很高
正題部分 — 關于無限地圖的構想
------------------------------
首先是客戶端
地圖可以是無限大的，把整個游戲的外景地圖叫做世界地圖吧
世界地圖不論有多大，都可以拆分成塊成一個個的Tile
Tile無縫拼接
------------
世界地圖只做一張大的高度圖，alpha混合紋理，光照圖，并由美工去按tile的大小去分割這些圖
這樣分割出來的圖自然是無縫銜接的，每個Tile也有了自己配套的高度圖，混合紋理，光照了
而且整個世界源圖是一張，美工也很容易處理和修改，最大的好處是解決接縫問題和動態(tài)加載問題
動態(tài)內存管理的基本思想：游戲的人物一般長時間一般再某個局部區(qū)域內活動，
游戲中只加載那些經常訪問的Tile，不經常訪問的Tile不加載
具體實現(xiàn) －隊列
---------------
把參加剪裁的地形放入到隊列中去，最新參加裁減的放到head，隊列中已存在的就直接排到head，
不存在就新建tile，然后排到head,過去剪裁的排后直到end出隊列并釋放
隊列放入最近訪問到的Tile首指針，長度可根據(jù)需要去定義，不能過小，或過大
過大內存好用太大，過小導致加載釋放頻繁,我想設置成36足夠了
有一種情況很特別：就是人物從地圖的一頭一直跑向另一頭，一定會不停的加載和釋放
這是無法避免的，所以，要對加載和剪裁進行測試并優(yōu)化
需要保證間隔時間內不斷創(chuàng)建和釋放的257的地形而"不卡"
也就是保證客戶端帶的起就行,一個257x257的Tile加載并裁減時間很短暫，其實問題不大
這個方法不一定很好，也可以采用dxsdk example contextStream技術（我還不會，也只了解- -!)
或是動態(tài)輔助GC線程的管理，有很多種策略，方法不是唯一的，只要適合自己就行。
服務器端無限地圖
------------------
目前只有個模糊的構想:
因為還沒開始做服務器端的東西，我想客戶端搞定后，把IOCP的服務器加上來
我想登錄服務器應該有用戶的Session，這個Session關聯(lián)與角色相關的一切信息，
包括所見的tile，并做游戲規(guī)則的檢測，任務流程等等，
服務器端而不需要保存block的信息，只有所有的tile信息，和tile里面的場景包圍盒信息
不需要包含細致的東西,這樣不僅可以大大節(jié)約內存，而且執(zhí)行效率也高，
服務器只做規(guī)則引擎，而不做渲染，還記得傳奇純外掛給我們留下了深刻的印象，只運行外掛就可以練級，
里面也有人物的地圖，而且移動的地圖就好像是個衛(wèi)星定位圖一樣，根本沒有細節(jié)部分，人物就是一個點
我想服務器的地圖做成那樣一個2D的東西就足夠了,甚至需不需要做都無所謂，也就是網絡監(jiān)控友好點吧。
好了，就寫這么多了，有些部分也還只是個構想未實現(xiàn)，一定有很多不健全的地方，我現(xiàn)在要去一一實現(xiàn)。
在做的過程中一定能有更好的思路。
本人業(yè)余人士，只是水平有限, 單槍匹馬, 只是激情無限，有什么不對或更好的建議還望指正!