mirror of
https://github.com/TTimo/GtkRadiant.git
synced 2025-01-25 10:51:36 +00:00
2913e619e7
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/trunk@373 8a3a26a2-13c4-0310-b231-cf6edde360e5
68 lines
2.3 KiB
Text
68 lines
2.3 KiB
Text
DESCRIPTION OF PROBLEM:
|
|
=======================
|
|
|
|
The example map, maps/disappearing_sliver2.map, contains an example of this
|
|
bug. The triangle sliver surface in the middle of the room is not rendered
|
|
in the final BSP.
|
|
|
|
To trigger the bug, compile the map; you don't need -vis or -light. Only
|
|
-bsp (the first q3map2 stage) is necessary to trigger the bug. The only
|
|
entities in the map are a light and a info_player_deathmatch, so the map will
|
|
compile for any Q3 mod.
|
|
|
|
|
|
SOLUTION TO PROBLEM:
|
|
====================
|
|
|
|
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.
|