Advice for articulated character getting stuck

[Jetro Lauha]

(I'm not sure if this is a double-post - I sent this message to ode-
users@... but it seemed to get silently discarded, or at
least I don't see my message in the group.)

Hi,

I'm creator of the "Dismount" games, and just lately tried a new
scenario.
Since the rag doll is composed of multiple bodies, I have always had
the
problem that sometimes it gets stuck to other (static) geoms in the
scene
in a nasty way.

Typically this happens so that one or more of the dynamic objects get
stuck
between two geoms and have hard time "getting out", e.g. between two
stairs
in the Stair Dismount (the stair geoms didn't have any overlap - do
you think
that is a good idea?). Or alternatively if there's a thin geom, some
of the
jointed bodies end up being on other side of the thin object and rest
on the
opposite side, so that joints try to keep the bodies together but
collision
detection keeps forcing them back to the opposite sides. This happens
e.g.
with the window shield in Truck Dismount.

However, just lately I noticed somewhat similar behavior but so that
the
ragdoll's body parts got stuck only in a very big box, so that any
part didn't even
pop out from the other side. This particular kind of situation is
somewhat newer
to me and I started wondering if my scene or simulation setup is
perhaps
somewhat odd, or if there would be some tricks I'm not aware of.

Here is image of the poor fellow getting stuck to a wall:
    http://jet.ro/tmp/kiuasturvat-20080723-wall.jpg
he happens to hang just above a sauna stove, since this is a "Sauna
Dismount".. :-)
Notice how the right arm is almost completely embedded in the wall
(which is
actually just a big cube).

If the wall is not rendered at all and camera is put inside the wall,
it looks like this:
    http://jet.ro/tmp/kiuasturvat-20080723-wall-inside.jpg
Things to note is how the forearm is somewhat detached from the arm,
and hand
is detached from the arm.

Executable version (for windows) is available here for now: (at end of
the page)
    http://www.assembly.org/summer08/news/compos/gamedeventries


This sort of problems manifest more often the sloppier the simulation
set up is,
i.e. if step size is big or when using quickstep with low number of
iterations.
However, for now I actually even switched to the good old dWorldStep
and that
doesn't prevent these problems from happening.

I'm currently using step size of 0.04 (trying to simulate 60 frames
per second).
Naturally I have experimented with other parameters as well, but the
current
snapshots seems to be: global CFM 0.001, global ERP 0.9 (which is
quite low?),
gravity -1.4, max contact amount 10, auto disable on w/average sample
count 1
(the ragdoll still jitters enough that it doesn't really get disabled
until game timer
stops the action).

I haven't currently set ContactMaxCorrectingVel or
ContactSurfaceLayer, although
I have tested those as well at times with values 0.1 and 0.001 for
example.
I'm not doing any contact merging or other fancy stuff like that, and
I'm running
the simulation with floats (single precision).

Simulation step just executes dSpaceCollide followed by dWorldStep. In
the
near callback I filter out bodies connected to each other or otherwise
disabled
from colliding with each other (using a custom map). Contact surface
mode
is simply just dContactBounce for now, with mu 500, bounce 0.1 and
bounce_vel 8.0.  In the past I have had some more stuff enabled in the
contact
mode, e.g. dContactSoftCFM with some very low soft_cfm, as well as
dContactApprox1 with some minimal values, without really thinking too
much
which ones I actually need. This time I just put in the bounciness for
now.


It's quite a bit of work trying to isolate a separate test app for
this stuff (with having
all sorts of scene setup, merging, xml loading etc in place), so sorry
for not giving
a test framework. If some of you have had similar problems and found
out ways to
prevent or workaround these issues, I'd still be glad to hear any
tips!


--
Jetro Lauha - http://jet.ro
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@...
To unsubscribe from this group, send email to ode-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Riemer v.d. Zee]

Hello,

First of all, could you please tell us which version you are using of
ODE? maybe switching to a newer version would help solving a few
problems.
Also I have noticed you said something of having a 'max contact amount
10', maybe increasing this value would help.

Riemer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@...
To unsubscribe from this group, send email to ode-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jetro Lauha]

I'm not entirely sure, but I think it's at least the v0.9 I'm using..
perhaps
with some updates from svn trunk at some point.

However, the problems I described aren't tied to some specific release
or so, but more like typical for any simulation (not even just ODE).


On Jul 24, 3:50 pm, Riemer van der Zee <riemervd...@...> wrote:
> Hello,
>
> First of all, could you please tell us which version you are using of
> ODE? maybe switching to a newer version would help solving a few
> problems.
> Also I have noticed you said something of having a 'max contact amount
> 10', maybe increasing this value would help.
>
> Riemer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@...
To unsubscribe from this group, send email to ode-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Daniel K. O.-2]

Jetro Lauha escreveu:
> Typically this happens so that one or more of the dynamic objects get
> stuck
> between two geoms and have hard time "getting out", e.g. between two
> stairs
> in the Stair Dismount (the stair geoms didn't have any overlap - do
> you think
> that is a good idea?).

Is it like the situation described in the FAQ, Q 6.13 "My rolling bodies
(e.g. wheels) sometimes get stuck between geoms"? dContactApprox1 might
help.


> Or alternatively if there's a thin geom, some
> of the
> jointed bodies end up being on other side of the thin object and rest
> on the
> opposite side, so that joints try to keep the bodies together but
> collision
> detection keeps forcing them back to the opposite sides. This happens
> e.g.
> with the window shield in Truck Dismount.

Sounds like a tunneling problem. There are ways to minimize it like:

* Use smaller timesteps, reduce the maximum velocity of bodies.

* Use specialized collision detection code; collide the ragdoll against
a plane (in ODE planes are infinitely thick) for the windshield if you
"know" it's still inside the truck.

* Use continuous collision detection, which ODE doesn't provide (yet).
Check out Bullet.


> I'm currently using step size of 0.04 (trying to simulate 60 frames
> per second).

You could try even smaller timesteps, and run more steps per rendered
frame. For example, the demo_basket uses step size = 0.001, so your step
size might be too high.



--
Daniel K. O.
"The only way to succeed is to build success yourself"

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@...
To unsubscribe from this group, send email to ode-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jetro Lauha]

> Is it like the situation described in the FAQ, Q 6.13 "My rolling bodies
> (e.g. wheels) sometimes get stuck between geoms"? dContactApprox1 might
> help.

Not really, since in this case the bodies get stuck _inside_ a
collider
(I'm speaking especially of the last case I described of which I
posted
screenshots as well).

> Sounds like a tunneling problem. There are ways to minimize it like:
> * Use smaller timesteps, reduce the maximum velocity of bodies.
> * Use specialized collision detection code; collide the ragdoll against
> a plane (in ODE planes are infinitely thick) for the windshield if you
> "know" it's still inside the truck.
> * Use continuous collision detection, which ODE doesn't provide (yet).
> Check out Bullet.
..
> You could try even smaller timesteps, and run more steps per rendered
> frame. For example, the demo_basket uses step size = 0.001, so your step
> size might be too high.

Sure reducing step size "always" helps... :) As would CCD.
Unfortunately
those just mean considerably higher CPU requirements for real-time
sim,
raising the minimum spec machine, which is why I don't see it really
as
an option to use so small time-step. We'd like to run some additional
dynamic stuff along with the ragdoll, and even now it starts to get
slow
when throwing in a nice bunch of boxes or so.

Hacking the collider to be a plane is a nice idea though, haven't
tried that
yet. Thanks for your tips. :)


Jetro
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-users@...
To unsubscribe from this group, send email to ode-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en
-~----------~----~----~----~------~----~------~--~---