I remove the AnimControl by calling spatial.removeControl(control) in onAnimCycleDone.
When I do this, the animation is left incomplete, at a point that depends on the playback speed (faster -> closer to the beginning of the animation; slower -> closer to the end, but incomplete in each case).
Any insight as to why this is happening?
I thought that onAnimCycleDone is called when the animation completes … I mean, that’s what the name implies, but that doesn’t seem to be the case.
You’re not really supposed to remove the anim control just to stop the animation…
@normen said: You're not really supposed to remove the anim control just to stop the animation..
I think they are doing the opposite of this… s/he is removing the control in the onAnimCycleDone method.
@t0neg0d said: I think they are doing the opposite of this... s/he is removing the control in the onAnimCycleDone method.
What could be the reason for this antic then?
@normen said: What could be the reason for this antic then?
/shrug don’t know… I was just reading out of curiosity and thought that you misunderstood him =)
I think that’s the way onAnimCycleDone is implemented. I cam across the same issue. It is mainly apparent with “fast” animations and gets worse with lower FPS, because then the value for tpf on the AnimChannel is larger and the AnimChannel#time gets incremented with larger values.
onAnimCycleDone is called on
[java]
time >= animation.getLength() || time < 0
[/java]
so it is either called after the animaiton is finished or when using LoopMode.Cycle before it’s finished. That’s what I figure at least. There is even a comment in the code: “NOTE: This algorithm seems stable for both high and low tpf so for now its a keeper” along some commented code. So there might still be an issue?
@t0neg0d said: I think they are doing the opposite of this... s/he is removing the control in the onAnimCycleDone method.
Exactly (I thought I made that pretty clear, but I guess there was some room for interpretation).
And btw - I’m a guy, so “he” would be appropriate. 
@arpagaus said: There is even a comment in the code: "NOTE: This algorithm seems stable for both high and low tpf so for now its a keeper" along some commented code. So there might still be an issue?
It sounds like an order issue: The listener is notified before the controller updates, so if the controller is removed in onAnimCycleDone, it doesn’t get a chance to finish the deform.
But that’s just a guess.
Although, if that happens to be the case, a simple fix would be to trigger the notification on a flag set by the controller (after the mesh update), instead of sampling the time directly, and hitting this bug (I guess we can call it a bug, right?).
Do you have some test case?
I never noticed this on my animations, but I never tried to remove the control when the animation is done.
The animation system is a bit sensitive to changes and fixing this anomaly may bring some more…
@nehon said: Do you have some test case? I never noticed this on my animations, but I never tried to remove the control when the animation is done.
Just try to remove the control in onAnimCycleDone, and you’ll see the problem (set the playback to something higher, to make the effect obvious).
Ok i have the issue too. It looks like the culprit is the blendTime. When I go setAnim(“blah”,0) it works. (using setAnim(“blah”) uses a default blend time of 0.15 sec)
I’m gonna look what’s wrong, in the meantime could you confirm that using a 0 blend time alleviate the issue on your side?
Ok I think I fixed the issue, the problem was that the blend time didn’t take the speed of the anim into account.
So there were cases where the blend time could be superior to the anim actual time.
Also, the time was incremented before checking for the animCycleDone listener, resulting in calling it during the second to last frame instead of the last one.
I committed a fix could you please test it?
@nehon said: the time was incremented before checking for the animCycleDone listener, resulting in calling it during the second to last frame instead of the last one.
I would think that the time was incremented after the call to onAnimCycle done … If it was before, than the animation would finish before.
Well, in either case, if you managed to fix it, that’s great.
I’m not in a position to test the patch (at the moment), but I trust you.
@Goran said: but I trust you. :-)god...huge mistake ;)
@nehon
Thank you for looking at this. Unfortunately, the latest change introduced a new issue. Now notifyAnimCycleDone is not called anymore at all. I have many animations which are cycling and they do not enter notifyAnimCycleDone anymore at all.
Furthermore, I always used a blend time of 0ms and still encountered the original issue. So there must be another problem.
It’s quite noticeable with animation tracks with a resolution of 25FPS and restricting the JME’s FPS to 30FPS. So far I haven’t found the time to dig deeper in the code, so, I’m not of much help so far…
Then I need a test case, because my change made mine work perfectly,
Please direct follow-up discussion to http://hub.jmonkeyengine.org/forum/topic/onanimcycledone-not-call/