pouët.net

The scene.org version (party version) of the intro unfortunately requests a "low power" GPU. (Forgot to change it before submitting the entry.) On anything that has more than one GPU (i.e. laptop) WebGPU will therefore choose the low end/integrated GPU for rendering. Please use the version at the following url, which properly requests the "high performance" GPU.

https://unik.de/download/bypass-luminosity.zip

When trying to run this on Linux you might be better off with the party version, though. Chrome's WebGPU support on Linux is still somewhat wonky with Nvidia cards - at least from what I experienced so far (and which was the reason to request the low power GPU on my machine in the first place).

Lastly, the intro won't run on Firefox yet. Firefox' support for WebGPU improved during the past months, but they are still not yet supporting indirect compute dispaches, which our code heavily relies on. Should just be a matter of time..

@wrighter @zavie The intro does not use any RTX or other APIs (e.g. OptiX). As far as I know WebGPU does not yet support the raytracing part. Rendering is done in a couple of compute shaders, with a final fragment shader for postprocessing (applying glow, gamma etc) and blitting. We are path tracing 1 SPP with 5 bounces, but most of the time don't get that far due to RR. The path tracing follows a "wavefront" style pipeline, i.e. no single "megashader" that does everything. In terms of geometry we are only intersecting triangles. (Meshes for primitives are generated CPU side. Letter meshes are embedded intro data.) We did analytically intersect primitives at some point in time too, but trimmed it down to triangles only. I felt this is most versatile and keeps the pipeline uniform/simple. (Might have been better to keep it, now that there are basically just primitives.) All objects are dynamic per se even though we had very few animations in the intro. Lights are sampled via RIS (resampled importance sampling). We tried different approaches (e.g. stochastic light cuts), but RIS hit the sweet spot for complexity/size/quality. Material bsdf is standard microfacet for reflection/refraction (Walter et al) blended with simple diffuse (even though I think it does not show in the intro). MIS weights contributions between light and material sampling. During shading stages we render an additional attribute buffer (like a g-buffer) for later filtering, which is done via SVGF. SVGF unfortunately blurs reflections/refractions unpleasantly and introduces ghosting. We improved that for pure specular reflections, where we can provide noise free attribute buffers (which SVGF needs). Refractions still suffer, because they are sampled stochastically (only 1 ray). This was the first 64kb in a long time for us and generally a first for me utilizing path tracing, so I guess there is much to improve and learn. Criticism/suggestions/ideas are welcome!

@wrighter I can report that I'm seeing differences when switching the WebGPU power preferences. My machine has an integrated Intel and a dedicated Nvidia GPU. When I request the "low power" adapter the integrated card will be utilized by Chrome. Specifying no power preference or requesting with the "high-performance" flag, I seem to be getting the dedicated GPU, which then unfortunately fails when initializing the view from the context's texture. (It works with the high performance setting if I'm just running the compute shaders and not present via the swap chain.) webgpureport.org shows the two GPUs plus a fallback adapter at least in Firefox. Devs on the WebGPU mailing list said that WebGPU on Linux wasn't a major priority. :(

We rendered a converged version (256 spp) of the intro:

https://www.youtube.com/watch?v=KrE181wamdo