Fix mesh flicker

[teh-cmc]

Funnily enough, the reason this was flickering on 0.15 was completely unrelated to the reason why it flickers on main.

Long story short: it had to with how explicit client-side splats were splitting the data across different timestamps and in some cases this was incorrectly handled.

In the new APIs it's just an issue in the entity_iterator machinery which lowers everything to range semantics, which leads to problems when the query expects latest-at semantics.

• Fixes Renderer randomly fails to handle a Mesh3D changing its size #6072

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[Wumpf]

maybe it's just late but I don't get what indices on a latest-at query mean and why the particular index chosen fixes which primary components come together with which secondary ones. Can you try to eli5 it to me? 🥺

[teh-cmc]

maybe it's just late but I don't get what indices on a latest-at query mean and why the particular index chosen fixes which primary components come together with which secondary ones. Can you try to eli5 it to me? 🥺

It all has to do with a hack that entity_iterator does in order to cut down on code deduplication in all space views.

The entity_iterator queries the different components using either latest-at or range queries depending on the current state of the blueprint, and then converts the results to range results no matter what, so that the downstream views only need to be implemented for range results.

The problem is that latest-at results can be spread over time in arbitrary ways (e.g. position data from frame 42 and color data from frame 157), and should just be joined blindly, irrelevant of their respective timestamps/indices.
So, to make sure they do get joined together during the temporal join (range_zip), we give them all the same index.

[Wumpf]

ahh thank you that helped a lot! :)