[Gtkradiant] Realtime lighting approach issues.

Mon, 06 May 2002 06:54:27 -0500

At 01:55 PM 5/6/2002 +1000, you wrote:
>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.

Looking at some maps(especially indoor maps) you probably get > 8 lights.

>
> > >- 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.

There's no real need for in soft shadows really but in case we wanted them 
what we can do is do a render to texture of just the shadows and then we 
apply some blur.

>
> >
> > >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.

Read my reply to the use of Ritual's lighting approach in GtkRadiant. Also 
I think we would have to reduce a lot the resolution of q3map in order to 
use it for realtime lighting, it would probably look like a few lights and 
with shadows so soft that the designer won't be able to rely on them as he 
works.

>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.

q3map won't be able to use an image(the lightmap) as a base for generating 
new lightmaps, the lightmaps are result of a lot of other calculations, you 
can't get those calculations by taking a look at an image. But if we do a 
progressive lighting algorithm and use the information generated by 
GtkRadiant then that's an alternative.

>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.

We are talking about allowing the designer to see everything in realtime 
with changes and no compile process, we aren't talking about making a q3 
bsp viewer for GtkRadiant. Keep in mind that.

>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 ;]

Exactly, I don't think we have time to do that, we really have decide a 
lighting approach, stick with it, and get it done.

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