Better log_pinhole and orient camera furstum based on pinhole view coordinates

[Wumpf]

What

Fixes #2244, Fixes #2589

• ViewCoordinates are not working properly for camera frustums #2244
• Specify Pinhole without an explicit matrix #2589

Camera frustum and contained 2D content reacts now correctly to axis conventions set by view coordinates. Turns out that we before had essentially RDF hardcoded which became particularly apparent when flipping the Z axis, e.g. by using RUB (which ironically is the convention we use for the Eye camera itself).

I tested this against all samples that have a frustum and in particularly also made sure that 3D->2D transforms still work as expected (tested this in arkit and objectron).

Furthermore, I checked against #2512 where frustum orientation did not align with what happened when taking the view of the camera (i.e. double clicking the frustum). Without setting view coordinates this now correctly shows

And with setting

rr.log_view_coordinates("world/cameras", xyz="DLF") # TODO: Why is the camera wildly different?

the frustum flips around and the scene starts making sense

I also took the opportunity to look over uses of view coordinates and remove SpaceSpecs as well as unnecessary caching thereof (or view coordinates) as a result.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)

PR Build Summary: https://build.rerun.io/pr/2553

Docs preview: https://rerun.io/preview/399c6d9/docs
Examples preview: https://rerun.io/preview/399c6d9/examples

[Wumpf]

converted to draft since this doesn't account yet for projected rays

[Wumpf]

Phew. I think I understand situation now way better than before. Before the last couple of changes, the points we pass between 2D and 3D didn't work out because we had underlying assumptions of how axis translate. Now both the ray and the projected hover point work nicely:

hover point (just ehm imagine the mouse in the right spot)

hover ray:

[jleibs]

This PR seems to be conflating the role of view coordinates with the role of camera extrinsics. We do need to be able to use view coordinates to resolve the ambiguity in positive vs negative z. However, we should not arbitrarily be pointing the frustum along the axis that happens to have been annotated as F within a parent view coordinates. The only thing that should be changing which axis the camera is aligned with is a transform3d relative to the parent frame.

[emilk]

Converted to draft because we are not aligned with how to proceed on this yet. Basically we don't know exactly how view_coordinate should affect the frustum of a world/camera, if at all.

Based on PR discussion. Unblocking this (but not approving yet).

[emilk]

I'm taking this over!

[emilk]

This has gone waaay above and beyond the original PR. I'll open my own PR instead :)