Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / managing .fx techniques Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
ganchmaster

March 07, 2005, 10:50 AM

Using D3DX .fx files to manage shader programs is powerful. But if you start developing shaders which have many options (ie bump or not, specular map or not, shadows or not, detail map or not, lighting function) you end up with a combinatorial explosion of techniques. Managing the pixel and vertex programs is not _so_ bad because you can use uniform parameters to generate different versions of the programs, but you still have a large number of techniques which have to be uniquely named and selected based on runtime parameters.

I was thinking of handling this by building an offline compiler which would generate a header file containing constant definitions (static bool g_bShadows = true, etc.) and then repeatedly compiling the same .fx file (with fxc.exe) which includes the header. This would give me a bunch of different effects; I would much rather have a single effect with a bunch of different techniques, but maybe it would be ok. And then I could name them in some systematic way and develop some code to load them and select them using the naming convention...

But anyway, I'm wondering if anyone else would care to comment on strategies they are using to manage many variations of HLSL techniques. Or maybe there is some simple way of parameterizing techniques that I missed in the documentation.

 
icosahedron

March 17, 2005, 10:26 AM

What you describe is more or less what we do. I have a single FX file, and I use the compile defines array parameter to set options and then compile them based on the parameters selected. I also cache these in a hash map so that if the same parameters are requested again, I simply retrieve the shader from the dictionary.

After doing it this way, I wish I would have done it more shader specific. It's messy and hard to debug the shader. I would suggest that you delineate what types of shaders you are going to have and create custom FX for them. You might be able to use certain parameters such as light count on each shader type, but even then, it's usually just easier and not much worse to just stuff 0s into constants.

DX9 used to have something called the fragment linker, that worked something like what you're talking about, but it was removed (though it might have been put back). Also, the latest ShaderX book has a technique that looked more complete that you might want to peruse at the book store (though the book is probably worth owning it its own right).

Good luck.

 
ganchmaster

March 17, 2005, 02:53 PM

Thanks for the response. It definitely seems like there are serious issues that come up with the shader autogeneration system. As you said it could be messy and hard to debug, and also I would guess a "frankenstein" shader might be less efficient than a hand coded specific one. Maybe that route is not best after all.

 
This thread contains 3 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.