-
Notifications
You must be signed in to change notification settings - Fork 24
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
Timeline #157
Timeline #157
Conversation
if self.steps_forward > 0 { | ||
self.steps_forward -= 1; | ||
} |
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 wasn't completely sure why steps forward was decremented down here rather than up above with the rest of the step forward logic. Should I decrement steps_backward
down here as well?
I'm also curious under what circumstances steps_forward
is greater than 1?
let mut delta = (self.physics_time - t).min(Duration::from_millis(16)); | ||
|
||
// Find the difference between current time and snapshot time, with a max value of 16 | ||
// TODO: Why 16? The tick length is 16.66 miliseconds. Maybe that's it? |
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.
Wasn't sure about this, but I want to document it while I'm here.
// TODO: Unsure what this is for | ||
// TODO: More magic numbers | ||
if delta > Duration::from_millis(3) { | ||
delta -= Duration::from_millis(1); | ||
} |
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 also want to document this
pub fn snapshot_count(&self) -> usize { | ||
self.snapshots.len() | ||
} | ||
|
||
pub fn snapshot_index(&self) -> usize { | ||
(self.snapshot.as_ref().map_or(0.0, |s| s.time) / PHYSICS_TICK_LENGTH).round() as usize | ||
} |
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 exposed for the UI
@@ -60,9 +60,10 @@ impl yew_agent::Worker for SimAgent { | |||
self.link.respond(who, Response::Snapshot { snapshot }); | |||
} | |||
Request::Snapshot { ticks, nonce } => { | |||
if self.errored { | |||
if self.errored || self.sim().status() != Status::Running { |
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.
This keeps responding with snapshots after the end of the simulation if we don't guard against it.
pending_snapshots: VecDeque<Snapshot>, | ||
snapshots: Vec<Snapshot>, |
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.
We no longer need this to be a Deque. I was able to shave off 19% of used memory in a benchmark with this change.
…particles weren't rendering and sim was running at half speed
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.
Could you squash together the commits and mark the PR as non-draft? Then I can merge.
@rlane Alright you're good to go. You can squash the commits through github's UI ![]() |
Merged, thanks! |
Summary
The intent is to help users debug by allowing them to move both forward and backward through simulations. Users can currently only move forward.
New
Screen.Recording.2024-12-21.at.10.13.38.PM.mov
Memory impact
This change causes the system to cache all snapshots, where previously snapshots were loaded as needed and unloaded as soon as they were rendered. Running the Planetary Defense scenario with the default solution, 178MB are used when snapshots are cached, and 38MB is used without caching as in status quo.