[ODE] Inconsistent joints

[Roland Plüss]

In fact there is a rather simple way to deal with changing depths
without collision detection. You only need to calculate two additional
values which I call "extends". If b is the contact point on the geometry
( closest point on geometry to collision point ) then e ( extend ) is
the projection of ( b - p ) onto the normal ( hence e = ( b - p ) * n )
). Those values can be considered constant over a time step. Then we
need only the current distance between the two object centers in respect
to the normal hence d = ( p2 - p1 ) * n. Now the depth is simply depth =
d - e1 - e2. The result is then dynamic with the position and still more
or less accurate.

In the case though of not having sub-steps that's not really a gain
there. Hence I need to figure out a way to use the contact joint then to
simulate what I need. But now I have a better insight so I should figure
out some way to fake this.

Jon Watte (ODE) wrote:
>
>
> Roland Plüss wrote:
>> With nT I tried to reference the 'contact normal' btw. Judging from the
>> multi-stepper I thought the joint constraints are checked more than once
>> for one simulation step ( dWorldQuickStep ). So the constraint force is
>> calculated only once per simulation step and not per interval?
>>   
>
> Ah, sub-steps. The problem with contact joints is that they depend on
> arbitrarily complex topology, so to really calculate a new depth, you
> would have to re-run collision between the geoms, which is usually not
> a good idea from a performance point of view.
>
> You could re-derive the points of the bodies that interact, and
> re-calculate the distance for each sub-step, if you want. That would
> probably work "OK" but wouldn't be any more "correct" than assuming
> the same depth each sub-step; you just don't have more information.
>
> The contact joint was formulated when dWorldStep() was the only
> solver, and there were no incremental methods.
>
> However, the incremental solvers don't necessarily divide time in X
> steps, and just solve each of those steps discretely. Instead, the
> incremental solvers solve the matrix that comes out of the joints
> using an incremental (converging) method, rather than doing the O(N^3)
> matrix solution. This does not mean that physics steps are subdivided,
> just that the matrix solution is iterative.
>
> Caveat: I haven't been on the inside of either of the solvers for a
> long time, so it may be that one of them does time sub-steps, and the
> other one doesn't.
>
> Cheers,
>
>          / h+
>
-- 

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.dnsalias.net/ )
- Game Engine: Drag(en)gine (
http://epsylon.rptd.dnsalias.net/dragengine.php )
- Normal Map Generator: DENormGen (
http://epsylon.rptd.dnsalias.net/denormgen.php )

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://q12.org/pipermail/ode/attachments/20060901/217f6bb2/signature.bin