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

[Stefan Andersson]

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 AnderssonTribal 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081008/901e3fc4/attachment-0001.html>