Camera Rework

Feb 15, 2008 at 5:32 AM
Continuing this discussion from the issue in the issue tracker.

The last comment was something regarding that the camera's should all update before other entities:

My response:
If you have a moving security camera, it moves whenever it is updated, I don't see why it should update before everything else. Here are some examples of a moving security camera in both scenarios.

Example 1 (Updating camera before rest of scene entities in a system where rendering is synced):
End of frame 1: Security camera has an entity in its view.
Frame 2: Security camera turns slightly, builds a new view frustum, and the entity is no longer in its view because the camera has turned too far. Now entity updates and moves, entity is now in view. Rendering system uses camera's frustum to render and entity is rendered.

Example 2 (Updating camera whenever its entity is called for an update, is a synced system):
End of frame 1: Same as above.
Frame 2: Entity updates before camera and moves out of view of the camera. Camera updates afterwards, and the entity is back in view. Renderer uses new frustum and renders the entity.

If the rendering system is async is still doesn't matter:
Example 1, async:
End of frame 1: Assuming rendering system has the entity in view of the camera at this point....
Frame 2: Camera updates, causing it to rotate, and...... (Rendering system gets latest values from scene, because we're in the middle of a frame it just redraws frame 1) .....recreates its frustum. Entity is now in view of the camera.
Frame 3: Camera updates, causing it to rotate, and the entity is probably still in view (doubt the camera is moving so fast in 1 frame the entity is out of view). (Rendering system gets new frustum and renders Entity.

Example 2, async:
I think you get the point. This will be no different from above.

Aside from when updates occur. I'd like to get into the details of the camera system.

  • I'm not sure I want to require cameras to attach to an entity. What about allowing any entity to attach to any other entity? If we allow this, then any camera can attach to an entity anyway. This would allow free cameras to not be required to be connected to entities.

  • I'd like to have the camera system setup in a Dictionary. To request the camera, you request a unique ID. If that ID is found you get a "pointer" to the camera. You could pass the ID of the camera itself, or the ID of whatever it might be attached to:
We have 3 entities: Camera (ID 1), Player (ID 2), Enemy (ID 3).
We attach Entity with ID 1 to Entity with ID 2. (attach camera to player).
We do not attach anything to ID 3.
We request a camera from the camera handler, sending it ID 1. We recieve the Camera, which is currently attached to the player.
We request a camera from the camera handler, sending it ID 2. We recieve the same camera as in the last step.
We request a camera from the camera handler, sending it ID 3, we recieve either a null value or a simple enum error value for a "camera does not exist" type of message.

This system would also make it easy to request cameras that were independent or unattached.

The nice thing about having this automation through a camera handler is that throughout development, anything that needs access to a camera associated to an entity or scene doesn't need direct access to that entity or scene. For example you could request from the camera system current rendering camera, without having to be connected directly to the renderer. You can request the red team's captain's FPS camera, without needing to have a direct connection to that team, or it's captain. It removes dependancies and keeps anything needing a camera dependant upon only the camera interface to get it.

Anyway, just a thought, talk amongst yourselves.