Some Thoughts on Shaders
(This is an excerpt from documentation from WavesWorld --WavesWorld/Source/Shaders/README. Copied with Permission)
Some notes on shaders:
Shaders are what make RenderMan renderers different and so much cooler (i.e. powerful and flexible) than other renderers. Unfortunately, while writing shaders is not really hard, getting to the point where you can write shaders *is* difficult. You don't quite have to have the equivalent of a MS in Computer Graphics to do it, but it gets close. A real short cut to learning how to write shaders, though, is access to good shader source code. For a long time, the only source of shader source code was the examples in the RenderMan Companion. These are nice, but it's not clear (a priori) if these are "toy" examples, and also, it's always nice to see how a bunch of different people do similar things.
In the past few months, though, this paucity of shader source has started to change. With the advent of Larry Gritz's shareware RenderMan compliant rendering toolkit, the "Blue Moon Rendering Tools", and the release of the book "Texturing and Modeling: a Procedural Approach", which cleaned up information from a few SIGGRAPH courses and made it generally available, there is now a ready source of lots of shader code to start hacking with.
Wannabe graphics hackers using NEXTSTEP have a great leg up here, since you've now got the best of both worlds; the superior tools and enviroment of NEXTSTEP to play, and now a wider market for you to share your work (i.e. other UNIX boxes can now compile and run your shader code using the Blue Moon tools).
I've gathered together a large amount of shader source code here in one place to use as a starting point from which WavesWorld hackers can draw from. Feel free to use the code in here, but make sure you prominently mention who wrote the shader you started with; it's only good manners, especially since no one writes a shader from scratch (at least no one I know).
An important note on naming: shader name space, especially when you have lots of them, can get very cluttered (i.e. plastic1, myPlastic, brick, glass, grid, etc.) One partial solution to this is to write more and more general shaders and shove the namespace problem on to the parameters; i.e. you have more and more parameters on the shaders, cutting down on the number of shaders because you have 5 that do the work formerly done by 30, but that's only a partial solution, especially when you just need to bang one out... The other problem is that there are certain problems (tiles, bricks, wallpaper, metals, etc.) that different people approach slightly differently. When both solutions are good (sometime for different problems; one might be better, but runs slower, etc.), and you want to keep both around.
To combat this, I've tried to use consistent prefixes that correspond to the original source of the shader: DP for Darwyn Peachey, LG for Larry Gritz, BM for ones Larry distributes with the Blue Moon Rendering Tools, KM for Ken Musgrave, RC or RenderMan Companion, etc.
This seems like a reasonable solution. A better one would also encompass some sort of "dictionary" for shader names and parameters, but that will have to wait until we have a critical mass of people on the net who want to share shaders. I'llbe happy when we get to the point of having this problem...
Compiling these shaders:
In my environment, I have both Larry Gritz's Blue Moon Rendering Tools installed and the normal RenderMan distribution that comes with NEXTSTEP. Larry purposely uses a different suffix (.so vs. prman's .slo) for shaders compiled with his shader compiler. This has the happy circumstance of easily allowing both shaders to coexist in the same directory. Unfortunately, I couldn't come up with a standard Makefile that I was happy with that, with a run-time flag, could switch rules and generate compile shaders with both shader compilers. I'm hoping someone will read this and send me one, actually :-). In the meantime, I wrote a stupid little shell script which compiles them all and moves the shader object code into /LocalLibrary/Shaders, where they belong. All you have to do is type "./doIt" in this directory and it will go and compile all the shader source. It's a lame-o method, I know, but I've got bigger fish to fry, and if it bothers you that much, send me a better fix; maybe I'll use it.