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>
Check whether any of the entities have colored fields set and if so,
enable colored light output. Can still be overridden from the command line
if needed.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The "fatbin2" target isn't working yet since I don't have the right cross
compiler set up, but once I do then adding CC=foo to the $(MAKE) command
should be all that is needed.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Implement the two extra light attenuation formulae that were added to
Benjt Jardrup's light util (http://user.tninet.se/~xir870k/readmevis.txt).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
I guess this bug has been here a long time. This was preventing us from
using all four available lightmaps in most cases. Now fixed!
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
No more games with save/modify/restore on the entity->lightcolor.
Could have actually caused nasty races in the multithreaded case.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Stop playing silly games with saving, modifying and restoring the global
sunlight_color. A couple of variable naming changes in lightface and use
an entity pointer instead of always indexing into the global array.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Some editors will work with floating point rotations, so let them keep the
precise texture alignment written to the .map file.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Add some manpage-like documentation for the three main compile utils.
Some updates for README.txt to ready for a new release.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
First pass at detail support as implemented in tyr-qbsp, using the PRT2
file format (hopefully nobody else already decided to use that?)
Because the "leaf" terminology is pervasive across the source, I've left
it there for now (so "leaf" usually now means "cluster") and added a few
variables with the "_real" suffix when they actually mean the real leafs
and not the clusters which vis still calls leafs. A bit disgusting, but it
actually works so I'll go through and clean up naming, etc. later.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Took a while to find this - need to make sure that we actually count and
write out the portals which get attached to the top node of a detail
cluster (with ->detail_separator set true).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Update PortalThru() to take the portal as it's argument, then we can
examine the two nodes on either side of the cluster. The nodes could
either be leafs or clusters.
Walk the detail clusters recursively and if the contents are all the same,
return that, otherwise if there is some empty space, leave it as empty.
Similarly, if there is some water, return water, etc. Basically non-solids
take precedence over solids in calculating the contents of the cluster.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kind of messy but necessary to either write the number of entries at the
start of the line or write a terminator for vis' fscanf style of parsing
to work easily on the .prt file. Writing a terminator is easier for the
way qbsp is currently set up, so do that.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Now that I've done this I realise there could be a more compact
representation by just specifying the number of leafs per cluster, since
leaves are sequentially numbered... but this format is okay as well. And
easy to parse, etc.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Fairly simple extension of the original "PRT1" format; the first four
lines are:
Identifier := "PRT2"
Number of Leafs := INTEGER
Number of Clusters := INTEGER
Number of Portals := INTEGER
Followed by one line for each portal made up of the following, separated
by whitespace:
Number of points on the portal winding := INTEGER
Cluster Number on the front side of the portal := INTEGER
Cluster Number on the back side of the portal := INTEGER
For each point, a coordinate in the format ( x y z ), where x, y, z are FLOATs.
After the portal descriptions, there will be one line for each cluster
which lists the leaf numbers included in that cluster.
LEAF1 LEAF2 LEAF3 ...
I should probably write this up in BNF somewhere, but it's pretty straight
forward.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The test here was really to see if we need to add a portal between two
adjacent leafs with the given content. Rename and re-arrange the code a
little to make it a bit easier to read.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kevin Shanahan