So okay assume you have a scene, and you have objects in there that use any combination of 5 shader effects. How do you do this? Well there are the usual answers, code every permutation of the 5 effects that the scene requires, or make an uber shader which does all the effects but each can be optionally deactivated through shader parameters.

The problem with the first approach is that it is code intensive and a maintenance nightmare, if you want to modify how much things glow in a scene then you have to adjust the glow code in every shader which might not be a lot of work in the above example but can be in more involved scenes.

The second approach fixes the first's problem, but then you have code constriction, you can only have so much code in a shader before you reach the instruction limit. Meaning that each effect has to be coded with minimal instructions for the uber shader to encompass all you need, and in some cases this is impossible. The uber shader approach's weakness is that the supposed uber shader that does it all can only do so many effects before you just can't add anymore to it.

There is a third approach. However it's not very well documented and god help you find tutorials or information about it due to it's unfortunate name. The third approach is using shader fragments and assembling shaders dynamically as they are needed. This is a great idea! I've thought about it and came up with an interesting idea to design a Scenegraph like approach to specify what models use what shader fragments and in what order. Basically you have this Scenegraph like object where each scenegraph node is ascribed a shader fragment, which each of it's children use to generate their shader. the end result is that the traversal down the tree of nodes yields the fragments and their order of execution at a given node. The problem is that the topic of shader fragments how to code them how to combine and compile them is hard to google, because a much simpler topic with overwhelming coverage is the topic of Fragment Shaders which you may or may not know is another term for pixel shaders.

Does anyone know of good sources of information concerning the writing and runtime compiling of shader fragments? Or if this scenegraph like shader system is feasible on the Xbox360?

It's doubtful you'll find any specifics on Google regarding this.  It's such an open ended problem and there are tons of different ways to implement what you're describing, all of which of course result in the same thing -- a highly dynamic system which is capable of combining fragments into a final shader.  In the past, I've found the most difficult aspect of this is the C++ to HLSL interface responsible for dynamically organizing Vertex Declarations, shader constants, and shader inputs.

I would define "effect profiles" and let the object select one of the profiles. Profiles can match to techniques, say. One of the profiles would use all 5 effects, and then there would be a few other profiles for common combinations. However, if you need a combination that's not defined, then you simply pick one that's a superset, and set the "strength" of the ones you don't need to 0 in that case.

Dark flow:
There are DirectX9 objects used specifically for HLSL fragments
 Their Declaration: http://msdn.microsoft.com/en-us/library/ee418614%28VS.85%29.aspx
There are also an assembler and a linker for these shader fragments available within DX9 according to other sources but I can't find them. This all suggests that very little is required from me other than the understanding of how to code the fragments correctly, and knowledge of the assembler and linker that exist somewhere in the DX9 library.

Jwatte:
Huh, I never thought about that one, I guess it didn't come to me to think that you could call multiple vertex and pixel shaders in a row through a technique... I'll have to give that a try but... I'd like to understand this aswell.

Thanks for the help however I THINK I found a good source on the msdn, it was just very well hidden. Apparently DirectX after 9 (aug 2005) only give fragments a passing mention and no information about them is given. BUT DX9SDK (aug2005) includes a sample called FragmentLinker. This should shed some light on things (currently downloading).

EDIT: Upon further investigation it appears that the FragmentLinker class which is required in the use of shader fragments did not make the cut to XNA, nor did it to the Xbox's version of DirectX&.Net. Another item of interest is that DX10 doesn't have the FragmentLinker. It would appear that Microsoft has deserted the poor FragmentLinker. :(

Oh FragmentLinker I hardly knew ye. Oh well.

DX10 has other options to combine fragments instead of the old fragment linker. However, XNA only supports a common subset between PC and 360, which does not include runtime shader manipulation at all.

One more thing I can pray for the next gen xbox.

1) Cuda
2) Runtime shader manipulation.

Ben Andersen:

One more thing I can pray for the next gen xbox.
1) Cuda

Knowing that CUDA is NVIDIA-only, and hearing the rumors/reports that Microsoft will probably be partnering with ATI again, that doesn't seem entirely likely.
Also, CUDA is only usable from C, so I'm not sure how that would help in XNA land.
Another option would probably be OpenCL, which is not tied to any vendor, but most likely MS would rather support it's own Direct3D 11 ComputeShaders.

Yeah when I said Cuda I didn't really mean the NVidia specific Parallel computing suite, but rather the concept of offloading computationally complex problems to a gpu or similar parallel computational unit. The point of this is to provide developers with a powerful way to deal with computationally intensive problems that cannot be sped up any other way than by having multiple computational elements running several iterations simultaneously. I don't know about Cuda being only usable from C... I don't think that matters really, since it's just injecting code into the graphics hardware, just like putting a shader into the gpu. But yeah you are right they will still be using DirectX HLSL Shaders (probably version 5.0 or maybe beyond) since, well it's XNA and it wraps DirectX.

Ben Andersen:

I don't know about Cuda being only usable from C... I don't think that matters really, since it's just injecting code into the graphics hardware, just like putting a shader into the gpu.

Trust me, CUDA is C-only right now, and they are working on supporting FORTRAN and C++ in the future.

Ben Andersen:

But yeah you are right they will still be using DirectX HLSL Shaders (probably version 5.0 or maybe beyond) since, well it's XNA and it wraps DirectX.

You can't even be sure they'll support ComputeShaders. It's a lot of work creating a managed wrapper for something like this, and it really is questionable whether or not is makes sense to enable GPU computing in XNA depending on how many people would have need for it.

Okay. I've done a little in depth research. Until today Cuda has just been a concept of using shaders to do computationally intensive work paralleled across multiple gpu codes. Cuda is more than that. shader programs in Cuda are not standard shades at all, they are actual C programs that are compiled and injected into the hardware via cuda's tool kit libraries. So that explains the C constriction, it's in reference to the language the toolkit handles for the "shaders". My point stands however that if you simply port the tool kit libraries Cuda should still work in C# C++ or whatever language.

I suppose I SHOULD have prefaced my last few lines of my post with "if it happens" because yeah if the next console has graphics hardware that can handle cuda like operations and they want to give it to XNA developers they'll do it through DirectX because it's XNA and it wraps DirectX.

Of course I realize now also that you didn't mean it to be anywhere else either since openCL doesn't mean that it's constrictive to something other than DirectX that's talking about the programming language the "shaders" use.

"Thus I promptly stick my foot into my mouth"