Transform3D scale does not affect arrow length in C++ about rerun HOT 4 CLOSED

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 :)

from rerun.

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!

from rerun.

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?

from rerun.

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.

from rerun.