Will 'float' vars be replaced by 'double' vars in later releases of Godot API?

Question

I found that float in GDScript is equivalent to double in C++ as a double-precision floating type.
Documentation

However, in Godot API of C#, all appearances of float in GDScript are corresponding with float type in C# which represents a single-precision floating number. And all float parameters in GDScript actually requires single-precision in Godot API, which seems to be a problem that double values should have been supported to fill the parameter but actually not.

e.g.
In GDScript, function sin(x:float) -> float accepts x as a double-precision input, and returns a double-precision as well.
while in Godot API, float Godot.Mathf.Sin(float x) accepts single-precision instead and so does the return value.
And we knew that there's no Godot.Math or Godot.Mathd with System.Math not working.
Certainly we can cast a double to float at a loss of precision, but that doesn't make sense.

In the recent 4.0 mono beta release, I found that _delta parameter of _Process callback is defined as double.

public override void _Process(double delta)
{
	//...
}

---

I just wonder if all float parameters in Godot API will be replaced as doubles in later release of Godot, or at least if it is put on schedule present.

Coastwise

Answer 1

I just wonder if all float parameters in Godot API will be replaced as doubles in later release of Godot, or at least if it is put on schedule present.

Double precision build starting with godot 4(IIRC) is a build option for custom builds. Pre-built downloadable packages are a possibility but last I heard I think it was still TBD.

Ern

Answer 2

Good question.

I would argue the other way round, doubles in GDScript maybe nice to have for calculations that remain in a script, but make little sense outside of that as the precision is usually not needed in a game, and vanishes on its way to the graphics card anyway, if not handled. Also excessive conversions between GDScipt and the API cost time.

Anemometry

Answer 3

I see what you mean. Indeed, such high precisions may not be necessary to a game. I just feel ... well should I say, it might be a bit unfair to Godot developers working with .NET.

And _delta is defined as double in the recent release. So I think it might be a trend in my opinion. :

Coastwise

Answer 4

... it might be a bit unfair ...

Well, then I don't understand the problem. If you need double precision in a C# script/program than use double, and float if not. Actually, use the data types that fits best your problem.

The Godot engine has power over defining data types in the script language GDScript, but C# is up to MS.

Anemometry

Answer 5

Yes, there are some cases where this can be an issue. I can't recall what I was doing, but I think I was trying to pack data into a texture for a shader. Color (as well as most floating-point types) in GDScript is a tuple of doubles. But the shader only accepts floats as a uniform. I think there is a way to get higher precision, but then you are doing two conversions, basically losing anything you would have gained. Seems they should just use double everywhere if it is indeed 64-bit under the hood.

Gash

Answer 6

In C++/OpenGL, I do use double in the application and single precision in the GLSL shader. Vertex data is converted automatically with the right parameters, but uniform buffers are populated on the CPU anyway and need conversion there.

To achieve double precision in the vertex stage of a shader, you either bite the bullet and accept an 8- or 16-times performance impact on most consumer grade graphics cards, or you split a double into two floats (upper and lower part of a large number) and perform operations on these two parts separately. There's a Fortran library (DSFUN90) that can do this, there are C++/C implementations as well, but in the shader you actually have to write the functions for conversions and operations yourself. There's a huge performance hit, but it is not 16 times.

For double precision in C#, just use type double (or whatever it is called).

For doubles all over the Godot API, I think that is more complicated. Since Godot ships a form of runtime instead of compiling a project together with its engine functionality, I can imagine that making the use of (C++-)templates is difficult, and so all resulting conversions would have to be done manually, with a lot of possibility for errors.

Anemometry

Answer 7

Yes, in that case it makes sense (for shaders). I guess the point is that the API uses the keyword float but it is essentially a double but then at the same time it's not. Seems it would make sense to either make it a float or make it a double. Right now it is inconsistent. Meaning that values are stored internally as doubles but some functions operate on floats. It doesn't seem to make sense.

Gash

Answer 8

Seeing delta time and floats mentioned, here's a fun fact:
Using 32bit floats to store a game clock (seconds since game start), after 4 days of running the clock will be too inaccurate to handle 60Hz delta times.

Unity's Time.time and Time.deltaTime are both floats, but I've heard that internally they are doubles. It REALLY should expose that then, don't hide it. If you grab two timestamps using Time.time and compare them, the difference can't be smaller than 1/32s after running for 4 days (like a server might do).

Afterwards

Answer 9

They are doubles in GLFW (Windowing API) too, just like mouse movement and cursor position. With lower level like XCB programmer chooses the data types. Time depending physics on the CPU can/arguably should also be double in a somewhat reasonable simulation. I mean not necessarily an FPS or a platformer.

But they shouldn't be treated like static drawing data, where it can be useful to actually go down to half precision to save memory, bandwidth and speed things up. Anything with positions for drawing can't be doubles, so there will be conversions that cost time and one has to weigh against possible numeric stability and accuracy.

When cache misses are the one and only thing that slows the program down (often the case in larger simulations), than packing data as much as possible is the solution and the general use of doubles a bad idea. It all depends on the use case. Right data format and type for the job at hand.

Anemometry

Answer 10

I see, thx!

Coastwise

Answer 11

They explained how they figured it out, and it's pretty clever.

https://godotengine.org/article/emulating-double-precision-gpu-render-large-worlds

Gash

Answer 12

Ok, well, but that's nothing new.

• Users can’t do shader math in world space: User shaders will still be limited by single-precision floating point, so world space calculations will still be subject to low-precision artefacts,
• This only applies to precision issues from object positions. In other words, it won't fix your earth-sized sphere, for model vertex positions, you still need to work around single-precision floating point limitations.

This makes it practically a non-solution (or one that stops half way), as the world space positions (the huge transforms) are the real problem, and most if not all fast algorithms in the sector of large worlds depend either on dynamic content creation, on position calculations on the GPU, or on both. For this, the position attributes would have to be split as well, with double vertex buffer sizes, arithmetic and trigonometry routines for the representation, higher traffic, higher load on the CPU when splitting the numbers, etc. In short, hardly doable in a real time environment with large and dynamic data, and on old hardware.

I am not saying that there is no solution. I am thinking this over since a year, and books were written about it (for instance Cozzy/Ring 3D Engine Design for Virtual Globes). There are solutions, but they either require double precision on the GPU (there is no way around it, but Apple is a false belief anyway 🧑‍🍳 , though there must be way for Apple programs to use double precision on the GPU or accelerator), or the implementation of double precision math routines that work with split floats.

I have tinkered with such an implementation of some of the dsfun90 functionality in GLSL (link went broken), but it only supported addition and subtraction. It'll need at least multiplication/division for linear flat worlds, and that's too complicated for me. For spheres or ellipsoids one would have to implement trigonometry as well. I am not even sure if that has been done in dsfun90, but if someone posts a link the library or does an implementation in C#, C or C++ I could certainly do something more there, in a month or two.

But mind you, graphics cards do fp64 calculations since a decade or longer, it is just that it is artificially nerfed on consumer grade cards, to 1/16th or 1/32nd of fp32. This is for them not to be a competition to the high priced accelerators.

OpenGL and Vulcan both support double precision buffers, and GLSL can do the math as well. No idea about SPIR-V though which is the least common denominator of shading languages under Vulkan. But I think that if we drop the premise "must run everywhere and on old hardware" than we can do better with rendering large worlds. Though there are still some things to sort out :-/

See also:
https://prideout.net/emulating-double-precision
Cozzy/Ring's book
Various blog entries, e.g. from the Space Engine creators, the Cesium Engine, and others

Anemometry

Answer 13

Well if we just said "Apple can go to Hell" then everyone's life would be 100% easier (except, maybe, Mac users). I mean, their list of Mafia Tactics would fill an entire book. Killing Flash, deprecating OpenGL, never supporting Vulkan, poor WebGL compatibility up until like a few months ago, not allowing users to run apps downloaded from outside their store without their 30% Mafia Protection Fee, not even supporting C++, like WTH. They are horrible for the industry. But, a lot of people use their products, especially on mobile, so you can't claim cross-platform without them. I mean, I hate Apple, but I will still launch my game on macOS and/or iOS. Because I don't want to discriminate against users and become part of the problem. Maybe we can get the EU involved and force them to support Vulkan like they just forced them to put USB-C on iPhone, LOL.

Gash

Answer 14

Well, we have the explanation now why not everyone can do a renderer for actual size worlds and environments in real time.

I know too little about mobile devices to judge if the quicker ones are that far and can catch up with PCs. But seeing the recent progress on the PC side it seems to me that Moore's law hasn't been broken yet.

Which is cool.

Anemometry

Answer 15

Mobile today is pretty good. I would say getting close to PS4 levels. This is one of the newer games that looks pretty good (Shadowgun Legends), online sort of like Halo.

Gash