Up and Coming

How to do Multilayered Cameras With 0.4

49 replies
15274 views

Please see VRDaveb's response for a possible implementation 8-)

There are still problems and there is not a definitive solution that doesn't have issues.

Some people have reported it working for them but not with Image effects.

Current problems are duplicate images in one eye, latency between the updates of the sub cameras.

This topic has been closed for replies.

Show previous replies

J

jakeslack27

Up and Coming

Sorry to dig this up but I cannot seem to get the subcameras working correctly. I'm looking to get the subcameras to render AFTER the OVRCameras similar to LaeusVR so it can render on top of an image effect.

Here is my setup:

OVRCams:
OVRCam1: Depth 0, DoF Image Effect
OVRCam2: Depth 1, DoF Image Effect

Overlay camera effects 1:
SubCam1: Depth 2, ParentCam set to OVRCam1
SubCam2: Depth 3, ParentCam set to OVRCam2

Overlay camera effects 2:
SubCam3: Depth 4, ParentCam set to OVRCam1
SubCam4: Depth 5, ParentCam set to OVRCam2

This setup was working fine before the 0.4 update. If I used the OnPreCull modified script from above I get the left camera of each of the sub cams rendering just half the width?

Creative Director of Private Eye - A cinematic, neo-noir thriller for the Oculus Rift, where voyeurism meets mystery, played out against a 1950's New York city backdrop. Official Site: http://www.privateeyevr.com

sh0v0rAuthor

Up and Coming

"LaeusVR" wrote:
Just an update on multilayered cameras: I've finally tracked down the problem and have sub-cameras working without any latency.

TLDR: in vrdaveb's OVRSubCamera script, replace "void Update()" with "void OnPreCull()". You also have to ensure that your OVRCameras render before any OVRSubCameras by giving them the lowest depth values.

This works because OnPreCull is called after all the Update functions, which explains why none of the other orderings worked, even with manual setting of rotation from OVRCamera -- the sub cameras had already gone through rendering. Some useful info in the Unity docs here: http://docs.unity3d.com/Manual/ExecutionOrder.html

Also, this probably won't work correctly with TimeWarp enabled, per vrdaveb's note that the sub-cameras should be rendering first. Cross that bridge later. TimeWarp makes my builds unusable anyway, so not a big problem for now. :)

I tried this out and it still doesn't work for me, I am in Forward rendering for Lunar Flight, I end up with some sort of weird camera scaling problem. It seems like the two sets of cameras have different ICD settings.

My OVRControllers are scaled 0.25 as Lunar Flight is not built to scale. This makes it even more necessary that I can have layers because the near camera is affected by it even more as everything is smaller and a 10cm nearclip looks like 40cm.

I am still experiencing duplicate rendering in one of the eyes, is that because I amusing image effects?

It's hugely frustrating that after all this time we still don't have solid solution to this problem or at least one that is simple to implement like it was before (pre 0.3).

Thankfully my other tracking stability problem I had with Lunar Flight seems to be resolved now in the latest drivers, I was hopeful I could finally release a DK2 build but this is still holding it back.

S

siphi

Up and Coming

Hi sh0v0r,

I am not sure if this is of any help ... I picked up this thread when I was having problems with the new SDK, so thought I'd share what works for me.

Using 0.4.1 I found that it was possible to use a very simple camera tethering to the main OVR camera (just position, rotation FOV etc) - a simplified version of vrdaveb's OVRSubCamera script earlier in this thread.

Also I found that if I tried to render ANY scene geometry directly onto the OVR camera layer, then it was ALWAYS out of sync with the other (slave) cameras ... as though timewarp or something was still on (despite being switched off) ... which made things feel quite disconnected.

So, I now render EVERYTHING with the slave camera layers and just use the OVR camera as the hook into the OVR library. See attachment for detail. Note: I make good use of scene layers to keep bits of geometry away from certain cameras.

This means that all my cameras are in sync (although perhaps a frame behind the actual headset position), and I can add as many camera layers as I want (I actually disabled the "World-Close" camera layer as I was happy with the main camera (despite it spanning z=1 to z=800000 !). I am not using any image effects.

I also found that I had problems with "cross-eyed" focus ... I am not sure exactly when this went away, but I seem to think it was when I started to compiled with DX11 always on (a pain for the workflow, but workable). It might also have gone away when I stopped trying to match the camera matricies in the OVRSubCamera script.

Anyway, hope this is of some help ... looking forward to the DK2 version of Lunar Flight - which I must thank you for as it was one of the magical "WOW" moments for me when I was first getting into VR.

-Simon

sh0v0rAuthor

Up and Coming

"siphi" wrote:
Hi sh0v0r,

I am not sure if this is of any help ... I picked up this thread when I was having problems with the new SDK, so thought I'd share what works for me.

Using 0.4.1 I found that it was possible to use a very simple camera tethering to the main OVR camera (just position, rotation FOV etc) - a simplified version of vrdaveb's OVRSubCamera script earlier in this thread.

Also I found that if I tried to render ANY scene geometry directly onto the OVR camera layer, then it was ALWAYS out of sync with the other (slave) cameras ... as though timewarp or something was still on (despite being switched off) ... which made things feel quite disconnected.

So, I now render EVERYTHING with the slave camera layers and just use the OVR camera as the hook into the OVR library. See attachment for detail. Note: I make good use of scene layers to keep bits of geometry away from certain cameras.

This means that all my cameras are in sync (although perhaps a frame behind the actual headset position), and I can add as many camera layers as I want (I actually disabled the "World-Close" camera layer as I was happy with the main camera (despite it spanning z=1 to z=800000 !). I am not using any image effects.

I also found that I had problems with "cross-eyed" focus ... I am not sure exactly when this went away, but I seem to think it was when I started to compiled with DX11 always on (a pain for the workflow, but workable). It might also have gone away when I stopped trying to match the camera matricies in the OVRSubCamera script.

Anyway, hope this is of some help ... looking forward to the DK2 version of Lunar Flight - which I must thank you for as it was one of the magical "WOW" moments for me when I was first getting into VR.

-Simon

Cheers Simon!

I'll give that a go, am I right in assuming your OVRCameras are set to a layer that you haven't used in your scene so they don't render anything themselves?

EDIT: Nope this one didn't work for me either sadly, I got no barrel distortion and I could still see duplicates.

S

siphi

Up and Coming

"sh0v0r" wrote:
EDIT: Nope this one didn't work for me either sadly, I got no barrel distortion and I could still see duplicates.

???

Double check your camera render depth (render order). Double check to make sure your background is rendering first, and then render progressively towards the front, with the OVR camera being last (to apply the distortion).

And, importantly, one eye completely first, and then the other eye.

So, for me, the camera render order (camera depth parameter) is ...

Background-Left = 3
WorldFar-Left=5
Close-Left=6
OVRCamera-Left=7

Background-Right = 13
WorldFar-Right=15
Close-Right=16
OVRCamera-Right=17

I perform no geometry rendering on my OVR Cameras.

D

dragoonjefy

Participant

Thanks!

S

SteveTack

Up and Coming

"siphi" wrote:
And, importantly, one eye completely first, and then the other eye.

So, for me, the camera render order (camera depth parameter) is ...

Background-Left = 3
WorldFar-Left=5
Close-Left=6
OVRCamera-Left=7

Background-Right = 13
WorldFar-Right=15
Close-Right=16
OVRCamera-Right=17

Wow, thank you for that information. I wouldn't have thought of that. I have a five-layer camera setup for my game which was working fine with the earlier SDK and DK1, but in the new SDK I could not figure out why one OVR camera was rendering its right camera to both eyes. Bug in the SDK?

Anyway, I reordered the layers to do the right eye first and it's working properly now! Here's what mine looks like now:

Distant Right: 0
World Right: 1
Floating UI Right: 2
Cockpit Right: 3
Helmet HUD Right: 4

Distant Left: 5
World Left: 6
Floating UI Left: 7
Cockpit Left: 8
Helmet HUD Left: 9

For the head tracking, I don't use any sub-camera scripts or anything though. What I found out previously through trial and error is that the motion of all OVR cameras will use the camera with depth = 0 if there is one.

sh0v0rAuthor

Up and Coming

"SteveTack" wrote:
"siphi" wrote:
And, importantly, one eye completely first, and then the other eye.

So, for me, the camera render order (camera depth parameter) is ...

Background-Left = 3
WorldFar-Left=5
Close-Left=6
OVRCamera-Left=7

Background-Right = 13
WorldFar-Right=15
Close-Right=16
OVRCamera-Right=17

Wow, thank you for that information. I wouldn't have thought of that. I have a five-layer camera setup for my game which was working fine with the earlier SDK and DK1, but in the new SDK I could not figure out why one OVR camera was rendering its right camera to both eyes. Bug in the SDK?

Anyway, I reordered the layers to do the right eye first and it's working properly now! Here's what mine looks like now:

Distant Right: 0
World Right: 1
Floating UI Right: 2
Cockpit Right: 3
Helmet HUD Right: 4

Distant Left: 5
World Left: 6
Floating UI Left: 7
Cockpit Left: 8
Helmet HUD Left: 9

For the head tracking, I don't use any sub-camera scripts or anything though. What I found out previously through trial and error is that the motion of all OVR cameras will use the camera with depth = 0 if there is one.

I went back and had another look at trying this and I crucially missed the point about rendering the Right Eye Layers first with respect to depth order and this resolved the Duplicate problem I was having.

How ever I now have another problem.

Everything is Fisheyed as if there is no distortion taking place?

sh0v0rAuthor

Up and Coming

"vrdaveb" wrote:
Here is a similar script that also takes care of the projection, target texture, and a few other things. To use this, just set up the OVRCameraController and OVRCamera rig for your near cameras and make a "sub-camera" for each of your far-cameras. It's designed to be the child of a separate GameObject, not under your OVRCameraController. This would allow you to, for example, put the main OVRCameraController rig in a stationary cockpit/in-car model and put the sub-cameras somewhere else in the scene. Or you could make the sub-cameras children of a GameObject that's a sibling to the OVRCameraController. Hope it helps.

Dave can you please give us a status of what we should expect with the latest SDK. What should and shouldn't work. Despite spending days trying different setups I cannot get an acceptable result. Are we ever going to see Depth Camera Ordering become a standard supported feature, perhaps with a prefab.

D

DarthDisembowel

Up and Coming

Thanks guys, this thread solved a lot of problems for me. I ended up using Siphi's configuration and script (the original script was giving me the cross-eyed effect too). With multiple cameras I no longer have z-fighting at long distances, and I have nice clean shadows closeup and far away.

The only issue that has come up with the multiple-camera solution is that my shadows fade out and fade back in at the threshold between two camera ranges. Has anyone found a way around this?

Please check out the Millennium Falcon Experience , The Battle Of Endor , and TRON: Light Cycles @DarthDisembowel

Show more replies

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO