bounce lighting generates a grid of bounces rather than a single light, improving lighting in conditions with larger faces or where the midpoint is blocked by other geometry
simplify the face structure; now, "fragments" just mean the output windings (if you opt out of tjunction fixing, then there will only be 1 fragment with the same values as original_vertices)
move MakeTangentAndBitangentUnnormalized to qvec.hh since we will use it later
-tjunc allows for more fine-grained control now (-notjunc still exists)
-maxedges now throws if you specify a bad value (1 and 2)
remove the checks to OmitFaces - we can tell if a face was omitted because it will have an empty winding
remove static variables from tjunc
* cmd
* cmake change for tbb DLLs
add in test for double-hyphens
* cmd
* game version
* settings!
* bsp texture usage
decompile fix for q1bsp
* finish up the options for qbsp
* light finished?
* finish up the few missing bits
* move scalar/int32 up
* Run clang-format pass
* natvis for our mathlib
use slightly faster storage for winding
fix light tests
* allow dictionary to be a base type
* re-run style
* Remove cfg_static
Fix options summary
* natvis for lockable_value<T>
* last-ish pass?
* format
* forgot last few lockables
- there's still a couple failure cases - specifically base1 in the outdoor area has a side that wasn't able to match to a face
- the clip brush at the start of base1 gets cut into a bunch of pieces because of the whole "check for texinfo, compare and split into multiple pieces" thing, but I'm pretty sure it's just one single brush - we need to ignore the splitting thing on clip brushes since they don't care about texture
- triggers don't pull in a temp texture
- origin brushes?
Fix normalize generating NaNs to match old behavior of generating zero on zero length
Remove extended texinfo file before potentially not writing new one
Adjusted makefile to work with both clang and msvc on win32
Removed "WIN32", use the standard _WIN32 instead
Fixed bad VectorCopy's
Use qvec4b instead of special color_rgba type
qvec now follows built-in type procedures for handling operators; this means that (qvec3i + qvec3f) will now properly produce a float, as one would expect, instead of adding the float to the integers without casting to the common type.
Jonathan
Eric Wasylishen
Random