Dawn is amazing! I am currently building a PBR path tracer for UI components in JUCE using compute shaders. I can get away with off screen rendering to a juce::Image and paint that in a Component. I can render parts of the scene based on dirty regions (areas which needs update) and the read back only takes a few ms. It is definitely doable.
2 Likes
Mathelino It’s great to know people are using WebGPU with Juce. It would be nice to finally stop worrying about whether OpenGL is available on both Windows and Macs. I’ve been thinking about rendering a plug-in using Gaussian Splats! 
1 Like
Gaussian Splats, that’s a new one for UIs!
Gaussian splats are fun to do in webGL. Here’s some web demos in the .SOG format: https://superspl.at/ - you can fly around with mouse and keyboard. What’s nice is that reflections work. I ‘just’ need a 3D model or Photogrammetry to make the model of the plug-in. 
Making 3D versions of real hardware would be perfect though.
The trouble is they still take up a fair amount of memory, they also need a fast compute Z-sort, which is where webGPU comes in.
A reverb plugin where you can walk around a real space rendered with Gaussian Splats and hear how the room sounds from different places would be amazing.
2 Likes
Yeah, man. I would prefer to build a room, from user design, rather than a pre-made building.
Because of the nature of the sorted splats, I don’t know how it looks when you move walls about, as you can’t re-light or shadow them separately, yet, and don’t forget you’ll have to sort All the splats as the scene is created with new view positions. There’s also a big potential for holes, and you may have to be a separate poly list, for normals and occlusion. It’s all doable, but…I think I’ll start with something simpler. 
I can’t wait to use compute shaders and render in webGPU.
I was thinking you’d make it a convolution reverb and record dozens of impulse responses around the room and just select the closest one as you move about.
A ray-traced approach would be even more impressive though!
1 Like
I would love to travel the world, sampling empty cathedrals, concert halls, and caves. But I don’t have the luxury!
1 Like
I’ve been contemplating WebGPU and other options for a long time. At the moment I think the best fit for JUCE would be to support Slang, which would provide the ability for users to provide their own shaders. Compared to our current OpenGL renderer the main drawback for this particular approach is that runtime compiled shaders are extremely awkward.
Do people absolutely need the ability to compile shaders at runtime, or could all shaders be built at compile-time and embedded into the software as binary data?
1 Like
This is exactly what I do with Slang at the moment FWIW.
I have a CMake utility that compiles the .slang shaders to the native formats during generation, and then use configure_file() to embed the binary data using a std::vector<std::byte>.
Compiling at runtime means the end-user machine needs to not only have slangc installed but also some native tools like the metal compiler on macOS (as slang only outputs .metal files but doesn’t compile them to .metallib).
Happy to share more about my experience with Slang if you want to reach out
1 Like
That depends on how the tooling works. My current OpenGL pipeline detects changed shader files at run-time, and hot-reloads them instantly. If I can employ a similar mechanism (call compiler app, hot-reload the resulting binary) with slang, then it wouldn’t matter.
But if this means a typical C++ workflow (quit app, compiler, re-start app), then Slang doesn’t sound very attractive.
That might be possible in a development environment, but I can’t see a way to make that work well on a end user’s machine.
Slang is simply a transpiler - you write .slang shader files and it outputs .metal, .hlsl, or various other formats which you then use with the respective libraries. See GitHub - shader-slang/slang: Making it easier to work with shaders · GitHub.
If you were willing to refactor your existing OpenGL pipeline to instead use Slang and target native graphics libraries (Metal, Direct3D, etc.) then yes, in order to enable your end-users to edit those shaders you would need to ship the slang compiler with your product/installer.
In your case, sticking with OpenGL until you can use something like WebGPU would likely be the best option. Maybe you could look at using WebGPU through a web front-end?
Not interested in web front-ends. Shipping transpilers and compilers is brittle and convoluted, and it’s a hard sell for users. I can’t ship the compilers for macOS and Windows myself, so users would need to obtain those separately.
Embedding the Slang compiler pulls in a lot of additional dependencies, which I would like to avoid.
Overall this is an unpleasant path. OpenGL works fine for me; the only concern is Apple dropping support eventually.
2 Likes
is there anything that prevents you from using [MTLDevice newLibraryWithSource] on macOS ?
Turns out I was wrong about needing to ship the native compilers btw - both the Metal compiler and Direct3D compilers are built into the OS so will be available on any end-user machine. Although this isn’t recommended on either platform unless you do need to be able to change the original shader source on end-users’ machines.
You’d still need to ship the Slang compiler though.
we do ship glslang, shaderc and spirv-cross with our apps and we can target glsl, spirv, hlsl and msl at runtime no issues (we target devices on gles2 and 3, metal, d3d and vulkan) . the hardest part is starting from the same shading language subset so you always end up with a correctly compilable transpiled format.
Yes, I need to be able to do that. How much of a binary-size bloat can I expect when statically linking Slang compiler into my project?
Depends exactly how you want to embed it but the sizes of the latest releases on github range from ~50MB to ~120MB: Release v2026.12.2 · shader-slang/slang · GitHub.
That’s a non-starter for me. My binary right now is only 10 MB. I can’t justify bloating it to 60-130 MB just to transpile slang.
How is it that long? It blows my mind that transpiling could possible take so much space.
Edit: I just checked the x64 Windows version. Just the .dll files alone are ~150 MB. That is 15x the size of my whole app!