Is there a double precision build I can download?

xyz So all large distance calculations can be done with it, and you almost never need double precision for rendering stuff on screen.

This is the article that disagrees with you:

Close to the scene origin this looks totally fine, but once we move this same scene 10,000 kilometers away something terrible happens. The Godots clump together and the character teleports from point to point. The diameter of the earth is 12,742 km for reference.

xyz Just download the required software as stated in the instructions

Tomcat It requires installing and setting up weird programs that wouldn't be needed in peacetime.

I once built ArmorPaint according to the instructions, everything seemed fine. But when I wanted to do it again, one of the required programs asked me to register. So it's not that simple.

I also remembered, there were problems when building in Win 7, it required at least Win 10. I don't remember how I solved it.

Tomcat This is the article that disagrees with you:

From that article:

By default Godot uses single-precision floating point numbers to store things like object positions. While GDScript typically allows users to do user-space calculations with double precision, those calculations get truncated as soon as they are stored in Godot internal objects (like Vector3’s).

Then for data requiring double precision, don't use Vector3, Node3D, etc. Use only the primitive data types like float and int, and create custom classes using only those types. For some objects, you may need two copies: a double precision copy for real world calculations, and a single precision copy (using Vector3's) for displaying.

I haven't thought this through, and there may be obstacles, such as using the physics engine without using Godot's physics objects.

It will take effort, but so does making a custom build from source code. And with a custom build, you'll need to rebuild every time a new version is released, if you want to keep up with that.

kuligs2 what is even double precision? like x.xx?

I gave a link to the article above.

This is the range where individual integer values can be represented in a floating-point number:

• Single-precision float range (represent all integers): Between -16,777,216 and 16,777,216
• Double-precision float range (represent all integers): Between -9 quadrillon and 9 quadrillon

It is needed for astronomical calculations

kuligs2 like you want something with 100 zeros you just write it like maybe 1e100 then do some conversion maths from string/obj to some number and or something

That's possible, but it would make the math calculations extremely slow. And you wouldn't be able to use Godot's built-in features like CharacterBody3D, collisions and the physics engine.

Godot's primitive float variables and floating point operations are already double precision. The problem is that when using built-in objects such as CharacterBody3D in a standard Godot build, the position, velocity and other properties get truncated to single precision. So you would have to avoid using those objects, and do your own physics calculations.

Maybe the ideal solution is a double precision physics engine plugin.

I wonder how Unity and Unreal handle this.

For those interested the discussion about releasing an official build with double precision can be found here:
https://github.com/godotengine/godot-proposals/issues/5610

For the reverseZ(better depth buffer) topic read this:
https://godotengine.org/article/introducing-reverse-z/

Tomcat This is the article that disagrees with you:

Lol. The guy moved a scene that's several units big, 10000 units from the origin. That's a very naive bruteforce way to render it. If you plan to render a galaxy this way, not even quadruple precision will help you. Some form of coordinate localization approach should always be used with large spaces, and if you do it right the single precision will always be enough while player would still have the illusion that they deal with a huge continuum.

As I always say: don't do simulations in games, do illusions of simulations. It'll spare you much headache.

Tomcat If it is possible to achieve double precision in the engine, why do need to avoid it so energetically?

@Haystack Already said why. GPUs (means rendering) operate optimally in single precision. So rendering something that has big coordinates will always "fail". You need to translate it "near" origin for rendering. With sufficiently large distances you'll have the same problem with doubles as well. So a fully generalized solution is not to increase precision, but rather to localize your space representation. How to do it specifically may wary depending on the needs of your "simulation".

The problem really is not in precision. The problem is that people do not understand actual hardware limitations. Today's relatively powerful hardware spoiled them to feel entitled to bruteforce their way out of absolutely everything.

xyz The problem really is not in precision. The problem is that people do not understand actual hardware limitations.

Well, let people learn from their experiences. It's always more useful than outside advice. Warned about possible problems and difficulties, right? And then the person will decide whether to make up his own mind or listen to the wise.

"You can be absolutely right, but what's the point if the user is crying?"

xyz

GPUs (means rendering) operate optimally in single precision.

Oh it's worse than that. Some parts of the 3d rendering pipeline hardware only work at single precision. Your vertex geometry will be transformed, clipped, culled, rasterized and depth-tested in single precision. There is no double-precision for these steps.

Modern GPUs can do double-precision in the shaders, but the fixed-function 3d pipeline is still fp32.