Can't believe it's 2026 and we're having to disable GPU occlusion culling on flagship Google phones due to driver bugs. Pretty ridiculous. github.com/bevyengine/b...

Vim digraphs are the most convenient general purpose IME I've seen. I wish they worked in all apps!

Bevy 0.19 is releasing soon, which means it's time for a blog post! jms55.github.io/posts/2026-0...

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.

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

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.

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.

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 :)

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.

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

"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...

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 :(

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.)

Interesting 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.

Project that'd be fun but that I have no time for: Compile and run native code on-device on iOS by running macOS (or Windows?) interpreted in a VM on-device, and have the VM talk to the iOS device via a tiny device ($5 microcontroller?) you plug into the USB port that loops the USB back.

I noticed that x86 APX has a prefix that allows for 3-operand insns (e.g. add rax,rbx,rcx instead of mov rax,rbx; add rax,rcx). I wonder what the advantage of that over the 2 instruction pair is? Couldn't the CPU fuse the latter instruction pair into effectively a 3-operand insn?

OK, the way Clippy told me to replace cos(pi / 4) with the FRAC_1_SQRT_2 constant is wild. Clippy is becoming self-aware.

Bevy 0.17! I only have minor improvements in this one, because my engine-level work has been focused on VFX instead of Bevy proper, but the improvements everyone has contributed to this have been awesome to see!

OK, I love this. tl;dr using knowledge of your allocator, speed up linked list traversal by adding a branch that guesses where the next linked list element is and pre-populates the "next" variable to eliminate stalls if the allocations are well-behaved.

Wrote up how Unity's "Freeform Stretching" and "Rotate With Stretch" features work so that the next person who wants to run them on GPU doesn't end up pulling their hair out: gist.github.com/pcwalton/ff7...

Just reverse engineered Unity's "Freeform Stretching" and "Rotate With Stretch" particle system features. Never had a problem devolve into "write down as many random observations as I can until I get down to 2 equations with 2 unknowns and can solve for the result" before, but sometimes it works!

RTX in Bevy!

Well, that was certainly a bug. Problem: Hanabi particles are too fast. I store direction and magnitude separately, but direction wasn't being normalized. Hmm. Bug in my normalization code? No, it looks right... 1/

I made my temporary fork of Bevy Hanabi more concrete. It's now called Hanabi-Batched: github.com/pcwalton/bev... This is a temporary fork that provides much better performance in real-life scenarios, making the difference between a shippable game and not in most cases.

Also true for Rust.

With the GPU-driven rendering work I did earlier this year and the Hanabi VFX work I'm doing now, Bevy is consistently hitting 120 FPS for me. Looks really nice on a high refresh rate display. Building a GPU-driven renderer is a ton of work, but the results *really* pay off.

Just pushed a branch of Hanabi, the GPU VFX system for #bevyengine, with a significant overhaul of the way scheduling works: github.com/pcwalton/bev... In my tests, I can now have 500+ different particle *systems*, each with many particles, on screen at once and still hit 120 FPS.

Asking ChatGPT "what is two-phase occlusion culling?" and it confidently gives the wrong answer, saying that it involves artists placing occluders manually, when a huge draw of 2-phase is that it *doesn't* require artists to do that.

It's hilarious to me that ChatGPT can now write decent Rust, but it's completely useless at doing anything but the most basic operations in ImageMagick. ImageMagick is objectively more difficult than the borrow checker

Always resist the temptation to store extra data alongside indirect draw parameters. It may seem convenient now, but you will want to support multidraw indirect eventually and then you will have to redo all your bind group management and you will hate yourself.

peekable() is nice for iterators, but usually what I really want is pushbackable(). i.e. let me use the equivalent of ungetc(), to push back a single element.

Current status: Debugging a race condition in which the easiest way to repro is "put my laptop to sleep, stick it in a bag for at least 10 minutes, turn it on without A/C power, and then start the program".

wrote about some of the work i've done in the past year and what i'm hoping to accomplish next year in bevy! ✨ www.charlotte.fyi/posts/bevys-...

What's the origin of the name "rib" for a lexical environment? I believe it's Scheme, based on finding the name inside some Chez Scheme source in Racket and googling bringing up www.khoury.northeastern.edu/home/will/Tw... -- but I'm not sure *why* Scheme chose that name.

In WGSL: * There is neither ternary operator nor expression if/else. Strike 1. * The replacement, select(), evaluates eagerly. Strike 2. * select() arguments are in the *opposite* order of the ternary. Yes, that means the else branch precedes the if branch. Strike 3, you're out.

Every `EXPRS ::== EXPR | EXPRS ',' EXPR` production in any language ever should be considered a bug. Trailing commas should be allowed everywhere!