Viewer technical questions

[animats]

Some questions about viewer internals:

1. The host (sim) side has a physics engine, and the viewer side also has a physics engine. The sim side treats avatars as a capsule. The viewer side apparently treats avatars as a mesh object. Or at least that's what you see if you turn on Developer->Render metadata->Collision skeleton. What is that collision skeleton used for? Clothing? As far as I can tell, the only thing the viewer-side physics engine does is breast jiggle. It also apparently helps with uploading collision meshes for objects. Does that mean it's calculating the convex hulls?
2. What does Firestorm use for a physics engine, if anything? I came across a reference to Bullet, but don't know if that's actually in.
3. Is there anywhere this is discussed by people who actually know how it works? I've read through what passes for internal documentation for the viewer, but it doesn't mention physics at all.

[Beq Janus]

All actual physics is managed on the server side. Second Life uses a 3rd party physics engine known as Havok . When a collision event occurs it is always the sim that has detected it.

An example of this is when you try to drag a pot plant from your inventory onto your coffee table, where does it land? The decision happens in two stages. The viewer uses a combination of ray tracing and other functions to identify the "object" on which your item will land, hopefully, your table. The sim is sent this information and uses the physics shape to decide exactly where your dropped item sits, ideally the table top. This is one important reason why you should encourage creators to define a proper, representative physics shape. When the server side physics does not correspond well with the visual shape things go wonky

As you note, the breast physics are not handled by the sim, we all do our own jiggling. Breast physics is different to game engine physics in the sense that it is a deformation, like the compression of a bouncing ball as it hits the ground and not a collision detection capability. The collision skeleton is exactly that, the shape of your avatar as it appears to the sim.

The viewer does not have a physics engine that is used in its runtime operation at all. The render metadata views that you see, whether that be the "physics view" and the "collision mesh" view, are emulated. Occasionally this goes wrong and you get slightly odd behaviour. Where we do use physics is in mesh upload. The Mesh upload function has a physics tab and a mesh asset in SL has 3 possible representations of the physics shape. The most basic is the "base hull" this is the "plastic wrap" physics shape that you get when an object has "convex hull" selected as its shape. Next up we have what is probably the most common, the mesh physics, this is a physics shape defined by the triangles of a user-provided mesh model. However, that mesh-based physics is still only processed on the server side for collisions. Finally, we have the hull-based physics which it accessed through the optional "analyze" and "simplify" functions on the upload tab. These functions take the same user-provided mesh model and try to decompose it into a series of simple objects known as hulls which the physics engine on the server side knows how to optimise. To do this analysis, the viewer uses a small stub library provided by Linden Lab, which has a very specific limited set of functions to perform the hull conversion. 

Just a note on mesh upload and Havok, mesh upload is perfectly viable without Havok support, contrary to much urban myth. If your viewer of choice does not have Havok support (for example the current release of Firestorm 64 bit) then you will find that the analyze function is limited to the "default" method and that simplify is greyed out.This does not stop mesh being uploaded with the triangle physics, or even the default analyzed physics, it just means you have reduced options.

The only other area of the viewer that "needs" physics knowledge explicitly, is some of the pathfinding

Bullet is an open source physics engine that is widely used in the CG industry and is used in some Open Sim grids, again, it works on the server side and does not require client-side support.

There is not a lot of current documentation and Linden Lab are a little tight-lipped about the specifics of physics on the server-side, where things like the algorithm for the physics cost element of the  Object LI is incomplete in the wiki pages. 

A number of builders have discussions on physics creation but few cover the mechanics. As I have a foot in both the viewer dev and builder camps I have blogged a little more on the mechanics and the tools but even this is mostly implied knowledge and I would not claim to have everything right or complete. The best way to get answers is to ask in places like this, or inworld builder groups such as Mesh  Dev and Builders' Brewery but as with all things, be aware that misinformation lives on forever and there is a lot of bad information that get repeated so often that it becomes assumed to be true. 

Hope this helps.

 

Edited December 14, 2017 by Beq Janus
minor grammar fixups

[Polymath Snuggler]

Just to add a little addendum to Beq's lovely essay describing physics.  The avatar collision skeleton is primarily used for resolving clicks ( left and right ) on an avatar.  For example when you want to right click on your friend to see what their profile update is ~ in order for the viewer to "solve" that you've clicked on your friend it uses the collision volumes.  These collision volumes are also what allow you to "cam onto" someone and for the camera to stick.  The camera uses the Collision Volume to resolve where to point and what to follow around. This is what allows you to "stick" your camera to your friends head to look at their face, or stick it to another region of their body to examine that.  I believe that this is slightly different than "bounding box" resolving which is how we bump into things in the world or what responses are given for LLCastRay collision hits from such things as weapons and combat scripts.  This means that if your avatar is playing an animation that has your hands extended in front of you like a zombie, the arm collision volumes do not dictate when you bump into the wall, rather the extended avatar bounding box does.  As best I can tell the avatar collision bounding box does change based on a number of things including your present height, sitting status, etc, but it does not change based on what animations you are presently in, in fact I'm pretty sure that you can walk your "Collision volumes" completely out of your bounding box via an animation, thus visually being clickable in one location, while your bounding box is in fact in another.

Edited December 14, 2017 by polysail
Minor additions!

[Oz Linden]

Beq and polysail have it right.