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
Are we talking any shaders? Or HLSL whatever GPU Shaders ?
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.
Or alternatively RSL shaders etc⌠?
RSL shaders, yes. Its best to string as many as possible into an ubershader and switch between them with a toggle.
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 ____)?
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.
⌠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=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.
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.
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.
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.
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.
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?
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 
The rest is mostly combining the building blocks to complex networks here.
Regards,
Thorsten
: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âŚ
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)
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!
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.
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?