I’ve seen this done a few times before. I’ll give you a hint: There’s a reason the floors, walls, and ceiling are all comprised of tiny parts, a reason the frame of the portal is so thick, and a reason the camera is locked to a certain distance from your character.
2 Likes
Yeah, it’s not properly a portal if you’re staying in the same room (it’s still a very cool demo though). This is quite similar to what I did in this place (walk around inside the house):
7 Likes
That place “The Portal” could also easily be extended from simulating 2 rooms to infinitely many, even randomly generated. Specifically, if you walk from the starting room “A” through the portal to room “B”, and then you walk around the outside of the portal back to the other side, there is no reason you can’t then be looking through it into room “C”, ad infinitum. Just like in my Infinity House, you’d use a winding count to track which virtual room you’re in: if passing through the portal north-to-south increments the count, going south-to-north would decrement it.
I do the same type of thing in the Infinity House, just instead of a discrete counter, every interior furnishing has a min and max winding angle interval (angle being how many radians you’ve looped around the room’s center column), outside of which it’s invisible. Likewise, other players in the house are also hidden from you if they are not within -pi to pi radians of your winding angle.
7 Likes
So I finally took an evening to really play around with this.
I made a few changes to your code, that made it a little more usable for the standard user. For one we can now rotate, position, resize, etc the portal without worry.
Now this is most definitely an improvement in overall quality compared to my attempt, but one issue I’m still dealing with is when it comes to non-square surfaces (rectangles); we have excess blur!
There are two ways you can calculate these adjustments as far as I’m aware. The first is to adjust the CanvasSize of the SurfaceGui.
This works well, but as you can see in the above clip we get some blur up close that we wouldn’t get on an exact square surface.
The other method is to adjust the camera matrix itself.
Again, we have blurring, but in this case I find it more noticeable. The pixelation is “sharper” in that you can see pixel edges more clearly and as a result is easier to see from farther away.
You might say then this is a done deal, always use the first method then! However, when we use extremely lopsided rectangles I find the second method is better than the first!
First method:
Second method:
Quite the conundrum!
I’ve left both methods in the placefile. Perhaps one of them can be improved upon?
portal emily.rbxl (24.8 KB)
14 Likes
There are a number of ways you could try improving very close-up resolution, but I don’t know off the top of my head what is the actual limiting factor here; if it’s just the camera getting super close to the GUI (in which case pixel resolution) or it’s floating point precision in the scaling matrix.
If it’s just pixels, you can constrain the viewport size such that it’s never wider than it needs to be to completely cover the screen. That means basically combining it with code like you already have in your portal place to scale and translate the VPF.
There will always be some blurriness close up, and with extremely oblique view angles. I don’t think these viewports get the same anisotropic filtering as Decals, and resolution is capped. And it’s a 2D pixel image after all; walking up to a textured wall to the point where your camera is 0.2 studs away doesn’t hold up either.
And of course you can always get more resolution with… more viewport frames. Like if you want a really wide portal, it’s just multiple square portals 
With this solution, and the multiple copies of everything it requires to work, it becomes readily apparent why there is still demand for simply having multiple cameras in the main world. Even one copy of a decently complex room is a problem, especially if there are physically-simulated things going on and you have to manually replicate the CFrames of all the moving parts (even just a bunch of player avatars quickly becomes too much to replicate).
I love these experiments for how they reveal what kinds of things developers really want to do, even if the end results aren’t quite viable for the multi-player Portal scenarios people imagine. There’s value in just knowing the lengths that have been gone to to get demo places like this working, w.r.t driving feature requests.
7 Likes
Just as a heads up I got a great tip from @Elttob on twitter regarding skyboxes and viewport frames. As a result I was able to implement them into these viewport portals.
You can see it implemented in the portal demo:
41 Likes
Do you think it is possible to clone the player its model to the other side of the portal so that this wont happen anymore?
12 Likes
What about the other side then? You’d either need a thick wall, or you’ll have to apply it only to touching parts.
1 Like
You could try getting the player offset from the portal in local space, create a clone of the player, cframe it to the other side and then apply the offset. Then just delete any parts of the character that don’t go through the portal
1 Like
Is it possible to just make a mirror with this?
1 Like
I recently started talking to @Altevox about the portal system he has started to develop, a project i’ll be taking over following his kind offer. It fixes a lot of the issues with the current implementation including pixilation when up close due to viewport limitations and live feedback on material property changes.
13 Likes
It’d be really awesome if you open source this!
How did you stop pixelation??
2 Likes
That wouldn’t be a question for me, but Altevox. Once I get my hands on the source code however I can give you a real answer. I’m sure you can see why I was keen to help with this 
.
It’s not finished as of yet as it works around 40-60% of the time but once I knock out the bugs and get it to production level, I’ll open source it, assuming I have permission from all parties involved.
6 Likes
Do you know how the blur issue was fixed, though? That seems like one of the biggest issues holding this use case back.
I could be completely wrong, but i don’t believe that’s a viewportframe?
The reason i say this is because the neon part is still “glowing” which they don’t do in viewportframes.
14 Likes
Spot on, from my recelection he’s not utilising viewports as they are too restrictive for his use case. That said I can’t say much till I have the code, when I do i’ll be sure to update this post for you guys before I refine the sytem and make it public 
.
1 Like
I’d be very interested to see more, but tmk not using vpfs has a lot of constraints. For example, what parts you can use and space.
Maybe he’s made a breakthrough though?
3 Likes
I believe I found a glitch where force field parts can become invisible in the presence of invisible glass, which is very strange, if you set the force field transparency parts to 1000 and add decals you can possibly recreate this portal effect without using viewportframes…
Just if you guys wanted to know for your portal effects
4 Likes
Depending on where the glass is in relation to the forcefield part, this is intentional. For performance reasons, translucent objects do not render behind glass parts.
It doesn’t appear to be using any new techniques we haven’t seen before. My guess would be that there is a giant, nearly-invisible glass wall with a door in it, and slightly-transparent parts making up the interior of the Tardis. Then, all you need is a script that fully hides all the interior parts if the camera is on the wrong side of the wall. This is what the tardis-like portal in the upstairs of Club Raven is doing, and places where you can apply it are limited. It’s not a general-purpose portal solution for a number of reasons:
- Parts with even 0.02 transparency are significantly more costly to render than opaque parts.
- Large glass walls, even at 0.99+ transparency have shadow issues at various render quality settings, and can be seen if your world isn’t dark/night/space.
- Parts with 0.02 transparency have big depth-sorting problems. If you build an elaborate place that’s all not-quite-opaque, some things will look sorted wrong or inside out. Very glitchy.
Cost of duplicate geometry is similar to the VPF portal, in that if you intend to teleport players when they pass through, you need a copy of whatever they can see through the portal. Otherwise, you have to do a lot of workarounds to make players not able to see or hear players who are on the other side of the portal.
5 Likes