4
$\begingroup$

A question about portals from the 'portal' games.

In the games, pairs of flat, identically sized and shaped, effectively for simplicity rectangular, portals, that lay flat on surfaces, link two places.

Light, orientation of objects and momentum are conserved, relative to the orientations of both ends, as if the space going though one is seamlessly attached to the space on the other side of the other.

Something with one end protruding into a portal diagonally for example will also exist with its other end protruding diagonally out of the other portal. In this example there could seem from some angles to be multiple objects, where there is really just one.


I don't know if the portal mechanism is explained in the 'half life'/portal universe as using worm holes, but for the sake of this question, assume we don't know how this is achieved, only how it behaves.

Also there are limitations such as portals being unable to exist on moving surfaces in the games, but let's assume that portals are supposed to have no aversion, the games have a vanishingly small number of moving portal-able surfaces anyway so it doesn't seem as if they were stating that this is not possible.


Question

Two thin rectangular blocks of material of the same shape hold interconnected portals. One of these blocks is inserted through the portal on the other.

Are there strange consequences at any ranges of angles or insertion distances?


For example, but not limited to, geometric impossibility, sudden intersecting, more space seeming to be accessible than exists, spacial contradiction, or a different amount of space occupied by the blocks than their size.

Such an experiment seems very hard to visualise.

It seems that it wouldn't make sense for one block to be inserted more than half way, but would the blocks always be in each others way preventing this from occurring anyway?

$\endgroup$
5
$\begingroup$

Trying to picture this question made my brain hurt, but I think I have an answer.

It Depends.

(anti-climatic, isn't it?)

Basically, what happens falls into one of two categories: Either you end up with the portal emerging from itself (which works for a while, then breaks), or you get a NullReferenceException (to use a programming term).

To demonstrate, assume each portal has one end $A$ and another end $B$. If you insert something near $A_{in}$ end, it comes out near $A_{out}$, at the same angle.

Normal portals

Case 1: Portal emerging from itself

Case 1A: Matching Orientations

If you insert the portal such that you're pushing $B_{out}$ in near $A_{in}$, you get the bottom portion of $out$ emerging from $A_{out}$ - in other words, itself. See the diagrams below for a 2D demonstration. Note how the emerging portal is parallel to the one that it's being pushed into. This is only true when $out$ is oriented such that both portals are facing the same direction (that is, arrows drawn from the center of each one will intersect somewhere).

This will "break" when the point at which the $out$ portal emerges from itself reaches the $in$ one. At that point, you're now triggering the Case 2 issues, along with issues related to objects partially entering the portal across an edge.

Portal emerging from itself

Case 1B: Opposite Orientations

If $out$ is oriented the other way, then the angle formed is $90^{\circ}+\angle{A_2B_1}$. This means it's also parallel when $in$ and $out$ are perpendicular ($90^\circ+90^\circ=180^\circ$), and perpendicular when they're at $45^\circ$ angles to each other.

This will "break" when the emergence point enters or when the backside of $out$ reaches the edge of $in$ (which will only happen when $\angle{A_1B_2} > 90^\circ$). Then you have to figure out what happens with the backside of a portal, or when something approaches it side-on.

enter image description here

Case 2: NullReferenceException

In programming (C# specifically, although other languages may have similar behavior), a NullReferenceException is generated when you try to do anything to an object that doesn't exist. A trivial example (which is not valid in C#) is int i; i++: Create i, then increment it. What is its starting value? It's null. What does it mean to increment null? NullReferenceException. (In C#, an int actually defaults to 0, so this will behave correctly.)

In the portal case, you have a portion of the object going in $in$ that is supposed to be emerging from the part of $out$ that doesn't exist. In my above diagrams, this would be where $B1$ is near $B2$ (aka $B_{out}$ near $B_{in}$). What happens? It's impossible to define, and probably depends on the portal technology. The important thing to consider is that at the exact point where $out$ is entering $in$, it will also be coming out of $out$ This could mean two 2-dimensional surfaces perfectly adjacent to each other, it could mean coming out inside the other portal, or it could just generate a huge explosion.

$\endgroup$
  • $\begingroup$ My brain hurts now. $\endgroup$ – Bobson Dec 23 '14 at 18:32
  • $\begingroup$ I'd add more diagrams, but I gave up wrestling with Paint. I might do it when I have access to better software on a different computer. $\endgroup$ – Bobson Dec 23 '14 at 22:12
  • 1
    $\begingroup$ Great job. In the examples you've highlighted where the target part of a portal doesn't exist, it could perhaps exist, in the same way as the space inside a hall of mirrors appears to exist. But such virtual space is even harder to think about when you may be able to touch it and how to reason about if space exists around that space. It seems, with help of your diagrams, in 2D, that once one end of 'A' is inserted, however it is manipulated, it will be in the way of itself before causing issues. Inserting the other end of 'A' being where all the issues lie. $\endgroup$ – alan2here Dec 24 '14 at 12:19
  • $\begingroup$ @alan2here - I added the improved images. Depending on where your insertion is, it's possible to have some part of the portal sticking out of itself, but it's impossible to completely pass through itself because of the crossover point. $\endgroup$ – Bobson Dec 26 '14 at 4:09
1
$\begingroup$

With portals as wormholes, think of an illustration in 2 dimensions. The two holes on the page are connected under the page by a tube.

Putting one end into the other is the same as what happens in rubber: the exit is inside the tube as far as it can go before the material loses the abilitynto flex further. It might spiral around a few times. But it never re-appears in normal space.

With portals as teleporters as described in a previous question, the object is disassembeled onmthe atomic level and its pattern stored in a buffer; the destination is contacted, and at this point the call cannot be completed. The normal behavior is for the input terminal to emit the object itself. Or, in the case where the object is not a person, prompt as to cancel, keep trying, or select a different destination. If it recognises that the object is the destination portal, it can emit a pie aimed atnthe face of the operator, as an Easter Egg (you know kids are going to try it).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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