How are portals implemented in Portal?

Question

C++ / C#

How are portals implemented in Portal? How to implement them, for example, on the Unity engine (or on any other engine)?

Answer 1

Honest portals are very difficult to make, you need to have a good understanding of physics and the entire rendering pipeline. There are a lot of edge cases, each of which needs to be separately supported: a portal inside a portal, crossing the boundaries of an inner and outer portal, multiple inner portals, portal plane rotations, moving objects, shadows and lighting, transparent materials, etc. There are two main techniques portal rendering implementations: through texture rendering and stencil buffer .
Portals on render textures are made simpler, but they are more expensive in performance, even on simple geometry, several portals can be an overwhelming task for a computer. The basic principle is as follows: when you look at the portal, on the other side of the portal the camera draws a picture into a texture, this texture is stretched over a flat geometry, and from the side it seems as if another part of the scene is visible through the hole. A primitive implementation of such a scheme can be assembled by hand in the editor, but then difficulties begin. If the end portal has geometry "behind" it, it will fall into the camera's viewport and look weird. To prevent this, you need to shift the near clipping plane of the camera to the plane of the portal using CalculateObliqueMatrix. To calculate the position of the camera and recalculate the matrix, there is a convenient OnRenderObject callback . After adjusting the matrix, the portals will look more or less correct, but all sorts of jambs will pop up when moving through the portal plane due to the depth buffer and nearClipPlane of the main camera.
Stencil portals will work much faster, but to implement them, you need to be good at rummaging around in shaders. I won’t describe their work in detail, in general they are done in exactly the same way, only tricks with render textures are replaced with tricks with buffers, I suggest reading a couple of useful articles on the topic: one and two. In the context of a unit, everything is a little more complicated than in pure OpenGL, because there is no direct access to all buffers and you have to twist a little to get a similar result. A low-level API can potentially make the task easier , but I did not manage to achieve good results without losing image quality. I have high hopes for ScriptableRenderLoop , judging by the documentation, this is exactly what is needed.
Please note that all of the above refers to a purely graphical part, for the simplest case, when we have an FPS camera without animations, without additional mechanics, which simply drives around the level and can look into portals. What can we say about a million potential bugs, if you want to turn on a particle system next to the portal or pick up a cube. Therefore, I advise you to either buy a plugin and be content with what it can do, or get ready to spend several months developing your portal system. In both cases, the limitations of the engine will not allow you to get Portal in a reasonable time, at best it will be Narbacular Drop.

Answer 2

When the portal is fired, we create a game object with the material of the camera (available in a paid junk), which is located on another portal. Thus, we see from the portals a view from another portal, after entering the portal we simply change the player's position to the position of the portal.

Answer 3

well, with teleportation by trigger, everything is probably clear, and the image in the portal, it’s probably on one of the cameras, and the other displays the image of that camera, and in order to finally get closer to the result, you can turn the camera on one portal relative to the player’s position to another portal to approach to the edge of the portal, one could see what was on the edge of another portal.

Answer 4

https://www.youtube.com/watch?v=iHqjscifPnI

Answer 5

1) The portal image is a render to texture from a camera that hangs in the middle of another portal.
2) When the player model collides with the portal, spawn a copy in the second portal. That model of the two, which is on the back side of the portal (behind the portal or inside) - we kill. We hang the camera to the remaining model.
3) Issues of collisions and rejection of model faces when viewed from a camera inside the portal also need to be addressed in each specific case.
Something like this.

Answer 6

Play the first Portal with developer commentary