The blur/pixels when you’re up close won’t be a problem, I’ll most likely keep it in-game. If you do find a way to fix it feel free.
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.
I feel like I’m so close though! Real shame, but we may have to pack it in…
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
@DrAdministration I believe currently @EgoMoose has the best solution for the time being, you should probably give him the solution check
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 .
CameraCrop.rbxl (19.8 KB)
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.
portal.rbxl (46.7 KB)
Right, so that officially leaves us with just one problem: Keep the vpf position locked…
I really feel like we’re close here guys!
It’s so cool to read this thread and watch as this progresses and develops. You’ve done a spectacular job.
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!
portal.rbxl (42.9 KB)
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)
I am at a loss for words.
You took this impossible challenge and worked (and shared + explained) until it was more than we’d dreamed remotely plausible.
You… I just… Wow.
Last post of the night I promise!
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 )
Wormholes.rbxl (129.1 KB)
Edit 2: Yet again I’m posting another version of the wormholes. This one is more polished and has the ability to walk through the portals etc, etc…
portal physics.rbxl (34.5 KB)
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.
Can you upload that one abilities to walk into the portals please?
Uhh i unfortunately overwrote it, but it really wasn’t anything special. Basically when the portal was touched get the offset from the portal, rotate it, apply to the other portal, finally teleport the character. Very simple and easy to make.
Lucky for you @AnomliKnightimus, I saved it before @EgoMoose updated it.
Wormholes.rbxl (128.6 KB)
By the way, amazing work!
Thank you so much! @ThousandDegreeKnife