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.
03.03.2026 02:49 β π 16 π 0 π¬ 1 π 0
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.
25.02.2026 16:57 β π 1 π 0 π¬ 1 π 0My 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.
23.02.2026 22:28 β π 43 π 0 π¬ 0 π 0Really 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.
23.02.2026 22:26 β π 91 π 7 π¬ 2 π 0
𧡠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....
19.02.2026 02:13 β π 47 π 7 π¬ 1 π 1hacked and adapted Bevy's existing atmosphere support in last night, re-enabled lighting, and made a few more tweaks. enjoy some sunsets #bevy
11.02.2026 20:17 β π 66 π 7 π¬ 3 π 2
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.
09.02.2026 22:18 β π 12 π 0 π¬ 0 π 0
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.
09.02.2026 22:14 β π 78 π 6 π¬ 1 π 0
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.
07.02.2026 03:29 β π 28 π 1 π¬ 1 π 0
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@jpeg)
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
03.02.2026 00:42 β π 69 π 13 π¬ 6 π 1
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...
13.01.2026 21:49 β π 71 π 6 π¬ 0 π 0
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 :)
19.12.2025 01:32 β π 25 π 3 π¬ 3 π 0
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!
09.12.2025 04:54 β π 0 π 0 π¬ 0 π 0
"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...
08.12.2025 00:55 β π 18 π 1 π¬ 0 π 0
Seriously considering putting a bounty on x86-64 support for copy.sh/v86: github.com/copy/v86/iss...
A proper modern JITting emulator on the Web platform (including non-jailbroken iOS) would be amazing! I'm amazed how fast the jitcode can be, even with softmmu.
Noooo, even with APX the DIV and IDIV instructions are hardwired to rdx:rax :(
14.11.2025 00:34 β π 4 π 0 π¬ 1 π 0Note that these instructions by themselves won't enable fast emulation without the virtual memory proposal.
08.11.2025 01:38 β π 4 π 0 π¬ 0 π 0
I filed an issue on what I think the minimum set of instructions that wasm needs to efficiently implement JITs of systems with MMUs is: try-load and try-store. github.com/WebAssembly/... Interested in feedback.
(From what I see, this would enable fast emulation on non-jailbroken iOS.)
Yeah, I looked it over. I filed a couple of issues to add things that v86 would need: github.com/WebAssembly/... and github.com/WebAssembly/...
07.11.2025 18:36 β π 1 π 0 π¬ 0 π 0
Well, I guess nommu doesn't help that much when you still need to invalidate jitcode. You're paying most of the cost of a TLB in that case...
Wish wasm had better support for setting page permissions and catching faults.
By the way, the built-in benchmark on the Arch distro there reports 1GHz Pentium III performance for integer ops on my M4 iPad Pro, which really isn't too bad for softmmu wasm.
06.11.2025 21:59 β π 4 π 0 π¬ 1 π 0Interesting that having to emulate paging via softmmu and 80-bit x87 floats are what kills copy.sh/v86 wasm-based JIT performance. I wonder how fast you could go with MMU-less RISC-V Linux? Could be nice for non-jailbroken iOS.
06.11.2025 21:57 β π 9 π 1 π¬ 1 π 0
