PDA

View Full Version : Glow in the Dark Textures



bw359
07-15-2003, 12:59 AM
Is there a way to use OpenGL to get the effects of glow-in-the-dark textures? What I mean by this is like in Quake a soldier could stand in a dark corner but you could still see his bright-red triangle on his gun. Lighting was not a factor for that pixel color/value/index.

I intend to use OpenGL T&L and not have to write my own lighting system. I have a system that works with the 8 lights that are gauranteed to be available as per an implementation. This feature could be used to simulate many neat effects in our space sim.

Thanks,
Bw

Eric Lengyel
07-15-2003, 02:55 AM
This is called an emission map. All you have to do is add the value in the emission map after doing your lighting. Thus, you might do this per fragment to get your final color K:

K = C0 * T0 + T1

where C0 is the primary color, T0 is your ordinary texture map, and T1 is the emission map. This can easily be done with conventional texture blending, GL_ARB_texture_env_combine, or GL_NV_register_combiners.

bw359
07-15-2003, 07:33 PM
Thanks!!!!!

bw359
07-15-2003, 07:37 PM
Wait a minute.

Is there a way to do this without having to use extensions? I want the game to work with as many cards as possible.

The fact is im not using my own lighting engine, I am using OpenGL lights. I do store per-pixel or per-vertex lighting information nor do I calculate it.

I would like to basically ensure that one or more colors are unaffected by lighting and thus, if there were no lights in the scene or if they were totally dim that the colors would show but the rest of the texture would be pitch black.

OneSadCookie
07-15-2003, 08:00 PM
Well, ARB_texture_env add is supported by all accelerators I know of...

But yeah, just draw the scene once normally with lighting, then draw the emissive bits again with no lighting.

jwatte
07-15-2003, 08:44 PM
You can also do it by rendering the glowy bits using a separate material, and turn off lighting for those (or at least turn up ambient rather high).

CatAtWork
07-16-2003, 05:01 AM
As I remember it, Quake 1's software renderer could render 'overbright' textures, while the original OpenGL renderer could not. This was a pain in games like TF, where certain sneaky units (snipers) had an overbrighted red dot that helped you see them in shadows. OpenGL users couldn't benefit from it, and there was a bunch of complaining. Later OpenGL clients, released after the source was made public, have proper support for overbrighted textures. You should go look at their source.

zeckensack
07-16-2003, 07:01 AM
Originally posted by bw359:
Wait a minute.

Is there a way to do this without having to use extensions? I want the game to work with as many cards as possible.If you don't even want to depend on multitexturing, you can do two passes. Render the first pass as usual, for the second pass disable lighting and use additive blending (glBlendFunc(GL_ONE,GL_ONE); ).

FWIW, I wouldn't consider any hardware without basic multitexturing support to be a worthwhile target. Even a TNT/Vanta can do it single pass ...

TriangleMan
07-16-2003, 12:47 PM
For portability, I would do it one of two ways:

1. Create an emissive material (already suggested, and good).
2. Turn off lighting for that polygon.

These are both simple, and not necessarily pretty solutions, but if you just need to do it and move on, they should work.

bw359
07-18-2003, 03:11 AM
Excellent suggestions. Thanks!

The material sounds best and if not i'll use multi-texturing.

Thanks to all.

titan
07-18-2003, 08:55 AM
Originally posted by bw359:
Is there a way to do this without having to use extensions? I want the game to work with as many cards as possible.


As of OpenGL 1.3 tex_env_combine is no longer an extension. Every card from the TNT on supports this I belive. Cards before that had crappy OpenGL drivers and may not run your application anyway http://www.opengl.org/discussion_boards/ubb/smile.gif

Here is a tip: you can store the glow map in just the alpha channel or one of the rgb channels of a 2nd texture if you use the texture_env_dot3 (also part of OpenGL since 1.3) extension.

AFAIK the only reasonably powerful card that does not support OpenGL 1.3 is the PowerVR card because it doesn't support cubemaps.

Also you may want to interpolate between white and the primary lighting value. So 1 would be white and 0 would be 100% level light. If your level lighting is at 50% brightness and your glow map is also at 50% then you'll have about 50% brightness for those pixels instead of 100%. You'll have to run that one by your artists. IMHO it looks better this way.

Also you'll have to look at nv_reg_combiners if you want specular and only give it to geforce+ onwers. texture_env_combine does not allow you to do specular! http://www.opengl.org/discussion_boards/ubb/frown.gif ATI's experiemental route extension adds this to texture_env_combine, but they're dropping support for it presumably. http://www.opengl.org/discussion_boards/ubb/frown.gif

The only way to get the specular component on all brands is ARB_fragment_program which requires a ATI 9500+ or GeForceFX.

vincoof
07-18-2003, 09:34 AM
Originally posted by titan:
Also you'll have to look at nv_reg_combiners if you want specular and only give it to geforce+ onwers. texture_env_combine does not allow you to do specular! http://www.opengl.org/discussion_boards/ubb/frown.gif
(...)
The only way to get the specular component on all brands is ARB_fragment_program which requires a ATI 9500+ or GeForceFX.

If you mean per-pixel specular lighting, yes you can do it with ARB_texture_env_combine thanks to ARB_texture_env_dot3. It's harder to get a high exponent, but still it's possible.

bw359
07-21-2003, 02:49 AM
Where is a good place that covers the use of extensions for emission maps such as for windows on the starship in the darkness of space... etc.

I've look around and there isnt much on it.

zeckensack
07-21-2003, 05:19 AM
Originally posted by titan:
AFAIK the only reasonably powerful card that does not support OpenGL 1.3 is the PowerVR card because it doesn't support cubemaps.True. But http://www.opengl.org/discussion_boards/ubb/wink.gif
The Kyro supports GL_ARB_texture_env_combine (and DOT3 to boot) and quad texturing (the HW can do more, but it's not exposed in OpenGL). More than enough for these effects.

[This message has been edited by zeckensack (edited 07-21-2003).]

bw359
07-21-2003, 11:20 AM
OK these are nice posts but not one of them has explicitly and clearly defined the process cleary enough for me to understand what to make of them. I did a goodle search on some of these extensions and found zip on using them for the purposes of emissive lighting. Here are the requirments that I am bound to because of our design:

-We use OpenGL lighting and materials.
-We CAN use OpenGL extensions like multi-texturing but NOT anything else.

There is an OpenGL material property EMISSIVE. It basically makes the material for that color given to it become unaffected by light cast upon it. Which will give that "glow in the dark" look.

What are we trying to acheive?:
Lots of tiny little lights on a star-ship or space station in the darkness of space where the rest of the model is fairly occluded in darkness.

How we think it will be done:
Probably with multiple passes. We draw the normal diffuse color of the texture. Then an alpha masked texture will be applied to it with lighting disabled for that pass. But this seems inefficient and not sure how it will be affected by multi-texturing. In other words it would be nice to use multitexturing in an accelerated fashion and eliminate multiple passes and state changes in OpenGL by using the emissive materials properties. There is some magical combination here that I just have yet to see. Im sure I could eventually figure it out but I was hoping somone would have the answer to what must be somthing simple to somone who has done it before. I guess I will have to be forced into looking at some OpenGL ported quake source or somthing as like was suggested before.

Im not asking for a hand-out just a clearer answer if available... If you want to give me an article that will be fine as well as long as it follows the idioms that we have to code by for this particular project. I appreciate everyones post up to this point.

Thanks!

bw359
07-21-2003, 11:43 AM
Also to make it more clear:

- We are not using software lighting, lightmaps, or any such thing.

bw359
07-21-2003, 12:46 PM
Nevermind.

Quake was the answer.

It dynmically creates a glow map by flagging a texture that has a "full bright" color. To accomodate this in OpenGL we would use multi-texturing and will attempt to apply an emissive material OR disable lighting for the second texture... if that even will affect it or not. Then the key will be in multiple passes. Since GL does lighting calculations at the time we render the object we would have to do multiple passes if the emission values can not be set for each texture in the multi-texture stream.

titan
07-21-2003, 02:16 PM
The basic slow way would be this:
-draw with lighting enabled and all lights, but no textures
-draw now with glowing light textures additive (src*1+dst*1) and lighting disabled
-you now have a model lit by level lighting with the glowing sections on it
-draw again with blending set to src*dst+0*dst and lighting disabled

Ta da, you're done.

You can do this with basic OpenGL in three passes. If you use texture_env_combine it only takes one pass, but two texture units.

bw359
07-21-2003, 10:28 PM
Will look again at the tex_env_combine extension.

Thanks!

bw359
07-22-2003, 12:02 AM
Ok so whats the difference between using multi-texturing and the tex_combine... they way im reading them, neither allow you to accomplish this if you are using OpenGL lights!

You still have to make a second pass with the lighting turned of, even with multi-texturing, unless im missing somthing.

vincoof
07-22-2003, 03:03 AM
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 (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_texture_env_add)

bw359
07-22-2003, 07:11 AM
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?

vincoof
07-22-2003, 09:17 AM
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).

bw359
07-22-2003, 01:33 PM
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.

titan
07-22-2003, 02:45 PM
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.

bw359
07-22-2003, 03:21 PM
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.

bw359
07-22-2003, 03:37 PM
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?

bw359
07-22-2003, 04:44 PM
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.

vincoof
07-22-2003, 11:57 PM
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 :
- Fig2.1 and see that Primitive Assembly happen before Rasterization,
- Fig2.3 and see that lighting appears in the primitive assembly,
- Fig3.1 and see that texturing appears in the rasterization.
- Fig 3.11 and see that the fragment outpur color is dependant of the texture envrionment function.

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.

titan
07-23-2003, 08:42 AM
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.

bw359
08-05-2003, 04:54 PM
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