Found Bug with VrHeadModel rotationOfHeadMatrix, rotation, and yawPitchRoll methods.
These methods will always return a rotation of [0,0,0] the very first time they are called regardless of the actual rotation.
They return the accurate rotation array any time after the first call.
Can you let me know when they were first called as I suspect the issue is that the values are not ready as opposed to return [0,0,0] on first call. We should expose the readiness state of the API
Here are the relevant parts of my code. I have a button in my main component. When clicked, it will console.log the rotation and yaw/pitch/roll arrays.
I added a call to the rotation and yawPitchRoll methods to the componentDidMount function of the main component. This way the initial calls that return the [0,0,0] arrays will happen immediately and any result from the button click will be accurate.
Originally, I did not have these methods in the componentDidMount function. This caused the very first button click to produce incorrect results.
componentDidMount(){
console.log('IN COMPONENTDIDMOUNT');
let currRot = VrHeadModel.rotation();
let currYPR = VrHeadModel.yawPitchRoll();
console.log('current rotation: ', currRot);
console.log('current yawPitchRoll: ', currYPR);
}
printLocation() {
let currRot = VrHeadModel.rotation();
let currYPR = VrHeadModel.yawPitchRoll();
console.log('current rotation: ', currRot);
console.log('current yawPitchRoll: ', currYPR);
}
render() {
return (
<VrButton onClick={() => this.printLocation()} style={{transform: [{translate: [0,0,-5]} ] }}>
<Text>{'print location'}</Text>
</VrButton>
)
}
Probably due to the fact that all events get ignored until the React code loads, at which point it is immediately initialized: any components rendered on the first React frame will execute before any events have been ingested to update this value.
Since native modules get initialized before the bundle, we could pass the initial orientation of the camera through that manner. However, this probably isn't going to have the desired effect, since the initial value is almost always zero, and any head-motion events that fire before the bundle finishes loading are going to be dropped on the floor. The code capable of interpreting the events is in the bundle itself, so it doesn't receive the early ones. It'd be difficult to inject the latest head position just after React loads, but before it initializes the first render pass.
With all that in mind, I don't believe it can be "fixed" as desired – there's no way to have data that is both up-to-date and also available just before your React code initializes. Instead, we should probably aim to be clearer to developers when we haven't received any head data yet, and make a breaking change in 2.0.0 that returns null from these methods when there is no known data yet. It's more honest, and developers can then build code around knowing whether the data is accurate/available or not.
Either way, I've been intending to clean up some of this code. I was running some Oculus Browser experiments over the weekend, and noticed a non-negligible amount of frame time being spent here on the runtime side.
Great to know, thanks for the info!
@alyssagaudioso I'd like to clarify one detail about your example. You gave an example of the a component, was this component created immediately from the root?
VrHeadModel is a helper module and a better structure for you might be to listen to the event directly, eg
this._headMatrixListener = RCTDeviceEventEmitter.addListener(
'onReceivedHeadMatrix',
onReceivedHeadMatrix
);
...
function onReceivedHeadMatrix(headMatrix, viewMatrix, fov, aspect) {
...
}
This will mean you will know when the first update has been received
I hope this will unblock you for now
Most helpful comment
Probably due to the fact that all events get ignored until the React code loads, at which point it is immediately initialized: any components rendered on the first React frame will execute before any events have been ingested to update this value.
Since native modules get initialized before the bundle, we could pass the initial orientation of the camera through that manner. However, this probably isn't going to have the desired effect, since the initial value is almost always zero, and any head-motion events that fire before the bundle finishes loading are going to be dropped on the floor. The code capable of interpreting the events is in the bundle itself, so it doesn't receive the early ones. It'd be difficult to inject the latest head position just after React loads, but before it initializes the first render pass.
With all that in mind, I don't believe it can be "fixed" as desired – there's no way to have data that is both up-to-date and also available just before your React code initializes. Instead, we should probably aim to be clearer to developers when we haven't received any head data yet, and make a breaking change in 2.0.0 that returns
nullfrom these methods when there is no known data yet. It's more honest, and developers can then build code around knowing whether the data is accurate/available or not.Either way, I've been intending to clean up some of this code. I was running some Oculus Browser experiments over the weekend, and noticed a non-negligible amount of frame time being spent here on the runtime side.