   using D3DTEXTUREOP in multipass
  I've been struggling with a way to represent render and texture states in a well designed, API independant way. I think i finally have something, but i'm not sure about part of it. basically, there is a base class called Shader. it has only one variable, a pointer to another shader in case its derived one is unsupported. so for example, this could be shader that combines two shaders:class Combiner : public Shader{   Shader * Arg1;   Shader * Arg2; TextureOp ColorOp;   TextureOp AlphaOp;}; a texture would be derived from shader, color picker which would have an enum to let you pick from possible color sources like vertex diffuse, vertex specular, texture factor, etc. a texture transformation, which would let you put in coord generation stuff, and a matrix if environment mapping wasn't on.as you can see, it would also make a tree, so each shader could be used alone or part of a bigger shader.the problem is that the stage cascade on the card is set up 'linearly', as in the two arguments for a stage can't be *anything*, like the shader class has. i wouldn't mind having to make two or even three passes for complex shaders, at least half of all shaders will be simple textures anyway. what i'm having trouble with is setting it up so two shaders can use any given texture op. some work, because they can be represented with the alpha blending render states, but not others. at some point, i'll make a better render state compiler that only uses extra passes when absolutely necessary, but for right now i'm just trying to get any shader combination to be able to blend with similar capabilities of the D3DTEXTUREOP enumeration.edit: after reading it, i realized i didn't really ask my question, doh. is there a way to use the D3DTEXTUREOP states in multiplass?[edited by - billybob on August 3, 2003 10:14:15 AM]
  Im not sure if I fully understood your question, but..What I have done is simply set one colorarg to D3DTA_CURRENT and the other to D3DTA_TEXTURE and that way you can slowly build up your commands one by one.. (does this make sense?) So you dont really have a tree anymore, you kindof braking things up into seperate render-to-surface style things and then slowly combining them..The other question of course is, why are you doing this anyway? I would imagine most people have PS1.0 functionality now anyway... you could write some program that generates some simple Cg file and use that to compile platform-independently...(I ended up discarding my complex multipass render like this in preference of shaders..) (also it didnt work too well  ) ;  I get the texture cascade, using D3DTA_CURRENT and all, and it works fine until it runs into a shader thats too complicated. its also a pain in the ass to set up the combiners, because they work if one of the arguments is nearly anything but another combiner. as for the why not PS1.0, I have that also, I''m just trying to figure out a non-programming way (they would hook these shaders together in a windows GUI app) for the artist. 