[Gtkradiant] Realtime lighting approach issues.

[ydnar]

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>
To: <gtkradiant@zerowing.idsoftware.com>
Sent: 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:
| >
| >* 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
| >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.
|
| 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
| >
| >
| >
| >
| >_______________________________________________
| >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
|