Quote

**Travis Cobbs**

The expectation here is that LDraw files start out with fixed point coordinates, and very often, the transformed coordinate will also be very close to fixed point values (due to transformation matrices often being simple translations, or 90-degree increment rotations). So I wanted to prevent floating point innacuracies from separating two points from each other that were expected to be together.

Ah - I think that the expectation is correct for untransformed locations but likely to be incorrect for transformed ones.

For the untransformed point what you've basically said is: users shouldn't use more than 0.001 LDU, so I'll set up a grid of that spacing, with the gridlines at the half-way points between the canonical values, then bucket. And that makes sense.

But once the transform _stack_ is applied, how do you know where the 'grid lines' in the theoretical 1/1000th LDU grid are? Ignoring scaling, I think that just rotations will hose you. The result of the rotations may be totally misaligned with the grid, and thus two points that were near an even mili-LDU (mLDU?? :-) and would round together now span a 'split point (the points half-way between the canonical values where rounding has to go one way or another).

In other words, I think for untransformed parts your code works but for transformed ones some small sub-set of points that should have been locked together will be pulled apart.

cheers

Ben