ViewCoordinates documentation is wrong or at least misleading

[rafaelspring]

Describe the bug
https://rerun.io/docs/concepts/spaces-and-transforms#view-coordinates

Quote:

For 3D spaces it can be used to log what the up-axis is in your coordinate system. This will help Rerun set a good default view of your 3D scene, as well as make the virtual eye interactions more natural. This can be done with rr.log("world", rr.ViewCoordinates(up="+Z"), static=True).

I followed this and (using C++) I put this in my code
rec.log_static("world", rerun::ViewCoordinates::RIGHT_HAND_Y_DOWN);

But the view camera in the viewer is still gimbal-locking, basically same as without the above line.

To Reproduce
Follow steps in the quote.

Expected behavior
View camera up axis actually changing to what's been set.

To Fix
The path needs to be "/" instead of "world".
Maybe there's some bigger context that I'm missing but that camera gimbal-lock made the (otherwise great) viewer immediately unusable for me. I needed a solution and rr.log("world", rr.ViewCoordinates(up="+Z"), static=True) is what I found and it didn't help.

[Wumpf]

Thanks for filing this! world is just an example for a potential origin of the view and nothing special. I agree that this is written in a way that is very easy to understand. So really it should be something like your/view/origin and explain what this is all about.

The "lock" your experiencing on the camera btw. is not actual gimbal lock which would be if a degree of freedom is lost because axis are aligning. What's happening instead is that our camera maintains an abstract up vector (which is influenced by ViewCoordinates) that stays constant. Once the camera is tilted such that that its actual up vector coincides with the abstract notion of the world's up we don't allow further rotation. It's essentially preventing the camera to be up-side down.
Agreed though that we should probably also come up with something different here.

Related to:

• Split ViewCoordinates component #2663
• Advanced camera rotation controls #5823

[rafaelspring]

I used the term "gimbal lock" loosely here but I think we all know what is meant by that.
But TBF you actually do lose a motion DOF when you align with the up-axis.

I assume you're parameterizing your camera view by a pivot point, distance and 2-dof phi and theta?
You don't have to btw.
It's totally possible to have camera that's easy to navigate and doesn't suffer from gimbal lock.
The model for that is to treat your scene as a "ball" and then any drag operation will project the clicked points down to the ball and bring the start and current point into alignment by rotating the ball. We use this model in our Dot3D app and all our users tell us it's the most natural camera controls they know.

[rafaelspring]

Also, w.r.t my original point:
I think it'd be great if the solution proposed in the docs helps Rerun.io beginners like me. I found the "/" solution kind of by accident and was almost at a point where I gave up on Rerun.io, despite it being great otherwise. The camera locking is definitely an issue, and as long as it is, the solution shouldn't be far.

[Wumpf]

We use this model in our Dot3D app and all our users tell us it's the most natural camera controls they know.

There's plenty of suggestions floating around in various tickets, many attached with strong opinions on what's the best solution, typically implicitly tied to some particular field. I believe there's some universal improvements to be made (kicking out the constrained orbit camera may be one of them, but maybe also not as it's very popular in some fields :/), but for the most part this is a lack-of-easy-configurability story. Some of the associated tickets are linked here.

That said, the input is appreciated, thank you! :)