Are perfect portals possible? How?

By perfect portals, I mean a portal that the player is incapable of knowing is even there.

All the while it has objects with particle effects and lights passing through them.

Like I’m saying, take a game like Quake 3 and give it impossibly shaped maps and no one can tell where the portal is.

 

Yes

 

how?

 

In 3D with FPS-style movement and thus very free camera it will be tricky. I assume you are thinking of something like a Tardis effect? Where you step through some passage and the environment seems impossible.
One idea that comes to mind: render what the player would see through the portal onto a render texture and only display the right part of that render texture on that portal. When the player is close enough, swap to the actual rendering but maintain whatever object is surrounding the portal and is in the viewfield so that the now missing outer world is not shown.

 

Yes. Been done in Prey.

Basically, you render the scene twice, and use same resolution for the portal camera as for the main game camera.

When I tinkered with VrMirror, resulting class could also work as a portal.
https://forum.unity.com/threads/vr-mirror-test-project.1219659/

If you disable tint and resolution is high enough, you don't see the transition.

Also see Non-Euclidian Room from Ludumdare.

Spoiler

Similar trick was present in McGee's Alice, where there was a looping corridor in one room, but in alice, particls gave it away.

 

See, all these examples are not showing particle effects or lights going through them.

It’s easy enough to do portals that you walk through if it’s just you.

I suppose you could to moving rooms for an effect, but that has special limitations.

 

As said before render textures with multiple cameras work.
I personally prefer making portals with a single camera with URP stencil portals

 

No, rendering textures will not work with lights and particles.

 

They will, in a sense that they'll clip particles correctly.

Basically, you COULD do that, but it is a royal pain in the arse and not fun. It is also similar to trying to drag a r igidbody through portal.

Basically in a scenario where a portal is inovlved and an object crosses its boundary, you'd need to spawn a duplicate object on the other side of the portal, that will handle its effect and keep affected parts in sync.

For particle systems, you'd need to detect situation when particle crosses the boundary, and move each particle to the other side, while keeping its parameters synced.

Same deal will be with rigidbodies.

For lights you do the same thing, you make a duplicate light with the same parameters, EXCEPT it has custom shadowing formula to handle handle portal boundaries. Basically you'd need to reuse shadowmap from the light beyond the portal to lit up the scene in front of the portal, except on top of shadowmap you'd need to apply portal boundary clipping to the light source. This is basic clipplanes + cookie, if the portal has complex form.

In BiRP this step would require you to replace entire standard shader with your own function for all affected objects.

But it can still be done. It is not really worth it, though.

 

I mean.. it does make for a cool game feature

But yeah, it probably is smartest to design the map in such a way to minimize edgecases and then do not really care about the <20% of players who will take all measures to break it At the end they even have a personal achievement and thus still enjoy the game.

 

Ray tracing? (Although I guess this still doesn’t cover particles, but you could fake that)

 

By the time I get around ever working on the project, we will probably be up to PS8’s and RTX will be common, lol.

 

Prey advertised that at release date (2006) and they used it maybe 10 times total in the entire game.

It is one thing to think in your head how cool that would be and another to actually implement it and use it in gameplay.

Well, we have portal and portal 2, but I think even Portal does not support those features fully.

 

Portal is probably not the right example as that is the opposite of "player is incapable of knowing is even there". There are several tutorials and demo projects on YT and the asset store with that kind of portals.

Think I would play a game with fairly good, invisible portals that do lead to "non euclidian" worlds. Superliminal was an amazing one.

They had pretty much that and far more.

EDIT: WAIT WHAT! Superliminal IS made in Unity!
Well, that certainly answers the question whether all this is possible, lol.

Looking at it again, the portals are all in door frames. Fairly sure they used the renderingtexture method I described earlier. Admittedly that is a game without many moving objects (aside of ones directly made to move by the player) and nearly no particles though.

 

Or physics, because objects aren't being simulated as being in a non-euclidean space, a euclidean space is just being painted on to kind-of look like it.

I believe that games with custom engines deal with this via scene graph support. The scene graphs actually support loops, links, etc. so that as the graph is traversed and calculations performed an object can have results (i.e. "be in") multiple places at once.

To do this in Unity you would need to maintain your own scene graph, and then maintain a derived copy of traversal results in the Unity scene graph, duplicating objects with multiple appearances. I think. Or get source and go nuts.

 

In what position would an object need to be to require all this?
Even when something were half in the portal and half outside, it is should still suffice to just render it with the main camera as well as the render-texture camera, just making sure to cut out accordingly.

An asset where you can at least shoot bullets through the portal by the way: https://assetstore.unity.com/packages/templates/systems/euclidean-portal-system-225954

 

But also note that there's a difference betwen players not noticing, and developers not noticing.

Depending on your needs it's entirely possible that RenderTextures and careful design (with some deliberate constraints) would get the job done well enough to satisfy players.

I suspect that Control's Foundation expansion has examples of this, and even simpler. Pretty sure that their impossible-looking spaces are just fog and stencil buffers, and they worked perfectly even though, as a developer, I could immediately see that. Most players would have no idea.

 

Large physics objects which would collide with themselves, as one instance. Audio sources which can now be heard from multiple directions. Again, this isn't just a rendering problem.

 

The portals the thread starter asked for are meant to be seamless, right? Then there shouldn't be any immediate change to the physics environment right at the portal or the player would realize that something is really off, even if it technically worked perfectly.
For the same reason there also must be no portals that face each other or that would result in you looking through the portal and seeing yourself etc.

In that case just keep the physical part of the object only existing on one side until it has completely gone through and switch then. Or just use layers to not have objects collide with their counterparts.
Same with sounds, I'd say.

 

Of course it is. Trying to make something like that in Unreal engine will likely result in you tearing all your hair out in frustration.

In general highly experimental stuff is more likely to happen in unity engine.

You're definitely overthinking it.

Basically what happens is that when the object crosses portal boundary, you spawn its clone on the other end, then link them with a constraint so forces transfer.

You can override FixedUpdate and implement your custom constraint to control the object and its temporary clone. Portal 2 did that, and it used source engine.

 

The OP asked for them to be "perfect", and raised examples including nearby lights and particles, which may have to work through the portal. That won't happen with an RT and some joints.

Portal's simplified approach worked because of significant design constraints, and I already advocated (with an example) for that approach over making it "perfect".

For what it's worth, "Portal rendering" (not to be misunderstood because of the name - it's based around a culling technique) is a rendering technique for enclosed spaces which long predates Portal, the game, and popularity of that particular style of portal. I believe that the old Prey game used variations of this for its non-euclidean areas. What I'm talking about is essentially a variation of this where portals can be moved.

As it's not a generic use case I suspect you'd need to customise more than your scene graph and renderer, though. I am not suggesting it would be worth it.

 

Maybe @Not_Sure needs to flesh out their idea a bit more. Shall it be closer to the Portal portals, or to the door in that dropping house in Superliminal?

 

Antichamber says hi.

 

In our game we have a elevator. I made a static elevator on each floor and made sure baked lighting looks exactly the same. Then i just move the player. It's kind of a portal unknown to the player

 

i guess i don't understand.

if you look at a wall and cannot tell it is a portal, couldn't you just disable the collider on it and then player can walk through to the hidden area? If player cannot see something, why would you simulate it? Especially complicated stuff like lights.

 

sounds like build engine

 

This is really just food for thought.

But if I were to ever do something like this it would likely be a retro fps rocket arena like Quake 3, but with impossible level designs.

Like a stage where you can keep dropping down onto the enemy, or a very simple set of rooms that connect in unreal ways.

So you would need to fire through them with rockets (making smoke and lights) and of course AI would need to know how to use them.

 

Do you need the portal at all?

With some clever culling and dynamic loading, you could actually load both sides of the "impossible geometry" entirely. This way all your particle effects and physics work naturally. It would be a hell of a job mathematically, but entirely doable.

This would mean that you can't have direct line of site to the other side of the portal. But if you really wanted to, you could combine this with the render texture method other people have described and have the best of both worlds.

 

Its definitely possible, its just a question as to whether the extensive effort is worth it, which honestly is its just not and keeping a highly constrained design is likely more benifical.

I did a rough mock up of a physics integration with Portals many years back. It worked, but only because its also highly constrained, meaning its not a generalised solution, and even then is likely prone to breaking and I wouldn't be surprised if it ran into more issues later on.

The video first shows the scene and then the physics are enabled to show the results. The test is to show physics clipping ( preventing objects behind a portal being impacted by a physic object going through the portal ) and physics teleportation ( objects going through one portal affecting objects coming out of another ).

Quite surprised looking back at this that it worked for recursive portals, which explains why the same physic object in different portal views are different colors - its because each one is a independent simulation of objects within that portal space ( though I suspect i had one physic simulation running and that recorded the data and other simulations simply played back that data ).

However I never continued the project as it gets real complex, real fast. I did think of revisiting it sometime as I seem to remember Unity had implemented support for multiple independent physics simulation worlds and wondered if that might simplify things, but i suspect not. The problem is all the edge cases that can happen.