FWIW the issue that #23713 is more subtle than something that could have been caught with more testing. It was long-standing design-level confusion over what our policy should be when rendering shadow maps. It might have even dated back to before I started contributing, not sure...
Bevy 0.19 is releasing soon, which means it's time for a blog post! jms55.github.io/posts/2026-0...
Yep! It's literally just the `many_cubes` code in the repo.
Grayscale static (essentially) in a window saying "many_cubes"
This mess is a stress test of Bevy 0.19 with 2,000,000 instances of 100,000 separate meshes. Runs at 60 FPS on my laptop.
Each of the 2M mesh instances is a separate entity. There's no special "instanced mesh" component needed; the GPU driven rendering does all the batching automatically.
A graphical frontend to Nushell in which you can drag in commands to create pipelines might be, like, the ideal form of visual programming. It might even be not terrible on a phone for “I need to format this data real quick” throwaway stuff.
Been a while since I had a good old fashioned LL vs. LR vs. PEG debate
(LR is the best, don't @ me)
Gone too long without saying this so to reiterate yet again:
• Reference counting does not prevent GC pauses; you can deallocate a lot of objects at once
• It is possible to write RC that cleans up cycles and as a user you should demand this
• Most tracing GCs are bad and you should demand better
Maybe it's just me, but it feels like, more than any project I've worked on, the Discourse around Bevy is disproportionately just incorrect.
Not sure if it's because:
* Bevy moves so fast (aside from the editor);
* Bevy is relatively niche;
* Gamedev attracts a lot of confidently incorrect people
Often times when people say "oh, there's room for X and Y to coexist", that's just wishful thinking and either X or Y ends up totally displacing the other in the end. But regarding Go and Rust, that's actually ended up being true! Definitely a nice outcome.
e.g. You do leave some performance on the table if you don't use meshlets in Bevy, but you keep the workflow artists are used to, and you still get quite good perf, though not the absolute best. UE5's philosophy is "just use Nanite"--they're all in on the high end.
Both philosophies are defensible.
I'd say Bevy has a different philosophy. Unreal achieves megaworld scale by introducing new opt-in systems (Nanite, MassEntity) that are radical overhauls, while keeping the old as the default case. Bevy tends to focus on making the default systems as fast as possible.
My goal is to make Bevy "just work" when scaling to millions of entities. You shouldn't have to use a special DOTS/MassEntity/etc. system to scale. There's just one kind of entity, and the ECS scales seamlessly from small to large.
Really excited about the performance benefits coming in Bevy for mega-worlds. With all my patches we're starting to be able to render millions of mesh instance entities with hundreds of thousands in view with just a handful of drawcalls.
🧵 I've been experimenting with caching the best lights in world space to improve NEE sampling. Inspired by ReGIR, MegaLights, and www.yiningkarlli.com/projects/cac....
hacked and adapted Bevy's existing atmosphere support in last night, re-enabled lighting, and made a few more tweaks. enjoy some sunsets #bevy
A screenshot of the Nsight profiler, showing that the GPU clustering takes 108.736 μs
The GPU clustering itself runs at about 110 μs, a speedup of 30x over Bevy 0.18 on this stress test. It automatically resizes the clusters as necessary for best performance. There are no arbitrary limits on the number of lights or clusters. The same system handles light probes and decals too.
A screenshot of Bevy's `many_lights` stress test, showing about 8,000 small colored lights
A screenshot of the Tracy profiler showing a frame of Bevy rendering at 4.22 ms
In my GPU clustering branch, which is making its way through review, Bevy 0.19 can render ~8,000 visible lights (of 100k total) at about 200 FPS on my laptop 4070. This also adds the infrastructure for particle systems to emit lights entirely from GPU without any CPU involvement at all.
These findings, combined with the general messaging of “we’re an engine made for our users and contributors, not an engine made for our own goals” (paraphrased heavily), gives me the impression that there is no plan. Godot will have the features people decide to build for themselves, or the features that lots of people ask for, on some sort of timeline. And even if you make a feature, there’s no guarantee it will get merged, even if it is highly upvoted. This doesn’t have to be a bad thing, but it does mean you can’t expect from Godot the sort of steady, planned, expected updates you can expect from a professional software company. This is a risk, and one that should not be dismissed out of hand if you’re a games company that needs to ship your game to pay the bills. Consider carefully whether or not you’re comfortable needing to review changes before taking new versions, or taking what is in the engine right now with no guarantee vague future promises will materialise, because that is the worst case scenario of this sort of development. (To be perfectly clear I am not saying this will come to pass with Godot, just that with their current structure it is very possible, and would leave you with no recourse).
I'm taking no position on the technical merits of Godot here, but I will say that this is the exact kind of thing people used to say about GCC right up until it and LLVM killed all the other compilers because they couldn't keep up.
Landed light probe falloff and blending in Bevy 0.19: github.com/bevyengine/b...
Along with parallax correction, I think that's the last of the features that are needed to make light probes really usable. Still would be nice to have in-engine baking, of course.
![8.1.6 Quadrigraphs
When writing an Autoconf macro you may occasionally need to generate special characters that are difficult to express with the standard Autoconf quoting rules. For example, you may need to output the regular expression ‘[^[]’, which matches any character other than ‘[’. This expression contains unbalanced brackets so it cannot be put easily into an M4 macro.
Additionally, there are a few m4sugar macros (such as m4_split and m4_expand) which internally use special markers in addition to the regular quoting characters. If the arguments to these macros contain the literal strings ‘-=<{(’ or ‘)}>=-’, the macros might behave incorrectly.
You can work around these problems by using one of the following quadrigraphs:
‘@<:@’
‘[’
‘@:>@’
‘]’
‘@S|@’
‘$’
‘@%:@’
‘#’
‘@{:@’
‘(’
‘@:}@’
‘)’
‘@&t@’
Expands to nothing.
Quadrigraphs are replaced at a late stage of the translation process, after m4 is run, so they do not get in the way of M4 quoting. For example, the string ‘^@<:@’, independently of its quotation, appears as ‘^[’ in the output.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:g4kfvq6qttlpqiwfzmz2o73c/bafkreif2t6o6i6yyctzvhxzvhiufiyn6uwas6mgtsnvhi3xsnbel6umoue)
8.1.6 Quadrigraphs When writing an Autoconf macro you may occasionally need to generate special characters that are difficult to express with the standard Autoconf quoting rules. For example, you may need to output the regular expression ‘[^[]’, which matches any character other than ‘[’. This expression contains unbalanced brackets so it cannot be put easily into an M4 macro. Additionally, there are a few m4sugar macros (such as m4_split and m4_expand) which internally use special markers in addition to the regular quoting characters. If the arguments to these macros contain the literal strings ‘-=<{(’ or ‘)}>=-’, the macros might behave incorrectly. You can work around these problems by using one of the following quadrigraphs: ‘@<:@’ ‘[’ ‘@:>@’ ‘]’ ‘@S|@’ ‘$’ ‘@%:@’ ‘#’ ‘@{:@’ ‘(’ ‘@:}@’ ‘)’ ‘@&t@’ Expands to nothing. Quadrigraphs are replaced at a late stage of the translation process, after m4 is run, so they do not get in the way of M4 quoting. For example, the string ‘^@<:@’, independently of its quotation, appears as ‘^[’ in the output.
TIL about Autoconf quadrigraphs and I'm screaming
My fork of Bevy Hanabi, Hanabi-Batched, has been updated to support 0.18 and has many more improvements, such as lookup textures, PBR particles, and GPU mergesort for ribbons: github.com/pcwalton/bev...
If you're looking for a way to use Hanabi on 0.18, feel free to grab it!
Bevy 0.18 is out! My main contribution to this one was portals and mirrors: github.com/bevyengine/b...
Strangest issue I've encountered in the wild when fuzzing: `vaddps xmm0,xmm0,xmm1` and `vaddps xmm0,xmm1,xmm0` are *not* the same on x86 when it comes to which NaN payload it chooses. But LLVM will reorder the arguments anyway!
Lesson learned: always canonicalize your NaNs when fuzzing.
16 different versions of glam in my Bevy project. The ecosystem *might* want to improve this a bit :)
An example of mirrors in the Bevy game engine. A low-poly fox looks at a reflection of itself in a mirror.
I dusted off an old patch and landed the infrastructure for portals and mirrors in Bevy for 0.18: github.com/bevyengine/bevy/pull/13797
This builds the Lengyel oblique clip plane technique into the engine, which is the fastest way to do the clipping necessary for mirrors to work.
A demonstration of many Bevy logo decals on a plane. Each decal has normal, metallic/roughness, and emissive maps. The plane has its own normal map.
Landed normal maps, metallic/roughness maps, and emissive maps for clustered decals in Bevy 0.18: github.com/bevyengine/b...
They compose with other decals and whatever maps are on the base material, if any. Additionally, in a custom shader you can use these textures for whatever you want.
After nine years of development, meshoptimizer has reached its first major version, 1.0!
This release focuses on improvements in clusterization and simplification as well as stabilization. Here's a release announcement with more details on past, present and future; please RT!
meshoptimizer.org/v1
Congrats!
"Analyzing the Performance of WebAssembly vs. Native Code" places a lot of the blame for the worse performance of wasm on register spills, esp. with JS engines' reserved registers. Sounds like APX could actually help by bumping the register count from 16 to 32? ar5iv.labs.arxiv.org/html/1901.09...