Using Multiple Databases

This page provides some details on using multiple simultaneous Databases in a single World.

You should only need to use multiple Databases if you have multiple different types of characters that have either:

• Significantly different physical proportions, such as their width or height. These physical proportions are used during the generation of the static NavData in order to determine which areas of the terrain are valid for the character to stand. For example, a narrow hallway or a low-ceilinged room might be walkable terrain for a human character but not for a giant.

  

• Significantly different movement capabilities. These are used during the generation of the static NavData to determine whether a character can move from one place to another. For example, the generation process takes into account a maximum slope angle (set by the GenerationParameters::m_slopeMax value) that determines how steep a slope a character can traverse in its normal walking movement. For example, a mountainside might be easy for a giant spider or a mountain goat to traverse, but impossible for a human.

  

In cases like these, the differences in the areas of the terrain that are navigable to the two types of characters are different enough that two sets of NavData are warranted, which implies the use of two Databases to manage the different sets of NavData in the game at runtime.

Typically, the static NavData that you pre-generate for your terrain is the largest consumer of runtime memory when using Autodesk Navigation. Therefore, to avoid unnecessary duplication, you will probably want to make your characters share the same NavData whenever they can: i.e. whenever the differences between the characters are small enough that they do not cause noticeably strange behavior at runtime.

If you choose to share a single Database for multiple different types of characters, it is safest to generate the data using the radius and height of the largest character. This is readily apparent if you consider the case of the human and the giant:

• If you generate data using the dimensions of the human, the border of the NavMesh will be at a distance from the static geometry roughly equal to the human's radius. At runtime, the giant may therefore plan paths that pass closer to the static geometry than its own radius, which can lead to collisions.
• If you generate data using the dimensions of the giant, the border of the NavMesh will be at a distance from the static geometry roughly equal to the giant's radius, which is safe for both characters to use in their path finding and path following. However, it may lead to the smaller characters being unable to access some areas of the terrain that they should normally be able to reach, like the narrow corridor shown above, small hiding places, etc.

In cases like this, there is a tradeoff between on one hand conserving runtime memory by sharing NavData, and on the other hand increasing path finding and path following realism by tailoring each character's NavData to their precise dimensions. Ultimately it is up to you to decide which you should prioritize in your game.

Setting up multiple Databases in a World is conceptually the same as setting up a single Database, except that you have to do everything multiple times:

• Generate multiple sets of NavData for your levels, each with its own set of configuration parameters.
• When you create the World, you create one Database for each type of character.
• Each time you need to load a sector of NavData into your game, you create a separate NavData object for each type of character.
• You add each of those NavData objects to the Database that maintains the data for that type of character. NoteFor best performance, try to group all requests for asynchronous NavData addition and removal into the same frame.

The only real difference is the added challenge for your asset pipeline to ensure that you add the NavData for each type of character to the correct Database.

The Database has a mechanism for guaranteeing the coherence of its data set and preventing you from loading in any NavData generated for a different character. Once a Database has loaded any NavData, it will not load any additional NavData unless that additional NavData was generated with the same set of configuration parameters as the existing NavData.

Before you add a NavData object to a Database, you can test whether or not its data matches the data already present by calling Database::IsCompatibleWith() and passing your NavData object. If this method returns false, attempting to add that NavData to that Database will fail.

By default, whenever you add a new WorldElement such as a Bot or an obstacle to a World, that object is spatialized into all Databases in the World. This ensures that the new object is taken into account in the same way by all of the Databases. For example:

• The dynamic avoidance computer used by all Bots in all Databases will take into account all new Bots and dynamic obstacles.
• New TagVolumes and obstacles that are configured to modify the NavMesh dynamically will modify the NavMesh within all Databases.
• Spatial queries against any Database will pick up all of these objects. For example, running a SpatializedPointCollectorInAABBQuery to collect points of interest will pick up all the points of interest that have been added to the World, regardless of which Database you run the query against.

However, in some cases, you might not want this default behavior. Instead, you might want to restrict the Databases that your new objects are applied to. For example:

• You might want giant characters to ignore humans in their dynamic avoidance.
• You might want new TagVolumes to only tag the terrain in a limited set of Databases. For example, you might want a TagVolume that represents a flooded area to apply only to humans, not to giants.
• You might want your queries to give different results depending on Database: for example, the set of points of interest that are relevant to giant characters may not be the same as those that are relevant to humans.

Each time you create a Bot, BoxObstacle, CylinderObstacle, TagVolume or PointOfInterest, you can specify which Databases should take the new object into account.

The configuration object that you use to initialize each of these kinds of objects has an m_databaseBinding member, which maintains an instance of the DatabaseBinding class. Before you initialize your object, you can create a new DatabaseBinding, set it up with pointers to the chosen Databases, and set the m_databaseBinding member to point to your DatabaseBinding. For example:

Kaim::BotInitConfig botInitConfig;
...
m_databaseBinding = *KY_NEW Kaim::DatabaseBinding;
m_databaseBinding->AddDataBase(world->GetDatabase(0));
m_databaseBinding->AddDataBase(world->GetDatabase(2));
botInitConfig.m_databaseBinding = m_databaseBinding;

m_navBot->Init(botInitConfig);