Sign in to follow this  

Camera Design: Polymorphism or Uber Cam?

This topic is 2345 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I am currently writing on my camera for my 3D engine and I am a little bit uncertain about the design, especially about the movement strategy. The only thing that is a requirement for me is that the camera has 2 modes: a freemode to move the camera free in space (like in a first person shooter) and a "target mode" where the camera is attached to an object and lookat is always centered on the object.

But I can imagine a lot of different modes/situations: I want to give my camera() methods like moveForward(float time), moveLeft(float time), yaw(float time) etc. to simply use it as FPS camera. But what should I do if one calls moveLeft(float time) while the camera is attached to an object? And what if someday I wanted a maya style camera (which orbits around an object) rather than the FPS camera.

To put a long story short: Do you have any recommendation about the design of a camera? Should I make one uber camera that handles all situations, our should I create an abstract camera base class and then implement sub classes for each case (FPSCam : public Camera, MayaCam : public Camera) etc. I guess this is elegant, but I also think its some kind of overkill since almost all methods would be virtual.
Or should I make one uber camera with a lot of #ifdef and decide at compile time the type.

Any recommendations?
Thanks!

Share this post


Link to post
Share on other sites
I have a view class, which my freeroam camera class inherits from. My master render function takes a view object reference. Try that, it seperates behavior from data.

Share this post


Link to post
Share on other sites
The easiest way is to program what you need now, then as you need more features expand your code. You actually wont know what you need or how to design it until you get your hands dirty. Then, you can see what you need and how to implement it. I highly doubt anyone would use a polymorphism for their camera class since I don't believe that any virtual functions need to be implemented in any of your described scenarios.

Share this post


Link to post
Share on other sites
Well, the way I see it a 3D Engine properly said, would not be concerned on how the camera moves, rather with what happens when it moves and providing the services all types of cameras should provide.

Each of the examples you provided on the different types of cameras are simply restrictions on a camera's ability to move around and rotate, so what is a camera exactly? A camera is a point of view and a projection, nothing else, so your camera must do just that.

If you want to provide a wider range of options by pre-implementing something that tends to get application specific quite quickly, I would advice you to do so through an external library outside the engine that uses your engine's base camera implementation to move it around.

What you can do inside your engine with the camera besides simply providing a point of view, is making things easier to for instance, change cameras instantly without loosing the previous information, analyzing your potentially visible set considering you might have more than one point of view (split screen, in screen sub cameras, rearview mirrors), multiple viewports, so on and so forth.

Share this post


Link to post
Share on other sites
My solution typically looks like this:

[list][*]Define a base class valuesource<T> which accepts a Time value and produces a resultant T value valid at the corresponding time[*]Derive [i]movement controllers[/i] from the valuesource base, which are used for various animations (linear interpolation, constant movement, variant acceleration, etc.)[*]Define a camera as a movementcontroller<Position> and a movementcontroller<Orientation>[*]Create movement controllers for look-at modes, panning cameras, etc. etc. etc.[/list]
This has the advantage of being highly data-driven as well. You can create and compose movement controllers using definitions in a data file, and build really sophisticated behaviours out of them very easily. An extension of this approach is in use in a couple of my shipped games; it's robust, scales well, is flexible, and fairly easy to use once you get used to thinking in terms of parametric functions.

Share this post


Link to post
Share on other sites

This topic is 2345 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this