MCAP with multiple tf_static messages shows warning

[alcolado]

Describe the annoyance
MCAPs can have multiple messages between different parent/child frames all under "/tf_static" topic. When it's opened up in Rerun, you can only see the "last" static message in the timeline and there is a warning about data being overridden. By inspecting the transform tree, it seems like all transforms are actually there and not overridden (which is good). But the warning message and the fact that it is missing from the timeline seems bad. I'm not logging as a bug because the MCAP seems to be loaded correctly.

I generated an example MCAP with 4 TF static messages from world to camera[i].

To Reproduce
Steps to reproduce the behavior:

1. Open up this MCAP tf_static.zip in viewer
2. Scroll to /tf_static Transform3D in the streams and click on a component like "child_frame"
3. See error

Expected behavior
I would expect to see the 4 components (like what happens when it is /tf and not static)

Try example tf MCAP tf.zip

Your goals
I'm trying to visualize MCAPs and ensure everything is loaded properly. In the future, I probably will want to extend Rerun to load my custom ROS2 schema messages, but for now I've been looking closely at how the standard schemas are loaded.

After making this small toy example, it seems like everything is loaded OK, but with a more complicated MCAP I saw this error message and assumed the other static TF messages weren't going to be seen.

Desktop (please complete the following information):
Windows
rerun-cli 0.34.1 (base lance map_view nasm native_viewer oss_server perf_telemetry re_server release_full release_no_web_viewer web_viewer) [rustc 1.92.0 (ded5c06cf 2025-12-08), LLVM 21.1.3] x86_64-pc-windows-msvc prepare-release-0.34.1 4efb18f, built 2026-07-07T16:29:17.7132187Z
Video features: av1 ffmpeg nasm

[Wumpf]

As the tooltip you found implies, our datamodel has been so far that rewriting static data effectively overwrites previous static data, potentially destroying the data in the process. And quite some people use this when treating Rerun as a kind of monitor where they only want to keep e.g. the last image.
However, with ROS-style named transforms this gets a bit weird which is why we made an exception there and in actuality never discard any static transform data and read them out correctly - but the UI doesn't know that yet and still reports the behavior that is true for everything else and doesn't allow inspection.

Overall this is a little bit up in the air how we want to formalize this behavior. Previous thinking has been that we want to remove the silent static-discard behavior altogether and instead offer some other mechanism to allow Rerun use as a "monitor" in a more explicit way.

Looks like we didn't document this on the public issue tracker yet - thanks for filing and proving a repro & concise screenshots describing the problem <3

[wuisabel-gif]

I dug into this a bit. Reproduced the exact chunk shape the /tf_static MCAP parser produces (a single static chunk on the /tf_static entity carrying multiple (parent_frame, child_frame) pairs as separate rows, via Transform3D::update_fields().with_many_child_frame(...).with_many_parent_frame(...)) and ran it through TransformForest.

The data/transform layer looks correct:

• Both frames resolve fine (e.g. a → root and b → root each give the right transform), so no transforms are actually lost. This matches the "all transforms are there" observation.
• No warning is emitted from re_tf or from the chunk-store insert path (static-transform data is preserved via the is_transform_archetype exception in re_chunk_store::writes).

So the "data being overridden" warning seems to be a viewer-side artifact that only appears at render time, not a real ingestion/query problem. A few candidates I looked at but ruled out:

• warn_on_per_instance_transform in re_view_spatial, which only reads InstancePoses3D, whereas /tf_static uses named Transform3D.
• No user-facing "override"/"overwritten" warning string exists in the viewer crates.

@alcolado could you paste the exact warning text you saw (or attach a small MCAP that triggers it)? That would point straight at the emitting site. I couldn't find a ROS2 /tf_static fixture in the repo to reproduce the viewer warning directly, only the Foxglove FrameTransform one, which is a different message type. A minimal repro asset would probably be worth adding regardless.

[alcolado]

@wuisabel-gif here is a zipped MCAP for repro tf_static.zip. I dropped it into viewer with this version

Version 0.34.1 (4efb18f)
Built 2026-07-07T16:29:17.7132187Z
Platform x86_64-pc-windows-msvc
Compiler rustc 1.92.0 (ded5c06cf 2025-12-08), LLVM 21.1.3

You have to select a component under Streams -> tf_static -> Transform3D and look at the selection panel

The exact message is "When a static component is logged multiple times, only the last value is stored. Previously logged values are overwritten and not recoverable".

I guess it's coming from here https://github.com/rerun-io/rerun/blob/main/crates/viewer/re_data_ui/src/latest_all_instance_ui.rs#L66 (which indeed appears to be in the viewer side)

hope this helps!

EDIT: I also noticed if I log directly

import rerun as rr

rr.init("tf_static")
rr.spawn()

rr.log("tf_static", rr.Transform3D(translation=(0, 0, 0), parent_frame="world", child_frame="camera"))
rr.log("tf_static", rr.Transform3D(translation=(0, 0, 0), parent_frame="sun", child_frame="moon"))

There is no warning, but the data is invisible on the streams/timeline/selection panel (but shows up in the Transform cache)

[wuisabel-gif]

Thanks for digging up the line too, saved me a bunch of time.

So that warning at latest_all_instance_ui.rs:61 just fires whenever a static component gets logged more than once and prints the generic "only the last value is stored, not recoverable" text. But transforms are a special case, like @Wumpf said. The store never actually throws away static transform data (the is_transform_archetype exception in re_chunk_store), so for /tf_static that warning isn't true. The store already knows the data is safe, the UI just doesn't check.

So the fix seems to be: look up the component's archetype and skip that "not recoverable" warning when it's a transform, since nothing was actually lost.

Your edit looks like a separate bug though. When you log the two transforms directly there's no warning, but the values don't show up in Streams/timeline/selection at all, only in the transform cache. So there's really two things here: the misleading warning on one side, and multi-frame static transforms not being inspectable in the panels on the other. Probably worth splitting that second one into its own issue.

I'm happy to put up a PR for the warning if that's useful. I did see @Wumpf mention the static-overwrite behavior might change in general, so no worries if you'd rather sort the bigger picture first.

[Wumpf]

in your direct logging case you didn't enable static=True - the problem is as I tried to describe earlier one of our semantics for static data. The data isn't actually invisible on the timeline, it's just at two different times since if you don't specify a timeline yourself everything goes to log_time which takes wallclock time of the log. On your screenshot you have only the child_frame component selected, but the translation is right there as well.

@wuisabel-gif yeah I think a fix for the selection panel that is also aware of the transform conundrum would be useful until we sort out the rest of our datamodel inconsistency. Ideally we'd expose (& rename) crates/store/re_chunk_store/src/writes.rs's is_transform_archetype - the doc comment there already explains the problem.

[alcolado]

ahh oops, I messed up the EDIT. I was trying to see if I could reproduce without MCAP, and I forgot the most important part!
This snippet seems to reproduce the behavior from the MCAP

import rerun as rr

rr.init("tf_static_example")
rr.spawn()

rr.set_time("time", sequence=1)
rr.log("tf_static", rr.Transform3D(translation=(0, 0, 0), parent_frame="world", child_frame="camera"), static=True)
rr.log("tf_static", rr.Transform3D(translation=(0, 0, 0), parent_frame="sun", child_frame="moon"), static=True)

that makes more sense now...

Anyway, thanks for all the clarification! I'm content knowing it's just a transient UI warning... but maybe future users would benefit from a fix to the warning?

[atirna]

I've put up #12892, which keeps the selection panel from showing the "overwritten and not recoverable" warning for named transforms (Transform3D/Pinhole): it now shows a neutral info label whose tooltip explains that all static transforms are preserved, as discussed above. It exposes the store's is_transform_archetype check as re_chunk_store::preserves_static_transforms to do so.

[MichaelGrupp]

Since this issue is also about MCAP /tf_static: I'm currently considering whether we just load ROS /tf_static as normal, non-static Rerun data. This would have a few advantages:

• MCAP message_log_time and message_publish_time events for /tf_static are preserved
  • you might wanna see when a static TF was logged, or to debug cases where a static ROS TF was logged at a later time and the transform tree was broken before
  • with the current behavior, these are lost because Rerun-static makes all timelines static
• Transform tree correctness isn't affected
  • Rerun's transform system uses latest-at queries: i.e. tf_static stays part of the transform trees after it appears, not getting discarded
  • (ROS' TF buffer requires the "static transform" semantic because it works on a rolling time window otherwise, discarding transforms that aren't republished)

So basically, the concept of static in ROS TF and in Rerun don't have to be directly coupled. In ROS it also means "don't discard these transforms", but in Rerun this is also true after a non-static transform was logged.

BTW: we already do this when loading a Foxglove frame transform from a tf_static topic, so it would also be consistent and not have a special cased behavior for ROS only.

---

Note: the improvement of the selection panel is probably still useful and this is an orthogonal discussion

[alcolado]

For what it's worth, logging the the /tf_static as normal, non-static seems great to me for exactly the debug case you described 👍.