Portals from Kin

This blog will give some more information how I made portals in our 3 day gamejam Kin. I will talk about challenges and problems I encountered and how I tackled them. An update will follow after my team will work on the second version of kin. The portal system was implemented in one day with only room for fixes and optimization 3 hours the day after, due to the time limit.

Shader:

The shader is an unlit masked material, that shows the other side of the portal with correct viewing angles. I feed a picture taken from a camera at the location where the portal takes you. This is stored in a rendertarget. this will be linked to the emissive channel. the UV's are aligned with the position of the vertex relative to screen space. If the vertex is at the left bottom of the screen, it's UV will be close to (0,0). This works well and gives us the correct viewing angle when looking trough a portal because the rendertarget has the same aspect ratio as the player's camera.

Capture:

This is the SceneCapture2D or the camera that will render to the rendertarget for our emissive channel. This camera is updated relative to the player and its rotation. If the exit of Portal A is called Point B and the player is 10m north of the portal; the camera will be 10m north of point B.

orange line left bottom: Player position, Pink line left bottom: Player rotation.

Optimization:

There is no need to have Portals in areas you already visited, because the order of levels is linear. The Optimization was done the last day while this is 'OK', there is also no need for portals in areas that you don't see. The best practice is to have one portal and one SceneCapture and move them whenever you enter a new level. Due to the time limit deleting the previous portal was the easiest and fastest to implement.

One problem I encountered was that the GPU debug statistics showed that Shadow Depth took the longest by a big margin. This made us look into lights and searching for any light with dynamic shadows with a enormous radius. Later we found out that portals were rendering each other made the drawcalls skyrocket. Move the layout of the level streaming helped and setting the resolution from the rendertarget to 1280x720 also improved fps by a big amount. The portals still looked OK on our 1080p monitors, but should be checked on a higher resolution monitor. Ultimately having a setting in the video settings that determines the resolution of the rendertarget based on the resolution of the game would be the best option.

Gameplay:

Any Collision with the portal will teleport the player. This takes into account that the capsule component or hands of the player can also trigger the teleport. So teleporting to the exit point + the difference between the center point of the player and the portal will counter any jump / stutter. The stutter would come from the view of the portal not matching the exact view the second you teleport.

Kin article:

https://thibautlemmens.wixsite.com/portfolio/post/__kin