NINJA Physics: Networked INteractive Jointed Assemblies for OpenSim

This project proposes a new physics extension called NINJA Physics. The NINJA Physics extension enhances the ODE physics in OpenSim with joints: movable linkages between prims. This will allow wheeled vehicles, ragdolls, and mechanical/robotic assemblies to be interactively built within the standard viewer and controllable through scripting. This kind of physics is not currently available in OpenSim or Second Life.

A demonstration of the idea can be seen here: http://jp.youtube.com/watch?v=nirTXPO-opE

NINJA stands for a Networked INteractive Jointed Assembly. "Jointed Assembly" refers to an articulated rigid body. The "INteractive" aspect refers to interactive editing in 3D space of jointed assemblies using the viewer and intuitive 3D placement of joint objects as normal prims. The "Networked" aspect refers to many users simultaneously interacting with jointed assemblies in a networked virtual world.

The core ODE physics engine already provides support for joints; it is OpenSim and the viewer that lack support. This project therefore aims to extend the OpenSim physics interface to access the ODE joint functionality. Furthermore, this project must also provide a means of creating and editing joints within the standard viewer, which has no native support for joints. In the future, viewer changes and protocol changes can be considered for native joint support.

This new kind of physics, jointed physics, is separate from and complementary to the existing LSL script-based vehicles. Activity has recently accelerated on script-based vehicles, with some water-based vehicles already working (e.g. sailboats). The new jointed/NINJA physics will allow more new kinds of vehicles not currently possible with scripting. Two example of new kinds of vehicles are cars with wheels that actually turn and rotate, and robots that walk by moving limbs.

Philosophy

The development of NINJA Physics follows these principles.

1. Break nothing. When turned off, NINJA Physics should have no observable effect on simulator behavior. When turned on, existing physics behavior without joints should be exactly the same as before. Additionally, new physics behavior with joints should be available to the user.
2. Standard viewer compatibility. Editing of joints must be possible using only the affordances of the standard viewer. This means we must enter new information (joint information) in an existing GUI not designed for that purpose. We do this by using repurposing existing prim editor fields (Name and Description) and using a special naming convention to specify joints. The requirment of standard viewer compatibility conflicts slightly with the requirement of breaking nothing; by using a special naming convention, it is possible that existing regions might already use that naming convention, which would lead to altered behavior. In practice, this will likely not be a great concern.
3. Code readability. The first version of the NINJA Physics patch is implemented in as straightforward a way as possible to allow understanding and critique of the basic approach. At this stage, no overly-clever optimizations and only necessary abstractions have been applied.
4. Generalizability. The first version of NINJA Physics is implemented using ODE Physics, but the same implementation should be usable for any physics engine that supports joints.

User documentation

Quick start

To try out NINJA Physics, follow these steps.

1. Apply the patch ninja-allparts to your OpenSim source tree and compile.
2. Copy demo-playground.tgz to your opensim/bin directory
3. Edit OpenSim.ini to run in standalone mode with ODE physics. Set use_NINJA_physics_joints=true.
4. Start OpenSim.exe. In the region console type load-oar demo-playground.tgz to load demo data.
5. Login to the region and navigate to (128,128). Select everything in the region (Ctrl+3, mouse drag). (You can also select a smaller group of objects.)
6. In the object editing window, click on the "Physical" checkbox in the "Object" tab to turn the selection physical, then press ESC to exit selection mode. The prims and the joints go "live".
7. Click on any jointed assembly and drag it around. The following commands spoken in chat can control the ragdoll: "arise", "kneel", "die".

Definitions

A joint is a constraint on the motion of rigid bodies. Currently we consider two types of joints: a ball-and-socket joint and a hinge joint. A ball-and-socket joint is similar to the joint connecting your upper arm to your shoulder; the joint constrains the position of the two bodies, but allows free rotation. A hinge joint is similar to a door hinge: it constrains the position of two bodies but allows rotation about only one axis, the hinge axis. By using joints, we can create complex assemblies of prims in OpenSim that move with realistically-constrained motion.

A joint proxy object is a prim created in the viewer and existing within the region to represent a joint. Its position, relative to the prims it affects, defines the position around which the prims movement will be constrained. For hinge joints, the orientation of the joint proxy object defines the hinge axis; specifically, the x-axis of the proxy object is defined as the axis about which the connected prims will be allowed to rotate.

A physics engine joint is the data structure within the physics engine that actually constrains the behavior of the rigid bodies as simulated in the simulator. The physics engine joint is visualized by the joint proxy object.

Enabling NINJA Physics in OpenSim.ini

In OpenSim.ini, set "physics = OpenDynamicsEngine" and "use_NINJA_physics_joints = true".

Creating a ball-and-socket joint

Create two box prims side-by-side with space in between them. Leave them non-physical for now. Give each one a unique name (right click, edit, General tab, Name). Example names are "box1" and "box2". Leave the dimensions at (0.5, 0.5, 0.5). These 2 prims will be connected by a ball joint.

Create a small sphere. Make its dimensions something like (0.1, 0.1, 0.1). This prim represents a ball-and-socket joint. Position the sphere between the 2 boxes. Assign the small sphere the name of "balljoint-uniquename", where "uniquename" is a unique name not used by any other prim. Give the sphere a Description of "box1 box2", which are the names of the 2 prims to be connected, separated by a space.

Close all windows in the viewer. Press Ctrl+3 to enter edit mode. Drag the mouse to highlight the 2 boxes to be connected and the small sphere.

In the object editing window, click on the "Physical" checkbox in the "Object" tab.

Drag the boxes around and notice they remain connected by a joint.

Creating a hinge joint

A similar procedure is used for creating bodies connected with hinge joints, with the following differces:

The joint object should be named "hingejoint-uniquename", where uniquename is a unique name not used elsewhere in the region.

The joint object's position determines the anchor of the hinge.

The joint object's X axis orientation determines the axis of rotation of the hinge. The easiest way to visualize this is to create a prim whose size is elongated along its x axis; set the object size directly in the object editor to something like (1.0, 0.1, 0.1).

Hinges can be used for simulating wheels. Connected bodies can rotate freely around the hinge, like a wheel around an axle.

Activating and deactivating bodies and joints

Setting a joint proxy object to "physical" causes creation of that joint in the physics engine. Setting the joint proxy object to non-physical, or deleting the joint proxy object, or taking the joint proxy object caused deletion of the corresponding joint in the physics engine. (This is why each joint must have a unique name, so that the physics engine knows which joint is being referred to.) Deleting joints in an active jointed assembly will cause the connected bodies to disconnect. Deleting, deactivating, or taking a prim in an active jointed assembly will cause all joints connected to that prim to deactivate.

Developer documentation

Patch structure

The patch for NINJA Physics is divided into 6 parts for better readability.

Part 1: data structures

Patch ninja-part1-joint_data_structures.patch declares the PhysicsJoint class and its subclass OdePhysicsJoint for storing joint information.

Part 2: abstract physics interface

Patch ninja-part2-physics_interfaces.patch alters PhysicsScene.cs with new methods for manipulating joints. The main idea is that a user of the physics engine can make joint requests or be notified of joint activity. Joint requests include requesting the physics engine to create or delete joints. Joint activity notification takes place through events that are fired whenever a joint is moved or a joint is deleted. These events allow the external scene to update scene information (position and orientation of joint proxy objects) to accurately reflect the state of the joints.

This part of the patch also modifies PhysicsActor.cs to contain the scene object part name and description. The physics engine links bodies together based by looking for physics actors whose names match the joint description.

Part 3: scene

Patch ninja-part3-scene.patch alters Scene.cs to allow NINJA Physics to be turned on/off. It also extends the behavior of DeleteSceneObject to delete the joint in the physics engine if the scene object corresponding to the joint (i.e. the joint proxy object) is deleted.

Also, this part of the patch alters SceneGraph.cs with callback handlers to respond to joint movement or joint deletion notifications from the physics engine. When a joint in the physics engine is moved/deactivated, its representation in the scene (the joint proxy object) is correspondingly moved/stopped from moving. Note that the joint has no direct representation (i.e. no body or geom) in the physics engine, so the physics engine has no knowledge of the scene graph's joint proxy object, necessitating this callback approach.

Part 4: SceneObjectPart

Patch ninja-part4-sceneobjectpart patches SceneObjectPart.cs to detect if the SceneObjectPart is a joint (based on its name of "balljoint-*" or "hingejoint-*"). If it is a joint, then requests to make this SceneObjectPart physical/non-physical are translated into calls to the physics scene to request creation/deletion of joints.

Part 5: ODE joints implementation

Patch ninja-part5-ode.patch is the ODE implementation of NINJA Physics.

ODEPrim.cs is patched to remove an optimization that prevents updates from being sent when the object position is almost stationary. This prevents rotational-only motion from being sent to the client, such as a fan blade rotating on a hinge.

OdePlugin.cs implements the creation and deletion of joints within ODE. Internal data structures keep track of associations between joints and bodies. Unprocessed joint requests (creation or deletion) are processed in the Simulate loop.

Joint deletion requests are handled immediately and the joint deleted callback is invoked to nofity the external scene of the joint change.

Joint creation requests are not handled immediately, because a joint can only be created if the bodies it is connecting already exist in the physics scene. Therefore, a joint creation request adds the new joint into a pending list. After processing of joint taints, a check is performed to see if any pending joints are still waiting for their respective bodies to appear in the physics engine. If such pending joints exist, and all of their bodies also exist, the joint is removed from the pending list and is actually created in ODE. Internal data structures also keep track of the association between bodies and the joints connected to that body.

Finally, whenever an physics actor (body) moves, it is checked if that body is connected by joints. If so, movement of the body implies movement of the joints connected to that body. Therefore, a joint moved callback is invoked to notify the external scene of the joint motion.

The DumpJointInfo function is useful for debugging.

Part 6 - OpenSim.ini.example

Patch ninja-part6-ini.patch shows the OpenSim.ini option to control NINJA Physics.

Joint states

Joints pass through the following states during their lifetime:

• Requested creation. In this state, the joint is not yet processed by main physics simulation loop.
• Pending. In this state, the joint is processed by main physics loop but does not yet exist in the physics engine. It is waiting for its constituent bodies to exist in the physics engine.
• Active. In this state, the joint exists in ODE and affects the ODE simulation. Furthermore, motion of the joint generates a joint moved event that can be subscribed to and acted upon.
• Requesting deletion. In this state, the joint has requested to be deleted from the main physics simulation loop, but that request has not been processed by the main simulate loop. Therefore the joint is still being simulated.
• About to delete. In this state, the joint is about to be deleted and a joint deactivated event is sent to notify subscribers of the joint's impending death.
• Deleted. The joint no longer exists in ODE, does not affect the physical simulation, and generates no further events.

Limitations

This section describes some current limitations and shortcomings of the current implementation and areas of continuing and future work.

Naming limitations

• Each joint and each prim connected by a joint must have a unique name.
• Changes of joint names or prim names while the prim/joint is physical are not handled.
• When creating a joint, in the description field, use exactly one space between the names of the connected prims.

Timing issues

• Extremely rapid toggling between physical and non-physical states, with the final state being "physical", can sometimes incorrectly lead to the joint's last state being "non-physical".

Persistence of joints

• Region shutdown/startup persistence doesn't yet work. In other words, if you activate a jointed assembly then shutdown the region, upon region startup the recreated joints are not all perfectly reconstructed. It almost works, but some joint orientations are incorrect on region startup.
• load-oar persistence doesn't work due to threading/atomicity issues (see below).

Atomicity issues

• Non-atomicity of viewer selection processing. If you select a group of non-physical prims and joints, and turn them all physical by clicking "physical" in the viewer, it is not guaranteed that the entire selected group will be turned physical in one tick of the simulation. It is therefore possible that part of the assembly will go "live" and start moving before all of the joints in the assembly have been constructed. This will lead to joint positions different than the original static specification of the joints.
• Non-atomicity of load-oar. Due to multi-threading, physics simulation continues while a load-oar is executing. This again means that parts of an assembly will go "live" and start moving before all of the joints in the assembly have been constructed.

Accumulation of joint error

Repeatedly deactivating and reactivating a jointed assembly will lead to non-reversible accumulation of error in the joints. The joint proxy object saves the "position" of the joint but this information is not complete information about the joint. In particular, it does not contain any information about the joint error. For instance, imagine a ball and socket joint where, due to extreme forces acting on the parts, the ball and socket have been forced apart, leading to joint error. Currently, the joint proxy object only saves the joint position relative to one body, which is analagous to saving only the position of the ball but not the position of the socket. Upon deactivating and reactivating a joint with joint error, the current body positions are assumed to be 0% error, which means that the original joint error has been permanently "forgotten".

Multi-user testing

This hasn't been tested in a multi-user environment. Single-user testing revealed occasional deadlocks which should hopefully now all be solved, but multi-user testing may expose more corner cases. My hope is that interested users of the OpenSim community can help test various multi-user scenarios. It will also be interesting to see how network latency and server load affect the user experience.