05-04-2016, 08:00 PM
Here are some enhancements to camera control that I think should be cheap and make things a lot better.
First let me say that I dislike “driving†the camera with controls that put the camera into motion at a certain velocity. It’s either too slow, too fast, or both - a la hysteresis. I favor “direct†positioning, where mouse position translates through some factor to camera position - like grabbing and moving a camera.
In pursuit of that, I have mapped zoom, p/t, dolly and crane Throttle Modes* to CTRL Z, CTRL X, CTRL D and CTRL C respectively, on Mac. This almost does it, but the ballistics of pan/tilt, dolly and crane make it still hard to use. This is because the speed of all movements seems to be ignorant of what the camera sees. Luckily I think this has an easy fix. Suggestions:
PAN/TILT: This function should really consider the view size and camera’s angle of view, so that mouse movement always creates an appropriate translation of the field of view. I propose that the calculations be:
With this approach, dragging, say, from the left edge of the view to the right edge, will always rotate one “view full†in that direction. In addition to this I suggest the following enhancements while in pan/tilt throttle* mode:
- SHIFT + drag doubles the translation, pan/tilting twice as far per mouse offset.
- V + drag constrains movement to tilt.
- H + drag constrains movement to pan.
DOLLY: Like pan/tilt, this function should consider the field of view, but it should also consider the distance to an object of interest. This is because the amount of dollying typically needed is relative to perspective on some object. For example, dollying 3 feet past a tree a yard away displaces the tree much more than if it is a block away. Luckily this is pretty easy:
- SHIFT + drag doubles the translation, dollying twice as far per mouse offset.
- V + drag constrains movement to forward/backward.
- H + drag constrains movement to left/right.
- OPT + drag orbits (locks pan/tilt) around the object of click.
CRANE: This is like dolly left/right, but up/down:
- SHIFT + drag doubles the translation, craning twice as far per mouse offset.
- OPT + drag orbits (locks tilt) around the object of click.
If any of the math is elusive (or wrong) I’m happy to discuss more. I hope this is something FF can try. I think it will make camera movement much more snappy in all shooting situations.
* "Throttle Modes" seems to say the opposite of what these modes do. Since a throttle controls rate/velocity, I would expect these modes to “drive†the camera. They don’t. These modes are more direct in that, when active, mouse offset translates into a camera offset, not camera velocity.
First let me say that I dislike “driving†the camera with controls that put the camera into motion at a certain velocity. It’s either too slow, too fast, or both - a la hysteresis. I favor “direct†positioning, where mouse position translates through some factor to camera position - like grabbing and moving a camera.
In pursuit of that, I have mapped zoom, p/t, dolly and crane Throttle Modes* to CTRL Z, CTRL X, CTRL D and CTRL C respectively, on Mac. This almost does it, but the ballistics of pan/tilt, dolly and crane make it still hard to use. This is because the speed of all movements seems to be ignorant of what the camera sees. Luckily I think this has an easy fix. Suggestions:
PAN/TILT: This function should really consider the view size and camera’s angle of view, so that mouse movement always creates an appropriate translation of the field of view. I propose that the calculations be:
Code:
Pan degrees = (angle of view) * (mouse delta x) / (view width)
Tilt degrees = (angle of view) * (mouse delta y) / (view height)
- SHIFT + drag doubles the translation, pan/tilting twice as far per mouse offset.
- V + drag constrains movement to tilt.
- H + drag constrains movement to pan.
DOLLY: Like pan/tilt, this function should consider the field of view, but it should also consider the distance to an object of interest. This is because the amount of dollying typically needed is relative to perspective on some object. For example, dollying 3 feet past a tree a yard away displaces the tree much more than if it is a block away. Luckily this is pretty easy:
Code:
Left/Right translation distance = COS(angle of view) * (distance from clicked object plane) * (mouse delta x) / (view width)
Fore/Back translation distance = (initial distance from clicked object plane) * (mouse delta y) / (view height) / 2
- V + drag constrains movement to forward/backward.
- H + drag constrains movement to left/right.
- OPT + drag orbits (locks pan/tilt) around the object of click.
CRANE: This is like dolly left/right, but up/down:
Code:
Up/Down translation distance = COS(angle of view) * (distance from clicked object plane) * (mouse delta y) / (view height)
- OPT + drag orbits (locks tilt) around the object of click.
If any of the math is elusive (or wrong) I’m happy to discuss more. I hope this is something FF can try. I think it will make camera movement much more snappy in all shooting situations.
* "Throttle Modes" seems to say the opposite of what these modes do. Since a throttle controls rate/velocity, I would expect these modes to “drive†the camera. They don’t. These modes are more direct in that, when active, mouse offset translates into a camera offset, not camera velocity.