Does Torque 3D support duoble precision?

There are no stupid questions, just stupid answers.
6 posts Page 1 of 1
Gnollrunner
Posts: 3
Joined: Fri Dec 28, 2018 9:30 pm
by Gnollrunner » Fri Dec 28, 2018 9:35 pm
So apparently I fist posted this in the wrong forum so let's try again .........

I'm currently working on a planetary voxel engine (not like Minecraft but one that generates smooth terrain) . I've got it to the point where I it can generate planets at run-time via fractals (or other functions), it supports LOD with chunking, generates normals and it seems to have good performance. Currently I only have cursory wire frame graphics using Direct X 11. I would like to see if I can get it working with a game engine but I find most of them don't support double precision. To be more specific, I need it on the CPU side. I don't need or want it on the GPU. In addition I would also like to be able to use my own physics since the my engine currently drops everything directly into an octree so it kind of makes sense for me to do it. I'm wondering if Torque 3D can handle this or am I stuck with Direct X. Thanks in advance.
Happenstance
Posts: 88
Joined: Sat Apr 11, 2015 9:08 pm
by Happenstance » Sat Dec 29, 2018 3:14 am
Torque has support 64-bit datatypes (search for things like F64, Point3D, etc. in the code) but only certain parts of the engine make use of them by default. All object positions and rotations are stored and rendered using single precision floats. It wouldn't be impossible to convert these but be prepared for some pain if you go down that road.
Gnollrunner
Posts: 3
Joined: Fri Dec 28, 2018 9:30 pm
by Gnollrunner » Sat Dec 29, 2018 11:58 am
OK well thanks for the info. I'll search around a bit more but I'm a pretty competent programmer so if I can't find anything else I might consider it.
JeffR
Steering Committee
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sat Dec 29, 2018 9:07 pm
Honestly, the most common way to get around floating point precision issues with large open world/open universe simulations is to just recenter around the camera as the origin point.

This way, as the camera moves zone to zone, it recenters as origin, and just has everything via an offset to keep the numbers more reasonable. I saw one planetary simulation engine do this via recentering on the nearest celestial body as you moved around.

Any particular reason you have to roll with double precision? As @
User avatar
Happenstance
said, the double precision capability is there via 64bit types, but nothing's really written around that for positional tracking purposes.
Gnollrunner
Posts: 3
Joined: Fri Dec 28, 2018 9:30 pm
by Gnollrunner » Sun Dec 30, 2018 7:16 am
That's what I do for the GPU and it's relatively easy, but on the CPU ..... well, I'm not saying it's impossible but It will certainly make things a royal pain in the ass for collision and just the fact I no longer have a uniform coordinate system. It's possible the extra stuff you would need to support it, would outweigh any performance gains you got from using single precision. I really don't see why I should suffer with this. I think it would be easier to just use Direct X or port an existing engine. Also as far as I know most people doing this kind of stuff are using double and custom engines so that tells me that it's probably the way I should go.
JeffR
Steering Committee
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Dec 30, 2018 6:48 pm
Yeah, I get what you mean about the uniform coordinate system.

Well, if you did want to roll with the double precision positioning, the very first place you'll want to look at is SceneObject's transform matricies, like mObjToWorld and mWorldToObj and whatnot. They double-duty converting between local and world space, but mObjToWorld also is your general Transform.

Those are all MatrixF, so you could either make a MatrixD class that uses doubles internally instead of floats and shift those transform matricies to that, or maybe just give a shot at making MatrixF use doubles as a whole. It'd definitely use more memory, but that may be a quick-and-lazy shortcut to at minimum testing the idea out.

There'd be some other aspects that likely need dealing with, but that'd absolutely be your starting point with getting the positioning to be handled with doubles.

This sort of thing has come up before in requests, so if you may some headway or find some useful tidbits relating to getting it to work I know other people would be interested in progress on it.
6 posts Page 1 of 1

Who is online

Users browsing this forum: No registered users and 0 guests