Recently I entered the GMTK Game Jam 2025 -- You can play my game here: https://itch.io/jam/gmtk-2025/rate/3770752

It uses portals to move you around, but they're not really "immersive", (i.e, you can see through them when you walk up) which is fine for the game. You're not meant to know where you're going to end up, since it would make the game a whole lot easier. It's meant to be a memory puzzle.

But for other games, you might want a smooth portal effect (because portals are cool). In 3D this is actually a lot easier, at least for the rendering. You can just have a camera look at where the portal comes out, and display that on a screen in front of you. (See this video by Sebastian Lague), but in 2D it gets a lot trickier.

You need to have a sort of FOV effect coming out of the portal, and use a camera, custom  render texture, and material to display the image on a mesh that is created dynamically and has all of the UVs correct and renders on top of the screen.

I started by making a Room prefab. This has a Camera and a Room Camera script, which sets up creating the material and texture, and getting the camera to render to them. It also creates the Mesh that the FOVs from the player will render to. The Mesh is placed at 0,0,0 in the world, since a helpful feature of Meshes in Unity is that they dont have to be one continuous surface. Any FOV that is looking into that specific room will be attached as part of the same Mesh.

Rooms contain Portals, which are any GameObject with the PortalLink component. This component handles connecting 2 portals and toggling if they're one-way or not. The actual teleportation and rendering are done by different components; TPing by the Door, and rendering by the PortalRenderer. The PortalRenderer's job is to be told by a PortalViewer that it needs to render, and to make a mesh based on the Viewer's position and visibility and send it to the RoomCamera, where it is inserted into the Room's mesh.

A PortalViewer (in the PlayerHolder here) looks at all the doors in the room that it's in and asks them if it should attempt to render. If the portal is 2-way, it always says "YES!", but if it's one-way, it checks to see if the player is on the correct side of it (using dot product to test direction difference). If the PortalViewer gets the OK to render, it shoots raycasts at a number of points between one side of the door and the other, collecting a line of points across the surface of the door that it can see. This is then sent to the PortalRenderer of the door

The PortalRenderer looks at the points the player can see, and the player's position, and moves them in its head to be in the same positions relative to the exit portal. With these imaginary points in the other room, it extends a line from the player, through that point, and all the way until they hit the edge of what the exit rooms' camera can render. These portal-surface and extended-FOV points are used to make a mesh, and translated back to the entry door, which then gives the mesh to the RoomCamera which draws it.

There's still a lot more to go, namely making FOV-in-FOV recursion, and later the whole issue of collision, but I hope to have the rendering done and going smoothly in a few days :)