0000428: Portals Malfunction When Under Slopes Under Odd Con

These bugs do plan to be resolved, when they can be.

Moderator: GZDoom Developers

Post Reply
User avatar
6XGate
Posts: 8
Joined: Fri Feb 10, 2017 2:58 pm

0000428: Portals Malfunction When Under Slopes Under Odd Con

Post by 6XGate »

https://mantis.zdoom.org/view.php?id=428

Code: Select all

Summary	0000428: Portals Malfunction When Under Slopes Under Odd Conditions
Description	I 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.
Tags	No tags attached.
https://mantis.zdoom.org/file_download. ... 6&type=bug


Video link
User avatar
6XGate
Posts: 8
Joined: Fri Feb 10, 2017 2:58 pm

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Post by 6XGate »

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.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Post by Rachael »

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.
User avatar
6XGate
Posts: 8
Joined: Fri Feb 10, 2017 2:58 pm

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Post by 6XGate »

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Post by Graf Zahl »

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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Post by ZZYZX »

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.

https://github.com/coelckers/gzdoom/blo ... l.cpp#L525

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Post by Graf Zahl »

>> 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
Post Reply

Return to “On Hold Bugs”