Allen:


windam:

Allen:
由于cyrsis属于技术展示型的游戏，所以在空间和时间转换上基本上是考虑时间而不是空间。当然我很同意把所有顶点放在同一个vb不一定效率高的假设。这个应该是显而易见的，因为一旦多组巨大的vb产生，必然会存在切换到内存的情况。越大vb切换越慢是肯定的，所以129*129为单位的chunck，和33*33为单位的patch可能是比较好的折中方式，但是还是需要一个更大的tile类型来和并chunck。这个设定类似于魔兽的地图渲染概念。只是魔兽的chunck更小而已。有了tile概念还能在此基础上产生catch，那么渲染速度和资源消耗能达到一个比较好的平衡点。
很高兴很博主讨论这些问题，我获益良多，以后会经常来讨论。谢谢

很高兴你觉得有用。欢迎讨论，共同进步 ：）

windam:

Allen:按照geomipmap的原始理论，lod应该是按照高度变化的实际像素差异来判断的，我之前也是使用这个预算方案的，差别是我没有使用patch，而是最高精确计算lod。所以不能预算lod填充。但是极端情况在超大地图的情况下一定会产生，我感觉要限制小于5级差估计需要距离和高度复杂度同时判断。这样消耗会小些。关于vertex buffer的问题，我坚持两个观点，把buffer分的越小，冗余的顶点数越多。以33*33和65*65为例。65 *65的顶点总数是4225而拆分为４个３３＊３３就是４３５６。这还只是计算叶子处的冗余，由于没４个能合并成一个，那么每个父又多了３３＊３３个顶点。也就是说，总体来说多出了%30左右的顶点。其次如果以６５＊６５来绘画，只需要一次ｂｉｎｄ，而分拆就是４次。如果是１２９＊１２９，就是１６次。这本身并不涉及indexbuffer.indexbuff是固定的。我只是从效率上来分析这个问题。我们可以作个假设，４０９７＊４０９７的地形，如果只创建一个vertexbuffer,那么我们绘画整个地图的时候只需要一次bind而已，（当然这是忽略显存的情况下）而使用３３＊３３的vertexbuffer，最坏情况是需要ｂｉｎｄ１２８＊１２８次。这显然是巨大的开销。
明白你的意思了。vb的粒度增加，可以降低调用SetStreamSource的次数。以更大的单位组织顶点，可以减少边界处的冗余顶点。
事实上，vb的粒度与patch的大小可以是无关的，以33*33为单位来组织顶点作为一个patch，并把大量的patch放在一个vb里就可以了，渲染的时候利用Offset来选择实际使用的顶点区段，就不需要创建大量的vb了。（抱歉，在之前的叙述中，我下意识的把这种方案给忽略了，因为觉得对于已经存在于显存中的vb，这个切换的开销可能不是很重要。crysis就用了类似的方案，在PIX中查看到的数据表明，他存放地形顶点数据的vertex buffer，每一个都是200多kb左右，每个vertexbuffer中存储了若干个不同lod级别的patch顶点，包括33*33, 17*17, 9*9等不同lod级别的版本，因为他patch本身也会根据实际情况选择不同lod版本的mesh）
此外还有一个问题，是把所有的顶点放在一个vb里效率高，还是把vb切成一个比较合适的粒度效率更高？这个也不见得就是粒度越大越好，但我没有实际测试过效率所以不好评价。Crysis的做法是没有全部放置于一个vb里，我猜可能是做过考量和权衡的。对于已经创建在显存里的vb，SetStreamSource的开销可能并没有想象那么高。（只是切换一下当前选用的vb，而不需要向显卡提交数据）
至于冗余顶点的问题，边界处的我认为可以忽略不计，geomipmap产生的33%的冗余开销是这种方案的固有代价。对于大规模的地形，这种LOD策略自然会将总的渲染次数降低到合理的范围。

由于cyrsis属于技术展示型的游戏，所以在空间和时间转换上基本上是考虑时间而不是空间。当然我很同意把所有顶点放在同一个vb不一定效率高的假设。这个应该是显而易见的，因为一旦多组巨大的vb产生，必然会存在切换到内存的情况。越大vb切换越慢是肯定的，所以129*129为单位的chunck，和33*33为单位的patch可能是比较好的折中方式，但是还是需要一个更大的tile类型来和并chunck。这个设定类似于魔兽的地图渲染概念。只是魔兽的chunck更小而已。有了tile概念还能在此基础上产生catch，那么渲染速度和资源消耗能达到一个比较好的平衡点。
很高兴很博主讨论这些问题，我获益良多，以后会经常来讨论。谢谢

Allen:

按照geomipmap的原始理论，lod应该是按照高度变化的实际像素差异来判断的，我之前也是使用这个预算方案的，差别是我没有使用patch，而是最高精确计算lod。所以不能预算lod填充。但是极端情况在超大地图的情况下一定会产生，我感觉要限制小于5级差估计需要距离和高度复杂度同时判断。这样消耗会小些。
关于vertex buffer的问题，我坚持两个观点，把buffer分的越小，冗余的顶点数越多。以33*33和65*65为例。65 *65的顶点总数是4225而拆分为４个３３＊３３就是４３５６。这还只是计算叶子处的冗余，由于没４个能合并成一个，那么每个父又多了３３＊３３个顶点。也就是说，总体来说多出了%30左右的顶点。其次如果以６５＊６５来绘画，只需要一次ｂｉｎｄ，而分拆就是４次。如果是１２９＊１２９，就是１６次。这本身并不涉及indexbuffer.indexbuff是固定的。我只是从效率上来分析这个问题。我们可以作个假设，４０９７＊４０９７的地形，如果只创建一个vertexbuffer,那么我们绘画整个地图的时候只需要一次bind而已，（当然这是忽略显存的情况下）而使用３３＊３３的vertexbuffer，最坏情况是需要ｂｉｎｄ１２８＊１２８次。这显然是巨大的开销。

明白你的意思了。vb的粒度增加，可以降低调用SetStreamSource的次数。以更大的单位组织顶点，可以减少边界处的冗余顶点。

事实上，vb的粒度与patch的大小可以是无关的，以33*33为单位来组织顶点作为一个patch，并把大量的patch放在一个vb里就可以了，渲染的时候利用Offset来选择实际使用的顶点区段，就不需要创建大量的vb了。（抱歉，在之前的叙述中，我下意识的把这种方案给忽略了，因为觉得对于已经存在于显存中的vb，这个切换的开销可能不是很重要。crysis就用了类似的方案，在PIX中查看到的数据表明，他存放地形顶点数据的vertex buffer，每一个都是200多kb左右，每个vertexbuffer中存储了若干个不同lod级别的patch顶点，包括33*33, 17*17, 9*9等不同lod级别的版本，因为他patch本身也会根据实际情况选择不同lod版本的mesh）

此外还有一个问题，是把所有的顶点放在一个vb里效率高，还是把vb切成一个比较合适的粒度效率更高？这个也不见得就是粒度越大越好，但我没有实际测试过效率所以不好评价。Crysis的做法是没有全部放置于一个vb里，我猜可能是做过考量和权衡的。对于已经创建在显存里的vb，SetStreamSource的开销可能并没有想象那么高。（只是切换一下当前选用的vb，而不需要向显卡提交数据）

至于冗余顶点的问题，边界处的我认为可以忽略不计，geomipmap产生的33%的冗余开销是这种方案的固有代价。对于大规模的地形，这种LOD策略自然会将总的渲染次数降低到合理的范围。

Allen:


windam:

Allen:的确是好文章，但是在lod拼接的这个问题上好像有些矛盾。如果crysis使用的是固定拼接，那么就不存在高level的合并，因为一旦合并，原来的拼接面就要重新计算。比如说2个65 * 65顶点的相邻地形，每个都是由四个33 *33的patch组成的，内部拼接可以由预先算好的方式拼接，但是当其中一个65*65的地形被简化为33 * 33的时候就出现了跨层级的拼接，这时候就只能实时计算了。我曾经实现过４叉树的地形，最耗时的就是实时拼接。这个问题不知道博主研究过没有。
呵呵，写的时候偷了点懒，这块没说清楚。你说的65*65的节点是由4个33*33拼成的，但是在这个节点上可以事先预算好一个低级别的缩略版Mesh，缩略版只有33*33个顶点（但是囊括了65*65的区域，每个grid相当于高分辨率网格的2个grid），当渲染该节点的时候，使用的不是65*65的Mesh，而是预计算好的缩略版的33*33的Mesh。这样实际上还是在复用33*33 patch的索引。
至于你说的跨层级拼接的问题，事实上也很好解决 —— 通过预计算，把所有可能的跨层级的索引都先算好就行了。对于33*33的patch来说，无非就是每条边有5种可能的情况（2^5 = 32）：邻接patch如果lod高一级，就意味着本patch的2个grid相当于对方的1个grid，如果lod差5级，则是本patch的32个grid相当于对方的1个grid。将一个patch的四条边遇到的所有可能的情况都预算好是可行的，文中最后计算显存占用就是在算这块到底占用了多少显存。

这个预先计算我也考虑过，但是极端情况预先计算也无法完成。以最高精度33*33来举例。极端情况下相邻6级差就变成了2个33* 33相当于1个grid，这时候还能share一个顶点。更极端的情况是7级差，这时候4个33*33=1个grid，那么势必有2个33*33没有顶点共享，而且无法通过高精度预算来完成lod间的填充。（虽然是极端情况，但是我们也会遇到，比如说巨大的平原只有一个小山丘，这时候平原的高度差为0，而山丘是当前人物位置）
这个问题貌似只有2种解决方案，1：为低精度的grid增加新的顶点满足高精度，（这个方案我尝试过，因为不能预算，消耗较大）。2：强制规定不允许有5级以上的差别。
对于方案2我没有尝试过，感觉上这个强制计算依然是很消耗cpu的，尤其是当面对4096*4096这样的巨大地形。不知道博主有没有更好的方案？
还有一个问题，您的预算index buff显存占用大小是按照short类型来计算的。那么对于程序本身来说只能支持到129 *129的index buff.这样势必会需要把４０９７＊４０９７的高度图拆分成为３２＊３２个独立的顶点ｂｕｆｆ。这样必然还有冗余顶点产生，而且每个１２９＊１２９的ｐａｔｃｈ之间的ｌｏｄ填充依然会相当占用资源。这个问题不知道博主是怎么考虑的。

对于一棵树四叉树，如果从根节点到叶节点的深度如果不超过5，并且不考虑单个patch内的lod，就可以从数据结构上自动保证这一点（相邻两个节点的lod差不超过5）。

不清楚你采用的是什么lod策略，因为我觉得你说的极端情况是很难出现的，一个5级lod的32*32的网格所覆盖的区域，与最高精度下的1024*1024的网格所覆盖的范围是等同的（也就是说采用这种级别的网格，即便完整的渲染4096*4096的地形，也只需要16个draw call，我认为在游戏环境下，继续追求更高的lod级别已经没有太大实际意义了）。

这里的权衡，我倾向于调整lod策略，使得相邻patch的lod差别不要太大。所以建议尝试一下第二个方案。

关于索引：因为只需要支持对33*33大小的vertex寻址就可以了，用WORD是绰绰有余了。因为也只需要用到33*33的vertex buffer。
我觉得你的疑问可能是因为没理解Crysis的方案中所采用的geomipmap方案，这个方案的核心特点为整个地形网格创建了mipmap chain，并且顶点都是以33*33个顶点为单位进行组织，不会出现更多顶点的情况。四叉树的每一个节点都有自己的33*33的vertex buffer。不同lod级别之间，更换的是vertexbuffer，而不是indexbuffer。

windam:

Allen:的确是好文章，但是在lod拼接的这个问题上好像有些矛盾。如果crysis使用的是固定拼接，那么就不存在高level的合并，因为一旦合并，原来的拼接面就要重新计算。比如说2个65 * 65顶点的相邻地形，每个都是由四个33 *33的patch组成的，内部拼接可以由预先算好的方式拼接，但是当其中一个65*65的地形被简化为33 * 33的时候就出现了跨层级的拼接，这时候就只能实时计算了。我曾经实现过４叉树的地形，最耗时的就是实时拼接。这个问题不知道博主研究过没有。
呵呵，写的时候偷了点懒，这块没说清楚。你说的65*65的节点是由4个33*33拼成的，但是在这个节点上可以事先预算好一个低级别的缩略版Mesh，缩略版只有33*33个顶点（但是囊括了65*65的区域，每个grid相当于高分辨率网格的2个grid），当渲染该节点的时候，使用的不是65*65的Mesh，而是预计算好的缩略版的33*33的Mesh。这样实际上还是在复用33*33 patch的索引。
至于你说的跨层级拼接的问题，事实上也很好解决 —— 通过预计算，把所有可能的跨层级的索引都先算好就行了。对于33*33的patch来说，无非就是每条边有5种可能的情况（2^5 = 32）：邻接patch如果lod高一级，就意味着本patch的2个grid相当于对方的1个grid，如果lod差5级，则是本patch的32个grid相当于对方的1个grid。将一个patch的四条边遇到的所有可能的情况都预算好是可行的，文中最后计算显存占用就是在算这块到底占用了多少显存。

这个预先计算我也考虑过，但是极端情况预先计算也无法完成。以最高精度33*33来举例。极端情况下相邻6级差就变成了2个33* 33相当于1个grid，这时候还能share一个顶点。更极端的情况是7级差，这时候4个33*33=1个grid，那么势必有2个33*33没有顶点共享，而且无法通过高精度预算来完成lod间的填充。（虽然是极端情况，但是我们也会遇到，比如说巨大的平原只有一个小山丘，这时候平原的高度差为0，而山丘是当前人物位置）
这个问题貌似只有2种解决方案，1：为低精度的grid增加新的顶点满足高精度，（这个方案我尝试过，因为不能预算，消耗较大）。2：强制规定不允许有5级以上的差别。
对于方案2我没有尝试过，感觉上这个强制计算依然是很消耗cpu的，尤其是当面对4096*4096这样的巨大地形。不知道博主有没有更好的方案？
还有一个问题，您的预算index buff显存占用大小是按照short类型来计算的。那么对于程序本身来说只能支持到129 *129的index buff.这样势必会需要把４０９７＊４０９７的高度图拆分成为３２＊３２个独立的顶点ｂｕｆｆ。这样必然还有冗余顶点产生，而且每个１２９＊１２９的ｐａｔｃｈ之间的ｌｏｄ填充依然会相当占用资源。这个问题不知道博主是怎么考虑的。

Allen:

的确是好文章，但是在lod拼接的这个问题上好像有些矛盾。如果crysis使用的是固定拼接，那么就不存在高level的合并，因为一旦合并，原来的拼接面就要重新计算。比如说2个65 * 65顶点的相邻地形，每个都是由四个33 *33的patch组成的，内部拼接可以由预先算好的方式拼接，但是当其中一个65*65的地形被简化为33 * 33的时候就出现了跨层级的拼接，这时候就只能实时计算了。我曾经实现过４叉树的地形，最耗时的就是实时拼接。这个问题不知道博主研究过没有。

呵呵，写的时候偷了点懒，这块没说清楚。
你说的65*65的节点是由4个33*33拼成的，但是在这个节点上可以事先预算好一个低级别的缩略版Mesh，缩略版只有33*33个顶点（但是囊括了65*65的区域，每个grid相当于高分辨率网格的2个grid），当渲染该节点的时候，使用的不是65*65的Mesh，而是预计算好的缩略版的33*33的Mesh。这样实际上还是在复用33*33 patch的索引。

至于你说的跨层级拼接的问题，事实上也很好解决 —— 通过预计算，把所有可能的跨层级的索引都先算好就行了。
对于33*33的patch来说，无非就是每条边有5种可能的情况（2^5 = 32）：邻接patch如果lod高一级，就意味着本patch的2个grid相当于对方的1个grid，如果lod差5级，则是本patch的32个grid相当于对方的1个grid。
将一个patch的四条边遇到的所有可能的情况都预算好是可行的，文中最后计算显存占用就是在算这块到底占用了多少显存。

volfmath:

好文章，分析的不错。LOD那块crysis似乎是具体地貌复杂度来决定LOD的。

没错，Crysis的LOD级别判定会综合考虑地形复杂度和距离两个因素。
不过具体地形复杂度怎么算，我只想到一些比较山寨的法子，不清楚Crysis是什么做法，以及有没有相关的算法。