version of code in VectorNormalize() is used. Yes, I put the old code back
in there, and it's active if MATHLIB_VECTOR_NORMALIZE_PRECISION_FIX is 0.
Right now it's 1, so the fixed code is active. I need this quick way to
test regression tests.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@424 8a3a26a2-13c4-0310-b231-cf6edde360e5
into trunk. Right now all the new code that fixes problems is turned off.
There are three new #defines in q3map2.h:
EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES, EXPERIMENTAL_SNAP_NORMAL_FIX,
and EXPERIMENTAL_SNAP_PLANE_FIX. All of these are currently set to 0, which
means don't enable that new code. You can easily edit these to be 1 in order
to enable the new code.
There are very very minor changes to the code even with these three #defines
disabled. They are as follows.
- In PlaneEqual() in map.c, now considering deltas equal to given epsilon
values as "far enough to be different". Previously, the '<=' operation was
used, now '<' is being used.
- In FindFloatPlane() in map.c, considering delta equal to distanceEpsilon
(for plane distance) to be sufficiently far away. Before, delta had to be
strictly greater than distanceEpsilon.
- VectorNormalize() in mathlib.c is more accurate now. This change itself
causes at least one regression test to succeed. The previous implementation
of VectorNormalize() caused excessive errors to be introduced due to sloppy
arithmetic.
Note, the epsilon changes account for the possibility that the epsilons
are set to 0.0 on the command-line.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@416 8a3a26a2-13c4-0310-b231-cf6edde360e5
and mathlib.h (the regression tests have not been removed).
Trunk is now restored to a state that it was in before I started
trying to fix the math accuracy errors in q3map2. Commits r363 and
r371 were "correct" and did improve math accuracy significantly, but
unfortunately the underlying cause of math accuracy issues is something
else, which is being addressed in branch Rambetter-math-fix-experiments
currently. I'm taking the BSD approach here, which is "we not going to
partially fix the problem. it's all or nothing". Otherwise it's just
too risky in my opinion. I don't like playing Whack-A-Mole.
Someday, we might merge Rambetter-math-fix-experiments branch to trunk.
Sorry about all these needless commits to trunk.
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@390 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
Timothee TTimo Besset
rambetter
TTimo