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

viewer: double clicking an entity in the blueprint should put it into focus #917

Closed
teh-cmc opened this issue Jan 25, 2023 · 2 comments · Fixed by #4799
Closed

viewer: double clicking an entity in the blueprint should put it into focus #917

teh-cmc opened this issue Jan 25, 2023 · 2 comments · Fixed by #4799
Assignees
Labels
📺 re_viewer affects re_viewer itself

Comments

@teh-cmc
Copy link
Member

teh-cmc commented Jan 25, 2023

(Following a standup discussion)

For spatial entities, double-clicking on their name in the blueprint should:

  1. make their centroid the focus of the orbit camera
  2. zoom out the camera so that the entire entity can fit on screen

Both can be achieved relatively easily by computing bounding spheres (e.g. here's how Bevy's scene_viewer handles this), though this might lead to potentially undesirable edge cases in some very specific scenarios (very oddly shaped meshes, point clouds with extreme outliers, etc).

Future work

Possible future work mentioned during the discussion:

  • Could offer a way for end-users to specify custom centroids/focus-points and optimal zoom-out distances using e.g. dedicated components
@Wumpf
Copy link
Member

Wumpf commented Jan 25, 2023

the note on bevy is nice but handles only meshes and we do already have bounding volumes for meshes. everything else is the issue, some of which we create visualizations on the fly (e.g. a transform should be shown as 3 arrows)

@Wumpf
Copy link
Member

Wumpf commented Jan 25, 2023

Note that once we do this properly, bounding_box on SpatialScene should consider building itself up from the same bounding primitives instead of going through all rendering primitives (which in the future might not be freely traversable as they may reside in write-only gpu memory; plus we might add stuff that isn't logged data which shouldn't be in the scene bounding box)

@Wumpf Wumpf self-assigned this Jan 9, 2024
Wumpf added a commit that referenced this issue Jan 16, 2024
…in 3D space views (#4799)

### What

* Fixes #918
* Fixes #917

This PR introduces on-the-fly determined per-entity bounding boxes and
unifies a lot of behavior under the hood: A double click of a hovered
item (pretty much everywhere) causes now a "focused" event for that
item. Focuses are right now set on the viewer context for a single
frame, so each part of the viewer can react on it as it pleases. The 3D
Space view reacts by focusing the camera on the entity (using the new
bounding box) and tracks cameras.
Tracking of entities has been unified - originally this PR tracked
entities as well, but I found this a bit too confusing for this action,
we should instead have something more explicit (this was disabled in
86ddf0d so it's easy to get it back).


https://github.com/rerun-io/rerun/assets/1220815/b6077865-d500-4bc9-b112-8ff41b370fe0



Tradeoffs:
* can't focus on instances
-> before focused on 3D positions (without knowing anything about the
object under it) now focusing on entities; different behavior,
_sometimes_ worse, sometimes better
-> note that tracking an instance rarely what you want here (e.g. point
instance ids vary widely)
* tracking an entity is not always what you want -> disabled it
* it's very hard to tell that we're tracking something, can sometimes be
surprising
* Alternative design of `focus`: Send a focus event to space views that
should be interested in it. This makes would unify the dispatching code
for this which is nicer going forward. But for the moment it was just a
lot easier to implement it the way I did. I'm fairly sure though about
making focus not sticky in the global state since this way we'd end up
with two levels of selection.



### 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 the web demo (if applicable):
* Using newly built examples:
[app.rerun.io](https://app.rerun.io/pr/4799/index.html)
* Using examples from latest `main` build:
[app.rerun.io](https://app.rerun.io/pr/4799/index.html?manifest_url=https://app.rerun.io/version/main/examples_manifest.json)
* Using full set of examples from `nightly` build:
[app.rerun.io](https://app.rerun.io/pr/4799/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json)
* [x] The PR title and labels are set such as to maximize their
usefulness for the next release's CHANGELOG

- [PR Build Summary](https://build.rerun.io/pr/4799)
- [Docs
preview](https://rerun.io/preview/7183423673682ce3d9c0c68fcb335689b8c13693/docs)
<!--DOCS-PREVIEW-->
- [Examples
preview](https://rerun.io/preview/7183423673682ce3d9c0c68fcb335689b8c13693/examples)
<!--EXAMPLES-PREVIEW-->
- [Recent benchmark results](https://build.rerun.io/graphs/crates.html)
- [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📺 re_viewer affects re_viewer itself
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants