Based on the intrinsic camera calibration of the specific device (coming from the device profile) we create a GL projection matrix with the following coordinate frame:
The camera sits at <0,0,0> and points into the positive z-direction; x-direction is to the right and y-direction is down-wards. Hence, we have a right handed coordinate system. This is not how OpenGL does it per default, but since it is just matrix math, we can do whatever we want here.
The reason why we use this coordinate frame is, because it is the same as for targets - just rotated by 90 degrees around the x-axis (for targets x-direction is to the right, y-direction is upwards in the target plane and z-direction points out of the target-plane).
The effect is the following:
Assume that the projection matrix is setup using the QCAR tool function, the modelview matrix is set to identity (normally one would use the modelview matrix to move the object with respect to the camera) and clipping is setup accordingly (e.g. from 0.1 to 20).
- An object with coordinate <0,0,1> will show up in the middle of the viewport (being one scene unit away from the camera center).
- If we put the object to <0,0,2> then it will still be in the middle of the viewport but at half the size as before.
- If we move the object to <1,0,1> then it moves to the right of the viewport center.
- If we move the object to <0,1,1> then it moves to lower than the viewport center.
Since the QCAR API gives the developer access to the intrinsic camera calibration, the developer can of course also build his own GL projection matrix if he prefers to do so. This can be handy if he uses an existing rendering solution that enforces a different convention. Of course, one has to then also convert the QCAR pose data to GL modelview matrices a bit differently. We defined the convention described above, but nobody is forced to use it! For more info on building the projection matrix from the camera parameters see this article: CameraParameters.xml