For example, take this scenario (excuse my horrible drawing skills): image

This is based on "Portal", where the stickman is going through the blue portal (which is linked to the red portal), but there is a wall stopping him on the red portal. Therefore he cannot go completely through the portal.

So my question is this: How do I do the physics/collision detection with them? Do I slice the player? Is there a way to link them? Are there any physics engines that support doing this? If not, how would I make one?

  • \$\begingroup\$ As far as I know they explain some of the stuff in the developer commentary of Portal 1. \$\endgroup\$
    – Archy
    Mar 6, 2013 at 19:36
  • 1
  • \$\begingroup\$ @Byte56, thanks, I updated my post. I think this should clarify it more :) \$\endgroup\$
    – MiJyn
    Mar 6, 2013 at 20:27
  • 1
    \$\begingroup\$ I think the situation you describe is very uncommon in portal (if it ever happens) since the portals are not free floating placement. They are placed on walls, and only specific walls. I don't recall a situation where I was able to place a portal, but unable to go through it due to an obstruction on the other end of the portal. I imagine you could create a temporary copy of the player in both locations for the transition period. \$\endgroup\$
    – House
    Mar 6, 2013 at 20:37
  • 2
    \$\begingroup\$ @Byte56: You must not remember very much. I remember this being done in Portal 1. I seem to recall a crushing area where one could use a portal to avoid dying. Colliding with stuff near portals is a common occurrence, and the engine handles it easily. \$\endgroup\$ Mar 6, 2013 at 20:38

3 Answers 3


The Portal game has a nice way by which they solved this problem:

The player sticks through the source portal (blue) and is seen sticking out of the target portal (orange). The player is copied to the target portal and seen stepping through it. The game renders the image you see when looking through the source portal by using a second camera and render-to-texture.

However, the copy of the player at the target location does not interact with the physics. It is only there for rendering purposes. Instead, they make virtual collision objects on the other side of the source portal, and make the player collide with that instead. This keeps the physics simple.

You only need those virtual objects for as far as the player can reach without going fully through the portal. As soon as the player passes fully through the portal, the situation is reversed.

An image to illustrate: The blue portal is the source portal, the orange portal the target portal. The dashed white box is the virtual collision object, whereas the real box is the rendered object. The player (with the red dot) only interacts with the objects directly around it. The objects at the orange portal are completely ignored.

enter image description here

  • 4
    \$\begingroup\$ "using a second camera and render-to-texture" The developers commentary on Portal 1 explicitly said that they don't use render-to-texture, because that didn't work well for their needs (especially with seeing portals from other portals). Instead, they basically transform a version of the world to the other side of the portal and just re-render through it. \$\endgroup\$ Mar 7, 2013 at 1:40
  • \$\begingroup\$ Wow, this answers almost everything! I'm just wondering, does it work by the portal being a hole with objects inside? \$\endgroup\$
    – MiJyn
    Mar 7, 2013 at 2:39

Here's how I'd try and do it.

While you're inside a portal there would be two copies of the player in the physics engine. Each copy ignores all collisions that are on the opposite side of the portal, and you then combine the results and apply the simulation results to both models.

Ideally you'd apply gravity separately for each half of the player, but you might be able to get away with just applying it for the side of the portal the player's centre of mass is on.

To ignore those collisions you need to set up an appropriate volume, and test if a point is within it. A cylinder (possibly stretched vertically) would seem to be a good option. The test is then something like if (!collisionPoint.InsideCylinder(portal)) ProcessCollision(); else IgnoreCollision();

I believe most physics engines have a system for filtering what an object can collide with, so it should be possible using a standard physics engine. For example http://bulletphysics.org/mediawiki-1.5.8/index.php/Collision_Filtering#Custom_collision_filtering

To combine the results the simplest option would probably be to add some kind of inflexible constraint between the two, and let the physics engine handle it.

  • \$\begingroup\$ Hmm, okay, how would I do this? I get the part about copying the player, but apart from that, I'm clueless. How would I ignore the collisions from the opposite side? How would I even combine the results? \$\endgroup\$
    – MiJyn
    Mar 6, 2013 at 21:07
  • \$\begingroup\$ I've edited in some more details. \$\endgroup\$
    – Adam
    Mar 6, 2013 at 21:16
  • \$\begingroup\$ thanks, I'll think about this and reply later once I can set this straight in my head :) \$\endgroup\$
    – MiJyn
    Mar 6, 2013 at 21:18
  • \$\begingroup\$ Thanks a lot, your answer and Virtlink's answer my question :) Now to decide which to set the "correct answer" to... \$\endgroup\$
    – MiJyn
    Mar 15, 2013 at 21:22

How would I calculate how far the player goes down?

Why would you want to? You don't need to calculate how far a player goes "down"; you'll find out how far down it goes as the object goes through the simulation.

How would I even connect the portals?

A portal, from a purely in-game perspective, is little more than an elaborate teleporter that messes with collision to turn collidable objects into non-collidable ones. When an object touches the portal, it starts potentially colliding with things on the other side. When the object passes "far enough" though the portal, you effectively teleport it to the other one, instantaneously changing its position and orientation.

Physics simply proceeds as normal.

  • \$\begingroup\$ When an object touches the portal, it starts potentially colliding with things on the other side yes exactly. How would I do this with a physics engine? I guess that was my question :) \$\endgroup\$
    – MiJyn
    Mar 6, 2013 at 20:03
  • \$\begingroup\$ @MiJyn: You write a physics engine that can do that. Valve had to essentially break the Source engine to make Portal actually work. No commercial or open-source physics engine can naturally do that. There's a reason why, despite Portal's popularity, there aren't scores of Portal clones on the market. \$\endgroup\$ Mar 6, 2013 at 20:06
  • \$\begingroup\$ interesting, because there are a lot of other games that have very similar mechanics (see even the TARDIS mod for minecraft). I'm sure that there must be some way to do it easily. \$\endgroup\$
    – MiJyn
    Mar 6, 2013 at 20:11

You must log in to answer this question.

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