POLL: bind camera rotation and target by default, or not?

[rogerborg]

To recap, in Irrlicht, a camera's scene node rotation as set by setRotation() is independent of its view orientation as set by setTarget(). Changing one does not change the other.

This makes cameras flexible, but is non intuitive and is demonstrably confusing. What makes it even more confusing is that the FPS camera (only) does slave its scene node rotation to its target. (But this was broken on the SVN trunk after 1.4.2 for a while!).

Still with me? The current SVN situation is that slaving rotation to target and vice versa is now a configurable option for all cameras (ICameraSceneNode::bindTargetAndRotation()). It defaults to true for the FPS camera, and false for all other cameras, which preserves the existing behaviour from 1.4.2 and before.

The question: should we stick with this, or should we bind rotation and target by default for all cameras in future Irrlicht versions?

If we make binding the default, then the consequences will be that anyone relying on them being independent will have to call ICameraSceneNode::bindTargetAndRotation(false), whereas anyone who is currently binding them themselves can and should remove their application workaround.

Bearing all that in mind, seek your say in the poll and/or in comments.

[Mirror]

why not making it independent even for the fps so that the user just plays with setTarget and whoever needs setRotation use it on its own ?

i vote, don't slave for any type ( or in worst case scenario slave for all ).

For me though what's more important is that there is a universal behavour without exceptions.

[fennec]

It would be a shame to change the default behavior just to save noobs some confusion. After all, targeted cameras are standard procedure in almost all CG work for film, tv, games etc.

Perhaps have the camera slaved to it's rotation, but -only- if there is no target set. Even if bindTargetAndRotation(true).

[JP]

I would say keep the default behaviour for backwards compatability and the function is available for people who want to change it...

Having said that n00bs aren't the best at reading and understanding the docs so i'm sure we'll still get loads of questions about it... But then we can just point them to that function rather than saying it doesn't work and them asking for a solution which we then have to think up or paste from elsewhere...

[Dark_Kilauea]

I say keep them bound with the option to turn off the binding (as is currently done in the svn), I never really understood the redundancy of having both a rotation AND a target. People should probably not be parenting things to the camera anyway, but if they do, the children should rotate around with the camera, regardless of whether setTarget() or setRotation() is used.

If they really want independent values, they can call one function or use a dummy scenenode as a parent to both the camera and whatever else they wanted to parent to it.

[JP]

Well it's not really redundancy as they can be used for different things. As ICameraSceneNode inherits from ISceneNode it has the set/getRotation functions but as it's a camera it requires a target point to create the viewing matrix.

I guess really the set/getRotation() functions should have been bound right from the first version of Irrlicht...

[hybrid]

Well, directional light nodes have had the same redundancy, because direction in SLight wasn't really bound to rotation. So one had to do very special animators to rotate the light (even worse, it used the position to encode a direction, which was not really updated in the same frame ). I decided to remove this redundancy and use light node rotation for light direction. However, cameras are IMHO different, because they are directly used for the HCI, which requires maximal flexibility. that's why we should keep the possibility to keep the two things, target and rotation, separate. The current situation of making them bound to each other where desired is a perfect solution.
Backwards compatibility can be kept for a little while at least, we can think about this again for Irrlicht 2.0.

[rogerborg]

I'm with hybrid that we should keep the existing behavour (bound for FPS, unbound for other cameras), by the way. I don't see a compelling argument to change it, although the commenting on the FPS camera could possibly be improved to try and make it clear that it's an example of a bound camera type (not that anybody who needs to read that will do so... )

[Dorth]

I do not see the advantage of having them separated unless advance use. Why not have a unbinding option, but having it binded by default. Most people will only use one or the other. The very very few people who WILL use both are savy enough users to find the unbinding function.

[rogerborg]

Thanks for the feedback. I think we can see both sides of it, and in the long term we might bind them for all camera, but not for 1.5.

[oldskoolPunk]

If anyone is still looking at this thread, I was wondering ...

If rotating the camera does not change the target, then what really happens? I mean, if you rotate the camera 90 degrees but its still looking at 0,0,0 then nothing on the screen would even change, right ?

[rogerborg]

The camera will keep looking in the same direction. However, any scene nodes that are children of the camera will move.

[oldskoolPunk]

Oh....ok?

Well it seems to be tied at the moment. I definitely thing target should also be rotated.