Following what we saw above, "seamless" teleportation occurs when the camera is close enough to the portal. A problem that 3rd person controllers have is that the camera is behind the player, therefore, when the camera reaches the plane, the character has already passed through the portal. That is why this asset (since version 1.4) incorporates a mechanic that makes the camera, as it approaches the portal, move closer to the player, so that when teleporting, the camera behaves as a 1st person controller, to then slowly return to its normal position in 3rd person. This is all achieved automatically when "Camera Type" is set to "Auto Detect" or "Third Person." "Near Offset Position" is the position relative to the player at the time of passing. If you see a flicker when telporting, it's possible that the "z" value needs to be a little lesser (for example -0.5). If the camera goes through the player, you should raise the "y" value. Additionally, you can change the "field of view" of the camera when crossing, generating a zoom effect. To do this, activate the "Adjust Field of View" option and set a number lower than the normal "Field of view" of your camera. There are two ways ("Transition Area Detection Mode") you can calculate how near teleporting the player is. The simplest way is setting "By Radial Distance" and giving it a radius value. Another method is "By Custom Box", where you set the dimensions. Note that when you change modes and change radius or box values, you will see a gizmo representing the transition area in the yellow, so you can see the values while you're changing them. A small area or radius will cause a more abrupt change. A large area or radius will cause a more gradual change. Finally, by enabling the "Let Add Script To Player Camera" check, you give permission for a script to be added to the camera to make these position and FOV changes possible. You can also add it yourself, it is the "Third Person Offset And FOV" script, and it goes on the camera object. Finally, keep in mind that if you use a controller other than the one that comes with the asset, the position of the camera may be controlled by another script, which will cause a fight between two scripts for positioning the camera.

There is a problem when you see a portal through another portal. If that other portal is from the same set (portal A and B from the same group are facing each other), then the solution is to use recursive rendering, not this option. This option is for when the portals are from different groups. For example: Let's see the hierarchy to understand the problem: In the example, group AB lets us see room B from room A. But in room B we have the group BC. We should be able to see world C, but we can't. So, we don't have to do anything in the configuration of group BC, but in group AB. We have to go to group AB and declare that through portal A we want to see the inside of portal B of BC: Then the result will be this: It is worth mentioning that this functionality generates a small lag, like a woobly effect, because the portal will always be 1 frame late. The lower the FPS, the more noticeable this effect will be (1 frame in 30 FPS is worse than 1 frame in 500 FPS). And if you have several nested portals one inside another, the woobly effects is more apparent (inner rendering will be 2 or more frames late). Also, another limitation is that you cannot directly watch a portal that is being show as nested by other portal (a portal is either nested or not). So, my tip is: Whenever you can, try to face portal away from the others (try to avoid nester portals).

If you've come here, you probably know the video game Portal 1 or 2. This feature allows you to do something similar: to dynamically reposition portals on surfaces like walls and ceilings, although it needs to be said that this is not a well polished system, and there are some considerations to take into account regarding the player and the world. Also, keep in mind that, in version 2.0, portals in floors won't work. They will be placed, but the player is not going to be teleported, because the camera is higher than the body, and the body collisions will prevent the camera to reaching the actual plane of the portal. This will be addressed in future versions, but so far, be noticed that this is a limitation. There are two problems to take into account with this type of portals: First problem: The walls have colliders, and these can prevent the player from passing. That is, the character has its own collisions, its own "thickness", and that thickness can cause the character to collide with the wall before the camera is close enough to the shot to teleport: For this, I recommend 2 options: Option 1 (ideal for invisible characters): Make the character collisions very thin, for example lowering the character controller's radius to 0.02 or less, and a "skin width" of 0.1. This way, it is not necessary to deal with wall collisions, because the character will have room to teleport, the camera will reach the plane before the player touches the wall behind. The downside to this is that you'll have to modify your character, and if the character is visible and thick, parts of its body may clip through other walls. (In the image, now the camera is ready to teleport the character and he has not yet collided with the wall) Option 2: Another option, more world-friendly is to leave the character as it is and use the "Colliders Management" options, which will disable the colliders near the portal while the character is nearby, and restore them when it has teleported or moved away. 1) activate the "Disable Colliders Near Portals" option 2) in "Filter Type", choose either "Allow Everything Except Forbidden" (as in the example, where every colliders can be disabled except the ground's) or "Allow Only Explicit" (only those that you explicitly declare in "Allowed Colliders" will be managed). Second problem: The wall rendering obstructs the view of the portal. This happens because, being right under the portal, the portal camera has to be placed too close to the wall. For this, I recommend 2 options: Option 1 (ideal but requires adapting the environment): Make the walls only visible on the player's side, and not on the side from which the camera wants to film. To do this, walls that are cubes must be "planes" and walls that are 3D models must not have faces on the other side. In HDRP, the "both sides" option of the renderer must be disabled. The image shows how the wall (now a plane) is visible only from the player's side and doesn't obstruct the camera rendering. Option 2 (a little messier but you can keep your cubes or models alone): Another option is to use the "Hide Surfaces Before Rendering" option, which temporarily hides the wall so they don't obstruct the portal camera and then restore it. Keep in mind that the lights will pass through that wall, so if you're going to do it, it is recommended to place a "shadow caster" (a false wall in the same place) with the "Shadows Only" option in the "Cast Shadows" variable of the Renderer. Note: In the example images, the surface portals feature is combined with recursive rendering.

From version 2.0, a portal can lead to another "dimension", literally, as in an Escher painting, or as in the video games "Fragments of Euclid" or "Manifold Garden", and walk along the walls or through the ceiling, as seamlessly as in same-gravity portals. To use this feature, you must: 1) Activate the "Apply Multi Gravity" option: 2) Add the "Custom Gravity" script to the player: If you use one of the players that comes with the asset, make sure "Is Multi Gravity" is set to Yes or AutoDetect, and that's it. Now the player will have a special gravity, it will jump and fall according to its relative "up" and "down" and not the general "up" and "down" of the world. But, if you use a player other than the ones that come with the asset, you will have to prevent it from handling gravity on its own. Some tips to achieve it: - If your character have a rigidbody, remove the "use gravity" option - If it doesn't, check in the inspector if you see any exposed value for the fall speed and jump force, you could set those values to 0. - If this doesn't work, you will have to go into your player's code and replace the fall speed with 0 and the jump force with 0 as well.

Version 2.0 brings this long-awaited feature: being able to see the inside of a portal from another of the same group. This is: when both portals of a set are facing each other. If both portals are different groups, you're looking for "nested portals". It is worth mentioning that this function can have an impact on performance, especially in URP and HDRP, since the portal camera is rendering several times per frame. Please the some tips below to reduce the amount of recursions. If you want this feature, activate the option and set how many times the portal is viewed within itself. For your own good, this number is limited to 20. If you need more, go inside PortalSetup.cs and remove this cap. Example without recursion (only rendered 1 time): Example with 3 recursions: A tip to avoid a large number of recursions is to rotate one of the portals a little on the Y axis, so that the recursion is not infinite. For example, in the first image, one portal is rotated only 3 degrees from the other, and that alone limits the recursion to 7. Also, i'm working on a way to only go as far as needed. At this point (version 2.0) if you choose 7 recursions, it will renderer none (if the portal is being seen) or full 7, nothing in between. This will be addressed in future versions. You can also rotate in other axes to obtain psychedelic effects:

a. Implementation

Some portal prefabs have switches or buttons to turn portal on or off. If you don't want to use these switches, you can simply disable the "simple lever" gameObjects: ...or, in the case of portals with a sphere, deactivate the "Interaction trigger" object: If you want to use them with the player that comes with the asset, you don't need to do anything else. If you want to use them with another player, you can simply attach the "Portal Switch Interaction" script to the player's camera: This script requires some canvas element to show or hide. You can borrow the "interaction message" object from the demo scene (child of the Canvas) and paste it inside your own canvas. If you rename that object, you must reference it in the player's camera. If you leave it the same name, the script will find it automatically.

b. Initial state

You can set the initial state of the portal:

c. Timer

If you want the switch to slowly return and turn off, you can enable the "Is Timed" option and set the time in seconds.

In order to function, each group of portals requires a complex initialization. This can be done when entering Play mode (Runtime mode) or can be prepared beforehand (Deployed mode). The advantages of "deployed" mode are: 1. the game starts faster 2. it allows you to alter the initial configuration so it remains as you want when starting the game, no surprises. To change modes you can use the buttons below the whole script:

Since version 2.0, raycasts can also go trough portals. This is ideal for shooting games. Achieving this is very easy. You just need to replace "Physics" with "PortalRaycast", and remember to include above everything: using DamianGonzalez.Portals; Example with minimum parameters: All the way until full explicit parameters: In the latter case, a very useful variable is added which is a listing of all the individual portions of the ray with its start and end positions. A ray crossing 1 portal has 2 subrays (one from the source to the portal, one from the other portal to the destination). You can see the ShootBullets.cs script (inside Demo/Scripts) to see a real example of how it works, and how individual lines are drawn. Again, if you use any of the players that come with the asset, you don't need to do anything. With left click you shoot and the rays can teleport.