[Gtkradiant] Realtime lighting approach issues.

[ydnar]

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.



Method 2:

* 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

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.


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.

y