 |
In order to get through a sequence of portals, the following things are done: 1. The set of frustum planes is taken as initial "portal planes". 2. The portal polygon (i.e. "winding") is considered. 3. It is clipped against all the portal planes, obtaining smaller polygon (winding). 4. New set of portal planes is created from the clipped winding: each pair of subsequent generates a new plane (passing through eye). 5. Go to step 2 with new portal. The problem here is that both step 3 (clipping) and step 4 (generating planes) have no tolerance (aka "epsilon") in the checks. In other words, after clipping the winding can contain arbitrarily close adjacent points. When a portal plane is generated passing through such pair of close points, it is not checked properly if these two vectors are colinear or almost colinear. So the problem happens like this. Imagine that a portal plane goes through a vertex of the winding (or very close to it). Then the clipping routine produces two equal or almost equal vertices. When we generate a plane going through them, its normal is very unstable: its direction depends on luck and behavior of floating point errors and can be arbitrary. It can for instance cut the real winding into halves, thus incorrectly reducing the view visible through the portals. This is then taken into account when screen rectangle is calculated: it becomes less than it must be. As a result, scissor test culls out everything outside this erratic rectangle. |
|
|
In order to fix the issue, we need to check whether the normal of new portal plane is stably defined. Which is equivalent to having angle between two adjacent points of the winding not too small. If the angle is very small, we should simply drop the portal plane (dropping planes is always OK). Currently I added a check if the angle is less than 1.19e-4. If it is greater, than the plane's normal should have less than 1e-3 relative error after calculation, which should be OK. The angle threshold corresponds to about a half of arcminute, which is usually less than a pixel on player's screen. |
|
|
One important note is that such a issue can happen only when the visportals in a sequence are not in general position in the player's view. For instance, if you have many visportals sharing a common edge (or almost sharing), then such a problem is very likely to happen. Other case is when an edge of visportal lies on another visportal, with its endpoints being on the edges. If any vertex of any visportal in a sequence does NOT concide with another portal, then the issue is very unlikely to happen. |
 |
Fixed per stgatilov Rev 6840 Binary 14784 (Confirmed by me.) |
- Anonymous
