U3Terrain的一个BUG及修正
来源:互联网 发布:星星知我心电视剧1集 编辑:程序博客网 时间:2024/05/19 23:10
不知道有人遇到了没。U3的Terrain系统,在层数高于5层后,一定会出现一个BUG——6层时,当你开始对第1、2层的过渡进行涂抹时,就一定会发现,整个地形以统一的Alpha给第2层和第1层来了个过渡,无论你怎么刷,这个Alpha都不会变。
跟踪资源,发现两张Weight Map都在,第一张描述了2-3、3-4、4-5、5-6四层,第二张描述了1-2。资源这里没问题,跟踪游戏流程,数据直到提交到渲染线程之前,都是对的,Alpha Map的生成完全没有问题。
那么问题在哪里呢?
用PIX跟踪,发现是6层后,因为U3使用了两张Weight Map权重图,来描述各层混合,问题就发生在这里:用于描述第1、2层之间Alpha的图,也就是第二张Weight Map不翼而飞!只留下了一个白白的纹理。在U3中,当纹理资源不存在时,会自动给入一张白色纹理,以提醒用户注意修正。
根据这个信息,重新跟踪流程,发现数据层的Weight Map是存下来的,两张,数据都对,提交到渲染线程后,渲染的Shader Compiler做了一件事,根据当前用到了哪张,而提交哪张。这流程都是对的,因为比如我只涂抹了1-2,也就是只用了第二张Weight Map,那么第1张就根本不应该被提交,否则白浪费了一个Shader Resource Stage。只有我既涂抹了1-2,也涂抹了3-4时,两张Weight Map才应该被提交。
问题是,这里,当只涂抹了1-2时,从传入的表中居然查不到这张Weight Map!!!!传入的表只有一张Weight Map,是第一张,搜第二张当然就搜不到了!
地形数据的表里明明是两张,为什么传给渲染线程就只剩一张了呢?
跟了跟,发现数据在从地形数据到渲染线程的过程中,中间包了一层,就是这层搞出了问题——把第二张根据一个叫做Mask的变量给丢弃了……这点让人很无语,因为Mask这个描述的是用户使用了哪几层,而在这个例子中,使用的应该是1-2这两层,那么,应该是保留第二张啊,为什么要丢弃呢?!
而且,后面渲染线程里既然去查表了,你这里就把表完全拷贝过去不就完了吗?干嘛要随随便便丢弃几层?不给自己找麻烦么?
于是修改了这里,不在根据Mask丢弃了,所有的Weight Map完全保留!
编译,调试——问题解决!
下来以后想了一下,极有可能这个系统是由三个人在维护的,一个人A做了数据层,没问题。一个人B做了渲染层,也没问题。其实,做中间那一层的这个人C,其实除了一个小BUG外,你还真不能说他的立意是错的。
项目开发中经常能够遇到这样的问题,很可怕,每个系统都没有大问题,配合到一起就是问题。接口一看都对,数据一看也没错啊,放到一起就是BUG。
看来,有时候,单单的接口安全也不安全了。 : O
- U3Terrain的一个BUG及修正
- 分享:Microsoft IE Webcontrols Treeview的一个bug及修正
- BugFree 的一个 bug 修正
- 修正o-blog 2.5的一个bug
- 修正TaskManagerEx2.0的一个BUG
- pe_xscan 修正文件时间的一个bug
- 一个有趣的Bug修正记
- 关于h264bitstream的bug修正及完善
- 修正bug的方法
- CCEditBox的bug修正
- [置顶] 我修正的 modalbox 的一个bug
- 今天修正了一个SMD数据库的BUG
- 修正了cgit 项目中makefile的一个Bug
- Linus修正一个内核的mmap data corrupt bug
- 修正了标准工时软件的一个BUG
- C# 修正DataGrid bug引起的问题及反思
- CVE-2017-7269的几个技巧及BUG修正
- 修正XPMenu的两个Bug
- 汉化教程
- GamerClass Shading系统设计【四】需求-扩展性
- jp
- 二级网页打不开解决方案 (轉摘)
- JDeveloper学习笔记
- U3Terrain的一个BUG及修正
- 【C#制作CAB压缩包】压缩解压类
- BCB/Delphi中常用的VCL函数说明
- java字符集笔记
- Groovy探索之MOP 十五 方法名的动态性(1)
- 点击TextBox实现全选,并点击复制到剪贴板中
- 批处理写的五子棋程序
- 图片等多媒体文件插入到表
- 软件架构师和企业家