[Gtkradiant] Realtime lighting approach issues.

[gtkradiant@zerowing.idsoftware.com]

I might have missed something but all of the discussion i've seen=
 on realtime lighting in radiant SEEMS to be based on point=
 lighting. Me and many other ppl i know use a mostly shader based=
 lighting (80-90%), which presents a completely different issue=
 when considering lightgrid spacing and other shader effects.

IMO-- Actually seeing the light being cast on surfaces isn't as=
 important as seeing where it's going to fall. UED, for example,=
 can show the effective radius of pointlights. it's just a red=
 line circle that changes dynamically with parameter changes. The=
 ued version is spatially odd to look at cuz it doesn't stop at=
 surfaces that it affects... but once you figure it out it helps=
 quite a bit. a better featured version of this would achieve the=
 goal of reducing the number of redundant light compiles. 

off the top of my head here. . . what about a "preview plugin"=
 that requires a compiled bsp, and presents a 3d view of the bsp=
 with radiants lighting ents? 

with a bsp, you'd have all the things that ydnar listed that=
 aren't avail to radiant, and being a separate window/process,=
 you could 'start from scratch' with the renderer without mucking=
 up the radiant renderer with a "view realtime lighting" pref.=
 (would radiant have to sleep to use it tho)

>Message: 3 From: "ydnar" <ydnar@shaderlab.com>=A0To:
><gtkradiant@zerowing.idsoftware.com>=A0Subject: Re: [Gtkradiant]=
 Realtime
>lighting approach issues.
>Date: Fri, 2 Aug 2002 10:29:04 -0700 Reply-To:
>gtkradiant@zerowing.idsoftware.com
>
>Realtime. Heh. Please consider the following:
>
>1. The Q3Map attenuation model could be approximated=
 sufficiently with
>ATi/nVidia pixel shaders on modern rendering hardware.
>
>2. Every unique lightsource/surface interaction requires one or=
 more
>rendering passes.
>
>3. Stencil shadows are expensive for two reasons: 1.=
 Determining
>silhouette edges. An unsorted collection of convex solids=
 (brushes) is
>sub-ideal for creating stencil volumes.
>2. Fillrate: Every shadow volume cutting through the view=
 frustum exacts
>a fillrate cost.
>
>Given 2 and 3 respectively, assume that Doom III uses less than=
 8 lights
>per scene. It is also rendering geometry optimized for stencil=
 shadows.
>
>An average Quake 3 scene has significantly more than 8 lights.
>
>Radiant's scene graph is an unordered collection of brushes. No
>visibility information, no hierarchy of geometry, no=
 pre-calculated edge
>lists.
>
>So forget about realtime.
>
>y
>
>
>----- Original Message -----
>From: "Pablo Zurita" <pabloz@qeradiant.com>=A0To:
><gtkradiant@zerowing.idsoftware.com>=A0Sent: Monday, May 06, 2002=
 2:13 PM
>Subject: Re: [Gtkradiant] Realtime lighting approach issues.
>
>
>| At 11:18 AM 5/6/2002 -0700, you wrote: | >Method 1: | >=A0| >*=
 Move
>lighting code from Q3Map2 to a lib | >* Modify brush/patch/model=
 classes
>to have extra storage for lighting data | >* Modify Radiant to=
 use said
>lib via a command (no BSP or vis necessary)
>| >* Add "Light Preview" mode to Radiant's renderer to use=
 lighting
>storage | >=A0| >The lighting code in Q3Map2 has little dependency=
 on the
>Quake 3 BSP | >format (well, it can be used outside of it with |=
 >some
>small tweaks). It uses brush data to determine sample occlusion,=
 so |
>>the lightmaps/vertex light for the map file | >would suffice=
 for BSP
>lightmaps.
>| | The problem is that it would take too much time to use it=
 in
>realtime.
>| | | >Method 2: | >=A0| >* Modify Q3Map(2) to emit a secondary=
 file that
>ties BSP drawsurfaces | >and/or individual tris to their=
 original source
>| >brushes.
>| >* Modify Radiant to load this file + the BSP after a compile=
 | >
>* Modify Radiant's renderer to draw a hybrid of the map's source=
 brushes
>| >as well as the BSP's drawsurfaces | >* If brushes/ents=
 change, Radiant
>draws source brushes/ents ONLY, ignoring | >the surfs/tris that
>correspond in the BSP | >=A0| >This approach is similar to how=
 UnrealEd
>works (the lighting preview just | >uses the Unreal renderer to=
 draw the
>compiled | >BSP). The other nice thing about this approach is=
 that if
>Radiant loaded | >the BSP every time it was written out by=
 Q3Map, |
>>mappers could see the radiosity solution in-progress without=
 having to |
>>launch the game.
>| | I don't know if you have seen my reply to Gef, but anyway,=
 the point
>isn't | to make a q3 bsp viewer for GtkRadiant, the point is to=
 make a
>solution | that would work when the user is editing independent=
 of what
>the user does, | the user should always see the lighting. I=
 mean, if we
>run through the same | process as q3map we may as well just load=
 Q3 right
>away.
>| | | >Simulating Q3Map's lighting in Radiant (or ZHLTRad's=
 lighting for
>| >Half-Life) using pixel shaders and/or crude lightmap |=
 >approximation
>doesn't do the mapper any favors, IMO.
>| | Crude lightmaps wont work, I have faith in the combination=
 of per
>-pixel | lighting + stencil shadows. But I don't think that=
 doing q3map
>in Radiant | doesn't help much because the user could compile=
 the map and
>run Q3 with | the same amount of time. Again, the point isn't to=
 make a
>q3 bsp viewer, | the point is to make a lighting solution that=
 would work
>in any | situation(or most).
>| | >y | >=A0| >=A0| >=A0| >=A0|=
 >_______________________________________________