Boosting Frame-rates in Unity Games Using Umbra 3
•Download as PPT, PDF•
6 likes•2,652 views
A presentation I gave in the Unity Developer Day during GDC 2014. I explain how you can best use Umbra to improve frame-rates in your Unity games.
Recommended
Recommended
More Related Content
Featured
Featured (20)
Boosting Frame-rates in Unity Games Using Umbra 3
- 1. 1 SAMPO LAPPALAINEN UMBRA SOFTWARE Boosting Frame-rates in Unity Games with Umbra 3
- 2. 2 UMBRA SOFTWARE OCCLUSION CULLING MIDDLEWARE FOR TRIPLE-A GAMES RELATIONSHIP WITH UNITY STARTED IN 2010 FOUNDED IN 2007 14 EMPLOYEES BASED IN HELSINKI, FINLAND SUPPORT OFFICE IN SEATTLE, WA SAME PROBLEM – DIFFERENT SOLUTIONS “Level artists are there to fill the world with content. Integrating Umbra saved us not only artist time but the time to create and maintain an efficient visibility culling solution. Umbra’s support provides us with the solutions and features that we need.” “Umbra’s technology is playing an important role in the creation of our next universe, by freeing our artists from the burden of manual markups typically associated with polygon soup.”
- 3. 3 Video Games Powered by Umbra 3
- 4. 4 CHECK OUR PRESENTATION THURSDAY 2:30PM ROOM 301 SOUTH HALL
- 5. 5
- 6. 6
- 7. 7
- 11. Umbra 3 in a Nutshell
- 13. VISIBILITY DATA GENERATION 1. CONVERT INPUT POLYGON SOUP INTO VOXELS 2. GROUP EMPTY SPACE VOXELS INTO CELLS 3. COLLECT OBJECTS IN CELLS 4. GENERATE PORTALS BETWEEN CELLS TOME OF VISIBILITY
- 14. RUNTIME BASIC OPERATION AS IN A TRADITIONAL PORTALS AND CELLS SYSTEM 1.FIND CELL THAT CAMERA IS IN 2.TRAVERSE PORTALS-AND-CELLS GRAPH 3.GATHER VISIBLE OBJECTS IN CELLS GENERATES AN OCCLUSION BUFFER FOR DYNAMIC OBJECT TESTING
- 15. Umbra 3 in Practice
- 16. WHAT IS NEW UNITY 4.3? • SIMPLIFIED INTERFACE • INCREMENTAL BAKE • POINT LIGHT AND SPOT LIGHT CULLING • SHADOW CASTER CULLING • MASSIVE RUNTIME PERFORMANCE OPTIMIZATIONS
- 17. SMALLEST HOLE MORE DETAILED INPUT GEOMETRY SLOWER BAKE HIGHER BAKE MEMORY USAGE LESS DETAILED INPUT GEOMETRY FASTER BAKE LOWER BAKE MEMORY USAGE
- 18. SMALLEST OCCLUDER LARGER DATA SLOWER QUERY LESS CONSERVATIVE SMALLER DATA FASTER QUERY MORE CONSERVATIVE
- 20. BACKFACE THRESHOLD SMALLER OCCLUSION DATA LESS VISIBLE BACKFACES IN SCENE MORE UNDEFINED AREAS LARGER OCCLUSION DATA MORE VISIBLE BACKFACES IN SCENE LESS UNDEFINED AREAS
- 21. VISUALIZATIONS
- 22. Further Reading
Editor's Notes
- Hello everybody. My name is Sampo Lappalainen and I work for Umbra Software. Thank you all for coming to this last presentation of the day. Our presentations are typically very tech heavy as is our software, but I try to keep things as practical and hands on as possible. So I’m here to talk about how you can use occlusion culling to improve the frame-rates of your unity games. I’m going to explain the basics of how the system works and then give a few very specific tips on how to tweak it for the best performance. There’s not enough time to cover every aspect of the system in a complete detail so I’m going to leave time for questions after the presentation so we can address the most interesting aspects for you all.
- A little bit of background. (soap story) Umbra software is an independent team of computer graphics geeks based in Helsinki, Finland Our customer base mostly consists of triple-A games studios, but obviously as I’m up here, we have some entanglements with mobile and smaller-scale productions as well. We’ve been happily married with Unity since 2010, so that’s 5 years already! As a matter of fact, we’ve been partners with Unity pretty much throughout the entire devcycle of Umbra 3, the tech I’m here to talk to you about. We have kept going at it since 2007 – and individually even before that.
- Before I dive in into further into the technology let me just quickly give you some context by showing some of the video games the Umbra technology is used to power-up.
- This is little title was released today and we’re proud to be part of it on PC, xbox one and ps4.
- ...this powerful technology is available to you. In Unity 4.3 (Pro). To make your games run better.
- Doing this allows you to add more detail to the visible part of the world in the same frame budget! In short, better looking games that run faster. Not all 3D games or environments will significantly benefit from occlusion culling. Games with top-down views, mostly transparent elements or stationary cameras etc.
- Doing this allows you to add more detail to the visible part of the world in the same frame budget! In short, better looking games that run faster. Not all 3D games or environments will significantly benefit from occlusion culling. Games with top-down views, mostly transparent elements or stationary cameras etc.
- This is a high level overview on how the visibility data generation works. The first step is to create a voxel grid out of the incoming polygon soup. Voxels because: No issues with floating point accuracy or small modeling issues -Can choose the granularity at this we operate that is independent on the complexity of the input Visibility cells are built by grouping empty-space voxels. For each such group of empty voxels, we collect the objects that they touch and generate 2D rectangle portals for where they touch neighboring cells. The magic happens in the next step (5), where we analyze what we have and iteratively remove portals from the data that do not contribute to occlusion in a significant way. Removing portals causes cells to be collapsed together. We could keep removing portals to hit a given budget, but even better we can remove portals up to a certain threshold of how much conservativity we are willing to accept in the result. The final piece of the puzzle is that we need to be able to tell in which cell a given query point is. For this, we simply take the voxelization and build a KD-tree for the cells. We call the output of this process a ”tome” – a tome of visibility..
- The other part of the solution is the runtime query module. The basic principle of operation is very much like what a traditional portal culling system does. We find the cell that we are in from the cell KD-tree. This is O(log(n)) cheap. Then we traverse the graph, limiting visibility to cells by processing portals as we go. As we traverse, we collect objects from cells and test against currect visibility. The big difference is that instead of recursively traversing and clipping the frustum, we rasterize the encountered portals into a per cell occluder mask. This allows us to proceed in a breadth-first fashion, not having to process each cell multiple times. Since we are rasterizing anti-occluders instead of occluders conservative rasterization in lower resolution becomes easy, we can always grow primitives without producing errors. The whole query can be pretty trivially parallelized by subdividing in screen space and processing each sub-frustum separately. In addition to returning a list of visible objects, we also build a global 16-bit depth buffer as the result of the traversal. This can then be used for additional visibility tests for dynamic elements. To make this is easy as possible to integrate, we’ve made this run in fixed memory of around a hundred kilobytes. Also there is no state stored from one query to the next, every execution starts fresh. This is particularly important for being able to run multiple queries for multiple views in a flexible fashion.
- We simplified the interface by hiding a lot of stuff from the interface. For instance, only Smallest hole, Smallest Occluder and Backface Threshold are visible.
- The input is controlled using the smallest hole parameter. When voxelizing the occluder geometry, smallest hole maps almost directly to the voxel size. This means that if your geometry contains intentional holes, gaps or cracks that you wish to see through, using a smallest hole smaller than these is a good idea. On the other hand, a lot of the time the geometry contains lots of unintentional cracks that you do not wish to see through. A reasonable voxel resolution will patch these up. It may help to think about smallest hole as the “input resolution” of the bake. Note that setting smallest hole into a ridiculously small value means that baking will be unacceptably slow and/or take up a monumental amount of memory in the editor. In some rare cases, it may even cause the bake to fail due to insufficient memory. Then again, while using a larger value will be faster and more memory-friendly, it may cause Umbra to not see through things like grates or fences. So bigger isn’t always better either. In general, a smallest hole as large as possible without visible errors is desirable. In practice, we’ve found that values between 5 cm to 50 cm work fairly well for most games where the scale is “human-like”. The default value in Unity is 25 cm, and it’s a good starting point.
- While smallest hole mostly deals with what type of input geometry you have, smallest occluder determines what kind of output data is produced. In essence, you can think about smallest occluder as the output resolution of the data. The larger the value, the faster it is to perform occlusion culling in the runtime, but at the cost of increased conservativity (false positives). The smaller the value, the more accurate results are generated, but at the cost of more CPU time. Obviously higher-resolution data will mean a larger occlusion data size as well.
- In most games, keeping smallest occluder slightly larger than the player, so around a few meters, is a good default. So anywhere between 2 and 6 meters may make sense if your game’s scale isn’t microscopic or galactic. The default value in Unity is 5 meters.
- Perhaps the most difficult parameter to grasp is called backface threshold. While in many cases you don’t really need to change it, there are some situations in which it may come in handy to understand how it affects the generated data. First, it’s important to note that the parameter exists only for a single purpose: occlusion data size optimization. This means that if your occlusion data size is OK, you should probably just disregard backface threshold altogether. Second, the value is interpreted as a percentage, so a value of 90 means 90% and so on. Umbra uses the occluder object triangle winding information to optimize for its data size. Any location within the scene where the ratio of visible triangle backfaces to visible front faces is larger than the assigned threshold is deemed to be invalid. So for instance, the parts under the terrain or inside solid occluders can be removed from the output data.
- The purpose of the Visibility Lines visualization is to show you the line of sight that Umbra sees. The way it works is that Umbra will project its depth buffer back into the scene and draw lines to the furthermost non-occluded points in the camera’s view. This may help you to figure out, for instance, which holes or gaps cause “leaks” in occlusion, ultimately causing some objects to become visible. This may also reveal some dubious situations where some object that clearly should be a good occluder, doesn’t occlude anything because of, say, forgetting to enable the static occluder flag for the object.
- Describes the Umbra algorithm in more detail A great troubleshooting guide