Is it unreasonable to try solving for the modelview transforms of 4 (of 
6 possible) marker tiles in a 640x480 mono frame and still maintain 30 
fps?  Is the toolkit multi-threaded and able to take advantage of the 
new multi-core chips?  Any thoughts on hardware to achieve the above? 
We'll definitely be using a dual-core (or dual processor) machine with 
the graphics running in a separate thread.

Cheers,
Darran.


-- 
Darran Edmundson [darran@e ............]
Interactive visualization for museums and industry
http://www.edmstudio.com

As we showed in our recent ARToolKitPlus publication
(http://www.icg.tu-graz.ac.at/Members/daniel/Publications/ARToolKitPlus),
the tracking speed of ARToolKitPlus (and the same goes for ARToolKit on
the PC) is usually more than fast enough on modern PCs, even with many
markers visible.

E.g. on a 2 GHz Core Duo (only a single core was used) for a
multi-marker with 4 visible markers, a PC requires 2.7ms or 6.2ms
(depends on the compiler used). For a similar setup with 10 visible
markers it is still just 8.3ms or 17.5ms (again different compilers...).
More details can be found in that paper. So, if you target a framerate
of 30fps then even for the 10 marker case this is just about 25% of your
processing performance of a single core...

Phil is right that with many markers know and/or visible to the system
the performance will drop considerably when using template markers (with
N visible and M known markers, N*M*4 template matches have to be
performed). For such a case use Id-markers (which only require only N
tests, each faster than a template match) which are supported by
ARToolKitPlus and the commercial version of ARToolKit.

Both ARToolKit and ARToolKitPlus are currently single-threaded. While it
would be quite simple making parts of them multi-threaded (e.g. the
labeling or the pose estimation parts) there is currently no real reason
to do so: Tracking is only a small part of a practical AR application
(camera reading, rendering, networking, GUI, application overhead, etc.).

Daniel

Daniel Wagner wrote:
> As we showed in our recent ARToolKitPlus publication
> (http://www.icg.tu-graz.ac.at/Members/daniel/Publications/ARToolKitPlus),
> the tracking speed of ARToolKitPlus (and the same goes for ARToolKit on
> the PC) is usually more than fast enough on modern PCs, even with many
> markers visible.

I'm using 5-8 marker tracking on the Nokia 6600 cellular phone with 
109Mhz ARM CPU without floating point, with 8 frames per second. I'm not 
using ARToolkit though, but my own highly-optimized ARM-friendly fixed 
point tracker with barcode marker ID. Any semi-modern CPU 800+ Mhz more 
than enough for tracking dozens of markers.

Darran,

I've also replied to you off-list, but this is no problem for almost  
any machine. Over about 10 markers, using 2D barcode (ID-based  
markers) rather than the standard markers improves performance a lot.

ARToolKit v2.x is not multi-threaded, and will probably not be any  
time soon. The performance bottlenecks usually lie elsewhere in the  
system.

Cheers,
Phil.

On 20/02/2007, at 4:12 PM, Darran Edmundson wrote:

>
> Is it unreasonable to try solving for the modelview transforms of 4  
> (of 6 possible) marker tiles in a 640x480 mono frame and still  
> maintain 30 fps?  Is the toolkit multi-threaded and able to take  
> advantage of the new multi-core chips?  Any thoughts on hardware to  
> achieve the above? We'll definitely be using a dual-core (or dual  
> processor) machine with the graphics running in a separate thread.