Position tracking - where is the target point?

It should be relative to the position tracking camera (when it's visible), but the origin is based off of the last time the position tracking was reset via the ovrHmd_RecenterPose() call.

One should also mention: Without calling ovrHmd_RecenterPose(), the Rift always initializes with the origin of the tracking coordinate system exactly 1 meter in front of the camera. As soon as you call ovrHmd_RecenterPose(), the current tracking position will become the new origin and the viewing direction will by the new y-axis.

@cyber: By the way, I wanted to suggest the following for a while. Imho it would be much better to add another version of ovrHmd_RecenterPose(), which allows to specify an arbitrary origin and yaw manually. In many applications (*) it would be preferable to store the last known "recenter pose", and re-load it on start up. Currently it is not possible to use ovrHmd_RecenterPose(), since it only allows to set the origin to the _current_ position, and not any other stored position.

As far as I can see, the only possibility to persist the tracking orientation with the current design is to never use ovrHmd_RecenterPose() at all. What I do instead is to always stick with the initial tracking coordinate system and subtract the "recenter position" manually.

(*) Use case: In a simulator cockpit, a user may spend a lot of time recentering the Rift so that the phyiscal and virtual input devices line up perfectly. Currently this has to be done again every time, since most applications do not care about persisting the tracking origin. If this would be implemented in the SDK, we would probably see this feature much more often.

Yes, I've been thinking we needed that feature for a while. Let me see what I can do.

@bluenote, @cyber - so ovrHmd_RecenterPose() will change the tracking *origin* from the default, but I still wonder what point on the headset is the tracking target. Is it the center of front face of the headset or is it "behind" the eyes, close to where the center of a user's actual head would be, or somewhere else?

then you mean the origine point of the vector not the target (opposite).
since the rift utility allows you to specify some measurement of the head's viewer, i hope this means there is some use done for these measurement to place the origin somewhere behind the eyes. (or the camera)
that is commonly called the nodal point (while purists will reject this) and it is used to avoid parallax problem when rotating the camera

@nosys70 - so you mean HeadPose.ThePose.Position is the coordinates of this "nodal point" (relative to the tracking origin). Do you know where the nodal point is relative to the headset itself?

Ok, so am i right to say the HeadPose.ThePose.Position is the point between the two eye nodal points ?

And since i also get data in this field with my DevKit1 : Is the Position for the DK1 estimated using "average head size" or something like that ?

"bluenote" wrote:
One should also mention: Without calling ovrHmd_RecenterPose(), the Rift always initializes with the origin of the tracking coordinate system exactly 1 meter in front of the camera.

This is a bug that only occurs if you call ovrHmd_ConfigureTracking too quickly after some other function. If you put a 200 ms sleep in front of ovrHmd_ConfigureTracking it won't happen. I reported it here somewhere, but I can't be bothered to find the thread right now.

"jherico" wrote:

This is a bug that only occurs if you call ovrHmd_ConfigureTracking too quickly after some other function. If you put a 200 ms sleep in front of ovrHmd_ConfigureTracking it won't happen. I reported it here somewhere, but I can't be bothered to find the thread right now.

In this case I suggest to turn it into a feature. In my opinion it makes perfect sense to initialize the tracking with a well-defined absolute coordinate system (for instance because it enables my solution to persisting tracking state -- maybe there are even use cases that require absolute tracking position in general). If a developer wants to initialize using the current position/yaw as origin, they can simply call ovrHmd_ResetPose immediately after ovrHmd_ConfigureTracking to emulate the current behavior.

"bluenote" wrote:

maybe there are even use cases that require absolute tracking position in general

Yes! This is exactly what I'd like. For instance, I'd like to know the precise position of some point on the front of the headset relative to the IR camera.