[Opensim-dev] Using ODE for vehicles and ragdolls

nlin (message) nlin.message at gmail.com
Fri Nov 21 14:12:45 UTC 2008 

Hello,

Great to see all of the work on and interest in vehicles and ODE in
OpenSim. I have posted a highly experimental patch to enable jointed
ODE vehicles, based off of r7394. The project is on GForge here:

http://forge.opensimulator.org/gf/project/physicsjoints/

Though this patch is nowhere near complete, I thought it might help
the discussion by providing an illustrative example of a working
prototype implementation of jointed ODE vehicles in OpenSim.

Please have a look if you are interested; feedback and discussion
would be most welcome.

Thanks,
N Lin (nlin)


2008/11/19, James Stallings II <james.stallings at gmail.com>:
> Heh.
>
> For the record:
>
> It was I who first demostrated the possibility of using
> llSetForce/llApplyImpulse as a viable method of making a prim behave like a
> vehicle, some 10 months or so ago. During a conversation with one Owen Oyen
> (who is something of a physics guy), of SL and OSGrid, he became aware of my
> proof-of-concept efforts along these lines and produced a working vehicle
> script.
>
> On the linden grid, Owen is a boat scripter and scripter of related
> technologies; he has, for instance, devised a means of producing current
> effects based on a model of the contour of the sea floor
>
> While our current work is targeted directly at boating, it can be readily
> adapted to encompass all of the typical vehicle types of SL, without any of
> their vehicle functions.
>
> This model is very primitive, as are those presented in the LSL Vehicle API
> as found in LL's LSL.
>
> The characteristics of the LSL vehicle API as implemented by LL are quite
> simple:
>
> 1. Linear motors. These motors provide motive force parallel to a given axis
> or axes.
> 2. Torque motors. These motors provide rotational force about an axis or
> axes.
>
> That's it. Period.
>
> These two models are further modified by a series of contraints that
> introduce the concept of friction or other load against the forces provided
> by these motors.
>
> Tidy all this up into a 32 bit bitfield for describing the motive forces and
> their loads and wrap it up in a nice set of functions exposing this via LSL
> commands that characterise a vehicle 'type' (e.g., boat/car/plane) with any
> related constraints/dampers and you have Linden vehicle physics.
>
> As I said, this is a highly simplified vehicle simulation model. There is no
> distribution of mass involved, no geometry-based drag. There is a single
> center of gravity at the geometric center. All motion produced by the calls
> to the API is produced around this center. The complexity all rests witth
> the description of the motive forces and their respective loading and
> damping. The forces are applied either to a simple prim in the simplest
> case, or to a linkset. If to a linkset, the linkset is treated as a single
> object except for collision purposes, the extent of which is to mesh any
> geometric complexities of the object.
>
> The short story is, we have modelled LSL-style vehicles using little but
> llApplyImpulse and llSetForce, and a first-order friction calculation.
> Ironically, our experiences indicate that these vehicles are consistently
> better in their handling characteristics than what is available on the
> Linden grid. Indeed, about half of Owen's current work is in the interest of
> porting this work *back* to the linden grid.
>
> Enough of that. Lets talk ODE :D
>
> ODE *does* present some rich opportunities for simulation beyond the
> (arguably oversimplified) model presented by the LSL vehicle API. given the
> type of things I've seen reading the ODE documentation, my suspicion is that
> it's strong points for such simulations will be wheeled vehicles, tracked
> vehicles, walkers, and by extension, ragdoll/skeletal physics. These would
> certainly add an interesting element to the mix, and I am all for seeing
> these ideas roll forward.
>
> I do, however, wish to draw a strong distinction between this ODE work and
> basic vehicle physics ala Linden Labs, as the vehicle paradigm in LSL is so
> heavily abstracted that 'simulation', for any meaningful employment of the
> word, is at best inaccurate, and at most hype. Worse, their method of
> 'simplifying' (read 'dumbing down'), adds significant processing cycles;
> were I to guess, I'd say that their API represents greater processing
> overhead than do the physics proper.
>
> I'd say +1 for rolling forward with some OS functions for ODE; indeed, I
> would suggest (as I have been for some 9 months now) that ODE's interface be
> exposed directly in a set of OS functions, allowing the scripter to work in
> a relationship that is only once removed from the physics engine, in the
> interest of providing the fullness of the ODE featureset to the scripter. I
> think some fabulously interesting things would come of this, not the least
> of which might be a more interesting in-world experience for those of us who
> primarily employ this as an entertainment platform.
>
> Keep up the good work y'all, this is an excellent dialogue and I hope I have
> contributed in some way to a clarification of the events surrounding our
> recent in-world vehicle work (btw we should be ready to demo some of this
> broadly this coming weekend), and to the issues that lie ahead as we work to
> bring more physics features to the scripting language and our virtual
> environment.
>
>
> Cheers!
> Hiro/daTwitch/Laz...etc.
>
>
>
> On Wed, Nov 19, 2008 at 6:14 AM, Stefan Andersson
> <stefan at tribalmedia.se>wrote:
>
>>  I for one would love to see it unfold something like this
>>
>> 1) one or several prototypical and specialized implementations coding
>> directly to ODE but in a nice manner.
>> 2) the implementations refactored into a nice OpenSim API for ODE joints
>> 3) one or several implementations of vehicles utilizing this API directly
>> 4) these implementations refactored into a nice OpenSim vehicle API
>> 5) implementing the LSL vehicle model using this API
>>
>> so yeah, bottom up is the way to go, but with a clear goal in the back of
>> our heads.
>>
>> I for one would want to see the monorail module before the monorail lsl
>> script.
>>
>> I also suspect that along the lines, we might see that we want to
>> implement
>> vehicle types that don't fit into the lsl model... like the 'humanoid' or
>> 'animal' - anybody up for building a stone giant or re-casting an agent in
>> pure prims? :D
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>> Join the 3d web revolution : http://tribalnet.se/
>>
>>
>>
>>
>>
>> > From: adam at deepthink.com.au
>> > To: opensim-dev at lists.berlios.de
>> > Date: Wed, 19 Nov 2008 02:01:27 -0500
>>
>> > Subject: Re: [Opensim-dev] Using ODE for vehicles and ragdolls
>> >
>> > Doesnt ODE have vehicle support internally? The concern I'd have about a
>> vehicle layer over the top might be that performance is suboptimal since
>> we
>> need to run a second physics step which could introduce issues.
>> >
>> > Regards,
>> >
>> > Adam
>> >
>> > > -----Original Message-----
>> > > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>> > > bounces at lists.berlios.de] On Behalf Of Gerhard Dünnebeil
>> > > Sent: Tuesday, 18 November 2008 10:40 PM
>> > > To: opensim-dev at lists.berlios.de
>> > > Subject: Re: [Opensim-dev] Using ODE for vehicles and ragdolls
>> > >
>> > > Hi
>> > >
>> > > having looked into the ODE engine I don't think it's usable for the
>> > > vehicle API.
>> > >
>> > > Instead i think we should put the vehicle engine on top of it.
>> > >
>> > > This is pretty easily done by adding another layer (could/should be in
>> > > a
>> > > plugin).
>> > > It can be called in each "Simulate" step and calculate the forces
>> > > needed
>> > > to achieve the vehicles behaviour.
>> > > These forces are then applied -- using the phys engine's API -- to the
>> > > objects.
>> > >
>> > > This way we are
>> > > a) ... independant (at least theoretically) from the characteristics
>> > > of
>> > > the underlying Phys engine
>> > > b) ... able to implement different engines for different purposes
>> > >
>> > > I know someone (is it you, nlin?) already implemented a sailing boat
>> > > in
>> > > OpenSim. A modular approach here would allow us to implement
>> > > alternative
>> > > friction models beyond what LSL gives us.
>> > >
>> > >
>> > > Just my two cents
>> > >
>> > > Gerhard
>> > >
>> > >
>> > > nlin (message) wrote:
>> > > > Hello,
>> > > >
>> > > > There's been some discussion about SL-compatible vehicles in OpenSim
>> > > > recently, with its higher-level abstraction of how vehicles work.
>> > > This
>> > > > would have the long-term goals of compatibility and ability to swap
>> > > > out physics engines while still using the same vehicle layer.
>> > > >
>> > > > SL-compatibility and abstracting vehicles from the physics engine
>> > > > are
>> > > > good goals for the long term; sort of a top-down approach (start
>> > > > with
>> > > > the vehicle abstraction, map it to many different physics engines).
>> > > >
>> > > > Complementary to this, I'd like to explore and start discussion of
>> > > > an
>> > > > alternative way of handling vehicles by using a bottom-up approach.
>> > > > Starting with the specific physics engine of ODE, can we use
>> > > > ODE-specific features to make simple vehicles?
>> > > >
>> > > > I did some experiments with OpenSim and ODE and the answer seems to
>> > > be
>> > > > yes, we can make simple vehicles with ODE by using joints. We can
>> > > also
>> > > > make ragdolls. I posted some videos to YouTube of the preliminary
>> > > results:
>> > > >
>> > > > http://www.youtube.com/watch?v=iYIh-eIwmjs
>> > > > http://www.youtube.com/watch?v=z9bedzIuxdM
>> > > >
>> > > > This is only prototype work for now, put together sort of quickly as
>> > > a
>> > > > proof-of-concept with just enough "plumbing" (data flow) to work.
>> > > > There are a number of issues that need to be solved for this to work
>> > > > cleanly. As far as I know (please correct me if I'm wrong) there
>> > > > hasn't been much work done to try to get ODE
>> > > > joints/vehicles/ragdolls
>> > > > working in OpenSim, but I think it's an avenue worth exploring.
>> > > >
>> > > > Is there interest in pursuing this approach for OpenSim vehicles? I
>> > > > would look forward to discussing some of the issues that would need
>> > > to
>> > > > be solved.
>> > > >
>> > > > Thanks,
>> > > > N Lin (nlin)
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > ---
>> > > >
>> > > > _______________________________________________
>> > > > Opensim-dev mailing list
>> > > > Opensim-dev at lists.berlios.de
>> > > > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> > > >
>> > >
>> > > _______________________________________________
>> > > Opensim-dev mailing list
>> > > Opensim-dev at lists.berlios.de
>> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
> --
> ===================================
> 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
>

More information about the Opensim-dev mailing list