Head offset

Glad I am not the only one that feels this way. It is really frustrating having to dive into the oculus plugin and delete/rewrite swathes of code when it should be simple to just get the vector and quaternion then do whatever you want with it. Such a shame that Oculus entirely ignores everyone who suggests this, and has ignored them since the very beginning.

"KrisRedbeard" wrote:
G'day,

DK2 arrived and I have been mucking around with it and the latest UE4 binary build and have come across a little problem - the head offset.

At the moment, impossible to aim correctly while wearing a Rift. Its offsets the location of the camera after it has been adjusted in-game to line up with the weapon sights correctly.

In earlier versions of the Oculus Plugin, you could control the head offset via a config variable:

[Oculus.Settings]
HeadModel_v2=(X=0.0,Y=0,Z=0.0)

In the latest version, this is no longer the case.
Needless to say, this is very frustrating.

This has been mentioned before, but I'll say it too - I don't want anything to be done automatically for me.

Please give game developers the control needed to make the best possible experiences.

Thank you.

Holy crap I couldn't figure out why this was messing up my aiming all day. So really there hasn't been any response on this since that previous post?

Been a bit too busy in other areas to check the progress of this until today.
Its been over a month and UE4 has been updated to version 4.5, yet the situation remains the same :(

OK, can you let me know specifically what you would like or how you would like it to work?

I can share your feedback with the team. Thanks.

"cybereality" wrote:
OK, can you let me know specifically what you would like or how you would like it to work?

I can share your feedback with the team. Thanks.

Blackfang pretty much summed it up already:
"... give us a quaternion, a vector, and make the game render in stereo with HMD warp and chromatic aberration correction."

The plugin should:

• Give us access to the orientation & position offset without adjustments for sex/height/skull or other factor.


• Handle rendering.


• Give us access to the player height defined in Oculus Rift profile.

It would be nice if it would adjust the canvas as well, but given that should really be placed on a plane in front of a camera, its not necessary.

Hopefully Blackfang will chime in on this, as he mentions having adjusted the plugin to suit his own needs earlier.

Thank you cyberreality!

My adjusting the plugin mostly consisted of gutting all the code out of the functions, then redoing it from scratch. Heres a basic list of what I think it should do, from the perspective of somebody that thinks true first person setups are the way to go in VR.

The plugin should have the following values.

A quaternion representing orientation relative to its zeroed orientation.

A vector representing the position of the rift in relation to the position it was zeroed in, in the coordinate space of the zero orientation, preferably in cm, but mm are fine; just make sure it is specified in a comment somewhere in the code.

A quaternion representing orientation of the HMD relative to the head tracker.

A vector representing position of the HMD relative to the tracker. (These last 2 may be useful for something like "Soccer Goalie Simulator" or the like)

Motion prediction versions of the above values.

A bool indicating if the tracker can currently see the HMD.

A vector of the last know position of the rift relation to the position it was zeroed in, in the coordinate space of the zero orientation.

A vector of the last know position of the rift relative to the tracker.

The plugin should contain functions for the retrieval of these values. The plugin should NOT, under any circumstance attempt to automatically apply these values to ANYTHING.

The plugin should contain functions for the retrieval of values from the player profile. Player profiles should contain, if they don't already, measurements from the location of the rift when worn to the joint between the skull and c1 vertebrae, as well as player height. These values can be retrieved by developers and used at their discretion.

The plugin should automatically launch the game in stereo and correct chromatic aberration. It should turn on the tracker and start receiving data. The plugin should NEVER, ever, under any circumstance attempt to adjust or override the position or location of player cameras. (I weld these to the head bone of the player character then use data from the rift to drive animations that ensure the location and orientation of the player and character's heads match.)

As long as you supply good documentation and give an example code template, there will be no need whatsoever for any of the "automagic (but only if generic fps)" stuff going on in the plugin.

"KrisRedbeard" wrote:

"cybereality" wrote:
OK, can you let me know specifically what you would like or how you would like it to work?

I can share your feedback with the team. Thanks.

Give us access to the player height defined in Oculus Rift profile.

Thank you cyberreality!

+1 for this.

I really need the height to be able to correctly map the player's physical height/scale to a character's (e.g., so that Hydra positions can be 1:1 for instance). In general being able to change the character's height based on the player's would be really useful.

Yes, I use height to scale my Hydra data as well. Right now I use a set value that matches me, but it needs to be able to retrieve this from the profile. Palm to wrist distances and eyes to neck distances would also be very useful, as these devices don't attach directly at the joint they need their motion mapped to.

I agree with a lot of these suggestions.

I would just like to add that it would be nice to have access to the raw accelerometer data if needed so we can detect a specific category of gestures such as when a user taps their rift the impact of which may be filtered out in the position data we get.

Decoupling of the rift and the pawn control rotation absolutely key and done in probably 90% of the projects. It trivial to add this rotation if needed, but the inverse is trickier and it is not possible to cleanly remove it with blueprints only. This decoupling should be the standard.

Well, nearly a month later and no follow up by Oculus on this thread. I'm not surprised. They acted very similarly when we had to beg them to fix Oculus UDK.

Accelerometer data sounds like a good idea. Tapping the rift to activate something akin to Samus' Xray visor would be cool, or to open menu/inventory. That type of interaction could really add to immersion. It could even be something mundane like adjusting your character's glasses.

Overall, these aren't large demands by any standard. We are actually asking for them to remove more code than add, which could mean less code maintenance to do between UE4 versions.