0000428: Portals Malfunction When Under Slopes Under Odd Con

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

Moderator: Developers

0000428: Portals Malfunction When Under Slopes Under Odd Con

Postby 6XGate » Sun Apr 30, 2017 1:47 pm

https://mantis.zdoom.org/view.php?id=428
Code: Select allExpand view
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
 
Joined: 10 Feb 2017

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Postby 6XGate » Sun Apr 30, 2017 1:48 pm

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
6XGate
 
Joined: 10 Feb 2017

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Postby Rachael » Sun Apr 30, 2017 1:48 pm

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
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Postby 6XGate » Sun Apr 30, 2017 1:48 pm

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
6XGate
 
Joined: 10 Feb 2017

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Postby Graf Zahl » Sun Apr 30, 2017 1:48 pm

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Postby ZZYZX » Sun Apr 30, 2017 1:49 pm

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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: 0000428: Portals Malfunction When Under Slopes Under Odd

Postby Graf Zahl » Sun Apr 30, 2017 1:49 pm

>> 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
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to On Hold Bugs

Who is online

Users browsing this forum: No registered users and 1 guest