View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003815||The Dark Mod||Coding||public||16.08.2014 05:04||19.10.2023 19:21|
|Product Version||TDM 2.02|
|Target Version||TDM 2.03||Fixed in Version||TDM 2.03|
|Summary||0003815: Side-on visportals can cause game freezes|
|Description||The game can freeze for extended periods if the player gets in line with multiple side-on visportals between the same two visleafs. Getting in line with an open visportal also causes nearby visportals to open inappropriately.|
An old bugfix in the renderer made it so that the player view isn't clipped by an open VP when they're close to its plane. But it looks like it meant to handle only the case where the player is right next to the VP. Added a further check after the plane-distance check to verify that the view origin is within 1 unit of the portal's bounds. The plane-distance check is still there and gets done first for efficiency, as it's already been calculated in the function anyway.
Freezes were caused by the renderer recreating the light/surface interactions once for every possible combination of coplanar open VPs, and their number is doubled if the player is within 0.1 units as the view can propagate through a VP both ways. There's no ordering of the portals, and if any portal is in view after player's view has passed a portal, it's considered to be a valid path to explore. Not clipping the view means that every portal is "behind" every other.
|Additional Information||Full description and diagrams in this thread: http://forums.thedarkmod.com/topic/16254-invisible-brush-of-death-its-doing-my-head-in/|
|Tags||No tags attached.|
|Committed at rev 6083|
The same issue happens for light passing through visportals.
Before 0005172, this could happen only if static light happens to be almost exactly on a plane with several visportals, so nobody caught it.
After 0005172, the code runs for dynamic lights as well, and this the issue happens as easily as for view/player.
I added test map FloodLightThroughPortals_Overflow.map.
Grab the candle (with heavily increased light radius) and try to cross some visportal between rooms.
If the source point is within 0.1 distance from portal plane, then the code allows to go through the portal both directions.
Also in this case it does not clip the light beam, because that would generate imprecise light beam.
This allows passing through several portals on same plane many times --- not infinite though, because passing through same portal twice on single light beam path is forbidden.
I was trying to invent some solid solution that would guarantee no complexity explosion from such "pass-through" portals, without any dependency on geometry/floats.
But I quickly gave up and decided to reuse with SteveL's solution.
Basically, we allow the pass-through code path only when the source point lies on the visportal polygon (with tolerance up to 1.0 doom unit).
If the source point is on the portal plane but it is far outside the portal winding, then we use the usual code with clipping.
I only made a tiny improvement here: SteveL's code checks point against bounding box of the portal.
Now point is precisely checked against the polygon/winding of the portal.
Committed in svn rev 10464.
|16.08.2014 05:04||SteveL||New Issue|
|16.08.2014 05:04||SteveL||Status||new => assigned|
|16.08.2014 05:04||SteveL||Assigned To||=> SteveL|
|16.08.2014 05:26||SteveL||Note Added: 0006851|
|16.08.2014 05:51||SteveL||Status||assigned => resolved|
|16.08.2014 05:51||SteveL||Fixed in Version||=> TDM 2.03|
|16.08.2014 05:51||SteveL||Resolution||open => fixed|
|16.08.2014 05:58||SteveL||Description Updated|
|19.10.2023 11:03||stgatilov||Note Added: 0016134|
|19.10.2023 19:12||stgatilov||Note Added: 0016137|
|19.10.2023 19:21||stgatilov||Note Edited: 0016137|