3 decimals is not a lot of precision for rotation matrices
2013-03-23, 19:48 (This post was last modified: 2013-03-26, 22:29 by Sergio Reano.)
2013-03-23, 19:48 (This post was last modified: 2013-03-26, 22:29 by Sergio Reano.)
Hi Y'all,
Roland and I have been tossing around part numbers, looking at smoothing results. One thing that surprised me is that we needed a rather large 0.05 LDU error margin to 'snap' the segments of the 6x6 webbed dishes together. (The part is built via 8 sub-sections rotated 45 degrees.) 0.05 seems like a 'big' error because part authors can specify vertices to the 0.001.
Today I cracked open the part and took a look at the numbers, and the large error margin now makes sense.
The fundamental problem is absolute error amplification: if the error on a matrix ratio is 1/1000 (0.001 precision) then the actual error in the position of a rotated part is 0.001 * R where R is the approximate radius of rotation. In other words, a part that extends 60 LDU from its center will have an absolute error of 60/1000 (0.06) after rotation. (In fact, the real results are up to 3x worse because error accumulation is additive and we add the X, Y, and Z components of the matrix).
The actual numbers of the 6x6 dish show that the worst case error could have been much worse than this actual part. The bottom line is: 0.001 just isn't _that_ precise for a rotation component that's going to be used for a moderately big part. :-(
This matters because the rounding tolerance for welding rotated part segments for smoothing defines the smallest 3-d detail an author can make without having their triangles collapsed.
I realize that we have a gajillion parts and my going "we should do X" isn't going to actually change the library, but I wonder if this perspective should result in some kind of updated practices for authoring.
Naively, I would suggest two possible changes...
1. We could allow higher precision for matrices. For example, the part is using 0.707 for a 45-degree rotation. If I go into the text file and replace it with 0.707106781186548 I can cut my error margin down by 4x. (Clearly BrickSmith isn't using all of 0.707106781186548 - I just typed a big long number into the text file...BrickSmith is using 32-bit float.)
2. Authors could avoid angle rotations that aren't 90 degree increments. At 90 degrees, the rotation matrix can be _exactly_ represented - all rotational coefficients are 0, 1, or -1. :-) So the 'lock-up' of vertices around 90 degree rotations should be pretty good - certainly in the same ballpark as the geometry itself.
This would mean 'bigger' parts - 90 degree swathes of dish instead of 45 degrees, but the precision would be a lot better.
Cheers
Ben
Roland and I have been tossing around part numbers, looking at smoothing results. One thing that surprised me is that we needed a rather large 0.05 LDU error margin to 'snap' the segments of the 6x6 webbed dishes together. (The part is built via 8 sub-sections rotated 45 degrees.) 0.05 seems like a 'big' error because part authors can specify vertices to the 0.001.
Today I cracked open the part and took a look at the numbers, and the large error margin now makes sense.
The fundamental problem is absolute error amplification: if the error on a matrix ratio is 1/1000 (0.001 precision) then the actual error in the position of a rotated part is 0.001 * R where R is the approximate radius of rotation. In other words, a part that extends 60 LDU from its center will have an absolute error of 60/1000 (0.06) after rotation. (In fact, the real results are up to 3x worse because error accumulation is additive and we add the X, Y, and Z components of the matrix).
The actual numbers of the 6x6 dish show that the worst case error could have been much worse than this actual part. The bottom line is: 0.001 just isn't _that_ precise for a rotation component that's going to be used for a moderately big part. :-(
This matters because the rounding tolerance for welding rotated part segments for smoothing defines the smallest 3-d detail an author can make without having their triangles collapsed.
I realize that we have a gajillion parts and my going "we should do X" isn't going to actually change the library, but I wonder if this perspective should result in some kind of updated practices for authoring.
Naively, I would suggest two possible changes...
1. We could allow higher precision for matrices. For example, the part is using 0.707 for a 45-degree rotation. If I go into the text file and replace it with 0.707106781186548 I can cut my error margin down by 4x. (Clearly BrickSmith isn't using all of 0.707106781186548 - I just typed a big long number into the text file...BrickSmith is using 32-bit float.)
2. Authors could avoid angle rotations that aren't 90 degree increments. At 90 degrees, the rotation matrix can be _exactly_ represented - all rotational coefficients are 0, 1, or -1. :-) So the 'lock-up' of vertices around 90 degree rotations should be pretty good - certainly in the same ballpark as the geometry itself.
This would mean 'bigger' parts - 90 degree swathes of dish instead of 45 degrees, but the precision would be a lot better.
Cheers
Ben