For those of you who are still interested in my free marker-based flash AR tracker, I updated qtrack to v1.0. There were actually only few minor changes, however. 1st, I changed detector code to avoid v0.9 marching squares bug; interesting side effect of this change is that now literally anything that remotely resebles a quad can be used for the marker (like those examples on the right). 2nd, I added requested option to track the marker in NetStream-ed video. 3rd, there is new makePlaneTransform method that should help you with molehill setup (but no molehill demo included for now). 4th, some minor stuff you wouldn’t care about.
On a related note, back in December I promised to make Alternativa3D AR video tutorial for russian xmas, that would include qtrack and other trackers available through FLARManager. I did not finish that video in time, so for this post I uploaded qtrack part only (and chances are that FLARManager part will be only available in text version of tutorial). The video is in russian, but you can try english subtitles. Enjoy:
Coding on acid. 
Now who wouldn’t be interested? :) GREAT job, I love it, although it’s a bit unstable, meaning the model is “jittering” a little bit. Not a dealbreaker for me though :). Is there a way to use multiple markers?
QuadTracker tracks single marker. In theory you could write your own tracker class using QuadDetector.
very interesting project! Could you upload the code to github or so, so we could track the development a bit better! Keep up the good work!
Hey Makc
Thank you very much for providing qtrack for us to play with – its been my first real experience with AR and it just works.
I have a few questions regarding a couple of projects i am working on for the ios platform.
I have a very simple alternativa object consisting of just two cylinders, and when i set modelContainer.matrix = tracker.getPose3D(); this seems to work just fine for rotating the model. But moving the marker in x, y or z hardly has any impact and when i trace tracker.getPose3D().position.x it only goes from -7 to 7 when the marker on the screen is moving several hundred pixels. Can you help me explain that?
sorry, but unless you’re moving your model way back somewhere else in your code (for example by setting .z = 1234), I can’t explain this. -7 to 7 is fine as long as it is close to camera, so when it is projected to 2d, you should get your “several hundred pixels”.
Hey Makc
Happy new year. Thx for getting back to me so soon. It seems the problem lies in my collada model – the 3ds version works perfectly??? So i’ll just work with the 3ds version for now.
My second issue is: i would like to cover the marker (in the video) with a movieclip i have setup with an image. have you got any pointers as to how i could acheive that?
Using something like this.
Hey makc3d
Thanks for the link – it seems about right – messing with it right now. I am going to ask you another question – just tell me to shut up if its too much.
I am seeing a fair bit of jittering. Do you have any ideas how I can dampen that? I have been thinking about two ways – one is using tweenmax to tween the values of the getPose3d() matrix3d – the other is just keeping track of one or two key aspects of the getPose3d() and then just skip rendering if the value is not in line with previous values. I am going to try this last one out shortly. Any help is greatly appreciated. thx
Sorry I dont have good solution for jitter. Image trackers (such as in2ar or flare*nft) solve this by calculating the pose from hundreds of 2D points – as opposed to marker trackers (such as flartoolkit or qtrack) that use only 4 points. So – yes – camera noise kicks in. You’re free to apply some easing to the pose, just remember that any easing comes bundled with lags.
Hi Makc – i solved the worst of the jittering by applying the averaging of the last 10 rotation values and skipping over frames that are two far away from the average. Very low key hack – but very nice results. Its running pretty smoothly on my ipad as an air app. – ill do a video of it as soon as i have a little spare time.
One more thing, you should get less jitter if you provide actual camera focal length rather than just using random a-priori value. Unfortunately, I didn’t make any tool to measure that value, either :P
thx – I tried a range of different values and just stuck to the best.