Forum Discussion
Proper way to determine out of IR camera range?
I looked all over and didn't see a way to even simply query whether the player is out of range or not.
I see in OVRVisionGuide that the position of the player (relative to where the orientation/position was last reset) is checked against the bounds of a cube of a particular size, and then it figures out from that whether to display a "out of range" message and how much to fade out. The problem with this is that the camera's tracking volume is not a cube so it may warn the player prematurely or too late depending on how close to the camera the player is. Plus, the cube is based on the user's relative position so if the user reset his orientation/position near the edge of the actual tracking volume, the cube becomes even more ineffective as a warning.
OVRDevice.IsCameraTracking() appears to always return true (and probably simply means the blue light is on).
So... unless I missed something, I don't see a way (in Unity) to accurately determine whether the player is out of range (or even close to being out of range).
I have a way to guesstimate at the bounds of the tracking volume frustum, but this assumes that the camera is straight ahead and aimed straight at the player at startup. As soon as the camera is repositioned to the side or up or down or aimed anything other than straight at the player, this frustum becomes incorrect and thus ineffective as a warning to the player.
In the Configuration Utility's demo scene, there is a Camera Bounds feature that shows the tracking volume that I'm interested in. Anyone know of a way to access that information from the Unity integration?
I see in OVRVisionGuide that the position of the player (relative to where the orientation/position was last reset) is checked against the bounds of a cube of a particular size, and then it figures out from that whether to display a "out of range" message and how much to fade out. The problem with this is that the camera's tracking volume is not a cube so it may warn the player prematurely or too late depending on how close to the camera the player is. Plus, the cube is based on the user's relative position so if the user reset his orientation/position near the edge of the actual tracking volume, the cube becomes even more ineffective as a warning.
OVRDevice.IsCameraTracking() appears to always return true (and probably simply means the blue light is on).
So... unless I missed something, I don't see a way (in Unity) to accurately determine whether the player is out of range (or even close to being out of range).
I have a way to guesstimate at the bounds of the tracking volume frustum, but this assumes that the camera is straight ahead and aimed straight at the player at startup. As soon as the camera is repositioned to the side or up or down or aimed anything other than straight at the player, this frustum becomes incorrect and thus ineffective as a warning to the player.
In the Configuration Utility's demo scene, there is a Camera Bounds feature that shows the tracking volume that I'm interested in. Anyone know of a way to access that information from the Unity integration?
8 Replies
Replies have been turned off for this discussion
- Check the Tuscany code. It puts a message when tracking is gained or lost so you can follow that code path.
"brantlew" wrote:
Check the Tuscany code. It puts a message when tracking is gained or lost so you can follow that code path.
That is actually what I was referring to when I talked about OVRVisionGuide code. It's just comparing the relative position against the bounds of an arbitrarily-sized cube, which I believe falls short of what I'm looking for."drash" wrote:
"brantlew" wrote:
Check the Tuscany code. It puts a message when tracking is gained or lost so you can follow that code path.
That is actually what I was referring to when I talked about OVRVisionGuide code. It's just comparing the relative position against the bounds of an arbitrarily-sized cube, which I believe falls short of what I'm looking for.
Is there no way to get the HMDs position/orientation relative to the cams position/orientation so you can set the bounds yourself?
I have not yet had a look, but is the tracking volume represented by a cube? That sounds weird.
A real "found tracking info" or "no tracking info" would be good, even better would be some sort of reliability information that goes from 100% to 0% depending on what the prediction of reliability on the tracking info is. So that you can smoothly warn the player that he is nearing the edge of good tracking (be it through leaving the tracking area or rotating the HMD away from the cam occluding the LEDs).- You can turn on a wire frame box of the tracking zone in the little positional tracking test Oculus provides. Might be useful to be able to turn that on an off with a keystroke during all VR applications so you can check that your chair is still in the right place. Could also turn it on automatically when you approach the edges so users can avoid position freezes and readjust there seat.
Perhaps we should push for a standard convention that escape key pauses the simulation and makes a wire frame of the position tracking volume visible in all VR applications. - I found the absolute values to be pretty consistent just use those. I think they're referenced in some commented out debugging lines in the vision guide.
"drash" wrote:
"brantlew" wrote:
Check the Tuscany code. It puts a message when tracking is gained or lost so you can follow that code path.
That is actually what I was referring to when I talked about OVRVisionGuide code. It's just comparing the relative position against the bounds of an arbitrarily-sized cube, which I believe falls short of what I'm looking for.
They kicked us all out of the office this weekend as we are moving to a different floor. But I'll post some code next week that can help with this. Well - at least I'll post the C code. Not sure if that all the capabilities made it through into the Unity integration yet."brantlew" wrote:
They kicked us all out of the office this weekend as we are moving to a different floor. But I'll post some code next week that can help with this. Well - at least I'll post the C code. Not sure if that all the capabilities made it through into the Unity integration yet.
I appreciate that! Insert Good-Guy-Oculus-Employee meme here.- Digging into this some more, I ran across some camera frustum info in the Unity integration tucked away in OVRDevice.HMD.GetDesc(), but I'm not sure how you can determine the origin or the angle at which the camera is pointed (relative to the HMD, at least).
