Posts Tagged 'FLARToolKit'

Meet qtrack

It stands for “quadrilateral tracker”, little pet project I have been sporadically working on since october. I should have given it more love, but I didn’t want this post to drag into next year, so here goes “version 0.9”:

After December 7th, qtrack is the only free, as in “free beer”, flash 3D AR tracker. Curious why? There are many reasons for that. For one, most of its code is already available for free elsewhere on the web. But another, more important reason is that I just don’t see enough flash AR around, and setting this thing free is my modest contribution to spark some more creativity in the field :) I mean, when was the last time you actually saw flash AR game, huh?..

Any way, back to qtrack – it works similarly to famous FLARToolKit, except it is not that advanced and currently implements only single instance of single quad marker tracking. On the bright side, it is less restrictive regarding marker shape – all these markers could be tracked with qtrack, for example:

So, this is something you can try today. Zip file comes with two simple examples for Away Lite and Alternativa engines, and soon short video tutorial will follow. In January I will try to further improve qtrack in the areas where it currently have problems, and release stable version 1.0.


As I said, most of this thing is based on free code snippets published or inspired by various people. This includes blob detection (Tomek), homography (Zeh), marching squares (Sakri), Otsu thresholding (Andrew), automatic thresholding (some unknown guy), brilliant camera activity trick (Deepanjan). Even my complex numbers experiment found its way into this – I used it for pose estimation. So big thanks goes to all these people who have posted right things at right time for me to come across – without you qtrack would never happen!


Simplest FLARToolKit example ever?

FLARToolKit is said to be slow, but exactly how slow is it? To answer this question, I had to write the most simple bare bones FLARToolKit example ever :) It has neither trix to speed it up, nor complex 3D content to slow it down.

update: source updated to FLARToolKit svn head; it can work with 2.5.4 download if you remove param.setValue() call, line 48.

One wheel to drive them all

As soon as I had FLARToolKit+Unity3D test done, another idea stuck in my head: why not use original ARToolKit and some WinAPI magic together to control every game on the desktop. While that is perfectly possible, my C skills are too rusty to do that in 1 day, but – lo and behold – it is, nevertheless, done:

You can see here me using the same paper steering wheel and webcam to play Quake2, Midtown Madness and Tanki Online. Well, Quake2 was overreacting, Midtown Madness was laggy as hell, and in Tanki Online I was stuck into wall every minute or so, but I consider this test successful (for a PoC :)

Continue reading ‘One wheel to drive them all’

Unity3D and FLARToolKit steering wheel test

Now that there is free windows version of unity3d, everyone has to try it out. Inspired by this experiment, and having ready FLARToolKit steering wheel code from one of recent projects, I did this:

I’m not exactly the best modeller in the world, and I still suck at unity scripting, but I still think this is pretty good demo, so go ahead and give it a try :) Print this marker sheet beforehand. Continue reading ‘Unity3D and FLARToolKit steering wheel test’

Augmented reality and QR codes

This is basically proof-of-concept that this is already possible in flash, today. What you do is take saqoosha’s FLARToolKit, add keno’s QR code reader, and load results into 3d engine (in this case, kiroukou’s sandy).

Clicky to see PoC

It doesn’t require webcam, just click to upload your test image. It also makes use of saqoosha’s PixelBender homography transform filter, since keno’s reader apparently doesn’t do that on its own (and generally is very sensitive to input bitmap, I must add). Default image comes from here.

Alternative to adaptive thresholding

As cool as it is, adaptive thresholding generates too much redundant data. The only alternative implemented before seems to be the method called automatic thresholding, suggested by ARToolKitPlus folks:

ARToolKitPlus can do dynamic thresholding by looking at the marker content (pattern) and taking the average between the darkest and brightest pixels. If no marker is found the threshold value is randomized.

From this description alone, it is clear that there will be frames with marker undetected even though it is clearly visible in the image, so I thought, until now, that this method has to be quite bad. It turns out, however, that this method actually works very well and the number of lost frames is very small. In practice, you don’t even have to find pixel values range, it suffices to assume that current good threshold value lies close to last known one.

On code side, you no longer need to write or import some fancy filter classes, all you have to do is to modify your fixed thresholding main loop just a bit:

private var threshold:Number = 0.5;
private var confidence:Number = 0, confidenceThreshold:Number = 0.5;
private function onEnterFrame (e:Event):void {
	videoSnapshot.draw (video);

	if (confidence < confidenceThreshold) {
		// randomize threshold
		threshold *= 0.8;
		threshold += 0.2 * Math.random ();

	confidence = 0;
	if (detector.detectMarkerLite (raster, 255 * threshold)) {
		confidence = detector.getConfidence ();

		detector.getTransformMatrix (result);
		stuff.setTransformMatrix (result);

	scene.render ();

If you’re sandy fan, you can play with this method using this stub code.

FLARToolKit adaptive filter experiment sources

For those who asked about sources of my little experiment from last week, here they are. Make sure you are using FLARToolKit revision 2570 with these.

If you wasnt reading FLARToolKit mailing list, here is short summary: FLARToolKit converts color image to “binary” image before doing any magic on it, using fixed threshold filter. In fact, this threshold is simply hard-coded to be 80 in many examples, and you will need to write more code to detect good values for threshold if you want your application to run regardless of lighting settings. The filter in this experiment avoids the problem by using local average brightness as a threshold for every pixel; the downside is that it enables FLARToolKit to “see” far more details, thus wasting even more CPU time. As a work-around, I tried to narrow down search area in the image using last detected square, but this only helps when marker motion is limited.

Well, check it out, play with it, and let me know what you think.

Old stuff

September 2018
« Jan    

Oh, btw…