View Full Version : Define Shaders
02-22-2004, 11:49 PM
Ok, a lot of the programs etc that I have been looking at recently have been discussing the use of shaders concerning modelling, lighintg etc. I was wondering if someone could fill me in a little on the actaul technical issues, ie what is a shader?
As far as my knowledge (and technical programming ability so far) entails, rendering involves material properties, which have ambient/diffuse/specular Phong lighting models (normals generated at point of intersection), and then the material definitions can be extended to include textures for each aspect of the Phong lighting model, bumpmapping for normal manipulation, and perhaps some other info such as reflectivity, emission if you are doing a light emitting object, transparency/density of material etc.
So what is a shader? I take it they are programmable, and are put into a program as opposed to being individually executed. I can only think that shaders somehow extend the materials definition somehow.,
02-23-2004, 09:58 AM
A shader is a program that is run for every shading sample on the surface (simplistically, every visible point on a surface).
The shader is given a bunch of parameters by the renderer (point position, surface normal, light positions and colours etc.), and a bunch of parameters by the user (surface colour, shininess, texture filenames etc). Given these parameters, the shader calculates what the final surface colour and opacity should be. That colour is put into the final rendered frame at that point.
That's the basic idea from a shader writer's point of view.
All the "materials" in Maya or 3dsmax are shaders. The concept of material properties is designed to make playing with the shaders easier for an artist. Ever wonder why the "specular power" slider on a phong shader seems to have the opposite of the expected effect? It makes a lot more sense when you code it...
Basically a shader is what you make it. You don't have to do anything. You can just set the colour to white and drop out. Or you could do something complex like calculating subsurface transmission and scattering.
02-23-2004, 03:18 PM
ok that makes sense, so the shader is a subroutine that allows the generation of the surface color.
Kinda makes sense. But isn't it really inefficient?
The efficiency depends on the shader itself. The renderer will have to jump into a shading subroutine anyway (even in renderers with fixed shading algorithms), it's up to the user to determine how simple or complex the shading algorithm is.
02-23-2004, 04:29 PM
Exactly, if you think at some point in the pipeline the renderer has to decide what colour to make a particular pixel, a shader is just opening that process up to user intervention.
02-23-2004, 10:38 PM
Yeah, but that process is going to be run hundreds of thousands of times!!! Really the best thing to open up to the lay computer artist/non-programmer?
I'm guessing most people have to rely on the actual shader being generator by another program, and fiddling with the parameters.
It works in both ways: You can write shaders that are more complicated than the application's default, resulting in slower rendering, but you can just as well write simpler shaders that render faster than the application's defaut material.
The real benefit comes when you start optimizing: You use complex shading only where necessary and render the rest of your scene with very simple shaders.
Programmable shaders are not slower than non-programmable materials, they just give you a lot more flexibility.
02-23-2004, 11:42 PM
So are they scripted and then interpreted, are are they encoded in a native language eg C++ and then compiled and linked in?
That depends on the applicaiton.
02-24-2004, 12:41 AM
Ok, just wondering because obviously scripted us going to be quite a bit slower than compiled.
01-17-2006, 01:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.