Add live visualization for behavior trees - #58
Conversation
Sollimann
left a comment
There was a problem hiding this comment.
Will try to find some time to review during the weekend. Its a big PR, so I'll have to do it batches. I pinged a few other reviewers as well
kaphula
left a comment
There was a problem hiding this comment.
I can't participate at this time. Thanks.
| <title>bonsai-bt visualizer</title> | ||
| <script src="https://d3js.org/d3.v7.min.js"></script> |
There was a problem hiding this comment.
This might not be a problem, but this grabs d3.js from a CDN which means the visualizer server requires egress (internet access) or else you'll get a 404.
I think one way around it is by downloading the file locally and referencing following way
pub const VISUALIZER_D3: &str = include_str!("d3.v7.min.js");
There was a problem hiding this comment.
I guess its fine for now, but might be something we need to address in future if someone complains
|
@Sollimann I will address all PR comments once you've had the time to go through it all as the first pass. Let me know. In the meantime, I saw you comment here, and whipped up some changes to the html file, shall I push? Any refinements to the UI/color scheme/etc? #55 (comment) Recording.2026-05-09.002941.mp4 |
|
Very cool, looks great! Yes, please push changes👍 how does the color animations look e.g if ticks run at 20Hz? Also, is the animations able to keep up at that rate? Will try to take do a second wave of reviews later today. |
|
Will push in a second! Attaching what it looks like for 20Hz - it is able to keep up (although I doubt the human looking at it will be able to make sense of it haha). I also cranked it up all the way to 100Hz, where I change tree status every tick. Framework is able to handle the load no problem 👍 Recording.2026-05-10.150150.mp4 |
Sollimann
left a comment
There was a problem hiding this comment.
Added a few more comments. General opinion is that implementation looks solid and test coverage is good 👍 I think you need to rebase as there has been a change to main today, also you need to install and run pre-commit
Let me know when you have addressed comments, and I'll take another look
| /// Like [`with_telemetry`](Self::with_telemetry), but lets you pick the | ||
| /// bind address. Pass `"0.0.0.0"` to listen on every interface (so peers | ||
| /// on the LAN can connect), `"127.0.0.1"` for loopback only, or any | ||
| /// specific interface IP. The address is parsed by `TcpListener::bind`, | ||
| /// so hostnames and IPv6 literals (e.g. `"::1"`) also work. | ||
| /// |
There was a problem hiding this comment.
localhost debug server is fine for most cases. Debugging on a separate machine can be achieved with ssh port portwarding 👍
|
@Sollimann I addressed all the comments, rebased onto main, and builds are passing now. |
There was a problem hiding this comment.
Its getting closer now 🚀 I just noticed a couple of things when doing a final round of reviews. Please take a look
Also, once merged, to get some publicity around your latest enhancement of the crate you can post an announcement in following subreddits Rust, rust_gamedev, robotics, gamedev etc - include the gif. Up to you, but I think people will be excited to see this :)
| use Behavior::*; | ||
| match b { | ||
| Action(a) => ("Action", Some(format!("{a:?}"))), | ||
| Wait(t) => ("Wait", Some(format!("Wait({t:.2}s)"))), |
There was a problem hiding this comment.
not for this PR, just pointing out for future
if you're up for the task, I think this porting Wait to take in std::time::Duration instead of seconds in float is something we should #52
There was a problem hiding this comment.
Hmm. While the actual fix is non-trivial, it may break backwards compatibility, how do you feel about that?
Wither way I might address in future PR.
There was a problem hiding this comment.
yes, the fix is non-trivial. Its not great introducing breaking changes, but the sooner the better. Also, if any wants to use this crate for production scenarios having Wait only accept seconds in floating point is not a great interface I think. I'll have to look at the implementation to fully jugde whether we want to publish it or not
Do you have a template you generally follow for bonsai announcements? Also, what about tagging new release/pushing to crates.io, etc. ? |
Nope, no template. Just explain the new feature and link to the repo on second question - I'll make sure to release it now right after merge |
Sollimann
left a comment
There was a problem hiding this comment.
Fix looks good. Great work on this one! 🚀 I'll make sure to publish it
Live web visualizer: Attach via
BT::with_telemetry(port)(default 127.0.0.1) orBT::with_telemetry_at(addr, port)— opens an embedded HTML page athttp://{addr}:{port}/that renders the tree over a WebSocket. Rationale for choosing websockets, along with advantages I wrote here: Add view/read only graphical interface for inspecting tree state in real-time #55 (comment)Zero-overhead when off: Whole feature is hidden behind
visualizeTo see a live demo:
cargo run --bin visualizer_smokehttp://127.0.0.1:8910/I also added a whole bunch of tests for prevent regression. Also, a huge chunk of this PR is me adding a tracer to all bt nodes. While there is graphviz and json serialization support, without an actual tracer it would be impossible to know the live state of each node (running/pass/fail/idle) at every tick. Existing code only gave static structure of the tree, not the live state of the entire tree along with every single node's status at each tick.
Disclaimer: Used claude code to generate documentation and the unit tests.
Recording.2026-05-07.223944.mp4