[Opensim-dev] Update libode, or work towards better physics handling in this libode revision?

[Teravus Ovares]

Some of them are changable while the simulation is running, some of
them are not.   Most of them have a path C consequence.  (You start
with settings 1, and are on path A, you want to move to settings 2 and
end up on path B, but instead you move to settings 2 and end up on
Path C).   The parameters that you can't change in mid stream will
cause your world to explode if you change them between steps(worldstep
is a notable one like this).  Many, if you change the settings
'wrong', if your world doesn't explode immediately, your world will
accumulate simulation errors that will cause you not to get consistant
results after the settings change.

Physics depends on what happens the last time the world was stepped.
If you change the parameters between steps, things get weird.

Best Regards

Teravus


On 10/8/08, Stefan Andersson <stefan at tribalmedia.se> wrote:
> Teravus,
>
> would it be possible to re-structure (no, this is not refactoring) the
> internals of the physics engines so you could change or re-load those
> parameters in real time? Or at least a sub-set of the parameters?
>
> Not knowing what efforts would have to go into that, it might have a short
> ROI from what I understand, especially since you state that the same ardous
> work has to be duplicated over various environments.
>
> It would also have the added bonus of us slowly inching towards a situation
> where we don't have to re-start the region for every environment change,
> something that has become more and more of a problem for us lately when
> testing and debugging applications.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
> Join the 3d web revolution : http://tribalnet.se/
>
>
>
>
> ________________________________
>
> > Date: Tue, 7 Oct 2008 10:11:00 -0400
> > From: teravus at gmail.com
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] Update libode, or work towards better physics
> handling in this libode revision?
> >
> > No worries on the burden
> >
> > To answer the question on tests/calibration.. I guess the purpose is
> > to set the variety of settings (and there are a plurality of them) to
> > produce reasonable physics results while using the least resources
> > possible in doing so. It might be easy to configure in double
> > floating point mode, but we'd use twice to three times the CPU to
> > accomplish that. Usually what I do is get it in a usable state with
> > high resource usage and scale the resource usage back until a balance
> > is acchieved. This usually requires a lot of trial and error,
> > additionally, in the past, it has required the same process for each
> > platform (win/*nix/mac).
> >
> > The first thing that I do is get collisions stable. Avatar shouldn't
> > fall through the ground or shoot millions of meters into the air when
> > they log-in.
> >
> > Next, I tune the avatar PID controller so it moves the avatar's
> > physics proxy effectively. (un-tuned, you might see a result where
> > pressing a button causes you to go in the direction you want but with
> > a slow, curving direction change from from what seems like some random
> > direction)
> >
> > After that, I find the best balance of frame frequency, collision
> > testing, contacts and contact friction.. and CPU usage while
> > testing against a very thin object in multiple directions. (tests to
> > ensure that I don't pass through a thin object at reasonable
> > velocities).
> >
> > After that, I usually patch the libode library with some fixes that
> > apply to our use case. In the past, superfluous asserts in the
> > library have caused random crashes. (Yes, I've tried to beat it over
> > the head of the ode developers and they insist on having them). Also,
> > in the past, the heightfield collider needed a few patches to work
> > properly. Without the patches, the ode library is very unstable.
> >
> > After that, I usually work on more fine grained details, like
> llMove2Target.
> >
> > This process needs to be done for windows platforms and usually also
> > has to be done for *nix platforms. Furthermore, Mac platforms often
> > need a few small tweaks after that, but most of the *nix platform
> > settings apply.
> >
> > This is a relatively long process of starting the simulator, fixing
> > something, stopping it.. starting it over again.. tweaking
> > something, stopping it.. over and over until it's right. There's
> > some math involved in finding what fps/collision detection settings
> > /could possibly/ be good, but a lot of it is just, trial and error.
> >
> > Best Regards
> >
> > Teravus
> >
> >
> > On 10/7/08, Dr Scofield <DrScofield at xyzzyxyzzy.net> wrote:
> > > Teravus Ovares wrote:
> > > > ok, so far, 2 for update, 0 for current lib.
> > >
> > > +1 for update --- but i'm kind of feeling bad saying that because that
> places a
> > > tremendous burden on you...
> > >
> > > --
> > > dr dirk husemann ---- virtual worlds research ---- ibm zurich research
> lab
> > > SL: dr scofield ---- drscofield at xyzzyxyzzy.net ----
> http://xyzzyxyzzy.net/
> > > RL: hud at zurich.ibm.com - +41 44 724 8573 -
> http://www.zurich.ibm.com/~hud/
> > > _______________________________________________
> > > 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
>
>