[ODE] Russ: [..]making the iterative solver fully stable[...]

[Geoff Carlton]

That is a very impressive paper.  I wonder how easy it would be to put 
this into ODE.  Thinking about it now, it actually seems fairly doable 
without any major overhaul needed.

It would be especially easy if the caching used local positions rather 
than edge/polys.  Although the paper does highlight the possible problem 
of aliasing, I believe that robust contact generation should never 
create duplicate contacts at a single position - I have found that 
merging close contacts is very beneficial for stability anyway.  If 
cached contact holds sufficient information, such as normal, and local 
orientation on both bodies, then aliasing would seem to be less of a 
problem. 

OTOH, more contact information (such as poly number, edge number) has 
been proposed before, so if it were implemented it would be beneficial 
for the app as well.  For instance, on my local build each contact has 
two ints representing this information, which comes in handy for hooking 
up sound/particle cues based on trimesh polygon number.  I haven't done 
this for box-box, but such a feature would be useful there as well - 
imagine a box with metal one side and wood the other.

In terms of the actual solver, I don't fully grasp how big a change it 
would be there.  As far as I can tell it, once the cached value is 
found, it seems trivial to poke that value into the appropriate place in 
the solver (or perhaps, a pointer so that it is automatically updated).  
Is this correct?

Geoff


Erin Catto wrote:

>Contact caching is used to provide the Projected Successive Over Relaxation
>(PSOR) constraint solver (aka QuickStep) with a better initial guess. As it
>stands now, ODE guesses that all contact forces are zero each step. This is
>a poor guess. 
>
>PSOR has great performance, but poor convergence. To get a good estimate of
>the exact contact forces, it is necessary to amortize the computation over
>several steps. This is precisely what is called for in dynamic simulation
>for games:
>
>- Slow moving bodies benefit from caching because they need accurate forces
>to stack in a stable manner (less jitter).
>- Fast moving bodies don't benefit from caching, but everything is moving so
>fast that accurate forces are not needed.
>
>I have written a paper on the matter:
>
>http://www.gphysics.com/files/IterativeDynamics.pdf
>
>Erin
>
>-----Original Message-----
>From: ode-bounces at q12.org [mailto:ode-bounces at q12.org] On Behalf Of
>jnilson_99 at yahoo.com
>Sent: Sunday, July 03, 2005 1:36 AM
>To: Aras Pranckevicius; ode at q12.org
>Subject: Re: [ODE] Russ: [..]making the iterative solver fully stable[...]
>
>"How is warm starting (e.g. using part of previous
>solution as an initial guess for the iterative solver)
>relate to some "solver error and crashing"?"
>
>because if you have to "warm start" you have
>encountered an error somewhere, thus the data you are
>working with are no longer valid.
>
>if that's the case then ask the question: "how did i
>get here?".....
>
>if the answer is because of some sort of failure, then
>ask "what caused the failure?"
>
>otherwise how would you ever get into the position of
>re-starting the solver?
>
>john
>
>--- Aras Pranckevicius <nearaz at gmail.com> wrote:
>
>  
>
>>>"so that the solver can be warm started."
>>>
>>>doesn't that imply recovering from some sort of
>>>      
>>>
>>error
>>    
>>
>>>at run time? why not just find the error, fix it,
>>>check in the source code and thus prevent the
>>>      
>>>
>>solver
>>    
>>
>>>from crashing?
>>>      
>>>
>>How is warm starting (e.g. using part of previous
>>solution as an
>>initial guess for the iterative solver) relate to
>>some "solver error
>>and crashing"?
>>
>>-- 
>>Aras 'NeARAZ' Pranckevicius
>>http://nesnausk.org/nearaz |
>>http://nearaz.blogspot.com
>>
>>_______________________________________________
>>ODE mailing list
>>ODE at q12.org
>>http://q12.org/mailman/listinfo/ode
>>
>>    
>>
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode
>
>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode
>
>
>  
>