Creating Collision Volumes

From Multiverse

Jump to: navigation, search

Contents

Overview

When you create a model with a modeling tool such as 3ds Max, you can associate one or more collision volumes with each submesh. A collision volume defines how a model physically interacts with other models in the world. The Multiverse physics system prohibits collision volumes from overlapping in space, so models with associated collision volumes cannot move through each other. The collision volumes associated with a single model cannot overlap.

You associate a collision volume with a submesh by matching portions of the submesh name. For most assets, you create, align, and orient collision volumes in the modeling tool by creating basic shapes with names corresponding to the model.

Alternatively you can use a tool that outputs COLLADA .physics files, or create .physics files by hand using a text editor. This latter approach is common for creating .physics files for avatars, whose collision volumes are often just a single capsule shape. If you take this route, you can modify one of the .physics files installed to the Sampleworld asset repository Physics directory, such as human_male.physics.

Static versus animated models

You can define collision volumes both for animated models (mobs) as well as stationary objects, like buildings, fences, and so on. The procedure is the same in both cases, but there are differences as to what types of volumes can be used. The end result of creating collision volumes is a .physics file, in COLLADA physics format.

Both static and animated models, may have multiple associated collision volumes of various shapes and orientations. Each collision volume must be associated with a submesh of the model.

NOTE: CVs are not affected by the visibility (or invisibility) of the associated submesh. That is, CVs will always apply, regardless of whether the associated submesh is visible or not. Also, model animation does not affect the position or orientation of associated CVs.

Performance considerations

Any collision system suitable for MMOGs must scale to worlds containing huge numbers of obstacles. The computational load of a collision system depends on two characteristics:

  • Number of object pairs that must be tested.
  • Costs of the tests.

The Multiverse collision system client minimizes the computational and memory load by caching only obstacles within the "collision horizon" of moving objects. To minimize the number of object overlap tests performed, the Multiverse collision system maintains all obstacles in a "sphere tree" that grows and shrinks as obstacles come inside the horizon. Testing if two spheres overlap is computationally inexpensive, so the sphere tree locates the minimum set of candidate obstacles for collision detection cheaply. Most real-world obstacles are capsules or oriented bounding boxes (OBBs), and capsule/OBB and OBB/OBB overlap tests are relatively expensive.

NOTE: Although collision detection is initially implemented on the client, it will be moved to the server in a future release. This change will not affect how you create collision volumes for assets.

Procedure

Follow this procedure to create collision volumes using a 3D modeling tool:

  1. Create the models and associated collision volumes.
  2. Export the models to .dae files using the COLLADA exporter.
  3. Use the Model Conversion Tool to extract the models from .dae files into .physics files.
  4. Use Asset Importer to create an asset definition for the model that includes the .physics files. If there is already an asset definition file for the model, the use Asset Importer to add the .physics files to it. For more information, see Creating asset definition files with Asset Importer.

Sometimes it is easier to use the canonical sample collision volumes provided in the Physics directory, rather than creating collision volumes from scratch using a 3D modeling tool, particularly for mobs.

SpeedTree collision volumes

All SpeedTree trees come with predefined collision volumes. You do not need to do anything to enable them.

Collision volume shapes

The Multiverse physics system uses four primitive shapes for collision volumes, as described in the following table.

Shape Description Name prefix
Oriented Bounding Box Rectangular cuboid with any orientation. That is, a box with six rectangular faces defined by three orthogonal axes, represented by unit vectors, a center, and three "extent" values, one for each axis. The resultant box has dimensions 2 * extent1 by 2 * extent2 by 2 * extent3. mvcv_obb_
Axis Aligned Bounding Box Rectangular cuboid whose edges are aligned with (parallel to) the world axes (X, Y, and Z). Since the axes are always the same, they are omitted, so all you need to specify an AABB are two points in space: the x, y, and z coordinates of the minimum point, and the x, y, and z coordinates of the maximum point. mvcv_aabb_
Sphere Simple sphere defined by a center point and a radius. mvcv_sphere_
Capsule Cylinder with any orientation capped with a half sphere on both ends. mvcv_capsule_

For example, to create an oriented bounding box collision volume for a submesh called houseShape (representing a house model), the collision submesh name must start with mvcv_obb_houseShape. Complex shapes, such as buildings, will have several associated collision volumes. For example, a set of collision volumes for the house submesh might be:

  • mvcv_obb_houseShape_left_wallShape for the left wall of the house.
  • mvcv_obb_houseShape_right_wallShape for the right wall of the house.
  • mvcv_obb_houseShape_floorShape for the floor of the house


The prefix is case sensitive and must be all in lower case letters. For example, mvcv_obb must be lowercase.

The submesh association portion of the naming scheme can be in lower or uppercase letters, but must match the names of the submeshes in the file as far as the case is concerned.

Examples

A complete example of a 3D Max model with collision volumes, the exported .dae file, and the mesh, material and physics files generated by the ConverstionTool are in the human_tall_shack .zip file.

There are examples of .physics files extracted from models, as well as hand-edited avatar .physics files, in the sampleworld asset repository Physics directory.

Creating a collision volume for a character model

The Platform Tutorial includes an example of creating a physics (CV) file.

Creating collision volumes with Maya

When using Maya, you must pay attention to the names that Maya assigns; see Creating Collision Volumes with Maya for more information.

Displaying collision volumes

To display collision volumes in the Multiverse Client for testing and development purposes, press Ctrl-h:

  • The first time you press Ctrl-h, it displays collision volumes for all objects (mobs and static objects).
  • The second time, it turns off display of mob collision volumes, displaying only static object collision volumes.
  • The third time, it turns off display of all collision volumes

Note: If you use the client character change UI or the /model command to change characters in the client, then your new character will continue to have the collision volume that your old character had. This is a bug that will be fixed in an upcoming client release.

"Stuck" support

Rarely, a player can get "stuck" in a collision volume, usually by moving into a new area before the Client loads buildings and other objects with collision volumes. Once the player is in this state, the avatar can't move, because the Multiverse collision system prevents it.

In 1.0, if the player has been in this situation for five seconds, the chat window will display the message

Executing /stuck command because player has been in a collision volume for 5000 milliseconds

Then the Client will automatically issue the command "/stuck". If the world defines the waypoint "stuck", then the player will be moved to that location. If the waypoint "stuck" is not defined, then the /stuck command will use the location (0,0,0) and the player will be moved to the origin.

To change the time between getting stuck and executing "/stuck" set the value of the ClientAPI.InputHandler.MillisecondsStuckBeforeGotoStuck property. The default value of this property is 5000 milliseconds.

To disable "stuck" support, set ClientAPI.InputHandler.MillisecondsStuckBeforeGotoStuck to zero (0).

Personal tools