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!

Hey #bevy :D It's time for your weekly #bevymergetrain, where I go over the community-reviewed #opensource PRs for the #rustlang game engine that I help maintain! Somehow, there's already 24 PRs in our backlog today: github.com/bevyengin...#bevy#bevymergetrain,#opensource#rustlangll we merge the PR, or request changes? Follow along!

Bevy really feels like it's reached a milestone where you don't have to do engine work anymore to ship something. (And I'm ridiculously excited to reveal what that "something" is, but it's gotta wait...)

One thing I've always wondered is why GCC reports undeclared identifiers only once per function. It's done this for a very long time: I remember the "Each undeclared identifier is reported only once..." message on NeXT!

I’d love it if iSH had a built-in Wayland server that exposed Stage Manager multi-window support on the iPad. It’d probably solve a good 75% of my “why is it so hard to do X random thing on iOS” problems.

Idea I have no time to implement: A RISC-V emulator for iOS, using a single jump table for every 16-bit compressed instruction. Would probably be a lot faster than iSH. 16 bits is small enough that you could inline every single instruction. (I know not all insns are compressed, but most are.)

Looking through old photos and I found this one of a whiteboard in Mozilla offices from Nov 2011. IIRC I was explaining early borrow checker designs to @dherman.dev and @pcwalton.bsky.social.

The fundamental reason I'm bullish on Rust in game dev doesn't have anything to do with (lack of) GC, or memory safety -- it's the way aliasable-xor-mutable makes it easy to multithread your game logic. Updating game objects *should* be embarrassingly parallel... 1/2

The most disqualifying thing about Zig is the semantics around aggregate assignment. github.com/ziglang/zig/... For performance, sometimes Zig doesn't copy structs on the stack, so refactoring to introduce temporaries can cause Zig to just miscompile code. It happens a lot and still isn't fixed.

And they say that comptime is better than generics.