FLARToolKit vs NyARToolKit

[Makc]

I just downloaded latest FLARToolKit and couldnt help but notice that
some classes (like FLARParam) are now simply proxies for Ny classes,
and some (FLARSingleMarkerDetector) are not, even though there's
corresponding Ny class.

why is there such a mess? why not just deprecate FLAR classes and let
everyone use Ny stuff?

[makc]

after poking around, I see Ny stuff is really weird. e.g.,
NyARRgbRaster.as line 75
this._reader=new
NyARRgbPixelReader_INT1D_X8R8G8B8_32(Vector.<int>(this._buf),i_size)
throws exception for unallocated _buf because it's typed as Object,
and line 99
NyAS3Utils.assert(!this._is_attached_buffer) specifically forbids
overwriting allocated buffer.

thus you cant do thing like
nyraster.wrapBuffer (bitmapData.getVector (bitmapData.rect))

well, actually you can't do that any way, because getVector returns
Vector.<uint>, not Vector.<int>

so the only option I could try (without hacking nyatla classes) would
be to copy one vector content to another, which is stupid, and
probably will not work any way :(

[makc]

> probably will not work any way :(

of course, if you create raster with pre-allocated buffer, you hit
Error #1034: Type Coercion failed: cannot convert
__AS3__.vec::Vector.<jp.nyatla.nyartoolkit.as3.core.labeling.rlelabeling::NyARRleLabelFragmentInfo>@3708251
to
__AS3__.vec.Vector.<jp.nyatla.nyartoolkit.as3.core.labeling::NyARLabelInfo>
somewhere deep inside new NyARSingleDetectMarker (nyparam, nycode, 2,
NyARBufferType.INT1D_X8R8G8B8_32)

I guess this answers original question... but I am playing with 2.5.4
download, may be things are better in svn head? let's see...

[makc]

> may be things are better in svn head? let's see...

tried with http://www.libspark.org/svn/as3/FLARToolKit/trunk/libs/NyARToolKitAS3/src/jp/nyatla/
revision 4416 (libspark's head atm), same shit. NyARToolKit (as3)
officially doesn't work.

[Makc]

> officially doesn't work.

unofficially, I've got it to detect hiro marker by hacking out two
lines of code... this might actually work all the way, ha ha! I should
have went to sleep.

[Makc]

> unofficially, I've got it to detect hiro marker

right... but nydetect.getTransmationMatrix (nyresult) returns matrix
full of NaN-s

p.s. I hope you guys don't mind me talking to myself in your mailbox.

[Makc]

any way, here's how far I could get.
perhaps rokubu or who's that nyatla guy, can have a look.

[eric socolofsky]

not sure why it's such a mess. when i was messing around with this stuff for FLARManager, um, v0.7? i was a little frustrated with the fact that it seems like there are two copies of the same thing, when i was trying to figure out exactly what i was supposed to plug into. if you look in the FLARManager distro, you can see that there are both org.libspark and jp.nyatla packages, and they're both required to compile.

basically, FLARManager interfaces with org.libspark.flartoolkit.detector.FLARMultiMarkerDetector, but it has to use some types from org.libspark and others from jp.nyatla. i tried to go with jp.nyatla for types when i could, as they're more generic than the org.libspark types, which often seem to be useless (no additional functionality) wrappers around the nyatla types. but still had to use types from both packages...

-e

[Rokubou]

Hello,

FLARTK v2 is a rapper of NyARTK as said by you.


FLARTK was made based on NyARTK.
However, FLARTK was transplanted from old NyARTK.

Saqoosha was not able to take the time of the maintenance of FLARTK.
And, no one additionally renewed FLARTK to the version that NyARTK is
new.

Therefore, nyatla and I additionally planned the renewal of FLARTK to
the release of NyARTK v2.5. We thought about release by the package
name
of NyARTK.

nyatla chose to do API name as well as FLARTK. However, nyatla's
rewriting the class name take lots of hard work.
Therefore, FLARTK became the current easy structure to correspond of
him.

There is such details.

rokubou

# I'm sorry in poor English.

[Makc]

On Sun, Nov 14, 2010 at 6:46 AM, Makc <makc.th...@gmail.com> wrote:
>nydetect.getTransmationMatrix (nyresult) returns matrix
> full of NaN-s

my div-by-0 bugfix addresses NaN problem in FLARToolKit-based test but
not in NyARToolKit-based. more debugging ahead :(

btw, I have also committed type mismatch bugfix (r4418), hope that helps.

[Makc]

> more debugging ahead :(

this was easy, NyARParam does not init screen size.

so,

here's what it boils down to: using rev 4418, you can use NyARToolKit
classes ONLY. (almost) working proof of concept code:
http://pastebin.com/7uNTGfMY swf at http://megaswf.com/serve/72168/
(ignores confidence, use any marker)

the only hack (that I will not commit, because it is *cough* hack) is
to comment NyAS3Utils.assert call out in wrapBuffer. this can only be
resolved by nyatla and rokubou.

finally, bad news:

this is almost 2 times slower than using FLARToolKit detector, so you
guys should reconsider the direction of the project.