<html><body>
<p>> Teravus writes:<br>
<tt>> To answer the question on tests/calibration.. I guess the purpose is<br>
> to set the variety of settings (and there are a plurality of them) to<br>
> produce reasonable physics results while using the least resources<br>
> possible in doing so. It might be easy to configure in double<br>
> floating point mode, but we'd use twice to three times the CPU to<br>
> accomplish that. Usually what I do is get it in a usable state with<br>
> high resource usage and scale the resource usage back until a balance<br>
> is acchieved. This usually requires a lot of trial and error,<br>
> additionally, in the past, it has required the same process for each<br>
> platform (win/*nix/mac).</tt><br>
<br>
<tt>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. </tt><br>
<tt><br>
> The first thing that I do is get collisions stable. Avatar shouldn't<br>
> fall through the ground or shoot millions of meters into the air when<br>
> they log-in.<br>
Some thoughts/questions toward possible automated collision tests: </tt><br>
<tt> - 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?</tt><br>
<tt> - How bouncy should they objects be, and how much is the physics vs the material property?</tt><br>
<tt> - Do we want std tests of spheres for a range of materials falling and colliding with other objects and terrain?</tt><br>
<tt> - 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?</tt><br>
<tt> - 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?</tt><br>
<tt> <br>
> Next, I tune the avatar PID controller so it moves the avatar's<br>
> physics proxy effectively. (un-tuned, you might see a result where<br>
> pressing a button causes you to go in the direction you want but with<br>
> a slow, curving direction change from from what seems like some random<br>
> direction)</tt><br>
<tt><br>
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?</tt><br>
<tt><br>
> After that, I find the best balance of frame frequency, collision<br>
> testing, contacts and contact friction.. and CPU usage while<br>
> testing against a very thin object in multiple directions. (tests to<br>
> ensure that I don't pass through a thin object at reasonable<br>
> velocities).<br>
</tt><br>
<tt>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...</tt><br>
<br>
<tt><br>
> After that, I usually patch the libode library with some fixes that<br>
> apply to our use case. In the past, superfluous asserts in the<br>
> library have caused random crashes. (Yes, I've tried to beat it over<br>
> the head of the ode developers and they insist on having them). Also,<br>
> in the past, the heightfield collider needed a few patches to work<br>
> properly. Without the patches, the ode library is very unstable.<br>
</tt><br>
<tt>heh, no automation there..</tt><br>
<tt><br>
> After that, I usually work on more fine grained details, like llMove2Target.<br>
<br>
> This process needs to be done for windows platforms and usually also<br>
> has to be done for *nix platforms. Furthermore, Mac platforms often<br>
> need a few small tweaks after that, but most of the *nix platform<br>
> settings apply.<br>
</tt><br>
<tt>Tests might really help getting a uniform response across platforms</tt><br>
<tt><br>
> This is a relatively long process of starting the simulator, fixing<br>
> something, stopping it.. starting it over again.. tweaking<br>
> something, stopping it.. over and over until it's right. There's<br>
> some math involved in finding what fps/collision detection settings<br>
> /could possibly/ be good, but a lot of it is just, trial and error.<br>
</tt><br>
<tt>I feel your pain. I spent many years in similar loops.. just seeing if there's anyway to ease the burden...</tt><br>
<br>
<tt>Comments on some params in the ODE section of the ini file, (my comments follow ###)</tt><br>
<br>
<br>
<tt>[ODEPhysicsSettings]</tt><br>
<tt>; World Step size. (warning these are dangerous. Changing these will probably cause your scene to explode dramatically)</tt><br>
<tt>; reference: fps = (0.09375/ODE_STEPSIZE) * 1000;</tt><br>
<tt>world_stepsize = 0.020</tt><br>
<tt>world_internal_steps_without_collisions = 10</tt><br>
<tt>### clearly the param that has the main effect on stability and CPU usage is stepsize, but steps without collisions </tt><br>
<tt>### is somewhat coupled inversely: larger stepsize may in some ranges support smaller steps </tt><br>
<tt>### without collisions since that value is related to handling 'reasonable velocities' for moving objects.</tt><br>
<tt>### There might be some guideline based on the product of the two: world_stepsize * world_internal_steps_without_collisions </tt><br>
<tt>### which when multiplied by a 'reason velocity' gives the distance that object would travel without a collision check</tt><br>
<br>
<tt>;World Space settings. Affects memory consumption vs Collider CPU time for avatar and physical prim</tt><br>
<tt>world_hashspace_size_low = -4</tt><br>
<tt>world_hashSpace_size_high = 128</tt><br>
<tt>;Dynamic space settings Affects memory consumption vs Collider CPU time for static prim</tt><br>
<tt>meters_in_small_space = 29.9</tt><br>
<tt>small_hashspace_size_low = -4</tt><br>
<tt>small_hashspace_size_high = 66</tt><br>
<tt>### Not sure whether hash table granularity is a sensitive tuning target</tt><br>
<br>
<tt>; Contact properties. (the stuff that happens when things come in contact with each other)</tt><br>
<tt>; surface layer around geometries other geometries can sink into before generating a contact</tt><br>
<tt>world_contact_surface_layer = 0.001</tt><br>
<tt>### Does this factor scale any material specific value for material hardness? or is this a material independent factor?</tt><br>
<br>
<tt>; Non Moving Terrain Contact (avatar isn't moving)</tt><br>
<tt>nm_terraincontact_friction = 255.0</tt><br>
<tt>nm_terraincontact_bounce = 0.1</tt><br>
<tt>nm_terraincontact_erp = 0.1025</tt><br>
<tt>; Moving Terrain Contact (avatar is moving)</tt><br>
<tt>m_terraincontact_friction = 75.0</tt><br>
<tt>m_terraincontact_bounce = 0.05</tt><br>
<tt>m_terrainContact_erp = 0.05025</tt><br>
<tt>; Moving Avatar to object Contact</tt><br>
<tt>m_avatarobjectcontact_friction = 75.0</tt><br>
<tt>m_avatarobjectcontact_bounce = 0.1</tt><br>
<tt>; Object to Object Contact and Non-Moving Avatar to object</tt><br>
<tt>objectcontact_friction = 250.0</tt><br>
<tt>objectcontact_bounce = 0.2</tt><br>
<tt>### The bounce and friction may automatable with std ballistics/pachinco tests</tt><br>
<tt>###</tt><br>
<br>
<tt>; PID Controller Settings. These affect the math that causes the avatar to reach the </tt><br>
<tt>; desired velocity</tt><br>
<tt>; See <a href="http://en.wikipedia.org/wiki/PID_controller">http://en.wikipedia.org/wiki/PID_controller</a></tt><br>
<tt>av_pid_derivative_linux = 3200.0</tt><br>
<tt>av_pid_proportional_linux = 1400.0</tt><br>
<tt>av_pid_derivative_win = 2200.0</tt><br>
<tt>av_pid_proportional_win = 900.0;</tt><br>
<tt>;girth of the avatar. Adds radius to the height also</tt><br>
<tt>av_capsule_radius = 0.37</tt><br>
<tt>; Max force permissible to use to keep the avatar standing up straight</tt><br>
<tt>av_capsule_standup_tensor_win = 550000</tt><br>
<tt>av_capsule_standup_tensor_linux = 2000000</tt><br>
<tt>; used to calculate mass of avatar. </tt><br>
<tt>; float AVvolume = (float) (Math.PI*Math.Pow(CAPSULE_RADIUS, 2)*CAPSULE_LENGTH);</tt><br>
<tt>; av_density * AVvolume;</tt><br>
<tt>av_density = 80</tt><br>
<tt>; use this value to cut 52% of the height the sim gives us</tt><br>
<tt>av_height_fudge_factor = 0.52</tt><br>
<tt>; used to control llMove2Target</tt><br>
<tt>body_pid_derivative = 35</tt><br>
<tt>body_pid_gain = 25</tt><br>
<tt>; Used for llSetStatus. How rigid the object rotation is held on the axis specified</tt><br>
<tt>body_motor_joint_maxforce_tensor_linux = 2</tt><br>
<tt>body_motor_joint_maxforce_tensor_win = 5</tt><br>
<tt>###</tt><br>
<tt>### Maybe some coded bot movement tests could help with the pid controller settings ??</tt><br>
<tt>###</tt><br>
<br>
<br>
<br>
<tt>-Mike / Rez</tt><br>
<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for "Teravus Ovares" ---10/07/2008 10:13:07 AM---No worries on the burden"><font color="#424282">"Teravus Ovares" ---10/07/2008 10:13:07 AM---No worries on the burden</font><br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td style="background-image:url(cid:2__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="40%">
<ul>
<ul>
<ul>
<ul><b><font size="2">"Teravus Ovares" <teravus@gmail.com></font></b><font size="2"> </font><br>
<font size="2">Sent by: opensim-dev-bounces@lists.berlios.de</font>
<p><font size="2">10/07/2008 10:11 AM</font>
<table border="1">
<tr valign="top"><td width="168" bgcolor="#FFFFFF"><div align="center"><font size="2">Please respond to<br>
opensim-dev@lists.berlios.de</font></div></td></tr>
</table>
</ul>
</ul>
</ul>
</ul>
</td><td width="60%">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">To</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">opensim-dev@lists.berlios.de</font></td></tr>
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">cc</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
</td></tr>
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">Subject</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">Re: [Opensim-dev] Update libode, or work towards better physics handling in this libode revision?</font></td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="58"><img width="1" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""></td><td width="336"><img width="1" height="1" src="cid:3__=0ABBFE48DFCD8A3C8f9e8a93df938@us.ibm.com" border="0" alt=""></td></tr>
</table>
</td></tr>
</table>
<br>
<tt>No worries on the burden<br>
<br>
To answer the question on tests/calibration.. I guess the purpose is<br>
to set the variety of settings (and there are a plurality of them) to<br>
produce reasonable physics results while using the least resources<br>
possible in doing so. It might be easy to configure in double<br>
floating point mode, but we'd use twice to three times the CPU to<br>
accomplish that. Usually what I do is get it in a usable state with<br>
high resource usage and scale the resource usage back until a balance<br>
is acchieved. This usually requires a lot of trial and error,<br>
additionally, in the past, it has required the same process for each<br>
platform (win/*nix/mac).<br>
<br>
The first thing that I do is get collisions stable. Avatar shouldn't<br>
fall through the ground or shoot millions of meters into the air when<br>
they log-in.<br>
<br>
Next, I tune the avatar PID controller so it moves the avatar's<br>
physics proxy effectively. (un-tuned, you might see a result where<br>
pressing a button causes you to go in the direction you want but with<br>
a slow, curving direction change from from what seems like some random<br>
direction)<br>
<br>
After that, I find the best balance of frame frequency, collision<br>
testing, contacts and contact friction.. and CPU usage while<br>
testing against a very thin object in multiple directions. (tests to<br>
ensure that I don't pass through a thin object at reasonable<br>
velocities).<br>
<br>
After that, I usually patch the libode library with some fixes that<br>
apply to our use case. In the past, superfluous asserts in the<br>
library have caused random crashes. (Yes, I've tried to beat it over<br>
the head of the ode developers and they insist on having them). Also,<br>
in the past, the heightfield collider needed a few patches to work<br>
properly. Without the patches, the ode library is very unstable.<br>
<br>
After that, I usually work on more fine grained details, like llMove2Target.<br>
<br>
This process needs to be done for windows platforms and usually also<br>
has to be done for *nix platforms. Furthermore, Mac platforms often<br>
need a few small tweaks after that, but most of the *nix platform<br>
settings apply.<br>
<br>
This is a relatively long process of starting the simulator, fixing<br>
something, stopping it.. starting it over again.. tweaking<br>
something, stopping it.. over and over until it's right. There's<br>
some math involved in finding what fps/collision detection settings<br>
/could possibly/ be good, but a lot of it is just, trial and error.<br>
<br>
Best Regards<br>
<br>
Teravus<br>
<br>
<br>
On 10/7/08, Dr Scofield <DrScofield@xyzzyxyzzy.net> wrote:<br>
> Teravus Ovares wrote:<br>
> > ok, so far, 2 for update, 0 for current lib.<br>
><br>
> +1 for update --- but i'm kind of feeling bad saying that because that places a<br>
> tremendous burden on you...<br>
><br>
> --<br>
> dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab<br>
> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- </tt><tt><a href="http://xyzzyxyzzy.net/">http://xyzzyxyzzy.net/</a></tt><tt><br>
> RL: hud@zurich.ibm.com - +41 44 724 8573 - </tt><tt><a href="http://www.zurich.ibm.com/~hud/">http://www.zurich.ibm.com/~hud/</a></tt><tt><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> Opensim-dev@lists.berlios.de<br>
> </tt><tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a></tt><tt><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
</tt><tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a></tt><tt><br>
</tt><br>
</body></html>