[Opensim-dev] A proposal for a viable physical vehicle abstraction architecture

[Dahlia Trimble]

James, good thoughts.
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.

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.



On Thu, Nov 6, 2008 at 7:18 AM, James Stallings II <
james.stallings at gmail.com> wrote:

> 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.
>
> Many things gelled in my mind during our conversation:
>
> - if one uses only the global CFM/ERP to manipulate the collision
> properties of prims, one can simulate at most one material
> - if one uses a per-object CFM/ERP profile one can simulate infinite
> materials, or at least as many as one has objects for
> - if one optimizes on a standard set of CFM/ERP profiles, one can simulate
> classes of materials
> - if one simulates vehicles at the scene level, one is running a machine
> simulation
>
> perhaps the most pertinent to this conversation is the latter observation:
>
> "if one simulates vehicles at the scene level, one is running a machine
> simulation"
>
> this may seem desirable, but is, in fact, not what we do when we employ
> vehicle scripting APIs in SL
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> Any comments? Thoughts? Critiques?
>
> Please, I know very little of the internal operations of the physics engine
> and the scene. Enlighten me where I am in the dark.
>
> Thanks for taking the time to examine my feeble ideas :)
>
> Cheers!
> James
> --
> ===================================
> The wind
> scours the earth for prayers
> The night obscures them
>
> http://osgrid.org
> http://del.icio.us/SPQR
> http://twitter.com/jstallings2
> http://www.linkedin.com/pub/5/770/a49
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081106/ea4f59ff/attachment-0001.html>