Have you called glGetIntegerv with GL_MAX_TEXTURE_UNITS_ARB ?
I would not like to get "as granted" that you''re limited to 2 texture units. As I''ve written before, if your drivers can do it then you can do it, no matter what your graphics card is.


You can find documentation about GL_COMBINE in the OpenGL specifications (go to opengl.org to get it). In the OpenGL A Spec 1.4, it''s in chapter "3.8.13 Texture Environments and Texture Functions".

Without texture environment, you can do :
GL_MODULATE (since OpenGL1.0) : multiply the previous fragment with the texture fragment
GL_REPLACE (since OpenGL1.1) : use the texture fragment regardless to the previous fragment
GL_BLEND (since OpenGL1.1) : use the texture''s color (RGB channels) to blend between the texture constant color and the previous fragment
GL_DECAL (since OpenGL1.1) : use the texture''s alpha channel to blend between the texture''s color and the previous fragment
GL_ADD (since OpenGL1.3) : add the texture fragment and the previous fragment
GL_COMBINE (since OpenGL1.3) : setup your own texture combiner

The texture combiner (GL_COMBINE) allows more than the scheme "Operation(PREVIOUS, TEXTURE)"
With texture combiners, you specify yourself what is the equation and what fragments you attach to this equation.
For instance, there exists the MODULATE combiner (that I used in the lines of code) that computes :
OUTPUT = ARG0 * ARG1
The difference with the GL_MODULATE texture environment function (described a few lines above) is that you''re not limited to modulate the PREVIOUS fragment with the TEXTURE fragment. It''s up to you to decide what you set in ARG0 and ARG1. For instance, you could compute TEXTURE * TEXTURE, or PREVIOUS * PREVIOUS if you want.

Here''s the line-by-line walkthrough :

glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB);
Tell OpenGL to use a texture combiner as environment function.

glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB_ARB, GL_MODULATE);
Ask OpenGL to use the MODULATE combiner which outputs ARG0*ARG1

glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_RGB_ARB, GL_TEXTURE);
Select the source of ARG0 : we take the TEXTURE fragment

glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_RGB_ARB, GL_SRC_COLOR);
Select the operand of ARG0 : we take the RGB channels of the source. That is, we take the texture''s RGB fragment.
If you want, you could use the alpha channel instead. You would call glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_RGB_ARB, GL_SRC_ALPHA);
Or you could use somthinglike "the opposite of the RGB color" and then you would call glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_RGB_ARB, GL_ONE_MINUS_SRC_COLOR);

glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE1_RGB_ARB, GL_PREVIOUS);
Select the source of ARG1 : we take the PREVIOUS fragment

glTexEnvi(GL_TEXTURE_ENV, GL_OPERAND1_RGB_ARB, GL_SRC_COLOR);
Select the operand of ARG1 : we take the RGB channels of the source

glTexEnvi(GL_TEXTURE_ENV, GL_RGB_SCALE_ARB, 2);
Specify a scale factor for the output : we scale by two

With this configuration, the texture unit outputs :
RGB_SCALE * ARG0 * ARG1
where ARG0 gets the RGB channels of the TEXTURE fragment, ARG1 gets the RGB channels of the PREVIOUS fragment, and RGB_SCALE is 2 :
That is, it outputs :
2 * texture rgb * previous rgb

That''s it !

Also, note that I used GL_*_RGB (GL_COMBINE_RGB, GL_SOURCE0_RGB, ...) because you define the equation for the RGB output. But you can use the GL_*_ALPHA tokens to configure the equations for the ALPHA output independantly.

Feel free to ask for more explanations. I''m probably going a bit fast.

ps: I''m posting the other answer in a few minutes...

There''s the other answer...


For your vertex arrays, you could have called :


And it would have worked too I think.

quote:

---

even though they''re the same for all of the textures because I''m mapping a sphere - a little sidenote here, though: I need to map the shadow on the planet independently of the texture coordinates as it has to stay at the same place while the planet revolves around its axis - my texcoords are prebuilt, so is there an easy way to make the necessary adjustments to the coordinates?

---

If you map texture coordinates on your sphere in the "U=longitude, V=latitude" scheme and if your planet rotates along the "vertical" axis, then yes there''s a very easy way : use the texture matrix.

quote:

---

"Yes" regarding the first sentence. I''m talking about TEXTURE0 and TEXTURE1 in the original post - these textures will be used with vertex arrays later on. They''re actvated by calling glActiveTextureARB() without the Client part which doesn''t seem to follow this logic...

---

If you''re calling glActiveTextureARB or glClientActiveTextureARB with GL_TEXTURE2_ARB, and if you really support no more than 2 texture units, then it is "almost" normal that there is no logic : the driver developers may have considered and *catched* the case for glActiveTextureARB, but they may have forgotten it for glClientActiveTextureARB. It''s a (small) bug in the drivers that (often) happens.

quote:

---

Original post by vincoof
Have you called glGetIntegerv with GL_MAX_TEXTURE_UNITS_ARB ?
I would not like to get "as granted" that you're limited to 2 texture units. As I've written before, if your drivers can do it then you can do it, no matter what your graphics card is.

---

I called glGetIntegerv() - my gpu/drivers only support 2 TU's. Sad.

Thanks for the walkthrough - it'll take me some time for me to become comfortable with the theory, but now I know where to look for the answers.

quote:

---

If you map texture coordinates on your sphere in the "U=longitude, V=latitude" scheme and if your planet rotates along the "vertical" axis, then yes there's a very easy way : use the texture matrix.

---

Here's what I tried:

1) set glMatrixMode(GL_TEXTURE)
2) retrieve the texture matrix
3) rotate it
4) set the updated texture matrix
5) switch back to modelview
6) draw

I can see changes in the texture movement on the sphere, but they are incorrect (not sure what's wrong - I think that, while before the shadow used to move in unison with the surface texture, it now moves faster - in that case how do I rotate it "backwards" - simply changing the signs for the rotation flips the texture's alignment on the sphere altogether. PS - excuse my poor mathematics - I never was too good at it...). Is the above method what you had in mind?

Furthermore: I'm currently rotating the planet around its center point - according to its rotation and its TILT (didn't apply tilt while testing the above code). I find it imperative that the planets have axial tilt - makes them look more real. Having fooled around with the texture matrix a little I think I see what you mean by only rotating the texture by the planet's "vertical" axis - rotating on the x axis (lateral) messes up the texturing quite a bit (never thought it'd be that easy to create such cool effects, though )... I haven't tried this, but would altering the upvector during texture matrix rotation solve the problem?

quote:

---

If you're calling glActiveTextureARB or glClientActiveTextureARB with GL_TEXTURE2_ARB, and if you really support no more than 2 texture units, then it is "almost" normal that there is no logic : the driver developers may have considered and *catched* the case for glActiveTextureARB, but they may have forgotten it for glClientActiveTextureARB. It's a (small) bug in the drivers that (often) happens.

---

When using only 2 texture units for multitexturing, glClientActiveTextureARB() produces a white surface only my graphics card when using vertex arrays (haven't tried procedural texture mapping). I think my gpu is simply too old...

quote:

---

Feel free to ask for more explanations. I'm probably going a bit fast.

---

Thanks, and - it's a good thing people don't charge money for reading this more than once

Crispy


--edit

I'd like to express my deepest dissatisfaction with the recent events on this site. I hold the profession of a hacker in quite a high regard and I consider any decent hacker an educated person, but such attacks on totally benevolent sites (.net, not even .com!) are just plain idiotic in my opinion. If you want to cause damage - here's an address : www.micro____.com - at least innocent bystanders won't be affected, but for the love of god, what have non-profit sites ever done to anyone?

[edited by - crispy on September 19, 2002 10:23:49 AM]

quote:

---

I called glGetIntegerv() - my gpu/drivers only support 2 TU''s.

---

Thanks for the asnwer. It''s much clear now !

quote:

---

it''ll take me some time for me to become comfortable with the theory

---

ok. don''t forget to come back and check it later. You''ll be so amazed to see how easy it is that you won''t believe it !

quote:

---

Is the above method what you had in mind?

---

Yes in the sense that you have to call glMatrixMode(GL_TEXTURE), but no in the sens that you don''t have to rotate the matrix : you have to translate it.
However, if you want to apply a shadow-like effect in this texture unit, I recommend 1D texturing with automatic texture coordinate generation.

quote:

---

never thought it''d be that easy to create such cool effects, though

---

texture mapping can show incredible effects. Unfortunately, we (humans) find it obvious to map a texture orthogonally, but when it comes to move/rotate/project the texture it seems hard as hell.
NeHe posted a news of an effect that Erik Fernquist wrote : the force field effect. It''s all about texture mapping and is a very good example of the kind of effects that can be achieved with nothing more than OpenGL1.0 ! No fancy extension used !

quote:

---

I think my gpu is simply too old...

---

I''m sorry but this is a wrong assumption even though I see what you mean.
IF the drivers tell you that you can use vertex arrays and that you can use multitexturing, then you HAVE TO BE ABLE to do it, let it be software or hardware or whatever.
IF your graphics card, or your drivers, do NOT know how to do it, THEN it''s up to the drivers NOT TO TELL YOU that those features are available.
In other words, that''s a bug in the drivers. That''s not the fault of your card.

quote:

---

such attacks on totally benevolent sites (.net, not even .com!) are just plain idiotic in my opinion.

---

Even though neither you nor I know what gamedev.net really is, I have to agree that the attack is a shame in the sense that the free contributors are the first ones to be annoyed. That is enough for me to blame the attack, no matter what gamedev.net may have done to get some people furious.