[Opensim-users] Changed default av_capsule_tilted to false inOpenSim master

[Zane Legion]

Thanks for the explanation nlin. For me (on 0.6.7-post-fixes), tilted=false 
solved the bendy knee issue and the feet partially underground issue, 
although everyone now seems to float slightly above the ground.

I'll keep a lookout for the other two issues you mention.

Zane
--------------------------------------------------
From: "nlin" <nlin.message at gmail.com>
Sent: Tuesday, November 10, 2009 12:37 PM
To: <opensim-users at lists.berlios.de>
Cc: <opensim-dev at lists.berlios.de>
Subject: Re: [Opensim-users] Changed default av_capsule_tilted to false 
inOpenSim master

> Hi,
>
> 2009/11/10, Justin Clark-Casey <jjustincc at googlemail.com>:
>> There was a bit of discussion last week in the OpenSim dev's office hour 
>> and on
>> irc that changing av_capsule_tilted = false in OpenSim.ini.example would 
>> be a
>> good idea in the master branch for avatar related physics for ODE.
>
> The av_capsule_tilted=false should generally be safe. Please let me
> mention some general things to watch out for. These shouldn't be a
> problem now, but were problems that I encountered and hopefully fixed:
> 1) Avatar falling through terrain
> 2) Extremely rapid changes of direction and movement could conceivably
> cause the avatar capsule to become unstable.
>
> Note that these items are refer to poor behavior in terms of the
> physics engine itself (visualized with drawstuff), as opposed to ways
> that poor behavior might manifest itself in the viewer (such as
> bendy-knees).
>
> Regarding 1, terrain collisions, reducing the avatar tilt seems to
> increase the tendency of the avatar to fall through the terrain - this
> has something to do with the ODE terrain collider, which I wasn't able
> to fully debug - anyone wanting to give it a shot, let me know. As a
> workaround, currently a small, experimentally-determined tilt is
> maintained (even with tilt=false) to prevent falling through the
> terrain. This isn't ideal, but seems to work well enough.
>
> Regarding 2, rapid changing of avatar direction: The tilt rotates with
> the avatar, snapped in 90-degree increments to one of  four directions
> (NE,NW,SE,SW), so that the direction of the tilt always is opposite
> the direction of movement. In other words, if your avatar is moving
> forwards, the avatar is leaning slightly backwards. The reason the
> tilt is rotated with the avatar is to reduce/remove
> direction-dependent behavior, such as being only able to climb over
> prims from a certain direction. The reason the tilt rotation is
> snapped to 90-degree increments, instead of smoothly rotating with the
> avatar, is to prevent extremely rapid changes in tilt orientation,
> which is done by setting ODE motor stops. If you change ODE motor
> stops too rapidly, the avatar capsule may "explode" and go flying
> several hundred meters into the air. Conceivably, if your avatar
> walked directly straddling a line facing northeast and constantly did
> a zig-zag motion above and below the NE line, this could cause the
> avatar orientation to change rapidly enough to cause avatar
> instability. In practice I doubt that this will be an issue. (Still,
> would be interesting to write a bot to try to provoke this behavior.)
>
> More generally, however, this dynamically rotating tilt is not ideal.
> I think there are 2 avatar physics issues that need further
> investigation:
>
> 1. Removing the tilt completely instead of just reducing it. Currently
> not workable because the terrain collider then allows the avatar
> capsule to fall through sometimes. Fixing this would allow complete
> consistency (direction-independence) in avatar physics behavior, close
> avatar interactions like hugging, and no need for changing the motor
> stops while the avatar is moving, reducing risk of explosion.
>
> 2. Allowing flexible height of steps that the avatar can step over.
> Currently the bottom-most hemisphere of the avatar capsule always
> drags against the terrain or any objects it collides with. This has
> the limitation that the height of obstacles that can successfully be
> stepped over cannot be directly tuned, as it depends indirectly on the
> size of the hemisphere and the specifics of collision handling (things
> like ERP, CFM, bounce). Ideally we would want to be able to directly
> tune the height of "steppable" objects in OpenSim.ini, or perhaps have
> this be different per avatar (dependent e.g. on the avatar height).
> But it looks like we would probably have to implement a new avatar
> physics mechanism to handle this flexibly: something like a floating
> capsule, capsule+sphere, or using mesh collisions instead of primitive
> capsules.
>
> -nlin
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>