Some observations
Hi there! Just passing on my observations after spending a few days integrating the Rift into our game.
Observation one: the current Unity plugin implementation briefly threw me for a loop. I'm of the opinion that any controller or peripheral should try and follow Unity's input manager model as closely as possible, since that would make a proper integration much easier. The groundwork I had laid in preparation for integrating the Rift assumed I would be treating the Rift sensor data as controller input axes, polling the HMD for the orientation every frame, and in general just treating whatever Rift object/prefab was supplied as just a straightforward camera replacement. It took me a little while to figure it out, but I got it working in the end.
(We're using Mecanim and IK with a full body avatar system, and our entire motion control scheme was based around polling new peripherals for positional and/or rotational input and either applying those directly to the affected bones or using them to drive IK effectors. In this case, the expected implementation assumed that the HMD would only be supplying its look rotation and the skeletal IK would have taken care of orienting and positioning the cameras.)
Observation two: Rotational drift isn't that noticeable without an avatar body or a pair of hands in the scene, but once you have it hooked up to a body, you can see quite a bit of drift in the Y axis that accumulates over time. I have to hit the B button to reset it about once every couple of minutes. Any advice on minimizing or mitigating that would be welcome.
Observation three: Some visual elements that our art director loves are broken, like realtime shadows and skyboxes. Light cookies are also semi-broken. This...is not good. I really don't want to have to fork things all over the place to ensure that things look good on both monitors and the Rift, 'cause things are complicated enough as it is. Advice and any news of pending fixes/reworks are most welcome.
Observation four: Unity is...a bit awkward when it comes to trying to launch games on the Rift. Sometimes the "-adapter N" command line trick works, sometimes it doesn't, and I end up having to clone the Rift with my primary display to make it work reliably. This brought on a sudden attack of curiosity about how to handle this sort of issue on the user side of things--does anyone here have any practical tips for making Unity standalone builds play nice without having to explain to them how to screw around with their display settings and whatnot?
Observation five: With a full body avatar system, the lack of position tracking for the HMD becomes a noticeable issue at certain points in the game. In our case, the avatar's wearing a headlamp that's turned on by reaching up to your head and pulling the trigger on a Hydra controller, and sometimes the head/hand relationship isn't 1:1 at all. It's sort of dealable with, but it would be way better if it wasn't an issue in the first place. This isn't so much an Unity integration thing as much as something general that came up while I was integrating it, and I wanted to mention it before I forgot. So if there's anyplace where I can cast my vote for an add-on position tracker or to have positional tracking added to the consumer version, point me there so I can toss my 2 cents in. :)
Observation one: the current Unity plugin implementation briefly threw me for a loop. I'm of the opinion that any controller or peripheral should try and follow Unity's input manager model as closely as possible, since that would make a proper integration much easier. The groundwork I had laid in preparation for integrating the Rift assumed I would be treating the Rift sensor data as controller input axes, polling the HMD for the orientation every frame, and in general just treating whatever Rift object/prefab was supplied as just a straightforward camera replacement. It took me a little while to figure it out, but I got it working in the end.
(We're using Mecanim and IK with a full body avatar system, and our entire motion control scheme was based around polling new peripherals for positional and/or rotational input and either applying those directly to the affected bones or using them to drive IK effectors. In this case, the expected implementation assumed that the HMD would only be supplying its look rotation and the skeletal IK would have taken care of orienting and positioning the cameras.)
Observation two: Rotational drift isn't that noticeable without an avatar body or a pair of hands in the scene, but once you have it hooked up to a body, you can see quite a bit of drift in the Y axis that accumulates over time. I have to hit the B button to reset it about once every couple of minutes. Any advice on minimizing or mitigating that would be welcome.
Observation three: Some visual elements that our art director loves are broken, like realtime shadows and skyboxes. Light cookies are also semi-broken. This...is not good. I really don't want to have to fork things all over the place to ensure that things look good on both monitors and the Rift, 'cause things are complicated enough as it is. Advice and any news of pending fixes/reworks are most welcome.
Observation four: Unity is...a bit awkward when it comes to trying to launch games on the Rift. Sometimes the "-adapter N" command line trick works, sometimes it doesn't, and I end up having to clone the Rift with my primary display to make it work reliably. This brought on a sudden attack of curiosity about how to handle this sort of issue on the user side of things--does anyone here have any practical tips for making Unity standalone builds play nice without having to explain to them how to screw around with their display settings and whatnot?
Observation five: With a full body avatar system, the lack of position tracking for the HMD becomes a noticeable issue at certain points in the game. In our case, the avatar's wearing a headlamp that's turned on by reaching up to your head and pulling the trigger on a Hydra controller, and sometimes the head/hand relationship isn't 1:1 at all. It's sort of dealable with, but it would be way better if it wasn't an issue in the first place. This isn't so much an Unity integration thing as much as something general that came up while I was integrating it, and I wanted to mention it before I forgot. So if there's anyplace where I can cast my vote for an add-on position tracker or to have positional tracking added to the consumer version, point me there so I can toss my 2 cents in. :)