CameraController class

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

CameraController class

Post by dark_sylinc »

I got this question into my inbox, and since it's relevant for the community in general, I'm going to post it here.
(...)
I started learning it from the EmptyProject which is a very nice template project. I write this message to you because I don't know which catergory my question(suggestion) belongs to.

I found that all the public member functions (update, keyPressed, keyReleased, mouseMoved) of CameraController class are not declared as virtual functions. Were they designed not to be overridden?

IMHO, I think there is no harm to put them as virtual functions. For example, if the end user wants to create a third person camera which follows some SceneNode, a convenient way to achieve it is to use the injected functions as the old v1 Ogre Character demo does. But in v2.1, if to use the built-in CameraController, there are no easy ways to do that. But all in all, there is always a way to solve the issue by adding statements to the relevant functions of EmptyProjectGameState class, but that is not very convenient, and codes are not neat.

I think if the public member functions of CameraController class were declared as virtual functions, one could inherit the CameraController class and override the update, keyPressed, keyReleased, mouseMoved functions. In this way, it is quite easy to create the object of the sibling-class of CameraController and assign it to mCameraController of TutorialGameState class. Thus, the end user can easily customize the update, keyPressed, keyReleased, mouseMoved functions in his own sibling class, and doesn't have to worry about changing the declaration of public member functions (update, keyPressed, keyReleased, mouseMoved) to virtual in CameraController.h file in the OgreCommon directory everytime the project refreshed. This is quite neat and convenient for end users. (Currently ex. when loading a project the QtCreator will refresh the OgreCommon directory with the content of Samples/2.0/Common/ directory and overwrite everything.)

What is your thought about these public functions of CameraController?
Hi!

I am glad you're liking Ogre.

Regarding CameraController... the previous 1.x incarnation of Ogre blew out of hand because we had users asking "why don't you add virtual here? In case I want to customize it..." and years later we ended up with everything being virtual, without ever being overriden by the project.

Virtuals aren't free:
  • Runtime-wise, they add a performance cost (the vtable, indirect jumps)
  • Human-wise, they add a bigger strain to understand how things work: is this the final implementation? if it can be overriden, then where are the overriders and what they do? Do they add extra functionality or entirely replace it? And why they do that?
CameraController is very basic. Even WASD is hardcoded into its movement, whereas likely a real application should be able to customize it. It provides basic camera functionality the demos need.

What you're asking is to let us allow you to override everything or almost everything about CameraController so it can do what you wanted. At this point I'll ask then... what's the point?
If you're going to override everything, then why not create your own class?

CameraController.cpp is 126 lines of code, including comments and empty newlines. It's not big nor complex. You could copy paste it and write your own.
Sure, you've heard that copy paste is bad and a programmer should reuse code. That's true.
However it's quite likely the code from CameraController will be of little use to you:
  • An FPS game needs to constrain the camera to physics (e.g. gravity) and sometimes even follow certain animations
  • A Super Smash Bros-like game needs to account all players on the arena in order to zoom out so all of them are included
  • A third person game needs some constraints to always focus on the main player. An Assassin's Creed-esque game also needs to account objects being targeted the player
Another argument against copy-pasting is that if we change CameraController in the future, then you won't getting those changes. But again... you're talking about overriding everything or almost everything. There's a very high chance those "potential" future changes are of no use to you, or may even work against you.

Furthermore, we purposedly do not create CameraController for you. It's the samples the ones initializing CameraController.
While CameraController will likely get you started in no time with a "God mode" camera that can fly anywhere, it's very likely that you will soon forget about this class, never creat it an implement your own, which could be very different.

A CameraController is like a dog. All dogs may belong to the same species, but your dog is unique in its own way, and cannot be simply replaced by a similar dog of the same breed or another pet.

Cheers
Post Reply