Hey there,
I wrote a small script that swaps 2 digits of all vertex positions of a mesh.
The problem: when I assign the new position to the mesh it is not the same number I assigned.
Here are some example numbers. The first number is the original x vertex position. The second number is calculate thorugh swapping 2 digits right before the decimal point. The third number is the printed vertex position after I assigned it to the mesh. The number I assigned is not the same as the one I calculated…
I dont know if this is a precision problem or the floats getting rounded by blender somehow.
for mesh in bpy.data.meshes:
for v in mesh.vertices:
print(v.co.x)
print(flipVertex(v.co.x))
v.co.x = flipVertex(v.co.x)
v.co.y = flipVertex(v.co.y)
v.co.z = flipVertex(v.co.z)
print(v.co.x)
print("")
floats in blender should be precise to about 17 digits.
What is the code for flipVertex()? My guess is that your object is transformed, so the vertex positions after assignment are taking that transformation into consideration- it’s certainly no coincidence that all of your values are off by exactly 6.697937011718
floats in blender should be precise to about 17 digits.
This is not true. Inside The C / C++ Blender, almost all floats, including coordinate values, are single precision floats, about 6 decimal digits of precision. In the Python API to Blender, the floats are indeed double precision and hence about 17 digits of precision, but as soon as it gets transmitted into Blender proper they get converted to the 6-digit single precision value that is nearest.
Okay thats what I was looking for. Is there anyway I can get more precision? This distorts my meshes and makes them unusable when I export them from Blender…
No, there is no way to get more precision without a massive effort to convert all the floats inside Blender to doubles, or build in a choice mechanism. While that idea has been raised on and off over the years, there has never been a consensus that it should be done. As well as the question of prioritization (would users prefer the developers work on other things first?), it is also unclear whether (especially without the choice mechanism, which would likely be even more work to implement) the potential loss in performance and increase in memory requirements would be regarded as a good tradeoff for most Blender users, who don’t need CAD-like precision beyond 7 decimal digits.