Description

A demonstration of physically impossible spaces using portals to join two spaces together.

Features

Toon-styled lighting + model silhouettes
Functional portals, allowing one to peer and walk through them
Portals preserve scale ratios when going from big-to-small or small-to-big portals.
Portals redraw objects that are partially on both sides to preserve continuity.
Very basic map definition system for defining portal, floor, and endpoint placement
First person character camera control with jumping support
Baked lightmapping on maps
Maps can be linked together procedurally via portals
Bunny buddies that follow you around.

Graphics Technologies

This project makes use of several graphics technologies and techniques in order to make portal flows as smooth as possible.

The stencil buffer

In order to draw these worlds-in-worlds, this program makes use of the stencil buffer. Each pixel has an associated stencil value that can be used to decide whether or not to write to the framebuffer. (Just as the depth buffer 'tests' before it writes, so too does the stencil buffer). This way, we can draw the world from the portal's view space, but only in a specific, confined area on the screen. This our 'window' into another room.

Matrix transforms and coordinate systems

The portal view must be relative to the portal's orientation, but also the player's view direction as well. There are a lot of coordinate space transformations to put the camera where it needs to to correctly render. Additionally, this same transformation code is used on the CPU for when the player (or objects) walk through the portal plane and are teleported to the other side.

Oblique view frustum projection matrix

An oblique view frustum is a view whose near clipping plane aligns with any arbitrary plane within the frustum. Because we don't want anything behind portals drawing (giving strange results), we can create a matrix whose near clipping plane aligns with the portal's plane. I found an incredibly useful resource linked below.

Optimizations

Although barebones, I implemented a few optimizations in hopes to get it running as fast as I could.

All map sections were a single model, and a single draw call. Because the portals can render the entire world many many times over, world drawing needed to have minimal overhead.
Rudimentary view culling. Portals do not bother rendering their world if you are behind them (a dot product check). Same applies for objects behind the player, they are not submitted as a draw call.
A resource manager to share commonly used resources (like shaders, shapes, and textures). Allows a much lower memory footprint, and for shaders require much less needless binding