Building Double-precision Torque
by Valador, Inc. · in Torque Game Engine · 01/13/2009 (7:07 am) · 4 replies
Hi there.
I'm trying to build 64-bit precision TGEA 1.8. In other words, I'm trying to get all vectors, matrices, quaternions, scalars, etc. (even mesh implementations) to be effectively implemented in terms of F64 instead of F32. I've been looking for a preprocessor switch, macro, IDE setting, etc. that would enable me to easily do this.
Since I'm unable to locate such an option in documentation or in the forums, I'm trying this approach:
Replace "typedef float F32;" with "typedef double F32;" wherever it occurs in the engine, and eliminating all the resulting implementation conflicts (one in terms of F32 and the other in terms of F64, which are both double) through manipulation of preprocessor ifdefs and symbols I define, to cull out duplicate/conflicting implementations. With my BUILD_64_BIT_PRECISION switch defined, I get double-precision vectors, quaternions, matrices, etc., and without it, I get the standard single-precision TGEA 1.8 out of the box. That's one possible approach.
Another possible approach:
Try to get each math class: vectors, matrices, quaternions, etc., one class/implementation at a time, to build/link/run correctly (replacing F32 with F64).
I recognize that, despite the proposed hack idea above, it will be alot of work (perhaps even a daunting task) to get it to build/link/run correctly. If there is a better way to do this (to achieve 64-bit precision), please let me know. I'm open to any/all ideas/criticisms.
Thanks,
Franklin
I'm trying to build 64-bit precision TGEA 1.8. In other words, I'm trying to get all vectors, matrices, quaternions, scalars, etc. (even mesh implementations) to be effectively implemented in terms of F64 instead of F32. I've been looking for a preprocessor switch, macro, IDE setting, etc. that would enable me to easily do this.
Since I'm unable to locate such an option in documentation or in the forums, I'm trying this approach:
Replace "typedef float F32;" with "typedef double F32;" wherever it occurs in the engine, and eliminating all the resulting implementation conflicts (one in terms of F32 and the other in terms of F64, which are both double) through manipulation of preprocessor ifdefs and symbols I define, to cull out duplicate/conflicting implementations. With my BUILD_64_BIT_PRECISION switch defined, I get double-precision vectors, quaternions, matrices, etc., and without it, I get the standard single-precision TGEA 1.8 out of the box. That's one possible approach.
Another possible approach:
Try to get each math class: vectors, matrices, quaternions, etc., one class/implementation at a time, to build/link/run correctly (replacing F32 with F64).
I recognize that, despite the proposed hack idea above, it will be alot of work (perhaps even a daunting task) to get it to build/link/run correctly. If there is a better way to do this (to achieve 64-bit precision), please let me know. I'm open to any/all ideas/criticisms.
Thanks,
Franklin
#2
I was determined to do this a while back, but ended up coming up with a solution which was, for me, a lot simpler. This won't help you if you have more elaborate needs for 64-bit precision, but if you're just looking to beat the limits to environment size I'm going to recommend you consider some kind of "page" system (a multiplier to the actual position value).
I just wrote up a pretty complicated explanation of my implementation of this for multi-player space sims, but decided it was excessive for this post, especially if position accuracy limits aren't your motivation.
01/15/2009 (5:59 pm)
Ben's solution is very doable, and honestly probably a lot less work than trying to convert the entire engine to 64-bit floating point. That also seems like it could be overkill; I mean, do you really need 64-bit precision for audio volume, for example?I was determined to do this a while back, but ended up coming up with a solution which was, for me, a lot simpler. This won't help you if you have more elaborate needs for 64-bit precision, but if you're just looking to beat the limits to environment size I'm going to recommend you consider some kind of "page" system (a multiplier to the actual position value).
I just wrote up a pretty complicated explanation of my implementation of this for multi-player space sims, but decided it was excessive for this post, especially if position accuracy limits aren't your motivation.
#3
01/15/2009 (6:38 pm)
I am sorry, I am still learning C++. What would the difference be? Other than using more RAM.
#4
The OP didn't explicitly say this was what he was thinking of, but it's the usual reason. One common scenario is a space simulation, where ~20,000 units of precise physics isn't nearly enough to handle the distances you'll be using, even if you're not going for true realism. Extremely high speeds and forces in any environment can also result in failure if you're limited to single-precision floats.
01/15/2009 (6:57 pm)
The reason for interest in 64-bit precision comes from the inherent precision limits with floats in a 3D environment. If you move an object out to very high coordinates, as in the 100,000+ range, you'll see that it no longer moves smoothly because the actual position resolution is so limited. The objects jump around as the positions and physics calculations themselves get truncated. The OP didn't explicitly say this was what he was thinking of, but it's the usual reason. One common scenario is a space simulation, where ~20,000 units of precise physics isn't nearly enough to handle the distances you'll be using, even if you're not going for true realism. Extremely high speeds and forces in any environment can also result in failure if you're limited to single-precision floats.
Associate Kyle Carter
In other words you have to distinguish between "F32 as a default float" vs. "F32 because we need a 4 byte float."
Not sure there is a way you can do it without hand-modifying everything.
If you just need to change position related code to be double-based, the amount of work is reasonable - probably a few days to make a QuatF64, MatrixF64, etc. and then update the relevant parts of the code to use them. Mostly copy/paste search/replace stuff.