Practical Occlusion Culling in Killzone 3
7 likes•10,944 views
The document discusses the implementation of an occlusion culling system in the video game Killzone 3, highlighting the use of software rasterization for improving performance in large environments. Key topics include the technical details of the culling mechanism, how to select effective occluders, and the challenges in automating the occluder creation process. The findings reveal that while software rasterization offers efficiency, achieving optimal occluders requires significant artist input and careful planning during content creation.
Practical Occlusion Culling in Killzone 3
- 2. Practical Occlusion Culling in Killzone 3 Michal Valient Lead Tech, Guerrilla B.V.
- 3. Talk takeaway Occlusion culling system used in Killzone 3 The reasons why to use software rasterization (Some) technical details How to pick good occluders Q&A
- 4. Talk takeaway Occlusion culling system used in Killzone 3 You’ll love software rasterization (Some) technical details How to pick good occluders Q&A
- 5. Talk takeaway Occlusion culling system used in Killzone 3 You’ll love software rasterization (Some) technical details How to pick good occluders Q&A Huge environments
- 6. Talk takeaway Occlusion culling system used in Killzone 3 You’ll love software rasterization (Some) technical details How to pick good occluders Q&A Armed JetPacks
- 7. Talk takeaway Occlusion culling system used in Killzone 3 You’ll love software rasterization (Some) technical details How to pick good occluders Q&A Giant Spider Robots
- 8. Killzone 3 visibility solution Software rasterization running on SPUs Render occluders into depth buffer –Use simplified version of the scene geometry Conservatively scale down –To make it fit into SPU memory –To make it faster to test against Test all objects against small depth buffer –Test bounding boxes
- 9. Why software rasterization Previous solution did not scale well –Manually placed portals
- 10. Why software rasterization Previous solution did not scale well –Manually placed portals Works automatically –Can be enabled early in production
- 11. Why software rasterization Previous solution did not scale well –Manually placed portals Works automatically –Can be enabled early in production Completely dynamic solution –Any object can become an occluder
- 12. Why software rasterization Previous solution did not scale well –Manually placed portals Works automatically –Can be enabled early in production Completely dynamic solution –Any object can become an occluder Maps well to SPUs –No sync issues –No GPU costs related to visibility testing
- 18. Occluder setup First stage, not parallel Outputs clipped + projected triangles –One list of triangle data –One “index” DMA list per rasterizer job Caches are important at this stage –2KB vertex array cache (90% hit rate) –32-entry post-transform cache (60% hit rate) –Various double-buffered output caches
- 19. Rasterization Split 640x360p depth buffer into 16 pixel-high strips –Rasterize in parallel, one SPU job per strip –Load triangles using the prepared DMA list Traditional scanline rasterizer –Fill internal 640x16 floating point depth buffer Vectorization is the key –Set up three or four edges at once –Generate 4x1 pixels at once –Optimize in assembly
- 20. Rasterization Compress depth buffer –One output pixel is maximum depth of 16x16 block. –But patch single pixel holes first. –Encode as uint16, reserve 0xffffu for infinity Output single scanline of 40x23 occlusion buffer
- 21. Occlusion tests Tests happen in parallel Each object consists of one or more parts First test object bounding box –Skip for objects visible last frame Then test individual parts Continue with submesh culling –Small Spatial Kd-Tree inside most meshes –Allows for culling arbitrarily small mesh chunks
- 22. Occlusion tests Accurate tests –Bounding box rasterization and depth test –Working on small depth buffer, be conservative Fast bounding sphere tests –Precomputed hierarchical reject data –Constant time test for small spheres –Only used for fast reject
- 24. Where to get occluders Aiming for automated solution Originally wanted to use scene geometry –Reduced polygon count –Too many errors, in general does not work Now using physics mesh –Closed, low polygon meshes –Not always conservative in the right sense –Visual mesh can be inside physics mesh causing drops
- 25. Where to get occluders
- 26. How to select good occluders Simple heuristics to identify good occluders –Discard anything which is small –Discard by meta data –clutter, set dressing, foliage, railings… –Discard if surface area is significantly smaller than bounding box surface area Artists can override the process –Still creating the best occluders by hand
- 29. Conclusion Software rasterization is great –Fast on SPUs –Easy to integrate –Very accurate (if occluders are accurate) Creating occluders is hard –Automatic system was not enough –Plan for this in content creation –Define workflow for finding and fixing leaks Voxelization anyone?
- 30. Conclusion Special thanks to Will Vale (Second Intention Ltd) for implementing this system for us.
- 31. Statistics 100 occluders, 1500 triangles Test 1000 objects, 2700 parts Timings –Setup job: 0.5ms –Rasterize job: 2.0ms (on 5 SPUs) –Query job: 4.5ms (on 5 SPUs) –Overall latency: ~2ms
Editor's Notes
- #2: \n
- #3: \n
- #4: I’ll first describe the occlusion system in Killzone 3\n and the reasons why we chose it and why should you\n\nThen I’ll talk about some technical details\n and heuristics for picking good occluders.\n\nAnd I hope we’ll have some time for questions.\n\n... but let’s first take look at what Killzone 3 actually is.\n
- #5: Killzone 3 is a first person shooter released \n earlier this year exclusively for Playstation 3.\n\nAnd it's essentially about space marines trying to escape \n from the planet full of space Nazis.\n
- #6: The game is set in huge detailed outdoor environments…\n Where you can fly around with an armed jetpack...\n And you get to fight giant spider robot.\n Twice.\n\nKillzone 3 is a big game\n and we needed good object visibility solution \n that works well with these diverse settings.\n\n
- #7: The game is set in huge detailed outdoor environments…\n Where you can fly around with an armed jetpack...\n And you get to fight giant spider robot.\n Twice.\n\nKillzone 3 is a big game\n and we needed good object visibility solution \n that works well with these diverse settings.\n\n
- #8: The game is set in huge detailed outdoor environments…\n Where you can fly around with an armed jetpack...\n And you get to fight giant spider robot.\n Twice.\n\nKillzone 3 is a big game\n and we needed good object visibility solution \n that works well with these diverse settings.\n\n
- #9: \n
- #10: We chose to try software rasterization running completely on SPUs. \n \nWe render the simplified version of the level geometry \n into a depth buffer (these are the occluders)\n\nAnd we then use scaled down version of this depth buffer \n to test visibility of all objects or lights in the current view frustum.\n The test itself uses bounding box of the objects.\n
- #11: I'll try to summarize the reasons why we chose this solution \n and I'm sure you recognize some of your own experiences here.\n\nFirst and foremost we saw that our solution based on portals \n does not scale well with the big outdoor levels.\n\nEspecially since our portals were hand placed by artists and we were \n running into production stalls.\n\n Very important issue if you try to create the game in two years.\n
- #12: The process of occluder creation can be made largely \n automatic and can be enabled from the early days of production.\n\nThe whole concept of occluders is very similar to building \n of regular geometry and it's easy to understand by artists. \n\nThis makes it very easy to step in and manually create occluders where needed.\n\n
- #13: Unlike most other approaches, this one is completely dynamic.\n\nAny sufficiently large object on screen can serve as a good occluder. \n If you're hiding behind a destructible barrel or a metal plate in our \n game, it is an occluder.\n\nDoors can open and close and they perfectly block the visibility \n without you having to write special code for such case.\n\n
- #14: Software rasterization maps well onto SPUs - it's easy to distribute \n and SPUs are generic enough to allow us to run complicated object culling logic.\n\nAnd unlike GPU based solutions, you get exact results \n within the same frame without complicated synchronization logic.\n
- #15: Let’s look at the example of how the occlusion system works.\n\n
- #16: If we look from the side, you see we don’t \n render anything behind the closed door.\n\nBut as soon as the door open...\n
- #17: ...we start to render the rest of the visible scene. \n As I mentioned earlier, this \n happens entirely automatically.\n\nAnd since I forgot to record the occlusion \n depth buffer, you’ll have to trust on this one.\n
- #18: We implemented the system as series of SPU jobs.\n Most run in parallel to do the heavy lifting.\n\n
- #19: The first SPU job loads visible occluder primitives and \n outputs clipped and projected triangles for rasterization. \n\nA single list of triangles is shared between the rasterizer jobs, and each job\n has its own DMA list pointing to the subset of triangles it needs to draw.\n\nThe occluder primitives are identical to visual meshes, with vertex and index arrays.\n Therefore we introduced several caches to \n reduce bandwidth and vertex transformation costs. \n This setup is very similar to what you find in a GPU.\n
- #20: We split our depth buffer into 16-pixel-high strips and\n run one rasterize job per strip in parallel.\n\nEach rasterize job loads the list of triangles that intersect with its\n strip using the DMA list prepared by the setup job.\n\nWe perform standard scanline rasterization \n into an internal floating point buffer.\n \nThe rasterize jobs are compute-bound, and the code is \n extensively vectorized to improve throughput.\n Inner loops are written in SPA assembler.\n\n
- #21: For output, we conservatively compress the depth buffer.\n Each output pixel is the maximum depth value of a 16x16 pixel tile in the depth buffer.\n\nBefore compression, we patch single pixel holes to avoid leaks \n when the occluders are not water-tight.\n This is a bit of a cheat, but it’s necessary otherwise\n such hole pushes the tile way into the background.\n\nThe last step encodes depth into 16 bits, \n Occluder frustum is shorter than visual frustum so we \n reserve one bit for points behind occluder far plane.\n\n
- #22: The last step is the actual visibility testing.\n We have one job that gathers all objects in the camera frustum\n and then spawns an occlusion test job for each batch of objects.\n\nWe have a two level hierarchy of objects and meshes\n objects live in the scene, and meshes are what we send to the GPU.\n We test objects first to avoid testing meshes.\n\nIf a mesh has many triangles, we can continue with submesh culling.\n This uses the mesh’s Kd-tree to cull away whole ranges of mesh triangles.\n Visible meshes form new primitive sent to GPU.\n\nThe output of these jobs is the final result of the occlusion query, and is sent for rendering.\n\n
- #23: We have two kinds of visibility test we can use to cull objects and parts.\n\nThe basic test is the most accurate, but also the most expensive.\n It rasterizes a bounding box with depth testing against the small occlusion buffer.\n\nWe also have constant-time tests for small objects.\n We precompute several versions of the occlusion buffer by \n conservatively dilating the depth values.\n This allows us to perform very quick bounding sphere tests.\n\nIf an object passes the fast test, or if it is too large, we do the accurate test.\n\n
- #24: In the final part of the presentation I’d like \n to explain how we create occluders.\n\n
- #25: We didn’t want artists to hand-make occluders \n for the entire level, so we looked for an automatic solution.\n\nWe experimented with using visual meshes,\n but the good polygon reduction proved \n to be difficult to get right.\n\nPhysics mesh is much better choice.\n It’s available for each mesh in the game\n and it’s cleaned and sufficiently low polygon count.\n\nUnfortunately the physics meshes can be slightly larger \n than visual meshes causing objects to disappear.\n Worst offenders have to be fixed manually.\n
- #26: Here’s an example of occluders \n generated automatically from physics mesh.\n You can notice there’s some unnecessary detail, \n but in general the quality is pretty good.\n
- #27: Even using physics mesh there was too much occluder geometry.\n\nWe needed to reject occluders that were unlikely to \n contribute much to the occlusion buffer.\n Our simple heuristics rejects all small objects or \n objects where the name suggests that they are not good occluders.\n\nWe also reject meshes whose surface area suggests\n that they are thin or with too many holes.\n\nArtists can of course step in and override the heuristics\n or provide their custom occluders for difficult cases and optimization.\n
- #28: Here’s an example of KZ3 multiplayer level where the \n automatic heuristics did not work well.\n
- #29: And here’s the highly optimized occluder mesh created by artist.\n
- #30: We like this system, it’s simple, efficient and fits well with our pipeline.\n\nUnfortunately the content creation proved to be a problem.\n The automated solution did not work well enough in some cases\n and artists had to create custom occluders for entire levels.\n Luckily the geometry is easy to create.\n\nUsing scene voxelization might be a good way \n to generate simple, robust occluders automatically.\n
- #31: I’d like to thank Will Vale for implementing the \n system for us and help with this presentation.\n
- #32: Questions?\n