[Opensim-dev] Update libode, or work towards better physics handling in this libode revision?
Mike Pitman
pitman at us.ibm.com
Tue Oct 7 18:39:36 UTC 2008
> Teravus writes:
> 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).
I'd really be surprised if double precision would make a noticeable
difference here. It does for energy conservation with realistic potentials
in molecular dynamics, but even there some folks get away with single
precision by playing tricks. I can imagine setting to double precision
while your tweaking things just to take the possibility of single precision
problems off the table though.
> 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.
Some thoughts/questions toward possible automated collision tests:
- Could we agree on a responce for an avatar falling and hitting the
ground from, say, 10m, 100m, and 1000m? Or do we want simple splat and
stand anim?
- How bouncy should they objects be, and how much is the physics vs
the material property?
- Do we want std tests of spheres for a range of materials falling
and colliding with other objects and terrain?
- Do we want pos/vel measurements at the inner timestep level or
inworld by scripts in the falling object calling out positions on a timer,
or both as a characterization of inworld vs server side timing?
- Is it useful to setup various chutes and circular slides for
spheres or pachinco type scenarious to test convergence of results with
decreasing timestep size, so we can find a largest timestep/min cpu effort
to get a consistent simulation result?
> 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)
I'm unsure on the specifics of the PID controller, but it seems like the
end game on tuning it may be very subjective and stylized (how many g's do
you want to pull when banking in flight?). Are there programmable bot
flight sequences that could be used to track changes in response?
> 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).
With a basis of tests and expected responses we might be able to get a
handle or a path to an overall figure of merit that could be simplex
optimized (scratches his grey beard) or something even more blunt. At the
very least, it may help speed up adopting and tuning physics updates in the
future...
> 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.
heh, no automation there..
> 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.
Tests might really help getting a uniform response across platforms
> 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.
I feel your pain. I spent many years in similar loops.. just seeing if
there's anyway to ease the burden...
Comments on some params in the ODE section of the ini file, (my comments
follow ###)
[ODEPhysicsSettings]
; World Step size. (warning these are dangerous. Changing these will
probably cause your scene to explode dramatically)
; reference: fps = (0.09375/ODE_STEPSIZE) * 1000;
world_stepsize = 0.020
world_internal_steps_without_collisions = 10
### clearly the param that has the main effect on stability and CPU usage
is stepsize, but steps without collisions
### is somewhat coupled inversely: larger stepsize may in some ranges
support smaller steps
### without collisions since that value is related to handling 'reasonable
velocities' for moving objects.
### There might be some guideline based on the product of the two:
world_stepsize * world_internal_steps_without_collisions
### which when multiplied by a 'reason velocity' gives the distance that
object would travel without a collision check
;World Space settings. Affects memory consumption vs Collider CPU time for
avatar and physical prim
world_hashspace_size_low = -4
world_hashSpace_size_high = 128
;Dynamic space settings Affects memory consumption vs Collider CPU time for
static prim
meters_in_small_space = 29.9
small_hashspace_size_low = -4
small_hashspace_size_high = 66
### Not sure whether hash table granularity is a sensitive tuning target
; Contact properties. (the stuff that happens when things come in contact
with each other)
; surface layer around geometries other geometries can sink into before
generating a contact
world_contact_surface_layer = 0.001
### Does this factor scale any material specific value for material
hardness? or is this a material independent factor?
; Non Moving Terrain Contact (avatar isn't moving)
nm_terraincontact_friction = 255.0
nm_terraincontact_bounce = 0.1
nm_terraincontact_erp = 0.1025
; Moving Terrain Contact (avatar is moving)
m_terraincontact_friction = 75.0
m_terraincontact_bounce = 0.05
m_terrainContact_erp = 0.05025
; Moving Avatar to object Contact
m_avatarobjectcontact_friction = 75.0
m_avatarobjectcontact_bounce = 0.1
; Object to Object Contact and Non-Moving Avatar to object
objectcontact_friction = 250.0
objectcontact_bounce = 0.2
### The bounce and friction may automatable with std ballistics/pachinco
tests
###
; PID Controller Settings. These affect the math that causes the avatar to
reach the
; desired velocity
; See http://en.wikipedia.org/wiki/PID_controller
av_pid_derivative_linux = 3200.0
av_pid_proportional_linux = 1400.0
av_pid_derivative_win = 2200.0
av_pid_proportional_win = 900.0;
;girth of the avatar. Adds radius to the height also
av_capsule_radius = 0.37
; Max force permissible to use to keep the avatar standing up straight
av_capsule_standup_tensor_win = 550000
av_capsule_standup_tensor_linux = 2000000
; used to calculate mass of avatar.
; float AVvolume = (float) (Math.PI*Math.Pow(CAPSULE_RADIUS,
2)*CAPSULE_LENGTH);
; av_density * AVvolume;
av_density = 80
; use this value to cut 52% of the height the sim gives us
av_height_fudge_factor = 0.52
; used to control llMove2Target
body_pid_derivative = 35
body_pid_gain = 25
; Used for llSetStatus. How rigid the object rotation is held on the axis
specified
body_motor_joint_maxforce_tensor_linux = 2
body_motor_joint_maxforce_tensor_win = 5
###
### Maybe some coded bot movement tests could help with the pid controller
settings ??
###
-Mike / Rez
"Teravus Ovares"
<teravus at gmail.co
m> To
Sent by: opensim-dev at lists.berlios.de
opensim-dev-bounc cc
es at lists.berlios.
de Subject
Re: [Opensim-dev] Update libode,
or work towards better physics
10/07/2008 10:11 handling in this libode revision?
AM
Please respond to
opensim-dev at lists
.berlios.de
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/20081007/8c80c69d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081007/8c80c69d/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic17417.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081007/8c80c69d/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081007/8c80c69d/attachment-0005.gif>
More information about the Opensim-dev
mailing list