Merge branch 'NateEag-master-patch-12920' into 'master'

[xonotic/netradiant.git] / regression_tests / q3map2 / disappearing_sliver2 / README.txt

diff --git a/regression_tests/q3map2/disappearing_sliver2/README.txt b/regression_tests/q3map2/disappearing_sliver2/README.txt
index 77ad09bd0b2de765fdd343be9c4a04d413da2c19..ffa12be5678ee509ca7a93ab141d6131b2bb277a 100644 (file)
--- a/regression_tests/q3map2/disappearing_sliver2/README.txt
+++ b/regression_tests/q3map2/disappearing_sliver2/README.txt
@@ -14,5 +14,80 @@ compile for any Q3 mod.
 SOLUTION TO PROBLEM:
 ====================
 
 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 commits to revisions 371 and 377.
+
+
+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.
+
+After the fix committed in revision 377, which is a further attempt to address
+BaseWindingForPlane(), we get the following accuracy:
+
+  (6784.00000000 16241.00000000 -1722.00000000)
+  (6144.00000000 16083.00000000 -1443.00000000)
+  (6144.00000000 16122.00000000 -1424.00000000)
+
+It's just a fluke for this particular case, but obviouly revision 377 looks
+favorably upon this regression test, because there is zero percent error.
+
+
+MORE NOTES:
+===========
+
+I attempted to improve upon revision 371 by streamlining the code in
+BaseWindingForPlane() some more.  Those attempts were committed as revision
+375.  After revision 375:
+
+  (6784.09375000 16241.01757812 -1722.04687500)
+  (6144.00000000 16082.99414062 -1443.00390625)
+  (6144.00000000 16122.00000000 -1424.00097656)
+
+Revision 375 has since been reverted (undone) because of the loss in
+accuracy.  Revision 377 is a fix for those failed attempts.