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.
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.
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.
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.
Is there a way to do this without having to use extensions? I want the game to work with as many cards as possible.[/b]
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 …
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
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! ATI’s experiemental route extension adds this to texture_env_combine, but they’re dropping support for it presumably.
The only way to get the specular component on all brands is ARB_fragment_program which requires a ATI 9500+ or GeForceFX.
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!
(…)
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.
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
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).]
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.
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.
The basic slow way would be this:
-draw with lighting enabled and all lights, but no textures
-draw now with glowing light textures additive (src1+dst1) and lighting disabled
-you now have a model lit by level lighting with the glowing sections on it
-draw again with blending set to srcdst+0dst 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.
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.
