Shader permutation problem ( again )

Started by
13 comments, last by wolf 15 years, 5 months ago
Quote:Original post by andur
You include all common elements/functions from shared seperate files, so, changing the lighting falloff only necessitates recompiling the shaders that use that particular lighting model. Easy to parse fx files for the #includes.

Is this only possible in a makefile-style build system? I would like to do this in the Visual Studio dependency checking system (where .fx files are processed according to a custom build rule) but can't figure how to do it.
___________________________Buggrit, millennium hand and shrimp!
Advertisement
Quote:Original post by samv
Quote:Original post by andur
You include all common elements/functions from shared seperate files, so, changing the lighting falloff only necessitates recompiling the shaders that use that particular lighting model. Easy to parse fx files for the #includes.

Is this only possible in a makefile-style build system? I would like to do this in the Visual Studio dependency checking system (where .fx files are processed according to a custom build rule) but can't figure how to do it.


I don't think that there's any way of doing it with Visual Studio's dependency checking system, at least, not without installing/creating some 3rd party plugin.

What I did, was, I wrote a little ShaderCompiler tool that runs as a pre-build step in my project and scans through the .fx files, and seeing which need to be recompiled and what depends on those files. Then it fires up a bunch of fxc processes and compiles them in parallel. It was only about a 100 lines of C# code to write such an app (I can't share it with you, as I wrote it at work). Typically, takes only a few seconds to make the necessary changes, and virtually no time if you didn't change any .fx files.

Oh, and as a little tip, if you do this, redirect the stdout of the fxc processes that you spawn, so that they show up in Visual Studio's output window. Then you can see what its doing, and any build errors will show up in the error list and be clickable to jump to the problematic lines/files.
Quote:Original post by andur
I don't think that there's any way of doing it with Visual Studio's dependency checking system, at least, not without installing/creating some 3rd party plugin.

Do you know of any particular 3rd party plugin that could help?

Quote:
What I did, was, I wrote a little ShaderCompiler tool that runs as a pre-build step [...]

I see, thanks for the advice. I just hoped I could use the "custom build rules" mechanism of VS as it is very nice to use. Unfortunately it seems it is a bit underpowered.

A different approach seems to be: run a VS macro in a pre-build step and use VCLinkerTool.AdditionalDependencies to add the dependencies dynamically. I haven't tried this though.

[Edited by - samv on November 4, 2008 3:45:38 PM]
___________________________Buggrit, millennium hand and shrimp!
Quote:Original post by samv
Quote:Original post by andur
I don't think that there's any way of doing it with Visual Studio's dependency checking system, at least, not without installing/creating some 3rd party plugin.

Do you know of any particular 3rd party plugin that could help?

Quote:
What I did, was, I wrote a little ShaderCompiler tool that runs as a pre-build step [...]

I see, thanks for the advice. I just hoped I could use the "custom build rules" mechanism of VS as it is very nice to use. Unfortunately it seems it is a bit underpowered.

A different approach seems to be: run a VS macro in a pre-build step and use VCLinkerTool.AdditionalDependencies to add the dependencies dynamically. I haven't tried this though.


I don't know of any available plugins that do this automatically. I know that there are a few that do hlsl syntax highlighting/intellisense, but, I've never used any of those (I just tell visual studio to use the c++ editor for .fx files, which is fine for my needs). I seem to recall seeing one of these highlighted in one of the Weekend Reading journal entries here on GameDev.

I've never tried to use a VS macro for anything, so, I'm afraid I won't be of much help there.

The seperate program has a couple of other advantages. It can be run outside of visual studio, it could be set up to be called by your game engine to compile shaders on the fly, and if you aren't tied to the visual studio build button you can compile your shaders without compiling your game/engine as well (though you could probably set up a dummy build project/configuration to only do shaders).
Hey Christer,
Quote:(2) in your "simpler" system you have the problems of remembering to change every relevant shader file when you want to change e.g. lighting
No just a function in a header file.

I hope the ubershader approach will go well for you. Looking forward to your post-mortem regarding it at some point on a PS3 conference :-)

This topic is closed to new replies.

Advertisement