When I am using clamped rotations (set to 15) the rotation always ends up being 89.9999, or 179.9999 ectect. Always 0.0001 off. Yes, 0.0001.
I am working out the kinks for my lego-piece buildings, which require perfect alignment to not have any graphical glitches. Wanting to work on the corners, I duplicate a side 4 times to makes full building. 89.9999. 179.9999. 269.9999. Each time it throws off the position of the wall every so slightly.
Things that appear. Without an editor script, I don’t think I can quickly fix setting the entire side to 270 correcting their position (instead of being at 10X, it may be at 10.0252X which is noticeable). A rounding error?
It’s not a bug, but rather is behavior inherent to floating-point numerical representations.
This topic has actually come up quite a few times recently (that is, how to get neighboring vertices under different transforms to match up exactly). Unfortunately, you really can’t count on geometry under different arbitrary transforms matching up exactly, especially when the transforms involve transcendental functions (as rotations do).
I know it might involve significant redesign to implement this, but unless I’m overlooking something, the optimal solution is probably to generate the mesh geometry procedurally and apply only one transform to each ‘geometry group’ so that neighboring vertices can be guaranteed to be exactly coincident.