[Gtkradiant] Realtime lighting approach issues.

Pablo Zurita gtkradiant@zerowing.idsoftware.com
Mon, 06 May 2002 16:13:02 -0500

At 11:18 AM 5/6/2002 -0700, you wrote:
>Method 1:
>* 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
>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:
>* Modify Q3Map(2) to emit a secondary file that ties BSP drawsurfaces 
>and/or individual tris to their original source
>* 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
>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).

>Gtkradiant mailing list