ZDoom

Graf Zahl wrote:only

And of course i've got no idea of how to do it, i'm not that smart. Do you mean using the existing FBoundingBox class and r_viewpoint.Pos? I'd need to get the vertexes from somewhere else. The problem is the stuff in hw_portal.cpp of course.
Is this really that important? If someone wants to help...

No, not really. The bounding box only checks the actual lines that get added to the portal.

Ultimately, though, don't be surprised that as time moves on it gets increasingly harder to keep the ancient code base in sync with current development.

And it seems this cannot be merged (requires sections).

After thinking about this issue for a while I had to conclude that with the portal setups out there a proper fix is plain and simply impossible.
The amount of maps that abuse Doom's strange sky mapping in a way to defeat any robust mechanism is unbelievable.

So I went for the cheap route and only calculate a portal's bounding rectangle and restrict the cap to that. For most cases that should be sufficient. To break this it really needs some deliberately fucked up setup with multiple mergeable portal areas and some incompatible ones in-between.

I'll only think about that when I actually see it.


@drfrag: If you find my first commit too hard to merge, just forget about it. It's more cosmetics to make the setup a bit nicer.
The second one contains the relevant code you need to adjust.

Thanks for posting all that information. I can see why this is a tricky situation to try and resolve efficiently.

So I finally got to the bottom of this mess after analyzing the different parts of the code back and forth.

This is a side effect of a recent fix where nested portals were interfering with each other. Unfortunately that fix now causes portals on the same nesting level but in different areas to interfere.

It all boils down to a major design flaw that was caused by how Doom renders skies. Instead of closing off the portal with the actual sector ceiling it has to draw a wall into infinity. Of course you cannot draw into infinity, so the stencil gets capped at a certain height - and that cap has no shape. It's just a rectangle across the entire potential map area.

What now happens is that the portal near the player gets rendered first. This works as intended. Now a second sky portal gets drawn. Here the problem occurs: The cap not only covers that portal's area but the entire map, including the area the player is in. But since the local portal has no defined ceiling, that other portal gets drawn in the small space left by the walls that should be infinitely tall but aren't.

Fixing this will require collecting a lot more information about the portal, which cannot be done without some performance hit. I still have to see what is needed here to not let this escalate.
For real portals this isn't too big of a problem because the maximum area they span is static and readily accessible. For reflective floors and ceilings the impact can be ignored because their area will be rather limited most of the time. Not so for skies. Skies can span entire maps and can be highly dynamic - changing them only requires setting a sector's texture. So I'll have to see what can be done here.

It most likely branched off after introducing the bug. I've been analyzing the code for half a day now and I still haven't found out what precisely makes it go wrong.

This happens in the vintage build as well.

So, logically this happened in the big refactoring commit. And I absolutely cannot see what is different. This is going to be fun to fix...

This happened somewhere between 3.4 and 3.5, but I haven't found out yet where it broke

Graf Zahl wrote:The shape can easily be seen by setting the fov to 10.

Indeed.

Interesting stuff.

I know where these come from. The stencil cap apparently does not get rendered properly. I already fixed this a few months ago but it must have snuck in through some backdoor I haven't found yet.

The shape can easily be seen by setting the fov to 10.

You probably already know this but, just in case, the "dot" is actually a view of one of the other skies in the map. I just noticed this after making a modified UDMF version of the test map. I set the light pulsing in the dark box to be more obvious and I was therefore able to notice the pulsing effect in the "dot" in the cloudy sky. So, in the above shots, the dot in the cloudy sky is probably a view into the dark skybox (the one with the BFG shots) and the light coloured dot in the dark sky is a view to the cloudy skybox.

Interestingly (to me anyway) is that the two sectors that are meant to show the cloudy sky actually have different coloured dots. The area that the player starts in shows a dot from the dark sky whereas the adjacent area with the same cloudy sky shows a brownish coloured dot like a view to the cap colour of the default Doom2 sky1 texture (which is, of course, a sky in another area of the map).

Why has this crap come back? I thought I had it fixed some time ago...

I was taking a look at the original skybox example and I noticed a "dot" in the middle of the sky when I looked straight up.

Dark dot in cloudy sky


Light dot in black sky


And the MAP01 sky in the same map


Just load the map and look up. You may have to move around a little to see the effect because it comes and goes a bit - and for some reason it seems to do that a little more in the starting area - but it's not hard to make it happen.

Seen with both g3.7pre-216-gf6af50fc7 and g3.6.0