I'm trying to make a segmented/portal-based game engine that supports impossible (non-euclidean?) geometry.

By segmented/portal-based I mean the world is divided into segments which are connected by portals. This technique was used by the engines for classic shooters like Doom and Duke Nukem 3d.

The portals do not look or function like the portals in the game Portal, which is unfortunately what most of the results that queries containing "portal" bring up.

Each area is in its own coordinate system with each portal defining the transformation between the portal entrance in the origin segment and the portal exit in the destination segment.

It is possible for there to be multiple portals connecting the segments and for those portals to have different transformations. If I understand correctly, this makes the world non-euclidean and precludes storing a transformation for each connected segment on a segment.

Objects have transforms for each segment they are present in. So instead of the usual transform setup of objects having a local transform, a parent transform, and a world transform there is no world transform and it is possible to have more than one "parent" transform.

Advanced math is not my strong point. I understand the basics of the transformations but there are some details I don't fully grok and almost certainly some important or useful properties that I am not aware of.


Where do I "store" or "collect" the results of applying transformations to an object?

Do I apply them to the object's local tranform or do I apply it to the object's transforms relative to "parent" segments?

It seems like a bad idea to accrue transformations on the local transform, but perhaps I don't understand the purpose of the local transform.

Research before asking question:

tutorial on simple portals in unreal that helped with outlining the transformation logic, but is focused on unreal and does not answer my questions.

flipcode portal rendering tutorial which gets brought out anytime there is a question about portal-based rendering. I have read through it a couple times, although the small font is hard for me to read so it is very possible I missed some details.

related question

related question

discussion on gamedev subreddit

  • \$\begingroup\$ Isn't this exactly like the game portal, except a more limited version where the player can't move the portals and the portals "try to look natural" \$\endgroup\$ Commented Jan 20, 2018 at 21:27
  • \$\begingroup\$ @RichardTingle I guess? although a large portion of portal was the player moving the portals around and interacting with them as "portals being portals" and taking that away makes the comparison less fitting. my needs are more like Doom or Descent, where portals were used to stitch together a world. \$\endgroup\$
    – Kloranthy
    Commented Jan 20, 2018 at 22:49
  • \$\begingroup\$ I'm pretty new to stack, is there a way to add linebreaks? Pressing enter submitted the comment sooner than I wanted... \$\endgroup\$
    – Kloranthy
    Commented Jan 20, 2018 at 22:55
  • \$\begingroup\$ Not to comments no, they are ment to be small and temporary. But if you do submit them to soon you can edit them for 5 minutes \$\endgroup\$ Commented Jan 20, 2018 at 22:57
  • \$\begingroup\$ Do you know that portals were used because GPUs (or CPUs) weren't able to render enough? You can achieve everything a portal renderer does with the usual mehods (even non-euclidean rooms, just look at A hat in time's ship). \$\endgroup\$
    – Bálint
    Commented Jan 21, 2018 at 0:01

1 Answer 1


You do not need to have multiple reference frames in order to support portals.

You mentioned Duke Nukem 3D as the kind of portal system you want. That game fakes 3D using a technique called Sector-Over-Sector. Rooms are actually overlapping over the same 2D space, but because objects in different sectors do not see or interact each other, you can fake the appearance of multi-story levels. For example, look at this map layout:

sector over sector

This represents two rooms connected via a pathway. The two rooms overlap each other, but because you cannot view both rooms at the same time, it gives the illusion of being a top-and-bottom floor.

One downside of this technique is that you need to track which sector every object is in. Another is that you don't have arbitrary, "teleporting" portals.

Another technique is to use "true" portals, like you see in the game Portal. With this technique, you can connect parts of the map that are completely separate. Then you don't have to worry about which sectors objects are in, as the world position alone identifies where something is. One downside here is that each portal contains a transform - usually translate, but could have others like rotation - and for everything passing through these portals, you need to apply the portal transformation. This is especially troublesome for rendering, as you have to recursively perform rendering passes for each portal in view.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .