I have noticed this problem for several version and oddly I haven’t noticed any reports regarding this issue.
When using “make transform” blueprint node the values for rotation are altered somehow. Even basic functions such as rotating yaw 90 degrees cause the actual transform rotation to be 89.99 which is very visible if you are trying to rotate objects that seam together.
Even worse if you make a rotation with pitch 90, yaw 90, and rotation 90, the yaw and rotation get altered to -13.26 for some odd reason, while the pitch remains 90.
This is easily replicate. Easiest is to have a make transform filled with rotation values and then print the transform. To visualize how even the 90 = 89.99 issue create a series of cubes that are place exactly next to each other horizontally. Rotate one of the cubes by yaw 90 and you will notice very apparently creases. This poses many issues if you are using tile base generation.
Scale and location do not seem to be affected, it is only rotation.
I think this is partially caused by a floating point precision error and by the backend implementation of the FTransform. The FTransform uses quaternions to store rotation values, so when they convert a quaternion back into a Yaw, Pitch, Roll (YPR) rotation, it’s going to change the YPR values. The rotation angle is still the same (or extremely close to it).
the rotators aren’t the only things affected by floating point precision errors. You may notice it with your location values as well (ie, an object x value is at -0.000001 instead of 0). Generally, you should not count on floating point numbers to be exactly precise. If you’re really curious, you can read more about how floating point values are assigned within the IEEE pubs.
The thing with floats in general is that you get higher precision when your numbers are closer to zero. The floating point precision between 0 and 1 with floats is much higher than at 100000 and 100001. This is an important design consideration to make.
As for the rotators getting different values… it’s generally going to try to keep your angles as close to zero as possible to maximize precision. If you give an object a rotation of 270 degrees, it’s the exact same as -90 degrees. -90 is closer to zero than 270, so the engine will prefer to use -90. With quaternion rotators, you have an X,Y,Z and W component. These are hard and funky to wrap your mind around, so don’t try. Essentially, it’s a rotation around an arbitrary axis of rotation. When the engine converts the quaternion into a yaw, pitch, roll rotator, it’s going to try to make each XYZ component get as close to 0 as possible, so your rotations will generally be between -90 and 90 degrees.
Deleted my previous comments to have a more succinct and simple example to show you.
While I’m certain its is an issue to relating to floating point precision, its is one that can be accounted and fixed for, which defines it as a bug.
I have 3 make transforms, all which have a location of 90,90,90. Each make transform is unique in that it adjust either pitch, roll, or yaw.
Roll and yaw are both affected by the floating precision error, but pitch is not, nor are the location or scale adjustments.
I have already accounted for discrepancies in regards to the print string node, as this is visually replicated if you have 2 cubes that both have a side sharing the exact same location for it’s vertexes and rotating one of the cubes rotation or yaw. because of the small offset, what should be seamless is displayed as a crack between the 2 cubes.
I have made a custom “make transform” macro that takes the exact same parameters, and performs without any loss in precision. While my work around works, its a bit tedious as a lot of BP nodes require a transform, so I have to use it anyway, set the values to 0 and then run my fixed “make transform” macro.
below is an actual example you can use for replication. A flat plane composed of tiles 800x800x100 that have random rotation with a factor of 90 degrees. You can have the tiles as actors, but I used instanced static meshes in this instance. The larger the object, the more obvious the cracks become as the crack width will increase.
edit: also to add, I already checked out the make rotator, it outputs correctly so I’m certain the error is within the make transform, and it only affect pitch an yaw, I have tested several times but I was unable to replicate the issue for roll.
This is a known issue and is in our system as UE-4459. is correct, however, that this is due to FTransform using quaternians. I’m updating the bug report to reflect that more developers are experiencing this.
