atenza
场景的基本结构
 
1) 基础地形层 -- 指打底的大地皮,一般是一个体积很大的Mesh,如果是地宫或天空城场景,就没有大块地皮了,可能只是一个远景大平面
2) Ground物件层 -- 可以在上面行走的物件,比如桥,建筑地板,阶梯,祭坛等
3) 其他物件层 -- 非阻挡层与阻挡层,也包括特效等
 
坑1、地形切片
 
地形切片后面被证明是没有必要的。手游来说,业界通用的做法是先用Unity的Terrain工具刷出一个精度比较高的地形,然后用大家都熟知的T4M插件(Terrain for Mesh)专制成Mesh,美术人员再将这个Mesh导出到3dMax进行优化(细节比较丰富的部分增面,大平面的部分减面),这样我们就可以得到一个面数不是很高的地形,直接放在要加载的Level里面就行了。
地形切片主要用于大规模的场景动态加载,然而这在手游上基本是用不到的(因为手游的地图不会大到哪里去)。之前看到的《天子》是有用的这种方式,最近新出的网易手游《天下》也是,不过人家用的是自研引擎。似乎这块是自研引擎都一贯具备的。天子我觉得也是由蜗牛自研引擎的一些理念延伸过来的。
不过大多还带着一些LOD,这块没有接触过。
天子的切片做法,大概是底下几个过程:
1) 用Unity自带的Terrain工具刷出地形,然后根据地形精度(顶点密度)的设置用射线照射的方式拾取地形的顶点数据,并收集地形的lightmap数据、贴图混合数据、地形上的物件放置数据。按照固定大小的地形块分组,将这些信息存放成二进制文件。
2) 游戏运行时,通过这些二进制文件数据重新构建玩家周围的地形,以及地形上的物件。玩家走动,其范围的地形也会随之构建加载出来。地形的构建也是一个比较繁杂的过程
3) 已经加载过的地形,就保持在场景中,并对其已经渲染的材质贴图进行拍照,更换另一个简单的shader,后续直接使用这个简单的shader渲染
 
最近接触了一些手游,发现对于场景的处理有以几种风格
1) 将建筑放很大,让整个场景变得很宏大的样子,物件也有LOD,实现起来性价比很高,然而建筑的贴图精度一般比较渣。比如六龙为代表的一系列游戏(不过角色制作比较华丽),这类游戏喜欢做自由视角

2) 定视角2.5D的,因为是定视角,可以通过错位的方式来处理场景物件(不过大部分2.5D没有做到这个份上,对美术要求比较高),让物件显得精度很高,天子就是这么做的,看过一篇文章,暗黑也是这种做法,不过局限就是不能转视角,一转就穿帮,现在要求能转视角貌似是比较基本的需求。项目也要开始转视角了

 


坑2、lightmap
lightmap简介:
其实通过实现把一些不动的静态的实时光烘焙到场景的贴图上面,在实际运行丢弃实时光源,直接混合光照贴图,实现光照的效果。

 

Unity的lightmap支持还是不错的。虽然坑不少,

比如需要开启Mesh的GenerateSecondUV选项来启用UV2,否则不同电脑解析lightmap有可能会出错,无法复用
比如某个版本的Unity解析不同平台的lightmap数据也会出错
比如lightmap的Auto选项会出现不少问题,场景反射源的影响有时候会莫名丢失
比如Unity自带的standard光照模型帮我们处理了lightmap与原来贴图的混合,但如果我们使用4张贴图混合的shader,在iOS上居然会出现噪点,换成lambert光照模型居然就OK了
 
坑3、场景高度图
项目的场景其实是二维的,也就是只有x,z平面,不会出现在Y轴上的物体逻辑上重叠的情形。
当前生成高度图的方法是做按照高度图的精度等距离做RayCast射线,采集一份二维高度图。实际使用的时候,再根据玩家当前位置在二维高度图上做二次插值来获取高度数值。
生成高度图最为蛋疼的地方就是要指定哪些物件是可以被玩家踩在脚下的。目前还是手动指定的,比如一些有略微抬高的圆形石板,人物需要走在上面,就要给这个石板附一个collider(没有collider,Raycast就无法识别),另外还要设置成Ground层(只有Ground层的Object会参与高度图拾取),但是比如有一些GameObject,只有一部分是可以踩在上面,如图:

这个就比较蛋疼,得自己手动放一个BOX到龙骨的中间可行走区域,然后用这个BOX来龙骨参加高度拾取

类似的问题还有这个场景,破船坑坑洼洼的,拾取出来的高度也是坑坑洼洼的,没法用啊,只能再自己用一个plane盖在上面代替甲板去参与高度拾取
 
这个过程目前没有什么比较好的方式,原来还想过写代码通过物件的Transform特征来自动识别属于可以行走在上面的GameObject(比如包围盒长宽数值,比例),感觉有点不大靠谱 
 
坑4、NavMesh
Unity自带的NavMesh有比较全面的工具支持,然而接口的问题坑也是很多,由于无法看到和修改源代码,我们只能在调用其API这层做一些取巧的操作来规避
1) 摇杆碰撞障碍问题
2) 斜坡RayCast获得脚下点的问题
3) 地形上的小山坡不能走?
4) NavMeshAgent接管寻路的各种问题   --  后面直接使用NavMesh的接口来做单纯的寻路
总结了一下,发现NavMesh在有高度起伏的场景中烘焙,会出现诸多问题,决定自己构建一个水平面,然后在这个水平面基础上烘焙NavMesh来规避这个问题(WalkLayer),这种做法也得益于项目的场景逻辑上是二维的
 
坑5、物件Bound识别
。。。。。。。

分类:

技术点:

相关文章:

  • 2021-07-24
  • 2021-08-09
  • 2021-12-10
  • 2021-06-06
  • 2021-05-08
  • 2021-07-22
猜你喜欢
  • 2022-12-23
  • 2021-08-08
  • 2021-12-11
  • 2021-07-04
  • 2022-12-23
  • 2021-07-14
相关资源
相似解决方案