View Issue Details

IDProjectCategoryView StatusLast Update
0000428Software Renderer[All Projects] Bugpublic2017-04-30 13:55
Assigned ToRachael 
Status closedResolutionopen 
Platformx64OSWindowsOS Version10
Summary0000428: Portals Malfunction When Under Slopes Under Odd Conditions
DescriptionI am seeing a situation where sector portals will malfunction when standing under a sloped sector. The issue seems to be triggered by having a zero high sector in the area seen through the portal. Here is a video of the issue.
TagsNo tags attached.





2017-03-13 14:28


portaltest.wad (39,016 bytes)


2017-03-13 14:32

reporter   ~0000963

This happens under QZDoom-q2.0pre-34-gba844fd2c, the latest as of this note. I should note that a workaround for this it to not have a zero height sector visible through the portal.


2017-03-13 16:01

administrator   ~0000969

This is because of how portal clipping is handled. Unfortunately it's a very complicated issue not really helped by the code being completely helter skelter in this place.

Basically, in the Doom engine, a single wall is infinitely tall no matter how high the adjacent floor is to it. And because of that the BSP engine refuses to render anything behind it because it doesn't make sense to render what you can't see, does it? Except in this case, obviously, you can because you are *under* the wall which does not account for the fact that it is still infinitely tall.

GZDoom handles this more gracefully because it is not only able to clip away anything that is between you and the portal, but it also does not have this problem with walls being infinitely tall.

Even worse is the fact that in ZDoom you can only have 1 sector portal per column due to the way the portal buffer is handled.

So yes, this is a known issue, but there is really no easy fix at this time.

The example wad will definitely come in handy if someone decides to tackle this issue, though.


2017-03-13 17:22

reporter   ~0000972

I started to see that as I modified that WAD. The one side of the room that only breaks the portal by fully removing the other side completely can be fixed by not having the zero height sector. But; the other side, which only has partial breakage by allowing the walls from my current sub-sector to bleed in at certain points, stays broken the way it is no matter what I do.

I'm guessing this is also due to the nodes. I've seen perfectly symmetric rooms get very asymmetric nodes, so I'm not surprised.

Thankfully if I get nodes that only break the portal by just causing the HOM, not having a zero height sector or gap will make that not be an issue. The other breakage was odd in that it doesn't completely shutdown the portal but rather cause the walls I'm already seeing to be drawn within it. I'm guessing due to me crossing through sub-sectors that go down a different path in the BSP tree.
Graf Zahl

Graf Zahl

2017-03-15 04:17

administrator   ~0001005

To elaborate on why this works in GZDoom:

No, it is not about walls not being infinitely tall, for the purpose of clipping they are so as well in GZDoom.
The reason this works better is because I went to great lengths to set up a data structure that allows checking every linedef being clipped against the portal's silhouette and discard everything that lies in front. In fact, if there is no portal at the camera point, the clipper starts entirely closed, so that everything that comes along is getting discarded.

And when a portal boundary is reached, the respective part in the clipper gets opened again. This can go on over multiple steps so that it works as intended for a multi-section portal.

This could also be done in the software renderer, but like Rachael said, the code is all over the place - it was just a quick hack to make some basic portals work but was quickly abandoned when the first serious problems started to show up. I guess with some real dedication it could have been fixed but Randi lost interest as quickly as the feature was started. It's a testament to mappers' creativity that this broken feature was actually used for good effect.


2017-03-16 07:21

reporter   ~0001017

Last edited: 2017-03-16 07:32

View 4 revisions

I had a function in the old wall portals that'd clip anything to a plane. The problem with sector portals can be solved by calculating a plane that faces away from the viewer and goes through the nearest 2d vertex of the portal sector — everything closer than this plane should be clipped away.

Also, it's not about the BSP, it's about the code that explicitly prevents rendering anything behind an one-sided wall that's been already rendered (or thought to be rendered).
At least that's what it is from my experience. The problem might be caused by few overlapping things at once.

Graf Zahl

Graf Zahl

2017-03-18 19:47

administrator   ~0001049

>> I had a function in the old wall portals that'd clip anything to a plane. The problem with sector portals can be solved by calculating a plane that faces away from the viewer and goes through the nearest 2d vertex of the portal sector — everything closer than this plane should be clipped away.

That is not enough for sector portals. There's several far more tricky cases and the approach in GZDoom is a lot more involved than just checking a single plane

Issue History

Date Modified Username Field Change
2017-03-13 14:28 6XGate New Issue
2017-03-13 14:28 6XGate File Added: portaltest.wad
2017-03-13 14:32 6XGate Note Added: 0000963
2017-03-13 16:01 Rachael Assigned To => Rachael
2017-03-13 16:01 Rachael Status new => on hold
2017-03-13 16:01 Rachael Note Added: 0000969
2017-03-13 17:22 6XGate Note Added: 0000972
2017-03-14 00:29 Rachael Assigned To Rachael =>
2017-03-15 04:17 Graf Zahl Note Added: 0001005
2017-03-16 07:21 ZZYZX Note Added: 0001017
2017-03-16 07:22 ZZYZX Note Edited: 0001017 View Revisions
2017-03-16 07:24 ZZYZX Note Edited: 0001017 View Revisions
2017-03-16 07:32 ZZYZX Note Edited: 0001017 View Revisions
2017-03-18 19:47 Graf Zahl Note Added: 0001049
2017-04-30 13:55 Rachael Assigned To => Rachael
2017-04-30 13:55 Rachael Status on hold => closed