DLSS-RR is kind of magic (quarter-res lighting)

Behind the pretty frames of #PRAGMATA. Breaking down many tricks and hidden gems of the renderer behind CAPCOM's RE Engine.
i hope you enjoy & find this few months worth of freetime article useful...
mamoniem.com/behind-the-p...

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

Exciting, congrats on the release!

I haven't been following along lately: is the meshlet compression topology, vertex attributes, or both?

meshoptimizer 1.1 is out!

github.com/zeux/meshopt...

Featuring two new major features, meshlet topology compression and opacity micromaps, as well as a few smaller features and improvements! More information in the infographic and release above :)

Boosts and repository stars are welcome!

Seems like a common trend!

Yep, love working with Foresight!

Nominal Connect: Shipping Realtime Desktop Software With Rust, Bevy, and egui A one year retrospective on the technology behind Nominal Connect.

A little different than my usual writing, but I've written a blog post about our usage of Bevy/egui/Rust at Nominal, the company I work at.

Give it a read! nominal.io/blog/nominal...

Avian Physics 0.6 - Joona Aalto Move-and-slide, joint motors, and BVH optimization

I just released version 0.6 of Avian, an ECS-driven physics engine for @bevy.org. #physics #gamedev

v0.6 features move-and-slide, joint motors, and an overhauled broad phase using BVHs, resulting in massively reduced overhead for scenes with a large number of colliders.
joonaa.dev/blog/12/avia...

Nanite + Reyes Let's get into the details of how this integrates with Nanite. We aren’t replacing anything Nanite already does. Nothing is changed about th...

2 more Nanite Tessellation posts are up. graphicrants.blogspot.com/2026/02/nani...,
graphicrants.blogspot.com/2026/03/vari...

GitHub - adobe/openpbr-bsdf: Adobe's reference implementation of the OpenPBR BSDF Adobe's reference implementation of the OpenPBR BSDF - adobe/openpbr-bsdf

My team just open-sourced our internal implementation of the OpenPBR BSDF from our path tracer: github.com/adobe/openpb...

Real-time Rendering with a Neural Irradiance Volume
Delivering fast inference (~1ms/frame), a tiny memory footprint (1-5MB), 10x quality gains over probe-based methods @ equivalent mem budgets, bringing neural rendering within reach of consumer hardware without RT or denoising.
arnocoomans.be/eg2026

Investigation: Bindless resources · Issue #380 · gpuweb/gpuweb Currently, in WebGPU, if a draw/dispatch call wants to use a resource, that resource must be part of a pre-baked "bind group" and then associated with the draw call inside the current render/comput...

See the sub-issues here github.com/gpuweb/gpuwe...

It's being worked on! Details are still being shaked out.

Prerequisites have starting landing in the spec and in dawn (Chrome). E.g. latest Chrome release now supports textures and samplers in let bindings (variables).

Some type of buffer reinterpreting scheme is also being debated.

So... back to the drawing board? Maybe copying what Doom DA did and cluster lights in world-space rather than any sort of RIS-based scheme.

No matter what your RIS output is, you have to write it back to the cache. You can't conditionally do that and stay correct.

So scrapping that and trying to think of other schemes, I'm basically just reinventing ReGIR (except I don't want to do ReGIR since it requires many visibility tests).

Update on bsky.app/profile/jms5...:

Turns out my code was bugged, and I never actually wrote to the cache...

Fixing that reveals that the whole scheme was wrong anyways - conditionally replacing cache cells with RIS outputs does not give an unbiased/correct output.

Only thing I'd be worried about is making shader writing _too_ accessible - I don't want people making a million pipeline variations instead of 20 uber-ish shaders.

Thank you - this is very interesting!

I know our users would love if we did this with Rust, so that people don't have to learn WGSL :P

But the basic idea of a general shader skeleton, and then allow users to compose pieces to modify inputs/outputs between stages of the skeleton seems good.

Anyone have examples of Material APIs they like in an engine, or links to good talks on this topic?

Right now Bevy materials let you reuse host code (texture/buffer bindings), but customizing the default material is essentially "go to github and copy paste the entire shader". Not very modular.

🚀 Unleash your creativity with GPU Zen 4!

📖 Dive into cutting-edge techniques from industry experts to tackle complex graphics challenges and elevate your projects.

Available now on Amazon!
📔 Standard Edition: a.co/d/0cvhJuSU
⭐️ Deluxe Edition: a.co/d/07t0MZGz

#GPUZen #GameDev

bevy/crates/bevy_solari/src/realtime/world_cache_update.wgsl at solari6-light-sampling-wc · JMS55/bevy A refreshingly simple data-driven game engine built in Rust - JMS55/bevy

Btw code (minus visibility weighing and alias table building) is open source if you want to try improving it github.com/JMS55/bevy/b...

Maybe cache the result of the 32 sample RIS in the cell and use that, so we're not doing the expensive RIS per-pixel?

Message me if you have ideas!

For GI, I don't really have a good idea of where to go next. Perhaps just ReGIR after all? I know Tom Clabault got good results tomclabault.github.io/blog/2025/re..., but it's fairly expensive.

For ReSTIR DI, I next want to try feeding the traditional froxel-based light clustering into the initial RIS. Could help with many-lights.

So yeah, total bust. I was hoping to get a good sampling distribution I could feed into ReSTIR DI, and switch the irradiance caching part of the world cache to not store DI, and do NEE per-pixel for GI instead of immediately terminating in the cache - which would massively prevent light leaks.

Final result... the cache (left) has higher variance than just brute-force 32-sample RIS (right). Complete failure :/

5a. If in cache, update weight and estimated visibility
5b. If not in cache, is visible, and contribution larger than one of the 8 lights already in the cache, replace it
6. Generate an alias table of the 8 lights and their final weights to accelerate per-pixel sampling in the rest of the renderer

1. Do RIS over 8 random lights
2. Separately, do RIS over the up to 8 cached lights
3. Combine the reservoirs of 1. and 2., capping the random reservoir's weight to 25% of the other reservoir's weight
4. Test visibility of the final sample

With just a few lights, it's not a big deal. With 441 lights like this scene, pure random sampling becomes more of a problem.

My idea is that I would extend my existing spatial world cache structure to also store the 8 best lights it has found so far, in addition to cached irradiance (DI+GI).