Sponsored By

A story about shaders, Part III

Even with fancy shader builder GUIs, we can't completely ditch the programmers from the shader creation process. Now explore what's involved in sharing the work between programmers and artists in the artist-driven paradigm.

Neil Gower, Blogger

March 26, 2009

2 Min Read
Game Developer logo in a gray background | Game Developer

In the previous post, I looked at how optimization is hard and suggested that you probably need to dedicate a graphics programmer to analysis and guiding the artists in the optimization of the shaders. This leads into a new issue, the question of differing and sometimes conflicting values across disciplines.

When you add a programmer to what was going to be a pure art task, it's not hard to inadvertently pit artist against programmer, fighting for visual fidelity and performance, respectively. Some artists will be more than happy to Cock fightabdicate all responsibility for performance, especially if they were uncomfortable with it in the first place. Many artists don't think that performance is their responsibility to start with, rather that they should make the best looking content and let someone else sort out making it efficient. Others may take some level of offence to being "babysat" by a programmer. Programmers can get annoyed spending time and effort tracking down performance problems in shaders they had no part in creating. Both programmers and artists can get their feathers ruffled, but regardless of the cause, an adversarial relationship is going to kill shader performance. Successful optimization requires balance, and balance requires cooperation and compromise.

The values problem is really a social issue, so the solution depends how your team works together. Maybe you work in a studio where programmers and artists frolic merrily together producing kick ass games with nary a conflict. If that's the case, just keep doing what you're doing. Otherwise, you could try to find a way to make the graphics programmer part of the art team, for example call her/him a technical artist and have them sit with the art team. Another approach is to have the art team hire a contract programmer to work for them. Either way, the programmer should be involved in shader creation from the start, this both helps to head off potential performance issues sooner and can create a sense of shared ownership of the shaders. Whatever approach you choose, the critical part is getting the artists and the programmers to share the responsibility for reaching the performance targets. If you can achieve a good level of collaboration, the quality of the work will improve dramatically.

Next post will wrap things up and touch on how time factors into shader performance.

 

Flickr photo by tarotastic

Read more about:

2009Blogs

About the Author

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like