YT YouTube2Text

YouTube2Text → Transcripts → What happens if you put a portal in a portal? Simulation and explanation

What happens if you put a portal in a portal? Simulation and explanation — Transcript

by optozorax · 3,699 words · 407 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00These are two connected portals.
0:02It's easy to imagine how an object would pass through them.
0:05But what about if the blue portal comes into the orange one?
0:09Will this create a black hole,
0:11or might the universe just return an error?
0:14Let's try it!
0:19Well, the universe is safe, and blue portal just comes out of itself.
0:23But there is something interesting going on.
0:26This is my solution to this problem.
0:28And in this video, we will see what's inside of this, what a portal is,
0:32how portals can move,
0:34how it works, why there is no singularity, and what will happen to the object inside.
0:39My name is Ilya. Let's dive in.
0:44For this video,
0:45I wrote a program called Portal Explorer that draws portals using ray tracing.
0:50In Portal Explorer, you can put portal into another portal and explore everything
0:54shown in this video by yourself.
0:56It even works on most smartphones.
0:58And there is a link to this program in the description.
1:01You are probably familiar with portals, thanks to the Portal game,
1:05where they connect the same universe and can teleport light, unlike portals
1:08in many other works of fiction.
1:11After the game's release, the community came up with this question.
1:14And it is very hard to imagine a solution, because there are no portals in real life,
1:19we can't experiment with them and develop visual intuition.
1:22So please remember
1:23that this video is just a reasonable model that I explore via my simulation.
1:29Whenever this question comes up, people always say:
1:32"Portals can't be placed on moving surfaces."
1:34You really can't do this in the first game,
1:36but it is possible in the second game.
1:38Who is right?
1:40It does not matter.
1:41Let's not base our understanding of portals on some games.
1:44It is better to think of a portal as an abstract mathematical concept
1:48that can potentially exist in real life.
1:50Then our only limitation is rules of logic.
1:53Therefore, let's assume that portals can move
1:56until we run into contradictions.
1:59Let's first understand what a portal even is.
2:02There isn't a strict mathematical definition of them,
2:04only a vague idea of what a portal should be.
2:08I think that a portal concept comes from the idea of a doorway,
2:11which can connect two different rooms. We can build portals
2:14by cutting and joining space between doorways, like this.
2:18Now we can say that a doorway is just two back-to-back portals.
2:22This becomes our first property of a portal:
2:25if we connect two portals back-to-back to make a doorway,
2:28everything should work the same.
2:30Let's apply this property to the moving doorway.
2:33We see that the two portals that comprise it are moving too,
2:37and even if we move them slightly, nothing really changes.
2:40This also works for this kind of movement.
2:44As we can see, there is nothing preventing portals from moving.
2:47We've learned that portals can move while stationary relative to each other.
2:52Now let's consider another type of movement:
2:54when only one portal moves.
2:56And we already have another community picture for this.
2:59I won't discuss it because it's just plain wrong as a question.
3:02It has no concrete values: speed, mass, force — everything.
3:06You can say that the object is very heavy and the portal is slow,
3:09therefore A is correct.
3:10Or the object is lightweight and the portal is fast,
3:14therefore B is correct.
3:15Everyone interprets this picture their own way.
3:18So, I have plans to make a video about this situation with concrete values
3:22and with respect to energy and momentum conservation.
3:25So subscribe if you want to see this.
3:27For now, let's forget physics and talk only about geometry.
3:31This is a similar situation without gravity, air friction,
3:34conservation of energy or other physics.
3:37Here, the blue portal and object are still, but the orange portal moves
3:41and will fly onto the object.
3:42I claim that the teleported object will fly out from the blue portal
3:47despite not moving before teleportation.
3:50Like this.
3:51And this is just visually appealing.
3:53But if you want an explanation, let's use the first property of portals.
3:58In a geometrical sense, a moving portal and stationary object
4:01is the same as a moving object and stationary portal.
4:05So if we connect backs of the portals,
4:07then the object should also move for the blue portal.
4:10So when portals move,
4:12they change the speed of anything going through them.
4:15Finally, since the portals can move, we can return to the original problem.
4:19To answer complex questions such as "portal-in-portal",
4:22we must understand how a portal can teleport another portal at all.
4:26For that, we can take two independent pairs of portals:
4:29triangular and circular.
4:31Each has both parts: triangular here and circular here.
4:36Let's say that two different portal guns created them.
4:39So now we can take one triangular portal and push it inside the circular portal.
4:44The result is straightforward.
4:46Everything looks continuous and we can barely notice any change.
4:49But when the effect is so seamless, it's hard to understand how it works.
4:54So let's break the continuity illusion and disable light teleportation.
4:58Now our portals can teleport objects, but can't teleport light.
5:02We see that there is some surface behind which is another place.
5:05We will use that frequently to understand how portals work.
5:09Here, the red color represents the triangular portal part
5:12before teleportation, and the wall color has nothing to do with it.
5:17Next, the green color is after the teleportation.
5:20As a result, when we push the triangular portal inside,
5:22it splits into two pieces.
5:25We can see why the first portal splits.
5:27But why does this one split too?
5:29Why was it red, then half green, and then full green?
5:33Let's suppose that at this stage, here, it must be not half red, but full red.
5:39What would happen then?
5:40We can understand that in the following scene.
5:43We can treat the missing part as green.
5:46It seems that everything is fine.
5:48When we move the teleported object up, it breaks on one side.
5:52This violates our first portal rule:
5:54when we connect the backs, we don't get a clean doorway.
5:57It means that portals must always have the same shape on both sides.
6:02And therefore, here our portal is split into two: red and green.
6:07When we teleport the input, the output will change its shape too.
6:10It might seem strange that changing one portal forces the other
6:14to change too, but it all makes sense
6:16when we remember that portals are created from a single doorway,
6:20and they are one thing that looks like two things.
6:24But if there are two portals, then why does this look so continuous?
6:28How does this work?
6:29Let's take a circular portal and split it into two pieces: red and green.
6:34It's split from both sides.
6:36There are many ways to split it.
6:38But if we turn on light teleportation, we will see that everything is continuous
6:43despite the portal being cut into two pieces.
6:46Therefore, this division exists only in our minds,
6:49and there is no way to determine portal division by its appearance.
6:54We can divide any portal into infinitely many pieces,
6:56and this will be useful later.
6:59Now we understand that when two portals touch at their edges,
7:02then they can create a continuous image. In one case, they touch physically,
7:07in another — through a portal.
7:09We always push object into a whole portal. So how should we handle a split portal?
7:14If we move this square object, it will look like this.
7:18But how must that work in the implementation?
7:20If one object enters two different portals,
7:23then there must be two different objects on the other side.
7:27The green portal creates green copy and the red portal creates red copy.
7:31We can do that by placing an imaginary knife on the portal borders.
7:35This knife will cut an object along its speed direction,
7:38resulting in separate objects entering their own portal.
7:41An object is cut on the input, but it will be joined on the output,
7:45and portals always work this way.
7:48There is no way to determine when an object is being cut,
7:51so this knife exists only in our minds.
7:54Now we have a clear picture of that scene,
7:56and this is very important, because that's the whole point.
8:00In the "portal-in-portal" problem, nothing teleports by itself.
8:03Every portal is teleported by another portal.
8:07Our job is to split the portal into independent pieces,
8:10thereby we get rid of paradoxes
8:12and turn an impossible task into a computational one.
8:16But before continuing further explanation,
8:18let's return to the start of the video and better figure out what is happening.
8:23The first thing to notice — that portal is moved to the edge.
8:26This border prevents it from moving further.
8:29Then we should see that the blue portal comes out from the blue portal.
8:33In other words, it comes out of itself.
8:35So one picture about the "portal-in-portal" problem
8:37that I found on the Internet is wrong. Colors do not alternate.
8:42Then what if we look inside?
8:44We see an exciting recursion pattern from the blue portal and the same image
8:48from the orange portal. Such recursion isn't strange
8:51because we see similar effects with standard portals.
8:54Due to that recursion everyone thinks that we have
8:57some sort of singularity here, but actually we don't.
9:00Everything works like regular portals,
9:03and I will show that by placing an object here.
9:06An object can be there without touching anything,
9:08with no singularities yet.
9:10If we push it into the portal, it's just teleported to a different place.
9:14It will not duplicate, sometimes splitting into three parts.
9:18But if we enable light teleportation, it will look like
9:21the object isn't teleported anywhere, not even cut.
9:24And the distance between the object and its images
9:26is preserved, just like with regular portals.
9:30So there is no singularity.
9:32If we disable light teleportation, we will see colors: red, green and blue.
9:37We already saw this in the previous scene, the red and green colors.
9:41Here these colors represent the same thing.
9:43The red color represents the non-teleported part,
9:46the green color represents the first outgoing part,
9:49and blue represents the second outgoing part.
9:52These colors represent "teleportation degree" —
9:55how many times that portal section has been teleported.
9:58Red represents first degree, green second degree, and blue third degree.
10:04There are infinitely many degrees represented by other colors.
10:07For example, there is fourth yellow degree for this setup.
10:12When one portal comes into another, the degree of an incoming portal
10:16and degree of receiving portal add up into an outgoing portal.
10:21This happens because of how portals work mathematically.
10:24But this video will be too long with the math explanation.
10:27Write a comment if you want portal math analysis.
10:30To get a green portal we need to put a red portal into the red portal.
10:34To get a blue portal we can put red into green or green into red.
10:38There are many ways to get a yellow degree.
10:41And for the end of this section, let's just look at
10:43beautiful rotations of portal inside itself.
10:53If we pause this animation, we will see this beautiful picture.
10:56See how many teleportation degrees there are.
11:00Okay, it's all clear now.
11:02But how do we unite all this magic and make it work?
11:05If you worked with physics simulation or game development,
11:08then a naive solution is obvious.
11:11We need to take discrete steps and make a procedure
11:13that will return the next simulation step from the current one.
11:18This is how we will make a discrete approach.
11:21We have the scene
11:22where the object has come into the portal in one discrete step.
11:26By the end of this step, we can cut the entered part entirely.
11:30If previously we cut by the speed of an incoming object,
11:34then now we have a second cut approach: cutting along the portal surface.
11:39And we see that we have two different parts:
11:41one fully enters the portal, and the other doesn't enter at all.
11:45And we can teleport this second part.
11:48This is how teleportation looks: move,
11:51cut,
11:52return, teleport, move again.
11:56We can imagine something like that for portal teleportation.
12:00Now we have all the pieces to create a discrete approach.
12:03I spent months programming this a long time ago before Portal Explorer.
12:08Here colors are different because of a different algorithm.
12:11But the main idea is preserved.
12:13We have some state, let's continue with it.
12:15First, we find where to cut,
12:17like we did previously, cutting by portal plane.
12:20Notice, when we cut the blue portal, a seam appears on the orange portal too.
12:25Now move and teleport.
12:27And now join parts with the same color, which is physically near.
12:30This is needed to save computational resources.
12:33Now cut by portal plane again.
12:36And here we have a new stage — cutting by speed knife.
12:39We see that this little piece is caught exactly by this type of cutting.
12:43Previously, we had two different portals nearby too,
12:46and the border between these parts creates a speed knife.
12:49And now look, if we cut the incoming portal
12:52by these borders and these borders emerge from cutting, then we have a recursion
12:57and cutting process might continue indefinitely.
13:00Fortunately, this doesn't work like that and this process will stop.
13:04In this scene, we got fortunate because there is a small number of parts.
13:09But for other setups, this can work badly.
13:12Do you remember I said
13:13that every portal is teleported by another independent portal?
13:18So this is the essence of the discrete approach.
13:21We cut a portal into pieces until we have each portal teleported
13:24by another independent portal to get rid of paradoxes.
13:28This is the reduction of an impossible task
13:30to a computational one.
13:31Everything works like that further in that scene.
13:34The problem is fully solved for flat portals.
13:38But for complicated, non-flat portals, my code mostly worked,
13:41albeit with strange bugs that I haven't figured out yet.
13:45Let's try to put this complicated portal into another part of it.
13:49At first, everything works fine, but then some triangles appear.
13:52This is the bug.
13:54Because of that, I call this approach naive,
13:56because it is easy to invent,
13:58but it is ineffective and difficult to implement.
14:00This led me to believe that I am doing something wrong,
14:03and there should be a much simpler way.
14:06And I managed to invent such a method, but a bit accidentally.
14:09I call this the analytical approach.
14:12I will start by explaining it on an object and then transfer these to portals.
14:17First, we will learn how to teleport a triangle.
14:20The triangle is defined by its coordinate system.
14:23This coordinate system determines the plane for the X and Y axis
14:27in which the triangle is located.
14:29The blue axis is Z, the normal axis to that plane.
14:33The triangle remains fixed in that coordinate system.
14:36Therefore, to move the triangle we need to move its coordinate system.
14:40Similarly, portals are just planes determined by two coordinate systems.
14:45And there is an operation called "teleportation",
14:47which takes three coordinate systems and returns another coordinate system.
14:51Here X represents the triangle coordinate system
14:54and P1 and P2 are the coordinate systems of the portals.
14:58In the interface, this coordinate system is created this way.
15:02So teleported coordinate system will be placed behind blue portal.
15:05And if we move the triangle, this coordinate system will move too.
15:09So we can replace that coordinate system with second triangle.
15:12And when moved, the triangle looks like it comes out from the blue portal.
15:16Let's push this triangle by half.
15:18If we disable the added triangle,
15:20then we will see only one useful part of the first triangle.
15:24The other part does nothing useful and must be removed.
15:27But if we disable the first triangle and enable the second,
15:30we will see the same, but inverted.
15:32But if we enable both parts,
15:34it will look like our teleportation works but with two excess parts.
15:38So we need to get rid of them.
15:40And here we need to pause for a moment.
15:42In this program, I use Ray Tracing to draw everything.
15:46For example, let's draw a circle.
15:48To do this, we write a function that takes an arbitrary point on the plane,
15:52determines if it lies within the circle,
15:54and returns a material number that defines how that point should be painted.
15:59Therefore, if we want to filter something,
16:02we can do this for each point independently.
16:04For example, we can get a circle by writing
16:07that the distance must be lower than 1.
16:09Just like in the high school definition of a circle.
16:12Now, how to get rid of excess parts?
16:15Remember that portals are just planes.
16:17The useful part is located in the positive half of the Z-axis,
16:22and the excess part is located in the negative part of the Z-axis.
16:27Then we can add this code to filter excess points.
16:30In this code, we transform the current point on a triangle surface
16:33into orange portal local coordinates.
16:36And then if the Z part is negative,
16:38then we remove that point from the painting.
16:41This removes the extra part.
16:43We will do the same thing for the other triangle.
16:46And now triangle teleportation looks correct.
16:49Let's think about what happened. We have two triangles,
16:52and we can say that they are two teleportation degrees of the triangle,
16:56first and second, and we just filter which part is visible and which is not.
17:01But this isn't a perfect solution,
17:03because we filter incoming objects by unbounded planes
17:07and not by portal surface.
17:09So the key idea of the analytical approach is:
17:12add as many teleportation degrees as needed, then filter excess parts.
17:16And this is enough to solve the portal-in-portal problem.
17:20Here everything works the same way.
17:22We have some number of teleportation degrees and we filter
17:25excess parts a little smarter.
17:27But here the code is more complicated.
17:29First, we have code to transform coordinates
17:32of the orange portal, and then we have code to filter by planes.
17:36The code is big for the 11th degree
17:38because we must filter by 10 previous portals.
17:41I use only 11 teleportation degrees.
17:43I can do more, but in most cases, this isn't necessary.
17:47This is how all 11 teleportation degrees look without filtration.
17:51And they are looking very cool when rotating together.
17:55This is how the analytical approach works.
17:57And it's better than the discrete approach.
17:59But it has pros and cons.
18:01Cons: It works only for ray-tracing.
18:04Therefore, we need a lot of computational resources.
18:07We have to write each teleportation degree by hand in code.
18:10It works only at the visualization stage.
18:13That is, to put physics here, we need to reinvent everything.
18:17Pros: it can be programmed very easily.
18:19Therefore, it is less prone to errors. It works very well
18:22for demonstration purposes, which is what I am pursuing in the first place.
18:26By the way, I have an idea how to solve the problem of the unbounded planes,
18:31but this is the topic for another video.
18:33Solve this video's problem, I wrote a discrete approach for months.
18:37It was really hard and tedious.
18:39But with this analytical approach,
18:41I made the "portal-in-portal" just in one day.
18:44And from this example, I am more convinced
18:46that it is more important to learn how to find effective and clever solutions
18:51instead of being diligent in solving naively for a long time.
18:55Okay! Now what you definitely want to know.
18:58As I said, here the portal can't be moved further than that.
19:01I am sure that you are interested in what will happen
19:04if we move the portal further, ignoring these limitations.
19:08There were no unbounded planes
19:10in my old code, so thanks to it we can see what will happen.
19:14Previously, stopped here. Okay, we move forward and see
19:17that a portal is being cut parallel to its velocity.
19:21This occurs because the speed knife exists not only between portals,
19:25but also on the borders.
19:26Now this portal breaks here.
19:29On the orange portal, these parts are located nearby.
19:32But for the blue portal, they are placed far from each other.
19:36Therefore, here we have a deadly knife.
19:38If we look at this scene with light teleportation,
19:41then it will look like that.
19:43Sorry about this rough visualization, the old program can't do better.
19:47As I said, to solve the problem of this video,
19:50I wrote this program,
19:51where you can see and create portal scenes.
19:53And every scene that I showed in this video is in this program.
19:57In scenes you can tweak different parameters.
19:59This program has many windows for users.
20:02This is the most important.
20:04Here you can control the current scene or read a detailed description about it.
20:09This program also has camera and rendering settings.
20:12For example,
20:13you can enable Panini projection or increase antialiasing.
20:16And the next window is most important for me.
20:19I can edit a scene here, and you can too if you want.
20:22And a couple of words about the technical details.
20:25As I said, everything is drawn by ray tracing.
20:28It works on GPU through shaders.
20:31Shaders are automatically generated using available objects.
20:35Matrices and sliders are transmitted by uniforms.
20:39Uniforms can be sent in real-time,
20:41which is very convenient to create real-time movement.
20:44The whole thing was written in pure Rust — my favorite programming language.
20:48The interface is made using the concept of an "Immediate Mode GUI".
20:52I did not expect that I could make all that so fast.
20:57For this type of interface I used the "egui" library.
21:00This program works not only in the browser,
21:03but also on Windows, Linux and macOS, thanks to the "macroquad" library.
21:08And in the browser, this works not because it's written in JavaScript,
21:12but because Rust can be compiled to WebAssembly, which can run in browsers.
21:16The source code of this program is available on my GitHub.
21:20I have many more portals of different complexity
21:23and many more paradoxes and questions.
21:25So don't forget to subscribe.
21:27That's all. Bye.

About this transcript

This page contains the full transcript of What happens if you put a portal in a portal? Simulation and explanation by optozorax, generated from the public captions YouTube serves with the video. The transcript has 3,699 words across 407 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.