During the rewrite, I want to improve the process of writing shaders so that I don’t need to write similar shaders multiple times for each shader permutation (say, for each surface, I have to write a shader for static mesh, skinned mesh, instanced static mesh… multiplies with the number of render pass), and instead I can focus on coding how the surface would looks like. So I decided to write a shader generator that will generate those shaders which is similar to the surface shader in Unity.[/quote]
To be honest, I don't understand why would he have to write a different shader for a static mesh, a skineed mesh, and an instanced static mesh... can someone explain?..
As far as I know, if you want a shader to behave the same in whatever surface you are using it, you shouldn't need to write one different for different types of meshes, no matter what.
or how can they differ that would make any one write multiple similar shaders for each?
thanks
why would you need a different shader doing the same for static/skinned/instanced meshes?
Author
basically that... I was reading this article http://www.altdevblo...ader-generator/ about a shader generator this guy made, but in his introduction he says:
Because sections of that shader would be doing different things for the different types.
Mesh isn't skinned? Then you don't need the code which pulls in bone weights etc for skinning.
Instanced mesh? Then you'll need to add code to pull the correct instance parameters in.
Shader generation to solve this problem is nothing new; our system (currently) uses shaders where units of functionality are #ifdef'd in or out depending on configs which are setup pre-compile which lets us generate multiple shader types from one source however the downside of this is that it does tend to lead to shaders which can be hard to read at times.
Mesh isn't skinned? Then you don't need the code which pulls in bone weights etc for skinning.
Instanced mesh? Then you'll need to add code to pull the correct instance parameters in.
Shader generation to solve this problem is nothing new; our system (currently) uses shaders where units of functionality are #ifdef'd in or out depending on configs which are setup pre-compile which lets us generate multiple shader types from one source however the downside of this is that it does tend to lead to shaders which can be hard to read at times.
You probably don't need different pixel shaders, but you'll need different vertex shaders, since the vertex format will change depending on if a mesh is skinned or not.
Author
You probably don't need different pixel shaders, but you'll need different vertex shaders, since the vertex format will change depending on if a mesh is skinned or not.
Yeah, I guess that was what confused me the most, since in this article he's talking about the pixel shader too...
Now, in this context, what role does Dynamic Shader Linkage has?... isn't it supposed to attack that kind of problems?..
Thanks!
Dynamic shader linkage can be used to solve certain cases of shader permutation problems, but not all of them. For instance you can't use it to change which inputs a shader uses, so you couldn't use it to solve skinning or instancing since those require different vertex shader inputs. Plus the API and shader syntax for dynamic linkage are pretty awkward to use, which I would suspect has contributed to the fact that almost nobody is using it.
Author
I see, that makes more sense now, thanks!
And besides using shader generators, are there any other solution alternatives to this problem?... (any more elegant than other)...
And besides using shader generators, are there any other solution alternatives to this problem?... (any more elegant than other)...
You can write shaders with #ifdef blocks around certain features, and the compile it for every permutation of features #defined on or off.
And besides using shader generators, are there any other solution alternatives to this problem?... (any more elegant than other)...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
