Categories & Tags
Archive

Iterative baking of Occlusion and NavMeshes

November 30, 2012 in Rants & Raves, Tech by

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!

Ninjas: Jakob Hunsballe, Joachim Ante & Jesper Mortensen

Share this post

Comments (15)

Comments are closed.

30 Nov 2012, 6:55 am

That is grand! Great work. :)

JHS
30 Nov 2012, 11:15 am

(1) It’s a great project from “Unity Ninjas” !!!

(2) Special thank to Ninjas:
Jakob Hunsballe, Joachim Ante & Jesper Mortensen

(3) I want from you to add this feature to runtime.
With a function that we can call it.

It’s a great feature for games like strategic games,
as you know players can add static objects like buildings in runtime,
and we can use this feature for:

(a) NavMeshAgents understand these new runtime & static objects and don’t go through them. (NavMeshes)

(b) if these new runtime & static objects are big, then camera don’t render objects behind them. (Occlusion)

(4) I want more information about other “Ninja Camp VII” projects !!!

(5) Please update “unity3d.com/ninjacamp” with “Ninja Camp VII” projects !!!

Thanks.
JHS.

30 Nov 2012, 11:37 am

Nice! Is it on the 4.1 roadmap?

30 Nov 2012, 11:49 am

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

30 Nov 2012, 12:48 pm

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

Joachim Ante
1 Dec 2012, 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.

Matt
2 Dec 2012, 3:27 am

This looks brilliant! Excellent work guys!

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

2 Dec 2012, 4:10 am

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

2 Dec 2012, 6:05 pm

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.

Nicolas M
3 Dec 2012, 2:22 am

Do you plan to update the previous dedicated website (http://unity3d.com/ninjacamp) with the current Ninja Camp projects?

Kamil A
3 Dec 2012, 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 =)

Joachim Ante
3 Dec 2012, 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
3 Dec 2012, 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

17 Dec 2012, 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.

10 Feb 2013, 10:42 pm

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.

Leave a Reply

Comments are closed.