another possibility is to threshold changes in the transformation
matrix every frame -- if changes are < threshold value, don't update
that value.
curious, how are you tweening the matrix results, are you just
individually tweening each value in the matrix?
Doing all these interpolations and so are are just one form of filter
or another; they don't fix the problem, the just trade it off for
other problems (latency, sloshiness, most likely).
Here's what's going on (this is based on having fixed this in the
past, for non-Flash versions of ARToolkit and ARToolkitPlus).
The pose (position + orientation) of the marker, relative to the
camera, is computed based on the pixel coordinates of the 4 corners.
Those corners are determined from the thresholded image. The first
step in ARToolkit processing is to threshold the image and search for
blobs; then, 4 sided blobs are found; then, the pattern inside is
compared to known patterns (aside: the confidence value you get back,
that's been discussed before, is it's measure of how close it matches
the pattern -- if you accept low confidences, you will "detect" more
things that aren't markers).
Once the system has decided it's found a marker, if uses the pixel
locations of the four corners to determine the pose.
The problem, then, is that the corners are not determined very
accurately. If the threshold is not VERY close to correct, the
corners can be off by a few (or MORE!) pixels, since the blob will
bloom out or shrink in depending on how far off the threshold is.
If the corners are off by even 1 pixel, the orientation of the marker
will be wrong (draw some pictures to convince yourself of this,
especially if you move some in toward the center and some out from the
center; the resulting projections are very different).
The solution we used is to take the 2d pixel corners provided by the
ARToolkit, and feed them into a sub-pixel corner finder that operates
on the original color or greyscale image. We used openCV to do it
(cvFindCornerSubPix). I know that some folks have converted some of
OpenCV into AS3, so perhaps someone would be interested in trying it.
I'll be spending some time (finally!) with FLAR this summer, so
perhaps we'll port this in. But I wouldn't hold my breath waiting for
me! :)
type="cite">We found a solution that is working for us. We tween from one
Doing the marker finding on the greyscale image (to avoid the
innaccuracy introduced by threaholding) would be really expensive.
Sent from my iPhone