-
Notifications
You must be signed in to change notification settings - Fork 373
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
Conversation
f6b2448
to
2aa04d8
Compare
There was a problem hiding this 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_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.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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.
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.
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.
There was a problem hiding this comment.
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
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. |
There was a problem hiding this 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
.iter() | ||
.map(ToOwned::to_owned) | ||
.collect() |
There was a problem hiding this comment.
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
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
ViewPartSystem
trait 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
Mesh3D
archetype 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