Roblox doesn’t quite give much control on customizing Viewports mainly because of the graphical processing power required which is unfortunate but it’s a price developers pay to be on a platform with millions of free games for mostly kids on usually slower PC’s.
4 Likes
This bug could easily be fixed by Removing other Characters when they are removed and when a player leaves the game.
It’s just not coded into the Demo
I somewhat fixed loose ends on your script. Allowing for multiple viewports, freezing the viewport, either parts (characters, workspace, etc) and the camera. Not updating viewports not in the camera, of course, this aspect doesnt account for parts covering it, so it isnt perfect. and some other things that make this much easier to understand and code for.
I plan to add some more features, at the current moment i dont think i have addinitems working, although i havent tried yet. I also didnt add character removing/adding when the players leave/join.
Updated Mirror Test.rbxl (34.1 KB)
The module has a comment in it describing each function in it. Read it and experiment.
The camera feature isnt added. Please dont ask for this, somehow add it yourself, ill figure a way to do it if i want to.
I added the character system. Now characters will be removed when a player leaves, and added when a player joins. I also added the :Modify() function, as i didnt do so before. One last thing i did was fix up the rendering to disable easier, without it overwrite a bind action, so you can have many viewport objects at once without it bugging or something.
Also added some cool testing keybinds.
holding F will freeze the viewport, but not cam. To freeze cam too, hold shift while holding F. Letting go of F with shift pressed will resume the viewport but with no camera updates. Otherwise camera will be unfroze.
Pressing Q will set the viewport to the original part, while pressing E will change the viewport. Pressing L will delete the portal viewport on the side… This i used to test the destory method.
[Upd] Updated Mirror Test.rbxl (35.1 KB)
20 Likes
I had nothing better to do yesterday than dig up my own portal experiment from last summer and see if I could find a workaround for the CFrame limitations I encountered with my original homography-based approach. Turns out, there is a way that doesn’t require the full 4x4 projection matrix to be correct, on account of the flattening to 2D. So I solved it like a 3x3 homogeneous system, and it works pretty well (crude demo file attached).
Pros of this approach:
- No scaling or translation of the ViewportFrame on the SurfaceGui, it’s always just sized to the gui: UDim2 of (0,1,0,1)
- Full ViewportFrame pixel resolution is always rendered (1024 x 1024 in my example place) because there is no cropping
- Less distortion when close-up (though not zero, because of resampling and hard 1024x1024 limit** (see notes below)
Cons:
- Way more calculation per frame, because gnarlier underlying mathematics.
- Resulting camera CFrame is not orthonormal. This is not 100% guaranteed to be future proof since CFrames expect the 3x3 matrix to be a valid orthonormal rotation matrix.
** If you were really ambitious, you could dynamically-resize the SurfaceGui itself to only be as large as need to fill the main camera view, and squeeze out a little more pixel resolution that way, at the expense of having to work out a whole other layer of translation and scaling 
I present the proof of concept place as a demo hacked together on a Sunday afternoon with no expectation of it being a clean, optimized, or properly-generalized solution for any portal shape or orientation, only for its academic value and further inspiration.
Portal_Demo.rbxl (24.9 KB)
21 Likes
I think there’s a possible glitch with the portal. For some reason, when I was in the portal testing, the other side of the portal showed some of the player characters on the other side without some of their body parts, or some of their accessories or clothing missing. This has happened to me on both sides of the portal, and has happened when I zoomed out right into the portal’s way and saw the entire other end. This doesn’t happen with all player characters. Some of the characters, including mine, have been fully seen properly with all body parts. Other than that, thanks for making the portal, it is amazing among what I have seen before!
This guy figured how how to make a portal without using ViewPortFrame. I’m not sure how it works exactly but it looks pretty cool. It’s uncopylocked for anyone who wants to check it out.
8 Likes
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.