AS3 Starling with Bones support - question on implementation

[slopps]

I'm amost finished with my As3 Starling implementation of Spriter, which is successfully using loaded sprite sheets instead of individually embedded images.

Of course, I've hit a snag now that I realize how the parenting to bones work.

I'm trying to figure out which would be more overhead: calculating all the transformation matrices of parents to figure out the coordinates/angles of each image so that I don't actually have to create the bones themselves, or creating displayObjectContainers for the bones to house the children images so that I don't have to manually do any of the transformation math.

[update] I now realize that creating displayObjectContainers for the bones to house the child images wouldn't really be effective because it wouldn't allow proper z-indexing of the images. So I suppose that's out.

So, to figure out the actual coordinates/size/rotation of the images, do I pretty much have to go down the chain of bones and concat the matrices or something? I'm lost at this point.

Anyone have any suggestions?

[grimfang4]

SCML does not use matrix math. There was some discussion of implementation technique in another thread. Have you gone over the plug-in documentation? The C++ API is a good reference, too.

[slopps]

I only meant using matrix math to figure out the final and actual coordinates, scale, and rotation of the images. Since the coordinate systems are all nested inside one another, one of the best ways to do this is to concatenate all transformation matrices from the top-most parent down to the final child, and apply that concatenated matrix to the child.

Of course, it would be far easier to treat the bones as containers and just add children inside of them, since they would inherit their parents transformations, but then the z-indexes of the images would be all wrong.

Thanks for the link to the C++ implementation, I'll check it out. Does it already have bones implemented properly?

thanks again!

[update] In the post you linked you, they're basically doing the math the long/hard way, assuming the language or framework in question has some functions to help concatenate matrices. I suppose either way is accomplishing the same things, just with fewer lines of code on my end. There's could be more efficient, actually, since they aren't creating full blown matrices and calculating skew, rotation, etc.

[grimfang4]

I mentioned that it doesn't use matrix math not because you can do without matrices, but that you have to. Proper matrix math will not work with the way transforms are expected to be composed. Specifically, scaling directions are not rotated as they would be when composed as a matrix. I'm not a total fan of the way it is since it can't be represented just with matrices, but it works fine anyhow.

Yes, the C++ implementation does handle bones. It should handle everything that the latest alpha version of Spriter supports.

[slopps]

Really?! dang...

I'm not sure I understand the " scaling directions are not rotated as they would be when composed as a matrix" comment. Can you explain further?

I feel like if the parent is rotated 90 degree and scaled by 3, applying that transformation matrix to the child (and that of all parents above) should be just fine, no?

In doing some quick tests in flash, it seems to work. Is there something about the rotation values in the scml file I'm not understanding?

Thanks again and sorry to be a bother.

[slopps]

Ok, now I get the directional scaling problem. Sigh...looks like I'l be calculating the manual/only way possible as well.

Thanks again for your insight.

In case anyone is wondering, imagine you have a square. Then rotate that square by 45 degrees. Then imagine applying a transformation matrix to it that applies scaleY of 2. Instead of having a rotated rectangle, you will instead have a funky, skewed diamond since the scale-direction is still being applied vertically instead of rotating with the object.

[grimfang4]

No prob. Good luck on the rest of the implementation and feel free to ask more questions of course.