Have you considered using a game engine (e.g. Bevy)?

[matthieu-foucault]

Since A/B Street is often described as a game, why not use a game engine?

When this project started, it looks like the rust ecosystem was in its infancy so a lot had to be written from scratch. Now, Bevy is an extremely popular project with a constantly growing community. I played with it a bit when starting to learn Rust, and it was very easy to use.

It would mean you wouldn't have to maintain a lot of the widgetry code, things such as "Embedding a second view of the map canvas" would be straightforward instead of advanced, and libraries such as bevy_egui would make it easy to add UI elements (e.g. for tutorials).

You may also be able to find new contributors in the bevy community.

I'm sure porting the code over is a significant lift, but I'd be happy to try making a small prototype if that's a direction you'd be interested in exploring.

[dabreegster]

It's definitely something I've considered. As I'm sure @michaelkirk would agree, working on widgetry has taken lots of effort. There are very basic things widgetry can't do right now (like... typing underscores in text boxes?!) that I have no particular interest in spending my time on. I totally agree more contributors would be attracted to the project.

I don't have any time myself to explore this direction, but if you're interested, I'd absolutely love to see a prototype of part of A/B Street using Bevy! I don't know how big a scope you'd want to look at, but going by app, fifteen_min or osm_viewer is probably the simplest. Being able to load and render a map_model::Map and interact with buildings, lanes, intersections, etc would be a start. It could also be interesting to see what santa would look like ported to an actual game engine. :)

I don't know anything about Bevy, so I'm curious if/how it handles things like:

• loading large files on native and web. Does it have loading screens and progress indicators? Does it have some trick to avoid the expensive serde deserialize step and not lock up the main UI thread?
• expressing a set of static objects on a moveable 2D slippy map/canvas, with easy ways to draw in hovered/selected states, click on objects, etc? (ie, what Refactor map-space objects #763 has started to refactor)

Let me know if you'd like to chat more about this idea, or about first steps to take

[dabreegster]

Another thought: Bevy and the ECS idea more generally could apply potentially to many aspects of A/B Street. The traffic simulation is a whole other mess. I would be personally much more interested in the UI aspect -- how an end-to-end app not involving the traffic sim (ie, the 15-minute or LTN tool) would look using Bevy.

[matthieu-foucault]

loading large files on native and web.

Using the AssetServer or the bevy_asset_loader plugin you can load files in the background and track progress. With the bevy_common_assets plugin, you can load assets using serde.

expressing a set of static objects on a moveable 2D slippy map/canvas, with easy ways to draw in hovered/selected states, click on objects, etc?

If I understand ECS correctly, the selection handling would be a System, and selectable entities would have a "Selectable" component.
For picking the 2d meshes, looks like bevy_mod_picking can help us.

Let me know if you'd like to chat more about this idea, or about first steps to take

I'll see if I can get something started, and keep you in the loop either here or in a draft PR.

[dabreegster]

An example of an amazing benefit of leveraging the Bevy ecosystem would be something like https://johanhelsing.studio/posts/cargo-space-devlog-1. Hooking up to inspector-egui and fiddling around with parameters without recompiling would be a game-changer. I've been doing lots of recent experiments with WASM and using Leaflet or Maplibre for rendering, partly to speed up the compilation cycle and partly to trivially add bits of UI interaction.