Real time diffuse global illumination for static geometry in Wgpu
v.redd.it/36pt0mupkpo51
v.redd.itPosted Sep 22, 2020, 2:23 PM UTC
22117
v.redd.itImpressive work! I also found that wgpu is really easy to use, like vulkan it is very expressive in what you want to do, but it has almost none of the drawbacks that vulkan has from a convenience standpoint. Just a very sweet spot in between GL and vulkan.
Are you planning to open source your implementation?
15
Sorry, I'm not releasing the code. In my head this is becoming a larger engine, but for now it is very much in its infancy, and I'm not very confident in open sourcing it yet
10
Nice!!
2
Awesome work!
2
Really impressive, nice work!
2
That looks amazing! I've not had a proper look at wgpu yet, but will definitely do so.
1
This looks absolutely beautiful!
1
I wanted to share this article https://twitter.com/_AlecJacobson/status/1308546141760430080, since you mention compressing a big bunch of data for rendering. It's quite out there, but imagine training an overfitted neural net live instead of exporting a giant amount of probe data and compressing it after the fact.
1
I just finished implementing this technique as my first real project in Rust, and I've had a lot of fun!
The technique itself is this (Real-time Global Illumination by Precomputed Local Reconstruction from Sparse Radiance Probes), which got featured in this Two Minute Paper episode three years ago; when I was looking for something graphics related to test the Rust ecosystem with, this seemed like the perfect choice, and it turned out to also be a great learning experience.
The algorithm works by precomputing a radiance transport operator in the form of sparse probes and receivers' reconstruction vectors, by making heavy use of the spherical harmonics lighting representation;
all this data, which uncompressed measures several GBs, is then compressed using Clustered Principal Component Analysis (CPCA) down to less than 100MB.
At runtime, a bounce of indirect lighting is computed each frame, by relighting the probes using direct lighting information + the irradiance of the last frame (which effectively yealds practically infinite bounces), and using them to reconstruct local irradiance to be used for lighting the scene. It's also possible to extend the algorithm to account for glossy surfaces with a minimal performance loss - I will probably look into that next.
This simple scene was rendered using:
As far as performance, I am very pleased to see comparable results to what the paper shows: with those settings the Cornell Box takes just about 2.5 ms of GPU time with fully dynamic lights on a GTX 1660Ti.
Oh and about Wgpu... Wow! Coming from OpenGL and having a tiiiny bit of Vulkan experience, I must say that Wgpu is incredibly easier than even GL while being extremely powerful. It sure feels nice not having to worry about synchronization or memory pools!
I have never touched OGL directly, is it that bad?
I wouldn't say it's bad as in difficult, but I also wouldn't recommend it anymore for a first graphics API either, it's just too messy imho.
Rather, webgpu takes the cake for me as an excellent starting point, and if you ever need or want more control, I'd just go with Vulkan.
The only gripe I have with current wgpu is its odd lack for tessellation shaders; I can see why geometry shaders need to go, but why tessellation?
Because it's not the future. Mesh shaders FTW!
Do you know good learning resources for someone wanting to learn graphics programming with WebGPU (as a complete beginner in gfx). Most people seems to recommend learning OpenGL first because learning material is abundant, but it feels like “learn C before Rust because the underlying concepts are the same”…
I'd recommend this excellent site at first. After reading through the beginner section you'll have understood the core mechanics of webgpu, and after that everything becomes very intuitive. For example, you'll learn that, to render something, a RenderPass needs a RenderPipeline, which needs (among other things) shader modules and a PipelineLayout, which needs BindGroupLayouts, and so on. Basically you can't forget a step, which is instead a very real problem in OpenGL, which is a big state machine.
At this point, I think every resource on computer graphics will be appropriate, for example for techniques such as shadow mapping, etc.
The only real challenge would be GLSL, for which there probably aren't many non-OpenGL related resources.
I wouldn't say it's bad, just old. It was created for a different time and different requisites than we have today for rendering APIs. As time passed, in order to fit new needs they started adding more and more features on top of older stuff, creating a kind of mess for pepe that want to learn the Good Stuff™.
If you somehow learn to only use the modern subset of APIs, direct memory access stuff, etc, you will have a good experience. The issue is that most tutorials and books either focus on older versions of the API or start by using them instead of ignoring them and sticking to modern stuff. Also, due to how dated it is, doing some things like threading can be a bit of a pain.
Would you want to add an entry to the rust game-dev newsletter about this? That would be great! See https://github.com/rust-gamedev/rust-gamedev.github.io/issues/278
I'd be honoured to write something about this!