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).
I think it should go a little more than just touching the portal.
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.
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”.
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.
Wormholes.rbxl (128.6 KB)
By the way, amazing work!
Thank you so much! @ThousandDegreeKnife
Small stability fix! Prior to this fix when you had a surface that wasn’t exactly square you’d sometimes get a “jiggle”. I fixed this so now you can have non-square windows galore without worrying! Woopee!
Portal.rbxl (365.1 KB)
Once again, you are a savior for making this. Going to play around with this and see what I am able to make out of this
Edit: Forgot what I wanted to say and I remembered, is it possible for the portal physics to interact with parts?
The portal physics i made only works for the character, but it shouldn’t be too hard to extend it to random other parts.
The mirror implementation of this can be used for really nice visuals.
Terrain water has screen-space reflections, and parts don’t even have that. However, using this, one could make parts that have proper reflections!
Links to Tweets
We will be able to obtain this power without workarounds soon™. Have high hopes for the furthering of the Future is Bright project. You can download the demo build to get started early, though it won’t show in regular games.
(Unless FiB doesn’t cover this)
I believe they discussed world reflections at RDC, but i was under the impression that this was independent from FiB.
This looks way better over a wider view-angle range than I would have thought possible, well done! Some blurring up close was inevitable even without the camera scaling limitations, just from the limited resolution of SurfaceGUIs.
I just looked at your Portal.rbxl file to see how you got around the inverse projection conundrum, and I was pleasantly surprised to see not only something very clever, but also something I recognize from a completely different context than Roblox, specifically from actual photography.
What you’re doing with the translation of the ViewportFrame itself within the SurfaceGui is how a lot of architectural photographers corrected perspective of buildings in-camera, before computers and Photoshop were even conceived. It’s something called the Scheimpflug Principle, but is more commonly known as the “shift” part of tilt-shift photography. The way you’re cropping the edge of the viewportFrame’s view is equivalent to shifting a real camera’s lens parallel to the film (or sensor plane).
I would never have thought to try this with a UI frame
I know pretty much nothing about photography, but these are interesting reads! Thank you for sharing! I appreciate that someone like yourself has the knowledge to recognize and put a name to these concepts. It helps myself (and I’m sure others) learn more and hopefully come up with even better solution to this problem