How to make good mesh physics

[Tess Juel]

There's been some talk about compatibility issues between the three physics engines we have so I thought a quick physics tutorial would be a good idea.

ODE, Bullet and ubODE all have their quirks and "shortcuts" but the principles for a truly well made and efficient physics model are the same for all of them.

What physics does
First we need to think of what the purpose of physics really is. The physics model:

• defines "exclusion zones" where avatars (and physical objects) are not allowed
• defines walkable surface
• defines (to some degree) surfaces it's possible to rez on

That's all there is to it. This means there is no point in including small lumps and bumps in the physics model since they won't affect an avatar's movement anyway. This again means that the visual model is hardly ever suitable as the physics model; it's usually way too detailed and since running the physics engine is very heavy work for the server, we want to keep it as simple as possible. So we need to be prepared to make separate models for our physics. Fortunately that isn't difficult at all:

Simple physics
Most decorative objects (such as furniture) only reall needs a simple "bounding box" style physics model to keep people from walking right through them. For such items, make a dae file with a simple cube, save and reuse whenever needed. Size doesn't matter, the physics model will automatically be scaled to the same overall dimensions as the visual one.
This method works for phantom objects too of course.

More advanced physics
Keep the overall dimensions the same as the visual model, sometimes we have to add one or more extra tris just to define the outer limits of the size for this.
Apart from that, add surfaces wherever you want an avatar to be able to walk and wherever you want to block an avatar from passing through. Nothing more and nothing less. For vertical, blocking, surfaces, you don't need exact placement, a few cm leeway makes no noticeable difference. But for horizontal walkable surfaces you want pinpoint precision. And as I alredy said, don't include lumps and bumps too small to affect the avatar in the physics model.

[Mike Lorrey]

additional effects of physics:
- defines surfaces that register collisions for avatar damage in the system health, and for executing "collision_start()" events in scripts. If you cannot collide with an object, you cannot use those events in your script to detect nonexistent collisions, so you have to use volume_detect() events instead to detect when an avatar or object is passing through what is essentially phantom volume. This is of course a bit more complex of an issue with mesh than with prims.
- server calculation load for an object. The simpler the collision mesh is, the less work the server has to put in on calculating the objects collision mesh, calculating collisions that happen (because it tends to be related to proximity to vertexes and possibly edges that determine how many collisions happen (and yes, how many vertexes are on the object colliding with your object as well, hence why bullets tend to actually be cubes since they are the simplest shapes to calculate collisions for.)
For this reason, the physics mesh can be FAR simpler than the visible mesh. A floor or wall that you give lots of vertexes to not just for details but also so it does not decompose with distance very rapidly, only needs a tiny fraction of the number of triangles to provide an efficient but working collision surface (in ubODE at least, bullet physics tends to want to see a vertex ever few meters on any walkable surface.)
- simpler geometry is easier to pass the upload process. The uploader hates small and thin triangles, and "small" is a variable value depending on the size of the mesh object. If your building is 200 meters tall, its not going to like any triangles of less than several meters size. "Thin" from my experience tends to be any length to width ratio greater than about 8:1 or so. I'm sure the viewer code has some exact ratio coded but I'm not sure what it is.

[Tess Juel]

The uploader hates small and thin triangles

This is true for HAVOK, the physics engine used by Second Life but it doesn't necessarily apply to opensim since we use different physics engines here.

uBode's physics weight algorithm actually stipulates that it's the other way round: larger triangles are heavier to handle than smaller ones. That may only be an assumption though, has anybody tested this?

[Christine Nyn]

Hi Tess,

Having less triangles for which collusions need the be calculated is better for all physics engines. There are a few exceptions in the case of huge triangles that may be hitting many other physical objects, but the rule of thumb is to simplify collision meshes as much as possible.

[Ada Radius]

It can get tricky for complex builds with curved surfaces. I finally got my whale house figured out, but it took a while and much help. The problems: couldn't get a second door to work (still can't), the physics model was arriving in the viewer not lined up with the visible mesh, too many pieces in the model, error messages.

Both Kayaker Magic and Mike Lorrey teach classes to show how to put a small triangle at a distance from, for example, the stern of a ship to get a script to work. And also at any bits of the mesh that we might not want for collision, but are needed to keep the physics mesh lined up with the visible mesh. If you're having problems, come to a class. Bring your model so the workshop can stomp around on it and take a look at it with physics visible.

As Mike Lorrey mentioned, and can't be said too often, the uploader won't take narrow triangles. That may mean that some areas of the physics model may have to have more loops than the visible mesh, to make even quadrangles that will triangulate pretty.

[Christine Nyn]

...Both Kayaker Magic and Mike Lorrey teach classes to show how to put a small triangle at a distance from, for example, the stern of a ship to get a script to work....

For ease of scripting it is convenient to have sails rotate (more or less) with the mast as their axis of rotation. Crude sails can be created which are in effect "doors" using the tried and tested prim slicing method and thus appear to rotate around an edge which is in fact their natural Z-axis. Mesh sails are more realistic but can have their axes in somewhat arbitrary and unexpected places if not carefully constructed. The small triangle mentioned above is usually positioned at a distance from the main body of the sail that has the effect of moving the Z-axis (normally) to coincide with the forward edge of the sail, thus allowing the simplified scripting used for the "door" type sails to still be used.