Some work on double-precision support

[aaronfranke]

Please see this proposal for the eventual goals this PR is a part of: godotengine/godot-proposals#892

This PR does a lot of work on double-precision support. I have previously split this PR up into smaller ones that are easier to review/merge and now those have been merged. It's small enough now that I don't think splitting this further would help much, the majority of the code that can be reviewed/merged separately has been reviewed/merged. Note that the rest of this PR changes things like arrays/vectors which are a bit more tricky so keep that in mind when reviewing.

In its current state things are mostly working except for a binding issue with integer vector multiplication/division that causes this PR to not compile. I previously had #44441 included in this PR's list of commits but now I've removed it so that this can be merged, and then the integer vector multiplication/division issue can be solved separately.

[fire]

Haven't had time to look and compile the patch, but thank you for continuing with the work. Currently looking at the driver side of this which is dependent on Opengl4 or Vulkan. Since Vulkan is in the roadmap, I'm focusing on that.

This is the dmat4 type for the position.

[reduz]

This is great! Besides ensuring that everything is using real_t, there is some significant piece of work missing which is making sure that binary serialization uses doubles instead of floats when compiling in this mode (yet keeping compat). One of the places that needs to be modified is:

https://github.com/godotengine/godot/blob/master/core/io/marshalls.cpp

As you can see I added a tiny bit of support for encoding as 64 bits like here:
https://github.com/godotengine/godot/blob/master/core/io/marshalls.cpp#L153

but needs to be:

• Expanded to handle other datatypes that become doubles (Vector2, Vector3, etc).
• Make sure when engine is compiled with real_t as 64 bits, writes 64, else 32 (save for real and int because Variant always has those as 64)
• Make sure, when reading, that this flag is always recognized, so scenes remain compatible.

Similar work needs to be done here:

https://github.com/godotengine/godot/blob/master/core/io/resource_format_binary.cpp

[fire]

Remember the code to turn on 64bit float is in: https://github.com/godotengine/godot/blob/2d3f6945ee7de9bf37139799b15e24c34b1e5a0b/platform/windows/detect.py#L207

godot/platform/windows/detect.py

## Libs
    if env["float"] == "64":
       env.Append(CCFLAGS=['/DREAL_T_IS_DOUBLE'])

Edited: I had cascading errors when turning that on.

[aaronfranke]

@fire Isn't that just for Windows? It's in the platform/windows folder.

EDIT: Done, see code here, I also made it exit if you try to compile 64-bit floats on a 32-bit CPU, even if it works it would be slow and it's not a good idea.

[fire]

You can move it out into SConstruct, but the main point you need to

    if env["float"] == "64":
       env.Append(CCFLAGS=['/DREAL_T_IS_DOUBLE'])

So that real_t is defined as double.

[AndreaCatania]

when compiled with double precision, is important that even bullet is compiled with double precision. btScalar is the type def of floating point variables inside bullet.

[aaronfranke]

@reduz Like this? efee149

[fire]

I was blocked when I realize to fully convert the code, I need to touch the float in the position shader and gles3 version of our code didn't double precision matrixes.

However, not doing still gives us more precision. I'm not sure how to calculate it, but it's better converting from double to a float on render than using a float directly.

[aaronfranke]

@fire Perhaps it would be best to worry about the rendering code after Vulkan is added.

Since GPUs work with floats, it would be best to use floats there. The most important thing is for all math (including physics etc) to be in doubles. I can move the world around the player so that the "global" positions of what need to be rendered are within the precision range of floats. Or, it would be really cool if this could be done automatically by the renderer (some kind of "camera-centric" rendering where all objects are position -= camera_position; and camera is at 0,0,0?)

[ghost]

This change will be a game-changer for Godot! No more '#50251's!

[akien-mga]

Thanks!

[ghost]

Thank you!!!!!!!!!!!!!!!