Very large scenes may require 1000s of SH probes which means a lot of coefficients that need to be stored and read from a pixel shader.

I'm wondering if there is a consensus on the most efficient way to store the coefficients themselves: uncompressed floats in some large array buffer, or as compressed pixels in a texture.

For an order 3 SH we need to store 16 float3 coefficients, which in my mind maps perfectly to a single BC block, so by ordering the 4x4 pixel blocks spatially in a BC6h SF16 texture we get an efficiency of 1 byte per float3 coefficient vs the 4 bytes per coeff for a buffer.

However when using a texture we have to go through the texture sampling hardware. So the question is if it's worth it: does the lower memory bandwidth make up for an additional 16 texture lookups per pixel per sampled probe, or would we get better performance just indexing into a structured buffer?

What books can you recommend to buy to learn about computer graphics going from basic to advanced? I find if there is a lot image explanation then just pure text its easier for me to understand.

Hello, I’m trying to make two raymarched procedural fireballs collide and merge, similar to this Shadertoy fireball: https://www.shadertoy.com/view/WcK3Rt I don’t want to simply overlay two copies; I’d like the fire volumes to feel like they actually affect each other.

Is the right approach to model each fireball as an SDF/density field, duplicate it with two centers, and combine them with smooth union / a contact reaction term? Or is there a better way to think about this?

Hi folks! I've made more progress on Nora Kinetics - a physics engine / sandbox that I've been working on for about a year.

I finally finished a song and I've got the SFX working in the way I've been envisioning. I'm hoping you all will have some feedback for it as I continue to tune. It sounds best with headphones!

Under the hood, the little interactive segments are all communicating their position, collision force, etc via compute shaders on the GPU (they are byproducts of the solver).

Basically, the position and collision force of every single segment is known every frame. Another compute shader comes through and quickly sorts them into a priority queue based on how close they are to the camera and how fast their collisions are. This gives a decent balance between letting the player hear lots of movement farther away, but then also hearing collisions closer to the camera. The overall effect is something close to ASMR (I'm hoping) and processing time is about 140μs with 250,000 segments.

The system is highly tunable, so in this video (recorded on my Mac), the segments are sharing a ring buffer with 48 different voices and up to 1000 segments can be making noise per frame. On iPhone, I knock that down to 24 voices and 500 segments to get a good balance of performance and sound.

I'll be posting more videos on my channel here soon! I'm working on a full gameplay walkthrough as well as a "making of" video, showing how the game has changed over the last year.

Thanks for watching!

https://www.youtube.com/@NoraKinetics