Blender's vertex coordinates accuracy

Hi there,

I’m X-Plane (flight simulator) add-on developer and I’m facing a problem that I would like to present to the community, so maybe someone has an answer.

I’m using blender (latest) with respective import/export script to X-Plane’s own .obj format file (proprietary format - different from wavefront).

Let me describe you a bit my workflow and then the problem, you might find somewhere what it cause it. Note, doing the same with sketchup… I get no problem!

What I’m trying to do is to edit the mesh (the ground) of an airport, to add some missing features, like basins, underpasses, etc. There is a utility that you take the part you want to edit. This utility converts this part to an X-Plane .obj file. Next step is to import it in blender. Here is a problem. Since the newer script have omitted the import function, I have to use the older combination of blender/script (blender 2.49b).

So, I’m importing it into blender 2.49b, saving it and open it with the latest blender to be edited. I’m exporting it from the latest blender back to X-Plane .obj file, and using the utility I’ve mentioned above, I’m injecting the edited part back to airport mesh (ground).

The problem: I’m getting small gaps around the edited part. That’s why the vertices on the perimeter of the edited part do not align correctly with the rest vertices of the mesh. Let me give you an example.

Here is what a vertex coordinates should look like (it’s actual geographical coordinates, longitude/altitude/latitude):
VT -8792170.6912 202.4374 -4197249.3706

Here is what is exported from blender:
VT -8794056.00000000 201.81651306 -4197771.50000000.

As you see the exported vertex has its coordinates rounded to the closest 0.0 or 0.5. This kind of rounding is happening to all vertices in the exported file.

Now, the questions: Is this a blender’s design limitation? I mean that’s the kind of accuracy blender is providing? Probably a Python limitation? The use of the older blender (2.49b - 32bit)? Or this can be happened due to export script? (Here is the export script in github:

Thanks you in advance for your answers!

Best Regards

Ilias Tselios

Blender stores coordinates as 32bit float I believe, this leads to rounding errors that get bigger the farther from origin you go. Obj writes coordinates in text format and should be dumb, so probably the issue is different number storage in X-Plane vs. Blender. It might use integer numbers which keep absolute precision the same but limit the bounds of maximum values. In Blender coords get rounded and this produces the gaps you see.

I might be wrong, but isn’t there also a “the more digits on the left of the decimal point = the less digits available for the right of the decimal point” thing going on?

Which would explain why the “201.x” value keeps most of its decimal digits, while the"8794056.x" (BTW, that’s almost 9 million OBJ units way from the scene center, right?!) and the “4197771.x” are rounded.

In blender units 1 is considered to be a meter and your largest number is 8792170, which is larger than the radius of the earth in meters. I’m not sure why you would expect blender to handle that big of a number accurately but I would suggest scaling down your object by a couple of factors if possible.

This is basically how floating point numbers work. You have the base and the exponent and the precision of base is the same whether the magnitude is 0.00001 or 100000.0. The bigger the exponent the bigger the absolute rounding error because bigger exponent “amplifies” the base precision errors.

These numbers represent actual world coordinates. By world I mean… earth! The origin is at the center of the world, and the airport I’m editing is at Chicago. So 9 million units (or meters if you using metric) is 9000 km…the real distance. The is the altitude (200 meters) above the mean sea level. Keeps the values probably because fits into the 32bit value storage (I think).

It is distance on the surface of the earth from 0 deg. Longitude to Chicago O’Hare airport ~9000 km.

If that’s true, which look very probable because altitude (201.xxxx) has much smaller integer part keeps the float values intact, I have to learn Sketchup!

Hello. I know this thread is old but I am running in 2021 with the exact same problem. I can confirm this is happening as you go further away from the origin, precision is lost.

This is something that definitively needs to be fix in Blender. Other DCC like softimage don’t do this. This is really important when it comes to precisions in rendering inside games. Otherewise gaps are shown.