[ODE] Accuracy / FPU stuff

[Fig TaTam]

As long as we can still use "double" precision for ODE, we have no problems 
with OPCODE.

But if not, that's like saying "OPCODE doesn't need double precision so ODE 
shouldn't use it either." I hope that's not the case.


>From: "Pierre Terdiman" <p.terdiman@wanadoo.fr>
>To: <ode@q12.org>
>Subject: [ODE] Accuracy / FPU stuff
>Date: Tue, 8 Jul 2003 12:50:35 -0700
>
> >    Is there some good reason for this, or is this just that OPCODE uses
> > single internally and doesn't have a switch (i.e., will OPCODE break if
> > I make it "use double and memory use be damned"?)
>
>Let's make it clear....
>
>There are two different issues here :
>
>1) Using "float" instead of "double", mainly OPCODE vs ODE :
>
>OPCODE really doesn't need double precision :
>
>- if you're using quantized trees, nodes don't even contain a single
>floating-point value. So you won't "damn the memory use" by using "double".
>
>- if you're using non-quantized trees, nodes contain floating-point values
>for bounding boxes. However those are only bounding boxes which are *not*
>supposed to be accurate in the first place. Using "double" here will indeed
>increase memory usage, *and be totally, definitely useless*.
>
>- the actual client mesh is *not* stored in OPCODE's structures, I'm only
>using indices to get those back. So I don't really care how you store your
>meshes (floats or doubles) as far as computations are concerned. The only
>thing that needs fixing if your meshes are stored in "double", is the
>MeshInterface, because it expects float pointers in return. This is 
>probably
>where all the problems are coming from : if you cast your double-precision
>points to float in OPCODE's callbacks for example, it obviously won't work,
>and collisions won't be detected indeed.
>
>Using callbacks, a possible fix would be to convert each requested triangle
>to floats on-the-fly, and return pointers to the converted triangle to
>OPCODE. As long as you don't use multiple threads doing simultaneous
>collision queries, it should work fine.
>
>Now I seriously doubt you need double-precision meshes. In particular,
>they're probably single-precision to begin with, out of your favorite
>modeling package (3DSMAX, etc). So you should keep them single-precision,
>use OPCODE's pointers (possibly with a stride), and convert the floats to
>doubles for ODE's computations, if needed. But even this is probably 
>dubious
>: doubles are useful in big and intensive matrix computations, but that's
>about it. My own rigid body code uses plain floats all the way without
>troubles, for example.
>
>I'm also using D3D, which brings up the second issue :
>
>2) the *internal* FPU accuracy and D3D's D3DCREATE_FPU_PRESERVE
>
>The nature of your floating-point values ("float" or "double") is only half
>the story. Using "float" for example, you still have multiple choices
>regarding the *internal* FPU precision. This is controlled by the FPU
>control word, and can't be accessed / modified through C.
>
>The D3D flag only changes this internal accuracy as far as I know. They
>don't use "double" inside, that would be ridiculous, especially since :
>
>- you only store 32-bits floats in your vertex buffer anyway
>- the hardware certainly doesn't have two code paths for two different
>pipelines, it would be twice as much gates for nothing !
>
>I believe this flag only changes only very few things, and mainly related 
>to
>the software rendering mode. There have been a number of threads about this
>on the DXML in the past.
>
>Now I've seen cases where *internal* FPU precision was modified by D3D init
>*even* with that flag on. It might also change the FPU rounding mode, which
>is a problem when you compile with /QIfist on VC++ 6 (for fast float-to-int
>conversions).
>
>On top of this, D3D *isn't* the only thing changing the FPU settings
>silently. A classical other example is LoadLibrary.
>
>In summary, assuming the FPU is correctly setup is a recipe for disaster.
>(Never assume anything, as always)
>
>What I do then is very simple :
>- initialize D3D the normal way, without the FPU flag
>- explicitely reset the FPU control word to what I want, each frame (it's
>very cheap, no problem)
>
>For what it's worth, my rigid body simulation uses "floats" all the way 
>with
>the smallest internal accuracy, and renders the scene with D3D or GL just
>fine.
>
>Pierre
>
>
>
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963