Camera Roadmap

[pjcozzi]

• Higher-level interfaces, e.g., like Heading, tilt, roll #977, Make Camera scene mode independent. #2007. Details TBA.
• Collision prediction and avoidance: prevent undesirable effects like passing through the globe or models. See Chapter 9 in Real-Time Cameras. We should be able to make volumes, e.g., a rectangle around a model, that the user can't enter. Tilting under map in Columbus view #1977 Do not go under terrain #449
• Better interaction with terrain. Rotating the camera on terrain #549
• Better interaction with terrain when following an object on terrain. Add Camera-terrain collision detection when following an object. #1936
• Better ability to lookup from the ground.
• Easier zoom to a location. Continuous camera zoom #2816, Improve camera zoom #302
• Improve flights. Long camera flights #1158, Camera flight path in Columbus View ends at wrong destination #802, Camera flight path in 2D tries to fly through the map #804, Easy to break camera in Columbus View #1400, flyToRectangle doesn't work with rectangles that cross the IDL #2093, Specifying a flyTo pitch of -90 degrees causes crazy flights #2468
• More flights. Inertia bounce interferes with camera flights in 2D #1401, Make it possible to cancel camera flights #2027
• Improve 3D/2D/Columbus view transitions. Clean-up Columbus-view morph #451, Disable flights during morph #1596, Camera jumps at the end of morphTo3D transition #2065
• Consistent mouse controls. Consistent mouse controls #453, Inconsistent 3D and 2D camera controls #1200
• API to set home view. Centralize "home view" logic #1798
• Improved Touch. Camera sky interaction for touch events #1978
• Movement events. Events for when the camera moves #2366
• VR support
  • ScreenSpaceCameraController.maximumZoomDistance doc fixed #4660 #4778
  • http://casual-effects.blogspot.com/2015/01/adapting-camera-entity-for-virtual.html
  • https://twitter.com/morgan3d/status/608710628958720000
• Reevaluate ScreenSpaceCameraController options. Some may be better suited on the Camera. Fix camera view/flight issues when colliding with terrain #4105 (comment)

Experimental ideas

• Follow two objects, e.g., two aircrafts, using the rule of thirds. There is a chapter in Jim Blinn's Corner: A Trip Down the Graphics Pipeline.
• Stabilize camera. For example, if we are following a ground vehicle through the mountains, don't use a fixed position in the vehicle's body frame. Instead just keep a bounding sphere in view. Could be a special case of above.
• Focus the view on one object while keeping another object in view, e.g., a satellite and Earth, or a satellite and a ground station it has access it. Again, probably a special case of above if there is a generic system.
• Physics: camera shake when rocket takes off.

[pjcozzi]

It may make sense from the implementation side (I'd have to look), but having the controller come off of camera and the screen-space controller come off of the scene makes things hard to find. Even after reading the tutorial, I had to search the codebase to find where the screen-space camera was.

Example code:

scene.getCamera().frustum.near = 10.0;
scene.getScreenSpaceCameraController().minimumZoomDistance = 10.0;

I also think that the separation of camera and controller and frustum makes implementation sense, but the end user won't know what's where.

The higher-level interfaces will go a long way here. We should even consider making some of this @private.

[mramato]

I absolutely agree. In my opinion, end users should only ever need access to a single camera object where they can access the entire API (where every call works across all scene modes).

[pjcozzi]

Dropping the 1.0 label. We won't be able to do anything beyond #1817 for 1.0.