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?

没有更多推荐了,返回首页