I guess the best way to explain it would be like this. Say my video card only supports up to 2 texture units for multitexturing(exageration for simplicity), now say that my model had 4 texture layers. All 4 textures need to be combined together to make some sort of cool looking texture, but since it seems that glTexEnvf only works with the current texture units 1 and 2, I need to call glDrawElements again for the second two texture units. Only problem is, is that it doesn’t work. What happens is that the second call to glDrawElements overwrites the previous two textures draw.
Am I suppose to use a glBlendFunc in this situation?
I want to deal with texture layers like this so that my algorithm won’t even stutter if it detects differant max multitexture unit amounts.
Dude, thats multipass. Using two render calls on the same geometry, with differing render states is multipass, and the only way to combine the results of multiple passes is using blending.
Dont mean to offend, but I was under the impresion that you were quite advanced in OpenGL, and am surprised you’re asking this.
No offense taken. I am still quite weak in a few places in OpenGL. To name them: Vertex Programs, Stencil Tests, glBlendFunc and MultiTexturing.
Other than that, I’m good to go .
So a multipass is when you have to actually call glDrawElements again to blend over the same geomentry, correct? This is where glBlendFunc scares me . Is it possible to carry accross the same blending mode from glTexEnv over to glBlendFunc?
I sound like a newb
If I had more time to experiment with this stuff, I’d know it by now. Once Spider3D has a solid foundation(it does now because I can export model directly from LightWave), then I can impliment all the stuff I don’t know using Spider3D.
Also, I usually go looking for info before coming to places like this, so it may seem like I know more than I do simply because I only answer question I’m pretty sure I know the answers too…and that’s far and few between
[This message has been edited by WhatEver (edited 06-07-2002).]
So a multipass is when you have to actually call glDrawElements again to blend over the same geomentry, correct?
Yep.
This is where glBlendFunc scares me
It’s not that bad once you know the equation. The equation is.
(Src * SF) + (Dest * DF)
Where Src is the computed fragments of the current pass. i.e. the result of the multi-texturing, the value computed at the end of Register combiners, the value that is written into the framebuffer under non blend.
Dest is the color in the framebuffer.
SF and DF are source and destination blend factors. These are the GL_ONE, GL_ZERO, GL_SRC_ALPHA, etc etc… things.
Theres also a blend equation extension, that allows you to use subtractive blending, and reverse the order of subtraction also.
You dont have the as much flexability with blending, as you do with RC’s or even TexEnv, which can make converting heavily textured geometry difficult to split into multipass, if they all use quite complex Texture combinations. Usually they dont tho.
I’ve been trying to figure this out for 4 hours now. I have my DOT3 bumpmapping working in another program of mine, but I can’t get it going in a new program.
This code is suppose to blend GL_TEXTURE1_ARB on top of GL_TEXTURE0_ARB. If I only use GL_TEXTURE0_ARB, then I get a bumpmapped surface that is black and white only.
Any suggestion why GL_TEXTURE1_ARB isn’t blending properly?
I couldn’t find the latest glext.h also, so I just used the hex value I got from NitroGLs code because I was avoiding defining the constant myself. Lazynes on my part.
Anyway, anyone know why the second texture unit won’t blend properly?
If it’s anything like glClientActiveTexture, it selects the texture unit for the next call to glTexCoordPointer (for Vertex Arrays). If you want multiple sets of tex coords with vertex arrays (ie you want multitexturing), you need to select multiple pointers.
So you first call
glClientActiveTextureARB(GL_TEXTURE0_ARB);
glTexCoordPointer(duhdahdah); //texture coordinates for unit 0
glClientActiveTextureARB(GL_TEXTURE1_ARB);
glTexCoordPointer(dumdadiddy); //texture coordinates for unit 1
…
Hmmmm, maybe they should have used a different name to avoid confusion, glClientAvtivateTextureArrayARB…LOL that’s a long function name .
Someone had a problem compiling Spider3D in their program because of duplicate extension function names, so to solve that problem I decided to use the s3d prefix on my extensions.
Thanks for all the help guys. The functions used for multitexturing are making a lot more sense now.