Unpegged texture through sector portal

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
User avatar
Sandro
Posts: 173
Joined: Sat Oct 05, 2013 8:03 am
Location: Erathia

Unpegged texture through sector portal

Post by Sandro »

It might be already well known but I haven't found anything related to this :

Unpegged textures that are entering a portal are not working properly (using [wiki]Sector_SetPortal[/wiki]).

In the lower sector it is displayed correctly
Spoiler:
But the upper sector is not rendering the texture inside itself.
Spoiler:
Using latest GZDoom build, also tested with QZDoom.

P.S : Dynamic lights rendering (defined in GLDEFS) seem to have troubles too - however in some cases it seems to work just fine - but that's another issue I guess.
Attachments
TEST.wad
(5.5 KiB) Downloaded 18 times
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: Unpegged texture through sector portal

Post by Graf Zahl »

Don't use textures like this in a portal. It will inevitably glitch a bit due to how portals are being processed. The texture should not cross the portal boundary or the results will be undefined.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Unpegged texture through sector portal

Post by Rachael »

To be fair, I do find there is some quite predictable definition in the results, just not what the author of this thread expects. :P

To understand how portals work you have to first unlearn everything you know about 3D space. This isn't the "game" Portal where we have a courtesy Source engine that can render objects twice when they go through it. What's happening in a portal is an optical illusion - everything on the other side is in fact being rendered into a "window" so to speak (well, a stencil in technical terms) - in Lehman's terms, that means everything that's in the room you're presently in will appear in front of anything inside the portal, even if what's inside the portal would otherwise take up space in the room you're in.

This will happen no matter what - if an object is inside a portal and it is closer to you than an object that is further away but inside the room with you, the object that is inside the room with you will be rendered over it. You simply don't notice that effect occurring because it's extremely rare for an object to be further away without crossing the portal boundary first, anyhow. Source games solve this effect by splitting and rendering each portal-affected object twice - once inside the portal, and once in the room where it "should" be. GZDoom will not do that.

So in order to do this properly in GZDoom, the affected object will need to be set up twice - once in each portaled subsection, and in each case they will have to cut off right at the portal line or the visual effect may get messed up.
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: Unpegged texture through sector portal

Post by Graf Zahl »

Rachael wrote:. Source games solve this effect by rendering each portal-affected object twice - once inside the portal, and once in the room where it "should" be. GZDoom will not do that.

Sorry, but that's not correct. Sprites will actually be rendered twice on both sides of the portal. The effect here comes from how the stencil for the portal is generated and a lot of this comes from the portal code originating from sky rendering: It's not the portal flat that is being drawn into the stencil, but actually the upper parts of the walls extended into infinity, so that sprites and some texture based linedef effects are not chopped off.

And here's where it gets tricky. In order to properly handle sprites there's already a lot of bookkeeping needed but that's unavoidable because sprites are moving objects.
If the same had to be done to walls, too, a lot more bookkeeping would be needed but since walls are statically placed it's just easier to skip this part and say "do not let textures extend through the portal", to avoid the drag on performance (remember: This code would have to be run for every wall in the scene at least partially.)
Post Reply

Return to “Closed Bugs [GZDoom]”