[v0.5] less about features, more about streamlining all the v0.4 changes, removing deprecated bits, getting new defaults in place (i.e. flarConfig.xml) ( ) FLARProxy as IFLARSource, specified in flarConfig.xml ( ) clean up comments for ASDocs ( ) get native mirroring working ( ) fix bug: width < height causes strangeness in PV3D ( ) full-res video ( ) create new camera_para.dat with no correction ( ) get non-4:3 aspect ratios working for Flash3D ( ) build SWCs for FLARToolkit and PV3D [v0.4 TODO] (X) test all examples with all combos of aspect ratio and downsampleRatio (X) 2D (X) 3D (X) PV3D fix: (X) 2D, 3D, PV3D: <4:3, any dsRatio (X) 3D: downsampleRatio changes make a difference in scale (X) test resultsToDisplayRatio in both FLARCameraSource and FLARLoaderSource (X) update FLARProxy to match changes to downsample/resultsToDisplayRatios (X) downsampleRatio should be relative to source, not display (X) remove downsampleRatio from FLARManagerExample_Flash3D (X) non-4:3 aspect ratios are broken in FME_Flash3D / MarkerOutline3D (X) width < height causes strangeness in PV3D (X) clean up all the testing junk in SimpleCubes.as (X) recompile ASDocs (X) clean up / port to flarConfigFile existing examples (X) mirroring (X) non-4:3 example (X) non 4:3 sizes (custom FLARCameraSource) distorting PV3D scene/viewport not centering vertically when 4+:3 (widescreen) (X) would be nice to pass source/displayW/H in via xml, but then flarSource will not be available for addition to display list immediately on instantiation. one way around this is to make FLARManager a Sprite, and just add it, similar to Loader. would like to keep things composition-based though...hm... (-) basic example, with no setup, empty FM ctor, no config xml file. basically, a quickstart. (X) remove Mothership tests (X) test all examples (X) test without (full and partial) flarSourceSettings node in flarConfig.xml (X) FLARLoaderSource specified via flarConfig.xml (X) test mirroring in all examples (X) test aspect ratios in all examples (X) should all use flarConfig.xml, this is now preferred. [v0.4 changes] - commercial license - changes to FLARCameraSource - true mirroring (does not require mirroring container object) (TODO: not yet working for PV3D...) (TODO: working for flash 3D, but turned off (in FLARMarker) to avoid interfering with PV3D) - full-res video (TODO: doesn't work well with low light, so defaults are still 320x240.) - captureW/H vs. displayW/H - downsampleRatio clarified -- applied to sourceWidth/Height to determine size of BitmapData sent to FLARToolkit ACTUALLY, mostly removed, replaced with captureToDisplayRatio - encapsulated downsampleRatio within FLARManager classes, so FLARManager apps don't need to know about it (TODO: this is not yet complete in Flash3D example...) - similar changes to FLARLoaderSource - full-res display - captureW/H vs. displayW/H - matrix-level smoothing allows developers to set the amount of smoothing, and to easily implement their own smoothing algorithms - many application settings can now be specified in xml file, without recompiling (use FLARManager.initFromFile): - mirroring and smoothing - external file paths, e.g. camera params and pattern files - changes to FLARMarker - consolidated FLARMarkerOutline into FLARMarker; deprecated FLARMarkerOutline - provides vector3D, rotationX/Y/Z, what else? - sessionId - applySmoothing (see above) - better disposal - changes to FLARManager - initFromFile - exposed markerUpdateThreshold - smoothing / smoother (see above) - Flash3D working, except for non-4:3 aspect ratios - 12 new sample patterns - ASDocs - there are a LOT of new features here, so there are likely bugs! please help me squash them. - PV3D and FLARToolkit now distributed as SWC instead of individual files, to make downloading and updating from the repo faster - known bugs: specifying a FLARCameraSource with width < height with PV3D causes strangeness (X) remove mothership tests!! - MarkerOutliner ( ) test FLARTransMat.transMatContinue with new code uploaded by saqoosha ( ) oddly, still can't really go over 320x240 for capture. even though BitmapData being sent to FLARToolkit is definitely downsampled to 320x240, FLARLabeling_BitmapData.labeling() iterates about 3x as long with a 640x480 capture. can't figure out why... ( ) create camera_para.dat with as little distortion as possible. (use long focal width unibrain lens?) distortion is quite noticeable when using very long or very tall aspect ratios. (X) allow ability to specify patterns in xml file, like MythManagerCMS / FGAR. ( ) move config loading and parsing out of FLARManager into its own class, FLARManagerConfigLoader. ( ) redesign FLARProxy so it can be used as a source by FLARManager, so any application can just init a FLARManager instance like normal, but specify a FLARProxy as a source (instead of the default FLARCameraSource, for example). also, allow FLARProxy usage to be set via flarConfig.xml. ( ) ensure FLARMarker instances are being disposed properly after being copied to new (updated) instances, and after removal. ( ) move cameraParamsPath and patterns params from FLARManager ctor into a separate init method, and move flarConfigPath into ctor params. (i.e. make flarConfigPath the default way to instantiate FLARManager.) ( ) implement converters for other 3D engines, from makc's links on the google group http://groups.google.com/group/flartoolkit-userz/web/links (look at this: http://makc.googlecode.com/svn/trunk/flash/alternativa3d_flar/SimpleTest.as for info on converting to alternativa3d and also on dissecting FLARParam) also, saqoosha just added Away3D support -- grab matrix conversion from that and add to FLARManager. (X) FLARMarker and FLARMarkerOutline are confusing. some doubled information, may only need one class...assess. yeah, this should be done. just move all accessors from FLARMarkerOutline up to FLARMarker. possibly leave FLARMarker.outline available for one revision, and add trace in outline getter that reads "this is deprecated". ( ) dynamic thresholding: take a look at makc's solution; also, ARToolkitPlus method for auto-thresholding: http://studierstube.icg.tu-graz.ac.at/handheld_ar/artoolkitplus.php take avg b/w darkest and lightest pixels within detected marker. perhaps just grab ARToolkitPlus source and integrate into FLARToolkit? ( ) compile SWC of libspark and pv3d for distrib w/ FLARManager ( ) documentation! (+ ASDocs) (X) add easing (optional, set with flag, on by default) to transformation matrices ( ) reduce jitter by using an ease value that corresponds to the distance the marker moved b/w frames. if small motion (i.e. jitter in a mostly-stationary marker), use slow(low) ease value. if large motion (i.e. moving marker), use fast(high) ease value. NOTE: can do this fairly easily now by changing FLARManager.smoothing on-the-fly; more specifically, by using FLARManager.smoothing as a base, and by sending a value for numFrames to each detected FLARMarker that deviates from FLARManager.smoothing based on the amount of motion in the FLARMarker between current and previous frames. or better yet, based on amount of motion averaged over previous N frames. NOTE: have to check for motion in rotation as well as position. perhaps possible to check for motion in matrix values? (X) add z to FLARMarkerOutline.centerpoint (is there a native FP10 Point3D?) (X) can i get rid of downsampleRatio? it's a complicated concept, and could probably be automated by just specifying screen size and source size, sim to what i did in...? VideoDownsamplerTest? (-) mirroring FLARCameraSource messes with marker detection. rewrite to flip transmats if source is mirrored (?) (x) detect marker rotation for 2D tracking, and add to FLARMarker.as (x) x/y of FLARMarker.outline should already be scaled according to downsampleRatio when the FLARMarker is instantiated. (X) modify FLARCameraSource to output video at full-res, but downsample according to downsampleRatio. see VideoDownsamplerTest for this, or my modded WebcamFaceDetector. ( ) specify settable delay (in frames) before removing a marker. (i.e. "stickier" marker detection.) make available via flarConfig.xml. ( ) calculate velocity and acceleration of markers and extrapolates when markers disappear momentarily. (i.e. better fast-moving marker detection.) ( ) add patternToBorderRatio to FLARMultiMarkerDetector: use FLARDynamicRatioColorPatt_O3 instead of FLARColorPatt_O3. ( ) create flash IDE version? (-) provide example that draws objects with pv3D this example should demonstrate addition and removal events with some special animation on each event. how bout a simple box that spins up out of the marker on addition, and down into nothing on removal? (-) add an article to sanflashcisco.com (X) contact alex about presenting next month: FLARToolkit maaash.jp (face detection) soulwire's motion detection (subtractive analysis) (X) recreate patterns at higher res; the 3x3 ones all get confused for one another. (X) get new version of FLARToolkit, with ratio params in FLARCode ctor. (X) test FLARPattern._patternToBorderRatio (with tarotaro's marker generator) (X) patternToBorderRatio is working, but only in FLARSingleMarkerDetector. it gets divided by 10, and then passed into FLARDynamicRatioColorPatt_O3 ctor. follow that through further to be sure it's getting used correctly. (X) figure out FLARMarker.direction, and add to method doc need to figure out what 0-3 map to (i think up.left.down.right, same as .pat file, but verify) (X) build new .pat files for all the new patterns i created (X) support different resolution pat files, not just 16x16 (will have to have error checking on patt load; i don't think FLARToolkit can handle different sizes in the same session.) it cannot. FLARMultiMarkerManager will throw a FLARException if any of the loaded patterns are not the same width/height as the first loaded pattern. edit this to be a more descriptive error. (X) support mirrored camera output [optimization opportunities] ( ) replace "jaggedArrays" with Vectors. try to eliminate multidimensionality as much as possible; FLARMatchPatt_Color_WITHOUT_PCA.evaluate, for example, uses a 3D array to compare patterns. ( ) convert Arrays to Vectors ( ) use PixelBender to run averaging (synchronously). ( ) create b/w-only tracking mode (3x speed increase here...) ( ) FLARBitmapDataReader is currently using BitmapData.getPixel. could use BitmapData.getVector instead, particularly in FLARBitmapDataReader.getPixelSet(). also, if there's a way to update a source image as Vector instead of BitmapData, may be gains to be had there as well...?