 |
portaltest.wad (39,016 bytes) |
|
|
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. |
 |
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. |
|
|
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. |
 |
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. |
 |
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/blob/master/src/portal.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. |
|
|
>> 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 |
- Anonymous
