Quat

It will export meshes and other data from maya files, process vertex data, compile shaders, pack archives and do anything else that's necessary to generate efficient, runtime-ready data that can be loaded on the target platform. In our content system materials will define which permutations they can have, and will also specify which shader code to use.

Thanks for the info.  I'll have to see if I can get time scheduled in to make a more sophisticated system.  Does your build system also take into consideration different render pass settings and global settings?  For example, one might want to use a simpler shader for a reflection pass.  Also global settings the user sets could affect which shader permutation (e.g., shadows on/off). 

Are you using VS2012?  If so, then you don't need to create a custom build step as there is integrated support for compiling HLSL files.  Unfortunately there is a limit of one build rule for each HLSL file, so you have to play games with adding an empty HLSL file and just include the original target file to be able to specify multiple build targets from a single file.

Still on VS2010, but I've played with VS2012 for metro apps, and yeah, the one build rule is kind of annoying. 

I like the results of using video fire textures:

http://http.developer.nvidia.com/GPUGems/gpugems_ch06.html

Yeah I could do something like that.  Is that what people are doing?  I know I asked a specific question, but I was also looking for possibly better ways to manage shaders.  Do people just treat shaders like assets and lazy load them and store them in a hash table?

Also, if I need to sort the particles back-to-front for transparency based particles, would I just run another ComputeShader on the particle buffer to do the sort?

For the CS particle system, you update the various point quantities in the CS.  Then do you just instance a quad by drawing numParticle instances and sample the structure buffer you updated by the CS in the vertex shader?