- Removing DIST_EPSILON #define from map.c. It's unused and only confuses
programmers.
- Adding new function SnapPlaneImproved() to map.c which is like
SnapPlane(), only it takes an additional argument which is the "center".
This new function is not being used anywhere yet.
- In mathlib, adding VectorIsOnAxis() and VectorIsOnAxialPlane(), two
convenience methods that will help make other code look more intuitive.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@400 8a3a26a2-13c4-0310-b231-cf6edde360e5
- Setting EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES to 1 (enabled). I'll
turn this off before merging into trunk.
- In function MapPlaneFromPoints() in map.c, doing a bit tighter math when
EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES is on. This comes at the
expense of a few extra CPU cycles. The signature of the function remains
the same.
- In VectorNormalize() in mathlib.c, fixing a cast of the return value.
I did not see compile warnings or runtime errors, but it seems wrong the
way it was.
- Adding VectorNormalizeAccu() in mathlib.c, for normalizing vectors built on
the high resolution data type.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@395 8a3a26a2-13c4-0310-b231-cf6edde360e5
- Renaming CopyWindingAccuToNormal() to CopyWindingAccuToRegular() in order to
avoid confusing "normal" (as in "regular") with "normal" (as in the normal
to the plane).
- In mathlib.h/mathlib.c, breaking out all the *Accu() #define functions
into actual functions in mathlib.c. I think this is much safer for ensuring
that the correct types are passed in. Otherwise math might take place
in the 32 bit world without any warning.
- Adding VectorCopyAccuToRegular() and VectorCopyRegularToAccu() to mathlib.
- Improving comments on VEC_SMALLEST_EPSILON_AROUND_ONE and
VEC_ACCU_SMALLEST_EPSILON_AROUND_ONE.
- Had to "adjust" some code in polylib.c due to the change in functions
in mathlib (moving from #define to actual functions).
In case you're curious as to the correctness of this code at this point:
I was able to compile Icy Fantasy -bsp stage in the same amount of time that
it took in the original q3map2 (23 seconds to be exact), and there are no
more disappearing triangles. I'm almost positive the regression tests are
fixed at this point, but there is no hurry in testing them because I still
have to comb through quite a bit of code to ensure that things are being
done correctly with respect to math accuracy.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@394 8a3a26a2-13c4-0310-b231-cf6edde360e5
- Adding a bunch of *Accu() functions:
* SnapWeldVectorAccu() in brush.c (needs major proofread).
* FixWindingAccu() in brush.c (needs major proofread).
* CopyWindingAccuToNormal() in polylib.c.
* VectorLengthAccu() in mathlib.c.
* Q_rintAccu() in mathlib.h.
* FreeWindingAccu() declaration in polylib.h (was missing).
- Adding a #ifdef's for EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES.
It's turned on now. Testing brush winding formation.
This code compiles on Linux, I have no idea if it works. About to test a
little, then going to bed.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@384 8a3a26a2-13c4-0310-b231-cf6edde360e5
- Added lengthy comment to describe the choice of smallestEpsilonAllowed
in polylib.c for the new 64 bit chopping code. I think that this comment
will allow us to make sure that we have the correct choice of epsilon.
- Tweaked comments around VEC_SMALLEST_EPSILON_AROUND_ONE and
VEC_ACCU_SMALLEST_EPSILON_AROUND_ONE (actually renamed them).
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@383 8a3a26a2-13c4-0310-b231-cf6edde360e5
- Adding new function ChopWindingInPlaceAccu() in polylib.c. This function is
just like ChopWindingInPlace() except that the winding input has the higher
vect_accu_t resolution. I actually did a deep massage of this code as well
(went over it with a fine-toothed comb). I still need to examine it at least
one more time when I'm fresh, and fix an issue related to choosing the value
for maxpts.
- In mathlib.h, defining VEC_SMALLEST_EPSILON and VEC_ACCU_SMALLEST_EPSILON
constants that will help determine suitable epsilons to use for certain
operations. Comments are provided detailing what these constants do.
- In mathlib.h, defining DotProductAccu() and VectorCopyAccu().
- Small comment in brush.c that has concerns about a certain use of
BaseWindingForPlane() in WriteBSPBrushMap().
State of this code is: compiles on Linux. May not compile on Windows. Not
tested (new functionality not used yet in any real code, only functions exist).
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@382 8a3a26a2-13c4-0310-b231-cf6edde360e5
- Adding new function BaseWindingForPlaneAccu() in polylib.c. Analogous to
original BaseWindingForPlane() only that the return value is a
winding_accu_t (new type w/ double precision). This function is not being
used yet.
- Restoring the original BaseWindingForPlane() function (pre-r371). Will keep
this as a reference. What I did exactly:
* Renamed BaseWindingForPlane() to BaseWindingForPlaneAccu(), changed stuff.
* Renamed _BaseWindingForPlane_orig_() to BaseWindingForPlane(), preserved.
- Adding things like vec_accu_t, vec3_accu_t, VectorSubtractAccu(),
VectorAddAccu(), VectorScaleAccu(), CrossProductAccu(), and
winding_accu_t. Also AllocWindingAccu() and FreeWindingAccu().
- Removing the recently added VectorSetLength() function because it is no
longer needed.
State of this code is: compiles, not tested (new functionality not used yet).
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/Rambetter-math-fix-experiments@381 8a3a26a2-13c4-0310-b231-cf6edde360e5
commit). I have disovered the fundamental problem to the math error problems,
and although this commit (r377) is "correct", it fails to address the
fundamental problem. Therefore, I'd rather leave the code in a state that
has the exact same behavior as before until I get a chance to address the
fundamental issue.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@379 8a3a26a2-13c4-0310-b231-cf6edde360e5
the approach that was committed in r375 (but was then backed out). I can't
believe my eyes, but I seem to be getting 0.000000% error in some of my
regression tests. The trick is to scale by a power of 2 and never do a
VectorNormalize().
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@377 8a3a26a2-13c4-0310-b231-cf6edde360e5
is totally unchanged, and I verified this by running extensive tests. The
only difference is that the math precision is much much better now.
Performance should be better as well (but that is not tested).
This is a major milestone because it fixes two regression tests:
disappearing_sliver2 and sparkly_seam.
Improvements to math precision is ongoing and more improvements can probably
be made even after this patch.
I will update the README.txt files in the regression tests in a separate
commit. This commit only includes the actual fixed code.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@371 8a3a26a2-13c4-0310-b231-cf6edde360e5
