regression_tests/q3map2/disappearing_sliver2/README.txt

   1 DESCRIPTION OF PROBLEM:
   2 =======================
   3
   4 The example map, maps/disappearing_sliver2.map, contains an example of this
   5 bug.  The triangle sliver surface in the middle of the room is not rendered
   6 in the final BSP.
   7
   8 To trigger the bug, compile the map; you don't need -vis or -light.  Only
   9 -bsp (the first q3map2 stage) is necessary to trigger the bug.  The only
  10 entities in the map are a light and a info_player_deathmatch, so the map will
  11 compile for any Q3 mod.
  12
  13
  14 SOLUTION TO PROBLEM:
  15 ====================
  16
  17 It was discovered that BaseWindingForPlane() in polylib.c did some sloppy
  18 mathematics with significant loss of precision.  Those problems have been
  19 addressed in commit revision 371.
  20
  21
  22 POSSIBLE SIDE EFFECTS:
  23 ======================
  24
  25 Great care was taken to preserve the exact behavior of the original
  26 BaseWindingForPlane() function except for the loss of precision.  Therefore
  27 no negative side effects should be seen.  In fact performance may be
  28 increased.
  29
  30
  31 IN-DEPTH DISCUSSION:
  32 ====================
  33
  34 Turns out that the problem is very similar to the original disappearing_sliver
  35 regression test.  You should read that README.txt to familiarize yourself
  36 with the situation.
  37
  38 The thing we need to look at is side 0 of brush 0, if you applied
  39 winding_logging.patch from disappearing_sliver regression test:
  40
  41   In ParseRawBrush() for brush 0
  42       Side 0:
  43           (6784.000000 16241.000000 -1722.000000)
  44           (6144.000000 16083.000000 -1443.000000)
  45           (6144.000000 16122.000000 -1424.000000)
  46
  47 That is the exact plane defninition of our problem sliver, and in fact those
  48 are also the correct points for the actual vertices of the triangle.
  49
  50 Now the results of the winding for this surface after all the clipping takes
  51 place:
  52
  53   (6784.12500000 16241.02343750 -1722.06250000)
  54   (6144.00000000 16082.99218750 -1443.00781250)
  55   (6144.00000000 16122.00000000 -1424.00390625)
  56
  57 As you can see, 6784.12500000 is more than epsilon distance (0.1) away from
  58 the correct point.  This is a big problem.
  59
  60 After we apply the fix committed in revision 371, the result after clipping
  61 is this:
  62
  63   (6784.06250000 16241.01171875 -1722.03515625)
  64   (6144.00000000 16082.99609375 -1443.00781250)
  65   (6144.00000000 16122.00000000 -1424.00585938)
  66
  67 As you can see, all points but one have an increase in accuracy.  This is
  68 still not accurate enough in my opinion, but is a step in the right direction.