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>
Need to be a little more careful to order brushes correctly when adding
detail to the worldspawn. CSGFaces assumes that the brushes are ordered
such that earlier brushes have chunks carved out of them by any later
brushes that intersect them.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
During conversion from map brushes to bsp brushes, set the brush detail
flag for later use in CSGFaces().
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Pull the progress output up into the caller (not ideal) to deal with the
fact we are making extra calls to load the detail entities for the
worldspawn.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The first step towards supporting detail brushes for Quake 1. This gives
us a way to add detail brushes to a map within the existing mapping tools. A
mapper can simply add a definition for a "func_detail" entity to their
editor and create func_detail entities.
Of course, currently they will behave exactly like world brushes. Future
patches will start to treat them differently.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Make Brush_LoadEntity() take a source and destination entity arguments. In
order for this to work, intialisation is done before calling and then the
BSP brushes generated from the source entity's map brushes are added to
whatever is already in the destination entity.
Reasons for doing this will become obvious with the following patch! :)
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kevin Shanahan