Floating point error accumulation when moving slot

[copygirl]

Describe the bug?

When moving a slot between parents, a small error accumulates in the transform of the slot, which is especially noticeable for non-visual and UI slots that typically have a default transform. This might be due to the transform being calculated relative to world space, rather than the first common (grand)parent of the two parents.

Due to the nature of the slots' transforms not being relevant in these cases, this is technically a non-issue, but it is still a bother to me and I've noticed myself wanting to reset transforms after moving these slots just so they're at the default value. There is the argument of "if it's not default, then there should be a reason why it isn't", as well as the possibility of some ProtoFlux wanting to test if a slot's transform is default for some reason?

To Reproduce

• Spawn a new object away from the world origin.
• Open it in the inspector.
• Add any amount of (grand)children with default transforms.
• Move any slot in the hierarchy.
• Notice the moved slot now has a transform that's slightly off default.

Expected behavior

If all involved transforms are default, no floating point error should accumulate when moving a slot to a different parent.

Screenshots

Resonite Version Number

2024.10.29.1229

What Platforms does this occur on?

Linux

What headset if any do you use?

No response

Log Files

Not.. relevant?

Additional Context

No response

Reporters

copygirl

[JackTheFoxOtter]

This isn't an issue technically speaking, but I agree that it is a little annoying / frustrating. I usually set the slots local transform back to 0 manually when that happens.

[shiftyscales]

As you covered, this is likely an expected outcome from a lack of floating point precision- as such- I do not think this should be considered a bug. Seeking input from @Frooxius if there is anything we would want to do to mitigate this.

In #121 Frooxius had noted plans to mitigate / minimize issues with floating point imprecision in larger worlds by "chunking" them.

I'm changing this away from a bug, this is not really a bug, just more of a consequence of how floating points behave, so it's not totally unexpected - and not something that can be really fully addressed - we can only mitigate this in various ways.

Longer term, we'll likely provide systems for chunking worlds, so you can build much larger worlds, while keeping the actual values pretty small within each chunk. That would allow to build virtually unlimited (meaning limited by complexity, storage and RAM) world sizes.

[copygirl]

What I was trying to say is that the precision error can be avoided by applying the relevant transformations relative to the first shared parent's space rather than the world space, since doing the math on a bunch of identity transforms should not accumulate an error.

[mpmxyz]

Computations based on the first shared parent will be more precise in general but I assume there may be performance implications if the precomputed local-to-global/global-to-local matrices aren't used.
I personally agree that there should be no error for identity matrices. They invert perfectly and do not change vectors.
As a compromise, should reparenting be handled more precisely if done within the inspector? That's where it affects people's OCD most.
Using the shared parent should also improve reparenting behavior within slots that are scaled to 0 on one axis. This causes children to lose all transform information. (pos=scale=[0;0;0], rot=[0;0;0;1])