I've been following the development of Shader Park for a while, and I'm so excited to see it come out of alpha/beta. It allows folks who aren't necessarily familiar with writing shaders to create amazing interactive 3D graphics, skipping all the difficult boilerplate and math. I think this will do for SDF geometry what Processing did for general graphics programming.
Great to reduce the complexity of shader programming and making it more accessible to front-end devs. Shader elements can lend a unique artistry to web design if not overdone.
I haven't looked very deeply in the codebase but it seems to be a JS abstraction/generator library for GLSL. So now the high-level pipeline as I understand it is ShaderPark > GLSL > WebGL.
Co-creator here, really excited we're on hn!
We had a new account creation bug today but just deployed a fix.
Happy to answer any questions people have :)
It's fine to use this sort of tech on a web page but it's vital to detect whether or not the device rendering the page supports it well, and only use it (or scale it up) where support exists. There are GPU detecting functions out there, and measuring the framerate your app is getting is simple, so progressively enhancing is not hard. That said, browsers could make it easier.
I viewed the page on my crappy Android phone and got maybe 5fps. Anyone shipping an experience like that hasn't done a good job of supporting their users.
In my experience, it is hard. As you suddenly don't have only one result you need to test and polish, but many different ones.
So it is possible, but it is not easy to do right, except for very small applications.
And as for the example here, well - it is a collection of many examples, loading all at once. Of course it is hardware intense - but in a real world project, you would use only some of it, or make a disclaimer, that it is hardware intense, but if you make a game, I think it is expected, that it does not run on all hardware?
As you suddenly don't have only one result you need to test and polish, but many different ones.
In the case of WebGL you need to account for more than the browser. If the user's GPU is on Chrome's blacklist then they won't see anything - and the only way to do that is using the GPU detection functions I mentioned. You have to do progressive enhancement for 3D stuff. And if you've implemented it for that then you have the necessary infrastructure in the code to do it for performance as well, so it's not hard...
I didn't see any reference to a frame rate limit in a quick search. I'm worried that it's just using all the CPU all of the time, even for simple demos.
This looks really cool although it’s hard to find an explanation of what it really is. Looking through github it seems to be a sort of api for producing SDF volumes? Rather than a generic js->glsl transpilier.
It’s a very cool rendering tech and nice to see an easy to use library like this. I’m curious what the rendering stack looks like and what the performance is? SDFs are usually pretty expensive to render.
It would have taken you as much effort to read the "shader" wiki entry [1] as it did to pendantically put down a foss library website for privacy issues. You would also have learned a fundamental concept I 3d graphics.
Are you on safari/any ios browser? If you are, I suggest using a platform that supports a modern browser. The page and shaders work fine with ublock origin and googletagmanager blocked.
For what it's worth, I can confirm that on an older version of Safari the page is completely broken, and upon opening a debugger the page is utterly infested with analytics/trackers anyway.
If a page can't even display an error message when it fails, it's broken, full-stop. The browser is just the messenger.
Congrats to the Shader Park team on the release!