[Gtkradiant] Realtime lighting approach issues.
Pablo Zurita
gtkradiant@zerowing.idsoftware.com
Sun, 05 May 2002 17:31:08 -0500
<html>
I'm working on realtime lighting and when ever TTimo and I talk about it
we never manage to agree on the use of extensions so I decided that
everybody should have an opinion and maybe we can reach an agreement on
how I should approach this. My approach is the use of per-pixel lighting
and use a modified version of Carmack's reverse technique for shadows. To
do this in an effective way I need arb_multitexture, Nvidia's register
combiners, and the stencil buffer. This means that this feature would be
available for Nvidia's cards from the GeForce 1, but my plan is to add
support to ATI extensions(I don't own an ATI card but I know its pretty
easy to get ATI to send me a Radeon or something). TTimo basically is
against the use of extensions in GtkRadiant(TTimo: you may want to expand
on this). Ok, here are some lines of the talking, after you read this
post your own opinion.<br><br>
<b><i><TTimo> well actually, I wonder why I found this function in
the core<br>
<^Fishman> just for the two textures(one is 1D, the other one is
2D)<br>
<TTimo> 1D texture from a loaded 2D image ?<br>
<TTimo> I'm not sure I'm following you<br>
<^Fishman> two different textures, one is 1D, the other one is
2D<br>
<^Fishman> one for attenuation the other one for the actual shape
of the image(eventually I think I will have to generate the textures
instead of loading them in order to have a reliable representation)<br>
<TTimo> we are not at a point where we would want something that's
well integrated in the overall design, we just want some experimental
code that works, which we can design to fit in once we know how to do
it<br>
<^Fishman> well, the lighting shows up if I just load the texture
from the face_t but it looks uber gay because the texture for the lighing
is the same as the texture of the brush<br>
<TTimo> I don't understand<br>
<TTimo> when you render, your first pass is the brush texture, the
second one is a greyscale image<br>
<TTimo> I don't see why you need to use the texture to build the
lightmap, but then again, I never looked at lighting code, so I don't
know<br>
<^Fishman> that gets colored, but it looks just like if you just
changed the hue of the who thing<br>
<^Fishman> doesn't look like lighting<br>
<^Fishman> its not making any lightmaps, its just rendering a
texture over the affected brushes<br>
<^Fishman> which right now are all because I don't have the
attenuation code done<br>
<^Fishman> nor any kind of shadow code<br>
<TTimo> the card is doing the computation I suppose<br>
<^Fishman> yes<br>
<TTimo> you tell it 'that second pass is what you get from
per-pixel shadow computations'<br>
<TTimo> I suppose that means it builds a black and white, or a
lightgrey texture<br>
<^Fishman> no shadow, it just check lights the radius of image into
the scene, its like the dlights in Q2<br>
<^Fishman> TTimo: actually it can have any colors<br>
<TTimo> ah, it's even easier then? why would you use some weird nv
stuff to do that<br>
<TTimo> standard GL supports lights<br>
<^Fishman> so if I make an image with some color dots and make it
rotate in the scene then it will look like a disco light or
something<br>
<TTimo> and what would be the use to radiant<br>
<^Fishman> gl lights only allow 8 lights rendered at the same time,
and you have to tesselate the geometry to make it look right<br>
<TTimo> well that sounds fine to me<br>
<^Fishman> no need to tesselate or any strange thing with
per-pixel<br>
<TTimo> use an OOB to select the nearest lights, and render<br>
<^Fishman> and the disco light was just an example, I will actually
use per-pixel lighting to light the maps<br>
<TTimo> I am interested by the solution that's appropriate for the
editor, and that fits as many cards as possible<br>
<TTimo> I never cared about projected shadows either anyway, so I
don't care about nv stuff<br>
<^Fishman> per-pixel should work on any card after the TNT2
Ultra<br>
<TTimo> using GL light code binded with some intelligent
sorting<br>
<TTimo> should lead us to something<br>
<^Fishman> the nv stuff is to speed up the code, eventually if I
manage to get an ATI I may use some of their extensions<br>
<TTimo> I don't think it would be any speedup<br>
<TTimo> if you do something that can be done with regular gl
lights, some weird extensions won't speed it up<br>
<^Fishman> using registers conviners improves the speed a lot when
doing per-pixel lighting. At least in the NV cards<br>
<TTimo> after that, it's a matter of cost, I don't want to spend
time integrating some light code that would be totally overkill<br>
<^Fishman> the problem with gl lights is that we would need to
tesselate the geometry A LOT(at least 5 times) to make them look half
decent<br>
<TTimo> is that such a problem<br>
<^Fishman> it is concedering the size of the maps now<br>
<^Fishman> it's not such a problem for q3dm17, but it is for maps
like q3dm7 and others<br>
<TTimo> well we probably don't want to render the whole level
lighted anyhow<br>
<TTimo> we only need it for some bbox around the view<br>
<TTimo> the only real important thing as a preview tool, being that
it stays close to the lighting in game<br>
<^Fishman> yeah, we could use the cubic clipping, but for example
you go to the room of the hellish mouth in Q3dm1 and after tesselating
the geometry too many tris will be generated<br>
<^Fishman> well, I believe per-pixel lighting will provide closer
results to the q3map than gl lighting<br>
<TTimo> true<br>
<^Fishman> and I have no idea how long it would take to make a good
tesselation code(its easy for bezier patches but hard for normal
brushes)<br>
<TTimo> I'm just annoyed by too much extension specific
dependency<br>
<^Fishman> well, this is the first time that extensions get used in
gtk, the multitexture wasn't being used even though the code was there,
and now I just added the reg conviners<br>
<^Fishman> anyways, if it fails to load then we just put a msg in
the console<br>
<^Fishman> "sorry mr, you are fucked, no lighting for
you!" :P<br><br>
============================================<br><br>
<^Fishman>: easy access to new drivers, techniques(after some
talking with SPoG I will have to work on shadows now and I'm looking
forward to some some of the nvidia stuff that isn't available in in the
normal dev site) and get some free hardware to test and shit<br>
<TTimo>: I still don't think we need to use any NV specific stuff
anyway<br>
<^Fishman>: my intention would be to put my stuff in a plug-in so
people wouldn't be forced to use it or anything, and as I said before we
just check if the extension needed is supported or not. And it also
improves the program, like RtCW, they use NV fog tables and ATI's truform
to improve their game but its not like if you don't have those extensions
the game doesn't work.<br>
<TTimo>: dynamic lighting in Q3 or RTCW doesn't rely on any NV
specific stuff<br>
<^Fishman>: Q3 and RTCW have a compile process that takes hours, we
can't afford that.<br>
<TTimo>: that's not related to the compiling<br>
<^Fishman>: well, the lights are drawn on the lightmaps, we don't
have light maps. And also remember that I'm not making this stuff to
simulate dinamic lights, its more than just spheres of light. And also I
have to work on shadows(probably using Carmack's reverse
technique)</b></i></html>