Transforms not yet published cause RGB axes automagically rendered at the origin

[stonier]

Describe the bug

Transform axes are drawn for an entity at the world origin, even before it has yet been published.

This is similar to #7729 which is the same problem but at the other end (after the entity has been cleared).

To Reproduce

use rerun as rr;

fn generate_transform(x: f32) -> rr::Transform3D {
    rr::Transform3D::from_translation_rotation(
        rr::Vec3D::new(x, 0.0, 0.0),
        rr::Quaternion::IDENTITY,
    )
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let (stream, storage) = rr::RecordingStreamBuilder::new("Clear").memory()?;
    let t_3 = generate_transform(3.0);
    let t_5 = generate_transform(5.0);
    let t_6 = generate_transform(6.0);
    stream.set_time_seconds("sim_time", 0.0);
    stream.log("/bar", &t_5)?;
    stream.set_time_seconds("sim_time", 1.0);
    stream.log("/bar", &t_6)?;
    stream.set_time_seconds("sim_time", 2.0);
    stream.log("/foo", &t_3)?;
    stream.log("/bar", &t_6)?;
    stream.set_time_seconds("sim_time", 3.0);
    stream.log("/foo", &t_3)?;
    stream.log("/bar", &rerun::Clear::flat())?; // <-- sends the visual 3d axes back to the origin
    rr::native_viewer::show(storage.take())?;
    Ok(())
}

Expected behavior

Nothing is rendered prior to the first entry in the log.

Screenshots

^You can see the axes for '/foo' rendered, even though it reports "Nothing logged at sim_time = 0.630s".

Desktop (please complete the following information):

OS: Ubuntu 24.04

Rerun version

v0.20.3

[Wumpf]

This and #7729 (which I wasn't aware of) both happens because...

• the decision whether a visualizer is active is independent of timeline. We generally don't add/remove visualizers over time and if a visualizer is applicable at one point in time we assume it's always applicable
• the Transform3DArrows visualizer technically has no "required components" since it simply asks the internal transform system for the resolved transform at a given entity path and uses that to draw the arrows

We could fix this fairly easily by having the visualizer check if at the given point in time there are any transform3d components around and if there's none don't draw anything.
But I'm actually not sure if that's the right call: It is technically still correct that there is a valid global transform around since we're technically not even visualizing the transform that was logged, but the ephemeral one that was propagated through the entity hierarchy. By the same line of argumentation it should always be possible to enable the visualizer. Which we'd actually like to do, but today that would mess with our view-spawn heuristics since it means that everything in existence can be visualized in a 3D view.
cc: @jleibs, I know you love discussing this stuff, maybe it's time again 😄

In any case the workaround for 0.20.x is to set the AxisLength component on the transform to zero when it shouldn't show up.

FYI, in 0.21 we're going to spawn less transform arrows by default, see

• Don't show transform arrows on all entities without any other visualizer #8387

[stonier]

Thanks for the 👀.

The workaround (AxisLength to zero) doesn't really help our use case - the fact that it's rendered is not that much of a problem. The fact that an invisibly rendered artifact exists 7000m away from where the action happens (it's a driving resim from a log) is what's annoying. It causes the visualizer to zoom out and requires manual intervention to zoom in appropriately.

[Wumpf]

thanks for that detail, that makes a lot of sense; super annoying indeed!

Makes this related to

• Allow setting default camera position/direction in blueprint #8265

but also the default camera shouldn't do that, in other words invisible arrows shouldn't add to the bounding box that is used for the camera. I can fix that bit right away!

[Wumpf]

Huh, so actually we already do ignore zero axis lengths for the bounding box (and rendering itself ofc). So the camera zooming out because of them is very unexpected. Can you check whether the bounding box that Rerun determines is unnecessarily blown up? You find those settings in the selection panel for a selected 3d view

Likely there is something else in your scene that confuses the bounding box / camera placement heuristic