You are seeing documentation of an old version (1.3) - Switch to newest version (1.4 and 2.0)

Fluid Portals & Non-Eucledian Tunnels - v1.3


First of all, let's try to solve your problem in this page. If the solutions there don't work, contact me (if possible with pictures of the problem) and I'll help you via e-mail or whatsapp. And if it's more delicate, I can solve it in your PC using teamviewer / zoom / anydesk or similar.

What's new?

For details of changes, see the change log, but to sum up, the latest version allows objects below portals being visible from both portals (clones), reduces the ugly effect crossing sideways, has its own first person controller, and improves overall performance.

So, first, what "fluid portal" means?

"Fluid portals" means you can enter a portal (from room A to room B) without noticing when you leave one room and enter the other, since you can see the other room at every moment, as if it was really there across the arch. This portals only teleport from one side. From the other side they look like normal archs.

What does this package contains?

This package contains a demo scene and 4 prefabs: - portals back and forth: This is a set of 2 portals. - long tunnel effect one end: This is a tunnel that from outside looks short but from inside is very long. The interior of the tunnel is actually in another location, but in one of the entrances of the short "real" tunnel there is a portal to the long "fake" one. - long tunnel effect both ends: Same as above, but with both ends of the tunnel with portals. - a first person controller


From version 1.3, objects can stand below portals ("in between"), and cross them seamlessly. You can choose whether to use this feature or not.


From version 1.1, when two portals has different rotations (for example, one facing north and other facing west, or one in the wall and the other in the roof), they work very smoothly. When something teleports, it also "rotates" its velocity, and changes in position are also calclulated considering the rotations.


As you can see in the video or in the demo build, when crossing portals, forewards or backwards, there is absolutely no flickering or jumps. Teleportation are really smooth and unnoticeable. Also, the effect of crossing the portal sideways, looking at the edge at the portal (which always was the Achilles heel of this asset) has been reduced to a minimum, it's almost unnoticeable.


In versions 1.0 and 1.1, this asset didn't include a first person controller. Since version 1.2, a simple first person controller is included, so the Demo Scene is completely playable as it is, no 3rd party controller is needed.


A fully-playable demo scene is provided. Demo Scene contains demo text, so it uses Text Mesh Pro. Although it's not necessary, it helps demonstrating the functionality of the asset. (The asset per se doesn't require it, only the Demo Scene.) If you run the demo scene and don't have Text Mesh Pro installed, Unity will offer you to do it automatically ("Import TMP Essentials"). If it doesn't happen, you may need to manually go to Package Manager and install Text Mesh Pro.


As you can see here, in this example of implementation, this package is almost ready to drag and drop to your scene. You just have to import the package and drag the prefabs to your scene. Just make sure your player has the "Player" tag. If your player has other Tag, type it in the "Player tag" variable in the inspector on the portal's (or tunnel's) main gameobject. Also, if your player has child objects (like a gun, or hands), give those child a special tag, like "DontCrossPortals" and tell the portal, using the filters in the main gameobject.


Since version 1.2, a simple first person controller is included in the Demo folder. It's simple but "does the trick", it's fully compatible with this asset, and may work as a starting point in case you want to expand it or implement other controller. If you have problems with your character controller (not teleporting, for example), check this troubleshooting page. General tips: - Your Main camera (the camera inside your controller) must be tagged as MainCamera - Your player must be tagged as Player For other problems check the troubleshooting page.


Recursive portals (like two parallel portals that create an infinite loop, similar to mirrors facing each other where you see infinite mirrors) is almost done, it's due to next version 2.0. Just keep in mind that current version 1.3 and previous won't give you that. They only render once, so you shouldn't place portals in a way where one portal faces the other.


Yes! If you're having some trouble, check the troubleshooting page. However, keep in mind that URP and (specially) HDRP can apply camera effects based on where you "really" are and the things you are "really" seeing. So, since you can be seeing a room trough a portal, without actually being there, the transition may not be 100% fluid. So, when you teleport, you could experience a little sudden change in the post-processing the moment you actually enter the room you were seeing trough a portal.


Not currently. I'll make it compatible soon, but so far it's not.


Let's say you have a set of portals, one portal (A) in room A, and other portal (B) in room B. Basically, it works like this: portals have a plane (which, unlike cubes or shperes, only are rendered in 1 face), and also have a camera. But portal A's plane renders the content of portal B's camera, and viceversa, creating the ilussion that room B is really across portal A. The necessary objects for this (the camera, the render texture and material) aren't there when the game is stopped, they are automatically created and set up when you start the game. All that happens in "portalSetup" script. And in every frame, those cameras are positioned and rotated. That happens in "portalCamMovement" script. When an object, included the player, touches the plane, it's teleported to the other portal, calculating the new position and rotation. That happens in "teleport" script. If you don't want other object to cross, you can uncheck the "otherObjectsCanCross" variable on the portal object in the inspector. But how to know when the object to teleport is passing through the "good" side of the portal (through the visible face of the plane) and not the other? For that, I put some triggers called "directionChecker" behind the "good" side.


Events are fired when important things happen, and you can suscribe and listen to those events. These events are not for communicate between the scripts (not for internal use), but solely for communicate with you. This way you can add functionality without the need of touching the original code. The script called "portalEventsListenerExample" contains examples on how to do so. These are the events fired: a) when something teleports b) when portal setup is ready c) when game window resizes
If you need my assistance, feel free to contact me via mail or whatsapp Damián González Back to assets catalog Curious of the game I'm making? Check it out :)