Original subtitles

So far we have just been working with constant retimes.

We've been applying the same speed change to the whole shot,

but there are times where you might need to apply

various speed changes throughout a shot.

Perhaps you want to start the shot fast,

and then slow it down for a specific piece of action,

and then speed it up again.

Retimes like this are called non-linear retimes or TimeWarps,

and like most things in Nuke there are various ways to do them,

but each method can get quite confusing.

First of all, I'm going to show you how you might set up your own retimes,

but often the retime has already been done by the editor,

and we need to recreate it in Nuke,

so I will show you some different techniques for

matching our footage to the edit.

We'll be working with this pretty cool footage of a free runner.

The footage has been shot at a high frame rate,

so it's already playing back in slow motion.

I want to speed the sections up where he's on the ground,

so it plays back in real time,

and then slow it down further than it was shot when the guy is in the air.

The first node we can try is the Retime node.

It feels like you should be able to go through your

timeline and key frame the speed slider,

but if we start with the speed of 2,

and then set a key frame on frame 37 and change the speed to 0.

5 we see that the action jumps backwards after that key frame.

I think this is because the node is applying the speed change to each

frame on the original footage and not taking into account the other

speed changes applied to the previous frames.

So this method won't work for what we want to achieve.

The Retime node has a second tab called TimeWarp.

This graph is similar to the kind of TimeWarp controls

you might see in an editing package.

The slope of the curve represents the speed of the clip.

To add a new key frame onto the curve hold Command and Option,

Command and Alt if you're not on a Mac, and click on the curve.

You can drag the key frames around on the graph to change the slope.

The steeper the curve is the faster the clip plays.

If the curve slopes downwards, then the clip will run backwards.

The odd thing about this graph is that axis goes between 0 and 1 with 0

being the first frame of your clip and 1 being the last,

so the values on the axis don't directly relate to your timeline.

By default, there is a key frame at 0 and at 1.

This means that if you make changes in the middle of the

graph the clip will stay the same length,

so if you speed up the first half of the shot the second half

of the shot will slow down to compensate,

and the overall length of the clip will stay the same.

Because the numbers on the axes of the graph relate to the proportional

progress through the clip rather than the actual frame number it can be hard

to be accurate with where you place the key frames.

If this doesn't matter,

and you just want to create something cool you can get some

really interesting results with this technique,

but usually we need to be more frame accurate,

so I don't often use this node either.

OFlow and Kronos allow you to key frame speed changes in a more logical fashion.

In fact, they let you do it in two different ways, input speed or output speed.

Output speed is the default, so let's look at that first.

This is the most logical way of working of all the options, in my opinion.

While you view the output of the node you can scrub through

the footage and set key frames at the points in the action

you want to change the speed.

You can even set negative values to play the footage backwards.

So, in this case, we would start with a speed of two,

and then create a key frame just before he takes off.

We can move a few frames along before we create a second key frame.

This will give us a nice smooth run between the two speeds.

At the second key frame we can set the speed to 0.

5.

We can go through the clip setting key frames like this,

speeding up and slowing down as we go.

This is what I want the final result to look like.

The clip starts off at double speed before slowing

down to half speed when he jumps, back to double speed when he lands,

and then half speed again, when he does his flip,

then back to double speed as he spins off the screen.

The Input Speed option works in a similar way,

except it expects you to view the raw footage while you set the key frames.

This means that you can't actually see the result until you're done.

The Input Speed method does not allow negative speeds,

so you can't reverse your footage.

Other than that, the final results are very similar.

The main difference between the two is where the key

frames end up on the timeline.

The key frames for the Output Speed are relative to the final result,

whereas the key frames for the Input Speed are based on the original footage.

Working with speed values is a logical way of thinking,

and it makes it easy to experiment and come up with some creative work.

If you're working on your own within Nuke,

using speed controls will probably be fine,

but if you need to share this retime information with other pieces of

software or other departments speed doesn't translate very well.

Different pieces of software refer to speed in different ways,

and the slopes created between the key frames can be interpolated

differently between different applications.

For that reason,

we almost always have to set up our retimes to be based

on frame numbers rather than speed,

but trying to set up a nonlinear retime like this one is much less

intuitive if we have to think in frame numbers.

We have to do a lot more mental arithmatic.

For example,

if we want to play this clip at double speed until he makes his

first jump at frame 70 we would need to work out that we need

frame 70 at frame 35 of the timeline.

We then want 70 to 112 to be half speed,

so those 42 frames need to last 84 frames,

starting at frame 35 on the timeline.

So frame 112 needs to land on frame 119.

This is going to get quickly confusing.

If you have already created a retime using speed you might be

able to recreate it with frame numbers.

While this is a pain, it's relatively simple to do.

We often have to do it to match retimes done elsewhere.

In Visual Effects we don't often get to actually create the retime ourselves.

It has usually already been figured out by the editorial team,

and we just have to recreate it.

While there are ways to export retime information from

editing software to VFX software the reality of production

is that we don't often get it.

If it's a linear speed change this might come through in the shop notes.

It might say something like, 200% speed up,

but if it's a nonlinear retime we can't actually describe this in words.

We usually just get an edit reference QuickTime,

which shows us the final retime that the editor has decided on,

and it's up to us to figure out how they did it.

Hopefully the QuickTime file has the original timecode burned into it.

The timecode will relate to the original frame

numbers before the retime was applied,

and we can use this to recreate the retime.

The time code is different from the frame numbers of the

exr that we will usually be working with,

but we can often find it in the metadata of the files.

To check that you have the timecode in your exr files

connect a ViewMetaData node to your Read node,

and look for a field called input/timecode.

There are various types of timecode,

but this is usually the original timecode from the camera's source file.

There could be other timecodes included in the metadata,

including timecode from the edit timeline,

so you might have to look for a different field name.

If you can't see a timecode field I'll show you a different way

to match up the frames later in the video.

In this case,

I have an input/timecode field in my exr's and a reference

QuickTime from editorial with the timecode burnt in.

This QuickTime only has one piece of information burnt in,

but in a feature film production there will be all

kinds of text around the image.

You might have to do some detective work to figure out which

set of numbers you need to pay attention to.

If you're lucky, the editor might have included individual shot frame numbers,

which will match directly to the frame numbers of your source footage,

starting at 1001.

The main thing that matters is that the numbers need to

be from the source frames not the resulting frames after

the retime has been applied.

You can usually tell if the numbers have been applied

before the retime because the numbers don't increase

linearly as you step through the frames.

If the footage has been sped up you'll skip frame numbers.

If the footage has been slowed down you'll see repeating numbers,

and if the editor has applied some kind of frame blending or optical

flow you'll see weird blended numbers like this.

Ultimately, it doesn't really matter where the timecode is from,

as long as it relates to the original source frames,

and you can find a matching set of numbers in the

metadata of your source material.

Once you know which numbers to match you need to create a

Text node and add the metadata to your clip,

like we've done in previous videos in the class.

In this case, I'm going to type metadata input/timecode inside square brackets.

Now it's just a case of matching up the frame numbers,

but I'm afraid this is a very manual task.

Add a TimeWarp node below your Text node.

Go to the Curve Editor and select the two existing key

frames that are in the TimeWarp node.

Hit the L key to make sure that the interpolation is set to linear.

Now go to the first frame of your reference QuickTime,

and adjust the first key frame of your TimeWarp,

so that the timecodes of your source file matches

the timecode of your reference.

Watch your reference clip through,

and try and spot the points where the speed changes.

Whenever you spot a change add a key frame to the TimeWarp node,

and adjust it until the timecode of your clip matches the reference.

You'll need to treat this process a bit like rotoscoping.

Try to pick out all the key frames where changes happen,

and then go back through the sequence and add more key

frames if you need to refine the result.

If the respeeds are quite simple you might get away with only a few key frames,

but if there are lots of fluid time rems you could end

up with key frames in most frames.

If we don't have access to either the burnt in timecode in

the reference or the timecode metadata in our source files

we have to do this visually.

Here's my method to making sure we get it right.

Connect your TimeWarp node to your source,

and then add a Merge node below that, and connect it to your reference.

Set the Merge node to difference.

This difference operation will show you when your two frames match.

A complete match will give you a black frame.

Bear in mind that your reference QuickTime will often be a different

format and in a different color space to your source,

so you'll often need to apply a reformat and some color

operations to get it as close as you can.

It might never be an exact match,

but as long as it's close you should be able to tell when

your frames line up because you'll have a relatively flat

gray result to your difference.

Once you have this set up you'll need to go through the clip in the

same as we did when we were matching timecodes,

setting key frames in the TimeWarp as you go.

Once you think you're finished preview the whole shot through the difference

key to make sure that there aren't any frames that pop out.

Now that we have set up the Retime and the TimeWarp node we can use

this to control other Retime nodes in your script.

I'll show you how to do that in our next video.