AFAIK, you won’t get the exact same blending results in multipass as you would in multitexture mode.
Interesting exercise though. Try REPLACE or DECAL on the first pass and MODULATE on the second. This may produce the effect you want. (I’m assuming you aren’t using ENV_COMBINE or something wacky like that.)
This means one cannot take advantages of more texture units (say GeForce(2 units) vs RadeON(3 units) GeForce3(4 units) if one wants to have exactly same visual results on all systems, doesn’t it? Sounds bad
I’m writing an app which supports (and requires) 2 units by default, and I wanted to add support for 3 and 4 units, so now I guess I will stick to 2 units.
Like I mentioned, I’d try it out. I’m only speaking from my experiences, and those are admittedly few with multipass methods. Typically I use multitex or no multitex, and avoid multipass regardless.
It really depends on what kind of multitextured function we’re talking about. There are things you can do in multitexturing that you simply can’t do with multipass. Dot products (for cards that support them in multitexturing) come to mind.
But, if we’re talking about fairly simple blending functions (things that can be written without register combiners, or dotproduct3), then you should be able to do it with multipass.
The thing is, the more textures you use, the more likely it is that one of the blend modes is going to be a dot product or something that really needs the flexibility of register combiners. If so, you might still get away with it by doing the dot product in one pass and then blending it with the rest in the next pass.
Personally, I detest multipass rendering, so I would simply disable those features if there are insufficient texture units avaliable.
Well, in my app I have materials which can have an arbitary number of texture maps, and for some things I need at least 5 or 6 to avoid wasting texture memory so i guess i’ll have to live with that