I have recently had some very informative conversations with ckrinke, where he related a number of things he has found in the opensim physics code while investigating how physical prim properties are represented.<br><br>Many things gelled in my mind during our conversation:<br>
<br>- if one uses only the global CFM/ERP to manipulate the collision properties of prims, one can simulate at most one material<br>- if one uses a per-object CFM/ERP profile one can simulate infinite materials, or at least as many as one has objects for<br>
- if one optimizes on a standard set of CFM/ERP profiles, one can simulate classes of materials<br>- if one simulates vehicles at the scene level, one is running a machine simulation<br><br>perhaps the most pertinent to this conversation is the latter observation:<br>
<br>"if one simulates vehicles at the scene level, one is running a machine simulation"<br><br>this may seem desirable, but is, in fact, not what we do when we employ vehicle scripting APIs in SL<br><br clear="all">
the vehicle scripting API in SL represents hooks to a generalized class of simple machines in SL as an abstraction; i.e., for a motor, we don't simulate the firing of pistons, the work lost to inefficiency of e.g., a driveshaft, or friction with the ground based on material type. Instead, we say we have a source of torque; it is damped in these axis; and produces a net force in all others.<br>
<br>Similarly, we classify the entire vehicle as having certain characteristics such as bouyancy and moment along or around some axis, in order to characterise the damping that occurs with respect to the motor(s).<br><br>
Through creative employment of these simple abstractions we create a host of physical vehicles that run the gamut from skateboards to boats to airplanes to rockets.<br><br>I propose that this is a viable approach for us as well. By implementing a 'sub' physics engine - i.e., one to synthesize the parameters (and perhaps others) mentioned above into a final 'product' or 'sum' of forces/orientations resulting from these motors and dampers, we can produce a physical 'product' or 'sum' that results in a delta for force (vector) and orientation (quaternion), that would then be supplied to the scene physics for the scene 'object' (prim or linkset) that is the vehicle. Typical scene dynamics then update the position and orientation of the object relative to the scene.<br>
<br>What's more, is that I can see a clear path to an SL-compatible API in the script engine to implement these notions. Being an abstraction, they do not necesarily have to reflect engine-specific implementation details or features. Also, being an abstraction, they may be implemented over a variety of physics engines, given sufficient capability in the target engine.<br>
<br>Any comments? Thoughts? Critiques?<br><br>Please, I know very little of the internal operations of the physics engine and the scene. Enlighten me where I am in the dark.<br><br>Thanks for taking the time to examine my feeble ideas :)<br>
<br>Cheers!<br>James<br>-- <br>===================================<br>The wind<br>scours the earth for prayers<br>The night obscures them<br><br><a href="http://osgrid.org">http://osgrid.org</a><br><a href="http://del.icio.us/SPQR">http://del.icio.us/SPQR</a><br>
<a href="http://twitter.com/jstallings2">http://twitter.com/jstallings2</a><br><a href="http://www.linkedin.com/pub/5/770/a49">http://www.linkedin.com/pub/5/770/a49</a><br>