However, this means that getting flare*tracker and flare*NFT projects running requires a bit more work. As such, I’ve reverted the examples and tutorials to use FLARToolkit, which I can distribute along with FLARManager, and also created this page to describe, in-depth, how to implement the various tracking engines that FLARManager supports.

Please take a moment to download the latest version of FLARManager and the current evaluation SDKs for flare*tracker and flare*NFT to ensure you’re up-to-date. And feel free to pester me with questions (as comments, below) about setting up your projects — I need your help to get the documentation as clear as possible.

Hello folks. I’m happy to announce that FLARManager is finally all growed-up!

FLARManager v1.0 has been quite a while in the making, especially the movement from v0.7. This is due to a number of factors; one of these has been working out the final details, between ARToolworks and Imagination, of flare*tracker and flare*NFT integration, which i first previewed in this blog post. But the major factor is the amount of restructuring that has gone into FLARManager.

Why restructure? FLARManager is now able to work with any tracking library, just as it’s able to work with any 3D framework. And switching between tracking libraries is as simple as this:

 
FLARToolkit:
new FLARManager("flarConfig.xml", new FlarToolkitManager(), this.stage);
flare*tracker:
new FLARManager("flarConfig.xml", new FlareManager(), this.stage);
flare*NFT:
new FLARManager("flarConfig.xml", new FlareNFTManager(), this.stage);

 
Obviously, the freedom given to application developers, creatives, and agencies by natural feature-tracking is the biggest element of this release to be excited about. But the restructuring goes deeper — FLARManager can now function as a link between *any* tracking library and *any* 3D framework. Developers are no longer bound to decisions based on limited availability or documentation; they are free to choose the tools that work best for them. (Some Californian CEOs would do well to pursue similar goals.)

You can get FLARManager version 1.0 here.

So what else is new about v1.0? A quick rundown beyond the jump…

what’s new

[support for multiple tracking libraries]
As mentioned above, FLARManager has a new structure that grants it compatibility with any number of tracking libraries. Currently, support exists for flare*tracker, flare*NFT, and FLARToolkit (v2.5.4). The classes used to make the connection between FLARManager and these tracking libraries live in the flar.tracker package, and FLARManager should now be instantiated with one of these tracker managers as a parameter.

Note: if you’re using flare*tracker or flare*NFT, you must have the .lic license files in the same folder as your swfs. These files are included in the FLARManager distro, in the /bin-debug/ folder. These are evaluation versions of the flare* licenses, and tracking stops functioning after one minute. Also, you must include the flare* .swc files in the /libs/ folder in order to compile. If you see any errors referring to CLibInit, the flare* .swc files are not on your build path and are not getting compiled.

Stay tuned for support for more tracking libraries in the future…

[native flash 3D]
Thanks to nutsu of libspark, FLARManager finally supports output to native Flash 3D. This is particularly useful for applications that just want to display a plane over the detected target — no more need to map a texture to a plane in a 3D engine. Think images, video, swfs. In the palm of your users’ hands.

[full documentation]
All of the changes did not go undocumented. Full html documentation of FLARManager’s source is available in ASDoc format (thanks to Grant Skinner’s handy ASDocr tool).

Additionally, all examples and tutorials are updated, both in the code and online. Online walkthroughs are available via the FLARMANAGER link in the nav bar above.

[alternative interface examples]
For my talk at FITC this spring, I put together a series of examples that show how markers can be used to craft alternative interfaces for games, digital tools, and artistic experiences. These can be found in the /apps package, and launched via the application class FLARManagerAppLauncher.as, both included in the FLARManager distro.

[support for FLARToolkit 2.5.4]
FLARManager v1.0 offers compatibility with the latest release of FLARToolkit, v2.5.4, and most of the goodies it provides. Support for ID-markers will follow in a later release.

[full-resolution video]
The default video resolution is now 640×480 in flarConfig.xml. This takes advantage of flare*tracker and flare*NFT’s superior framerate, and also works quite well with the recent improvements in FLARToolkit.

[flar.camera package]
Camera setup for various 3D frameworks is now abstracted into classes within the flar.camera package, which simplifies scene setup in application code. Each class within the flar.camera package sets up the projection matrix for a given 3D framework, regardless of the selected tracking library.

what’s missing

Unfortunately, there are still a few things that are not complete. The major items yet to complete include:

• FLARManager does not yet provide compatibility between flare* and Away3D/Lite, Sandy3D, or Alternativa3D.
• FLARToolkit 2.5.4 introduced support for ID-markers, but this feature is not yet available via FLARManager.

most of you probably have no use for this, but for the slice of you involved in installation work or IT with apple computers, this applescript may come in handy.

placed in your Login Items, this script will do the following on login:

• attempt repeatedly to join a wireless network, whether hidden or visible
• ping a server on that network until the server responds, and then
• mount a volume on that server.

hope someone out there finds the script, or parts of it, useful.

-- -----join wireless network-----
set networkResult to false
repeat while not networkResult
    try
        
        do shell script "networksetup -setairportnetwork networkName networkPassword | /bin/bash"
        
        -- network found and joined.
        set networkResult to true
        
    on error errorMsg
        
        -- network not yet available;
        -- wait five seconds and try again.
        set networkResult to false
        delay 5
        
    end try
end repeat

-- -----mount server-----
set serverIP to "10.0.1.1"
set serverUsername to "username"
set serverPassword to "password"
set pingResult to "100% packet loss"
set serverFound to false

repeat while not serverFound
    try
        set pingResult to (do shell script ("ping -c 1 " & serverIP))
    on error e
        set pingResult to e
    end try
    
    if pingResult contains "100% packet loss" then
        -- server not found; delay and then try again
        set serverFound to false
        delay 5
    else
        -- server found; exit loop and mount server
        set serverFound to true
    end if
    
end repeat

-- delay to allow server to finish booting
delay 90
mount volume "afp://" & serverIP as user name serverUsername with password serverPassword


the newest version of FLARManager, which will be released shortly, abstracts the marker-tracking library out from the marker management framework (FLARManager’s core).

what does this mean?

in short, it means that FLARManager can now easily be updated to support any flash-based marker-tracking library. FLARToolkit (currently at v2.5.3) is the most obvious player, and FLARManager continues to support FLARToolkit. additionally, the newest version FLARManager will support flare*tracker and flare*NFT.

what are flare*tracker and flare*NFT?

[flare*tracker]
flare*tracker is a marker tracking engine much like FLARToolkit, and applies many of the same concepts. however, it is written completely from scratch in Alchemy, so it can achieve framerates up to 45+ fps. also, it supports six different marker types, including BCH ID-markers (with marker id encoded directly into the marker pattern, so no need to load pattern files and no speed penalty for many different patterns) and Data Matrix markers (with a url encoded into the marker pattern).

[flare*NFT]
flare*NFT is a ‘natural feature tracking’ engine, which means that it can track any printed image. not just square markers with black borders. any 2D image, from a magazine cover to a product box to a photograph, can be tracked. and since flare*NFT is also based on ARToolkitPlus, and written in Alchemy, it also shows great performance, generally around 30+ fps.

check out the following videos to see the difference between the three engines. and stay tuned for the release…
 
 

FLARManager – FLARToolkit 2.5.2. the FLARManager we all know and love.
 
 

FLARManager – flare. note the ID-marker, and framerates averaging in the 35-40fps range.
 
 

FLARManager – flareNFT. natural feature tracking made easy. blur? occlusion? glare? no problem.

• Title
• GE Smart Grid
• Libspark
• Libspark – AS3
• FLARToolkit
• NYARToolkit
• FLARToolkit source
• Google Translate
• FLARManager v0.1
• Exploratorium
• Dividing Space prototype
• Reactable
• reacTIVision
• FLARManager v0.7
• Jim Alliban – Fractal ’10 AR Ident
• Jim Alliban – LearnAR
• makc – driving game interface
• 5 Lives of Criss Angel
• Theo Watson – Boards Magazine (FERNS)
• Le Monde de Montagnes (FERNS)
• Imagination – flare*tracker
• Imagination – flare*nft

version 0.7 has been a long time coming; a lot of the changes in this update have been in SVN for months. just been too busy too wrap them up into an update.

download here:
http://words.transmote.com/wp/flarmanager/

also! you know i do it all for the love. but love don’t pay the bills. please consider dropping a dime my way to help me continue working on FLARManager so i can put food in my cat’s bowl.

what is this?

FLARManager is a lightweight framework that makes it easier to build FLARToolkit augmented reality applications for Flash. it is compatible with a variety of 3D engines, and provides a more robust event-based system for managing marker addition, update, and removal. it supports detection and management of multiple patterns, and multiple markers of a given pattern.

what’s new this time around?

[marker motion analysis]
FLARManager now executes some simple analysis of the motion of each tracked marker. this information is used to improve tracking of fast-moving markers by extrapolating their position after they are lost by FLARToolkit, and is used to reduce model jitter by varying the amount of smoothing applied depending on marker speed. it could also be used, for example, to create simple gestural marker-based interfaces.
 
[FLARToolkit update and SVN restructure]
version 0.7 brings FLARManager more in line with the current state of the FLARToolkit repository, with branches for FTK 1.0.0 and FTK 2.5.1. the zipped distro for FLARManager 0.7 contains FLARToolkit 2.5.1; if you’re checking out via SVN and want the latest stable build, i recommend you use the FTK 2.5.1 branch.

 

adaptive smoothing

the amount of smoothing applied to marker motion now varies depending on the amount of motion. slow-moving markers are smoothed more, helping to ease jitter on near-stationary markers, while faster-moving markers are smoothed less, in order to maintain responsiveness at higher speeds.

developers can manipulate adaptive smoothing by setting FLARManager.adaptiveSmoothingCenter. this can also be set via flarConfig.xml, as an attribute of the <flarManagerSettings> element. smoothing at a marker speed of FLARManager.adaptiveSmoothingCenter is equal to FLARManager.smoothing. set FLARManager.adaptiveSmoothingCenter to 0 to turn adaptive smoothing off.
 
 

marker extrapolation

with marker extrapolation, fast-moving markers that are lost by FLARToolkit due to blur can continue their motion along the same speed and direction without being reported as removed. marker extrapolation continues until the marker is picked back up by FLARToolkit, or FLARManager.markerRemovalDelay frames have expired.

FLARManager.markerExtrapolation is true by default, enabling marker extrapolation; set to false to disable. this can also be set via flarConfig.xml, as an attribute of the <flarManagerSettings> element.
 
 

marker motion data

in order to accomplish adaptive smoothing and marker extrapolation, FLARManager needs to calculate information about marker motion. this information is made available to application developers for their own use, and includes:

• FLARMarker.velocity
• FLARMarker.motionSpeed2D
• FLARMarker.motionDirection2D
• FLARMarker.rotationSpeedX/Y/Z

see the asdoc comments (and the FLARManager API Documentation, once i get a chance to update it) for information on these new properties.
 
 

variable-width marker border support

FLARToolkit’s support for markers with border widths wider or thinner than 50% of the total marker width is now exposed to FLARManager. set via the patternToBorderRatio attribute of the <patterns> element in flarConfig.xml. the value is the percentage of the total marker width/height that the pattern consumes, so a pattern with 25% border and 75% pattern would require a value of "75".

FLARToolkit’s support for variable-border width markers seems to max out around 80% / 20%.

unfortunately, FLARToolkit 2.5.1 no longer supports this feature. FLARToolkit 2.5.2 will support it, and FLARManager will target FTK 2.5.2 once it is released. the FLARManager_FTK_1_0_0 branch still supports this feature.
 
 

support for inverted markers

FLARManager can now recognize markers with white borders, instead of just black borders. set via FLARManager.inverted or via flarConfig.xml, as an attribute of the <flarManagerSettings> element.

thanks to jim alliban and lee brimelow for the idea, and the PixelBender shader that makes this possible.
 
 

under-the-hood improvements and changes

• flarConfig.xml loading and parsing now lives in FLARManagerConfigLoader.as, cleaning up FLARManager.as a bit.
• DrunkHistogramThresholdAdapter.as is now the default threshold adapter (shout out to matt reynolds for the suggestion). as such,

adaptiveThresholding, adaptiveThresholdingSpeed, and adaptiveThresholdingBias have been removed.

• display mirroring now defaults to true.

FLARManager: AR and Alternative Controllers

i’m also participating in a panel on “inspiration”, along with Brendan Dawes, Tali Kraokowski, and Craig Swann. pretty noble topic…!

Source + Imagination

Super Early Bird pricing is now available — get em while they’re hot!

see you in toronto…

those of you who’ve tried to fullscreen an AIR app in OSX know about the annoying grey bar across the bottom of the screen. apparently, that’s a status bar. i guess you can even set status messages into it. handy, perhaps, if you’re making a browser entirely in AIR. but i think most of us just want it to go away.

you can do this by adding showStatusBar="false" to your mx:WindowedApplication tag.
(you can also add status with status="who needs this stupid grey bar?".)

i found this out while playing with mx:Windows. all NativeWindows have a statusBar by default. how bout that.

-eric

http://www.ardevcamp.org/

my session will address the web component of AR, and will tie in with discussions on mobile AR, standards, experience design, and more. i believe (free!) registration is still open, on the site above. stop by!