I found a bug in away3d gold when playing the same non-looping animation on more than one mesh.

Each mesh has its own SkeletonAnimator, using a shared AnimationSet. When 2 or more meshes play the same AnimationState, simultaneously or not, it creates a weird error in SkeletonClipNode with _currentFrame being a ridiculously high number (in the billions).

Attached is a simple FlashDevelop project that shows the bug using the HellKnight mesh. I modified slightly SkeletonAnimationState, IAnimationNode and AnimationNodeBase in order to get the animation duration, but didn’t touch anything else. This issue happens with any MD5 mesh I tried.

I also “found” quite a big problem with the way animations are handled in Gold version : out of the box, sharing animations doesn’t work (Shegl if you’re reading this, I was wrong in the other thread, got mistaken by the fact I was used to have it working and it was hard to notice in my game with the non-looping animation error popping up every few seconds).

To illustrate, in my diablo-like project I can have 2 skeleton warriors (same geometry, same material, same animationSet, different animator) play different animations : one attacking and the other walking for example.
But I can’t have both playing the same attack animation : technically I can of course, but visually both skeleton warriors will play the animation in perfect synchronization, even if one started attacking before the other.

This was not the case before the animation refactor, with “old” dev releases I could have all my skeleton warriors play the same animation independantly without any trouble.

My first question is : is this intended ? Or is it something that was overlooked during the animation refactoring ?

If it is intended, what’s the “official” / recommended way of dealing with the situation I exposed ?

Duplicating AnimationStates and create an AnimationSet per skeleton warrior ? If I’m not mistaken that aso requires a different material for each skeleton warrior, while they all should look the same so performance-wise that’s very bad (and out of question in my case).

Having “pools” of AnimationStates in the AnimationSet ? Meaning for example having 10 clones of the skeleton attack AnimationState, and keeping track of which ones are currently played so that every AnimationState is only used by one mesh/animator at a time ?

Modifying the SkeletonAnimator code (like Shegl suggested in another thread) so that it clones AnimationStates before playing them ?

I can hack myself through this for now, but it looks quite a big issue to me as this is a rather typical thing one wants to do in many games / apps.

man it’s not you find.. it’s me…
Also I already tell you solution how to avoid this bug….
And it’s not a “bug” it’s are nice feature in few ways.

my skype is “web-masta” i can help you. And u after this post good solution in right English language

No.. Optimized one.

Look Shegl, I appreciate the fact you want to help, but obviously we have problems understanding each other. I’m not here to brag “this is mine” or anything, I don’t care at all. It’s “your” bug ? Fine really, let’s call it Shegl bug if you want ^^

I also know how to modify away3d to make this work : I’ve said it before, I’ve said it again in this post.

Here I’m providing a detailed explanation and test project for the away3d team to see the problem. Trying to make (and understand) things better not only for me, not only for a temporary solution / hack.

If you still don’t get what I’m after, please just refrain from posting as it doesn’t lead anywhere

I suppose you don’t understand what it is are NOT a bug.. It’s only “bug” for me and you.. You can just create DublicatedSkeletonAnimator what solve this little problem without any update problems with away3d. I think no one from away3d wanna refactoring animate engine again.

P.S. Im very glad what u posting this bug and try to achive of attention of away3d team. And our missunderstanding of each over cause of my pure knowlage of English language. Sorry for this. =)

No problem Shegl I appreciate your input as well.

I suppose you don’t understand what it is are NOT a bug.. It’s only “bug” for me and you..

It *is* a bug : even if I wanted to have my meshes all play the same animation perfectly synched, if the animation is not looping it’ll crash. Clearly a bug as AnimationSets are clearly meant to be shared.
And also clearly a bug because this was working before, so somehow it is a regression. But also maybe the away3d team had a very good reason for doing it this way, and if so then I’m interested in hearing about it to get a better understanding of the whole thing.

Note there are 2 parts in my initial post : one about the bug, and one about the problem of having several animators playing the same animation independantly. Those are linked but not exactly the same thing.

I think no one from away3d wanna refactoring animate engine again.

Let’s not speak for them, I’m sure they want to make away3d as good as it can be. This might be something that was missed, or overlooked, or they could have decided to go this way while knowing about the problems and having their idea about how to handle them : until you ask, you’ll never know ^^

Shameless bump : anyone from the away3d team willing to shed some light on the bug and problem I described in the first post of this thread ?

Hey Matse

thanks for picking up on this problem - sounds like both the issues you describe are bugs of sorts - certainly the animation set is designed to be shared without problems like this so we are interested in fixing whatever issues you’ve been experiencing

I’ve already got your debug test but could you also file this as a bug in the github issues list? that way, a patch commit can be linked to the issue and you can follow progress in the comments there

Hey Rob,

Thanks for answering !

I created the issue on GIT : https://github.com/away3d/away3d-core-fp11/issues/368 (with a link to this thread)

Hey Matse

An update has been pushed to dev which should fix this issue, with a slight architecture refactor. States are now created specific for animators, and the range bug has also been verified as fixed