I tested it a little bit the other day. The first portal works fairly well, with some small (probably IPD-related) misalignments. Recursive portals seem very much not to work ATM, however. X-D
Everything needs to be loaded and in the world. It shows two places in the same world and lets you see and step between them.
It wouldn’t work very well without some additional scripts to handle it. Out of the box, a third person camera doesn’t understand concepts like “duck down and follow this person through the portal”. It would likely see the player teleport and go flying across the scene to catch up.
I’ll keep that in mind for future features to add though!
Do you have online documentation for this? I bought a similar asset a while back and the implementation was incredibly complicated and forced the use of the Unity 4 fps character controller. I just want to make sure I don’t make the same mistake, especially if I’m purchasing a portal package that costs more than the portal game itself.
I haven’t taken the time to put it online yet, but feel free to email me and I’ll send you the documentation included with the package.
Basic usage is very easy - drop one of the included prefabs in the scene and make sure there’s some empty space behind the portal.
The controller included with the demo should work wonderfully. Unfortunately the current version doesn’t yet support the Unity 5 FPS controller, but is on my list of things address in upcoming releases.
This asset seem very nice, great work! However I have not had any luck getting this to work with the Google Cardboard SDK. And Ideas how to do a basic portal with VR?
Google Cardboard isn’t officially supported as of yet. They seem to be doing some things in their SDK that trip up the usual OnWillRenderObject callbacks. I’ve been told of a couple workarounds that gets it sort-of working, but nothing I’m satisfied with yet.
If you turn off “Use Oblique” fog will work, though this can cause other issues (as described in the readme). It’s a tricky, situation as the global fog makes assumptions about the view frustum (in particular, the resulting Z value) that aren’t correct for portal cameras.
If turning off oblique rending won’t work for your layout, try using a different fog method for your scenes (billboard, volumetric, etc.).
Yes, it uses one render texture per portal render a la GetTemporary. In the early render steps it pre-renders the portals’ contents, then applies them as the “texture” for each portal during the main pass.
Currently, everything works except the camera doesn’t rotate when you step through. The current trunk build fixes this for both the RB and non-RB controllers.
If you’d like to try an early copy, message me your invoice number and I’ll send it over to you!
First, let me say that this is some profound work you have done, and it really brings an entirely new layer of interactivity to Unity that has been missing for some time. However, what is your current plan to make this asset VR compatible?
It’s tough. Unity has my hands tied on this one. The current iteration of their VR API is woefully feature incomplete for getting portal rendering to work right. There’s a lot of specific work we need to do for every camera, but Unity doesn’t give us access to implied VR cameras so we can do that work, among other things.
I just posted a feature request outlining what’s needed, feel free to vote on it, then get all your friends to vote on it too!
By the way, VR support is by far the most common feature request I get for this plugin. I’d love to support it, but Unity’s API for VR rendering is too incomplete to allow me to properly render stereoscopic, seamless portals.
Please take a moment to vote on this feature request if this is something you’d like to see happen in the future! Tell your friends and co-workers too!
I haven’t tried it with those systems. As a rule of thumb, if the scene has one camera per eye there’s a decent chance it will work, but if it’s a single Unity VR camera it probably won’t.
