Hello there! I’ve been working on this over the last couple of weeks, and it’s nearly done.
I noticed that there was nothing on the asset store for VR portals (let alone seamless ones), and the portal assets that were on the store were “jumpy” or let you hit the clipping plane with your face. There was also no documentation on the number of issues that come around when making Virtual Reality enabled portals, so I decided to do some research and come up with a working solution that I can share with you fine folks on the asset store.
Features:
Seamless transitions between portals
Absolutely no “fudging”, if you enter a portal you do not end up slightly in front of the exit
Portals support multiple levels of detail and reduction in quality for lower end computers
Portals have an option to act as if they were the same size and orientation as one another, allowing you to walk into a large portal and come out of a small one at an appropriate size. This also works for walking into a portal and coming out on a wall (this all can be disabled)
Will come with an easy VR movement script and mesh animation controller that lets you simply drop in a new avatar and model to change the player’s model. These both, again, work at any orientation (Credit to Railboy for providing the base for the character controller, although it had to be heavily modified for orientation fixes)
Portals do not render if they are not visible, even if you are “looking” at them through a wall (this one was a pain, as unity does not have occlusion checks available)
Portals are efficient enough to work well on mobile, web, or any other platform. Web has an issue with animated models, but all others work perfectly fine.
You can find the web demo here: Portal Demo by Phygon (Please note, there are visual bugs in the web demo not present in any other platform’s builds)
Models (including animated ones) can be partway into portals, and animations will behave exactly as expected- additionally, objects halfway inside portals will not be rendered behind the portals, sealing in the effect.
If the demo’s really working the way you say it is, that’s amazing.
So you can run multiple different dynamic portals that maintain physics, support partially inserted objects, can be walked through, seamlessly looked through, and they barely take up any resources whatsoever? and it works with VR.
Yeah, I’m gonna have to ask you for an estimated release on this one, this looks phenomenal.
Yep! All of that works, and more.
Release is looking to be in roughly two weeks or less, I’m doing a polishing/final testing run now. Maybe even sooner!
Definitely. Portals support physics (large objects are a bit of a problem for now, but that’s up next) so all that you’d have to do to make a portalesque game would be to make a physics-driven player controller and everything else would be dealt with automatically.
Thanks!
That’s the case at the moment, but I am/was actually working on that just today. In the released version, you will likely be able to set the number of times your portals recurse (unless I run into some unforeseen problem)
It’s worth noting that in VR, every single rendering step is more than twice as expensive as it would have been otherwise- for most applications, users would probably only want them to recurse once (or not at all)
Even if the delay between two portals was a single fraction of a draw step I feel like looking through recursive portals would be a one way trip to puke city
That, and falling through two portals infinitely like in Portal.
Good news! Due to a new matrix generation technique, portals are now about 90% faster, meaning that even outdated graphics cards could run them with little to no problem.
Also, I’ve implemented arbitrary script teleportation separate from game objects (so, for instance, you could grab something through a portal with a grabber script, or poke a gun through a portal to shoot from the other side). I’m working on a demo for this right now.
I have also implemented raycasting delegates, meaning that you can raycast through portals with no problems.
Here’s a much better delegate raycasting demo, as well as a demo featuring independent script teleportation.
As you can see, you can shoot through the portal from both your side (delegate raycasting), and with the gun on the other side (script teleportation). All that you have to do to get delegate raycasting to work is to call a TeleportableRaycast which is just as simple as a regular one, and scripts can be made teleportable independently of the objects they are attached to by simply having them inherit from TeleportableScript.
Sorry for the hiatus! I was vacationing in Japan, but I have returned.
The portal system is nearly done! Dynamic lights can pass through portals, portals now properly handle physics, dopplegangers can be dynamically updated, portals can be directly placed on walls, and the asset will come with a free physics-based control schema for VR usage.
This video is outdated at this point, but check it out!
Hi. Just found your project and I have to say that you’re doing phenomenal work. I was actually looking for assets for portals that work in VR that I could modify and use in unity. I would love to use your portal kit. Any ETA on when it will be publicly available? Also, will it be released free or have a price? Thanks. Look forward to checking your kit out.
It will be out in the next couple of days, assuming that I can figure out how to fix Unity’s bizarrely broken occlusion culling matrix. For some reason, it is scaling incorrectly with the actual occlusion matrix itself, causing absolutely bizarre issues where occlusion culling wraps around the exterior edge and explodes all over the scene. As performance was the entire focus of this project, obviously it was a bit of a wrench in the process, and I have to fix it before I release it to keep up with my performance claims.
I’ll likely be releasing a couple of versions. A base version for 5-10 dollars that works visually, a full version for ~20-40 with good optimizations, and a production version for ~100 that comes with all my custom optimization (portals effectively have no performance impact whatsoever) as well as all other features including physics passthrough, light passthrough, and more. The fully featured version would effectively allow you to make the game portal directly out of the box, as well as essentially anything else you need them for (like area portals etc)
Yep! I’m actually working on documentation right now while I have this downtime trying to figure out the occlusion. My goal with this was to make the system as flexible as possible for developers.