Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
printz

[PORTALS] Eternity portal clipping is ready to beta-test

Recommended Posts

EDIT: work so far (25/02/2016) has been merged to master. See https://www.doomworld.com/vb/eternity/86364-eternity-linked-portals-are-now-official/

I've just completed a large part of the Eternity linked portal clipping/collision rules, which means I've got rid of all the shaking that happened when travelling sector portals, telefrags are gone (and impossible), monsters properly use them. I also fixed the visual glitches, no more half-cacodemon or half-imps.

This means you can now make maps with linked portals. There are still a few kinks I need to fix (MBF torques, damaging or slippery floors etc.) but new versions will be released here as I progress.

The only downside is that I assumed that all linedefs are vertical rectangles in a 3D space, with well-defined heights, angles and lengths. This means that if you attempt impossible geometry, you may bump into invisible barriers caused by where solid lines or things should be. This will only happen in the vicinity of portals, so you may still get away with totally overlapped areas. But I'm considering trying impossible architecture for a later time. Even just having room-over-room is great.

ETERNITY-PORTAL DOWNLOAD LINKS*
February 20 2016: Windows, Mac: sight, aim, bullets and switch use can pass through infinite/inconsistent portals, line 385 (apply tagged sector portal to front sector) now works correctly if both floor and ceiling portal need to be copied, fixed a crash that happened when things were over inconsistent sector linked portals, some other effects work through inconsistent portals, merged stuff from trunk.

Old releases:
February 7 2016: Windows, Mac: more fixes on line portal rendering; merged core fixes.
February 2 2016: Mac, Windows: fixed a mistake in the line portal rendering; things now spawn correctly in sectors with linked portals floors and ceilings.
February 1 2016: Mac, Windows: fixed more line portal rendering bugs, using lines now works past line portals, so if doors are behind, they'll be usable.
January 31 2016: Mac, Windows: same-light line portals no longer cause HOM, fixed seg rendering bugs behind line portals, fixed a crash that always happened in maps without portals with z-clipping on.
January 29 2016: Mac, Windows: fixed some serious line portal bugs
January 26 2016: Mac, Windows: Now line portals no longer have visual glitches. It means you can now overlap areas unrealistically without seeing garbage in front of you! See the screenshot and download this demo wad to see for yourself!
January 24 2016: Mac, Windows: hopefully completely fixed the invisible wall problem. It was still happening.
January 23 2016: Windows, Mac: things no longer generate invisible barriers. NOW YOU DON'T NEED to distance your map layers far apart. Also fixed the similar bleeding of line portal box sectors. Fixed ugly mis-interpolation effects through line portals.
January 22 2016: Windows, Mac: linedefs no longer generate invisible walls in maps with overlapping geometry (portals still linked consistently though). Currently things still block across overlapping layers... [caution: by the time I uploaded the Mac version, I noticed some bugs that weren't fixed in the Windows version. When I have time, I'll update the Windows version]
January 20 2016: Mac, Windows. Hopefully fixed that portal+transferheights crash for good...
January 19 2016: Mac, Windows. Fixed line portals to work if multiple portals touch the same sector behind (on trunk it works). Fixed the crash that Mordeth reported in the other thread (also in trunk).
January 17 2016: Mac, Windows. Fixed nearly all sector effects when a portal is between a thing's centre and the floor. Hopefully fixed a serious bug that blocked monsters when up on a platform above a really detailed lower floor.
Eternity-portal January 15 2016, Mac version: fixed the passable polyobject bug; CANTLEAVEFLOORPIC monsters now move properly if with head above a portal.
Eternity-portal January 14 2016

Please post any troubles you have, here.

Here's a line portal image:


Here's an example, where the player is standing on an impassable line (not 3dmidtex) belonging to the layer below:


To know more about linked portals, read it in the wiki.

* all releases are based on the "portal-fixes-2016" branch, i.e. they're not yet part of the core.

Share this post


Link to post

Bug: polyobjects are pass-through.

To replicate: run vaprdemo.wad, get out of the train, and walk through (without activating) the door to the bridge. Then walk through (without activating) the door to the base. After saying "hi!" to the monsters, retreat back to the bridge, and you should see the imps and zombies walking through the doors to rejoin you.

All these polyobjects are properly blocking in regular Eternity builds.

Share this post


Link to post

I found a bug, though this is admittedly in a test map where I was trying to push my luck and create lots of physically-impossible connections. There's an invisible wall here, which blocks projectiles, players, and everything else: http://i.imgur.com/NInk7GA.png

I'm not sure if there are any other invisible walls there, but I didn't find any in a quick (not exhaustive) search.

It works correctly in the latest regular build on DRDteam, for whatever it's worth.

The impossible-structures map wad: http://esselfortium.net/wasd/tierplops.wad

---

Also, I hate to tease with maps that will probably never see the light of day (because even though they screenshot well, they are quite bad), but I spent some time playing around in the incomplete corpses of my unreleased Vaporware maps, summoning monsters on upper and lower levels and watching them attack from there: http://imgur.com/a/YqcVZ

Being able to seamlessly run up and down stairs on a portal boundary, and have monsters chase me down them or attack from a nearby ledge, is pretty amazing to finally see.

One thing that I noticed in the process of playing around there: Aside from the inherent issues in my old maps not having been planned well for actual functionality, monsters can be pretty stupid about portals sometimes. If I summon a cyberdemon below me and stand on a donut-shaped ledge above it, rather than trying to attack me from an angle that will allow it to actually hit me, it just tries to get as close as possible, standing under me (and thus under the ledge), rendering it completely harmless. This sort of behavior can happen in vanilla maps as well, but 3D structures allow for even more dumb-monster exploitation, and the added layout complexity due to 3D makes the use of monster-blocking lines less effective as a workaround. I'm not sure what can reasonably be done about that, and might be the domain of some sort of EDF mods with new vertically-aware A_Chase codepointers or something.

---

Anyhow. Awesome stuff, printz! Let me know if there's anything more I can do to help!

Share this post


Link to post
esselfortium said:

I found a bug, though this is admittedly in a test map where I was trying to push my luck and create lots of physically-impossible connections. There's an invisible wall here, which blocks projectiles, players, and everything else: http://i.imgur.com/NInk7GA.png

I'm not sure if there are any other invisible walls there, but I didn't find any in a quick (not exhaustive) search.

Unfortunately that seems to be the limitation I talked about in the OP, that invisible barriers appear where things or linedefs should realistically be. That wall, unless it's really a bug, may be caused by a linedef at those exact coordinates, from another layer. I'll check later if that's not the case... This doesn't happen everywhere, just near the portals in the blockmap range. I suppose that I should work to make such clipping possible, the popular demand may be high, but it's much more complex. It's just that impossible structures were likely not intended when linked portals were designed, due to how many hoops you have to jump through to avoid errors. Trying to make teleport points (places where even if looking at automap you still teleport, because of cycles in the portals) act seamlessly is even harder, and subject to varying interpretations, such as telling a monster where it should chase you if it can see you in two simultaneous directions. All this seems like the aim of a new feature branch, evolved from what we have here.

Adapting behaviour to real 3d, such as improving chasing, or explosions to be Z limited (something which Hexen already does) are separate tasks from improving portals.

Share this post


Link to post
Gez said:

Bug: polyobjects are pass-through.

To replicate: run vaprdemo.wad, get out of the train, and walk through (without activating) the door to the bridge. Then walk through (without activating) the door to the base. After saying "hi!" to the monsters, retreat back to the bridge, and you should see the imps and zombies walking through the doors to rejoin you.

All these polyobjects are properly blocking in regular Eternity builds.

Thanks for noticing, I've just uploaded a new version, now also for Mac.

Share this post


Link to post

I haven't had much time for testing, but here are my initial impressions.

The portal+242 crashing bug as described here is still present.

There's something wrong with monster's movement AI when a floor portal is at equal height as a regular sector's floor. Eg an Imp on 32 wide ledge with a neighboring floor portal at equal height of the ledge's floor. Looks like the Imp tries to move on it, only to get stuck like it would when you stick it partly inside geometry. The regular SVN build shows those Imps still moving around normally.

You did NOT break non-euclidean geometry, such as my beloved subway, provided I take some care with the bounding box behind the linked portals. It does however break the automap, showing each linked portal layer on its own instead of overlaying the relevant section on top of each other. The regular SVN build does this correctly, (provided you physically link the euclidean geometry, which is part of the trick anyway),

Share this post


Link to post
Mordeth said:

I haven't had much time for testing, but here are my initial impressions.

The portal+242 crashing bug as described here is still present.

I didn't get to that yet, maybe I should do it soon...



There's something wrong with monster's movement AI when a floor portal is at equal height as a regular sector's floor. Eg an Imp on 32 wide ledge with a neighboring floor portal at equal height of the ledge's floor. Looks like the Imp tries to move on it, only to get stuck like it would when you stick it partly inside geometry. The regular SVN build shows those Imps still moving around normally.

What exactly do you mean? Something like this?

            |
portal  imp |
.......+----+
       |
       |
       |
If so, in the trunk version, the imp would be able to move on the edge without problems. That was because it misdetected the portal z plane as a regular floor. In my branch, it gets stuck on the 32-unit ledge just like it would get stuck on such a ledge without portals, which is normal Doom behaviour.


You did NOT break non-euclidean geometry, such as my beloved subway, provided I take some care with the bounding box behind the linked portals. It does however break the automap, showing each linked portal layer on its own instead of overlaying the relevant section on top of each other. The regular SVN build does this correctly, (provided you physically link the euclidean geometry, which is part of the trick anyway),

Glad I did not break that particular case, sad that your subway depends on non-euclidean geometry; it looks like I may have to hack its support somehow. But what you're saying about the automap is really strange, because I didn't touch the automap code or the way portals are spawned on map startup.

Share this post


Link to post

The trans-portal thing and linedef collision system will have to be redone or improved. The current implementation, besides making non-euclidean levels difficult to design, also has other side effects such as lowering the "dropoffz" variable so much, that monsters standing on platforms above other floors get stuck because the floor below has detail linedefs which the monsters intersect on the XY axes.

EDIT: in case anyone believes this, it has been patched since it was posted. I didn't really restart anything, but maybe it can get even better as I understand even more of this.

Share this post


Link to post
boris said:

Creating plane portals is rather cumbersome, so I made a small plugin for GZDB:

How to use: select two or more sectors and either press the assigned hotkey or the button in the menu bar to create the portal(s).

Download: https://github.com/biwa/eternityportalhelper/releases/download/v0.1.0/EternityPortalHelper-v0.1.0.zip
Source: https://github.com/biwa/eternityportalhelper

Woah! I'm super excited to see native editor support for this stuff. Thanks for that, boris! In general it's exciting to watch all that's been going on with EE development this month :)

Share this post


Link to post

Updated with a new release where you can place line linked portals wherever you want (as long as you obey the XY consistency rules and place them correctly). I mean that you can now have Prey-like portals and overlapping corridors without seeing glitches caused by the geometry on the other side! See the original post.

Share this post


Link to post

I made a super simple portal but, even though it works, it has this HOM effect:



Also if I try to have another portal directly afterwards and essentially making the room an endless loop both portals stop working. I haven't messed much with portals so I don't know what's going on.

Share this post


Link to post

I have the same HOM effect. I've taken Essel's very old portal demo and tried to make it work by drawing areas behind the portals (so that the portal lines are no longer impassable and one-sided).

Share this post


Link to post

Unfortunately there's still an old bug where the sector behind the line portal has to be of a different light level.

You can't really make loops that easily. If you try, you will get an error. You need at least four areas to connect. But if you make an infinite corridor, you will get HOM errors.

@Gez: does the HOM disappear after you walk past the portal line? I suspect it's also related to loops. The code that made impossible line portal structures glitch-free also added a regression in loops. I'll fix that when I get back to it.

Share this post


Link to post

I made a pretty basic and ugly as sin proof of concept. It tries to resemble Duke Nukem 3D's e2l11 , and shows such a thing could be replicated in Eternity. http://s000.tinyupload.com/?file_id=04725811359329144920
I only copied over the basic structure that actually used the portals, and height variation and stuff are fairly off. If anybody with experience in BUILD is willing to help be make a more faithful recreation I would be exceptionally appreciative (I tried it myself but I can't figure out how to split the overlapping sectors into their constituent areas in the editor).
NOTE: Be careful running around the raised perimeter; you can clip out the map if not.
EDIT 2: printz fixed it. Also tweaked the map a teeny bit to avoid a potential bug to do with portal backing sectors not being the correct height.

EDIT: Here's a demonstration:

Share this post


Link to post
printz said:

Unfortunately there's still an old bug where the sector behind the line portal has to be of a different light level.

You can't really make loops that easily. If you try, you will get an error. You need at least four areas to connect. But if you make an infinite corridor, you will get HOM errors.

@Gez: does the HOM disappear after you walk past the portal line? I suspect it's also related to loops. The code that made impossible line portal structures glitch-free also added a regression in loops. I'll fix that when I get back to it.


No, but it was the light level issue. After changing these sectors the HOMs have disappeared.

Share this post


Link to post

printz, do you think the light-level issue might be easily fixable? SoM mentioned something on IRC about it a while back, with the general idea being that line-portal linedefs needed to be internally flagged as always drawn, so that they can't get passed over by the renderer in the same way that other lines without a sector-property change or midtexture do.

It's only a minor inconvenience, but it's still a nonsensical silly thing that would be nice to not have to worry about.

Share this post


Link to post

Updated; look in original post. Now line portals no longer cause HOM and fixed some major bugs.

Share this post


Link to post

Another bug, if a door is too close to a portal, you won't be able to open it from the side the portal is on.

And I just also discovered some visual glitches in the latest version with this test wad of mine. Go through the front door and you'll see one in front of you on the right and another when you turn around.

EDIT: I totally forgot to say this but the wad uses gothictx.wad, otherwise you'll run into issues.

Share this post


Link to post

Indeed there are rendering bugs and probably other stuff too. But your map also has missing textures in a few places.

Share this post


Link to post

Yeah, I noticed one after I posted it. The ones in the hallway though definitely aren't due to missing textures, and they also didn't seem to be there in the previous release.

Share this post


Link to post

Fixed some more problems with line portal rendering, as well as a physics issue (things spawning on the portal instead of the actual floor or ceiling).

Share this post


Link to post

Is there any possibility in the future that you could make it so portal loops don't take at least four portals to connect for them to work?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×