To be fair, I do find there is some quite predictable definition in the results, just not what the author of this thread expects.
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.