Given that Bevy’s systems scheduler is nondeterministic (for everything not explicitly ordered), do you foresee issues coming from that? Or does this approach sidestep that as an issue?
Revy is frame-based: it runs as the last system at the end of the frame, with exclusive access to the `World`, and synchronizes the state of the Bevy database with the state of the Rerun database at that point in time (it keeps track of 3 timelines during that process: the wall-clock time given by the OS, and the frame number and simulation time given by Bevy itself).
So non-deterministic scheduling is just not an issue by default.
You could of course access the Revy logger from any system (it's just a `Resource` after all) and log arbitrary data to Rerun from there (the resource is basically a handle to the Rerun SDK).
This still wouldn't be a problem. The data would once again be logged to the 3 same timelines (wall-clock, frame number and sim_time) and you would be able to visualize in which order the different systems doing the logging were scheduled during each frame.
Basing the recording off it's 24.6s runtime and 3.58MB download size it comes out about 145KB/s which is honestly really decent.
What format is it stored as (eg protobuf etc?) Is Rerun doing compression on the "raw" game data to achieve that?
Also had a good laugh at the cranky job in bacon.toml, might steal that :D
I also noticed the elements in the recording were all clickable, is that a Rerun feature, and did you have to manually reconstruct all the Bevy elements in a Rerun specific format?
Just curious how long this took you to make?
Super cool demo btw :) do you have more demos/PoC/examples listed somewhere I could peruse? Cheers
EDIT: Can your twitter post this so I can retweet :D
As mentioned in the README, Revy is not meant to be a polished / properly maintained project -- it's just a proof-of-concept.
I've talked more about how and why it came to exist in the first place in this thread [1], if you're interested.
That being said, I do intend to publish updates when new versions of either Rerun or Bevy land; if only to experiment with new APIs as they come online.
Now, to answer your question, I've been using Bevy since the 0.1 release and, in my experience, keeping up with the changes upstream has always been pretty painless.
Their organization nand release process is top-notch, with some of the most high quality changelogs and migration guides I've ever seen in any project, and releases are rare enough (~about once a quarter) to just not be an issue.
The community maintains compatibility matrices such as this one [2], and things generally just work :tm:.