3d Game Walkman

3d图形渲染,网络引擎 — tonykee's Blog
随笔 - 45, 文章 - 0, 评论 - 309, 引用 - 0
数据加载中……

过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)

 关于无限LOD地形的构想


前叙
----
从没好好写过一篇文章,现在也来好好写写

首先:具备了单个地形块Lod四叉裁减的能力就可以考虑做无限大地图和地形块的动态内存管理能力了
但是首要条件是现搞定单个地形块的四叉裁减,这个很基本也很是前提条件
无限地图的实现构想如下:


多个Tile的四叉剪裁
------------------
角色在移动的过程中,自身包括周围的一共9个Tile都是在可视范围内的,9个tile以外视锥看不到
视锥只和相交的Tile去做四叉剪裁,最多能看到四个Tile的内容,再分别进行可见Tile的剪裁
剪裁以后可见的Block送入到管线里面去渲染,四叉剪裁范围比较固定最多四个257x257的Tile,
范围很小,剪裁效率很高

正题部分 — 关于无限地图的构想
------------------------------
首先是客户端
地图可以是无限大的,把整个游戏的外景地图叫做世界地图吧
世界地图不论有多大,都可以拆分成块成一个个的Tile

Tile无缝拼接
------------
世界地图只做一张大的高度图,alpha混合纹理,光照图,并由美工去按tile的大小去分割这些图
这样分割出来的图自然是无缝衔接的,每个Tile也有了自己配套的高度图,混合纹理,光照了
而且整个世界源图是一张,美工也很容易处理和修改,最大的好处是解决接缝问题和动态加载问题

动态内存管理的基本思想:游戏的人物一般长时间一般再某个局部区域内活动,
游戏中只加载那些经常访问的Tile,不经常访问的Tile不加载

具体实现 -队列
---------------
把参加剪裁的地形放入到队列中去,最新参加裁减的放到head,队列中已存在的就直接排到head,
不存在就新建tile,然后排到head,过去剪裁的排后直到end出队列并释放

队列放入最近访问到的Tile首指针,长度可根据需要去定义,不能过小,或过大
过大内存好用太大,过小导致加载释放频繁,我想设置成36足够了

有一种情况很特别:就是人物从地图的一头一直跑向另一头,一定会不停的加载和释放
这是无法避免的,所以,要对加载和剪裁进行测试并优化
需要保证间隔时间内不断创建和释放的257的地形而"不卡"
也就是保证客户端带的起就行,一个257x257的Tile加载并裁减时间很短暂,其实问题不大
这个方法不一定很好,也可以采用dxsdk example contextStream技术(我还不会,也只了解- -!)
或是动态辅助GC线程的管理,有很多种策略,方法不是唯一的,只要适合自己就行。

服务器端无限地图
------------------
目前只有个模糊的构想:
因为还没开始做服务器端的东西,我想客户端搞定后,把IOCP的服务器加上来
我想登录服务器应该有用户的Session,这个Session关联与角色相关的一切信息,
包括所见的tile,并做游戏规则的检测,任务流程等等,
服务器端而不需要保存block的信息,只有所有的tile信息,和tile里面的场景包围盒信息
不需要包含细致的东西,这样不仅可以大大节约内存,而且执行效率也高,
服务器只做规则引擎,而不做渲染,还记得传奇纯外挂给我们留下了深刻的印象,只运行外挂就可以练级,
里面也有人物的地图,而且移动的地图就好像是个卫星定位图一样,根本没有细节部分,人物就是一个点
我想服务器的地图做成那样一个2D的东西就足够了,甚至需不需要做都无所谓,也就是网络监控友好点吧。

好了,就写这么多了,有些部分也还只是个构想未实现,一定有很多不健全的地方,我现在要去一一实现。
在做的过程中一定能有更好的思路。

本人业余人士,只是水平有限, 单枪匹马, 只是激情无限,有什么不对或更好的建议还望指正!

posted on 2008-01-01 14:54 李侃 阅读(3618) 评论(15)  编辑 收藏 引用 所属分类: 设计思路

评论

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)[未登录]  回复  更多评论   

嘿嘿,我是3D门外汉,它能懂我,我不懂它,要再接再厉~!
要把你之前总结的东西,拿出来跟大家分享噢~!
2008-01-01 15:06 | vicky

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

虽然好多看不太懂,不过要努力向您看齐...
2008-01-08 12:00 | wtlt

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

很好,给我帮助很大。
看得出博主程序分析设计的功力相当深厚!
2008-01-08 23:06 | benlei

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

牛年来请教问题了 哈哈
~
在这个帖子里 http://bbs.gameres.com/showthread.asp?threadid=108987

lz说
另外你只要设定好阀值,网格间距一致,事实上就不会出现block节点之间的lod级别大于1的情况


能讲的具体点吗?
lod级别先从哪个block开始算?
当四个相邻的block中 如果有还没算过lod级别的block该怎么处理?
先谢过了~



2009-01-21 11:06 | AstaTus

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

过年回家上次网不容易
lod级别我用的是最简单的 观测点到block中心距离×阀值(一个小数) 来确定的,相当于运用一个策略钳制一个LOD当量在可用级别范围内,传统的方式都是这样做的,当然要做的更复杂,不能光靠距离来决定lod级别,比如起伏大的地形用高的级别,平坦的地域用低的级别,这可以说是另一个高级话题了
2009-01-24 23:19 | 李侃

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

有一种情况:比如有个2*2的block 。lod级数1的分辨率最小
/2/3 /
/1/ ?/
问号所在的block的lod是多少呢?
既然都是边界都是向分辨率底的block补的,当算到?所在的block时,他只能向
对左边的边界做缝补操作,而向上的3呢?

我觉得要不把所有的情况先算好,包括向lod高的缝补也预处理好,但空间开销实再太大
要不就是先算好部分的index (分成四个边界和内部的一块)
然后实时渲染时将各部分的index拼起来
但貌似dx的lock和unlock的效率不怎么高~

还有地形的起伏的对lod级数的影响
个人觉得有2个方面 1个是block的平均的高度,2是起伏的分布 我在想是不是可以用方差求,
纯属愚见,望指教哈~
2009-01-25 11:27 | AstaTus

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

/2/3 /
/1/ ?/

?号的部分的级别显然应该是2,观测点因该在1点半的方位,前面叙述过,而且实践检验过,通过设定好的阀值,相邻的block级别不可能相差超过1的

各种级别和边的补缝形态索引的确是要计算的,但用过了不要浪费,我定义了一个cache,四条边的补缝形态以及除了四条边以外中间的形态都放入了缓存,缓存找不到的时候就计算,然后加入缓存,最终缓存能把所有形态填充到缓存,就不再需要计算lod形态了,我采用的就是这样的算法,能很有效的避免lock unlock,另外这点内存上的开销在空间上几乎是一次性的开销,其实非常的小,不必在意的。

lod影响的因素如果考虑起伏分布,的确是个高级话题,暂且还没考虑这些要求,但如果做个地理信息系统的时候,确实就很有必要了。
2009-01-28 10:41 | 李侃

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

请问LZ,对于33 * 33的block来说,这些索引是用程序生成的,还是画出图来手工计算的啊,对于优化的索引来说程序生成很困难,手工计算量又很大,怎么办啊,谢谢
2009-11-21 09:05 | 何彪

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

当然是用程序来生成索引了,我现在已经改用17x17的规格了,33x33有点大了
2009-11-23 09:31 | 李侃

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

哦,33 * 33 大了吗,听说比较平坦的地形可以使用比较大的分块,是不是啊

你的地形是用的是三角带还是三角列表啊,我本来想使用三角带的,但是现在还是打算用三角列表(比较好优化),我知道block的渲染为了避免裂缝分为两部分,一个主体,一个是连接体,对于主题部分来说他是很整齐,用程序生成比较好做,但是对于连接体来说,考虑到索引的优化,这个不好计算啊,请问LZ是怎么做到的啊,谢谢

2009-11-23 10:05 | 何彪

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

就是个细致活,多画画图,找找规律,自然就能发现其中的拓扑结构了,就是用程序生成索引,然后缓存索引,别无它法,完全避免重复无谓的lock,unlock
2009-11-23 21:08 | 李侃

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

哦,谢谢LZ,某还有个问题,拜读上文知LZ好象只在一个tile里对block使用四叉树剔除,而对36个tile则是使用距离判断来做剔除,速度上有优势,我也打算这么做,但是我有个没有想明白的地形,这样的话tile和tile之间就会有可能出现裂缝,就象是下图:
tile0
--------------
tile1

tile0 和 tile1 是上下相邻的两个tile,tile0最下面的 block 和 tile1 最上面的block 没有进行彼此的LOD判断,我想知道LZ大哥是怎么解决的,谢谢!!
2009-11-26 09:55 | 何彪

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)[未登录]  回复  更多评论   

tile和tile之间貌似可能出现裂缝,如楼上那位仁兄所说,不知道LZ怎么处理的,望赐教哈 O(∩_∩)O~
2010-07-11 17:28 | Ice

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)  回复  更多评论   

设定好阀值是不会出现裂缝的,我现在引擎正在用dx10重构,地形这部分我现在重新整理,已经有了很好的提升方法,我目前在考虑9宫之外的tile整体lod输出,9宫格内的按block lod 输出,9宫之外的tile加载的数据非常少,可视距离可以扩展2到三围tile的范围,这样能够花较少的代价看到更多更远的地形细节,也就是看的更远,这部分提升空间蛮大的。
2010-07-21 12:46 | 李侃

# re: 过去写的发布在GameRes的文章,无限lod地形的构想(如今已经不是构想,用的很爽了)[未登录]  回复  更多评论   

裂缝的问题我已经解决了,现在把自己写的UI系统和超大地形整合到了一个demo中,看起来还真有一点点感觉了 O(∩_∩)O~
2010-07-21 22:31 | Ice

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理