Q3A-stlye shaders

I was looking for a way to ‘detach’ the mesh data of a model from it’s ‘skin’ data(i.e. just load some geometry data from a file and be able to texture map it etc. in different ways easily) and I came across shaders(I had heard of them before but didn’t have the time to look into them).I don’t have a GF3 or 4 so I’m going to try the software version since I need texture mapping in my app and I need a clean and general way to do it.
Now the question is this(not connected to Q3A shaders,just shaders in general):without taking into account the sorting of shaders,what’s the best way of compiling the script into a more efficient form wich can be used for rendering?I was thinking of compiling the needed state changes into a display list,one for each multipass stage,then you can simply call the list and render the data for each pass etc.
Also, assuming you don’t allow multipassing in your shaders you don’t need each shader to know what is going to be rendered with it.You simply ‘bind’ the shader and render the data.If you want to do multipassing though(almost always,even as a fallback) the shader needs to know what data to render since he might have to re-render it when mutipassing(this might also be usefull when using a shader tree to minimize state changes etc.).So the question is:what would be a good way to store info about what data a shader has to render?Of course it would be best if I could use VA/CVAs,disp. lists and immediate mode but I guess immediate mode isn’t so implortant.Also since I’m doing CLOD the data each shader has to render might be dynamic so I suppose I can’t have a render list for each shader and list and unlist meshes to be rendered.I’d have to respecify everything in each frame.Anyway I hope something of his makes sense.

PS o thos HW accelerated shaders do all the things those Q3 shaders did.I mean controlling texturing,etc. on a mesh level or do they only work on a per-vertex,per-fragment and per-pixel level?

Q3A’s surface shaders are something totally different to vertex or fragment shaders, though one could probably emulate them to some point with a correct vertex shader.

Great!that means I’m not gonna go about implementing something that’s allready obsolete.Now about those implementation details…


taking a look at Alex Vlachos excelent doc at Ati is a good start. (Designing a Game’s Shader Library for Current & Next Generation Hardware - GDC 2002)

also there are some siggraph papers talking on this subject.

Tiago Sousa

Also, zen, since you mentioned ‘Q3A style’ perhaps a look at the documentation for Quake3’s shaders might be a good read - I believe it’s somewhere over at www.quake3arena.com, (then go to tech licensing and free downloads or whatever) it’s listed as the shader manual and is a .doc file.
Even though it really only tells you how to write them for Q3 interpretation, it might also provide useful insight for your own design.