Dynamic IPD & Out Of Memory Problem

I'm confused. Why would you adjust IPD?? Just so that the stereo separation is less when objects are close? Ignoring the fact that this will make everything look much bigger than it actually is - this also has a bigger negative side-effect of making people feel like they have a long neck when they move their head side to side. That wonky motion of the head can cause a lot of discomfort to people. If you must do this, please scale the neck model proportionally.

I should probably chime in with some thoughts here. I sometimes get the sense that the SDK is expecting certain rules of VR to be followed to the point of potentially stifling some innovation in the future. I understand the point of best practices very well, but exceptions do need to be made with all the different creative situations going on.

There's many times that I like to play with the ICD dynamically -- if not for some interesting effect, then to accommodate massive differences in scale. I would not have been able to make Titans of Space if it weren't for being able to freely change ICD on the fly, and have the ICD be different for the near vs far camera rigs. I know it's not the classical "you're transported to another world with all the exact same physical laws as meatspace" VR, but I think it's important that the option is there to play with it.

And, I know in raidho's Desperate Gods VR adaptation, he's had to play with ICD for his zoom feature and while it wasn't dialed in right for me personally, it's great that he's able to play with the idea of making it comfortable to look at something and yet still get some sense of stereoscopy when zoomed in.

I'm guessing in Sh0v's case, he's trying to make it comfortable to look at something mere inches away from the player's face, and whatever it is is probably taking up nearly the whole view. For that brief point in time, it's probably OK to do some trickery for the sake of comfort as long as the transition goes unnoticed. For temporary situations like a zoom, or a zombie getting in your face, it's OK make exceptions for the sake of user experience in my opinion.

@Sh0v, are you still able to use the lens correction shader instead of the distortion mesh? Or does that shader now need to have a precomputed lookup texture that needs to be recalculated every frame? I haven't played with SDK 0.3.1 too much yet.

Well certainly the hooks exist to change IPD dynamically else we wouldn't be having this conversation. And this certainly sounds like a bug since that operation shouldn't overflow memory. We'll definitely look into that.

But what we're also saying is that developers need to understand and appreciate the effects of these parameters. It's very dangerous to mess with someone's head dimensions. Our advice is that proportional scaling of all head parameters is fine - being a mouse is ok. But asymmetric scaling can be weird and uncomfortable to the player - being a giraffe is not ok. Tom Forsythe had a great talk about this at GDC and he hammers on it pretty hard...

http://www.gdcvault.com/play/1020714

Now for some technicalities... There are a couple of notions of IPD going on here. One notion of IPD is the actual position of your physical eyes in relationship to the physical lenses. The position of your eye relative to the lens changes the amount of scenery you can see to the left and right. This is why changing the IPD at the SDK level causes a recomputation of the distortion mesh - because your FOV is changing.

But... there is also the notion of the virtual IPD, the position of your cameras in the scene. Since I am suggesting that your entire virtual head needs to be scaled in proportion to the virtual IPD, then I'll just call this "scale". Changing the scale should NOT cause a distortion mesh recomputation. We have some sample code in our internal branch that demonstrates how to modify virtual head scale correctly - but I don't think that made it into the public release. The closest thing that I am seeing is the C++ OculusWorldDemo code for toggling zero-IPD. This is like a binary scaling - either 0 or non-zero and the neck model is also scaled in binary fashion. We'll try to get sample code out in future releases that demonstrates continuous scaling.

And then importantly, I'm not quite sure how this is exposed in Unity - if at all. I'll need to check with the Unity engineers. It seems like we need to be explicit about the difference between user IPD and virtual head scale at the Unity API level.

Yes, just to summarize:

IPD: the user's physical IPD. Determines the FOV and other real-world distortion/display parameters. This doesn't change - not without extensive surgery or blunt-force trauma! Just leave the SDK to do the right thing here - this is all about physical real-world optics.

Virtual camera separation/ICD: feel free to manipulate this, using the user's physical IPD as a starting point. As Brant pointed out, there's lots of discussion about this in my GDC talk, and it's a very powerful tool. The SDK doesn't really need to know where you put these cameras - that's up to you (but be nice to your users!).

Thanks for the replies!

"tomf" wrote:
Virtual camera separation/ICD: feel free to manipulate this, using the user's physical IPD as a starting point.

Hurray :)

So now my guess is that sh0v is fiddling with the IPD on OVRDevice, instead of the IPD on the OVRCameraController (i.e. the ICD)?

"drash" wrote:
Thanks for the replies!

"tomf" wrote:
Virtual camera separation/ICD: feel free to manipulate this, using the user's physical IPD as a starting point.

Hurray :)

So now my guess is that sh0v is fiddling with the IPD on OVRDevice, instead of the IPD on the OVRCameraController (i.e. the ICD)?

Yeah things changed from 0.2 and 0.3 but the legacy interface is still hanging around. In 0.2, setting the IPD only set the virtual camera separation. Things are different now and the interface should be updated to reflect that.

"tomf" wrote:
Yes, just to summarize:

IPD: the user's physical IPD. Determines the FOV and other real-world distortion/display parameters. This doesn't change - not without extensive surgery or blunt-force trauma! Just leave the SDK to do the right thing here - this is all about physical real-world optics.

Virtual camera separation/ICD: feel free to manipulate this, using the user's physical IPD as a starting point. As Brant pointed out, there's lots of discussion about this in my GDC talk, and it's a very powerful tool. The SDK doesn't really need to know where you put these cameras - that's up to you (but be nice to your users!).

So if I understand correctly: IPD is where you render the center of your game so they line up with the eyes through the lenses and ICD (Inter Camera Distance?) is how far apart your "virtal" software rendering is.

I also was wondering if you need to move the IPD by how much the ICD is so the centering is "correct". Now I don't and it works ok, no headaches!

Like OP I noticed that ICD needs to be lower the closer the object is to your face. But that also means everything becomes bigger, ALOT bigger!

Finally I would like to know how to manually adjust the FOV to please the VOR of the lizard brain for a custom engine:

viewtopic.php?f=26&t=8246

Thanks for all the feedback guys, I am very familiar with the effects of changing the ICD and it's impact on perception of scale. In particular Lunar Flight was not built to scale and I multiply the ICD by a scaling factor to make things appear correct. One thing I had not anticipated was the neck modelling being recalculated. In my test scene the neck position is at 0 which is obviously wrong and I wouldn't have encountered that issue during my test.

Regarding the difference between the ICD and IPD I wasn't aware there is an inbuilt variable for the ICD but it makes sense now to adjust it and not the IPD due to the lens/distortion mesh alignment.

Now as Drash pointed out I am trying something a little unusual to achieve a certain effect or result. In my case we have Zombies that grab the player and have a very up close interaction. This is not possible without adjusting the ICD to keep things in focus. I have already got this up and running and I combine it with a dynamic DOF effect, interestingly you don't really perceive any scale differences in the background but there is a perceivable change in the size of the zombies head however it is not jarring and it doesn't feel like it is unusually bigger. We feel that the combination of effects only adds to the intensity of this moment.

I am visiting you guys on the 21st after SVVR Con and I hope to bring a build along with me, looking forward to having a chat with you about all the things we have planned for ZVR.

"drash" wrote:
Thanks for the replies!

"tomf" wrote:
Virtual camera separation/ICD: feel free to manipulate this, using the user's physical IPD as a starting point.

Hurray :)

So now my guess is that sh0v is fiddling with the IPD on OVRDevice, instead of the IPD on the OVRCameraController (i.e. the ICD)?

No I am changing it in the controller but I traced it through and modifying that parameter causes the dirty flag to be set which triggers a full reconfigure of the camera. What I think I need to do is just modify the camera offsets after reading your posts. :)

The neck modelling isn't something that I hadn't considered but I'm confident there is a solution here by adjusting the ICD to simulate going cross eyed and the IPD reduction to track a close object. At least in my testing it works but I need to do more tests to improve it and since it had been crashing on me regularly I didn't get far as it only ran for a minute or two.

"tomf" wrote:

Virtual camera separation/ICD: feel free to manipulate this, using the user's physical IPD as a starting point. As Brant pointed out, there's lots of discussion about this in my GDC talk, and it's a very powerful tool. The SDK doesn't really need to know where you put these cameras - that's up to you (but be nice to your users!).

I did a test to increase this alot, and the world at a certain distance really pops out into existence when you push it; but then the stuff rendered close to your eyes becomes a horrible mess. So I added this "not so good" double rendering so that people can try this, even if it's harder to aim, because it looks so cool.

But have you guys at Oculus played with this and what are your conclusions?

The problem I see is that you can't get sensation of speed (narrow ICD) AND sensation of depth (wide ICD) at the same time. That combined with the rendering difficulties of the "sense of depth" (wide ICD) makes them appropriate per genre; for my space sim I should really use a low ICD, if any at all actually, but for a top view game like tower defence or the new platformer game, extreme ICD is something I would recommend or atleast have it configurable!