Default float=64 to be on (double precision emulation)

[fire]

Describe the project you are working on

V-Sekai social virtual reality.

Describe the problem or limitation you are having in your project

We would like to use emulated doubles for unified grids in an open world. Like loading the multiple parts of the world but only transferring lod'ed network entities.

We would also like Godot Engine to be more user friendly and avoid two different default extension_api jsons.

If it's possible, I would request we emulate double support by default for 4.0. Enable emulate double support by default for 4.1 might be more difficult.

Emulating doubles came up in my discussion about why don't we enable emulate doubles by default for 4.1 or 4.0.

https://github.com/godotengine/godot/pull/66178 this is really cool shit I thought Epic Games has large world coordinates. it does, but its a different way, they do it tile-based. they store a tile-offset and then position is tile coordinates * tilesize. this is an interesting thing with the dual floats. Should be enabled by default. For what I'm seeing this thing would have 0 performance hit or at least near 0. Just a small amount of extra memory for the double based positions and stuff. Especially on a newbie focused engine like Godot Engine. removing precision issues is great for indie developers yeah! I think it's an experimental feature so my understanding it's being tested at least I want to test it for one release before we enable it Sounds perfectly fair some stuff might not quite work but like Unreal Engine, this should be the default.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Enable float=double by default.

This would avoid two different json extension apis. https://github.com/tefusion/godot-subdiv/issues/21 (Crash with float=64)

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Set float=64 by default in scons and build this for releases.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Emulating double support is not a small script change. It is massively invasive and changes function signatures.

Is there a reason why this should be core and not an add-on in the asset library?

float=64 is a core feature.

[aaronfranke]

I would appreciate this being the default, but I don't know if this is the right approach for the engine as a whole, yet it's totally possible that it could be. It's what Unreal 5 did (well, they made double-precision the only option). If the performance penalty is low, it might be worth it to default to this for official builds and then if someone is making a high-end game in a small space then they can choose to use single-precision instead. Also, even if we switch back later for release, it might be beneficial to get a large amount of users testing double-precision in beta.

[Calinou]

It's what Unreal 5 did (well, they made double-precision the only option).

On the other hand, Unreal Engine 5 is not known for its support for low-end/mobile hardware and web platforms :slightly_smiling_face:

There are still a lot of people using Godot to target low-end mobile, web platforms, and sometimes both at the same time. We should avoid making people pay for performance features they'll never see the benefit of.

Feel free to create some benchmarks with physics and basic rendering[^1], but also make sure to benchmark it on mobile hardware and web platforms, not just desktop hardware.

What we can do however is distribute official builds with double-precision enabled. These would not be the recommended option for most projects, but this would allow you to use double-precision physics without recompiling anything.

[^1]: The rendering should not be a bottleneck in the project; it should only be used to check the accuracy of the results. Using the Forward Mobile backend, unshaded rendering with the viewport stretch mode and a low base resolution like 320×200 is a good way to achieve this.

[mhilbrunner]

PR review meeting: basically Calinou's comment, this would likely negatively impact more games than it would help due to physics, performance etc.

[fire]

PR review meeting:

• Needs performance numbers
• Build an official build with float=64

[fire]

What we can do however is distribute official builds with double-precision enabled. These would not be the recommended option for most projects, but this would allow you to use double-precision physics without recompiling anything.

This would be a good alternative to fix this enhancement and it will surface the extension bugs.

[Calandiel]

PR review meeting: basically Calinou's comment, this would likely negatively impact more games than it would help due to physics, performance etc.

As Calinou mentioned, distributing official 64 bit builds would be a good compromise, no? This really is the kind of feature that you either absolutely need or is completely useless (potentially even harmful). Imho, the fact that there are no official builds for double precision floats sends mixed signals about them. I know there's risk of combinatorial explosion with including every possible build configuration, but at least right now, Godot doesn't seem to be struggling with that.

[aaronfranke]

@Calandiel On the topic of combinatorial explosions, note that there isn't much of a point of producing 32-bit builds with double support. If you are targeting very old 32-bit systems you probably don't want to use doubles. Conversely, if you are using doubles you probably don't care about targeting very old 32-bit systems (note: there is one exception, WebAssembly, which is currently 32-bit only). So it would increase the amount of builds by 1.5x to have 32-bit arch & floats, 64-bit arch & floats, and 64-bit arch & doubles.

[Calinou]

So it would increase the amount of builds by 1.5x to have 32-bit arch & floats, 64-bit arch & floats, and 64-bit arch & doubles.

Note that doing so will require modifying the editor's export dialog to support situations where not all architectures have a matching binary. I assume double-precision export templates use their own folder already (within the templates/ folder of the editor data folder), so there would only be x86_64 binaries present.

(This may have been done already, I haven't checked this for a while.)