This avoids issues with some engines that require the lit and internal lightmap to have the same intensity. (MarkV, some QW engines).
Previously, if you used low-value colors (e.g. "0.2 0 0"), the .bsp lightmap and .lit file could have vastly different brightness.
This bug is a counterpart to this bug in quakespasm:
https://sourceforge.net/p/quakespasm/patches/15/
If the precision of the calculation in WorldToTexCoord done by ‘light’
is significantly different than the precision of the same calculation
in the engine, you can get corrupted lightmaps. The problem affects
light when it’s built as something other than vanilla 32-bit
x86. (e.g. x86_64 on a mac).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Colours need to be scaled correctly by the light intensity.
Thanks to Mechtech for reporting this issue.
Reported-by: Paul R <automan1001@yahoo.com>
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Add BSP2 support to the remaining utils. Since these share the common
bspfile.[ch] files, it was more effort than is justifiable to break this
into multiple staged patches - so you just get this disgustingly big
commit instead. Here is basically what was done:
* Modify the bspdata_t struct with a union of the two bsp formats
* Modify the tools to use bsp2_t for all internal processing
* Split out the byte swapping routines for the different bsp data types
* Add simple (although verbose) code to convert bsp29 <-> bsp2
Hundreds of lines added to bspfile.c, but mostly trivial stuff. The tools
internally had little modification except to substitute the bsp2 type
names.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Transition all tools to access the BSP data via the bspdata struct instead
of the shared globals. Remove the compatibility code from bspfile which
copied the global values to/from the instanced bspdata struct.
Mostly the changes just involved passing along the bspdata struct to the
various functions which needed to reference the data. TraceLine and
MakeTNodes in light got some extra changes so that we cache the node
dplane pointer and remove the need to pass the bspdata struct to every
trace operation!
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Avoids reference to global LightDataSize. Need to move writing the lit
file above the call to WriteBSPFile, since that will do the byte swapping.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Rename the default bsp29 data types and add the bsp2 data types to
the common bspfile.h. Propogate the bsp29 names into the other tools as
simple renames for now.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Used this to help with debugging, but may as well keep it around for
future debugging rather than implement it all over again next time.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Often these errors are caused by super small faces on brushes, show the
area of the offending face to make it more obvious if that is the case.
Kind of lost in the diff, but moved the TriArea, etc. functions up and
added FaceArea() and then augmented the error message.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Rather than allocating the overflow map within each function and
having to handle it as a special case in each, we always allocate the
extra lightmap in the base LightFace function and use common helper
functions to handle allocation and warning on overflow.
We lose a tiny bit of debugging info here about the specific light
that made the surface overflow MAXLIGHTSTYLES, but that never gave us
all the sources, only the last one encountered.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Simple functions, but just helps to tidy up the bodies of the other
LightFace functions and makes sure we're handling light & colours
consistently across each (we weren't in the case of coloured local
minlights, previously).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Move away from the "Fix" naming ~ it's not a fix, we're applying the
minimum lighting values as requested.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Factor out the allocation of new light styles - slightly increases the
code size, but we get two benefits; first is that we now don't
allocate the style 0 lightmap unless we actually need it; second, we
get warnings if sunlight or minlight is unable to be applied due to
lack of a style 0 lightmap.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Simplify the code by removing the if (colored) conditionals from the
code path. CPU cost is insignificant compared to tracing the rays.
As before, only write the lit file if colored lights are detected or
the use explicity requests it.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Since the newskip.exe tool leaves the faces in the bsp but removes
references, we will just skip over lighting such faces.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
No longer update the globals in this function - make the callers do it
instead.
bspinfo no longer refers to the globals at all.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Just having one base pointer was kind of annoying because you have to cast
to get to the lump offsets, then cast to byte * to find the miptex, etc.
Now we can access the same pointer using the correct types in each case.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Removes the MAX_MAP_ENTITIES and MAX_MAP_ENTSTRING limitations by
counting how much space we will need before parsing/writing.
Now that I look at it, I'm not sure why we should even be re-writing
the entity string in the new bsp file, but I'll leave that behaviour
alone... for now.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Makes minlight additive rather than just bringing low levels up to the
minimum. Not entirely identical to the bjp implementation as it seems to
treat local minlights in some strange ways, but in most cases the
behaviour should be identical.
Added missing help text for -anglescale|-anglesense parameters too.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Add the -soft command line option which implements post-processing on
the lightmap surface to blend adjacent samples together to smooth out
hard shadow lines.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
A relatively small amount of state to keep, just leave it there rather
than inventing any more types to pass around. Now that lightmap_t,
surfinfo_t & texorg_t are separate, I'm less concerned.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Substantial changes to TestLineOrSky which now becomes TraceLine to
more conveniently trace lines through the BSP and, terminate the trace
on specific contents and return information about the termination
point.
TraceLine also more correcly handles the cases where points are close
enough to the node planes to be considered "on-node" to ensure we get
a good intersection point back, when requested.
Finally, the algorithm for making the small adjustments to surface
points in CalcPoints has been changed so if the surface point can't
see the midpoint, we find the obscuring surface and move the surface
point just above that. Seems to work better and eliminates some (but
not quite all - midpoint is still not quite the ideal point to use)
random black spots.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
"nominlimit" is a more sensible default - people expect negative
lights to be able to subtract from minlight. The negative colors never
really worked properly and there's not really any worthwhile use for
the (that I know of).
Hopefully nobody will be too upset by these two changes to the old
behaviour.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
This option has been broken for a while, because we only dealt with
positive vs. negative colours and didn't properly handle the light
intensity.
All this messing around to try and correctly handle negative colors
seems just stupid. I might have to remove support for that in
future... is there really any good use for it?
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
More messing with data structures. Now a single sample has a
brightness and colour component and a lightmap structure captures all
the non-surface lightmap data.
The pointer arithmetic for iterating over the supersamples in
WriteLightmaps is perhaps a little silly, but it works well enough. It
might be smarter to generate the sample points in a different order
instead. Maybe later.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
A lot of churn for a small gain, but now the surface information is
separate from the lightmap data. And we can pass the surface
information around via a const pointer.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Eric Wasylishen
Kevin Shanahan