{"id":554,"date":"2017-07-30T22:27:27","date_gmt":"2017-07-31T05:27:27","guid":{"rendered":"https:\/\/invader.trystorymachine.com\/?p=554"},"modified":"2017-11-23T10:51:23","modified_gmt":"2017-11-23T18:51:23","slug":"custom-occlusion-culling-in-unity-improved","status":"publish","type":"post","link":"https:\/\/invader.trystorymachine.com\/?p=554","title":{"rendered":"Dev Diary: Custom Occlusion Culling in Unity Improved"},"content":{"rendered":"

Back in 2014 I wrote about the custom occlusion system<\/a> we built\u00a0for DEAD SECRET. \u00a0It’s a pretty simple system that works by knowing all of the places the player can stand ahead of time. \u00a0It allowed us to cut our draw call count way down and ship high-fidelity mobile VR nearly two years ago. \u00a0But DEAD SECRET CIRCLE<\/a>, the sequel to DEAD SECRET that we announced last month (check the teaser<\/a>!), has a lot of new requirements. \u00a0One major change is\u00a0the ability to move around the environment freely, which the DEAD SECRET system didn’t support. \u00a0We needed\u00a0a new way to manage occlusion for this title.<\/p>\n

First we tried to leverage Unity’s built-in occlusion system, which is based on Umbra<\/a>, an industry-standard tool that’s been around for over a decade. \u00a0But Unity’s interface to this tool is exceptionally restricted, with very few controls available. \u00a0The values that are exposed are hard to understand in terms of world units (the internet theorizes<\/a> that the scale value is off by a factor of 10), and in some cases the documentation Unity provides is misleading and\/or false. \u00a0While Unity’s built-in culling does work (very well!) in some cases, it is hard to understand why it fails in others. \u00a0The debug visualization adds to the confusion: when a “view line” passes straight through a wall, are we supposed to believe that the debug view is inaccurate, or the occlusion has broken, or that this is the way it’s “supposed” to work? \u00a0After about six months of trying to get by with Unity’s occlusion system, I gave up and decided to revisit the custom tech\u00a0we wrote for DEAD SECRET.<\/p>\n

\"KARLOFFlogo\"Robot Invader’s internal technology stack is called KARLOFF, and it has had a hand in every game we’ve shipped since our first in 2011. \u00a0The great thing about a mature technology stack is that we can build new tools very quickly. \u00a0Using existing KARLOFF tech, we built a new version of our occlusion system in less than a week.<\/p>\n

Our new system is still based on rendering panoramas and color-coding geometry to find potentially visible geometry sets from a given point in space. \u00a0But for a world in which the camera can move freely, we need a lot more points. \u00a0We also need a way to map the current camera position to a set of visible geometry. \u00a0All of a sudden this system goes from being a simple occlusion calculation to computing a full-blown\u00a0potentially visible<\/em>\u00a0set<\/em><\/a>.<\/p>\n

My goal is always to trade build time and runtime memory (both of which we have plenty of) for runtime performance (which we are always constrained by). \u00a0Therefore this system uses a 3D grid (as opposed to a BSP or kd-tree, which are common for this purpose) that can index into a set of visible geometry in O(1) at runtime. \u00a0The world is cut up into grid cells\u00a0and a panorama is rendered for each. \u00a0The resulting geometry information is stored back to the grid and then looked up as the camera moves through the scene at runtime. \u00a0Simple, right?<\/p>\n

Well, the devil is in the details. \u00a0There’s a trade-off between cell\u00a0size, accuracy, and bake time. \u00a0Very small cells\u00a0(say, 0.3 meters per side) result in highly accurate occlusion but take a long time to bake. \u00a0For DEAD SECRET CIRCLE\u00a0our primary goal is to cut entire rooms and building floors that are on the other side of a wall away, not to occlude small objects within the frustum. \u00a0We can get away with a larger cell\u00a0if we render occlusion from several points within the cell\u00a0and then union the results into a single set. \u00a0We actually need to do two passes, one with transparent geometry hidden and the other with it opaque (in order to catch both the objects behind a transparent surface and the surface itself). \u00a0Here’s an example of these two passes rendered from four different points within a cell.<\/p>\n

\"Last<\/p>\n

The output of this boils down to a bunch of lists of MeshRenderer pointers that get enabled and disabled as sets are selected. \u00a0It’s also necessary to do another set of renders for every occlusion portal (e.g. a door that can be opened or closed) so that we can adjust the visibility of the objects on the other side when the portal is opened at runtime. \u00a0At this point we have a fully functioning, highly accurate occlusion system that is nearly free at runtime.<\/p>\n

But there’s a catch: this method relies on walking a texture like the one above and picking colors to match to mesh. \u00a0At 1024×512 per panorama (which seems to be the minimum resolution we can get away with based on the size of our objects in the world), a full transparent \/ nontransparent pass from four points results in a 4096×1024 image. \u00a0With a 1x1x1 cell\u00a0size\u00a0we end up with about 450 cells for this small apartment level, which is\u00a01,426,063,360 pixel compares. \u00a0Add in more passes for portals and this time starts to grow exponentially. \u00a0Plus, 1x1x1 might not be small enough for perfect accuracy–we get better results with a 0.5 unit square cube, which on this level takes nearly 20 minutes to compute. \u00a0I know I just wrote that I was willing to trade build time for runtime performance, but 20 minutes to compute occlusion is unreasonable.\"Cell<\/p>\n

There are probably some smart ways to tighten the algorithm itself up. \u00a0I managed to achieve a 5x speedup by optimizing just the inner pixel compare loop. \u00a0But part of the problem here is the design: the cell sizes are of fixed size and sometimes intersect with walls. \u00a0Cells have to be fairly small to prevent objects from the other side of a wall from being pulled into the set. \u00a0Plus levels that aren’t rectangular in shape end up with a lot of cells in dead areas the camera will never go, rendered for no reason.<\/p>\n

The next iteration of this system is to stop blindly mapping the entire level and instead restrict cells to hand-authored volumes. \u00a0Unity even provides a useful interface for this with\u00a0the fairly mysterious Occlusion Area. \u00a0Exactly how it works with Umbra is the topic of some debate (compare Intel’s documentation<\/a> about the use\u00a0of Occlusion Areas to Unity’s own), but for our purposes we’re just using it as a way to size axis-aligned volumes in the world. \u00a0Each Occlusion Area produces an “island” of cells, and when within an island the camera can still find its cell in O(1). \u00a0Occlusion Islands don’t need to be the same resolution. \u00a0In fact, the cells don’t even need to be cubes any longer. \u00a0We can expose controls to control the granularity of the world per axis, resulting in rectangular volumes. \u00a0Why compute extra cells near the ceiling if the camera isn’t ever going to go up there?<\/p>\n

\"ezgif.com-optimize\"<\/p>\n

So now we have something that looks like a real occlusion system. \u00a0It handles transparent objects, occlusion portals, and can be easily controlled on a per-area basis by breaking the world up into islands of culling information. \u00a0By tuning the granularity per island the apartment area above went from 20 minutes to bake down to a very reasonable 1.5 minutes. \u00a0This system can still be improved, and it doesn’t solve for dynamic objects at all, but already we’re achieving better results than we were able to after months of twiddling with Unity’s built in occlusion system.<\/p>\n

DEAD SECRET CIRCLE is scheduled to come out this year. \u00a0Follow us on twitter<\/a> for more information,\u00a0or sign up to the mailing list<\/a> to get updates as they come out.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Back in 2014 I wrote about the custom occlusion system we built\u00a0for DEAD SECRET. \u00a0It’s a pretty simple system that works by knowing all of the places the player can stand ahead of time. \u00a0It allowed us to cut our … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16,11,15],"tags":[],"class_list":["post-554","post","type-post","status-publish","format-standard","hentry","category-dead-secret","category-game-engineering","category-unity"],"_links":{"self":[{"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=\/wp\/v2\/posts\/554","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=554"}],"version-history":[{"count":2,"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=\/wp\/v2\/posts\/554\/revisions"}],"predecessor-version":[{"id":566,"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=\/wp\/v2\/posts\/554\/revisions\/566"}],"wp:attachment":[{"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=554"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=554"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invader.trystorymachine.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=554"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}