In a game artist-specific Gamasutra feature, former Valve and current Bungie art veteran Steve Theodore examines the state of artist-friendly shader tools.
[In a game artist-specific Gamasutra feature, former Valve and current Bungie art veteran Steve Theodore examines the state of artist-friendly shader tools, in an article originally printed in sister publication Game Developer magazine.]
Have artist-friendly shader tools finally arrived?
Shaders can drive you crazy. Every new generation of hardware or slick new rendering technology tantalizes us with untold possibilities. Yet just when we fall in love with some new look, it's snatched away by engineers who tell us it's killing the frame rate or hogging memory.
Working as an artist in a shader-driven medium can be like supporting the Chicago Cubs. It's a slow-motion torture in which hope and excitement inevitably decay into disappointment and frustration.
We're entering a new round in this endless tango of technological enticement and frustration. The creative promise of shader tech has hovered just out of reach for artists for quite some time.
We know many tactics for managing a complex visual appearance. It's not as if we've never heard of texture maps or compositing or multiplying pixel colors together.
But actually putting together a working shader has always required unpleasantness like syntax-highlighting text editors and compilers. Many artists who are fully capable of imagining and even designing great shaders have been put off from actually building them by all these programmer-ish accoutrements.
It looks as though things are changing for the better. The latest crop of modern shader creation systems tries to lure artists with UI and workflows that seem to come straight from the familiar Maya HyperShade playbook.
The material editor that ships with the Unreal Engine toolset, the Max plugin ShaderFX from Lumonix, and the combination of NVidia's FX composer and Mental Mill all provide graphic interfaces for creating shaders using well understood, artist-approved node graphs instead of the horrors of typing code for yourself.
If you know your way around Maya HyperShade or DarkTree, for example, you can now find a shader authoring tool that looks pretty similar and will let you spit out fiendishly complex effects files that you would have never had the fortitude to type in manually. (Sigh.)
Unfortunately, despite this new convergence in tools, offline and online rendering remain very, very different. To achieve the millions of computations they must do every second, graphics chips evolved into the idiot savants of computing: amazingly powerful, but weird and off-putting.
It is absolutely true that the new generation of shader tools lets you create sophisticated effects with (relative) ease. What has not changed, though, is the awful truth that achieving reliable, sustained performance in the harsh world of online rendering still demands specialists.
Despite the cool new GUIs, the intricacies of graphics hardware and the esoteric, special-purpose shading languages that drive the hardware are still the province of engineers.
Turning shaders into just another form of "content," like a bitmap or a model, is an appealing idea. Unfortunately, that dream remains a long way off. Many teams have learned the hard way that giving artists the whole responsibility for shader creation is dangerous for at least three reasons.
First, even with the "friendly" face of a modern shader editor, many artists are still intimidated by shaders. Open-ended systems are very powerful in the hands of technically-inclined artists with a lot of patience and the will to learn. For many production line folks with deadlines to worry about, though, they seem like a waste of time.
If all you want really is a standard bumpy-shiny-Phong clone, creating it for yourself out of nuts and bolts isn't a plus—it's a drag. If you're going to reuse the same pieces over and over, wouldn't it be better if they were custom tailored and optimized by a professional graphics engineer instead of cobbled together by a harried artist?
Second, the artists who do embrace the tech and run with it are still going to run head-on into performance issues. It's torture to give an artist a tool that invites—even demands!—artsy experimentation and neat little extra touches, only to swoop in at the end of the project and rip them all out because some combination of graphics calls is causing the game to stutter like a 1978 AMC Pacer.
Even if all the shader artists are fairly good at performance programming (a big "if"), a library of hand-built shaders is still very difficult to rationalize when the project nears its ship date, so last-minute performance tweaks will be haphazard and risky.
Finally, and most damning, letting every artist build his or her own shaders can mess with your art direction. If, by some miracle, your artists manage to traverse the minefield of performance without blowing up the game, they'll reach the end of production with hundreds of materials created in very personal ways.
It's possible that my shiny metal and your shiny metal will look similar in the shader editor and yet behave altogether differently when dynamic lights, moving characters, or HDR lighting kick in.
Artist-built shaders offer no common way to herd these divergent shaders into the same dynamic range. If artist A's shaders are always much hotter than artist B's under the same lighting, how can you make them look like they come from the same physical universe without editing dozens or hundreds of complex node graphs?
All of this should not be taken as a slam on GUI shader tools. Graph-based shader authoring is a huge step in the long, slow process of educating ourselves about how our medium works.
By providing artists with tools that let them sketch out the way they'd like their shaders to work, graphics shader editors make a huge contribution to the thorny artistic problem of imagining and then realizing complex visual appearance. If you're setting out to prototype a new effect or custom material for your next game, these tools are ideal places to start.
The important caveat, though, is that you can't assume that shaders are now a "done" topic like bitmaps that can be safely left to the art department.
There are too many complex interactions between shaders and the rest of the game, and too many difficulties (as we've seen) involved in managing a shader library that was created by non-engineers.
If we artists aren't going to write our own shaders, what can we do to make sure the shaders we get are going to do what we want and tell the stories we want to tell?
Assuming the engineers can produces a good shader framework, what features should artists be lobbying for to make it a creative and reliable tool?
Here are a few suggestions to keep in mind the next time you have engineers asking you for input on a shader system.
Many non-technical artists are turned off by the sheer number of choices they have in their shader tools.
A good system should make it easy for line artists to concentrate on the jobs they know best and do most—modeling and texturing. Don't make them hack through graphics options they don't understand.
The Texture Tree Editor in Darkling Simulations' DarkTree procedural shader authoring tool is shown.
The first tool for managing this complexity is to offer a smaller number of high-level choices. A library of several basic shaders with contrasting material qualities is better than a single "ubershader" with dozens or hundreds of sliders. Yes, it is more limiting, but for most artists, that limitation is a stressreducing bonus, not a problem.
Non-technical artists will be happier with, say, dedicated shaders for metal, plastic, and wood than with a text doc detailing the dozens of parameter settings needed to get such different effects out of a single shader.
A good library system with strictly limited tweakability also helps junior artists produce materials that behave in predictable ways, and makes it easier for engineers to do performance adjustments late in the game, since the shaders are already grouped by function.
While designing the library system, it's also a good idea to build in a rough measure of shader cost to each of the library shaders. Engineers will tell you over and over that they can't give you the "real" performance cost of a given shader, because there are so many factors involved.
This is partially why having artists build shaders for themselves is impractical. However, relative costs are fairly easy to estimate. A three-pass shader is probably a lot slower than a single-pass one. A shader with anisotropic textures will be a lot slower than one with bilinears, and so on.
If your library shaders prominently display a relative cost factor (even if it's nothing more than fast, medium, or slow) it will help educate less technical artists about the performance issues they have to deal with and hopefully head off lastminute cutbacks as production winds up.
Of course, some artists will look at a library system like a straightjacket. They're a minority, but an important one.
If you have high-powered technical artists, you might allow them to create shaders directly for some limited purposes using tools like those above, or you could simply expose more of the inner workings of your underlying shader system to them. In either case, it's important to make sure that "expert mode" really is reserved for special cases.
Whether the choice to use custom shaders should be made by art leads, or handed off to tech artists, or enforced by the honor system alone is a question that depends more on company culture.
The important thing is to make sure that the "expert mode" doesn't morph into "everybody" mode.
If a lot of artists are clamoring for a particular look or behavior, it ought to be packaged up (with necessary performance tweaks and budget constraints) into a library shader instead of passed around the office by copying and pasting settings nobody understands!
The most difficult goal to achieve in designing a shader system is consistency. Even in a streamlined, fill-in-the-blanks library system, there are plenty of ways to make objects that look quite similar in some lighting conditions and wildly different in others.
Unfortunately, this is one of those problems where sociology trumps technology. While you can build a system that encourages consistent approaches to lighting and texturing, it's impossible to make one that will enforce consistency 100 percent of the time.
One important thing you can do to foster consistency is to build the lighting preview environment right into your tools. If artists drop a copy of their shader into the game to test it in the "real" environments, you can bet they'll find lighting backdrops that suit their tastes rather than ones that are really representative of typical in-game lighting.
If your shader editor comes with well-maintained lighting stages that accurately reflect standard lighting, you'll have a huge leg up on making shaders that look like they all belong in the same game.
Of course, maintaining consistent lighting across the whole game is itself a dicey experiment in art management, but we'll leave that for another discussion.
Another very helpful step you can take is to name your shader controls in ordinary English. Shader technology over-stimulates that part of the programmer brain that delights in obscurity.
For example, many shiny shaders control their highlights with two values. The first is typically named something like "specular power" and runs from 2 to 32 (that's how many times you multiply the diffuse lighting falloff by itself to get the falloff of the specular lighting). The second, typically named something like "specular coefficient," is multiplied against the result of the first, but runs from 0 to 1 for natural surfaces or maybe higher than 1 for unusual effects.
Not only are these names pretty incomprehensible to your average artists, but the value ranges don't mean anything intuitive. You can get similar looking results from many combinations of these two values.
A coefficient greater than 1 combined with a high power often looks much like a lower power value with a smaller coefficient. The result is confusion for newbie artists and headaches for the lead who has to figure out why some shiny shaders white-out under HDR lights and others don't.
Obviously, designing a shader system from the ground up is a daunting task. The engineering is tricky and has high demands, but the social side—the education and training and development of a house style—is also very difficult.
It's the human element that really counts. Very few artists are really pushing the limits of current shader tech because so few of us really know what the medium can do.
While we are not at the point where shading is the personal responsibility of an ordinary artist in the same way texturing is today, we do need to keep enlarging our understanding of the underlying tech so we can tell the stories we want to tell.
The new generation of shader tools is not going to have your graphics engineers scanning the want ads any time soon, but it can do a lot to encourage artists to learn more about the possibilities and limits of our ever-changing medium.
Even if all these new tools do is eliminate some of the aura of mystery around shaders, they will have earned a valuable place in the artist's toolbox.
Read more about:
FeaturesYou May Also Like
