Great job on the new camera animators!!

[MasterGod]

I want to say thanks for the work on the new cameras animators. I think it would ease a lot of work and pain and it's nice that it is finally done.

I still think the FPS code should be changed a little for better readability but that's ok..

[bitplane]

Thanks

I guess their usefulness will show when people actually start manipulating the cameras at runtime using the animators, and newbies make new cameras without having to deal with ICameraSceneNode

I didn't add your patch because it didn't check to see if keyMapArray.Action was valid, the switch will never add "count" or "always 32 bit" values into the keymap. Putting this check in would make it less readable than the switch imo.
However it could be done nicer for example making the Action member an EKEY_ACTION, but I thought that was more hassle than it was worth, given that I'd also have to test it

[christianclavet]

Is there some info on how to use theses animators? I could update my code using thoses.

[MasterGod]

Is there some info on how to use theses animators? I could update my code using thoses.

Yeah I'm waiting to hear about that too..

[MasterGod]

Oh I've seen that:

Not currently possible, however, if you're using SVN trunk the FPS camera is just a normal camera with a special animator.
You can get access to this animator by calling cam->getAnimators() and casting the one with getType() == ESNAT_CAMERA_FPS to an ISceneNodeAnimatorCameraFPS. You can then set the keys, move speed etc through the animator's interface.

If you're not using SVN then I guess you'll have to wait for Irrlicht 1.5

From here:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=27310

P.S
Can I use the FPS animator to apply the FPS movement behavior on any scene node or is it limited to cameras only?

[vitek]

Can I use the FPS animator to apply the FPS movement behavior on any scene node or is it limited to cameras only?

Is there a reason you can't look at the source in SVN? I'd think that the following would be a pretty good indicator of the answer...

Code: Select all

   95 	ICameraSceneNode* camera = 0;
   96 
   97 	if (node->getType() != ESNT_CAMERA)
   98 		return;
   99 
  100 	camera = static_cast<ICameraSceneNode*>(node);

Travis

[MasterGod]

vitek: Sure, and he also explained it a bit as I quoted but I thought maybe if he can describe all the changes it could be nice but yeah, you're right.

Edit:
Also a hint about how it would be wiser to use the new animators could be better which I guess isn't explained right away just from a quick glance at the new code.

[BlindSide]

I dont see why this should be restricted to camera use, I can see several applications for this kind of behaviour on other nodes.

[bitplane]

Yes, an FPS animator on a character (or a dummy node that a character follows) would be pretty useful, specially with a 3rd person animator attached to a nearby camera.
Need to work out sensible values for forward and up vectors first though, so don't expect an immediate fix for this

[BlindSide]

Need to work out sensible values for forward and up vectors first though

Ah, yes, it currently uses the getTarget() function of the camera to get the forward vector. I wonder if the speed difference in calculating it again manually is an issue.

[bitplane]

Speed difference wouldn't really matter since there will only be one node controlled by the mouse and keyboard. The problem is which direction is forward or up on an arbitrary node?
Use the rotation from the first animation time perhaps?