Forum Discussion
0.4.2 & x64 builds - OVRCamera stops working when lag occurs
This is a bit complicated to describe.
Effectively, I think the x64 driver restarts when the application is unresponsive for a moment. And because of that restart, it can't find the Rift.
In Darkfield, we load a new level asynchronously when joining/creating a server. This causes the game to freeze for second, sicne the enabling of the colliders happens in Unity's main thread. This does not cause any problems in the editor or x86 builds, but it disables the OVRCamera in x64 builds. I remember seeing an error message in the lines of "nullpointer in ovrdevice.GetTrackingState".
This does not happen in 0.4.1 either.
Effectively, I think the x64 driver restarts when the application is unresponsive for a moment. And because of that restart, it can't find the Rift.
In Darkfield, we load a new level asynchronously when joining/creating a server. This causes the game to freeze for second, sicne the enabling of the colliders happens in Unity's main thread. This does not cause any problems in the editor or x86 builds, but it disables the OVRCamera in x64 builds. I remember seeing an error message in the lines of "nullpointer in ovrdevice.GetTrackingState".
This does not happen in 0.4.1 either.
6 Replies
Replies have been turned off for this discussion
"skyworxx" wrote:
I remember seeing an error message in the lines of "nullpointer in ovrdevice.GetTrackingState".
You mean OVRDevice.HMD.GetTrackingState()? That wouldn't happen in our code because we check if OVRDevice.HMD is null before trying to use it. Can you send output_log.txt from a run with the issue?"vrdaveb" wrote:
"skyworxx" wrote:
I remember seeing an error message in the lines of "nullpointer in ovrdevice.GetTrackingState".
You mean OVRDevice.HMD.GetTrackingState()? That wouldn't happen in our code because we check if OVRDevice.HMD is null before trying to use it. Can you send output_log.txt from a run with the issue?
I see the same error here, only shows up in 64-bit builds. The error is deeper than from GetTrackingState() itself though. More details can be found in my post here.- I noticed with SDK 0.4.2 and Unity 4.5.0 and 4.5.3f3 that when I made an x64 build my game would load, head tracking would work, but the game was essentially frozen in all other ways.
I didn't notice any error messages - I haven't seen these issues, but they could be related to some recent changes we made in our memory layout on x64. I'll do some more testing there and make sure the assumptions line up between OVRService and the Unity plugin. For now, I would recommend sticking with x86.
- Sorry for the late reply.
"drash" wrote:
"vrdaveb" wrote:
"skyworxx" wrote:
I remember seeing an error message in the lines of "nullpointer in ovrdevice.GetTrackingState".
You mean OVRDevice.HMD.GetTrackingState()? That wouldn't happen in our code because we check if OVRDevice.HMD is null before trying to use it. Can you send output_log.txt from a run with the issue?
I see the same error here, only shows up in 64-bit builds. The error is deeper than from GetTrackingState() itself though. More details can be found in my post here.
Yes! This is the same error"vrdaveb" wrote:
For now, I would recommend sticking with x86.
I were not able to get rid fo the "screen 50% dimmed" bug in my x86 builds.
Right now, 0.4.2 is just not an option for me. Either I have a dark screen (even manually disabling timewarp did not help, it had to be toggled from on to off) or my cameras stop working. "molton" wrote:
I noticed with SDK 0.4.2 and Unity 4.5.0 and 4.5.3f3 that when I made an x64 build my game would load, head tracking would work, but the game was essentially frozen in all other ways.
I didn't notice any error messages
Found this today as well. x86 works great, x86_64 builds have no head tracking."vrdaveb" wrote:
I haven't seen these issues, but they could be related to some recent changes we made in our memory layout on x64. I'll do some more testing there and make sure the assumptions line up between OVRService and the Unity plugin. For now, I would recommend sticking with x86.
Will do!
