[Gtkradiant] Realtime lighting approach issues.

[ydnar]

Perhaps Bert Peers would be so kind as to lend us his BSP renderer source.

I like UnrealEd's approach to the textured 3d view...it just draws the BSP. Any brushes/stuff that's changed get
rendered as well, unlit.

y


----- Original Message -----
From: <monsto@comcast.net>
To: <gtkradiant@zerowing.idsoftware.com>
Sent: Saturday, August 03, 2002 5:59 PM
Subject: Re: [Gtkradiant] Realtime lighting approach issues.


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