No question, just want to say thanks! I've had a lot of false starts trying game tutorials but the ones I found for Bevy were really easy to follow. I was working two versions behind and the changelog for Bevy was so well done that I was able to figure out most of what changed. Bevy was also just straightforward to use.
I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4
Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality.
For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages.
Hi, I'm the author of both the Solari (Lumen) and Meshlet (Nanite) PRs, and I'm happy to see interest in them! To expand on pcwalton's answer:
Solari is _extremely_ experimental. I'm basically entirely scrapping my previous version[1] based on Radiance Cascades[2], and starting over with ReSTIR[3] techniques. Don't expect it anytime soon, but I'm definitely having fun working on it! The real technical blockers to Solari is that wgpu, our graphics library, does not have upstreamed raytracing support. I've been using a semi-buggy fork[4], but we'll need to get it merged before Bevy can merge any Solari code.
Meshlets (no cool product name like Solari) on the other hand are much less experimental. I already have a very functional and fairly fast GPU-driven renderer based on meshlets implemented, and mostly reviewed, and it should hopefully get merged into Bevy's main branch within a few weeks. Check the meshlet section of the "What Comes Next" section at the bottom of this post to see an image. I'm planning to do a livestreamed review session to get the PR pushed through since it's such a complex PR (thousands of lines). However, what I have so far is just the basics. Memory usage is a big issue, and lack of hierarchical LODs (the main selling point of Nanite) are not yet implemented. Further more, I'd really like to have both mesh shaders (for large triangles), and software raster (for small triangles) implemented to improve the visibility buffer raster speed. Mesh shaders are sadly not supported in wgpu, nor has anyone started a fork to implement them. For software raster, we need support for 64bit integers and texture atomics in wgpu, but that's something we're working on[5].
So yeah, lots of experimental work that's going to take a while to be production-ready and available to users, part of which will need to be working with wgpu to implement more modern features, as wgpu's current priorities are understandably focused on the WebGPU spec, which lacks the newer features from 2020+ that started shipping in the last 2-3 GPU generations. I'm having a lot of fun though, and making good progress!
The blog post directly mentions efforts towards a GUI-based editor in the "What's next" section.
We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
Just to clarify, irradiance volumes (and other forms of GI added this release like lightmaps and reflection probes) are statically baked ahead of time, meaning they'll start showing incorrect lighting as you move objects and light sources around. They take time to bake (slowing down development iteration), and limit how much you can do with them / need careful usage and placement, but are widely supported, and give great results for very cheap runtime costs.
Lumen is a fully _dynamic_ GI system. No slow offline baking, and much more flexible (and therefore realistic) lighting, especially reflections. The downside is it's much, much slower (but still barely fast enough to be realtime 60fps), and requires a semi-recent graphics card that support hardware-accelerated raytracing.
As for whether meshlets or realtime dynamic GI is harder, well, I'd probably lean towards GI right now. I haven't yet started the (very complex) LOD building system for meshlets though, so maybe I'll change my mind in the future :)
I can't help but feel that between events and commands, and especially with all the parallelism, there's no clean, powerful solution to manage all manner of inter-system interactions. Having .before(), .after(), .chain(), different schedules and whatnot is great, but I think there's something lacking in the model to round it all out. Granted, I'm a novice in these matters and I understand that concurrency brings many hard problems. Could you spare your thoughts on the matter? Thanks!
Pretty straightforward process / I just made it up. Throw some olive oil in an Instant Pot, add beef and sear (no need to fully cook, just brown it), add ~4 cups of water and ~2 cups of lentils (I eyeball these), throw in chopped onions / bell peppers / mushrooms / garlic, add spices (plenty of turmeric + generic store bought "curry powder", garlic powder, dill, cayenne pepper, salt), and the secret ingredient: ~1/2 cup of smooth peanut butter (trust me this is very important ... when in doubt add more).
(edit: I keep the Saute setting on while im adding ingredients and occasionally stir. Then I seal it up, turn on the "bean chill" mode on high. And wait 40 minutes for tasty goodness)
Core pillars (including WIP things like Scene, UI, Editor, Audio) are in place. Partial or full engine stability (see my "partial stabilization discussion: https://github.com/bevyengine/bevy/discussions/9789). More than a few fully released quality games. More than a few fully released quality non-games / tools (we're already seeing Bevy being used as a foundation for things like CAD software and modeling tools).
Any idea why the example image in the OP link appears to be running at sub-optimal framerate?
What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)?
Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
I would say that the systems in the ECS _are_ the game loop. The ECS overhead per frame is kind of hard to measure / it depends on the scale of usage. To establish the scale of operations: Random single-entity ECS data accesses are a sparse array lookup to find the table the entity is in, and then an array lookup to find the component in the table. Iterating components in a query is roughly the same as iterating an array / is very cache friendly. Running individual systems is _slightly_ more expensive than a function call. Scheduling systems in parallel does introduce some overhead (which is currently higher than we'd like / we're working on optimizing it), but when you pay that cost you get the benefits of everything running in parallel.
There is still a game loop that runs every tick. The engine wouldn't work so well if we only responded to inputs as they come in, event pub-sub style.
As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
> Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
How do you plan to have stuff moving then? You need to update their position every frame, so...