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
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
