{wf}shadowspawn> belac didn’t read the logs i sent him :/
]s[belac> i tried but geez =[
]s[belac> there was a lot
-*apparently, belac has a life. and, apparently, i don’t*-

note1
using fast or fastgrid will speed up compiling large open maps significantly. fast is a bit dimmer, but can be worked around, but fastgrid is hardly noticeable in the final map.
the reason lighting is slower on maps constructed mostly of detail brushes is because the raytracer walks the bsp first (created by structural brushes) and then traces against surfaces. since the bsp on detail-heavy maps is simplified, most of the tracing time is spent in the latter part.
the tracing code in 2.0.x differs from previous versions in a few ways:

lightmaps are computed in 3 phases, rather than one: allocation/projection (this used to happen in the bsp phase of compilation), luxel mapping (finding the location and direction of each sample), and finally illumination (tracing to lights in the world).
detail brushes are now considered “the void” when determining if a sample is occluded. this eliminates the dark splotchy edges from detail brush geometry. it slows down the luxel mapping process a bit, but pretty much does the right thing in most cases.
since surfaces can potentially be much more complex, the raytracer was modified to do more early-out testing of certain surface primitives. since a map is constructed largely of planar surfaces composed of triangles, the ray/plane intersection test is done for groups of triangles rather than for each individual triangle.
as of 2.0.0-a10, lightmaps are allocated in clumps of surfaces. generally speaking, no virtually identical luxel will be calculated more than once. older versions of q3map did a cruder approximation of surfaces->lightmaps and could potentially calculate many more luxels than were actually used.
iirc, vexar’s new map “radiator” went from ~7 hours to about 10 mins lighting time with the new build.
there are a few remaining bugs with 2.0 that I’m tracking with the help of my alpha testers. they involve mostly incorrect lighting on certain surfaces (dark spots, light spots, etc).

cheers,

y

note 2
-filter averages values from neighboring samples even if they’re “off” the surface. “off” samples have indeterminate surface normals which wackos phong shading. you could also omit -filter, and add -thresh 0.25, which means it’ll do more normal sampling/averaging. the maprawlightmap() will take about 2-3x as long though. thresh affects phong shading. think about it this way: super * 1.0 / thresh super * super / thresh ~= number of taps per luxel in mapping stage.

note 3
actually the renderer draws whatever surfaces are referenced by the bsp leaves in the current pvs.

y

note 4
I’ve never tested it, but there is code in q3map to import 3d studio ase files as well as md3s for models.
there is a 1024 vertex limit on misc_model surfaces.

y

note 5
surfaceparm nolightmap suppresses lighting data. it’s a bit of a misnomer. change it to “surfaceparm pointlight” to have it vertex lit but no lightmap.

y

note 6
use patches, especially if you’re making a map for competitive play. the vertex/surface/lightmap savings are noticeable, even if you only replace 3 brush faces with a single patch.

note 7
brush vertices can lie in 3 different places:

- in playable space
- inside a detail brush
- behind a patch (only affects -patchshadows)

the first case, playable space, will result in the vertex probably getting lit right.
the second, inside a detail brush, is pretty easy to figure out and work around.
the third, behind a patch, is the hard problem.

note 8
as i stated above, the only real reason r_vertexlight exists at all is to support older hardware w/o proper blend modes (gl_dst_color, gl_zero) or fillrate sufficient to handle > 1 pass per triangle with a reasonable framerate.
that said, to make your map look “correct” with r_vertexlight, you can do one of two things:

edit the “dark” brushes so that no vertices are buried, so light will reach them.
wait for y11, which should have the changes i proposed above.

y

erg..ok. you can add q3map_novertexshadows to any shaders you want to suppress vertex tracing on.

note 9
the radiosity in q3map uses a variable subdivision within the range of [16,256] relative to the diffuse gradient across the surface.

y

note 10
btw, since this is a snowy winter map, you might want to use:
-light fast -bounce 8 -patchshadows [-extra -smooth]
using -cheap limits the amount of light re-emitted by the bright snow. the results would probably get rid of all the dark shadow areas in those shots. also, perhaps considering upping the amount of surfacelight emitted from the sky shader. most default skies use something in the range of 100-200, which gets clipped out by fast. or alternatively, add q3map_nofast to the sky shader and up the q3map_lightsubdivide.

cheers,

y

note 11
new entity keys:

”_lightmapscale” key for brush entities (worldspawn, func_*). this lets a mapper scale the lightmap samplesize per-entity. for large constructions, 2.0 or 3.0 is a fine value, and keeps bsp size down and compile times low. for those areas you want to have high-detail shadows, make a func_group and use a value of 0.25 or so. it will scale the samplesize value for the surface’s shader (default 16) or the -samplesize argument.
”modelscale” and “modelscale_vec” keys for misc_models (1.0 = default). this was for proper rtcw support and is available for quake 3 maps as well. lets you scale up map models in the world, getting around the md3 size limitation. the next build of GTKRadiant has spog’s code to support this in-editor so you can see what effect a scale has.
flare surfaces are now suppressed from the bsp. they serve no purpose other than add to the vert & surfacecount in a bsp. these surfaces were created silently when a shader has “light 1” or “q3map_flareshader x.” use the new -flares switch when bsp’ing your map to have them emitted.

note 12
surfaces’ samplesize are now stored in the bsp. this change makes bsp’s generated from this version incompatible with all other q3maps. the upside is that -samplesize n is no longer necessary on the -light or -vlight stage. this feature is necessary to support the “_lightmapscale” key.

note 13
maj: you could automatically generate some autosprites at compile time, but they’re not really very good as halos.
y: aye, or add a “_sprite” key to light entities that would do same. mods (q3f and true combat come to mind) already have proper flares though...

note 14
area lights get optimized away with fast. it’s a subjective thing. luckily, there are a number of workarounds. the first thing I’d do is increase the amount of surfacelight emitted from your sky shader. secondly, since it is a space map, use a very crude q3map_lightsubdivide. something like 512 should do. small subdivides + dim light = root cause for most “dim” problems with fast.

y

note 15
fog brushes must be axial boxes. no corner chopping, I’m afraid...

y

note 16
you can have terrain in worldspawn. the entity keys have been tweaked. “shader” can/should be “_shader”. “alphamap” can/should be “_indexmap”.

layers keyword is still needed
”_layers”

note 17
* explicit, per-luxel normal storage:
1st pass normal calculation on the lightmap (temporarily using the lightmap to store surface normals)
2nd pass, walking triangle edges to solve for seaming issues

* direct evaluation of a surface per luxel:
works nearly perfect on brush faces, but is incredibly slow on patches

* retrofitting the lightmap calculation to work on a per-surface-fragment (triangle) basis
1st attempt, a full floating-point scanline rasterizer produced ok results, but failed on degenerate or flipped triangles
2nd attempt, optimized triangle rasterizer using edge deltas
the various tests used mixes of blending matrices, barycentric coordinates, (cheap) edge-clamped barycentric coordinates, and normal super-sampling. none of them produce “ideal” results, where a lightmap w/o shadows equates to a vertex-lit by averaged normal render. I’m going to modify the luxel triangle scanline renderer to calculate barycentric coordinates and do proper edge clamping within (1.0 / luxel radius) with destination blending. one nice thing about having this code in a more modular form is that -extra and -extrawide are being deprecated. they will still work, but there is a new switch (-super) that allows you to explicitly specify the super-sampling ratio. for now, extra = 2 and extrawide = 4. the other nice side effect of using barycentric coordinates for luxel determination is that dark edges on detail brush faces are eliminated.
working on it...

y

note 18
Q: also, what about this lightgrid shader. if you have a complex map, do you need to put this shader in the areas that are going to have the lightgrid calculated? i did a compile with -light fast fastgrid -cheapgrid and only had the lightgrid enclosure on one area. yes, the bsp size was chopped in half, but everywhere else the ents were blue/gray, the light that was in the area where the lightgrid shader was. so does this shader need to be enclosing -all- areas that the player is in? what about if you need to put up adjacent areas, does the lightgrid shadered box need to be perfectly flush with that? i realize the savings on the lightgrid after playing with this, but that example for the space map just confused me a tad.

A: q3map takes the smallest box that encloses all brushes with the lightgrid shader and sets the size of the map’s lightgrid to that box. it doesn’t matter if there are 1 or 100 lightgrid brushes. if the min/max bounds of the brushes is the same, then the result will be the same. ideally, you should put the lightgrid brush over the entire volume of the map that entities with “rgbGen lightingdiffuse” will be in. players, items, and powerups are examples of entities lit in this fashion. if they fall outside the lightgrid bounds, their lighting values are undefined. in the example space map, this doesn’t really affect much in-game.

y

note 19
don’t mix rgbGen vertex on one stage and have a lightmap in another. the lightmap is where the lighting data is stored.
for the tree to cast a shadow, you have to use “surfaceparm alphashadow.” if you want it to cast a translucent shadow, you have to use “surfaceparm lightfilter.”
the reason the boxes are lighting everywhere is because of radiosity. you can minimize it with a q3map_bounce N.N value in the shader. a value of 0.5 means it will re-emit half the light it normally would.
not that it’s a realistic simulation of diffuse interaction by a mile anyway...
your non-axial brushes probably aren’t snapped properly. make sure every vertex is snapped to at least a 1-unit grid. also, consider using GTKRadiant w/bobtoolz brush cleanup. brushes can get dodgy in short order when vertex manipulated.

y

note 20
another thing to keep in mind is that shaders must be modified to work the way you’d expect with q3map 2.0. it will not work entirely right out of the box. for instance, all clip shaders must have “surfaceparm trans.”

y