Language

Iterative baking of Occlusion and NavMeshes

A lot of cool stuff was developed during Ninja Camp VII. One of the projects targetted the baking of NavMeshes and Occlusion data.

Wouldn’t it be cool if the navmesh and occlusion data was just computed automatically, in the background when the level is edited – giving almost instantaneous visual feedback? A bake has the unfortunate property that the time it takes is proportional to the size of the loaded scene, even if the last change is tiny and localised. This can seriously hurt turnaround time (and the trips to the coffee shop whilst waiting for a bake).

Incremental baking addresses this issue by breaking the world up into tiles and recomputing tile data on the fly, utilising idle cores in your workstation. The system continuously monitors the loaded objects and computes unique hashes for them. As soon as a hash changes – due to, say, a transformation change – the tiles that are affected are recomputed asynchronously on a low priority thread – and once finished – the new results are integrated seamlessly. Even on larger levels like AngryBots this leads to interactive editing of NavMeshes allowing you to carefully tweak the positions of objects and getting near instant visual feedback of the layout of the navigation mesh.

On top of this, the hashed data will be added to the cache server such that when you load up a level edited by a team member the baked tile data can be instantly pulled from the server. Take a look!

Comments (15)

Some really fantastic articles on this web site, thanks for contribution. “For today and its blessings, I owe the world an attitude of gratitude.” by Clarence E. Hodges.

Perfect Party

December 17, 2012 at 2:07 am /

It’s actually a cool and useful piece of information. I am happy that you simply shared this useful info with us. Please keep us informed like this. Thank you for sharing.

Kamil A

December 3, 2012 at 9:51 am /

Thanks for replying.

I did try it but unfortunately it ended up being impractical in our workflow for a couple reasons;

– Centralizing the PVS data into the main scene meant we couldn’t use assetbundles for our “optionnal” scenes (streamed on demand), the main scene would become bloated with unused data

– Really a pain for debugging huge projects, some of our scenes are really complex (thousands of objects) and the Editor slows down to impractical speeds when everything is loaded. (Comp is a six core i7 980 @ 3.33Ghz)

– (lesser) Using the same View Cell Size for one huge scene was not optimal; mixing indoor / outdoor

Joachim Ante

December 3, 2012 at 8:46 am /

“Question though; If it can additively / subtractively change data on Occlusion PVS, can it possibily work per-scene instead of per-project? Currently, you can only bake the data on one scene and thats it. No occlussion on anything else in the project. ”

Have you tried scripting the bake process. You can load all scenes that can be loaded additively together using EditorApplication.LoadLevelAdditive and bake it into a “main” scene.

At runtime you can load the “main scene” using Application.LoadLevel and you load associated levels using Application.LoadLevelAdditive. This way the baked data for all levels is always present.

This is not a perfect solution for working with multiple scenes that can be additively loaded together at runtime, but it works. Optimally we can find someway of making this kind of workflow of working in multiple streamed scenes be builtin and very smooth.

Kamil A

December 3, 2012 at 6:45 am /

Pretty awesome!

Question though; If it can additively / subtractively change data on Occlusion PVS, can it possibily work per-scene instead of per-project? Currently, you can only bake the data on one scene and thats it. No occlussion on anything else in the project.

Many project have multiple scenes and it’s not nescesarly pratical to merge everything into 1 huge scene so right now, the rule is that “If you have multiple scenes; Occlusion is almost useless” This kind of defeats the purpose of having mutliple scenes.

Something on the level of lightmaps, where you can bake per-scene but AddLevelAddtive without any problems would be awesome =)

This is going to be great once it’s released! If it works during runtime then you could now make more dynamic levels. You could have dynamic-obstacle-events like falling boulders and whatnot. One thing I would like is if you could have the NavMeshes generate at more angles so you could be able to walk on ceilings if that’s part of your game.

lorenzo cambiaghi

December 2, 2012 at 4:10 am /

would be nice to be able to run complex processes (beast-occlusion-navmesh-etc..) on multiple render farms

Matt

December 2, 2012 at 3:27 am /

This looks brilliant! Excellent work guys!

Would love to hear about more Ninja Camp projects being worked on.

Joachim Ante

December 1, 2012 at 4:55 am /

For runtime usage we want to focus on support carving out of the existing NavMeshes.
Our plan is to extend the NavMesh obstacles with an API that can carve polygons out of the existing NavMesh. In 4.0 it only affects the obstacle avoidance, with that change it would affect the pathfinding.

The NavMesh baking shown here is not really interactive in the sense of a 30 FPS in game usage.

NavMesh carving on the other hand can be made fast enough to carve an obstacle out of the navmesh every frame. So it is perfect for placing buildings, barrels at runtime.

—

To support a 20km x 20km densly polulated world you would still need to split your world into multiple scenes and load them additively. And you would want NavMesh tiles to be loaded / unloaded based on which scenes are currently loaded. This is a step on the way toward that.

Beck Sebenius

November 30, 2012 at 12:48 pm /

Wow, this is pretty damn awesome! Great work guys.

Chaoss

November 30, 2012 at 11:49 am /

Nice… however this still wouldn’t really work for a 20km x 20km world.