Does anybody code shaders?

shaders

#1

Hey All,

I was curious to see how many people actually code shaders at their work, or if not coding them from scratch - what do you do with them? Maybe provide some examples of needs that your company has had and how you worked with shaders to achieve that.

Thanks,
Eric


#2

Are we talking any shaders? Or HLSL whatever GPU Shaders ?


#3

UDK shader networks: yes, HLSL: sometimes, MR shaders: nope, Renderman shaders: only once for R&D, Maya shader networks: yes. As outsourcer most of our requests are for custom shaders for UDK and Maya shader networks. I guess if you work at a studio with a proprietary engine there may be more shader work included - many clients give us their own custom shaders for Maya and Max.


#4

Or alternatively RSL shaders etc… ?


#5

RSL shaders, yes. Its best to string as many as possible into an ubershader and switch between them with a toggle.


#6

My mindset was shader creation specific to games but I’d be interested in hearing about fillm/cg as well. I’m assuming that in game production that you primarily only deal with engine shader creation?

I’m pretty beginner on shaders and trying to learn more about them and what people do with them. Are there any pro’s and con’s to the languages mentioned? Or are they all just situation based (i.e. if you want to do a shader in ____ you have to use ____)?


#7

Depending on workflow, there’s also going to be some shader creation for your DCC so the artists have some sort of reliable feedback there. Hopefully it’s the same or similar shader that can be shared.
Languages mentioned are pretty usage specific.

RSL->Renderman style renderereds
HLSL -> DirectX
GLSL -> OpenGL
CG -> fairly independent
OpenSL -> Meant to be renderer independent

Though really the concepts between all them are the same, though with realtime shaders, there’s a lot more implementation stuff you have to learn. Especially if you want to optimize a lot.


#8

… paging Bronwen…!

The most common thing for TA’s is to prototype or do proof-of-concept stuff in HLSL /CGFX (or UDK, or Maya procedural networks) and then pass off to a graphics engineer for optimization and bulletproofing. Most TAs have the patience, basic grounding in 3d math, and bloody mindedness needed to create a prototype shader but there’s a big gap between ‘looks good in my test app’ and ‘runs at 60hz with hundreds of things on screen’. It’s absolutely a Good Thing ™ to be able to do shader work so you can negotiate effectively with engineers, but it’s statistically uncommon for TA’s to write shippable code.


#9

[QUOTE=Theodox;18386]… paging Bronwen…!

The most common thing for TA’s is to prototype or do proof-of-concept stuff in HLSL /CGFX (or UDK, or Maya procedural networks) and then pass off to a graphics engineer for optimization and bulletproofing. Most TAs have the patience, basic grounding in 3d math, and bloody mindedness needed to create a prototype shader but there’s a big gap between ‘looks good in my test app’ and ‘runs at 60hz with hundreds of things on screen’. It’s absolutely a Good Thing ™ to be able to do shader work so you can negotiate effectively with engineers, but it’s statistically uncommon for TA’s to write shippable code.[/QUOTE]

What Theodox said applies to our company as well.
I write the occasional prototype or proof of concept in our engine, or by chaining together materials in 3dsmax, but none of my code goes into the engine without being reviewed and most likely changed by our rendering guys. I often cringe when people tell me that they “write shaders”, because there’s so much more to it than binding some textures and doing some vector-math. (grumpy old me :p: )
The days where tech savvy artists contribute shader-code to a game have gone with the advent of deferred techniques. This stuff is so complex that you need to touch every part of the pipeline (all the way down to file-formats) even for miniscule changes.
Definitely helpful to have an understanding of it though, as the added complexity makes it even more critical to develop production-friendly workflows.
I suggest playing around with simple renderers or tools like rendermonkey or fx-composer to get a basic understanding of shading languages and then read every single publication you can find on real-time rendering.


#10

Mostly GLSL nowadays as I’m doing alot of cross platform work, also writing alot of the framework code the shaders plug into. Not quite full blown engines, mind you, but definitely start to finish rendering code.


#11

I write shaders for Star Wars: The Old Republic. When we started our project, one of our goals was to make the game match the style that our concept artists were painting. So instead of using our concept art as just reference and inspiration, we used it as a style definition. A big part of that task was on the the artists to create textures and models that fit the style - but shaders were a big part of it too. In the shader department, we tried to create shaders that generated lighting that matched the style of the concepts - so instead of going for realistic and physically accurate light, we tried to make our light match the style of our concept artists’ paintings.

So if you’re looking for practice tasks to help you learn shader coding, try selecting a painting or illustration and code a shader that generates results that look like the style of the painting.


#12

Cool, glad to hear that some of the things I was thinking about people actually do! Thanks everybody for posting, keep 'em coming. Time to take the deep dive on shaders.


#13

I recommend not just learning about shaders themselves but how they fit into a rendering pipeline overall. Learning the basic math behind shaders and writing cool effects is pretty simple and straightforward, writing shaders that don’t give engineers fits is a whole other skill. Use something like XNA or Cinder to build out your own simple testbeds so you get your head around the whole process, or at least at the high level.


#14

How about unity? They kind of do their own thing using their Shaderlab which you can nest Cg within but it should be able to create a simple testbed. Are we on the same page?


#15

Reason i asked before is that we don’t deal with games. We do quite a bit of shader dev for VRay/Max and Maya. Main areas are utility shaders to ensure consistency between Vray in max and standalone. In addition there’s quite a bit of utility stuff done towards the 2D pipeline (like special matte channels or different types of z output etc). On the nuke end i did a bit of relighting, deferred reflection stuff that you could prolly count as shader work in our twisted niche :wink:

The rest is mostly combining the building blocks to complex networks here.

Regards,
Thorsten


#16

:D:[QUOTE=Erkmuss;18430]How about unity? They kind of do their own thing using their Shaderlab which you can nest Cg within but it should be able to create a simple testbed. Are we on the same page?[/QUOTE]

My opinion would be to start with something that’s either pure HLSL or GLSL just so you don’t get confused by the particulars of a specific wrapper, as the purpose of most wrappers (like shaderlab) is to abstract away alot of the stuff that you might actually be interested in learning :laugh: If you’re reasonably versed in reading code, there won’t be much of a hurdle for you. Just my $.02 tho…


#17

My opinion would be to start with something that’s either pure HLSL or GLSL just so you don’t get confused by the particulars of a specific wrapper, as the purpose of most wrappers (like shaderlab) is to abstract away alot of the stuff that you might actually be interested in learning :laugh: If you’re reasonably versed in reading code, there won’t be much of a hurdle for you. Just my $.02 tho…[/QUOTE]

I would go one further and say, Start with RSL. You can get a free single user license to 3Delight.
That way you don’t need to worry about implementation stuff (pixel vs vertex etc) at first and there’s a tonne more documentation available (I find anyway)


#18

Oh hai

Game-side graphics code here in HLSL.

When I started coding shaders there was an implicit assumption that people who weren’t hardcore graphics programmers would be very bad at making performant shaders. So I, like many others, did the whole prototype-and-pass-off thing. In practice, this meant waiting on another programmer to do work they didn’t enjoy. All the fun stuff was finished, it was the CPU-side setup and optimization that was left. I was unhappy that I had to wait to see my results in-game, the artists were unhappy that they were waiting on new tech to start content work, and the graphics programmers were unhappy to get stuck with the short end of the stick. Sounds ideal, eh?

About a year after I joined Valve, the programmer I was working with at the time said, heck with this, and walked me through the setup code. The idea was that it would be better to at see it in game as soon as possible. Then we could evaluate and test perf. I wasn’t even going to check in, just run some experiments. What ended up happening is that I got mentored through the process, and after that people just stopped checking my code because it wasn’t horrible! I’m not the only one who has had this experience. … Paging Heidi…?! Sometimes making assumptions about what’s going to create a problem is the worst problem you have. It stops you from trying things that might turn out to be big successes.

You actually have to work pretty hard to make a really badly performing shader on modern hardware. (OK, you don’t, but it’s hard to do it by accident.) After a little bit of experience, common sense kicks in, like “oh! I should not create a huge chain of non-contiguous dependent texture reads!” Most of the time things artists are asking for aren’t really that expensive, they’re just different than what’s available. And – shocker – most shaders don’t have to be ideally performant to be shippable. You’d expect we’d spend tons of time profiling and perfecting every shader, but the opportunity cost for that is too high. If the game is already performant, saving one instruction isn’t going to make the game perceptably better for your customers. But the time you waste tracking down those minor problems might mean something else important doesn’t make it in – something that your customers might really care about.

I check in shaders with the expectation that, somewhere down the line, I’ll have to write simpler fallbacks for lower-end hardware, or fix some memory or performance issues. Once we’re happy with the look of the shader we start caring about that sort of thing. Get it working first, get it working fast second. So long as it doesn’t block development that’s usually fine. Sometimes a graphics programmer will come to me because I’ve created a problem, but we just work through it and fix it. The building somehow doesn’t collapse. At times I need help, but mostly I’m able to solve it on my own once the problem has been identified. It saves everyone time and lets us each focus on our own tasks. And it’s easier for me to cut features and bugfix than for someone else because, hey, I know what it’s supposed to look like. Efficiency!


#19

I had a similar experience as Bronwen. When I started at Bioware, I was told very flatly “Artists don’t write shaders.” So I made lots of shader “prototypes” that mostly got implemented for “real” in the game exactly as I had written them. I also had to wait long periods of time for a programmer to finally get around to getting my code into the game. I was able to go from writing prototypes to actually checking in game code once our programming team saw that I was finding major opportunities for optimization that they had missed and actually making our game run faster. Now I sit with the programmers and my code goes up for review just the same as theirs.


#20

Ben, Bronwen, I’m curious to hear more about your rendering pipeline.

Like I said before our company uses a very elaborate deferred pipeline, where adding a single new slider to our main shader can drag a rats tail through the entire pipeline behind it. (permutations, cross-platform-optimzitations, modifying light-shaders to support the new param, packing all params into Gbuffers, etc.)
This is why we have only programmers writing shaders an everything that ties into it.

How do you deal with that at your studio?