[Gtkradiant] Realtime lighting approach issues.

[Gef]

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

> At 01:32 AM 5/6/2002 +0200, you wrote:
> >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.
> 
> The information generated by the 3d view lighting won't be able to be used 
> with q3map because the differences would be too many to actually have q3map 
> and gtkradiant exchange the lighting information, unless we do some kind of 
> progressive lighting algo or something like that so we could grab the 
> lighting generated by GtkRadiant and continue the lighting in q3map.
> 
> >- Can we classify the various lightings we have?
> >
> >That's mostly point lights, and light surfaces such as the skybox.
> 
> And spotlights.
> 
>
> >- 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.
> 
> Also a second pass is needed unless ARB_multitexture is used. The process 
> isn't done in hardware. And also the code would take much more time than 
> doing per-pixel lighting.
> 
> 
> >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 benefits are that there is no need to do a second pass for all the 
> geometry. And one pass if ARB_multitexture is used.
> About the drawback, you are right about having to do hardware specific 
> support but with Nvidia and ATI support you have about 90% of the 
> community. But, it isn't a large amount of work, in fact its pretty damn 
> easy, with about 100 lines of code I managed to get some kind of lighting 
> done using Nvidia's register combiners and ARB_multitexture. If I manage to 
> get the hardware needed(I think if I contact the chips manufacturers I can 
> get free hardware to do that) it wouldn't be much problem to get support 
> for other cards.
> 
> 
> >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.
> 
> GL lights are not an alternative really, first you have the limit of 8 
> visible lights max(even in OpenGL 1.3) and also you would have to tesselate 
> the geometry at least 8 times. The fillrate would go down A LOT. Also, 
> tesselating bezier patches is really easy but the rest of the geometry 
> would be a pain in the ass to make the code.
> 

The 8 light limit is only per surface (tris) so that limit doesn't really eliminate
using gl lights as an option, particular with smaller surfaces, you should never 
really need to use more than 2-4 lights per tris.
 
> >- 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.
> 
> The only thing needed is the stencil buffer.

Using the stencil buffer, with shadow volumes, afaik, can not produce soft
shadows, it's either shadowed, or its not. Which looks nice, but doesn't really
mimic the lighting model that q3map uses. Maybe there are tricks I haven't
read about yet that get around this limitation somehow.
 
> 
> >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.
> 
> I don't know how we are going to turn the q3map information usable because 
> by the time q3map gets to the lighting process q3map already trashed lots 
> of information with the BSP and VIS. It would be at least 3 times as much 
> work to do that than adding support to ALL the video cards with per-pixel 
> lighting.
> 
> 
> >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.
> 
> That's a possibility, maybe making a more simplified and faster version of 
> q3map lighting process we could get to something, but I don't think it 
> would be as fast as the per-pixel lighting.
> 
> 
> >- 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.
> 
> I don't mean to say Ritual sucks or anything similar, but their 
> photonmapping approach is terrible, they tried to adapt a technique that 
> was created for raytracing in a  realtime environment and it just simply 
> doesn't work(unless you have a really powerful computer). To speed up the 
> process we would have to add at least Irradiance caching which is a method 
> to reuse irradiance values via interpolation, KD-trees to store the 
> photons, and ray marching which speeds up the process to find how each 
> photon contributes to the light solution. That would take a long time I 
> believe.
> 

ydnars q3map lighting code, in some of its incarnations has been really quick
(by no means realtime) and also exports lightmap images. Adapting that with 
the FAKKRadiant implementation, which uses a similar tecnique to q3map lighting,
Reduce the lightmap resolution and maybe pull the lighting code out of q3map 
into a general lighting library, could be another alternative which would probably 
produce the most accurate representation of the final lighting result that you 
would see in game.

Adding a lightmap import function to q3map would allow you to use a modified lightmap
image as a base for generating the new lightmaps for the final compile. This would
simplify adding the mystical "paint with light" function to radiant, since all you would
be doing is modifying the lightmap image data for a given surface.

For a realtime editor, the lighting should not really need to be accurate enough that
the time taken to produce it detracts from the editing process. The lighting should
really only need to represent the final result that you would see in the engine, not
reproduce it.

I don't really object to using vendor specific extensions to add features to radiant,
but using vendor specific extensions to add functionality is a different matter. And
realtime lighting preview falls squarely in the feature category. Also, ^Fishman mentioned
that he would be implementing this in a plugin, so why not implement multiple methods
and allow the user to chose the one they prefer based on the performance of their
system and the extensions available. Of course, that assumes that ^Fishman, and
anyone else who contributes has nothing better to do with their time than experiment 
with realtime lighting methods ;]

I should add as a minor disclaimer that I haven't implemented, or studied any lighting 
code in much detail, so what I've said are opinions based on a fairly limited knowledge
of whats involved.

Gef :]

> 
> >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
> >
> >_______________________________________________
> >Gtkradiant mailing list
> >Gtkradiant@zerowing.idsoftware.com
> >http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
> 
> 
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant@zerowing.idsoftware.com
> http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant