# How to reduce rotation-caused coordinate/displacement problem?

I rotated an item 180 degrees with the pivot being at 0,0,0 (cursor). It was a large item (or more specifically a bunch of walls that were individual items). Then I rotated other items to 45 degrees, with the same exact problem. I noticed in almost all cases that the items rotated ended up having fractional location changes that were different from even the same items directly below them. Is that a problem? Is it normal? Is there any way to fix that?

Example:

Zoomed in to the max, we have this (item had its rotation applied in this case, because I see no reason not to):

The unrotated item looks like this, though (straight edges):

Is this an algorithm problem? I don't understand what is happening here X_X

File:

Instructions:

1. Right side is copied from the left side (left is original side) in wire-frame mode with box-select (CTRL+B). Note that the origin was set to cursor from the beginning.

2. moved 15 grid-spaced in the Y direction

3. then rotated on the pivot point (cursor) 180 degrees (although it shows 540 because I rotated it to test different angles).

4. Clicking on individual parts of the newly cloned & rotated wall shows that some wall parts now have an offset.

• I'm sure, that I don't quite understand your problem yet. However there is a marked Location offset (-0.0000002). Could it be that the objects are rotated around different centers? – Leander Mar 5 at 0:41
• I don't think so, but I could be wrong. There should be no offset imo. Maybe I should attach the part that is giving me a problem. I've uploaded the file and updated instructions for how to get the problem. – Lucidity of Power Mar 5 at 6:10

The 'errror' is caused by the limited precision of floating point numbers. A fix would be quite difficult and in most use-cases completely unnecessary.

After the translation, the objects matrix seems to represent exactly what we expect.

>>> bpy.context.object.matrix_world
Matrix(((1.0, 0.0, 0.0, 0.0),
(0.0, 1.0, 0.0, 15.0),
(0.0, 0.0, 1.0, 0.0),
(0.0, 0.0, 0.0, 1.0)))


After the rotation however, the value of 2 * pi gets included in the matrix.

Matrix(((-1.0, -3.2584136988589307e-07, 0.0, -1.3113416343912832e-06),
(3.2584136988589307e-07, -1.0, 0.0, -15.0),
(0.0, 0.0, 1.0, 0.0),
(0.0, 0.0, 0.0, 1.0)))


Since we have a limited amount of digits in floating points, it will only be an approximation. Applying this approximation to certain numbers will result in rounding errors. If you scroll until the view won't let you zoom in anymore you have reached the limit of Blender smallest units and are seeing these rounding errors.

• Oh, really? :o So is this a problem? does it affect anything (exporting into game engine, for example, or can it cause any lighting problems)? I've been bashing my head against a wall for weeks now, going as far as replicating geometry to get it to perfectly align. Is this worth the effort, or it is inconsequential when importing into a game engine or something else? Please advise. (Btw, thank you for the explanation--really helps me understand now why this is happening.) – Lucidity of Power Mar 5 at 8:30
• If you can, ignore it. Lot of numbers can only be approximated with 32bit floating point numbers. However, they are usually rounded to numbers which are close enough. Notice how this is the reason a lot of operations (remove doubles) need to have a distance threshold. In most use cases there is no need for extreme magnification. – Leander Mar 5 at 8:34
• So, no effect on how lighting translates or what the final representation of the meshes look like when they go into another program? I can ignore it, I just don't know if I should. What do professionals do when they face this problem in this case? – Lucidity of Power Mar 5 at 8:35
• If you can't ignore it or need complete precision, you will have to use a CAD software (or rewrite how Transformations are handled. – Leander Mar 5 at 8:35
• Yes, the imperfection are going to be retained and possibly accumulate, but they're still going to be too tiny to care about. If you want to blueprint precise machinery, don't use Blender. Most visual artists won't have time or reason to view their work magnified x100000, especially in an artistic context. Image output is likely going to only have less than 4000 pixels and only 8bit color depth. Rule of thumb: look at your work through the final output/image/camera/device. Do you see anything wrong. If not, others won't either. – Leander Mar 5 at 8:42