Hello! I’ve been developing a recursive portal system in Godot, but I’m hitting up against a few dealbreakers. For context, by recursive portals I mean the portals from Portal, a small game you might have heard of before. The recursion here is when you view a portal through another portal.
Issue 1:
A scene with only two portals, linked to each other, is simple enough; each portal creates a Camera and Subviewport node to handle rendering and displaying its contents. There doesn’t appear to be any way to clip the bounds of what is rendered into the subviewport, however, which means every portal will require a whole-screen draw to its subviewport. This results in a huge amount of overdraw. Is there any way around this, since Godot doesn’t support stencil buffers?
Issue 2:
The second issue comes about when trying to view a portal surface through another portal surface, e.g. recursion. The current subviewport setup only allows each portal surface to display one texture per frame, including when viewed recursively through another portal. The basic non-recursive approach here results in recursive portals displaying their “top level” texture from the incorrect angle.
My solution to this was to create a second camera, subviewport, and surface for portals, that is on a separate visual layer only rendered when in a recursive view. Each portal can then generate/display a single recursive view that will have the correct perspective when viewed through the top-level portal.
This is horrifically expensive and hacky. Each portal renders the whole scene twice, and recursive portals must decide which portal they are being viewed from in order to render from the correct perspective. If a portal is viewed recursively through two different top-level portals at once, one will always render incorrectly.
I’ve implemented some basic checks to skip portal rendering when they aren’t visible, but that can only go so far. Do you have anything particular in mind?
My thoughts here are perhaps not fully baked, but the idea was based around using occlusion impostors overlaying your portals to cut down the overdraw.
Your issue 2 is (in my experience) usually solved via level design. If you want to do a full portal engine with arbitrary numbers of portals, that’s kind of specialized and is something you really want the engine to understand at the renderer level. If you’re working with a general 3D engine like Godot, you’re probably best off not allowing arbitrary portal recursion. You’re going to run into similar problems if (for example) you wind up needing to raycast through portals.
This isn’t going to help with the overdraw, but for #2, have you tried altering the process priority of portals so that the farthest away one renders first? This would seem to make sure that everything renders in the correct order. If I’m understanding your problem correctly.
Level design is probably the answer here, yeah, though I was really hoping to let the player place portals in lots of locations. In a simpler scene, the portals can at least look entirely correct right now.
Unfortunately Godot doesn’t support that; as I understand, all the buffers get updated effectively simultaneously every frame, and can’t be re-rendered mid-frame.
I’m going to explain what the problem during the development was;
It’s a 4 - 6 - 1 problem;
When you end up building too many obstacles that resonate with junior yourself, you don’t actually see yourself on the other side. From what I understand this phenome-non happens when you in fact create a tangent line of view in your portals looking at the next on, which has the next one in the view all the way back to your original. It’s funny that it doesn’t actually render a mirrior.
Can I even begin to explain the developer hype?
So you obviously think you’re hot.
You take a friend down to the portal.
You think it’s going to be a date.
Got your normals.
Got cat certificates.
You also, got your recursion set the way you like.
Just like the adults for both cameras and different sides.
You even set your color point for the texture alpha to act as a device interpreter just so you don’t use extra times.
Then you take the friend to the portal gate. You say there we are.
Except the cards are working correctly. And only your friend sees you. Then complains they are not there.
And then the friend says the numb professor is standing right inside the camera FOV.
Hey, I’m bit late to the party but still. This talk by Valve developers is a really great resource:
Basically - you are on the right track with the recursive textures being horribly expensive. Dave Kircher touches on this at the 5 minute mark when he describes compares recursive rendering approaches - stencil and texture. Using textures for recursive portals conceptually simple, but hella expensive. Unfortunately, I believe that’s all Godot can offer right now.
I see you are using a custom engine build. Anything is possible, then! Good luck!
