• PhysicsInVos

Basic collision detection has been added to VOS in 0.22.

In the future, richer dynamics support can be added using either:

• Open Dynamics Engine (ODE)

• Bullet - A Continuous Collision Detection and Physics Library.

The Blender Wiki has an excellent discussion "RigidBodyPhysics" on thier preference for using Bullet over ODE.

Here are some thoughts on how to create a more realistic & enjoyable interactive experience for users of VOS 3D Worlds by adding support to VOS for the simulation of real world physics:

Problem

No physics in VOS. We have collision detection and basic downward gravity (added in 0.22), but we would like to have richer dynamic interaction between objects based on real Newtonian mechanics: forces, velocity/acceleration/deceleration, etc; Proper behavior of jointed or soft objects; friction between solids in contact and between solids imersed in liquids, etc.

Solution

Use ODE or Bullet to do rigid-body simulation of the 3D objects in a scene. Both of these Open Source Physics Engines provides full collision detection and response.

Design considerations

We need to a set of physics parameters in A3DL metabojects (see ChangesToA3dl). Also we need to send at least the instantaneous velocity of an object along with its position.

Each node (site) in the system will run a physics system independently, while correcting the state of the system to the "official" state (perhaps within some tolerance?) with each update from the network. This should allow for a very responsive physics simulation, while at the same time keeping things resonably synchronized.

So, each node runs it's own physics simulation -- based on it's knowledge of the world, to keep things smooth and to minimise server-client communication. Every now and again, the WorldServer will correct the client, and the client will then adjust its model accordingly.

Client-Side Prediction

Note that with client-side prediction, any state updates sent from the server will be "in the past" due to network latency. Therefore, to keep things running smoothly, the client should implement a history buffer of movement commands -- when it receives an update from the server, it should "back up" to the point in that buffer where the correction occurs, then re-apply the movement commands to bring the client back up to the present. Note that this requires the server and client to agree on timestamps for when the movement commands occur, and when the physics state updates happen, and for them to have identical physics simulation code. Specifically, each client input update is tagged with a sequence number, and each server update has an "acknowledge last received command" so the client knows where in the history buffer this update applies. This sequence number can be local simulation time, but I don't think it strictly has to be. In addition, the server updates are tagged with the server's simulation time, so the client can correctly calculate interpolation between updates as well as the starting time for simulating physics through the history buffer. Note that when the client simulates through the history buffer, it's only simulating its own Avatar movement -- all other objects in the world are taken "as is" from the most recent server update.

A client may choose not to do prediction if latency is low enough, or if it does not have the ability to run the same physics simulation as the server.

(Just to note: an authoritative server should be running its physics simulation on the same sequence of input commands that the client does locally. This means "move-forward-start" "move-left-start" "move-forward-stop" etc... something like "movevector xyz" would work too, updated whenever it changes -- but not "moveto xyz"!)

Finally, some applications may prefer a "client-authoritative" mode where the client runs physics for its own avatar, and the server just relays the information without doing any corrections. This has the advantage of having no client-side "snapping" and allowing more client freedom of movement, but the disadvantage of possibly unfair or strange-looking physics interactions when two avatars come in contact.

On "Clients" and "Servers"

The above discussion mentions "clients" and "servers" a lot. In a VOS context, the terminology would probably better being something like "Avatars" and "Sectors." Precise terminology should be hammered out so as to avoid confusion...

Previous Implementation

Some physics features were present in previous versions of VOS and Ter'Angreal.

TODO: describe previous implementation

Ideas

1. specify each force vector on an object

Add a new type. If an object has this type, it might have a list of active forces contained in a grouping object (like "forces"). Each force is a vector of some kind. (X, Y, Z; or direction quaternian + magnitude) These can be added remotely (if access control allows). Each client that has ODE can predict the effect of those forces, and animate the object. The actual owner (local site) for the object does the same, put pushes position (and maybe velocity?) updates periodically to keep the other sites sort of synchronized, and to account for clients that don't have ODE.

• A list of "forces" is useful for objects that actually propel with forces -- like a rocket-ship -- but for objects which move in more complex way -- like an avatar -- something like "intended-motion-vector" might be more usable. That vector is then transformed into forces or velocity constraints which are combined with the other forces and constraints in the world on which the simulation is run. See the "Client-Side Prediction" section above. --Ken

I know we talked about this for a previous implementation, and tetron decided not to use it, but I forget why, so here it is.

It has the advantage of being simple to use, and probably very natural for many kinds of dynamic movement. Disadvantage, is you have to calculate the acceleration and velocities, and you will probably never be able to achieve a desired velocity perfectly, if you just care about a desired velocity... you have to set a force (step on the gas) until you reach it your velocity, then stop, then use a force in the opposite direction when you overshoot, and go back, etc. This error migth introduce chaos, you might end up with a little teeny bit of acceleration left over when you reach your desired velocity and so you have to keep correcting, which causes wobbling?

• I don't think this'd be too difficult or unstable... basically, every timestep, apply a force to the object to attempt to accelerate it to match "intended-motion-vector." There may be additional constraints, of course, like you can only adjust your motion when in "contact" with the ground or when climbing a climbable surface, etc. The amount of force (ie your maximum acceleration) you can use can be constrained, and a "maximum velocity" imposed (if you're going faster than that velocity relative to your walking-surface, you can't accelerate any more in that direction. Though you can decelerate). I've never acutally implemented something like this, though, and I've heard they can be tricky to get to feel right. --Ken

• Update: This page http://www.gaffer.org/game-physics/spring-physics mentions using a damped spring equation to reach a desired velocity without oscillation... the "spring" applies a force proportional to the difference between the current velocity and the desired velocity, but that force is damped by the rate of change in the difference between those velocities. This probably would be areasonable way to go about it. --Ken

2. Implement Two systems

All the talk above about desired velocities is very games-orientated. I anticipate that for everyday use, the most basic physics will suffice.

So we have two models, a simple, less-regularly-updated model that gives less accurate physics but smoother viewing.

And we have a game model, that has very regular updates, and sharp physics.

You could alternatively just have one model and just change the rate of server updates.

• I'm not entirely sure what your simpler model consists of... but it sounds like it's something like -- no server-side correction of avatar movement (client-authoritative movement of avatars), combined with direct position or velocity setting on avatars (instead of using forces to attempt to attain a certain velocity, as described above). Is this what you're thinking of? -Ken

3. Enforcing Physics with access control

Let's say that the sector, or some manager object in the sector, controls the movement of avatars within the sector. Avatars have basic state properties describing their position, velocity, etc. These properties are listened to by nodes interested in displaying avatar movement.

If the node that "owns" the avatar has the ability to write to these state properties, it can override the physics system. Therefore, in an authoritative physics sector, those state properties will be read-only for everyone except the manager object. In order to control your avatar, you instead update "control properties" such as intended-velocity, or some other control scheme. The manager object listens to changes in the control properties, and runs the physics simulation, updating the state properties as needed.

A node can also query the manager object and request certiain actions, such as teleporting the avatar, or applying a force to some object in the sector. The manager object will determine whether this is allowable, and then update the physics state to reflect it.

Other properties such as mass, etc, can likewise either be edited directly or through the manager object.

The manager object can also be queried to determine which physics simulation it uses (so the client can do prediction if desired), and what input schemes it supports (such as intended-velocity, intended-position, or anything else that might be thought of). There should be certain "baseline" physics implementations and input schemes (in addition to direct-position-updates in sectors that allow it), and additional ones can be added through plugins.

Obviously some sectors may choose not to implement physics at all, allowing clients to set their positions directly through the position property (these would be the simplest implementations). Others may implement a simplified physics system that doesn't do full rigid body dynamics, but rather restricts the avatar movement in certain ways (think old FPS games).

Finally, this access control scheme can be used in other interesting ways -- giving "superusers" the ability to bypass physics, or giving "ownership" of an object's control properties to a certain user.

Search for "zen of networked physics". Synchronizing joints will likely be impossible with client-side prediction as local physics state with joints can vastly diverge from server state (with simple unjointed objects the snapping correction just updates objects' locations/orientations; with jointed objects, you'd be snapping the whole island of objects into a new configuration, which would look very bad - imagine a ragdoll locally simulated with his leg in the air suddenly being snapped to the server version with his hand in the air). With joints, it's better not to use client-side prediction but increased latency is the cost.

CategoryWorkInProgress CategoryTask NeedsDiscussion