Wall portals

Moderator: GZDoom Developers

User avatar
edward850
Posts: 5886
Joined: Tue Jul 19, 2005 9:06 pm
Location: New Zealand
Contact:

Re: Wall portals

Post by edward850 »

It might not need much, if your theory before is the solution. The plane portals at this stage only work on the train at the start, and only when you're in exact proximity, which makes me wonder if rendering wise the camera is still clipping into something. It definitely appears to try and render them based on performance usage, but there's just no visible result.
Scratch that. What I thought was lack of rendering due to r_clearbuffer was actually just a black texture on planes. Are portal planes not entirely in the xlat yet?
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: Wall portals

Post by Graf Zahl »

No. The linked portals are currently not defined for ZDoom. But I have tried, they are completely broken.
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: Wall portals

Post by Tormentor667 »

Graf Zahl wrote:In GZDoom things look different.
That's what I wanted to hear :)
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Wall portals

Post by ZZYZX »

Graf Zahl wrote:- any passable portal is required to have some space behind the portal line to ensure no physics breakage (no, it's not possible without that, not universally!)
Please NOT THIS. This makes 2-sided portals outright impossible to implement.
Graf Zahl wrote:- interactive portals handle anything a teleporting portal can, plus any action from another actor that reaches through a portal (like a projectile spawn at an offset), provided that there's no z-offsetting.
Why the hell no z-offsetting?

"no physics breakage" with portals is ensured by slight modification to PIT_CheckThing and PIT_CheckLine, I've got that working multiple times.
The test case and the goal for me was flat 2-sided line in the center of a sector that should act like a valid portal, no matter what's behind or around the line. In the portals branch I've almost had this working. In the portals2 (original one) I've also almost had this working. Consider this image.
The whole time I was making the portal code, I had this particular picture in mind and thought that it SHOULD work like that. That's the reason for overcomplicated mirror/portal render clipping as well. This also makes it better than Eternity which has requirements and restrictions all over the place even after printz advanced them.
And now you just want to throw it away because too complex PIT_CheckThing rewrite which you probably wouldn't even need to make if you make a branch to which I'd be able to commit.


P.S. edward850, what's the music used in that video? *god, people should start writing music tracks in their YT videos like I always did*
User avatar
edward850
Posts: 5886
Joined: Tue Jul 19, 2005 9:06 pm
Location: New Zealand
Contact:

Re: Wall portals

Post by edward850 »

ZZYZX wrote:P.S. edward850, what's the music used in that video? *god, people should start writing music tracks in their YT videos like I always did*
From the exact same wad, Vaporware. It would be beyond redundant for me to say that, now wouldn't it?
Last edited by edward850 on Sat Feb 06, 2016 7:33 am, edited 1 time in total.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Wall portals

Post by ZZYZX »

edward850 wrote:From the exact same wad, Vaporware. It would be beyond redundant for me to say that, now wouldn't it?
o. Sorry, haven't played it ever.
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: Wall portals

Post by Graf Zahl »

ZZYZX wrote:
Graf Zahl wrote:- any passable portal is required to have some space behind the portal line to ensure no physics breakage (no, it's not possible without that, not universally!)
Please NOT THIS. This makes 2-sided portals outright impossible to implement.
With 'space behind' I mean that on the backside there must be something VALID - i.e. no empty space. Portals on two-sided lines are ok. Passable portals on one-sided walls are a gamble - if they work there's normally enough space behind to put a real sector there. But I'm not willing to take lucky shots at the node builder et.al. to ensure that there isn't something obstructing behind.

If an actor trying to move into a one sided wall for teleporting this creates an undefined situation if there's some blocking geometry behind. It may work - it may not. The room behind a portal should be a clear sector with no obstacles, otherwise you'll have to hack - and this I won't.
Why the hell no z-offsetting?

"no physics breakage" with portals is ensured by slight modification to PIT_CheckThing and PIT_CheckLine, I've got that working multiple times.
no z-offsetting when you want more involved interaction. As I said, P_TryMove and its subfunctions, P_RadiusAttack and P_RecursiveSound should be fine, but when it comes to other actions that may cross the portal, there's just too much mess in the code to make this simple.

Portals can be two things:

a) prettyfied teleporters. These will have very little limitations on placement (the main one is to avoid rendering glitches) and only check portals in the abovementioned 3 functions (and since PIT_CheckLine is part of P_TryMove it's of course included.)
b) interactive connections between different parts of the map that monster AI can deal with.

b) is absolutely non-trivial with sight checking, spawn offsets etc. To fully handle this the Eternity way with severe limitations on placement is pretty much the only solution, i.e. no weird angles and fixed offsets between map sections. These are fundamental necessities if you want to calculate line of sight without randomly firing traces at potential portal candidates (and don't even start thinking about monster movement here!)
Part of this may be doable with other portals too - how much I cannot tell yet (and this stuff is very much at the end of my to-do list, I won't touch it unless the basics work.)

So my roadmap here is:

1. Make P_TryMove work (and make it work well!)
2. Make P_RadiusAttack work
3. Make P_RecursiveSound work
4. Thoroughly test the stuff.
5. Implement offsetting for static portals
6. Make sure that everything deals properly with static portals
And only then:
7. Think about what non-static portals can do to be more interactive.
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: Wall portals

Post by Graf Zahl »

ZZYZX wrote:This also makes it better than Eternity which has requirements and restrictions all over the place even after printz advanced them.

No, it doesn't make it better.
It makes it something completely different and limited in other ways. I want both. But I don't want a mess. It's not you who has to maintain this code in the future, it's me.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: Wall portals

Post by ZZYZX »

Graf Zahl wrote:With 'space behind' I mean that on the backside there must be something VALID - i.e. no empty space. Portals on two-sided lines are ok. Passable portals on one-sided walls are a gamble - if they work there's normally enough space behind to put a real sector there. But I'm not willing to take lucky shots at the node builder et.al. to ensure that there isn't something obstructing behind.

If an actor trying to move into a one sided wall for teleporting this creates an undefined situation if there's some blocking geometry behind. It may work - it may not. The room behind a portal should be a clear sector with no obstacles, otherwise you'll have to hack - and this I won't.
Consider a 2-sided line on one side of which a random actor stands (a torch). The player tries to move into a portal, and the torch is on the other side of local line. Does the player get blocked by the torch from entering the portal?
http://i.imgur.com/Vvc1t5A.png
Note that while a mapper can be told to not allow any solid actors/walls there, it can easily happen in multiplayer by having another player stand there.
Graf Zahl wrote:b) is absolutely non-trivial with sight checking, spawn offsets etc.
I was going to limit sight range for portals (pretty much as it's done for sight range for FRIENDLY monsters, i.e. 1280 units) and scan sectors around the monster (and then recursively scan sectors around every portal, and calculate a direction vector somehow based on current portal stack, with limit of ~3-4 recursive portals) in order to handle sight in portals. Monster movement is simply "move to a portal" in case thing was seen in a portal. Everything further would require testing and more hacking, so I didn't think that far.
Graf Zahl wrote:
ZZYZX wrote:This also makes it better than Eternity which has requirements and restrictions all over the place even after printz advanced them.

No, it doesn't make it better.
It makes it something completely different and limited in other ways. I want both. But I don't want a mess. It's not you who has to maintain this code in the future, it's me.
meh. Okay, sounds legit enough so I stop flaming on this. :P
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: Wall portals

Post by Graf Zahl »

ZZYZX wrote:Consider a 2-sided line on one side of which a random actor stands (a torch). The player tries to move into a portal, and the torch is on the other side of local line. Does the player get blocked by the torch from entering the portal?
http://i.imgur.com/Vvc1t5A.png
Note that while a mapper can be told to not allow any solid actors/walls there, it can easily happen in multiplayer by having another player stand there.
Quite obviously, the torch will block unless you add some insane fudging code that will eventually explode in your face. I think there's a reason why Eternity never removed this particular limitation from its portals.
It seems you are only looking at the simple cases but not the dirty details of what needs to be considered here (which goes far beyond PIT_CheckLine and PIT_CheckThing.) And I prefer to set some rules that keep the code maintainable and not try to work around eventual obstacles to allow ultimate freedom.

Graf Zahl wrote:b) is absolutely non-trivial with sight checking, spawn offsets etc.
I was going to limit sight range for portals (pretty much as it's done for sight range for FRIENDLY monsters, i.e. 1280 units) and scan sectors around the monster (and then recursively scan sectors around every portal, and calculate a direction vector somehow based on current portal stack, with limit of ~3-4 recursive portals) in order to handle sight in portals. Monster movement is simply "move to a portal" in case thing was seen in a portal. Everything further would require testing and more hacking, so I didn't think that far.
[/quote]

Yes, good luck with that. It'd mean a massive change to the monster ocde and we all know how fickle that is. Which is why I put such stuff at the very bottom of things to do. It's pointless to think about it when far simpler stuff cannot cope well with a portal setup that has no limiting rules. Remember: The limits are not there to annoy you but to streamline the implementation! We can go your route and not have anything working in a year or two, or we can go my route which limits some options but will yield a result far quicker.

I know I can get Eternity-style portals working - because a huge part of that work is already done - when I refactored the actor coordinate access. What I need here to complete it is
- P_TryMove, P_RadiusAttack and P_RecursiveSound
- a portal blockmap for quick detection
- a rework of AActor's Vec2* and Vec3* and Distance* methods to take portals into account (which is a lot easier when I have fixed offsets and no angle changes)

So obviously I try to do that first. For arbitrary portals that do not want to obey any positioning rules you still have the basic functionality of actors being able to pass through.
User avatar
NeuralStunner
 
 
Posts: 12325
Joined: Tue Jul 21, 2009 12:04 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support
Location: capital N, capital S, no space
Contact:

Re: Wall portals

Post by NeuralStunner »

hfc2x wrote:Lol, I had already made an article for the special: [wiki]Line_SetPortal[/wiki].
And this is why the wiki uses capitalization standards.

For what it's worth, I wouldn't have an issue with a more limited feature set (E.G no polyobject portals) if it means they work better (E.G. faster).

Random question: Is portal recursion (or more specifically, portals viewed through other portals) going to be its own CVar? Also, what happens at the recursion limit?
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: Wall portals

Post by Gez »

I'd say any portal beyond the recursion limit should simply be filled with the fog color.
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: Wall portals

Post by Tormentor667 »

Sorry for the impatience but when can this be considered to be added to the latest GZDoom svn?
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: Wall portals

Post by Graf Zahl »

When it works.
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: Wall portals

Post by Graf Zahl »

Gez wrote:I'd say any portal beyond the recursion limit should simply be filled with the fog color.

GZDoom fills with black. But for the software renderer which applies fog differently, fog color would be better.

NeuralStunner wrote:For what it's worth, I wouldn't have an issue with a more limited feature set (E.G no polyobject portals) if it means they work better (E.G. faster).
That's precisely the point why I am discussing this stuff here. While I can understand ZZYXZ, people need to understand that having the ultimately flexible feature is not always the best idea. The more flexible something becomes, the more it limits other, possibly far more useful and important things.
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”