Skip to main content
artyom17
Up and Coming
January 4, 2015

Experimental changes in VR camera control

Happy New Year to everybody, btw!

Ok, the first cut is in GitHub:
https://github.com/Oculus-VR/UnrealEngine/tree/4.7-np

This is 4.7-preview with re-factored plugin and improved (I hope) camera control. I haven't added new Blueprint functions yet (like raw accel data or player's metrics, still in work). I am going to document all the changes (documentation is long due anyway)...

So, briefly. I've added PlayerController.bFollowHmd property, which is by default set to 'true' (for compatibility reasons). When it is set in 'true' then the behavior is the same as it was before: HMD drives PlayerController. You can either set it to 'false' or just don't bother, it will be set to false automatically, once you use PlayerCameraManager or CameraComponent approach.

The main approach you guys care the most (I think) is to enable HMD via CameraComponent. This class now has two additional boolean properties - bFollowHmdOrientation and bFollowHmdPosition. In addition, the scale of the CameraComponent now will be a scale of the position change / ipd. The bigger scale is set, the smaller world is perceived. Camera's origin is located in-between eyes, i.e. IPD will be applied at the camera's origin, half of IPD in positive Y-axis direction and another half in negative Y-axis direction (in camera coordinate system).

Besides CameraComponent, the PlayerCameraManager also has boolean properties bFollowHmdOrientation and bFollowHmdPosition. Thus, any camera attached to this PlayerCameraManager via SetViewTarget method will follow the HMD orientation and/or position.

In addition, the HeadMountedDisplay::GetOrientationAndPosition method now has two additional boolean parameters: bUseOrienationForPlayerCamera and bUsePositionForPlayerCamera (by default - both a set to 'false'). Set these to true, if you use this method to get HMD orientation/position to change the camera orientation / position manually. This is necessary to correctly calculate delta orientation/position for timewarp later on a render thread. However, there is no way to specify the proper scale to position in this case (should I add one more parameter to this method? With default value vector(1,1,1)? Probably, will think about this.)

So, if you, guys, have a look on these changes and try them I'd be grateful. I'll meet with Epic Games guys later this month and we will discuss these changes (however, Epic may suggest different approaches, different names for function/parameters, etc), so these changes are not final in any sense. Your opinion will be very important and will be considered in that discussion.
    This topic has been closed for replies.

    49 replies

    Show previous replies
    hesham
    Up and Coming
    February 9, 2015
    I've mentioned this on the Unreal forums as well but I can't seem to get the GearVR plugin to work in the Oculus 4.7-np branch. I have all the Android dependencies, ran Setup.bat and GenerateProjectFiles.bat then compiled the Development and Development_Editor x64 targets but sadly there is no GearVR plugin like the Epic branch which does build and run on my Gear VR just is horribly broken (including on DK2).

    Any suggestions on how to proceed with testing or maybe a timeframe in which we can expect to test reasonably performing Gear VR support on Unreal would be very much appreciated :)

    The Epic branch seems to be majorly broken, to quote my issues from the other forum:
    The issue I'm having is that it seems that VR support is broken not just for Gear VR which is new and in progress, but even for the Rift DK2 in general. I've been playing with the sample FPS level and the issues I'm getting are objects popping in and out due to bad occlusion culling (they don't pop if I turn it off), shadows in the wrong places for each eye, ghosting of what looks like the shadow buffer being rendered as a ghost over the left eye, and settings that completely break rendering like the right eye not rendering at all if I don't have an active shadow volume for example.

    I figured I'd bring them up here but I'm sure fixes are in progress but it would be nice to get some more of the WIP fixes so we can provide real feedback on the GearVR support and get a head start on testing our projects

    Edit: Also, typing exit in the "VR Preview" console causes the editor to crash not to exit preview; hitting escape works fine and brings me back to the editor.
    Ibex 3D VR Desktop for the Oculus Rift: http://hwahba.com/ibex - https://bitbucket.org/druidsbane/ibex
    artyom17Author
    Up and Coming
    February 10, 2015
    It is questionable, is it better to use 4.7-np or not. It is experimental branch and 4.7 will be different at the moment of the release. There is also no guarantee that 4.8 will be exactly like 4.7-np. So, it is your choice.

    As to HMD SP: it is a known issue that ScreenPercentage setting does not work on mobile. Epic is aware of it.

    As to the second question, about making GearVR plugin to work: you must enable it in Windows -> Plugins window. There is also a known issue with rendering, you must turn off the 'Mobile HDR' option in the 'Rendering' project settings.

    Note, you should talk to Epic about any rendering issues in GearVR, they are still working on it.

    I'll check the crash with 'exit' and 'VR Preview', however, I remember I used it w/o issues before.
    hesham
    Up and Coming
    February 10, 2015
    "artyom17" wrote:
    As to the second question, about making GearVR plugin to work: you must enable it in Windows -> Plugins window. There is also a known issue with rendering, you must turn off the 'Mobile HDR' option in the 'Rendering' project settings.

    Interesting, I don't have that option on 4.7-np but I do have it on 4.7 from Epic. I'll try rebuilding again.
    Ibex 3D VR Desktop for the Oculus Rift: http://hwahba.com/ibex - https://bitbucket.org/druidsbane/ibex
    BlackFang
    Up and Coming
    February 11, 2015
    Unfortunately, I branched my branch off of your 4.7np branch which was branched off of a branch of Epic's 4.7 branch that had or perhaps still has broken physics. I'm still a github noob and was barely able to smush the Sixense integration for 4.6 into this version, so I'm wondering if anyone knows for sure whether or not this was fixed in Epic's branch yet, and how to apply that fix to my branching branch.

    EDIT: It would appear this was fixed in 4.7 preview 6, but I have no idea how to find those changes so I can integrate them into my branch.
    I complain a lot. Just think of me as a squeaky wheel lol. Youtube channel -> https://www.youtube.com/user/xblBlackFang/videos
    artyom17Author
    Up and Coming
    February 11, 2015
    "BlackFang" wrote:
    This version works much better than previous versions. The changes are very welcome. However, I still had to remove some lines that were clearing out the existing roll and pitch of my character when factoring character rotation into the camera rotation.


    Can you point out which lines exactly?
    artyom17Author
    Up and Coming
    February 11, 2015
    "BlackFang" wrote:
    EDIT: It would appear this was fixed in 4.7 preview 6, but I have no idea how to find those changes so I can integrate them into my branch.


    Let me sync 4.7-np to the latest 4.7 and you could get it from there.
    artyom17Author
    Up and Coming
    February 11, 2015
    Now 4.7-np should match the 4.7-preview 6.
    BlackFang
    Up and Coming
    February 11, 2015
    Wow, that was fast! I think the lines were around 606 in OculusRiftHMD.cpp. You might want to inclose them in an if statement and add a bool like, "bRespectRealGravity," or something of that sort.
    I complain a lot. Just think of me as a squeaky wheel lol. Youtube channel -> https://www.youtube.com/user/xblBlackFang/videos
    artyom17Author
    Up and Coming
    February 11, 2015
    "BlackFang" wrote:
    Wow, that was fast! I think the lines were around 606 in OculusRiftHMD.cpp. You might want to inclose them in an if statement and add a bool like, "bRespectRealGravity," or something of that sort.


    Those lines are within ApplyHmdRotation, which is there for backward compatibility with previous PlayerController behavior. Once you initialize FollowHmdOrientation/Position either in PlayerCameraManager or in a CameraComponent that method shouldn't be called (or, you can disable it by setting PlayerController.bFollowHmd to false).
    STW
    Up and Coming
    March 27, 2015
    I've noticed no one has posted in this thread in a while. Wondering if there are developments since...

    artyom, in the now 4.7 versions, is it possible for me to make it so the PlayerController follows the HMD position? I have a Leap motion controller attached to the current FirstPersonCamera, but when I physically move the position of the HMD (my body), the hands don't follow - they stick to the character rather than following the HMD view.

    I am assuming that this thread holds the answer, by having FollowHmdPosition initialized somehow. But reading through this, it seems like your github integration was for the Preview versions of 4.7? Or are they still relevant?

    Please help, I am really in need of this.
    Show more replies
    Terms & ConditionsAccessibility statement