James, good thoughts.<div><br></div><div>Before developing an abstraction layer, I would probably look at differences between the LSL vehicle API and the ODE API. Then I would look at other vehicle simulations in other physics implementations and note the commonalities, given the plug-in architecture that OpenSim is currently using. Where there is common ground between physics implementations may be an opportunity to improve our physics interface. Where there is something missing between LSL and the various physics engines is where the opportunity lies to develop a functional abstraction, rather than just an interface layer. Another alternative may be for the interface layer to pass vehicle calls to a special vehicle module which could then construct the proper common physics engine calls and pass them to the physics engine.</div>
<div><br></div><div>There seems to be a lot of momentum building around the newer GPU based physics and future viewers may provide some level of client side simulation for vehicles. In this case the current LSL API may be a short term goal for current opensim users but may quickly become deprecated in favor of more realistic simulations. Any work done with vehicle physics should probably allow for this form of future enhancement.</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On Thu, Nov 6, 2008 at 7:18 AM, James Stallings II <span dir="ltr"><<a href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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" target="_blank">http://osgrid.org</a><br><a href="http://del.icio.us/SPQR" target="_blank">http://del.icio.us/SPQR</a><br>
<a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br><a href="http://www.linkedin.com/pub/5/770/a49" target="_blank">http://www.linkedin.com/pub/5/770/a49</a><br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>