Shaders in Paradise

This topic is perhaps one of the most dear to me, yet I feel so unqualified to lead a discussion in it. Shaders, specifically runtime fragment shaders for video games is what the team is digging into yet again. I've been studying and practicing GLSL and HLSL shader languages ever since we choose unity for the initial game client. Despite what is now 3 or 4 years of experience with shaders, there is so so much more to learn.

My Senpai(s)

One should not utter "shaders" without also considering the book of shaders written by Patrico Conzalez and Jen Lowe. This is one of those old websites people are afraid of vanishing, as it is an absolute treasure trove of knowledge regarding fundamental shader work.

I'd also be remiss if I didn't mention Freya Holmer's generous 9 hour contribution to the game dev community. Where she explains similar basics, yet also shows how those basics can apply within a game engine directly. Illuminating many pitfalls and exposing ancient vocabulary as well.

Learning shader's would have been nearly impossible to complete in such a relatively short time if not for the above clear guidance. I feel a kind of debt over the whole thing. Like I was given some magic powers or something.

WebGL 2.0 API Quick Reference Guide, is an indispensible list of contracts for working with GLSL in the web (like I've shown on our website with the custom "3d" card graphic effect in other articles).

Even though one may reference the WebGL 2.0 API Quick Reference Guide, that simply isn't enough to explain how GPUs (video cards) process each pixel simultaneuously in isolation from one another statelessly! Then amplify GPUs stateless computation problem with a game's 30-60 fps (frames per second) requiremnent; and you have yourself a mountain of complexity to understand and master.

More Math

To top of the complex background required to design and write a good shader program; one must learn even more math! As someone whom was not exactly a strong mathematician, this added to the intimidation and difficulty. Working through sites like shadertoy.com and THREE.js examples significantly helped me to understand typical mathematical patterns via reverse engineering and tinkering.

Some advice worth repeating from all the great shader masters out there is to create your own utility library which handles most of the obnoxious math. Working through specific problems on this website, capturing the vision of our cards in live shader form, allowed me to form my first set of useful functions for working with layered animated images.

After getting over the math initially, it does start to become more enjoyable when you can see the results. One should know that the journey is hard, but absolutely worth it.

Node Based Editors

As a programmer, I find node based editors for code abstraction disgusting. This sole facet kept me from Unreal for a LONG time. My feelings on this have not changed even after using Unreal's blueprints and Unreal's shader editor. I admired Unity Engine for supporting the direct shader program compilation, even though the docs and help was limited. I could still apply my knowledge from Freya and The Book of Shaders directly.

With Unreal Engine, I can't exactly use my utility library unless I use the "raw shader node". So there are some setbacks with using Unreal Engine for stylized shaders because of their node based only programming.

Now, despite me saying this, I don't regret moving to Unreal Engine. It is my hope (perhaps a gamble), that future team members are more likely to know how to use the Unreal node based editors than they are to have self trained rigorously in the art of programming fragment shaders from scratch.

Look Dev

Okay, so lets talk about SteelPinion specifically here. If you've been following us since mid 2022, you'd know that we didn't achieve a decent "look dev" workflow until a year later from that point in article #13. This wasn't for lack of trying, it took me years to learn to both 3d model, then animate the geometry, then apply a lookdev workflow to those models...

LookDev is a tall tall order for a mere programmer. So I did what I knew how at first. I wrote a program that ripped the most popular color template combinations from the web, converted them into a list of hex values, and then applied those templates randomly to our vertex colored models.

Yeah, that sort of works. It was useful for viewing our models in a bunch of different way's I hadn't yet imagined. Generating thousands of images of our models in colored form was useful for learnig about colors, yet it wasn't enough to get a consistent color language.

Wait, what do you mean by "color language"

Welcome to the extent of my knowledge. I only vaguely know what I'm talking about with colors. Here is what I think it means based on my experience building web UIs. Colors can have implicit meaning. In web dev, we frequently reserve certain colors like red, yellow, and green for actionable statuses. Red typically means something is wrong, yellow warns, while green relieves the user of further action. These are used as "CTAs" (call to actions) indicators. If you wanna go deeper, you absolutely can. I'm not your guy though.

For Steelpinion, a tactics game; we want to signal certain materials like metal/wood consistently. This could help our players know how to counter a ship immediately simply by glancing at it. Fire to wooden ships, frost to iron ships, shock to steel ships. If we are studious and careful, we could design our own CTAs right within Steelpinion's own colors.

Cursed Customization Paradox

I am presently battling with a conundrum here about player color customizations and this color theory. If we allow player's to color thier own ships for personal expressiveness, how can we preserve color's meaning? ~Sigh, I don't know right now. Maybe we only allow metals be hues of blue, and wood hues of red, etc. The color customization will likely have some restraints to prevent going completely against the game's designs, though how that will pan out depends on what we discover as we tinker with various shader algorithms.

Closing Thoughts

We are aiming for a vintage comicbook look for the game, even with it's runtime animations. Presently, we don't have great support for solid colors, only textured blended colors which is much too noisy. This month, we've been defining a clear north star for our primary fragment shader. So far what we've discovered is that the UI, the ships, and the background may all need different algorithms! Needless to say we are still working on it, and will hopefully have a nice new Unreal version of our shader soon!