Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
As far as I know they explain some of the stuff in the developer commentary of Portal 1. –  Archy Mar 6 '13 at 19:36
@Byte56, thanks, I updated my post. I think this should clarify it more :) –  MiJyn Mar 6 '13 at 20:27
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. –  Byte56 Mar 6 '13 at 20:37
@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. –  Nicol Bolas Mar 6 '13 at 20:38

3 Answers 3

up vote 7 down vote accepted

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

share|improve this answer
"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. –  Nicol Bolas Mar 7 '13 at 1:40
Wow, this answers almost everything! I'm just wondering, does it work by the portal being a hole with objects inside? –  MiJyn Mar 7 '13 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.

share|improve this answer
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? –  MiJyn Mar 6 '13 at 21:07
I've edited in some more details. –  Adam Mar 6 '13 at 21:16
thanks, I'll think about this and reply later once I can set this straight in my head :) –  MiJyn Mar 6 '13 at 21:18
Thanks a lot, your answer and Virtlink's answer my question :) Now to decide which to set the "correct answer" to... –  MiJyn Mar 15 '13 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.

share|improve this answer
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 :) –  MiJyn Mar 6 '13 at 20:03
@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. –  Nicol Bolas Mar 6 '13 at 20:06
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. –  MiJyn Mar 6 '13 at 20:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.