Cinematic camera tool

I read one of Nicholas's posts about creating a cameraedit script. I have a need to do something similar, but instead of multiple pre-defined cameras, I'm trying to create a single long shot that moves around. My initial idea was to set up a system very similar to Aarku's transform saver script. The concept is that you go into play mode, control the camera manually via Halo-type controls, and every second a new transform is stored at the camera's position/rotation. Then you can tweak the transform manually, and feed the info into an array. Upon playback, the camera will find it's next transform, and lerp over the shot length between its current location and the next desired location.

Since Nicholas is both a film guy and a Unity developer, maybe he'd be willing to share the cameraedit script he's working on. Or anyone else could provide some input regarding a camera system like I'm proposing. Maybe Nicholas's script could be co-developed by the community to create an extremely robust cinematic camera system.

Any thoughts?

 

I can see the basic idea working out ok, but you need some modifications:

If you lerp from position to position, it will be very obvious when the camera changes direction, and feel very "linear", Abrupt. You need to smooth it somehow. A trick I've used in the past is to have a target 1-2 meters further along the path. basic algo is this:

Code (csharp):

1.  
2. move camera towards target.
3. if (dist (camera, target) < 2) {
4.   newTarget = AdvanceAlongPath (target);
5.   if (!raycast (camera, newTarget))
6.     target = newTarget
7. }
8.  

This will smooth the camera's motion as it travels along a very polygonal path. The raycast makes sure that the camera never cuts through a corner.
(This method was originally made to make NPCs follow a waypoint list)

Something else: most of the camera motions in movies are constant speed (barring a smooth in/out) - you might want to think a bit about if you want to normalize it (you record a path but make sure speed is constant - or at least smoothed). Possibly just having lots of input smoothing will help you here.

Looking at this problem from a somewhat higher perspective, it seems that this is basically a case of keyframe extraction from a lot of samples. 1 second may be too short or too much. You can play around with the value to get a good balance. (Or be clever about it: start at the endpoints and recursively subdivide you path until it fits).

How about recording with an analogue stick? That could work really well for handling speed. One hand on the mouse, one on the stick.

 

The analog stick is a great idea, now I need to invest in one. Yes, I agree that the 1-second interval may be the best approach. I was planning to essentially make a series of shots, each with a start/end position, start/end rotation, start/end FOV, and shot length in seconds. Having the camera's info recorded real-time every second would be a simple groundwork, and once the movement is captured, a wizard could handle editing the shots.

Thanks very much for the basic algorythm, I understand the basics of it, and it would be very helpful for smoothing shot transitions.

Do any other programmers want to tackle a project like this with me? We could Unify it.

 

I tried something like this in/out value stuff. It was VERY hard to set up in practice, so we killed for just camera cutting.

AFAICS, my camera cutting is on a layer above the individual camera: I can see them working together sth like this: the CameraCutter decides which of its children cameras to enable. What each camera does WHEN it's enabled is really up to itself. These two methods can also record on top of each other - so when you record a switch to Camera3, it will start recording. Possibly this is not what you want, but it could be one usage pattern.

One of the things I got right with my camera cutter was that when you recorded a new settings, it would play the old recording until you began edits. This meant the if you got the first 4 edits right and botched the 5th you could just re-record and not do anything until you got to edit 5.