Great job on your portal work, EgoMoose! My TARDIS portal demo was based on the exact same principles, though I never resized the viewport due to the same concerns with blurring (not that it worked, if you walked too far away you’d just see blank space).
As it would so happen, in the past week I’ve rewritten the portal with a different method and have reached a near-complete state. It allows for the viewport to maintain quality as it does not need to move nor resize, but issues with perspective come with it that ruin the effect as does blurring.
You can see the warping effect most obviously at the bottom while up close, and in the center while moving left and right, but it is otherwise pretty subtle . I just need some way to distort the viewport’s camera’s rotational matrix so it ‘faces the player’s center of view’, but I don’t understand CFrame matrices enough to do this, or if it’s even technically possible. Might need to ping a CFrame expert like AxisAngles.
This topic has gone quite farther than expected. Thanks to everyone who’s been looking into this. Im currently working on making the cameras connect to different portals, along with the portal clipping.
For the portal, instead of using a world folder in the example, What’s stopping us from simply getting the parts in the players view only to appear in the portal? So that way anything else not visible (such as behind a wall) is not duplicated, reducing lag. As well as that it needs to be live feed, such as a camera. Last part, the blue portal should show what the orange portal see’s, and the orange portal should show what the blue portal see’s and so forth. Once this is done I can start working on the actual gun, and how to smoothin out the transition between portals. This may require raycasting which is not my strong suit. Thanks to everyone once again for helping me with this subject.
I detailed how the aspect ratio was messing things up prior to this, but I think I’ve found a step in the right direction that has ultimately taken us a step back from another problem .
So instead of comparing the “real” and “perfect” distance (which is still a useful metric) and then scaling the vpf’s y-size I figured it may be better to recalculate the camera’s field of view to match such that the real distance would be the perfect distance!
This provides better results when viewing from the side and up close. However, it’s main issue is that our frame doesn’t cover the whole surface again.
Aside from that the blur and weird perspective issues that still happen when very close (although minimized) seem to happen when the rDist/pDist are 0.4 or less. So at the very least we have a measurement of when things start getting blurry and wonky and maybe that can help us hone in on when/how to fix it.
The mathematically-exact solution is not possible with CFrames and SurfaceGui. I gave the explanation in a place that’s now kind of hard to find, since it’s in the VPF release megathread: ViewportFrame Release - #202 by EmilyBendsSpace
In a nutshell, the matrix you would need for the viewportFrame’s camera view matrix (which we access as Camera.CFrame) in order for the “mirror world” to look correct can’t be represented as a CFrame. It’s the inverse of a perspective projection, which is a general 4x4 affine matrix that a CFrame doesn’t even have enough elements to store.
While you can construct CFrames where the matrix part is not a proper orthonormal rotation matrix, you’re still limited to just rotations, scaling, reflections, and shear transforms. You can’t do a perspective projection.
You should rigorously disprove it for yourself. There is some chance I didn’t have enough coffee that day and did some bad matrix math, and if not, you’ll at least know for sure if you’re chasing your own tail
This article wasent just about the mirror effect, it was about the entire simulation of two connected portals, I’ll put it as solution for the time being though.
Well i mean solving that problem would be the same as solving the portal problem. All we’re asking is how we can display a window that renders a different scene. Simply adjust such that you’re rendering a “portal” scene instead of a window.
When I say simulation of them connected, I mean when passing through, it’s not only smooth but it shifts the camera if the portal is placed on the floor for an example. (Using camera tweening) As well as that the way to place portals on a wall with the gun and being able to put objects through the portal and store their velocity as they go through.
Either or, the progress we’ve gotten done just on the forums is great!
The progress is actually pretty good, another thing:
The storing velocity part is easy in some amount of terms, you just have to grab any object that touched the portal and get it’s main velocity and store it in a table of some sort (Correct me If i’m wrong ;.; )
To do the smooth transition, what you’ll can/have to do is insert a small point, preferably in the middle of the humanoidrootpart, and attach a small point to it to use as reference point for the portals. When that point touches the portal, immediately teleport them but, make sure you get the position of the player relative to the portal they went through, get that stored position and have them teleport to the other portal’s location with the relative position, if done right, you can have a somewhat seamless transition. It might not be the best but better than nothing
I think it should go a little more than just touching the portal.
Compare the enter vector of the portal (I suppose an inverse lookvector works) with the velocity vector of the object either with an angle formula or by a dot product. I would use an angle formula because you could fine tune the entering angle, compared to a dot product that simply tells you how much both vectors affect each other (0 for perpendicular, Positive for same direction, negative for opposite direction).
Hmm, so further playing with this I again think I made a little bit of progress (if this is indeed possible).
I was thinking about this problem when I remembered an old tweet I once saw from @Reselim in which they were cropping and scaling the camera viewport. I figured some of this functionality may come in handy for what we’re trying to do so I found the tweet and sure enough they were nice enough to provide some open source code .
Now, what I was able to do with this is stretch/squish the image we put on the surface without stretching/squishing the actual viewport frame. This means we can maintain any viewport frame size while no longer being dependant on a field of view less than 120 degrees.
Old:
Fixed:
The main downside is that since we’re technically up-scaling the image we do get some pixelation, however I believe this is unavoidable unless we get an orthographic camera or something of that nature.
Alright lads, I believe I got as close to a final solution as I can.
So roughly two hours ago I mentioned the goal now was to lock in the vpf position. I have yet to succeed in doing that, however, I did manage to calculate a size adjustment that would ensure regardless of camera positioning that the vpf would cover the surface!
This does mean we have a solution that (imo) is good enough for use in game assuming you don’t mind blurring when close!
In addition you’ll notice I rewrote the code so that it works nicely on any surface.
Aside from that, I’ll update you guys if I come up with any other improvements in this thread. However, as I said, for now I think this is somewhat use-able in game and we’ve come leaps and bounds from “not possible”.
Enjoy!
Edit: Adding an example for a mirror. mirror.rbxl (42.5 KB)
Since the discussion was in regards to creating a portal effect like in the game “Portal” I figured I’d lazily throw something together:
This is more a demo of the visual than it is the ability to actually walk through the portals. The functionality for that is “kinda” there, but I didn’t really work on smoothing stuff out. Also I originally only planned for placing portals on the two walls, not on the floor, hence why in the video one portal is visually blocked.
Anyways, you get this jist…
Edit: I updated the file so it works better with more than just those two walls. However, I removed the ability to walk through the portals (who cares though, again we’re here for the visual )
The only thing to do now is make it so the player is no-clipped as they enter the portal, so that way we don’t have to manually make all the walls no-collided. I think I should be able to, if anything goes wrong I’ll share it here.
.
A tricky problem indeed!
I feel like I’m so close though! Real shame, but we may have to pack it in…
