Transform3D scale does not affect arrow length in C++

[psiorx]

Describe the bug
The arrow length of published Transform3D does not respect the scale parameter that is passed in when logged using the C++ API. The same functionality appears to work on the python side.

To Reproduce
Steps to reproduce the behavior:

1. Publish a Transform3D with a specified scale in C++
2. Observe that the scale in rerun viewer is different.

This is the code I used to see the issue:

rerun::Transform3D pose(
        rerun::Vector3D(position.x(), position.y(), position.z()),
        rerun::Quaternion::from_wxyz(quaternion.w(), quaternion.x(), quaternion.y(), quaternion.z()),
        rerun::Scale3D(1.0));

Expected behavior
The scale in the viewer should reflect what scale was published with the transform.

Screenshots

Desktop (please complete the following information):
Ubuntu 22.04

Rerun version
rerun_py 0.15.1 [rustc 1.74.0 (79e9716c9 2023-11-13), LLVM 17.0.4] x86_64-unknown-linux-gnu release-0.15.1 7dedf88, built 2024-04-11T14:47:41Z

[Wumpf]

This is by design: we're not using the transform's scale as the axis length because in a environment where 1.0 means e.g. millimeters and you're working with kilometers this would make the axis too small.

Instead, we heuristically determine the Transform-arrow length factor you see in the ui: It is determined by looking at the accumulated scene bounding box or if present the plane distance of a present pinhole camera.
What's a bit poorly communicated here is that it is a factor: if you log several transforms, but some with a smaller (or even non-uniform) scale, the transform axis will be transformed accordingly. I.e. whatever transform the actual transform tree does applies to the arrows just like it would to a mesh.

The good news is that in the next release it will be easy to override this:

• (python only) you can set a default value for this factor (which is now a component!) per View. Meaning you can tell Rerun to stop doing this fancy heuristic and instead use your default for everything
• (all languages) since the factor is now a component, it can also be just logged to the datastore alongside the transform itself

The later has already landed on main and the former is about to go in :)

[Wumpf]

Closing this as won't fix because the proposed solution of using the scale for transform axis length has shortcomings as described.

Hope the upcoming AxisLength component (that's what it's called right now, but I think we should go with AxisLengthFactor 🤔 ) solves the usecase of having a deterministic known axis length size.

Please re-open if you have counter suggestions!

[psiorx]

It's good to hear the ability to control the heuristic is going into the next release. Is there any workaround I can implement in the version I have to shrink the size of the published transforms? As it stands, the visualization of the trajectory above is not useful given the auto scaling makes the axes very large compared to the motion in the trajectory.

Can I add a fake pinhole camera to control this indirectly?

[Wumpf]

Using a smaller scale will already work since it shouldn't affect the heuristic and will shrink the arrows. Only problem of course is that this then also shrinks everything at and below the transform :/
A fake pinhole would change the arrow length to a quarter of the pinhole image length but that's probably not super useful since the pinhole image distance in turn is determined heuristically.

Likely a better alternative would be to just draw arrows manually using the Arrows3D archetype. The transform arrow visualization should automatically turn off if there's anything else logged at the transform.