[Gtkradiant] Realtime lighting approach issues.

[Timothee Besset]

That explanation is pretty far from what I tried to explain. I'll go over
the main points. Let's have an idea where we want to get before we talk
about how we get there.

- What is a useful lighting preview?

That's when the editor speeds up the lighting phase of a map, by requiring
less light compiling steps to get to the final result. Give the user an
idea of what the lighting will be ingame, and things will be easier for
him.

- Can we classify the various lightings we have?

That's mostly point lights, and light surfaces such as the skybox.

- What kind of solutions, for what kind of problems?

How can we render the point lights? 

Render them the same way the engine deals with dynamic light entities
(rockets for instance). Generate the lightmap based on a few parameters
(radius, color, falloff). Advantages: fairly easy to implement, works on
all hardware. Drawbacks: doesn't deal with shadows.

Or, use some more advanced features. The benefit, being able to render
shadows. Drawback: need different backends for NVidia / ATI, meaning
hardware specific support, and a large extra amount of work.

Another solution was to use GL lights (from GL 1.2 standard) and tesselate
the lighted surfaces to achieve about the same result as the lightmaps.
Interesting, but I don't have a clear view how workable this is.

- More about shadows:

This is really a matter of how useful it is to render the shadows
accurately against how much work we have to put into it, and how many
users we let down because of vendor specific extensions.

I don't consider that exact shadows are important. With the only exception
of the sky maybe. Shadows bring me to another idea, which I tried to get
through several times:

In the end, the user will still have to run a q3map lighting stage anyway.
One crucial point is that our preview should be as close as possible as
the final result. Very logically, why not using the lightmaps from the
compiler directly? Once the user has done a first rough lighting pass of
his level, we use this information as much as possible in the editor. If
the user changes a surface light, or moves/modifies a point light, we use
our internal code to reword the lightmaps in the affected areas. This
solution keeps us as close as possible to the actual lighting, which is
what this is all about.

Side note, this gets us closer to a feature I've wanted for some time too,
which is 'painting lightmaps'. I always considered that it would be
interesting to override the compiler's lighting and 'paint' the light in
some tricky areas.

- Looking back at Radiant history regarding lighting preview:

We've had Ritual's FAKKRadiant source for litteraly YEARS. Which has an
implementation of the lightmap lighting preview I described. leave well
enough alone. We should have had this implementation fully working in
Radiant for months already. At that point we would have had a good base to
talk about more advanced features.

TTimo

On Sun, 05 May 2002 17:31:08 -0500
Pablo Zurita <pabloz@qeradiant.com> wrote:

> 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.
> 
> <TTimo> well actually, I wonder why I found this function in the core
> <^Fishman> just for the two textures(one is 1D, the other one is 2D)
> <TTimo> 1D texture from a loaded 2D image ?
> <TTimo> I'm not sure I'm following you
> <^Fishman> two different textures, one is 1D, the other one is 2D
> <^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)
> <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
> <^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
> <TTimo> I don't understand
> <TTimo> when you render, your first pass is the brush texture, the second one is a greyscale image
> <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
> <^Fishman> that gets colored, but it looks just like if you just changed the hue of the who thing
> <^Fishman> doesn't look like lighting
> <^Fishman> its not making any lightmaps, its just rendering a texture over the affected brushes
> <^Fishman> which right now are all because I don't have the attenuation code done
> <^Fishman> nor any kind of shadow code
> <TTimo> the card is doing the computation I suppose
> <^Fishman> yes
> <TTimo> you tell it 'that second pass is what you get from per-pixel shadow computations'
> <TTimo> I suppose that means it builds a black and white, or a lightgrey texture
> <^Fishman> no shadow, it just check lights the radius of image into the scene, its like the dlights in Q2
> <^Fishman> TTimo: actually it can have any colors
> <TTimo> ah, it's even easier then? why would you use some weird nv stuff to do that
> <TTimo> standard GL supports lights
> <^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
> <TTimo> and what would be the use to radiant
> <^Fishman> gl lights only allow 8 lights rendered at the same time, and you have to tesselate the geometry to make it look right
> <TTimo> well that sounds fine to me
> <^Fishman> no need to tesselate or any strange thing with per-pixel
> <TTimo> use an OOB to select the nearest lights, and render
> <^Fishman> and the disco light was just an example, I will actually use per-pixel lighting to light the maps
> <TTimo> I am interested by the solution that's appropriate for the editor, and that fits as many cards as possible
> <TTimo> I never cared about projected shadows either anyway, so I don't care about nv stuff
> <^Fishman> per-pixel should work on any card after the TNT2 Ultra
> <TTimo> using GL light code binded with some intelligent sorting
> <TTimo> should lead us to something
> <^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
> <TTimo> I don't think it would be any speedup
> <TTimo> if you do something that can be done with regular gl lights, some weird extensions won't speed it up
> <^Fishman> using registers conviners improves the speed a lot when doing per-pixel lighting. At least in the NV cards
> <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
> <^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
> <TTimo> is that such a problem
> <^Fishman> it is concedering the size of the maps now
> <^Fishman> it's not such a problem for q3dm17, but it is for maps like q3dm7 and others
> <TTimo> well we probably don't want to render the whole level lighted anyhow
> <TTimo> we only need it for some bbox around the view
> <TTimo> the only real important thing as a preview tool, being that it stays close to the lighting in game
> <^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
> <^Fishman> well, I believe per-pixel lighting will provide closer results to the q3map than gl lighting
> <TTimo> true
> <^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)
> <TTimo> I'm just annoyed by too much extension specific dependency
> <^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
> <^Fishman> anyways, if it fails to load then we just put a msg in the console
> <^Fishman> "sorry mr, you are fucked, no lighting for you!" :P
> 
> ============================================
> 
> <^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
> <TTimo>: I still don't think we need to use any NV specific stuff anyway
> <^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.
> <TTimo>: dynamic lighting in Q3 or RTCW doesn't rely on any NV specific stuff
> <^Fishman>: Q3 and RTCW have a compile process that takes hours, we can't afford that.
> <TTimo>: that's not related to the compiling
> <^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) _______________________________________________ Gtkradiant mailing list Gtkradiant@zerowing.idsoftware.com http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant