(2020-04-23, 15:02)Orion Pobursky Wrote: I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.
Indeed. Internally all matrices are stored using c++'s double variables.
The mesh vectors are stored as single so they can go '1 on 1' to OpenGL. But matrices are only converted to single floating point for use with OpenGL at the very last moment (while keeping the double as the master).
All matrix file io is double too.
I've experimented with re-normalizing the rotation part of matrices during loading but that made thing worse in certain circumstances.
I've also played around with recognizing common matrix values (0.707 etc) to do substitution, but this too isn't fool proof.
The only real solution would be to store more digits or even the whole double precision content as a string (so it would translate back to the same binary content)
(2020-04-23, 16:56)N. W. Perry Wrote: Good, that's what I was guessing as well—that calculating from the coded values gives a different result than applying the series of mutations I make while editing.
As a follow-up, then, it seems I might be doing something backwards. When adding new parts to a rotated assembly, I first snap to grid and reset orientation of the new part (on the relative orientation of course), then move it into place using part snapping. I should probably snap to grid after moving the part into place, huh?
If you snap to the global grid after positioning something on a relative one you will get visual errors. Or do you mean snapping to the relative grid? If so that might also introduce rounding errors as the relative grid does some matrix operations of its own.
The best way to keep clean numbers in your files is by avoiding rotated assemblies of loose parts. Instead use submodels so only one reference line will have those nasty digits. This might not be an option in technic models though.