Previously, leak files would only be written for a leak in hull 2. This is
actually pretty bad because a small leak in hull 0 or 1 might not show up
in hull 2 and you would never get a leak file to chase it down.
Place a flag in the global mapdata to indicate whether we have written a
leak file or not so we only write for the first hull that leaks. Hullnum
is no longer needed as a parameter to RecursiveFillOutside, so remove
that from the fillparms struct.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Remove the (file) global fillmark from outside.c and place into the global
mapadata. Pass the fillmark into RecursiveFillOutside as a read-only
parameter instead.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
This is not a yes/no flag it's an integer mark to see if we have visited
the node within the same fill pass.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Makes it kind of obvious now that there is a bug here - if we have a small
leak in hull 0 or 1 which is sealed in hull 2 (due to brush expansion), then
we won't get a leak trail!
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The TEX_SKIP flag isn't needed and although it *shouldn't* upset any
engines, better to not write it out at all.
Well, even better to not write anything about the skip texture to the BSP
file, but need to re-organise things a bit more before that can happen.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Precalculate the distance at which lights will fade to zero brightness.
For lights with inverse falloff, use the gate value to determine the
cut-off distance. Use this value to cull samples and avoid the ray
tracing overhead.
Hopefully not too controversially, I am going to default this to "on" with
a gate value of 0.001. Unless you have > 1000 lights contributing
fractional light values across your map, this is not going to make any
visible difference.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
May as well keep dist as the actual distance and just call ScaledDistance
twice (poor function name, btw - it's effectively the equivalent of the
"fade gate" stuff)
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Rename member lightmapcolors -> colormaps
Remove unused member surfnum
Re-order things so the data lumps are together at the end.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Looks like the original code biased these to one side, but the
oversampling will be more accurate if we evenly distribute the points
around the actual lightmap point.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
We were calculating these values for every light and for every surface,
which seems a little excessive... Also made the variable names a bit more
sensible - we had stored a direction vector, not the actual mangle values.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kevin Shanahan