Freaking Shaders !
Today I was going to implement a basic shader with support for texture.
Shaders are separate programs for the graphic card that will execute specific code based by some parameters.
I was trying to keep the shaders interface system as simple and generic as possible and I got stuck.
Shaders do suck, but I'm not sure if they necessarily have to suck. What sucks is how one has to think..
For every 3D mesh there is one or more sections (primitive/display lists) with different materials. Each material involves different properties. Vertex data normally includes 3D coordinates, but also texture coordinates, color values, normal coordinates.
Some materials will need no texture coordinates, some will need more than one. Some will need no texture mapping, some will need one texture map per every texture coordinate, some will need a different number of texture maps and texture coordinates.
So each material brings different needs, but that means that there are potentially a different vertex and pixel shader programs, all of which need to be connected to the vertex and material data (a material can list one or more texture maps).
I would like to keep the structure flexible, but I would also like to simplify the interface.
One obvious choice is to decide before a limited set of shaders, a fixed set of permutations, but in the long run, one needs many possible combinations depending on specific needs.
I'm not up to writing a 3D engine, my actual goal is more into the future, where programmability is key.. where nothing is quite decided.
I want to face the problem with an open mind. I'm not sure if I need to try to forget shaders as they are, or if I need to learn more on how current games assemble and use their shaders. I can definitely use some friend's opinion here ;)
If you read to this point, let me also add that from this month I was, with great honor, magically appointed to lead some sort of 3D research, mostly on the future of 3D geometry.
There isn't really a group quite formed yet. so, I'm currently leading myself on this and actually getting stuck with the present 8)
My salary hasn't increased, but my meetings have. However I do realize that no standard salary increase is going to change my life. If I need to make a (positive) break at the economical level some day, I will have to do something extraordinary that comes out of my spare time. The only other option it would be to something cool with my company and make a big deal of it publicly. However I don't expect any big break on anything, my contribution will hopefully be useful, but definitely not dramatic.
ole'
- Davide's blog
- Login to post comments
hhmm i think we talked about
hhmm i think we talked about shaders when we had the pleasure of hosting mr Kaz here in SF. And I briefly described the shader model I tried for our next gen engine. The shader is basically something like this:
renderData* mpRenderData;
callbackBlock* mpDynamicCallbackBlock;
pixelShader* mpPixelShader;
vertexShader* mpVertexShader;
textureBlock* mpTextureBlock;
Very generic. Render data contains info about the vertex stream with a pointer to the actual vertex and index data. Callbacks are pointers to functions for setting shader constants and render states. pixel and vertex shaders are just like the name suggests. And texture block is a list of texture pointers for this shader.
The fact that those are all pointers allows multiple shaders to share same textures, geometry etc etc...
Everything is built offline during the asset processing stage, based on user parameters for each shader, so vertex and pixel shader code, number of textures, etc is all precomputed. The callback functions are referenced by common index table that is shared between game and tools.
So, I guess the glue is the
So, I guess the glue is the callback ?
I was thinking about using callbacks yesterday.
Notice however how normally still we end up with multiple vertex properties that are not necessarily needed for the whole mesh.
For example a mesh may have a portion with one texture and another with two textures. But because vertex pool is only one, every vertex will have storage for two texture coordinates allocated, regardless on whether that vertex actually corresponds to primitives with more than one texture.
mumble mumble
Ah, I have the vertex stream
Ah, I have the vertex stream also being generated based on user parameters for the shader. So vertex format is optimized per shader. On consoles the callbacks are really only needed to set any dynamicly changing states, like light positions or alpha fading etc etc... since any persistent states can be stored in a precomputed display list. However on the PC I dont think that is possible...
Similar thing
When I was doing GCEmu (Game Cube Emulator) I ran into similar problem. There a shader needed to handle different kinds of settings, texturing levels and so on. Finally I ended up by writing a dynamic shader generator (with cache) at the runtime level. Depending on my actual needs I was just generating necessary shaders.
The downside of it was to write shaders in the low level shader code and not using Cg or whatever else crap. However at some point I even implemented optimizations, templates and predefined functions and I ended up with pretty decent shader generator.
This thing had one more advantage that back then the shader pipeline memories were short and I could really squeeze the code well.
Another thing was the debugging hell - the only way to debug those shaders was just print them out and look at generated code.
If you have too much time on your hand you can look at my garbage: GCEmu@Sourceforge
I got the source but all I
I got the source but all I could find was a uber(all inclusive)-shader.
I think I need to go home and come up with some revolution.. trash things, concepts.. I'm starting to feel like I'm being dragged into the vortex of current limitations.
It's a bit like when one consults those "Gems" or "Shaders" books, with all those tricks, all those workarounds.. and suddenly you live in a world of facking limitations and facking tricks.
fack fack 8)
cool