//Could be any kind of animator.
ISceneNodeAnimator* anim1 = smgr->addAnimator();
//Two other kinds of animators. The animators can't be looping though.
ISceneNodeAnimator* anim2 = smgr->addAnimator();
ISceneNodeAnimator* anim3 = smgr->addAnimator();
//Set up animator chaining.
anim1->setNextAnimator(anim2);
anim2->setNextAnimator(anim3);
At least the code shown should be a no-op, because the animators would be executed in exactly this order. Moreover, a proper interface for priorities etc. would be more effective. If I missed something, please explain some more.
A priority system for this? That could be usefull. What else should there be? The reason I put it in bug reports was because I noticed that's where everyone else posted patches.
A no op animator system I think would be less flexible. If you had an animator that branched for example you'd want to hide the set next functions and the get next functions and just make the animator transision itself.
The reason why this is a no-op is that animators are automatically executed in creation order. You can actually chain animators today. So you should at least show some benefit of your method.
Posting these things in bug reports is ok. If larger design decisions are to be made it could better go into OpenDiscussion
//Could be any kind of animator.
ISceneNodeAnimator* anim1 = smgr->addAnimator();
//Two other kinds of animators. The animators can't be looping though.
ISceneNodeAnimator* anim2 = smgr->addAnimator();
ISceneNodeAnimator* anim3 = smgr->addAnimator();
ISceneNodeAnimator* anim4 = smgr->addAnimator();
//Set up animator chaining.
anim1->setNextAnimator(anim2);
anim2->setNextAnimator(anim3);
//...
//later somewhere when your animator is not finished yet.
if ( !anim2->isFinished() )
anim2->setNextAnimator(anim4);
//...
Then it already can. Oh and I forgot, you still have to add the first animator in the chain with ISceneNode::addAnimator();
From what I see you need to add all animators with addAnimator. Moreover, the chaining aspect doesn't come clear. You don't really chain anything here, you just start the animator at a later point. Does your code require anim3 to stop when anim4 starts?
The code is similar to the CProcess technique from Game Coding Complete third edition. You set all the animators and when the current animator in the sequence is finished, it's deleted and the current animators m_next variable (which is an ISceneNodeAnimator) is then added as the next animator. That's the best I can explain off the top of my head, if you want to see what I mean, try looking at the patch and you can see the whole thing.
Ah, ok. So you don't want any animator to start except for the first one and unless the old one has finished. Well, that's not that easily addable, because it would break the old "all at once" pattern resp. is not that easily understandable.
The all at once pattern is still there, if you want it. You can set the chaining to be on or off. It defaults to have animator chaining be turned off so that if people are porting existing projects they won't run into problems. You have to turn it on to get it to do the chaining.
I actually think such a behavior could be a nice addition for any and all animators, but more thoughts should be put into it. Aka, something like this should probably be possible:
1st:(3 animators simultaneously)
Then when the last one finishes (and maybe an option for when the first one finishes?)
2nd:(1 other animator)
Then loop on finish.
It could be a very good addition, as long as it's clean and easy to use.
Probably would be good if "chains" could be used inside one another too.
