Why I Built ShaderKit
I’ve been writing shaders for years now, and the whole time there were problems I kept running into that no tool I used actually solved.
The main one was loss of work. Sometimes I would work for hours on a shader, forget to save, close the tab accidentally, and realize too late that it’s gone forever. On top of that, rendering was always a tricky, clunky process. I would transfer code to a local CLI program that could render it, but it always felt like extra work. Some shaders I’d make as loops, and the process of figuring out how to make them actually seamless was tricky to be sure I got right without rounds of export and checking the loop quality. And if I wanted to make a GIF, that was a whole different CLI script to handle, and just sort of a mess.
ShaderKit is the answer to every need I’ve had in shader development. It’s a professional GLSL development and output studio that runs in your browser, and I built it so I can focus on the art, not the bugs. The full editor is free. The only two things that cost anything are the two features that actually cost me money to run, vibe mode and cloud rendering, and even those you can try before paying.
Once I found that AI tools could educate me on how to write WebGL code correctly, I realized I could learn all I needed to actually build this. I made a basic form of it early on as a functional tool for some exploratory work with QRI, and during that I proved to myself I could build a working WebGL app with what I’d learned so far, and started imagining how I could solve all the problems I’d encountered with shader writing.
The first prototype was basically just proving out the auto-save functionality. I’d lost so many shaders to accidental tab closes after spending hours on them, so once I tested and validated auto-save, especially when I started using it myself and first actually forgot to save a shader and was saved by auto-save, I knew I had to take it to the finish line.
The aesthetic behind it is to make something fully functional in the browser that has everything I found myself thinking when using other shader writing systems, every “it should have this or that feature” thought I’d ever had.
What’s actually different
The clearest one is cloud rendering. You set your render settings and then keep working, on other shaders or whatever else, until you get a browser notification that the render is done, and then effortlessly share it. Before, when I rendered something heavy at all, I basically couldn’t use my computer for the duration. With cloud rendering I set it and forget it. As far as I’m aware, no other browser shader editor has cloud rendering built in. The usual options either render locally in your browser, or make you export your code to a separate desktop or CLI tool that renders on your own machine and ties it up while it works.
The GPU rendering is for final renders. You set your fps (30 or 60), duration in seconds, and resolution up to 8K video, and even higher for images, where you can set a custom resolution. GPU-side the render splits into tiles to make huge resolutions like 16K work when it can’t all fit on the GPU at once. I’ve rendered raymarchers with deep complexity and high step counts that take hours, and just let them render overnight.
Then there’s turbo FPS, which lets you explore feedback systems like cellular automata in a whole new way. Sometimes the hardware, especially at a lower resolution (which is easily set in the editor interface), is capable of running things way faster than just 60fps, and in some cases that can be incredibly interesting to see. Rather than waiting what would be days at 60fps, you can speed it up, and at a low enough resolution run something at 20k fps. Yes, actually 20,000 fps. That test was set to 100x100, but I don’t think that defeats the point.
Vibe mode brings Cursor-like AI vibe-coding to shaders. It’s a small panel below the editor where you prompt an LLM to make edits to your shader, either in high-level vague terms like “make it cooler”, or by precisely writing code but in natural language, like “add a for loop with abs() on uv and a sine modifying a subtraction from it”. It isn’t just a raw “write shader code for this prompt” call, either. The user input first goes through a small LLM that picks relevant pieces from the function library and includes those in the prompt, which gives the main model less thinking to do, and that’s been a significant improvement in output quality. Language models write the best code when you’re essentially still writing the code but doing so with natural language, so a skilled shader writer telling almost exact lines through vibe mode can move a little bit faster, say on mobile, where typing code out is slow and painful. For everyone else, it opens up more advanced shader writing than would otherwise be doable without significant education in the medium.
The loop control tools are maybe my favorite part. You set a loop timing and then have it replay that specific time segment. Examine mode plays the last and first second only, over and over, so you can see if the jump between end and beginning is seamless. X-time mapping makes time static across the x variable, so you see the last and first second mapped across the screen with 0 in the center, and you can visually see the seamlessness or the presence of a seam without waiting for playback. There’s also a seek mode on top of that for inspecting a single x-slice through the whole loop, so if a shader is seamless in the center but not elsewhere, it’s easy to diagnose and fix.
Here’s a seamless loop made with those tools:
A lot of the rest is just the stuff I always wished I had. Auto-save has saved my ass multiple times when I spent hours on something and yet failed to hit the save button. The function library lets you easily paste in functions that get used over and over in many shaders, plus templates for common starting points like a raymarching shader, and you can save and publish your own for others to use. You can fork any shader to start a new one from the same code, the same as copy/pasting a Shadertoy and continuing with attribution, except in ShaderKit the lineage is actually tracked, so you get a visual tree of where a shader came from. There’s also a built-in color palette with palette functions, an in-browser recorder, export as standalone HTML to host a fullpage shader on your own site, a display mode that shows the final output no matter which channel you have selected, and uniforms (sliders you can add to drive your shader). And your work isn’t locked in: you can export and import any shader as JSON, so if you’re protective of your code or just want a local copy, you can keep one whenever you want.
The canonical flow is: open, write shader, iterate, save, optionally share a link, optionally render, fork, and keep going. Real-time here means you make a change and it’s immediately compiled and shown in the display. On Shadertoy you compile on edit, which isn’t the same.
I’m mainly aiming at the creative coder, though generative artist would count too. Someone who’s passionate about exploring shaders and sharing that, so needs to be able to export easily without thinking much about it, and who benefits from the writing tools (vibe mode plus the library) that decrease the friction between mental imagery and the resulting shader code. Most people will be coming from Shadertoy. TouchDesigner users may find vibe mode interesting, since it’s most functional with the specific instructions they’ll be familiar with from the nodes, just using natural language so the exact code writing can be secondary. I don’t really think of ShaderKit as yet another Shadertoy clone, it has so many more features that it’s much more in the realm of something Adobe might release.
Where it’s at
Honestly, most of what I wanted to implement is already there. Right now there’s nothing major on the roadmap, just bug fixes and polishing. The web recorder works but the UX could be better. Vibe mode is also somewhat basic compared to what I think it could be. Over time I plan to “teach” the LLM to write shaders better by carefully structuring its system prompt to optimize the chance of a quality output.
Pricing and signup
Everything is free except vibe mode and cloud rendering, the two features that actually cost money to run. Both use credits, which you can get by direct purchase or through a subscription. Pricing is per-month credits: $7.99 “Creator” for 50k credits, $20 “Studio Pro” for 175k (with yearly discounts, $6.39/mo for Creator and $15/mo for Studio Pro). A render at 1080p for 30s might cost around 500 to 1500 credits. There are also credit packs: $1 for 5k, $5 for 20k, $20 for 100k, $75 for 400k.
Signing up is just username and password. I don’t think collecting email is absolutely necessary for just using something like this. Email is needed for Stripe, so it’s prompted as optional at signup and as needed when you go to pay.
Try it
If you write shaders, or want to, I’d love for you to try it. Sign up (username and password, that’s it), post a shader to the public browsable list, and if you’re curious, grab some credits and try vibe mode or a cloud render.