ICameraController or ISceneNodeAnimator::isEventReceiver?

[bitplane]

I've been threatening to add camera controllers for a while, the reasons for it-
* everyone wants a way to change the settings of the built-in cameras
* making a new camera is a daunting task for beginners

Travis (I think, could have been Hybrid) originally suggested having an ICameraController class which is a special sort of animator that only works on cameras, but (iirc) this was before scene serialization and doing it this way now would mean having extra serialization stuff and a camera controller factory.
I'm not really in favour of this, so my alternative solution is to add the following function-
ISceneNodeAnimator::isEventReceiver()

and the following interfaces-

ISceneNodeAnimatorFPSCamera
ISceneNodeAnimatorMayaCamera

addCameraSceneNodeFPS/Maya functions would add a standard camera, then add an appropriate animator. ICameraSceneNodes would send events to any/all animators that are also are event recievers in the usual manor (events are passed to the next animator if not absorbed by the previous one)

The original solution we discussed a long time ago is adding the following functions:
ICameraSceneNode::getController
ICameraSceneNode::setController

and the following interfaces:
ICameraController
ICameraControllerFPS
ICameraControllerMaya

ICameraController would be similar to ISceneNodeAnimator but inherit IEventReceiver and have animateCamera instead of animateNode.

So, what does everyone think?

nb: One good argument is worth a million votes in the poll

[MasterGod]

ICameraController would be similar to ISceneNodeAnimator but inherit IEventReceiver and have animateCamera instead of animateNode.

So, what does everyone think?

So you say the controller will just be a simple animator with few different methods? - Please elaborate on the camera controller idea so it will be more clear what will it have. I guess things like setSpeed() will be in it too right?

[bitplane]

No, ICameraController would be the same as ISceneNodeAnimator but only apply to cameras.
ICameraControllerFPS or ISceneNodeAnimatorFPSCamera would have setRotateSpeed and setMoveSpeed, but ICameraController or ISceneNodeAnimator wouldn't have either.
compare with ISceneNodeAnimatorCollisionResponse

[rogerborg]

FWIW:

A pragmatic idiom would be that camera logic should be done entirely in the user application, because in any non-toy application that's where it's going to have to be done.

Having any kind of non-trivial built-in functionality just (demonstrably and repeatedly) sends new users off down the wrong path, and adding more functionality is just going to get them further down that dead end before they realise that they are going to have to actually create a custom camera for their specific application.

Less is more with camera functionality, so just remove the existing trick cameras altogether and have an explicit policy that camera logic is in the application domain. Move the existing FPS camera functionality to an example application, copiously commented to say that it represents one way of doing a very simple FPS camera. Drop the Maya functionality altogether. No serious developer will be affected by that.

[hybrid]

The thing is that we want to provide means for simplifying the task of creating camera interfaces. And giving the chance to separate some code of the (often huge) event receivers into a separate class (or classes) seems to be a good way.
I like the idea of having event receiver stuff also for non-camera scene nodes. Just like example 4 shows, it might be useful to move other things as well. We could still use the original idea then and provide some camera animators to simplify camera handling.
I don't see why serialization would make a problem, but even if more factories would be necessary that doesn't seem to be too bad, considering the potential reduction of the SceneManager API into factory calls. But maybe you can detail on that problem some more (onyl if it also applies to the event recevier animator szenario which I prefer )