I don't want to bore you with text (like I usually do), so here are two videos instead. First up, some footage showcasing the newly textured scene, along with models imported from Maya. I also added a bunch more shot types for the Follow idiom (most importantly, establishing shots), and there are now crowd scenes. Check it out below:
And finally, perhaps my last video. Consider it a sequel to "Birds of a Feather." Except instead of fighting, Professor Patton von Penguin and Colonel Steven Stork must now join forces... to hop up and down and wave their arms while a camera films them. Anyway, enjoy the automatically generated camera shots, the adjustable height and distance sliders, and the epic fight scene at the end.
Well, we're in the home stretch now—I designed and printed out my final poster. Hard to believe it's almost over, but let's make the most of the remaining time! We'll start with a list:
First thing: I added much more functionality to the camera menus: I have sliders for shot duration, distance from the target, and height, as well as a few preset buttons. Sliders can be adjusted while the camera is shooting—you'll see in the video below that I slide the distance in and out, causing the camera to fly towards and away the target while still filming it. The Follow button is pretty much the default standard, which causes the camera to track behind the target from a normal distance; Helicopter mode sets distance and height very high, so that the camera will film from far away and above; Bourne mode mimics the "Bourne" trilogy, by setting the camera to cut often, shoot from close angles, and shake like crazy.
Here's some footage (you can pretend that the dialogue is actually a fight scene. Or a dialogue scene taking place during an earthquake):
Second thing: you'll note in the video that the cameras now rotate slowly when they're not engaged. Right now they're ending up tilted, which is disorienting, so I'm going to fix that. But I will probably have them slowly do something when unengaged, just to look more visually appealing.
Third thing: In the corner of the video you can also see a crowd of my little blob actors. I started making a crowd event for the cameras to shoot, but it's not finished yet—you'll see it soon. But basically, I'm planning on leaving the event types as 1 actor events (follow), 2 actor events (dialogues), and 3+ actor events (crowds) for now. This is what it happened to look like in my original camera behavior tree anyway.
Fourth thing: You can't really tell in the video, but I rewrote a bunch of the code for the initial placement of the camera in a shot to ensure that it doesn't collide and keeps the target unoccluded. The major change is that when the target is near a wall and the camera is trying to track behind it, the camera now moves upwards and looks down; as the target moves away from the wall, the camera slides down and moves forward slowly until it can track at normal distance.
Fifth thing: The cameras now subtly look ahead of a target based on the target velocity, instead of at the targets themselves. Remember the rule of letting the actor lead? No? Here's a picture:
It's a small difference, and hard to notice. But if it's not happening, you'll feel uneasy, and you won't be sure why! So now you can rest easy again. However, speaking of rules...
Sixth thing: ...Editing rules are currently being violated. I realized that I never actually posted about those on this blog, so here they are in exciting picture form:
The 180-degree rule is related to the invisible line of action in a scene. Once you've established that the camera is on one side of that line, abruptly cutting across it will be disorienting for viewers. An example, look at that dialogue scene in the above drawing: the characters seem to switch places when the camera cuts. Alternatively, think about a ball rolling from left to right—if the camera cuts across the line, it seems like the ball changes direction. This happens sometimes in my project right now.
The 30-degree rule is kind of the inverse: if the camera doesn't move enough when it cuts, you get a jump-cut. In the drawing above, it would seem like the camera suddenly lurched to the side or stuttered, instead of cutting to a new angle. So when you cut, the difference in angle from camera to target should be greater than 30 degrees. This also applies to cutting closer or further from the target—it should be a large enough jump to seem motivated.
So right now these principles aren't being enforced, but that will be fixed soon. Essentially I'm going to set ranges when the camera cuts, so that it changes enough from the previous angle, but not enough to break 180. Hopefully that will work.
Anyway, time is quickly ticking away. The big list of things to do: crowd events, editing enforcement, and more camera shots for the idioms. After that, I will use remaining time to continue tweaking things. I'm also going to be working on my final presentation pretty soon, so that's exciting as well!
Wow, I've run out of Harry Potter titles already... I think I'll have to go back to Roll Hard, but with more subtitles. "Roll Hard: Electric Boogaloo," "Roll Hard: The Quickening," "Roll Hard: Back in the Habit," etc.
Oh right, I made some progress on the project too!
As I said last week, I wanted to get rudimentary menus implemented, so that the user can change the settings of the cameras while they're filming. Figuring out how to deal with GUIs in Unity was a bit of a struggle, but I think I managed to pull it off: You can click on any of the camera windows (I decided that forcing the user to click on the camera itself would be a pain, since they can teleport around instantly) to open up a (color-coded!) pop-up menu. Clicking on other camera windows changes the pop-up menu, and pressing esc removes it.
Right now, the menu allows you to change the shot duration of a camera (essentially how long each shot lasts before it cuts away). Watch the video below, where I shorten the shot duration of the camera filming the dialogue scene, and imagine that they're having an unbelievably exciting conversation to match the frantic pace of the editing. Setting the duration to 0 tells the camera to stop cutting entirely and just stay within its current shot-type (you can see me demonstrate this with the camera in the pachinko machine).
Getting the shot duration to work was more complicated than I was expecting, because it involved editing the behavior tree while the camera was... inside of it. The Wait nodes, specifically. Basically, I kept having issues with the camera getting confused and hopping around its behavior tree (like suddenly skipping from the follow idiom to the dialogue idiom). I think I have that under control now, so it should be easier to make new sliders and buttons on the menu.
Since presentations and posters are on the horizon, I'm going to add a bunch of new shot types and a few events for variety; I also want to continue tweaking the camera movement so that it can track the targets better. I also looked into camera settings like depth of field, blur, graininess, etc... but they're only available in Unity Pro (I guess I've been using Unity Amateur).
I think the SIG Lab has Unity Pro though, so I'd love to experiment with some of those things at some point. Have I mentioned that I want to make a film noir camera filter? Yes? Well I'm mentioning it again, because that would be awesome.
Almost forgot: Beta reviews were earlier this week!
One of the useful things I got out of it was a suggestion by Norm about how to handle tracking in complex environments. We talked a bit about how the characters in the "Harry Potter" movies are always running through forests (See? I had a reason for titling recent blog posts after those books), and the camera manages to track alongside them while keeping them in view and avoiding other trees. Essentially, think of it like this: instead of just trying to navigate the camera through the obstacles while looking at the target, imagine that there's a line from the camera to the target, and you're really trying to navigate the line through the environment. Since the camera can dolly in and out, the line should be able to get larger or smaller; it should also be able to be broken for a short time, as trees move through the view. Luckily, I have a shortcut: if the target is ever occluded for too long, I can just instantly cut to another angle.
Norm and Joe also told me about the new camera tools for Google SketchUp (Read more about them here!) These are still cameras, so they don't animate like mine. However, they do allow you to preview shots from different angles, and have options for things like focal length. So I definitely plan on checking it out, as it might give me some ideas for my project. We briefly discussed a future goal of turning my project into a plugin for SketchUp... But that's just for the future.
Also: This is probably the best blog post title that I will ever come up with. It's all downhill from here.
Last week, I managed to get basic cutting implemented. I said that my next goal would be to get basic idioms implemented, and decided to try tackling a basic dialogue scene. Let's check out some footage! (Note: Please watch this with another person so that both of you can provide improvised voice-overs for the characters)
And there you have it! Obviously, it's not a very exciting discussion: the camera just switches between two over-the-shoulder shots. But this is really the final piece in the foundational puzzle of my intelligent camera system: now the camera behavior trees handle different types of events with different shot idioms. So as you can see, cameras are reacting to a "follow" event by alternating between tracking shots and panning shots; they react to a "dialogue" event by alternating between over-the-shoulder shots. But now that I know that the behavior tree can handle more than one type of event, and more than one type of shot, it should be simple to add more. Awesome.
I'm going to work on more shots first, because many events will share the same types of shots (and just employ them differently). Currently, initial shot choices are handled by using an invisible dummy: the dummy starts at the position of the target and flies away from it in a certain direction; once the dummy reaches a predetermined distance, or collides with something, it stops. That way, when the camera warps to the position of the dummy, it should start with a clear view of the target (and if the target is within a box, for example, the camera will be inside the box too). For some events, such as the dialogue, the dummy and camera need to worry about multiple targets—in this case, for an "over-the-shoulder A" shot (that's over character A's shoulder, towards character B), the dummy starts at A, and moves backwards and to the side to get B in frame as well. Essentially, every type of shot has different instructions for the dummy, and then different instructions for how the camera should film the target. Soon I'll be adding aerial shots, establishing shots, reverse-tracking shots, close-ups, and so on.
But first, I do want to work a bit on the other part of my project: user constraints. While the program is running, the user should be able to click on a camera and get a little pop-up window allowing them to adjust settings on the fly (such as how often to cut, whether to only stick to certain types of shots, etc). I'm not sure how difficult this kind of thing is to do in Unity, but I want to start figuring that out as soon as possible.
