Zane Legion wrote: > 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.
Yes, thanks very much for the insight, Norman. > > I'll keep a lookout for the other two issues you mention. > > Zane > -------------------------------------------------- > From: "nlin" <[email protected]> > Sent: Tuesday, November 10, 2009 12:37 PM > To: <[email protected]> > Cc: <[email protected]> > Subject: Re: [Opensim-users] Changed default av_capsule_tilted to false > inOpenSim master > >> Hi, >> >> 2009/11/10, Justin Clark-Casey <[email protected]>: >>> 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 >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-users >> > _______________________________________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-users > -- justincc Justin Clark-Casey http://justincc.org _______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
