Wow, what happened? Two years after I stopped posting the youtube algorithm comes along and now this! :D I guess it's time to start making videos again! Thank you all for the kind comments! Since 2017, this channel has since been sort of an abandoned project of mine. I can't lie.... that really makes me want to make new content.
This is the tutorial I like to see because there is no code in it. It just explain the concept. This is very useful to auto check your method, and lets us thinking about code alone without been affected and atracted by what the guy in the video did in his code. Easy, great looking video !
yeah, I wish all coding tutorials were like this because when I copy someone else's code maybe I'll understand it but there's no way I would be able to apply it to a different situation
@@mikul9204 Dependes a lot on what you want to archive. If you are teaching a general concept (as you do here), yes. No code is better. But sometimes you want to teach how to do a certain thing in a certain language. Then it's better to explain the concepts and then walk through how to put that into code
Fun fact: The Unreal Engine 1 already had portals called WarpZones. Admittedly, they had to be made at map creation/editing and they wouldn't handle hitscan, but otherwise, yeah. This shit way back in 1999. Just another reason in a long ass list of reasons why Unreal Tournament is GOAT for the PC.
You sadly omitted recursive rendering, that is, stuff seen through portals seen through portals seen through portals seen through portals seen through ...
You have the portals camera look through and render the same image, but smaller, and overlay it in the middle of the first (at the scale). You also get a very slight intentional bend in the render, so eventually, it bends away and prevents indefinite looping at specific angles, which prevents the game from crashing due to infinite re-rendering of smaller portals. The angle you add to each render is directly comparable to how much rendering your system/engine can handle. For bad computer or engine, add more angle per render and have less portal renders. For better computer or engine, add less angle each time and therefore have a bigger "depth" by having more rendered portals. Try this sometime. Get two mirrors, preferably one on the wall and another small handheld mirror with an opaque backing. Try to see an infinite loop in the mirrors by facing them at each other. You will notice that no matter how hard you try, you can never see an infinite loop because the pattern in the mirror eventually bends off and prevents further patterns from being made. (Technically, if you had a 1-way see-through mirror and you looked directly through the back of the 1-way mirror at the wall mirror, then you could see an infinite loop, but we are coding the game to avoid this.) This principle of never seeing an infinite loop and only ever seeing so many at once is exactly how the game never crashes (in theory). Note I know nothing about the coding, but I do understand the logic behind it, so please correct me if I am wrong.
@@Turtledud3 Your idea is interesting, and it would work. However, I believe the effects of perspective would become broken (that is, the further an object is, the less there is a visual scale difference between its frontmost parts and its rearmost parts). I don't really know :)
If you listen to the developpers commentary, you learn some other things they did with the portals. If you drop the cube like at 6:44, it takes a lot of stuff to make that work. I think they made a sort of gradient of the effect of both side's gravity...
i also tried this many years ago but i came up with a different solution instead of rendering the other side of the portal to a texture, i would actually use a stencil buffer to keep track of what part of the frame was portal and what wasn't as well as which portal it was i would then use a translation matrix to modify the position of everything in the level, set a clipping plane so that nothing that was supposed to be behind the portal would be drawn, and then render the frame again but only in the spots where the stencil buffer indicated there was a portal the result was a perfectly seamless portal for the physics, i created a collision object to represent the portal it's self but made it so that if a collision was detected but that point of collision happened within the portal object then it would be treated as if it wasn't a collision at all and just to make things look nice i used another clipping plane when rendering objects going though portals just so they wouldn't stick out the back
I still don't understand the graphic part of making games (masks, shaders, redering, etc), hopefully, one day I will be able to come back to this comment and understand your solution.
@@shumanbeans well, if you have any specific questions, i might be able to answer them though if you're just starting, googling a tutorial might be beter
The visual portion does not need to be anywhere near as complicated as proposed. Have the second camera point perpendicular to the plane (or tangent) of the portal and render with an off-center view frustum. This has the exact effect of "projecting" what you should be able to see through the portal onto a planar surface, skipping past all the perspective issues, distance issues, etc. It would also massively simplify recursive portals rendering. This will also be much better for performance as your view frustum will only need to be as big as the portal on your screen, so most of the time the majority of the scene would not even have to be rendered in the portal. We created this exact same effect many years ago in an intro computer graphics course, albeit in D3D11/OpenGL, but I'm sure Unity supports off-center view frustums as well. Edit: To make sure I wasn't just speaking out of my ass I just spent an hour replicating the visual effect in Unity. Can't get the camera to natively render off-axis but easily solved by supplying a custom perspective projection matrix. The above method works in Unity.
"It's not as easy as you might think" I was blown away when I first saw it. I think it must be one of the toughest things to program. Honestly, the explanation you gave is actually much easier than what I thought!
If you ever programmed a 3D camera position matrix, it's actually pretty straightforward. The portal basically transports light rays, so we can either move the whole scene to be where the portal shows or move the camera. This is the same how mirror/water reflections work, just flip the camera to the other side, render it to a texture and map it to the reflective surface.
Thank you VERY much for getting straight the duck into it without 5 to 15 minutes of exposition and then explained every bit clearly and concisely man. You don’t know how much I appreciate that.
If the camera is clipping through the wall before the player teleports to the other portal, you would either need to teleport the player a bit sooner, or change the clipping plane of the camera to be much closer to the player. Since you'll basically have your face pressed up against the wall, your camera has to have a really close near-clipping plane :)
Me listening to the ending: O ok DigiDigger: And that cover the basics of portals! Me: *Basics.....* Edit: just a joke i understood this entire vid and pracically already knew most of it the only thing hard for me is coding and stuff like that
I guess it's basic to actual game devs. It seemed very simple and straightforward the way he broke it down. But I realize now that that's definitely because I have background in this, Unity in particular. So the basics of portals.. if you know a bit about game development.
i think this would count as the basics, though functional it lacks some important mechanics that i recall were implemented in the games, namely the conservation of diagonal velocity to the portal utilized in portal 2 along with the infinite mirrors effect you can get by placing two portals across from each other
@@CabbageGod I can confirm that. I created a portal effect myself a while ago and when you have done that you will know that this was just the basics. Implementing it had a bit more to it than these basics. For example, you will also have to use oblique frustum for each camera to make it look right. This means that you set a plane in 3D space where one side of this plane will not be rendered by the camera. This is necessary to clip everything behind the wall the portal is sitting on. For example, imagine a thin wall with a portal on it. Behind the wall, there is a box. Without oblique frustum, the box will get rendered when the camera is behind it and this will look odd when looking through the portal. With it on, the box will not be rendered. There are a lot of other details, like raycasting (shooting an invisible line to detect an object; used for example for picking up boxes in Portal) through portals, keeping the box in front of you while it is on the other side of the portal, physically at a completely different position, etc.
@@CabbageGod The camera part would kill me. The physics part is not straight forward, but that should be fine. I might figure it out in few days if I didn't give up
Till today, I thought that it would have been really easy to make the game portals. You really showed by the effort that had to be done in the game, and that was 13 years back.
Well, there is the predecessor of which portal is a RIP-off (game mechanic, not story). "Narbacular Drop". According to wikipedia, valve hired some of the devs of this game
In my early days of programming, I really thought the only solution to this was to have 2 identical maps with 2 identical versions of all players and physics objects, one map for each portal. But now I see it's not that bad. Thank you!
And viewer be like, "let's watch this content which we dont want to just for the sake of getting like by comenting comment which there is already like a infinite of them"
Portal always fascinated me. I always wondered how this works though I was aware that they must use two "cameras". It all seems so easy but I bet there is so much complexity behind this game.
i came here expecting it to be about how the actual game did it, sort of a boundary break style thing. But i think, you figuring it out yourself, outside the game, turned out even better.
He said in the video that in order to retain an entity's velocity when going through portals, you need to transfer the velocity information when you enter the portal, to when you exit the portal, so that your velocity isn't just set to 0, and the angle of exit should just be in the same direction that the portal is facing. This is wrong. Sometimes when you enter a portal, you enter it at an angle, say, I run through a portal that is diagonally facing toward the ceiling, I would exit the portal with the same velocity that I entered it in, *and* I would exit it at an upward angle, relative to how I entered the first portal.
Amazing! One more thing I thought of is that you can set the near clipping plane of the camera to the distance between the camera and the portal so that you don’t see objects behind the exit portal.
Ahhh, this explanation is sooo good! I love how you go back and forth between problem and solution, building up to the final implementation bit by bit in a logicl manner. 10/10 presentation!
@@daetheknight. You know me from somewhere? Currently I am a DBD youtuber. I once had Portal lets plays on my channel a long time ago 😆 Not sure how people react if I suddenly upload other games
@@smashenYT lol I watch your dbd videos all the time. Even join your stream when I can catch it. You can do a test video and see how people respond to it. Plenty of other toobers try it. And if it works then you have more things you can do. If it doesn't then you can go back to dbd
I'm seeing this video now but I have been wondering about this question for YEARS. I always wanted to do some research and find out but this video does an incredible job at explaining everything. You explained every part of the question and made it strangely easy to understand
Nicely explained! I did some portal experiments in UE4 a while back and it's pretty much the same implementation I vaguely remember reading from one of Valve's presentations that they do all the rendering in one pass by setting the view/projecting matrices for the masked area of the portal so they don't use a secondary camera in the same way. It's been a while, so the details are blurry to me. That would save a bunch on performance, but is a lot more involved in getting to work proper. Are you Dutch by any chance? *subbed*
Asking the same thing. Is the image stretched or is it positioned to make it seem like we're looking through a hole? What does the whole portal look like if it was the whole wall? How is it supposed to look like if we were to look at it in a different angle (assuming the viewpoint is still connected to the player's camera than the second one)? I got all the things listed here expect for the distance part. I honestly can't wrap around my head around it.
Just imagine putting a camera six steps away from portal, 3 steps ahead of the 9 steps portal, because you are looking from nine steps the resolution is for example 1600 x 800, because field of view increases with distance, so now you just crop the displayed resolution to the correct resolution to maybe 1200 x 800 and display it on the exact same mirror size as the portal enlarging the object and making it look closer, all the while calculating the correct setps
I don't if this is the right explanation but: The image on the portals comes from the image gathered by the portal camera. The camera gathers image in a ratio that is similar to display (most likely 16:9) which is longer horizontally. But if we try to project that in a portal which is longer vertically (likely 1:2), the image produced would be squeezed in the horizontal axis. In order to counter the squeezing of the image in the horizontal axis, we just stretch the image horizontally before projecting it in the portal plane. Also as he mentioned, we don't need all the information that cannot be seen through the other side so we just discard it and scale it up so the portal only projects what the player must see. Hope this helps, although I don't know if this is the exact thing that he is mentioning in the video.
Brilliant concept; ask questions about games that an aspiring developer would ask, then build a world in parallel while walking through the material. Professor grade stuff man
I always thought there was another room rendered behind the portals, with the exact properties of the original room. It would kind of fix every problem with the camera and the teleport timing.
I think Valve actually did solve the wall problem by adding a small collider on the side of the portal. I played portal 2 with a friend and he once collided against that small hitbox and lost all his speed, he even seemed to be standing on the edge of the portal a bit. I think your portals recreated valve's portals almost perfectly, great job on that
create another cube at position: offset + pos = (current portal - position) + other portal. And something similar to rotation. then when exit destroy that clone.
This video and all the comments down are literally a gold mine of brainstorming that can never be found in any university in a whole year! Congrats every participant! :D
That collision solution was fantastic! Such a simple solution to a very complex problem. If it works it works, and is probably the best out of all the example solutions you gave as all others have horrible draw backs performance or bug wise.
Nice video, you answered a long asked question of mine. I used to thought wrapping is done by placing the exact same room behind the portal and trim overlapping meshes.
I haven't really gotten much exposure yet. I try to just keep making videos and hopefully we'll gain some subs some day :) Can I ask: how did you come across my channel?
I'm not the guy, I'm another guy, and I'm not 100% sure how I got here, but I can trace it back probabilistically. I'm gonna say that probably you were listed along some other lesser known game development channels in some reddit r/gamedev post about "good game analysis channels", to which I'll venture to say that a disclaimer was probably added about how your channel "is not updated often but the videos are great practical in depth stuff" to which I would have agreed after browsing the backlog. I probably subscribed after checking out this along a few other channels on the list and I remained subscribed with the hopes of sometime getting one of the cool videos produced here, such as this one. That's enough with hypothetical remembrances. This video was indeed very cool. I appreciate your practical quest and analytical process walkthrough. I thought it was thorough, thought provoking, motivating and engaging. Keep at it!
You showed up in related vids for me, but I'm actually the head of social media at a Toyota dealership and I 'd love to lend you my marketing and branding skills to help you get exposure. I was so shocked to see you had under 1,000 subs, but from the sound of this guys comment you've already come a long way in a year. I don't wanna get paid or anything. I really just enjoy your content and want to help it reach more people. I hope to hear back from you (:
That part where you resize the camera's view and the portal effect finally looks perfect made me audibly go "oh shit" out of how beautifully simple it ended up being. Fantastic video.
You forgot to talk about player rotations (let's say u jump in-ground and another portal in a wall.) P.S. I literally made a copy of portal 1 in unity before see nur video. And everything made same way BUT I didn't have portal collider as u did. This is a good solution. (I trigger physics. ignores collisions when enters the portal but I didn't think of adding collider on the portal itself. Heh)
The Idea of having two identical objects too replicate the halfway transfer of meshes was exactly what I came up with. At first I thought of making the meshes extremely detailed so we can divide we can just cut and paste the certain parts in other side but that would not run on the conventional PC.
Maybe you can simply adjust the render distance in order to render only from the portal. That way, objects between the camera and the portal won't be rendered
Ok so this is really cool but I think your approach isn't the same as valve's; I once used p2's level editor to bug out a portal and the game started to not render some of the walls, revealing the effect: they seemed to just place/render an entire copy of the room behind the portal
@@sharp14x definitely not nodraw, no nodraw effects and there was nothing behind the wall in question the same shape as the room being shown (bear in mind this was a rectangular puzzle editor room)
@@Starwort I would guess this is a result of the stencil-buffer rendering. I'm no expert, but perhaps if the wall around the portal vanished it might not stencil out a proper portal shape and would just render the entire room. If they just placed an entire copy of the room behind the portal, you'd be able to place a portal at the edge of a wall and see the copy of the room appear behind that wall.
I was so worried this was going to be a video of some nerd trying to come up with weird theoretical physics to explain real life portals, but it was the _real_ how portals are created
I know this video's almost a decade old, but on the off chance anyone else sees this, a few questions: 1.) How does the described system work for cases where the wall with a portal attached has a thickness less than or equal to the distance between the camera and the opposite portal? 2.) Related to the above, how does the system work in cases where an object passes into the portal, but in realspace would extend past the other side of the wall? In Portal, we have a number of instances where the portalable surface is often thinner than the object phasing through the portal, yet from my memory the engine is able to shear both the collision and render meshes so they don't impact the space beyond the portal's parent brush. 3.) In cases where an object is rendered using a billboard technique (rotated to face the camera), how would one deal with these objects in instances where they're visible in both the portal and the player's direct line of sight?
This video just showed up on my recommendations and it is absolutely awesome! I have no experience in 3D but I absolutely understood every bit of your video. Kudos!
That would surely work, but since you say that you're not a coder, I'd like to tell you that your idea - when implemented, would take up a lot of system's memory, and that would be very hard to run across a wide range of computers, which would be against the principles of Valve.
Great video, logical and interesting. Yes this just randomly showed up on my homepage today without searching lol and I'm glad it did! Make videos again!!!
Thanks for the video. This was the exact thing I wondered while playing the game - what "black magic" did they use to make portals work in a game engine and on video adapters that deal with only real life physics and perspective? My first idea was to have two cameras with projections onto the portal surfaces. It was great to see you actually reproducing the same idea and explaining the caveats that came with it and dealing with them. One thing I liked about the Portal game is that you don't lose velocity when bouncing between two horizontal portals. If you jump into one horizontal portal from a high edge, you jump up to the same height out of the other portal, and then bounce back to exact same height out of the first portal and continue bouncing forever. I imagine, if portals existed in real life, you would inevitably lose some velocity due to gravity and air friction, and would end up with lower height of every next bounce. However, such behavior of portals would make it much more difficult to play the game because then slower players (like me who hates reaction-based games) wouldn't have enough time to shoot the next portal during a bounce. That level 18 ending example with multiple jumps would become very frustrating because I would have to restart jumping from the very beginning each time I missed a shot. I don't know if that "velocity preservation forever" feature was intended for exactly this purpose - to help less agile players - or not, but it was a tremendous help for me.
Wow, what happened? Two years after I stopped posting the youtube algorithm comes along and now this! :D
I guess it's time to start making videos again! Thank you all for the kind comments!
Since 2017, this channel has since been sort of an abandoned project of mine. I can't lie.... that really makes me want to make new content.
The video is extremely well made, you explained something really complicated in an easy and exhaustive way
Actually great video, good explanation and interesting topic
I will wait for more
Please make new content. I've discovered your channel half an hour ago and I can't stop watching your videos. There are explained so good.
Moet je echt doen!
I think it was thanks to the yourtube algorithim
3:49 "What is distance?"
*Vsauce music plays*
Or does it?
Mindfield Intro starts
Hey VSauce, Michael here
Or is it?
*vsauce music intensifies*
@@De50prala Where are your fingers.*Pervert
Wait what he hearted you 4 days ago
This is the tutorial I like to see because there is no code in it. It just explain the concept. This is very useful to auto check your method, and lets us thinking about code alone without been affected and atracted by what the guy in the video did in his code. Easy, great looking video !
yeah, I wish all coding tutorials were like this because when I copy someone else's code maybe I'll understand it but there's no way I would be able to apply it to a different situation
@@mikul9204 Dependes a lot on what you want to archive. If you are teaching a general concept (as you do here), yes. No code is better. But sometimes you want to teach how to do a certain thing in a certain language. Then it's better to explain the concepts and then walk through how to put that into code
Ya, but It would have been nice if he linked to the source code though. That way we can take a look at the core algorithm.
I just don't like coding so this is the best type of video to explain what's happening.
I would like it to be a coding tutorial. Otherwise it's just useless
"Speedy thing goes in, speedy thing comes out."
I thought that might become a meme some day.
layman's terms
Fun fact: The Unreal Engine 1 already had portals called WarpZones. Admittedly, they had to be made at map creation/editing and they wouldn't handle hitscan, but otherwise, yeah. This shit way back in 1999. Just another reason in a long ass list of reasons why Unreal Tournament is GOAT for the PC.
can't explain that
I love how it's the same sound that "ADA" (the computer of the ship) in Outer World has. Good things don't disappear.
jeez, what a great video. never thought i could wrap my head around this, but you explained it perfectly. bravo!
Nick Robinson Sup Nick
This is the last place I thought I'd find you
So i flew to japan to find a portal.
I am now permanently attached to the reply chain
Portal was way ahead of its time, the portals really looked convincing^^
You sadly omitted recursive rendering, that is, stuff seen through portals seen through portals seen through portals seen through portals seen through ...
Make portal layer invisible to the camera
@@OutOfNameIdeas2 this is a dumb way
You have the portals camera look through and render the same image, but smaller, and overlay it in the middle of the first (at the scale). You also get a very slight intentional bend in the render, so eventually, it bends away and prevents indefinite looping at specific angles, which prevents the game from crashing due to infinite re-rendering of smaller portals. The angle you add to each render is directly comparable to how much rendering your system/engine can handle. For bad computer or engine, add more angle per render and have less portal renders. For better computer or engine, add less angle each time and therefore have a bigger "depth" by having more rendered portals.
Try this sometime. Get two mirrors, preferably one on the wall and another small handheld mirror with an opaque backing. Try to see an infinite loop in the mirrors by facing them at each other. You will notice that no matter how hard you try, you can never see an infinite loop because the pattern in the mirror eventually bends off and prevents further patterns from being made. (Technically, if you had a 1-way see-through mirror and you looked directly through the back of the 1-way mirror at the wall mirror, then you could see an infinite loop, but we are coding the game to avoid this.) This principle of never seeing an infinite loop and only ever seeing so many at once is exactly how the game never crashes (in theory).
Note I know nothing about the coding, but I do understand the logic behind it, so please correct me if I am wrong.
@@Turtledud3 Your idea is interesting, and it would work. However, I believe the effects of perspective would become broken (that is, the further an object is, the less there is a visual scale difference between its frontmost parts and its rearmost parts).
I don't really know :)
Oh yeah, stuff like this: ua-cam.com/video/0TZd95BCKMY/v-deo.html
Would be nice to have a nice demo with explanation for that
Apparently Valve dynamically altered the wall's collision geometry whenever a portal was placed.
Hmm i dont know how to see geometry frames and shit with the command prompt in source so im gonna see if someone else has photo or video evidence
@@kaydencebernard7775 Pretty sure one of the CO-OP map developer commentaries has a commentary node that shows you how the geometry changes.
If you listen to the developpers commentary, you learn some other things they did with the portals. If you drop the cube like at 6:44, it takes a lot of stuff to make that work. I think they made a sort of gradient of the effect of both side's gravity...
i also tried this many years ago but i came up with a different solution
instead of rendering the other side of the portal to a texture, i would actually use a stencil buffer to keep track of what part of the frame was portal and what wasn't as well as which portal it was
i would then use a translation matrix to modify the position of everything in the level, set a clipping plane so that nothing that was supposed to be behind the portal would be drawn, and then render the frame again but only in the spots where the stencil buffer indicated there was a portal
the result was a perfectly seamless portal
for the physics, i created a collision object to represent the portal it's self but made it so that if a collision was detected but that point of collision happened within the portal object then it would be treated as if it wasn't a collision at all
and just to make things look nice i used another clipping plane when rendering objects going though portals just so they wouldn't stick out the back
I still don't understand the graphic part of making games (masks, shaders, redering, etc), hopefully, one day I will be able to come back to this comment and understand your solution.
@@shumanbeans well, if you have any specific questions, i might be able to answer them
though if you're just starting, googling a tutorial might be beter
@Joe Duke what do you mean?
Thanks, I spent the entire video wondering why you wouldn't just use this approach.
@Joe Duke ah, alright, no i've never used a 3rd party game engine so i 've no idea what they're like
The visual portion does not need to be anywhere near as complicated as proposed. Have the second camera point perpendicular to the plane (or tangent) of the portal and render with an off-center view frustum. This has the exact effect of "projecting" what you should be able to see through the portal onto a planar surface, skipping past all the perspective issues, distance issues, etc. It would also massively simplify recursive portals rendering. This will also be much better for performance as your view frustum will only need to be as big as the portal on your screen, so most of the time the majority of the scene would not even have to be rendered in the portal.
We created this exact same effect many years ago in an intro computer graphics course, albeit in D3D11/OpenGL, but I'm sure Unity supports off-center view frustums as well.
Edit: To make sure I wasn't just speaking out of my ass I just spent an hour replicating the visual effect in Unity. Can't get the camera to natively render off-axis but easily solved by supplying a custom perspective projection matrix. The above method works in Unity.
can you make tutorial or upload project files please?
Can I get some of your brain?
Can you elaborate a bit more on this strategy?
If there is enough interest, I will record a tutorial when I find some time
Samuel Van Allen That would be great.
"It's not as easy as you might think"
I was blown away when I first saw it. I think it must be one of the toughest things to program. Honestly, the explanation you gave is actually much easier than what I thought!
If you ever programmed a 3D camera position matrix, it's actually pretty straightforward. The portal basically transports light rays, so we can either move the whole scene to be where the portal shows or move the camera. This is the same how mirror/water reflections work, just flip the camera to the other side, render it to a texture and map it to the reflective surface.
"teleport from portal 1 to portal 2"
i didnt know this video also covered the basics of time travel
Thank you VERY much for getting straight the duck into it without 5 to 15 minutes of exposition and then explained every bit clearly and concisely man. You don’t know how much I appreciate that.
This is crazy
...call me maybe?
XD
How did you solve the camera clipping through the wall?
gyazo.com/435e1ce3f34e10c2bafecf7cd9ee13e7
If the camera is clipping through the wall before the player teleports to the other portal, you would either need to teleport the player a bit sooner, or change the clipping plane of the camera to be much closer to the player. Since you'll basically have your face pressed up against the wall, your camera has to have a really close near-clipping plane :)
Q: How were the Portals in Portal created.
A: By the portal gun
Q: Who created the portal guns.
A: Aperture science
Q: Who created Aperture science.
A: Cave Johnson.
Q:who created Cave Johnson
@Poralisium1337 humanity
@@SalemYbor I was gonna do that
@@SteelRider who created humanity
Me listening to the ending: O ok
DigiDigger: And that cover the basics of portals!
Me: *Basics.....*
Edit: just a joke i understood this entire vid and pracically already knew most of it the only thing hard for me is coding and stuff like that
I guess it's basic to actual game devs. It seemed very simple and straightforward the way he broke it down. But I realize now that that's definitely because I have background in this, Unity in particular. So the basics of portals.. if you know a bit about game development.
i think this would count as the basics, though functional it lacks some important mechanics that i recall were implemented in the games, namely the conservation of diagonal velocity to the portal utilized in portal 2 along with the infinite mirrors effect you can get by placing two portals across from each other
Yeah this is just the basics
@@CabbageGod
I can confirm that. I created a portal effect myself a while ago and when you have done that you will know that this was just the basics.
Implementing it had a bit more to it than these basics.
For example, you will also have to use oblique frustum for each camera to make it look right. This means that you set a plane in 3D space where one side of this plane will not be rendered by the camera. This is necessary to clip everything behind the wall the portal is sitting on. For example, imagine a thin wall with a portal on it. Behind the wall, there is a box. Without oblique frustum, the box will get rendered when the camera is behind it and this will look odd when looking through the portal. With it on, the box will not be rendered.
There are a lot of other details, like raycasting (shooting an invisible line to detect an object; used for example for picking up boxes in Portal) through portals, keeping the box in front of you while it is on the other side of the portal, physically at a completely different position, etc.
@@CabbageGod The camera part would kill me. The physics part is not straight forward, but that should be fine. I might figure it out in few days if I didn't give up
Till today, I thought that it would have been really easy to make the game portals. You really showed by the effort that had to be done in the game, and that was 13 years back.
Interesting, makes sense why there isn’t really any portal rip offs
yes there are
@Sébastien Levesque there is this portal shooter
I know that's not the point but there are some really good Portal2 mods.
try mari0
Well, there is the predecessor of which portal is a RIP-off (game mechanic, not story). "Narbacular Drop". According to wikipedia, valve hired some of the devs of this game
In my early days of programming, I really thought the only solution to this was to have 2 identical maps with 2 identical versions of all players and physics objects, one map for each portal. But now I see it's not that bad. Thank you!
You need Moonrocks to make them work properly
NOBODY'S GOING TO SPACE MATE
No FBI, No.
Like most folks, no idea why this appeared in my recommended but what a FANTASTIC video, thank you!
UA-cam is like, "Let's hold this good content for a couple of years for no reason"
And viewer be like, "let's watch this content which we dont want to just for the sake of getting like by comenting comment which there is already like a infinite of them"
Portal always fascinated me. I always wondered how this works though I was aware that they must use two "cameras". It all seems so easy but I bet there is so much complexity behind this game.
i came here expecting it to be about how the actual game did it, sort of a boundary break style thing. But i think, you figuring it out yourself, outside the game, turned out even better.
As a game designer undergraduate, i find this really helpful
subbed
He said in the video that in order to retain an entity's velocity when going through portals, you need to transfer the velocity information when you enter the portal, to when you exit the portal, so that your velocity isn't just set to 0, and the angle of exit should just be in the same direction that the portal is facing. This is wrong. Sometimes when you enter a portal, you enter it at an angle, say, I run through a portal that is diagonally facing toward the ceiling, I would exit the portal with the same velocity that I entered it in, *and* I would exit it at an upward angle, relative to how I entered the first portal.
Radio music at end: (Happy sounds)
Captions: [Laughter]
Amazing! One more thing I thought of is that you can set the near clipping plane of the camera to the distance between the camera and the portal so that you don’t see objects behind the exit portal.
That's actually very important.
Just found your channel from UA-cam home page from your Terraria video. I already love this series. Looking forward to seeing more.
UA-cam is really broken for not suggesting this video to me 2 years ago.
Ahhh, this explanation is sooo good! I love how you go back and forth between problem and solution, building up to the final implementation bit by bit in a logicl manner. 10/10 presentation!
This is such an underrated video O:
That was more complicated that I thought it'd be, thanks for explaining it all.
UA-cam is like "Hey this dude didn't upload in 2 years?! Lets give him some love"
UA-camrs Daily uploading: 👀
lol hey look its Smashen!! are you planning to upload portal or splitgate arena warfare to your channel now?? >.>
@@daetheknight. You know me from somewhere? Currently I am a DBD youtuber. I once had Portal lets plays on my channel a long time ago 😆
Not sure how people react if I suddenly upload other games
@@smashenYT lol I watch your dbd videos all the time. Even join your stream when I can catch it.
You can do a test video and see how people respond to it.
Plenty of other toobers try it. And if it works then you have more things you can do. If it doesn't then you can go back to dbd
@@daetheknight. yea your name seemed familiar. UA-cam recommends this to everyone I guess 😆
You want that in English on my main channel?
@@smashenYT si, creo que el lenguaje seria perfecto
I'm seeing this video now but I have been wondering about this question for YEARS. I always wanted to do some research and find out but this video does an incredible job at explaining everything. You explained every part of the question and made it strangely easy to understand
I did not expect such a great video, why was this recomended to me now ??
Ending it with the radio tune was perfect.
Nicely explained! I did some portal experiments in UE4 a while back and it's pretty much the same implementation
I vaguely remember reading from one of Valve's presentations that they do all the rendering in one pass by setting the view/projecting matrices for the masked area of the portal so they don't use a secondary camera in the same way. It's been a while, so the details are blurry to me. That would save a bunch on performance, but is a lot more involved in getting to work proper.
Are you Dutch by any chance?
*subbed*
Ok well, I know this channel is supposed to be abandonned, but what a great video! Clear explanations, interesting, detailed steps... Congrats!
I'm still confused on the final fix to the portal implementation at 4:15. How does stretching what the camera fix our distance issue?
Asking the same thing. Is the image stretched or is it positioned to make it seem like we're looking through a hole? What does the whole portal look like if it was the whole wall? How is it supposed to look like if we were to look at it in a different angle (assuming the viewpoint is still connected to the player's camera than the second one)?
I got all the things listed here expect for the distance part. I honestly can't wrap around my head around it.
its stretched out. Its like changing FOV in a game.
Just imagine putting a camera six steps away from portal, 3 steps ahead of the 9 steps portal, because you are looking from nine steps the resolution is for example 1600 x 800, because field of view increases with distance, so now you just crop the displayed resolution to the correct resolution to maybe 1200 x 800 and display it on the exact same mirror size as the portal enlarging the object and making it look closer, all the while calculating the correct setps
I don't if this is the right explanation but:
The image on the portals comes from the image gathered by the portal camera.
The camera gathers image in a ratio that is similar to display (most likely 16:9) which is longer horizontally.
But if we try to project that in a portal which is longer vertically (likely 1:2), the image produced would be squeezed in the horizontal axis.
In order to counter the squeezing of the image in the horizontal axis, we just stretch the image horizontally before projecting it in the portal plane.
Also as he mentioned, we don't need all the information that cannot be seen through the other side so we just discard it and scale it up so the portal only projects what the player must see.
Hope this helps, although I don't know if this is the exact thing that he is mentioning in the video.
Brilliant concept; ask questions about games that an aspiring developer would ask, then build a world in parallel while walking through the material. Professor grade stuff man
Many Garry's Mod implementations of the portal gun use this method, including Bobblehead's Portal Gun and Dr Matt's TARDIS Rewrite
Yup. Though unfortunately, the visual side is buggy as hell due to GMod's limitations, and the physics is wonky as hell too.
@@randomcatdude ye, i imagine it's tricky without rebuilding the source engine
I love casestudies like this that show the ugly but genuine reality of trial and error.
Good work!
I always thought there was another room rendered behind the portals, with the exact properties of the original room.
It would kind of fix every problem with the camera and the teleport timing.
but that would also cause issues with room overlap, where if the duplicate was on top of another room it would break.
That's a good idea but it would pretty much then double the gpu the game needs to run which is no fun
What a video. I haven't seen such great video simple, elegant, ample, and funny - in years.
Short but highly effective. Bravo.
UA-cam employee: How about we recommend this video to everyone
That guy boss: Y E S
Understanding the way Portal works helps me realise how amazing and smart this game was. Back then it was considered just a minor game
Why would youtube reccomend this to me in 2019 and the channel is dead 😭
Maybe he'll come back and see his channel booming?
youtube has been doing this nonsense a lot lately..
@@cembaturkemikkiran4109 Check out the channel mix and jam, it does the same kind of thing showcased in this video but the channel is active
Check out the channel mix and jam, it does the same kind of thing showcased in this video but the channel is active
@@hubjump Check out the channel mix and jam, it does the same kind of thing showcased in this video but the channel is active
This was a brilliant step-by-step tutorial. Seriously I wasn't expecting something this good, but...wow. Thank you!
I literally had this exact question in my mind yesterday
I think Valve actually did solve the wall problem by adding a small collider on the side of the portal. I played portal 2 with a friend and he once collided against that small hitbox and lost all his speed, he even seemed to be standing on the edge of the portal a bit. I think your portals recreated valve's portals almost perfectly, great job on that
I think they have some more detail on how they created them when you turn on the directors commentary :)
I always knew cameras were what was involved but this was like 100x more than I knew!
Awesome video! Perfectly explained. I always wondered how portals worked and now I'm glad to understand it, you just got subscriber++ ;)
Logicwise, the question was answered in the first minute, which I do appreciate.
Absolutely breathtaking, ive tried to do this once long ago and ended up doing minecrafts teleportation with ender stuff
Yes! I'm so glad this wasn't an abandoned account! Please keep doing these type of videos, they are awesome.
Could you elaborate more on how you went about using the two cubes to create the illusion of one single cube?
create another cube at position: offset + pos = (current portal - position) + other portal. And something similar to rotation.
then when exit destroy that clone.
@@thewowo Yeah but how do you set collision?
@@MMedic23 well, thats more complicated; make invisible walls around the portal and make that the things in the portal only collide with that walls.
@@MMedic23 or disable the clone's collider an rigidbody
I'm really glad the YT algorithm showed me your videos, sad I missed them when they were coming out, hope to see more from you!
It just puzzles me how somebody has implemented portals into Minecraft :0
what puzzles me is how they manage to implement them in Darksiders
Darksiders was awesome. It had pretty much any game mechanic you could imagine in there.
i was thinking this was gonna be one of those talk to a valve guy for 20 min but no. this was cool
I was actually looking for something like this and was just recommended it while looking at memes. What luck
That was one of the best videos explaining game codes that i have ever seen, i always wonder me how portals in portal were created.
Me: *trying to sleep*
My brain at 2 am:
*S P E E D Y T H I N G G O I N S P E E D Y T H I N G G O O U T*
@@thepixelkings3491 lmao i was a bout to reply this
This was not what I was looking for, but UA-cams algorithm has done something right.
Can we see the source code of the portals you've made? :D
Turned up in my home feed. You could make a pretty cruel maze using this technique.
Certainly could. Check out Antichamber ;)
Obligatory "Now you are thinking with portals"
This video and all the comments down are literally a gold mine of brainstorming that can never be found in any university in a whole year! Congrats every participant! :D
I feel like an aperture science intern now
That collision solution was fantastic! Such a simple solution to a very complex problem. If it works it works, and is probably the best out of all the example solutions you gave as all others have horrible draw backs performance or bug wise.
3:45 "Who wants $60?"
I never thought further than putting a camera on the other side positioned at the portal.
congrats to the people at portal for figuring this out!
I heard valve used their room system to spawn copies of rooms on the other side of each portal
yeah, that is why test chambers are separated in both games
Nice video, you answered a long asked question of mine. I used to thought wrapping is done by placing the exact same room behind the portal and trim overlapping meshes.
Brilliant! How do you even have only 190 followers? :O
I haven't really gotten much exposure yet. I try to just keep making videos and hopefully we'll gain some subs some day :)
Can I ask: how did you come across my channel?
I'm not the guy, I'm another guy, and I'm not 100% sure how I got here, but I can trace it back probabilistically.
I'm gonna say that probably you were listed along some other lesser known game development channels in some reddit r/gamedev post about "good game analysis channels", to which I'll venture to say that a disclaimer was probably added about how your channel "is not updated often but the videos are great practical in depth stuff" to which I would have agreed after browsing the backlog. I probably subscribed after checking out this along a few other channels on the list and I remained subscribed with the hopes of sometime getting one of the cool videos produced here, such as this one. That's enough with hypothetical remembrances.
This video was indeed very cool. I appreciate your practical quest and analytical process walkthrough. I thought it was thorough, thought provoking, motivating and engaging. Keep at it!
You sure will! Keep up good work!
I think I was looking for Hotline Miami analysis. That brought me here, I like what I see, so I sub.
Владимир Остапенко 698 now, vladimir :D
You showed up in related vids for me, but I'm actually the head of social media at a Toyota dealership and I 'd love to lend you my marketing and branding skills to help you get exposure. I was so shocked to see you had under 1,000 subs, but from the sound of this guys comment you've already come a long way in a year. I don't wanna get paid or anything. I really just enjoy your content and want to help it reach more people. I hope to hear back from you (:
That part where you resize the camera's view and the portal effect finally looks perfect made me audibly go "oh shit" out of how beautifully simple it ended up being. Fantastic video.
You forgot to talk about player rotations (let's say u jump in-ground and another portal in a wall.)
P.S. I literally made a copy of portal 1 in unity before see nur video. And everything made same way BUT I didn't have portal collider as u did. This is a good solution. (I trigger physics. ignores collisions when enters the portal but I didn't think of adding collider on the portal itself. Heh)
You must be a talented coder to recreate this and explain it so well. Please do more complex game mechanics from a code standpoint!
_I'm not even angry, any-more_ although you broke my heart and kill me. I'm still alive !
300k views! So wholesome after seeing your comments! I'm really happy for you!!
Could you give a more in depth tutorial? Code wise, it would be so great!
Holy shit I had NEVER considered that there would be two cubes. That is absolutely fucking GENIUS!
"just make a portal" what can be hard here?! - 2 cameras, nothing else
- that's how it looks like from non-programmer boys (c)
I found hidden gem channel. Excuse me I'll go binge watch all the videos
Will there be any code-type tutorial for this portal concept? Cheers
The Idea of having two identical objects too replicate the halfway transfer of meshes was exactly what I came up with. At first I thought of making the meshes extremely detailed so we can divide we can just cut and paste the certain parts in other side but that would not run on the conventional PC.
1 problem: If you move the camera back like that, what if there is an object in front of the portal camera? That is gonna look weird
Maybe you can simply adjust the render distance in order to render only from the portal. That way, objects between the camera and the portal won't be rendered
@@Asjagadra yeah that kind of works, but at some angles it doesnt
Portal is more than 10 years old games, but looking how perfect valve made them, it's still mindblowing.
Ok so this is really cool but I think your approach isn't the same as valve's; I once used p2's level editor to bug out a portal and the game started to not render some of the walls, revealing the effect: they seemed to just place/render an entire copy of the room behind the portal
That is probably just the skybox or the hall of mirrors effect, you cant just instantly place entire rooms easily like that in the source engine.
You just saw the nodraw.
@@KaNofbeans could be, just saying what it looked like lol
@@sharp14x definitely not nodraw, no nodraw effects and there was nothing behind the wall in question the same shape as the room being shown (bear in mind this was a rectangular puzzle editor room)
@@Starwort I would guess this is a result of the stencil-buffer rendering. I'm no expert, but perhaps if the wall around the portal vanished it might not stencil out a proper portal shape and would just render the entire room. If they just placed an entire copy of the room behind the portal, you'd be able to place a portal at the edge of a wall and see the copy of the room appear behind that wall.
Still makes the portal programming look like witchcraft. Amazing content
I was so worried this was going to be a video of some nerd trying to come up with weird theoretical physics to explain real life portals, but it was the _real_ how portals are created
I know this video's almost a decade old, but on the off chance anyone else sees this, a few questions:
1.) How does the described system work for cases where the wall with a portal attached has a thickness less than or equal to the distance between the camera and the opposite portal?
2.) Related to the above, how does the system work in cases where an object passes into the portal, but in realspace would extend past the other side of the wall? In Portal, we have a number of instances where the portalable surface is often thinner than the object phasing through the portal, yet from my memory the engine is able to shear both the collision and render meshes so they don't impact the space beyond the portal's parent brush.
3.) In cases where an object is rendered using a billboard technique (rotated to face the camera), how would one deal with these objects in instances where they're visible in both the portal and the player's direct line of sight?
Kids be like : Oh that’s how you make one
News : a kid made portal 3
This video just showed up on my recommendations and it is absolutely awesome! I have no experience in 3D but I absolutely understood every bit of your video. Kudos!
im not a coder, but i thought you just need to create 2 copy of the same 3d world and let portals connect this two worlds
That would surely work, but since you say that you're not a coder, I'd like to tell you that your idea - when implemented, would take up a lot of system's memory, and that would be very hard to run across a wide range of computers, which would be against the principles of Valve.
@@csbnikhil Except that's closer to what they actually did than what this video shows.
I take it back, they re-render the image of the same room, which is more like what this video shows.
But still managed to run smoothly on low end systems... Wow!
Great video, logical and interesting. Yes this just randomly showed up on my homepage today without searching lol and I'm glad it did! Make videos again!!!
Why didn’t you show us how velocity transfers through a portal in your game lol
TrueProGamer because he would have to code in velocity
He did.... 7:21
Pay attention!
Dr Logiq thats valves portal you dumbass
@@oglocfriend He still explains it...
Thanks for the video. This was the exact thing I wondered while playing the game - what "black magic" did they use to make portals work in a game engine and on video adapters that deal with only real life physics and perspective?
My first idea was to have two cameras with projections onto the portal surfaces. It was great to see you actually reproducing the same idea and explaining the caveats that came with it and dealing with them.
One thing I liked about the Portal game is that you don't lose velocity when bouncing between two horizontal portals. If you jump into one horizontal portal from a high edge, you jump up to the same height out of the other portal, and then bounce back to exact same height out of the first portal and continue bouncing forever. I imagine, if portals existed in real life, you would inevitably lose some velocity due to gravity and air friction, and would end up with lower height of every next bounce. However, such behavior of portals would make it much more difficult to play the game because then slower players (like me who hates reaction-based games) wouldn't have enough time to shoot the next portal during a bounce. That level 18 ending example with multiple jumps would become very frustrating because I would have to restart jumping from the very beginning each time I missed a shot. I don't know if that "velocity preservation forever" feature was intended for exactly this purpose - to help less agile players - or not, but it was a tremendous help for me.