-
Notifications
You must be signed in to change notification settings - Fork 368
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
Project: Performant visualization of scenes with large number of entities #8233
Labels
Comments
teh-cmc
added
🚀 performance
Optimization, memory use, etc
project
Tracking issues for so-called "Projects"
labels
Nov 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Context
We want the viewer to be able to scale to scenes with large numbers of entities.
This of course means visualizing these scenes, but also ingesting them in the first place.
This is blocked on a number of specific implementation issues, but put broadly: the work the viewer has to do to layout a scene more often than not grows linearly with the number of entities present in the entire dataset.
There are only two ways to combat this:
Of course in many cases, option 1 isn't even an option: if the user wants to visualize all entities in the scene, then somehow we have to make that fast.
Incremental caching of aggregated data (which is what the visualizers work with) is very hard, but will be a must in order to reach our performance goals.
This issue is not about:
Measurable end goals
Air Traffic example (
2h
dataset)TODO(cmc): What should we do about plotting? Is plotting 10k lines on a single plot really an important use case? If so, do we need to bring egui issues into this?
Revy
Revy was infamously bottlenecked by the performance of many entities (game scenes have a lot of them).
This is a good opportunity to revive that project, if we can make it happen.
Relevant material
Writings:
PRs:
Areas that need significant improvements
DataQueryResultTree
#8340 determining which entities participate in each view (query_results
)spawn_heuristic_space_views
)Wherever we don't do something obviously silly, we should strive to go with a retained/cached approach in order to get more scalable and robust against the per-frame regressions in trivially looking (== static frame) scenarios
If this is structurally hard, revisit structure!
The text was updated successfully, but these errors were encountered: