I think you can do it with two texture units, and without texture env combine :
texture unit 0 :
bind the non-glowing texture.
set the texture environment to MODULATE.
texture unit 1 :
bind the glowing texture.
set the texture environment to ADD.
For this to work you need the ARB_texture_env_add extension, which is supported by almost all graphics cards I’ve ever heard of. here is a non-exhaustive list
Yes but the moment you:
glEnable(GL_LIGHTING);
your glowing beauties are toast and are just another brighter color. In short: they are still affected by lighting.
The only way to do this is with multiple passes unless somone else knows of a better way?
Originally posted by bw359:
In short: they are still affected by lighting.
They are not directly affected by lighting. The emission map, by definition, does add color to the current colors defined by lighting.
If it does not give the results you want, try changing the ADD environment with DECAL. (beware your texture must be RGBA).
But the GL does not know a alpha map from a glow map from a regular texture map. It merely sees texels. If I am using OpenGL light sources and I apply, even in combination, a series of textures that I so happen to dub logically, emissive maps, but are really just elegantly blended textures… the end result is blended texels that get get adjusted by the light sources, nulling the effect of having certain pixels that are unaffected by light. I’ve read just about every doc and there is nothing that gives the abbility to set a range of RGB values or an alpha mask to be excluded from lighting, unless you setup an emissive material, but that applys to the whole as it is drawn. So my question still stands unanswered as to a way to do the “glowing” pixels that are unaffected by light that use the OpenGL lights without using multiple passes.
Must remember we are not using are own custom lighting calculations like so many are used to doing… this is what has caused so much confusion here I think.
Originally posted by bw359:
If I am using OpenGL light sources and I apply, even in combination, a series of textures that I so happen to dub logically, emissive maps, but are really just elegantly blended textures… the end result is blended texels that get get adjusted by the light sources, nulling the effect of having certain pixels that are unaffected by light.
That is incorrect. Please read the texture section of the OpenGL specification. Its got a nice chart on 154 with functions like Cv = CfCs for modulate or Cv = Cf + Cs for Add mode. The bottom of page 152 explains what v,s,f,c,p, etc are.
If using the different OpenGL texture blend modes is too confusing for now just start with the three pass method I suggested.
Confusion is premature enlightment.
I do not have the option of being waylayed by convoluted symantecs so I have to dredge through it. I’ve written this entire 3d engine and have tackled much harder things to get up to this point. I appreciate your feedback and answers but you have yet to give me a single sentence–with the exception of the 3 step method–that does not require me to peruse through gobs of technical specifications when all you have to say is what it does.
For example, I will probably read through this specification only to find out that these blending routines take into consideration the lighting calculations of the current lighting state set in the GL. OF COURSE then it would make sense that you could use these blending methods WITH opengl lighting because it would be taking it into consideration. But rather instead of saying that I am told that I am wrong… which is … only slightly helpful.
At least you gave me a page number. Some of the other posts were off in space somwhere.
So at least answer me this…
Do any of those C values in the blending routines represent a color value that is affected by the GL lighting system??
Of course I will download the specification (of which a version you did not specify, there are like 4) and read it over. But then that is why I asked somone now isn’t it? My point is (analogy): I can give you the point-slope intercept formula… but using it in a practical sense may not appear the ovbious even if you have the technical symantecs down to the T. This is the case with this. OpenGL is a very easy to use and powerful API. Within a short-time it can be mastered… but not all of its powerful features are overly apparent, especially if you have not used them.
Whatever… I digress, this is pointless and this is going to end up causing more heat than light.
Ok …
What about using C of (either)[RGBA] which is the environmental color. Then using like DECAL or BLEND. If C is the environment which is 0,0,0,0 by default, I assume this would override the lighting which is why it is 0,0,0,0 by default. Is this a correct assumption?
Blending works fine like you suggested (and how I origionally was going to do it before I tried to consolodate it into a single pass but was unsuccessful).
The key is to disable lighting for the second pass.
ARG!!! Does anyone know out there how to by-pass lighting calculated by OpenGL using multitexturing!? We just want to enable “full bright” texels in a single pass while using the OpenGL lights.
In the OpenGL pipeline, lighting is performed per vertex. And when filling a triangle, the colors of each vertex is interpolated (if ShadeModel is set to GL_SMOOTH) at the pixel level.
This lighting-dependant color is the input of the texture stage. That means, texturing takes place AFTER the lighting calculations. Then it’s up to the texturing stage to compute the colors, assuming the inputs are :
1- the color from lighting (known as the “primary color”)
2- the color of the texels, sampled from the texture(s) obviously,
3- the texture environment constant colors.
Texturing is like a function of these inputs : output_color = f(lighting_color, texel_color, constant_color)
and you merely do what you want with that function. This function could ignore lighting results, as well as it could ignore texels (pretty dumb, but sometimes useful), etc.
In the OpenGL specifications (v1.4), look at :
This means that texturing takes place after the lighting stage, and that texturing can bypass any input thanks to the texture environment functions.
In other words, you just have to configure the texture environment function you need and that’s all.
Originally posted by bw359:
I appreciate your feedback and answers but you have yet to give me a single sentence–with the exception of the 3 step method–that does not require me to peruse through gobs of technical specifications when all you have to say is what it does.
I’ve posted a follow up in the beginner forum (because getting around the semantics isn’t exactly advanced) that should be clear enough you don’t need to read much documentation.
VinCoof, thank you very much for your excellent reply. It was exactly what I was lookin for!
Titian, you have ovbiously turned this into a personal attack. You imply that I am a beginner because your explanations where in a format that I could not understand. I assure you there are things I know that you do not, and there are things you know that I do not. The point of the forum is to help other people. Somtimes somone doesnt’ understand. It doesn’t mean their knowledge is any less. Communications is a two-way street and I was merely asking for clarification. I am sorry if you felt that it was put to harshly and I appologize for my wording if it came across that way. But I assure you I am no beginner to PC development, or programming languages.
Thanks to all who posted, it has come together now. None of the OpenGL books and texts have ever clearly defined how the lighting process does what it does just like VinCoof put it so simply.
Regards,
bw359