Display config bug from Zendesk

[VRguy]

there is a bug in the display driver, where it doesn’t read the settings from the config file correctly.

Quick way to test:

"eyes": [

{

"center_proj_x": 0.5,

"center_proj_y": 0.5,

"rotate_180": 0

},

{

"center_proj_x": 0.5,

"center_proj_y": 0.5,

"rotate_180": 1

}

]

You would expect one half of the screen to be upside down, but both are, if you swap it:

None of the first group of eye settings are taken. I’ve looked at all the configs and they are all the same…

[russell-taylor]

Is this with the RenderManager examples? If not, which application is being run?

[robsonswiss]

Hi Russel

Test with sightline or palace demo... Also note that when making adjustments of say 0.1 or 0.9 the projection isn't shifted as expected, it also tilts and distorts.

[robsonswiss]

Hi

I've been thinking about the way the configuration is implemented, there doesn't appear to be any reference anywhere to display density, which if you don't have you can't adjust IPD accurately. Under user settings that plugin is used to set IPD however if the display density isn't known, how is IPD accurately implemented?

The way Oculus does it makes more sense, you'd want display size/resolution(from which you will calculate your X-offset at lens separation, let's use 64mm as an example), you'd also want a Y offset for lens height settings. Your IPD settings should then be based on the X/Y-offset, so IPD of 60mm should be set as X-offset -2mm X-Projection in case of fixed lenses(this needs testing, I'm assuming it will work by complensating for image shift due to off axis IPD), in case of adjustable IPD lenses then an IPD of 60mm should be set as X-offset -2mm X-offset since the user is on-axis.

I'm using offset here instead of projection because from what I see currently when you adjust X and Y projection it appears to shift the camera view, which might be usable in the scenario above with fixed IPD lenses. An offset would simply be shifting the flat picture.

Regards, Jonathan.

[robsonswiss]

Hi

I've got the new 3.8" displays, they don't work with 0.5 x projection, why doesn't "center_proj_x" or "center_proj_y" work? You can try adjust them from 0-1 and nothing changes.

Using latest OSVR binaries, doesn't work with or without rendermanager configs.

[russell-taylor]

I debug things like this using the RenderManager example programs, for the case of center of projection I use the RenderManagerOpenGLHeadSpaceExample.exe from C:\Program Files\OSVR\SDK\x64\bin because it puts a cube in the center of the field of view.

Using the attached config file and running with no HMD attached, I see the two cubes centered in each eye. When I change the center of projection in X to 0.1 in the first eye and 0.9 in the second, the cubes move to the far left in the left eye and the far right in the right eye.

nondirectmode_window.zip

A description of the configuration parameters can be found at https://github.com/OSVR/OSVR-Docs/blob/master/Configuring/distortion.md with the description of how to adjust the configuration file found near the end. Note that there is currently an open issue whereby the center of projection values are specified in D space, rather than with the range 0-1, so a large scaling for the distortion coefficients may require larger values until that is fixed. (The description at the above link matches the behavior, but it seems like it would be more natural to change the behavior to make these values always normalized and do the scaling internally to D space.)

[robsonswiss]

Thanks Russel, problem is it doesn't work with real content. I just installed the SDK, I see what you mean, the blue cubes follow the projection. Try it with any unity content and you won't get the same result, this is probably a bigger problem then since it might mean a problem with the unity plugin?

[robsonswiss]

How is OSVR HDK2 handling this because the AUO displays have a center projection at 67.6mm IPD. I look at the HDK json and it's set at 0.5

[robsonswiss]

Is there no bypass trick we can try to make this adjustment in another way?

[russell-taylor]

The HDK2 handles this by having its distortion correction render from a virtual screen that is symmetric, even though the display configuration itself is not symmetric. The pointer to the distortion.md above describes in general how this might be done, and the angles_to_config program described at https://github.com/OSVR/distortionizer/blob/master/angles_to_config/doc/anglesToConfig.md shows in detail how to construct such a distortion correction.

I don't understand the question about making the adjustment another way. The current way is working for me for all paths that use RenderManager so for those we should not need another way. For code not using RenderManager, it can implement this however it likes. If the RenderManager path is not working for you, we should figure out why and fix it.

[russell-taylor]

Sorry, missed the point about Unity content. I'll add @DuFF14 to the conversation because he is working on that plug-in.

[robsonswiss]

Thank you again Russel, I understand now how you do this with the HDK. Would you mind uploading a copy of the angles_to_config compiled utility?

[russell-taylor]

Here is a version that was compiled quite some time ago, but it should still work. You should also be able to build from source at https://github.com/OSVR/distortionizer/tree/master/angles_to_config

AnglesToConfig.zip

[robsonswiss]

Thanks again Russel, unfortunately the utility doesn't work, I ran the commands exactly as given here: https://github.com/OSVR/distortionizer/blob/master/angles_to_config/doc/anglesToConfig.md It just returns the options as if you typed "anglestoconfig /?"

[robsonswiss]

Sorry it also creates the json output but it's empty.

[russell-taylor]

Argh. Okay, I updated the code to work with the latest factoring of RenderManager and compiled a new executable:

AnglesToConfig.zip

This works for me with the example .txt file for the HDK 1.3 and the command-line options specified in https://github.com/OSVR/distortionizer/blob/master/angles_to_config/doc/anglesToConfig.md

[russell-taylor]

Note that you need to hand-edit a server file to use this client config, and that the server/client mechanism is deprecated and hopefully soon to be replaced by a server json protocol that can transmit large enough descriptions that we include them in the server config file.

[robsonswiss]

Thank you again, it works!

[robsonswiss]

Hi Russel, I really don't see how it's working with the HDK2, I've tried all options, including the built in ones and the IPD doesn't change at all, it could be that because the eye relief on my headset is virtually 0, I need IPD adjusted to the measured value, I'm not really sure why I don't see anyone else complaining about this, I've ordered a set of OSVR lenses to try out as well. So we'll see if at 10mm eye relief it's still a problem.

I've found a workaround for OSVR native titles, I calculated IPD to be 64mm at a resolution of 2006x1200, When I put this as the display resolution in the OSVR config file I can actually get focus. My displays are spaced 1mm apart so the IPD at 2160 is 68.6mm. The problem though is that this resolution hack doesn't work with SteamVR.

[russell-taylor]

The COP offsets are not the same thing as IPD. They describe where the center of focus of the lens hits the screen. IPD affects the separation between the projection matrix locations in world space, and it is controlled by an optional parameter to the GetRenderInfo() call in RenderManager.

If you are having resolution issues in Extended mode, it may be because Windows is deciding the magnify the application on that display; you need to set display scaling to 100% to make this go away.

[robsonswiss]

Hi

I would like to apologize for the long reply so long. :)

You can't possibly work on the assumption that all lenses are aligned to the center of the displays and all people have their IPD's at the center of the lenses. My lenses are at 64mm and the displays are at 68.6mm, I believe the HDK 2 has a similar misalignment, yet in the config files COP is at 0.5. There is no clarity on what the virtual camera separation is in mm, at some stage you need to convert from pixels to mm, and as far as I know this isn't done, but I might be mistaken?

So if you have a 64mm IPD, the lenses are at 64mm, but the display is at 68.6mm, you get double vision beyond about 800mm, so you can only actually focus on objects close by and the eye strain is pretty bad on far away objects. What needs to happen is the user's actual IPD needs to be reflected completely, the virtual camera's separation needs to be set at IPD, the only setting currently can be used is the COP, which should be equal to the user's IPD if possible, and if not it should be less, but never more.

If we use the example of a user with a 60mm IPD, non-adjustable lens separation of 64mm and a display separation of 68.6mm, where should the COP be? If you wan't it at 64mm as I understand you are suggesting, then what mechanism is used to further adjust the display offset or virtual camera to match the user's IPD of 60mm? To be honest COP as implemented doesn't seem to serve a purpose (let's assume it actually worked in the available content), other than to align the lens to the display, which has no practical application, this information is not used to calculate the actual display position/size/offset etc. and is not used for the virtual camera separation either for the same reason.

I'm using a workaround because I am unable to get COP figures to be accepted and from what I can tell there is no IPD adjustment in the OSVR system, the display setup for 100% scaling, the display is set for 2160x1200 resolution inside windows, however in the OSVR config file I've changed the resolution to 2006x1200, from my calculations in my headset this is at 64mm. I can use OSVR titles without double vision, in showdown I can focus on the robot in the distance, try that with the standard HDK 2 and config file and you will see double vision on the objects far away.