Hello Anna,
Your interpretation of the ARToolkit matrix is correct. Since the
location of the markers are described in camera co-ordinates (the centre
of the screen is zero X, zero Y), any movement to the camera will change
the relative position of the markers. The virtual camera doesn't move
with the real-camera, it's the marker positions that change.
This should be useful:
http://www.hitl.washington.edu/artoolkit/documentation/tutorialcamera.ht
m
In the example where it looks like the object is stationary, and the
virtual camera is moving, the matrix has been inverted.
Hope that's helpful.
Matthew
-----Original Message-----
From: owner-artoolkit@h ..................
[mailto:owner-artoolkit@h ..................] On Behalf Of Anna Callahan
Sent: 16 May 2006 16:54
To: artoolkit@h ..................
Subject: What is makeup of AR's config matrix?
Hi all,
We are using ARToolkit/ARToolkitPlus to get camera pose data in 6 axes -
x, y, z positions and x, y, z rotations. We use multiple markers and=20
call arMultiGetTransMat to get a config matrix. (We now use=20
ARTooKitPlus, but the calls are essentially the same.) My understanding
of ARToolkit's config matrix is that it looks (very basically) like
this:
[ R R R Tx ]
[ R R R Ty ]
[ R R R Tz ]
So we get our x, y, and z positions from that last column thus:
posX =3D ( config[0][3] );
posY =3D ( config[1][3] ); =20
posZ =3D ( config[2][3] );
But we are definitely getting strange data from that matrix. When I=20
rotate the camera about an axis only, the positional values also=20
change. (For example, rotating about the Y axis causes large changes in
both posX and posZ.) This must mean that the last column is not the=20
pure translational values, unless I'm missing something. Can anyone=20
tell me the makeup of AR's internal config matrix, or point me to a web=20
page with that info?
Thanks,
Anna
This message is intended for the addressee(s) only and should not be read=
, copied or disclosed to anyone else outwith the University without the p=
ermission of the sender.
It is your responsibility to ensure that this message and any attachments=
=20are scanned for viruses or other defects. Napier University does not a=
ccept liability for any loss
or damage which may result from this email or any attachment, or for erro=
rs or omissions arising after it was sent. Email is not a secure medium. =
Email entering the=20
University's system is subject to routine monitoring and filtering by the=
=20University.=20
|