Warpzone portals

[MirceaKitsune]

Thanks to Youtube recommendations I've been watching people play a lot of weird Doom mods, with stuff like myhouse.wad sparking my suggestion. It showcased what strange and amazing things you can do using warp zones. Many old engines supported them in some form, but sadly idTech 4 never did nor does our fork of it... so far, I suggest changing that.

What are warp zones: Those who played games like Unreal Tournament may remember some maps containing doors that lead to geometrically impossible locations, the classic title Portal is a more popular example except our implementation refers exclusively to static portals. The player may seamlessly traverse a short straight tunnel, but upon emerging on the other side they discover the exit leads behind the entrance to that tunnel. This allowed some neat tricks and layouts that aren't doable with standard euclidean geometry.

Why TDM can use this: Though we aren't a scifi FPS, many FM's contain magic and spooky maps which is a theme I like playing with myself, this would allow esoteric maps where the layout messes with the player in unexpected ways. Imagine a small shed you can walk around with a door leading to a giant hallway that can't possibly fit in that building, or an endless stairway you keep trying to climb until you realize it never ends and have to turn back to progress, or a pillar you have to go around in a particular direction to find yourself popping into another world. Even for non-magic FM's this can be used to change the environment, triggering portals to make doors lead to different versions of an area where the map has changed; Take an objective where you must set a building on fire from outside... you can enter the building before completing it and everything inside is normal, but after completion the door and windows lead to a charred version of the interior where the walls are a different texture and the furniture just a pile of wood on fire.

Implementation concept: The best approach by far is via visportals, what we want is a way to seamlessly connect two portal surfaces. Connected portals may have different rotations but must have the same shape and size, dmap should check this and throw an error if different sizes are detected. The most straightforward setup would be an argument to the func_portal entity, allowing it to target another func_portal so the two are seamlessly connected. There are two components to implement: Entity movement should be the easiest as it involves teleporting and rotating any entity that crosses through the warp zone... the visual aspect is trickier as the portal must hide the contents behind it and make you see through the other portal instead based on the angle you're looking from, this may not be that different from how realtime mirrors or the skybox use special render passes so hopefully the same system can be expanded.

Limitations: One issue will be spatial audio which can't easily be fixed with this approach, mappers should avoid placing noises near warp portals as you'll hear them change as you cross the surface. Same with lights which won't be able to shine through, don't light them or do so symmetrically to avoid a cutoff. Infinite hallways are impossible and the amount of warpzones you can see through warpzones must be limited to 1 or a low number of passes by default, mappers should position portals so that you can't see one through the other in an infinite loop.

[OrbWeaver]

These portals sound a lot like the ones in (the original) PREY, which I believe was an id Tech 4 engine.

[HMart]

5 hours ago, OrbWeaver said:

These portals sound a lot like the ones in (the original) PREY, which I believe was an id Tech 4 engine.

Indeed and yes Prey 2006 is literally Doom 3 engine with only a few modifications, TDM engine is way more removed from original idTech 4 than Prey engine was. 

Also I think this can be replicated in idTech 4 relatively easy (in c++ obviously): 

https://www.froyok.fr/blog/2019-03-creating-seamless-portals-in-unreal-engine-4/

Edited July 29 by HMart

[nbohr1more]

35 minutes ago, HMart said:

Indeed and yes Prey 2006 is literally Doom 3 engine with only a few modifications, TDM engine is way more removed from original idTech 4 than Prey engine was. 

Also I think this can be replicated in idTech 4 relatively easy (in c++ obviously): 

https://www.froyok.fr/blog/2019-03-creating-seamless-portals-in-unreal-engine-4/

If you post a patch we will merge it

[HMart]

2 hours ago, nbohr1more said:

If you post a patch we will merge it

I certainly expected and deserve that reply, but I just don't have the time and to tell the truth, I don't think I'm qualified to do it.

[Daft Mugi]

I looked into implementing Prey (2006) style portals last year. The expertise to implement portals doesn't overlap with mine, so I decided to drop the effort.

For those who want to give it a go, here are two idtech4 implementations that might be helpful.

• https://github.com/stephenap07/SP-RBDOOM-3-BFG/blob/master/neo/d3xp/GamePortal.cpp
• https://github.com/jmarshall23/PreyDoom/blob/master/code/Prey/game_portal.cpp
  • Warning: not GPL; uses non-free code (as far as I can tell).

Sending objects through a portal would be tricky as well as dealing with AI behavior.

Regarding constraints in Prey, I noticed that portals come in two types: (1) short, box portals that touch the ground; the player must crouch, and (2) tall, oval portals that don't touch the ground. In both cases, I'm not sure if objects can pass through, but weapon projectiles can pass through.

Prey example:

Quake 4 mod example:

[MirceaKitsune]

Happy to see many encouraging responses and examples on this. Didn't realize Prey used idTech 4 or that any game who did managed this including Quake 4. But I presume it was never part of the engine originally and they added it in their own game code, to my knowledge neither Prey nor Quake open-sources their own game code for us to copy it from... still we know it's easily doable and was even implemented twice!

Physical objects shouldn't be the tricky part: We should only need to teleport them and rotate their rotation and velocity relative to the orientation difference between portal faces. There's only one circumstance I see as problematic: What happens if the player is carrying an object and pushing it through the portal, like picking up a crate and dropping it through the warp zone? The object needs to teleport through while still being held, movement in the player's position and view rotation needs to be accurately translated at the other end.

AI likely won't be able to patrol through, at least not through conventional path_corner chains since they can't link through a portal, it would require a new path node like for elevators. It may be possible with a special node placed placed at each portal... in fact we already have a teleport path node, that might already work to have an AI pass through seamlessly.

[nbohr1more]

3 hours ago, HMart said:

I certainly expected and deserve that reply, but I just don't have the time and to tell the truth, I don't think I'm qualified to do it.

No worries. I figured you'd be a good candidate.

I think @7318 made our HL2 style portal skies, I keep forgetting if that was your old alt \ nick.

( Don't recall both of you in the same thread ? )

[HMart]

16 hours ago, nbohr1more said:

No worries. I figured you'd be a good candidate.

I think @7318 made our HL2 style portal skies, I keep forgetting if that was your old alt \ nick.

( Don't recall both of you in the same thread ? )

Thanks, but no I didn't wrote that sky portal stuff and that was never my nick, someone else deserves the praise for that. 

And about participating on a thread about the sky portal stuff, I don't recall that but perhaps I did but I doubt it was to say how to code that feature in. 

[datiswous]

Cool this idea comes up (again). I had some (complicated) ideas for implemented something like this, but found it too much work.

My (conceptual) idea was to look through a "portal" but what you look at is either what is seen in a different room (via a texture connected to a camera), or an x-ray screen, which make the area behind the "portal" look completely different (even walls can be hidden by making them func-static and apply a skin to them). When you move into the portal you get teleported to another room. Off course this has many limitations that you may or may not be able to work around via scripting.

On 7/28/2024 at 11:39 PM, MirceaKitsune said:

Even for non-magic FM's this can be used to change the environment, triggering portals to make doors lead to different versions of an area where the map has changed

This has already been done in (for example) A house of locked secrets.

[MirceaKitsune]

4 hours ago, datiswous said:

This has already been done in (for example) A house of locked secrets.

May I ask how? The only way I can imagine is a tricky setup using elevators (multistate mover) which I already went with for creating a simpler illusion. Anything else would require duplicating the whole area and teleporting the player relatively, which isn't seamless and doesn't allow for the complexity I'm hoping this would make possible.

My imagined setup involves being able to trigger such portals, so each can act like a normal visportal if not linked and a warp zone once connected. This would make possible all the amazing things like activating magic gateways, or changing the interior of a room so it leads to a heavily different version, or hallways that change as you navigate the maze.

[datiswous]

4 hours ago, MirceaKitsune said:

Anything else would require duplicating the whole area and teleporting the player relatively,

That's how it works in that mission.

[datiswous]

4 hours ago, MirceaKitsune said:

My imagined setup involves being able to trigger such portals, so each can act like a normal visportal if not linked and a warp zone once connected.

I don't understand your description, sorry.

[MirceaKitsune]

33 minutes ago, datiswous said:

That's how it works in that mission.

Yes, it's a good approach when you can get away with it, exactly what I'm doing on some of those stranger FM's I've been working on. This covers some use cases but doesn't create the illusion of having multiple things in the same physical space or seamlessly traveling between impossible points.

Another simple solution to making rooms that change is by using the building modules: Turn some wall models into doors, set them to not be frobable and have instant speed, and configure the door so that when open you don't see it hidden inside the ceiling but when closed it appears like a normal wall, allow the player to trigger it from a location where they can't see it changing.

28 minutes ago, datiswous said:

I don't understand your description, sorry.

So let's say the outdoor area contains a small shed the size of an outhouse, the player is given an objective to complete some sort of ritual. The shed has a standard door that opens and closes its visportal as usual. Before completing the objective, the player can walk into this shed like in any structure and maybe pick a necessary item for it. Once the objective is complete, opening the shed door from the outside now reveals a door leading to an impossibly large hallway that doesn't fit inside that structure.

That's what I meant with making warpzones possible to trigger: The portals are of course static and compiled by dmap, but could be triggered to link to different portals and establish new warp zones or turn it off entirely. The particular effect in my example can't be achieved with any other tricks, maybe by using sky portals to cover its back area but then you can't walk behind the shed outside as the invisible caulk covering the tunnel would collide.

Edited August 1 by MirceaKitsune

[datiswous]

Actually I think I did understand what you try to create, just not how to do that with visportals / func-portals. It's also that the one thing that I haven't done much building in DR is visportals, because I haven't really built anything apart from some room tests.

[MirceaKitsune]

5 hours ago, datiswous said:

Actually I think I did understand what you try to create, just not how to do that with visportals / func-portals. It's also that the one thing that I haven't done much building in DR is visportals, because I haven't really built anything apart from some room tests.

Visportals are one of the things you definitely want to get a hang of, as they're the #1 way of improving performance with the engine still being quite performance intensive. You want them covering any entrance of brushes they can cover to divide them into rooms, in such a way that they hide as much as possible from as many camera positions.

Every door and window has a visportal, which is closed when the door itself is closed given it's not a transparent door like grate or glass. Hence why I think they're the best candidate for warp zones: My suggestion would allow stitching distant rooms and corridors, the entrances of which are already defined by visportals in standard mapping. When a visportal is turned into a warpzone it also won't render what's normally behind it but render through the connected visportal instead, closing the room you normally see through it and recovering performance.

[datiswous]

Is this something that can be done without core modification?

[MirceaKitsune]

5 hours ago, datiswous said:

Is this something that can be done without core modification?

It would definitely require engine changes. I think the basic building blocks should be there: We have custom render passes for stuff like the skybox or dynamic mirrors, the rest should be entity teleportation. But it would definitely take one of the devs with experience in the engine and renderer to decide if it's worth their time to look into this.

[datiswous]

On 7/29/2024 at 8:09 PM, Daft Mugi said:

Quake 4 mod example:

I was looking at the video again and noticed that the room on the other side of the "portal" has the same size. So maybe this is still in the same room?

[peter_spy]

In case you want to know how it was implemented back in the old days:

I'm not sure if using it this way makes any sense in a mission.

You can have a really cool portal players can cross, without warpzones – see what Kingsal did in Volta 2.

[MirceaKitsune]

Thanks: I used to play with Unreal Editor ages ago, brings back memories to see all that. I did remember that our visportal and location_info system is very similar to early UT's in how we define and separate rooms.

As far as portals go, UT seems to be doing it via location info. Doing it per portal seems ideal, especially with func_portal already being there and easy to use for this purpose: I'd imagine that way you can still have a normal room, but only a particular door or window leading to an altered version. Also easier for mappers to understand, just link two func_portal entities together and that's it... rooms with multiple portals that don't match would have to throw errors otherwise.

[nbohr1more]

After some consideration, I think we already have all the needed ingredients.

1) Create a trigger patch which calls a teleport script

2) Create a security camera gui ( non-solid patch )

3) Use a script to move the security camera entity relative to the player's eye location and the distance to the destination "portal"

The only tricky part is calculating the surface normal of the destination portal so the camera always uses the correct offset

[datiswous]

6 hours ago, nbohr1more said:

After some consideration, I think we already have all the needed ingredients.

1) Create a trigger patch which calls a teleport script

2) Create a security camera gui ( non-solid patch )

3) Use a script to move the security camera entity relative to the player's eye location and the distance to the destination "portal"

The only tricky part is calculating the surface normal of the destination portal so the camera always uses the correct offset

Does this also work with objects and ai?

• So can ai see you from the other side of the portal?
• Can you pick up a chair and throw it through the portal and it ends up on the other side? Or shoot a fire arrow through the portal and see it explode on the other side?

[MirceaKitsune]

7 hours ago, nbohr1more said:

After some consideration, I think we already have all the needed ingredients.

1) Create a trigger patch which calls a teleport script

2) Create a security camera gui ( non-solid patch )

3) Use a script to move the security camera entity relative to the player's eye location and the distance to the destination "portal"

The only tricky part is calculating the surface normal of the destination portal so the camera always uses the correct offset

For the basics I think we do. The main difference between portals and cameras is the camera renders from a fixed angle, a warpzone is see-through and depends on the camera position... the skybox might thus be a better candidate to base them on, except not rendered in 360* but acting as a distant visportal.

Other than that the details may get complicated. Datiswous just pointed out yet another one: AI being able to see and recognize the player through such portals is yet another thing that would need to be implemented manually, the view cone would need to travel through the warp zone too. I think rendering and basic player / entity travel would be most important to get first, then all those other TODO's can slowly be done over time, with mappers informed of the limitations in effect at that time.

Edited August 7 by MirceaKitsune

[datiswous]

I had an other idea around faking portals:

Spoiler

You have a "portal". Everything you see behind it is still there, but there are alternative skins applied to possibly everything, so you can even hide walls and add or remove stuff seen through the portal (an x-ray screen is placed there so you see everything different). The portal itself is a small tunnel with 2 triggers. On the second trigger it changes all the skins for the area. So first you look through and only see it changed through an x-ray screen, after you moved through it the skins are changed. It needs 2 triggers so that the skins will not change when moving in and then back out.

This does mean everything is rendered, because all the things which you want to apply skins to need to be func-static or other entities.

This also has limitations that you have to fix in complicated ways.. (everything that is thrown through the portal has to be hidden when walked around the portal)

Making a portal in the middle of a room that you can walk around is what I have in mind, because that's the original Prey-like portal, which is super cool, but it does make it more difficult or too limiting.

A simpler way is having 2 rooms with a central door that is supposed to be the portal. On the far sides of the 2 room, there are 2 doors, so you can walk around, when you walk through these side doors the skins in the second room are changed and maybe ai and moveables are teleported away (and back when you walk back). This creates the illusion of entering a different room going through the center "portal" door.

 

Edited August 8 by datiswous