Deprecate DisconnectedSpace archetype/component in favor of implicit invalid transforms

[Wumpf]

Related

• Fixes Deprecate DisconnectedSpace, replace with pure transform marker type InvalidTransform/UndefinedTransform (tbd) #7868

What

See title. In detail:

• RotationAxisAngle will no longer be ignored when axis is non-normalizable
• deprecation of DisconnectedSpace
  • slight fixes to codegen for handling this smoothly
• lots of doc updates
• wherever we had constants for identity, we now also have one for invalid
  • python didn't have any at all so far, but I didn't want to add this in this iteration since generally constants there are a bit tricky
  • we should have more of those generally

[github-actions]

Latest documentation preview deployed successfully.

Result	Commit	Link
✅	85d151d	https://landing-bymn45d9e-rerun.vercel.app/docs

^{Note: This comment is updated whenever you push a commit.}

[github-actions]

Web viewer built successfully. If applicable, you should also test it:

• I have tested the web viewer

Result	Commit	Link	Manifest
✅	85d151d	https://rerun.io/viewer/pr/8459	+nightly +main

^{Note: This comment is updated whenever you push a commit.}

[jleibs]

Now that we have tagged components, does this actually need to be a Transform-specific component?

This could be rerun.components.InvalidData.

I'm also now wondering about Invalid = True vs Valid = False.

rerun.components.ValidityMask would feel the most arrow-like from a concept perspective, though I recognize this opens a can of worm of wanting to start supporting valid = False for every visualizer.

[Wumpf]

Now that we have tagged components, does this actually need to be a Transform-specific component?
This could be rerun.components.InvalidData.

That would imply that we make this more of an infrastructure thing and many things can be flagged as InvalidData. Which I really don't want to get into. Also, I wouldn't say it's invalid data per se. You might still have some valid transforms active, you just want to disable it.

On that note: we could also dodge this entire thing completely by saying any of the invalid-transform states like full nulled mat3x3 has the same semantics. Today, some of these "invalid transforms" are explicitly ignored since it's more practical - specifically we speced rotation-axis-angle with a null axis to just be no-rotation since that's more convenient (and I actually already fixed it up here so that the same is true for null quaternions)

I'm also now wondering about Invalid = True vs Valid = False.

Either isn't great, but Valid=False is indeed mentally easier. Maybe best to go with an enum to force making this explicit. In that case We end up with DataValidity/TransformValidity/ValidTransform == false/true

.... but overall I really don't want to make this any more complicated than is. The whole point of doing this now is to make a presumably rarely used feature not be as much in the way of performance enhancement & simplifying (!) refactors. That's why I wanted to deprecate DisconnectedSpace asap (something we already agreed upon) so I have simpler logic in the release after

[jleibs]

You might still have some valid transforms active, you just want to disable it.

This is a great observation, which makes me realize any of the names related to Validity aren't quite correct.

What we really want to say then is simply "Don't use this transform" (which is also more Transform-specific concept than validity)

Other words: "Enable/Disable", "Apply", "Connect/Disconnect"... 🤔

[Wumpf]

Talking this out we came to the conclusion that for the moment we won't introduce a new component and instead encourage invalid transforms like scale==0/matrix==0 etc.
Making this a much smaller change!