把開發(fā)日志按大章節(jié)從設(shè)計到實現(xiàn)來寫感覺很有節(jié)奏感，很Nice。以后都這樣做吧。

在前面的設(shè)計中提到，面對海量的方塊，把這些方塊看作為單獨的個體設(shè)計帶來的性能開銷是現(xiàn)在所有電腦都不能接受的，因此需要將這些結(jié)構(gòu)簡單的方塊合成一個結(jié)構(gòu)稍微復(fù)雜的大模型處理，這樣可以有效減少性能開銷。

面標志位和面掩碼

為了表示方塊六個面的有無，我聯(lián)想到了計算機科學(xué)中常用的設(shè)計：標志位和掩碼。使用一個比特的6個位，從低到高，依次表示從正x，y，z方向到負x，y，z方向的有無。比如000001，表示x軸的正方向；000111表示x，y，z的正方向。這么排列有一個小小的好處：只要循環(huán)位移3位，就可以取到反方向的標志位。

確定了方向的表示方式后，我設(shè)計了一種專用于這種方塊世界的模型格式。在這個格式中，模型由材質(zhì)綁定點和數(shù)個子網(wǎng)格構(gòu)成。它的獨特之處在于，除了傳統(tǒng)的頂點數(shù)據(jù)之外。模型中還額外包含了不透明面標志位（Opacity?Flags），子網(wǎng)格中包含了暴露面標志位（Exposure?Flags）。在以后的生成具體區(qū)塊網(wǎng)格的過程中，會根據(jù)由區(qū)塊方塊的不透明面標志位組成的不透明密度場生成暴露密度場，然后依據(jù)這個暴露密度場來具體計算每個方塊需要提供的網(wǎng)格。

下面是一個用我定義的模型格式表示的普通方塊。這個格式是用我自己用C#實現(xiàn)的Lisp解釋器來進行解析的。和Lisp比較像。

以上這個標志位和場的設(shè)計靈感來自《GPU Gems3》中的第一篇論文：Generating Complex Procedural Terrains Using the GPU。

密度場

在區(qū)塊生成時，首先會為根據(jù)區(qū)塊存儲的方塊的不透明面標志位生成不透明密度場，和按照全部不暴露初始化的暴露密度場。

接著遍歷這個不透明密度場，如果在區(qū)塊中某個方塊的不透明面標志位表示某方向的位為0，那么就給這個方塊在這個相鄰方向取反的暴露面標志位置1。

用語言描述這段代碼實在是有點繞...直接上一段代碼吧。

看代碼還是繞，硬要理解的話可以這么想象：把每一個遍歷的格子想象成里面有一個盲人。首先盲人在格子里面，如果格子某個面不透明，那么這個盲人就出不去。如果這個面透明，那么盲人就能走出格子，去摸上下左右前后的方塊，如果摸到了（該面不透明），那么就會報告給統(tǒng)計員該位置方塊是暴露的。

然后由這個像是積分的過程得出最終的暴露密度場。最后遍歷這個暴露密度場，讓這一格的暴露面標志位和模型子網(wǎng)格的暴露面標志位做按位與，如果結(jié)果等于模型子網(wǎng)格的暴露面標志位，那么就代表這個子網(wǎng)格需要被添加到區(qū)塊模型中。

廣度優(yōu)先遍歷

在開發(fā)過程中突然回想起不知道多少年前看過的一篇Mojang寫的博客，介紹MCPE的剔除算法的。印象里那篇博客還按曼哈頓距離畫了一張菱形像素圖，而且以一定的透明度疊加上了Minecraft的區(qū)塊示意圖。

這讓我意識到，是不是可以不用遍歷所有方塊，而是使用廣度優(yōu)先搜索？

思考了一下，確實可行，從玩家眼睛所在的方格出發(fā)，按照一定的曼哈頓距離使用廣度優(yōu)先遍歷的方式，模擬一群盲人人行走?？梢詼p少不少的被埋在深處的方塊的遍歷。

最終遍歷的方式也從暴力遍歷改成了廣度優(yōu)先遍歷的形式。

還有嗎？

我其實已經(jīng)可以想到用并發(fā)的方式來批量計算它們了，這是完全可行的。這個步驟做一下類比，像極了用計算著色器去做圖像模糊算卷積核的過程。只不過維度從二維升到了三維而已。

不過因為時間問題只好留待以后優(yōu)化了。

最后貼一張渲染出來的成品區(qū)塊