ioquake/gtkradiant
0
0
Fork 0
mirror of https://github.com/TTimo/GtkRadiant.git synced 2024-11-10 07:11:54 +00:00
Code Issues Projects Releases Packages Wiki Activity

Writing up results of disappearing_sliver2 regression test and commit 371.

Browse source 
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@373 8a3a26a2-13c4-0310-b231-cf6edde360e5
This commit is contained in:
rambetter 2010-12-28 11:09:06 +00:00
parent 538e4a59fc
commit 2913e619e7
1 changed files with 52 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

54
regression_tests/q3map2/disappearing_sliver2/README.txt
View file

@ -14,5 +14,55 @@ compile for any Q3 mod.
SOLUTION TO PROBLEM:
====================
None yet. The problem is likely caused by sloppy math operations (significant
loss of precision).
It was discovered that BaseWindingForPlane() in polylib.c did some sloppy
mathematics with significant loss of precision. Those problems have been
addressed in commit revision 371.
POSSIBLE SIDE EFFECTS:
======================
Great care was taken to preserve the exact behavior of the original
BaseWindingForPlane() function except for the loss of precision. Therefore
no negative side effects should be seen. In fact performance may be
increased.
IN-DEPTH DISCUSSION:
====================
Turns out that the problem is very similar to the original disappearing_sliver
regression test. You should read that README.txt to familiarize yourself
with the situation.
The thing we need to look at is side 0 of brush 0, if you applied
winding_logging.patch from disappearing_sliver regression test:
In ParseRawBrush() for brush 0
Side 0:
(6784.000000 16241.000000 -1722.000000)
(6144.000000 16083.000000 -1443.000000)
(6144.000000 16122.000000 -1424.000000)
That is the exact plane defninition of our problem sliver, and in fact those
are also the correct points for the actual vertices of the triangle.
Now the results of the winding for this surface after all the clipping takes
place:
(6784.12500000 16241.02343750 -1722.06250000)
(6144.00000000 16082.99218750 -1443.00781250)
(6144.00000000 16122.00000000 -1424.00390625)
As you can see, 6784.12500000 is more than epsilon distance (0.1) away from
the correct point. This is a big problem.
After we apply the fix committed in revision 371, the result after clipping
is this:
(6784.06250000 16241.01171875 -1722.03515625)
(6144.00000000 16082.99609375 -1443.00781250)
(6144.00000000 16122.00000000 -1424.00585938)
As you can see, all points but one have an increase in accuracy. This is
still not accurate enough in my opinion, but is a step in the right direction.