Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink view selection & filtering + make all views opt-in #3323

Merged
merged 13 commits into from Sep 15, 2023

Conversation

teh-cmc
Copy link
Member

@teh-cmc teh-cmc commented Sep 14, 2023

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 ViewPartSystem trait which now looks like this:

// [...]

    /// Returns the minimal set of components that the system _requires_ in order to be instantiated.
    fn required_components(&self) -> IntSet<ComponentName>;

    /// Implements a filter to heuristically determine whether or not to instantiate the system.
    ///
    /// If and when the system can be instantiated (i.e. because there is at least one entity that satisfies
    /// the minimal set of required components), this method applies an arbitrary filter to determine whether
    /// or not the system should be instantiated by default.
    ///
    /// The passed-in set of `components` corresponds to all the different component that have ever been logged
    /// on the entity path.
    ///
    /// By default, this always returns true.
    /// Override this method only if a more detailed condition is required to inform heuristics whether or not
    /// the given entity is relevant for this system.
    fn heuristic_filter(
        &self,
        _store: &re_arrow_store::DataStore,
        _ent_path: &EntityPath,
        _components: &IntSet<ComponentName>,
    ) -> bool {
        true
    }

// [...]

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:
image
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 Mesh3D archetype in this case).
Same data with this PR:
image

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

@teh-cmc teh-cmc added 📺 re_viewer affects re_viewer itself 🍏 primitives Relating to Rerun primitives labels Sep 14, 2023
@teh-cmc teh-cmc marked this pull request as ready for review September 14, 2023 10:04
@teh-cmc
Copy link
Member Author

teh-cmc commented Sep 14, 2023

Drafting: had some looong discussions about this and more with @jleibs and @Wumpf, this generally the direction we want to go int right now but we need to tweak some more things in those traits first.

@teh-cmc teh-cmc marked this pull request as draft September 14, 2023 12:56
@teh-cmc teh-cmc changed the title Make all views and view parts opt-in by checking for indicator components Rethink view selection & filtering + make all views opt-in Sep 14, 2023
@teh-cmc teh-cmc marked this pull request as ready for review September 14, 2023 16:09
Copy link
Member

@jleibs jleibs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! This is so much more clear.

crates/re_space_view_bar_chart/src/view_part_system.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>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any scenario where this needs the flexibillity from ViewContextSystem of returning Vec<IntSet<ComponentName>> instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The situation of our combined (Image, SegmentationImage, DepthImage) System is maybe one example?

Copy link
Member Author

@teh-cmc teh-cmc Sep 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should required_components just return an IntSet natively?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

crates/re_space_view_spatial/src/parts/images.rs Outdated Show resolved Hide resolved
Copy link
Member

@jleibs jleibs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meant to approve on the last review.

@Wumpf
Copy link
Member

Wumpf commented Sep 14, 2023

for the record, I skimmed it and agree: great step forward!

Comment on lines 67 to 71
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(),
Copy link
Member

@emilk emilk Sep 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not all required - only the first one is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are different sets -- any one of them is sufficient to trigger the system

@teh-cmc teh-cmc requested a review from emilk September 15, 2023 09:45
@teh-cmc
Copy link
Member Author

teh-cmc commented Sep 15, 2023

This has surfaced a completely unrelated dormant bug with the way the Box2D view handles annotation labels.
It drove me completely nuts until @Wumpf explained to me that this wasn't in fact something introduced by this PR.

I'll open a new PR for said bug, this has already scope creeped way too much.

Copy link
Member

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after a quick look, except I don't understand compatible_component_sets from its docstrng

Comment on lines +193 to +195
.iter()
.map(ToOwned::to_owned)
.collect()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

            .iter()
            .map(ToOwned::to_owned)
            .collect()

is starting to get tedious

@teh-cmc teh-cmc merged commit 3322abd into main Sep 15, 2023
20 checks passed
@teh-cmc teh-cmc deleted the cmc/view_part_filters branch September 15, 2023 10:46
Wumpf pushed a commit that referenced this pull request Sep 15, 2023
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/)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍏 primitives Relating to Rerun primitives 📺 re_viewer affects re_viewer itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants