So that’s why the tonemap messed everything up! I made portals in godot already and i had the same issue. kept it on linear because idk how to fix it. good video
This is excellent, everything from the design to the easy-to-follow tutorial! I'm so glad you were able to make good use of the V-Sekai mirror code, and I will try and push to get that custom-projection PR, or something like it, to be included in Godot 4.3.
Appreciate the comment and your work on the custom projection PR including the working example! Was very convenient to be able to drop it in to use for my portals. Didn't think you'd see this video! The mirror example looks great too, I want to implement that as well. Yes the custom projection would be great to have in Godot 4.3, either how it is now, or maybe some backend thing just on the RenderingServer so we can set the projection without having to present it in the camera node inspector UI to new users who may find it confusing.
It would be interesting to see how to correctly implement dynamic lighting through portals, so that the light can pass through as if it was a window, and that shadows are correctly taken into account.
The only implementation I've seen that does this is Portal RTX, where they have lighting and raytracing through portals, so objects can emit light and cast their shadows through portals: th-cam.com/video/DwFCSsc99Rk/w-d-xo.html Without doing raytracing, you might be able to simulate it by calculating the light at the start portal, then emitting the same color/intensity of light at the destination portal.
I have been wanting to make A multiplayer game with A massive changing labyrinth, and because I want space to be able to overlap I have been dreaming up A system where portals exist for the purposes of maintaining "overlapping" space in different locations on the server than on the client. This hides the portals from the client entirely by simply attaching another copy of whatever chunk of the map is behind the portal, that way your coordinates only update server side when you walk through, because the server is faking continuous space. Anyway in theory this could allow for the kinds of smooth transitions of things like rendering effects of any kind including lights that your talking about.
I was stuck on this for ages, the main reason was the tonemap and the viewport size. Your method of reversing the transform was so much better than mine, i was using a node3d to track the players position local to the portal but did not work out so great. Unfortunately while this looks amazing in flat 3d, in vr the shader is ran twice in one frame causing a weird duplicate effect, i am yet to figure out a solution but this is amazing work keep it up
Okay I managed to fix the shadow issue by setting all of the atlas quadrants to 64. Even when I disabled them, which causes all the shadows to disappear, a blurry 64 atlas quality shadow will still show up when looking through a portal. Almost like it has some sort of fallback that only shows up through the portal which is strange because you would think it would show that instead of nothing when all the quadrants are disabled. Strange behavior I would like to better understand but luckily my project looks better with lower quality shadows anyway.
Hi, I've been working on my own version of Sebastian Lague's coding adventure in Godot as well. I keep getting a flickering due to the remote camera updating one frame too late. What I mean is: my player gets teleported to the other portal but the image on the viewport on arrival is still the one displayed by the camera in its former location. I looked at your code and eventually decided to try and copy it just to see. I'm still getting this flickering... Did you do anything special to fix it? I mean I did see that you call "other_portal.do_updates()" right after moving the body but it seems not to be enough for me... Thanks for helping.
iirc i got different updates even based on the renderer i was using. it's really hard to say. it was very inconsistent for me and i just experimented to stop flicker. recently i ran into a situation where i couldn't stop some graphical glitches without using the RenderingServer.frame_pre_draw signal to update. you might add that to trigger the do_updates function if it's not yet. if mine doesn't work for you, im not sure, it's really hard to say. i would have to experiment a lot.
I'll keep on experimenting things. Thanks for answering ^^ I noticed it might be due to the way I'm keeping track of the player's position (I tried to change it in your code and it started bugging).
The main problem I encountered when implementing portals in Godot was the delay in rendering the portals. This is not noticeable until you try to implement portal recursion. Also, the delay becomes noticeable if you have low fps (which will be natural for complex scenes). Now I'm trying to master the RenderingDevice in order to implement full-fledged portal recursions without delays.
Awesome. Would love to see what you come up with for that. I did look a little bit at recursion with multiple viewports. I was wondering how that worked... The order in which viewports are rendered in. I was hoping it might be the case that Godot renders them in the proper dependency tree, so if you had a chain of shaders which use viewport textures, it will render the last one first, all the way up. But from your comment it sounds like that's not the case. I did notice the visuals completely break when I placed the portals so I could see myself walking through them. I think I was reading a little, don't we need this PR to accomplish this effect - so we can force them all to re-render the same frame as needed? github.com/godotengine/godot/pull/75436 It is a bit hard to wrap my head around without playing with a demo myself.
@@MajikayoGames Yes, the ability to manually redraw viewports would be ideal for this. As far as I can judge from my experiments, the current implementation does not care about the order in which the viewports are rendered. In any case, you will receive viewport_texture from all viewports only in the next frame. In my case, this created N frames lag from N recursion depth. It also seems that Godot doesn't like viewport recursion. When I used this scheme: root ---> viewport ------> viewport --------->viewport Already the third viewport began to stutter, and subsequent ones did not render at all. Your approach to recursion is no different from mine) To implement recursion, I used adjacent viewports with portal surfaces. But it is important to change the cull_mask for cameras and the render_layers for your portal surfaces, otherwise you will get a recursion bug. Since the main rendering thread is based on the RenderingDevice, I thought about copying the data references and running another thread in multiple passes, changing the camera position and redefining the portal plane texture on each pass. But so far I have no idea how to do this, so I’m studying everything related to this))) Probably someone will implement this faster than me, since I’m busy with other rather complex things for my game.
@@reteavstudio I hear ya, my thinking is similar. I am happy with the current implementation I have for now! It works. Maybe later I will add some recursive portal fanciness. I did see one person did recursive portals in Godot on TH-cam: th-cam.com/video/B_cE0q1wMbo/w-d-xo.html I wonder if their implementation suffers from the lag effect, I can't see any in the video but not sure.
@@MajikayoGames Godot 3 renderer faster on some light scenes than Godot 4. I only noticed lag outside of recursion after porting the project to Godot 4. I think there is lag, but it's not noticeable at 100+ fps.
This is a silly question but why isn't the player visible in the demo? I've looked everywhere I can think and I can't find a reason why the player doesn't show up in the portal if you point one portal so the other portal can see the player model before you step through. I didn't think I'd need to but do I need to build Godot with the PR you reference?
It is a cyclical reference. Each portal will have a reference to the other portal. it is meant to be linked in editor when placing the portals. So you place two portals. then the only thing required to set should be the other_portal on both portals, pointed to each other (select the other node in the tree, or drag it into that entry in the inspector). The code is a bit messy for now. I might rework it, especially if Godot merges a way to modify the camera projection matrix directly into the main branch. Hope this helps.
@@MajikayoGames Okay that makes more sense, my problem is that I have two separate level scenes each with one portal. I load the 2nd scene and just get pink texture lol. Do you think there is a way to solve that problem in Godot using some other method or do the portals have to be in the same scene initially for it to work to link the portals?
@@mahmoudzayad6862 i had a similar setup, you need to connect them via a script in that case. so just whenever you spawn both, on _ready(), you should in a script, set .other_portal on both portals to be the opposite portal. as soon as you connect them, it should work fine.
@@MajikayoGames Thanks Ill try that! Thanks for responding immediately! I just saw your Procedural Dungeon Generation video and I hope to see more content from you! Loved the visualization for the algorithms you used.
So that’s why the tonemap messed everything up! I made portals in godot already and i had the same issue. kept it on linear because idk how to fix it.
good video
This is excellent, everything from the design to the easy-to-follow tutorial!
I'm so glad you were able to make good use of the V-Sekai mirror code, and I will try and push to get that custom-projection PR, or something like it, to be included in Godot 4.3.
Appreciate the comment and your work on the custom projection PR including the working example! Was very convenient to be able to drop it in to use for my portals. Didn't think you'd see this video! The mirror example looks great too, I want to implement that as well. Yes the custom projection would be great to have in Godot 4.3, either how it is now, or maybe some backend thing just on the RenderingServer so we can set the projection without having to present it in the camera node inspector UI to new users who may find it confusing.
This is amazing, great job you just gained another sub!
Thanks appreciate it! :)
It would be interesting to see how to correctly implement dynamic lighting through portals, so that the light can pass through as if it was a window, and that shadows are correctly taken into account.
The only implementation I've seen that does this is Portal RTX, where they have lighting and raytracing through portals, so objects can emit light and cast their shadows through portals: th-cam.com/video/DwFCSsc99Rk/w-d-xo.html
Without doing raytracing, you might be able to simulate it by calculating the light at the start portal, then emitting the same color/intensity of light at the destination portal.
I have been wanting to make A multiplayer game with A massive changing labyrinth, and because I want space to be able to overlap I have been dreaming up A system where portals exist for the purposes of maintaining "overlapping" space in different locations on the server than on the client.
This hides the portals from the client entirely by simply attaching another copy of whatever chunk of the map is behind the portal, that way your coordinates only update server side when you walk through, because the server is faking continuous space.
Anyway in theory this could allow for the kinds of smooth transitions of things like rendering effects of any kind including lights that your talking about.
Thanks for this. I used it for the GMTK game jam.
LOVE. THIS.
I was stuck on this for ages, the main reason was the tonemap and the viewport size. Your method of reversing the transform was so much better than mine, i was using a node3d to track the players position local to the portal but did not work out so great. Unfortunately while this looks amazing in flat 3d, in vr the shader is ran twice in one frame causing a weird duplicate effect, i am yet to figure out a solution but this is amazing work keep it up
This is amazing. Shadows cast by an OmniLight3D or a SpotLight3D become blurrier through a portal and I have not been able to find out why.
Okay I managed to fix the shadow issue by setting all of the atlas quadrants to 64. Even when I disabled them, which causes all the shadows to disappear, a blurry 64 atlas quality shadow will still show up when looking through a portal. Almost like it has some sort of fallback that only shows up through the portal which is strange because you would think it would show that instead of nothing when all the quadrants are disabled.
Strange behavior I would like to better understand but luckily my project looks better with lower quality shadows anyway.
time to remake portal in vr
Hi, I've been working on my own version of Sebastian Lague's coding adventure in Godot as well. I keep getting a flickering due to the remote camera updating one frame too late.
What I mean is: my player gets teleported to the other portal but the image on the viewport on arrival is still the one displayed by the camera in its former location.
I looked at your code and eventually decided to try and copy it just to see. I'm still getting this flickering... Did you do anything special to fix it? I mean I did see that you call "other_portal.do_updates()" right after moving the body but it seems not to be enough for me...
Thanks for helping.
iirc i got different updates even based on the renderer i was using. it's really hard to say. it was very inconsistent for me and i just experimented to stop flicker. recently i ran into a situation where i couldn't stop some graphical glitches without using the RenderingServer.frame_pre_draw signal to update. you might add that to trigger the do_updates function if it's not yet. if mine doesn't work for you, im not sure, it's really hard to say. i would have to experiment a lot.
I'll keep on experimenting things. Thanks for answering ^^
I noticed it might be due to the way I'm keeping track of the player's position (I tried to change it in your code and it started bugging).
The main problem I encountered when implementing portals in Godot was the delay in rendering the portals. This is not noticeable until you try to implement portal recursion. Also, the delay becomes noticeable if you have low fps (which will be natural for complex scenes). Now I'm trying to master the RenderingDevice in order to implement full-fledged portal recursions without delays.
Awesome. Would love to see what you come up with for that. I did look a little bit at recursion with multiple viewports. I was wondering how that worked... The order in which viewports are rendered in. I was hoping it might be the case that Godot renders them in the proper dependency tree, so if you had a chain of shaders which use viewport textures, it will render the last one first, all the way up. But from your comment it sounds like that's not the case. I did notice the visuals completely break when I placed the portals so I could see myself walking through them.
I think I was reading a little, don't we need this PR to accomplish this effect - so we can force them all to re-render the same frame as needed? github.com/godotengine/godot/pull/75436
It is a bit hard to wrap my head around without playing with a demo myself.
@@MajikayoGames Yes, the ability to manually redraw viewports would be ideal for this. As far as I can judge from my experiments, the current implementation does not care about the order in which the viewports are rendered. In any case, you will receive viewport_texture from all viewports only in the next frame. In my case, this created N frames lag from N recursion depth. It also seems that Godot doesn't like viewport recursion.
When I used this scheme:
root
---> viewport
------> viewport
--------->viewport
Already the third viewport began to stutter, and subsequent ones did not render at all.
Your approach to recursion is no different from mine) To implement recursion, I used adjacent viewports with portal surfaces. But it is important to change the cull_mask for cameras and the render_layers for your portal surfaces, otherwise you will get a recursion bug.
Since the main rendering thread is based on the RenderingDevice, I thought about copying the data references and running another thread in multiple passes, changing the camera position and redefining the portal plane texture on each pass. But so far I have no idea how to do this, so I’m studying everything related to this))) Probably someone will implement this faster than me, since I’m busy with other rather complex things for my game.
@@reteavstudio I hear ya, my thinking is similar. I am happy with the current implementation I have for now! It works. Maybe later I will add some recursive portal fanciness. I did see one person did recursive portals in Godot on TH-cam: th-cam.com/video/B_cE0q1wMbo/w-d-xo.html
I wonder if their implementation suffers from the lag effect, I can't see any in the video but not sure.
@@MajikayoGames Godot 3 renderer faster on some light scenes than Godot 4. I only noticed lag outside of recursion after porting the project to Godot 4. I think there is lag, but it's not noticeable at 100+ fps.
This is a silly question but why isn't the player visible in the demo? I've looked everywhere I can think and I can't find a reason why the player doesn't show up in the portal if you point one portal so the other portal can see the player model before you step through. I didn't think I'd need to but do I need to build Godot with the PR you reference?
Im so confused how the variable other_portal works. How are we accessing the other portal if it does not exist yet?
It is a cyclical reference. Each portal will have a reference to the other portal. it is meant to be linked in editor when placing the portals. So you place two portals. then the only thing required to set should be the other_portal on both portals, pointed to each other (select the other node in the tree, or drag it into that entry in the inspector). The code is a bit messy for now. I might rework it, especially if Godot merges a way to modify the camera projection matrix directly into the main branch. Hope this helps.
@@MajikayoGames Okay that makes more sense, my problem is that I have two separate level scenes each with one portal. I load the 2nd scene and just get pink texture lol. Do you think there is a way to solve that problem in Godot using some other method or do the portals have to be in the same scene initially for it to work to link the portals?
@@mahmoudzayad6862 i had a similar setup, you need to connect them via a script in that case. so just whenever you spawn both, on _ready(), you should in a script, set .other_portal on both portals to be the opposite portal. as soon as you connect them, it should work fine.
@@MajikayoGames Thanks Ill try that! Thanks for responding immediately!
I just saw your Procedural Dungeon Generation video and I hope to see more content from you! Loved the visualization for the algorithms you used.
@@mahmoudzayad6862 Thanks! Yep I'm working on multiple videos now. Hoping to get them out in the next few weeks.
k now time to spend 2 weeks making this into a gun for my Portal Clone