Add support for double precision floats

[m4nu3lf]

Since I need more number precision for my game, I tried to recompile the engine with REAL_T_IS_DOUBLE, however it doesn't work.

It seems like float have been used here and there in place of the abstract real_t type.
In the other hand b2ConvexDecomp::float32 is defined as real_t... and real_t can be a double precision float (float64). So it is quite confusing.

[reduz]

support for doubles was never completed, maybe one day..

On Mon, Apr 14, 2014 at 7:23 AM, m4nu3lf notifications@github.com wrote:

Since I need more number precision for my game, I tried to recompile the
engine with REAL_T_IS_DOUBLE, however it doesn't work.

It seems like float have been used here and there in place of the abstract
real_t type.
In the other hand b2ConvexDecomp::float32 is defined as real_t... and
real_t can be a double precision float (float64). So it is quite confusing.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/288
.

[akien-mga]

See also the proposed implementation in #334.

[akien-mga]

That's planned for 3.0 AFAIK.

[Marqin]

real_t seems to be just typedef for float so it can be 64-bit, depending on your platform/compiler.

C++ standard:

There are three floating point types: float, double, and long double. The type double provides at least
as much precision as float, and the type long double provides at least as much precision as double. The
set of values of the type float is a subset of the set of values of the type double; the set of values of the type
double is a subset of the set of values of the type long double. The value representation of floating-point
types is implementation-defined. [ Note: This International Standard imposes no requirements on the accuracy
of floating-point operations; see also 18.3.2. — end note ] Integral and floating types are collectively called
arithmetic types. Specializations of the standard library template std::numeric_limits (18.3) shall specify
the maximum and minimum values of each arithmetic type for an implementation.

So if you want to be sure, you have to check:

std::assert( sizeof(float) == 4 && std::numeric_limits<float>::is_iec559 );

( this will work with C++98 ).

[bojidar-bg]

Wasn't this fixed in 3.0 already?

[reduz]

it's not done yet, needs some more work and testing

…

On Sat, Mar 11, 2017 at 8:23 AM, Bojidar Marinov ***@***.***> wrote: Wasn't this fixed in 3.0 already? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#288 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z23LdNaXNGndPbxAPEWlTK6Q-MAQrks5rkoQbgaJpZM4ByNZg> .

[reduz]

Not gonna be done for 3.0

[fire]

What is the current status? What is working? What is missing? How much work is required to get this in?

[reduz]

I'm not completely sure what needs to be done for this feature (and adding a proper compilation flag for this) happens, but comes to mind:

1. There is some support for using doubles in binary serialization, but it's probably not complete. files such as resouce_format_binary.cpp and marshalls.cpp would need to be checked and made sure that doubles are written (and read) in a binary compatible way.
2. Variant needs to be tested for double support, as this would mean Vector2, Vector3, etc. are doubles so Variant is bigger
3. Some third party libraries might need to be modified (I think probably not, but i'm not sure, If Bullet is added, i think it can also use btScalar as double)
4. Need to check that everything works in VisualServer when using doubles
5. As it is not possible to use doubles in GLSL, world coordinates in matrices will need to be somehow wrapped or clamped to avoid numerical precision errors. This is most likely the last step that needs to be done once everything works

If you or anyone else would like to do this, feel welcome :) It's quite some work but it would be awesome to get it to work

[Marqin]

As it is not possible to use doubles in GLSL

Bzzzzt wrong @reduz. I've used them in my project few years ago.

You can check on OpenGL wiki. But I remember I had to use some extension for it on my card:

#extension GL_ARB_gpu_shader_fp64 : require

[fire]

https://github.com/Hopetech/libSoftFloat

Emulated support for fp64 library.

[fire]

I'll add a compilation flag called float and it'll have float=32 and float=64 as arguments. Hopefully we won't have to implement float=128 ;)

[Hopetech]

Hello godot dev,

I replayed to question about using libSoftFloat in your game engine: Hopetech/libSoftFloat#1
TL;DR: Yes, you can use it. But the amount of work is huge and the result will be slow.

Let me know if you have any questions.

[aaronfranke]

I am also interested in double-precision floats in Godot. Please implement this if you can.

[NathanWarden]

If this doesn't get completed, as a workaround you'll be able to keep track of double precision floats in C# (and I believe in C++ also) for scripting. For instance, if it's for something like avoiding jittery movement for large scale (planetary sized) games then keeping track of x,y,z as doubles then converting them to floats when setting the position usually does a good job. It's not ideal, but it's an option.

[aaronfranke]

@fire 128-bit? Well, that depends on what kind of games you expect Godot to power.

• 32-bit floats have 6-7 decimal digits of accuracy, so if you aim for millimeter-precision, the play area is limited to just a few kilometers. This is incredibly restrictive, and means any large scale game is forced to use relative positioning, which is a pain especially for multiplayer games.

• 64-bit floats have 15-16 decimal digits of accuracy, so if you aim for millimeter-precision, the play area is limited to a few billion kilometers, or a few terameters. This is accurate enough to have non-relative positioning on planets, but not beyond solar systems (Neptune is about 5 Tm orbital radius). For universe scale games, it could be useful to have 128-bit floats.

• 128-bit floats have 33 decimal digits of accuracy, so if you aim for micrometer-precision, the play area is limited to a few septillion kilometers, or thousands of yottameters. This is almost exactly the estimated diameter of the observable universe. In other words, 256-bit floats are never needed :) But also, very few pieces of harwdare and programming languages support 128-bit floats.

[realkotob]

Since the float in GDScript is now 64bit on the master branch, is this resolved?

[aaronfranke]

@asheraryam No, it is not resolved. float in GDScript has been 64-bit double-precision for years, the issue is with having core types (like Vector3) and other CPU-side math done with doubles.

I have a PR here: #21922

[blaeberry]

@aaronfranke You mention CPU-side, but what about GPU-side? I'm working on shaders for my game and I'm noticing some issues with very small floating point values being rounded down to zero...

[Calinou]

@blaeberry As far as I know, using FP64 (= double precision) in shaders is ill-advised in a game engine. This is because FP64 can be very slow on consumer-grade GPUs. 64-bit floating point performance is intentionally crippled on such GPUs, to incite professionals to buy much more expensive professional-grade GPUs.

How do other engines typically handle this? I'm curious to see how they do it 🙂

[0x0177b11f]

@blaeberry As far as I know, using FP64 (= double precision) in shaders is ill-advised in a game engine. This is because FP64 can be very slow on consumer-grade GPUs. 64-bit floating point performance is intentionally crippled on such GPUs, to incite professionals to buy much more expensive professional-grade GPUs.

How do other engines typically handle this? I'm curious to see how they do it 🙂

There is a trick to bypass this problem.Although we use FP64, we can convert the coordinate system from world space to the camera-relative coordinate system when calculating animation and final rendering, so that we will not use expensive FP64 in shaders

[nxrighthere]

I've started a similar discussion on Unity forums. You might find some valuable information there.

[aaronfranke]

As part of an effort to move all feature proposals to the godot-proposals repo, I wrote this proposal which directly supersedes this issue. It significantly summarizes and elaborates on the discussion about double support in Godot. As such, this issue will now be closed.

[3top1a]

Will 4.0 support 128-bit floats/doubles?

[Calinou]

@3top1a There are no plans to add 128-bit (or arbitrary precision) integers or floats to GDScript, but this could be done by a third-party module.

[fire]

Godot does have a fixed point 128bit doubles implementation, but no plans to add to gdscript.

Edited:
https://github.com/godotengine/godot/blob/988dd09047aab9f33b172cfb140d4081885c7083/thirdparty/misc/r128.h

[3top1a]

@fire well yes, but that's a 128-bit integer.
What about a 128-bit float?

(in the core since I'm coding in c++ modules now)

[fire]

I was imprecise, its 64.64 float. It is not a 128 bit integer.

[akien-mga]

For the record (as this is referenced in various issues), this has been implemented in 4.0 (see godotengine/godot-proposals#892 for details).