Most Efficient MultiTexturing

31337 · December 23, 2002, 9:10am

This is my first post in the advanced forum (I think) and I’m inquiring about multitexturing. My current method is by using Glext.h (Check out my post in the beginners forum about multitexturing) and its just not working out.

So, what are some other methods for multitexturing? Can I get some links? Whenever I search I just find stuff on the same old glext.h method. I’m looking for the most efficient way of multitexturing, specifically on geforce 3 and 4 cards. The reason why I’m asking is because I saw a post saying that nVidia doesn’t recommend using ARB or such.

Any help/advice would be greatly appreciated - thank you

rgpc · December 23, 2002, 4:02pm

There are two basic ways to do multi-texturing.

Multiple passes
Register Combiners.

I cannot say I have ever tried (1) because (2) has been around for almost as long as I’ve been writing GL and has certainly been around alot longer than I’ve been using Multitextures.

Equates to using ARB_texture_env_combine. And is more efficient than 1.

I can’t say I’ve ever read anything where nVidia have said not to use the ARB extension (doesn’t mean it doesn’t exist, I just haven’t read it).

From looking at your code snippit I presume that your multitexture is not working because you are not setting up your combiners correctly.

Try something like this…

  glActiveTextureARB(GL_TEXTURE1_ARB);
  glBindTexture(GL_TEXTURE_2D, nTextureID2);
  glEnable(GL_TEXTURE_2D);
  glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_EXT);
  glTexEnvf (GL_TEXTURE_ENV, GL_COMBINE_RGB_EXT, GL_REPLACE);
  glTexEnvf (GL_TEXTURE_ENV, GL_COMBINE_ALPHA_EXT, GL_MODULATE);
  glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE1_RGB_EXT, GL_PREVIOUS_EXT);
  glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE1_ALPHA_EXT, GL_PREVIOUS_EXT);
  glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE0_RGB_EXT, GL_TEXTURE);
  glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE0_ALPHA_EXT, GL_TEXTURE);
  glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND0_RGB_EXT, GL_SRC_COLOR);
  glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND0_ALPHA_EXT, GL_SRC_ALPHA);
  glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND1_RGB_EXT, GL_SRC_COLOR);
  glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND1_ALPHA_EXT, GL_SRC_ALPHA);

pbrown · December 23, 2002, 4:31pm

There’s no problem using extensions like ARB_texture_env_combine on NVIDIA platforms. If it does what you want, there’s no reason not to use it.

We do not support ARB_texture_env_crossbar (where you can pull texel lookup value from other stages), because it wasn’t possible to support both this extension and the shipping NV_texture_env_combine4. The difference was only in a number of generally uninteresting error cases (e.g., what happens if one stage refers to another that has an inconsistent texture). OpenGL 1.4 also includes ARB_texture_env_crossbar functionality as a standard feature. OpenGL 1.4 relaxed the requirements for these special cases, and we were able to support it.

If you don’t care what happens if you reference a disabled or inconsistent texture using the crossbar, I think that you should be able write one code path that runs if any of OpenGL 1.4, ARB_texture_env_crossbar, or NV_texture_env_combine4 is supported. (I’d recommend double-checking this suggestion to be sure that all the enums are the same.)

NV_register_combiners (provides a number of interesting modes that aren’t available in the ARB extensions. You can apply a number of mappings to inputs, outputs, select inputs arbitrarily, produce multiple outputs in each stage. The biggest advantage might be temporary storage – you can compute one result in the first stage, a second result in the second stage, and combine the two in a third stage. That’s something you can’t do with only the ARB extensions. It’s more powerful and can sometimes produce better performance (by reducing the number of blending stages you need).

The only caveat is that it’s an NVIDIA extension, so will not run on all platforms. You may already have multiple rendering paths to support multiple platforms with different capabilities. For example, what happens if you don’t support ARB_texture_env_combine? If you are already set up that way, adding NV_register_combiners support shouldn’t be hard if there are performance or functionality benefits to be had.

31337 · December 23, 2002, 4:51pm

thank you for both of your replys and I’ve found them very helpful.

In response to pbbrown: If the nvidia extensions wouldn’t work very well on non nvidia cards than I don’t believe that is an applicable solution for me, simply because I want it to run on the computers at my school as well. Are you with SGI or nVidia or some other openGL affiliated group? Thank you for your reply it was very helpful.

In response to rgpc: I plugged in your code and its still no good. It didn’t seem to change anything at all. I’m looking at the bsp loader I’ve been studying (gamedev.net’s bsp tutorial #3) and they have two calls to glTexEnvf. One which is during the lightmap generation function (glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE) and one in the makeTexture function (glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE)

pbrown · December 26, 2002, 3:57am

31337:

I work for NVIDIA. You can tell from my profile – click the icon with the face and the question mark on it to bring up a poster’s profile.

With vendor-specific extensions, you would need multiple rendering paths to run on systems that don’t support these extensions. Even with more standard ARB extensions, you would still need multiple rendering paths to run on systems that don’t support the extension. For example, I don’t know if the systems at your school would support ARB_texture_env_combine or not.

This is a common problem. You can code to a least common denominator, but you would miss out on “fancy” functionality altogether. Or code to one or more extensions, but you would need fallback paths to handle systems that don’t support them, or at least don’t support them with adequate performance. Or you could effectively require some extensions, and refuse to run if they aren’t supported. There is a set of extensions that is supported on a wide range of devices.

Most game engines follow the multiple paths approach (usually determined automatically), but provide a bunch of tweakable knobs to control the engine. Performance is very important for games, and some nice effects will significantly slow down less powerful systems.

This is the same kind of issue discussed in the very long “fixed function vs. programmable” thread before it degraded into a long philosophical discussion having almost nothing to do with OpenGL.