Thanks for you insight.
I’ll look into tetrahedral mesh at some point as grid can be a limitation sometime.
Did you implemented everything from scratch (appart from Three JS) or start from existing work. Your solution use WebGPU entirely or a mix with WebGL2.
Thanks again, can’t wait to see the demo.
I found an old paper about tetrahedra probe mesh on unity I read long time ago.
You certainly already know about it, but it’s a good intro for people want to discover this subject.
I’ll move to WebGPU some day, but I’ve had some requests to keep the code in WebGL for a bit, at least 
It wasn’t an option when I started. The worst part about WebGL has been browser regressions and compilations times from complex shaders more than anything. Compute shaders will provide a performance boost and some of the new data constructs will be nice but otherwise once the texture sampling is abstracted away the fundamental path tracing logic is the same, which is the bulk of the complexity imo.
Yeah, I totally get it. I thought about doing it in a similar way, and toyed around with your codebase. I thought you did an amazing job, but the compile times, the data transformation and shader limits are all making it into a practical nightmare.
Actual raytracing (well, path tracing) is trivial by comparison. That said, I appreciate that majority of the complexity is on that end in what you created. It’s just that those other pesky bits are such an enormous pain.
I have written a few systems that run things on WebGL that don’t fit the API well, and I have more or less developed an apathetic attitude towards it. I get the end result, but you’re never fully satisfied with the solution, too many insurmountable limits.
Say I want to use this tech on WebGL - I would have to convert all geometries to textures, and atlas all textures and all that. At that point, a lot of time has passed for larger scenes and I might not even have succeeded, as there are practical limits on how big a texture can be in WebGL on a given device. Theeen, I have wait for the shaders to compile, which is likely a few seconds on lower-end device, and only then may I be able to use it. And all the while, moving data out of the GPU memory is a pain as well.
All of the points above can be addressed, but it just feels dirty at that point, workarounds on top of workarounds
I implemented visibility term into solution. That is, there is a sort of a depth map for each probe, and we use those maps to determine if a probe is visible from a given point in space or not. If it’s not visible - it doesn’t contribute. This essentially removed light leaks. At least in theory, I found that there are sampling errors because of low resolution in the map.
That said, results are still very good.
I was curious how close my solution is to “reality”, so I recreated the same scene in Blender (almost the same, minor errors due to laziness) and did a few renders at 4096 samples per pixel and the same 7 bounce light settings. Here are results, first picture is Blender Cycles render, and second is light probes in engine.
I’m really happy with how close it is already.
