本文主要是介绍Geometry Clipmap Limits，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Geometry Clipmap Limits
我非常喜欢geometry clipmap的思想，甚至还翻译过Hoppe那篇著名的paper，显然这是越来越多的图形计算从cpu到gpu转移的经典例子之一。可惜一直都没有机会实现，直到前段时候，需要编写一个地形系统，终于有了尝试的机会。在完成地形之前，一切都非常好，不幸的是，当实现纹理时，却遇到了非常大的问题，再次印证了那句老话：没有实践过，永远不知道会有什么问题。
仔细看就会发现，所有关于clipmap的文章只讨论过如何计算纹理坐标，却没有讨论过如何“贴”纹理。如果你只考虑程序纹理，那么很幸运，不会遇到任何问题。但是如果需要使用texture spalette（也就是游戏中最常见的情况），Boom~~，问题出现了。对于传统的chunk地形来说，通常每个地形有一张自己的texture spalette，以及相关的纹理t1，t2，t3，无聊渲染还是LOD处理，都以这整个chunk为单位。而对于geo clipmap来说，没有了chunk的概念，每个clipmap tile都可能包含属于多个chunk的数据，当渲染这个tile时，应该用哪一个chunk的spalette呢？ 解决方案之一是更新clipmap数据时，同时动态生成每个tile的spalette，但这并不能解决问题。假设chunk 1使用纹理t1,t2,t3，chunk2使用纹理t2,t4,t5这时当前tile应该用哪几张纹理呢？除非规定所有tile都只能用有限的（显然对于dx9级的显卡来说是8张）几张纹理，否则这将成为一个非常难以解决的问题。multipass也许能解决这个问题，不过这样就完全违背了使用clipmap的初衷——一种高效，简洁的方案——效率还有可能不如传统的方法。Texture array也是潜在的可行方案，可惜这就需要DX10的支持。
非常不幸，这是一篇我目前没有解决方案的blog，看到GameDev上也有人遇到了这个问题，同样没有可行的方案。结果非常郁闷，几天来编写的代码几乎都作废了，不得不回到传统的chunk方法上来:( 如果你正在考虑实现geo clipmap，那么当心遇到同样的问题，如果你不小心想出了解决方案，也不要忘了告诉我:)
ps：blog要搬家了，有没有人知道什么工具可以自动搬到cnblog？
这篇关于Geometry Clipmap Limits的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
