`
dogasshole
  • 浏览: 843389 次
文章分类
社区版块
存档分类
最新评论

Culling the Battlefield Data Oriented Design in Practice

 
阅读更多

http://publications.dice.se/attachments/CullingTheBattlefield.pdf

相当hardcore的介绍了dice怎么做cull的


scene数据,battlefield常常是有15000+的object,用新的方法,得出的数据是:

  • 360:1.55ms
  • i7:1.0ms
  • ps3:0.85ms
  • spu:0.63(spu太变态了)

使用简单的格子来做划分,AABB用bounding sphere来加入grid的obj列表中,并以此做frustum culling。

grid划分几个类别:

  • render dynamic
  • render static
  • phyx static
  • phyx dynamic

加减obj的时候

  • 加就用prealloc的数据,不够了再加
  • 减的时候用swap,然后count--的方式,高效的保持数据的紧密

然后就是数据简单到死,然后culling过程也很暴力,直接几个for,木有树状结构的操作。

culling函数里面很多条件判断,这个很费,于是用vmx还是sse的代码来优化,相当hardcore(这部分先记下,后面用到的时候再研究)。


project to screen space

这个很棒,会把aabb或者bounding sphere project to screenspace,如果面积小到一定程度就直接skip,这个以前还真没想过,nice!

这样就避免了subpixel这一类的东西的生成。


software occlusion

在一些大的建筑,地形这一类的用美术预先放好的occluder,然后cpu做一个大约256*111的render target,把bounding sphere弄上去,query一把(cpu端操作)不再里面就skip。

经过时间的考验,这招一直很给力。

上个图:场景这样

对应的software occlusion 这样:

蛋疼的爱写software renderer的这下有实际用武之地了。

这么一搞cpu端和gpu端都可以省(如果cull的比较多的话)


最后引用两句话,最近的工作经验对此极其赞同:

  • it's all about data
  • simple data often means simple code
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics