Rethink view selection & filtering + make all views opt-in#3323
Rethink view selection & filtering + make all views opt-in#3323
Conversation
f6b2448 to
2aa04d8
Compare
jleibs
left a comment
There was a problem hiding this comment.
Yes! This is so much more clear.
crates/re_space_view_spatial/src/contexts/annotation_context.rs
Outdated
Show resolved
Hide resolved
| /// The archetype queried by this scene element. | ||
| fn archetype(&self) -> ArchetypeDefinition; | ||
| /// Returns the minimal set of components that the system _requires_ in order to be instantiated. | ||
| fn required_components(&self) -> IntSet<ComponentName>; |
There was a problem hiding this comment.
Is there any scenario where this needs the flexibillity from ViewContextSystem of returning Vec<IntSet<ComponentName>> instead?
There was a problem hiding this comment.
The situation of our combined (Image, SegmentationImage, DepthImage) System is maybe one example?
There was a problem hiding this comment.
Yep, it's the only example I stumbled onto iirc.
EDIT: Oh no actually the transform one is the one I had in mind:
vec![
std::iter::once(Transform3D::name()).collect(),
std::iter::once(Pinhole::name()).collect(),
std::iter::once(DisconnectedSpace::name()).collect(),
]| fn archetype(&self) -> ArchetypeDefinition { | ||
| ColorArchetype::all_components().try_into().unwrap() | ||
| fn required_components(&self) -> IntSet<ComponentName> { | ||
| ColorArchetype::required_components() |
There was a problem hiding this comment.
Should required_components just return an IntSet natively?
There was a problem hiding this comment.
I want to keep these core methods allocation-free but... maybe we can generate a static intset in addition to the static array... hmm, I'll have a look.
There was a problem hiding this comment.
Eeeeh no actually there's still all the mesh stuff to ship so I'll just leave a comment for now, but yeah something to keep in mind
jleibs
left a comment
There was a problem hiding this comment.
Meant to approve on the last review.
|
for the record, I skimmed it and agree: great step forward! |
| fn all_required_components(&self) -> Vec<IntSet<ComponentName>> { | ||
| vec![ | ||
| vec1::vec1![Transform3D::name()], | ||
| vec1::vec1![Pinhole::name()], | ||
| vec1::vec1![DisconnectedSpace::name()], | ||
| std::iter::once(Transform3D::name()).collect(), | ||
| std::iter::once(Pinhole::name()).collect(), | ||
| std::iter::once(DisconnectedSpace::name()).collect(), |
There was a problem hiding this comment.
These are not all required - only the first one is.
There was a problem hiding this comment.
These are different sets -- any one of them is sufficient to trigger the system
|
This has surfaced a completely unrelated dormant bug with the way the Box2D view handles annotation labels. I'll open a new PR for said bug, this has already scope creeped way too much. |
emilk
left a comment
There was a problem hiding this comment.
LGTM after a quick look, except I don't understand compatible_component_sets from its docstrng
| .iter() | ||
| .map(ToOwned::to_owned) | ||
| .collect() |
There was a problem hiding this comment.
.iter()
.map(ToOwned::to_owned)
.collect()is starting to get tedious
What the title says. Requires #3323, which made the underlying bug visible to begin with. ### What ### Checklist * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested [demo.rerun.io](https://demo.rerun.io/pr/3331) (if applicable) - [PR Build Summary](https://build.rerun.io/pr/3331) - [Docs preview](https://rerun.io/preview/85a4a018bb55e34053f0fcbe475a719e7a0207a4/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/85a4a018bb55e34053f0fcbe475a719e7a0207a4/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://ref.rerun.io/dev/bench/) - [Wasm size tracking](https://ref.rerun.io/dev/sizes/)
This refactors view selection & heuristic filtering based on the lengthy standup discussions we had regarding the difficulties met during the implementation of the mesh-related archetypes.
The most important changes are to the
ViewPartSystemtrait which now looks like this:as well as the modification made to the heuristic filtering logic.
As a side-effect of these changes, our heuristics now support archetypes with multiple required components.
This also makes all space views opt-in based on indicator components, as opposed to the status quo where views are opt-out, even though there is no way to opt-out.
This prevents issues like the following:


where multiple view systems render the same data because they all can, even though that wasn't the intention of the logger (which merely logged a
Mesh3Darchetype in this case).Same data with this PR:
In the future, we'll want to provide ways for users to easily opt-in into multiple views.
This is already possible today by extending existing archetypes, but could definitely be more friendly using blueprints.
Checklist