A few months back Digital Tutors/Pluralsight have picked me up to release a training series with them. It’s entitled Intermediate to Advanced AOV Manipulation Techniques in NUKE. In it I will be showing some tips/tricks to work as efficiently as possible with multipass renders. It starts by giving a brief introduction to AOV’s for newcomers, just so that everyone is on the same page but will quickly ramp up into more advanced topics.
After the introductions I prepared a small project to integrate a CG car into a live action environment. Tweaking it to make it look good in the shot and an indepth rundown on why I do what are just a few of the things I will be discussing.

Also check out some before/after screenshots of the CG slapcomp vs the final composite to get a rough idea:

Integrating CG into uneven soil is an interesting challenge. On a recent show we had to integrate CG characters into plates which often had a grassy ground. For Comp it’s benefitial if you get masks from Rendering to aid the blending of the CG elements into the grass. If the ground the characters are walking on is flat this can easily be achieved with a standard PWorld AOV. It get’s a bit trickier though if the characters are walking up a hill or a similarly uneven surface, because the coordinates at which the character comes in contact with the ground are constantly changing. I’ve been trying to come up with a system to make a Comper’s life easier and found a relatively simple solution.

So here’s a simple example scene with a sphere and a bumpy ground:

First of all I wanted to have a point on the sphere and a corresponding point on the groundplane right below that travels wherever the sphere moves. That way it’s easy to always get the closest distance of the ground to the sphere. A simple way to achieve this is to create a locator and constrain it to the sphere with a Closest Point Constraint. This will add 2 more locators to the scene: cpConstraintIn at the position where the locator was placed and cpConstraintPos which sticks to the surface of the sphere and is always on the closest point of the sphere to cpConsteraintIn.  The original locator that was created can be deleted. Depending on the scene a Point to Poly Constraint might be a more viable solution, such as when there’s a character moving over the ground, because it may be more desirable to have locators bound to each foot. In this case I chose a Closest Point Constraint because this will give the ability to rotate or scale the sphere and still have the system work eventually (a practical example would be a barrel rolling down a hill for example).
Now one can move the sphere slightly up so that both locators are right above each other and Point Constraint the X and Z axis of cpConstraintIn to cpConstraintPos with maintaining the offset so that cpConstraintIn always travels along wherever the sphere moves. To make cpConstraintIn stick to the bumpy groundplane it can be Geometry Constraint’ed to it. For now this should give you something like this:

Next thing that needs to be done is the coloration whenever both surfaces are coming closer to each other. I created a ramp as a perspective projection with white on the bottom and black on the top. Once again this could be done with a separate UV set instead of a projection but the projection approach gives the flexibility of being independend of the UV’s and have the system also work in situations when the object is rotating for example. To make sure that the part where the ground is is always white I placed the place3dTexture node (that got created when I created the ramp as a projection) so that the lower edge would be slightly below the cpConstraintIn locator. I then point constrained the place3dTexture from the ramp to this locator so that the white section would always be according to where the sphere might touch the ground.

In the ramp one can now easily set the desired falloff and it should be all good to go:

The result can be piped into a custom AOV to deliver to comp for mixing it with a bit of noise and all that fancy stuff to make the elements sit properly in the plate.

Here’s a more practical example using point to poly constraints and a bit more effort being put into the setup:

Image based lighting often times simplifies getting started with a good lighting setup when trying to integrate CG into life action. Often times it’s beneficial to have the IBL sphere to just contain the ambient lights from the environment and therefore to paint out any actual light sources from the set. Those can then be used on separate lights to give the main illumination from the set lights, while the IBL sphere contributes ambient environment light. Now, if you have a lot of different environments and consequently a lot of different HDR’s it can be tedious to paint out the lights and output them after that… Apart from all the other work that needs to be done anyway (merge to hdr, stitch, match to plate, etc.). Sooo, let’s try to speed things up a bit… once again :)

//01.04.2014 Update

I was working on a Nuke gizmo that takes care of removing lights from an HDR with as little effort as possible. Upon creating the Gizmo you will be presented with a bounding box. This area should contain a light within the scene that you want to extract. Just put it tightly around a light source. If the HDR contains a light which isn’t planar to fit into the rectangle you can plug in an alpha into the “Mask” input. After you cleaned up one light you can proceed with adding another HDR_Prepper node to remove as many lights as you wish.
The Gizmo UI is divided into 3 sections:

The “Light Removal Settings” tab contains settings to ease the removal of light sources. It basically works by smearing in edge pixels of the crop area. Most of the knobs should be more or less self-explanatory. Either refer to the tooltips or watch the example demo further down this post :)
The topmost part of the gizmo deals with outputting both the extracted lights and the cleaned up HDR. The output path is the root path to where both the HDR as well as the lights will be rendered to. If you have multiple light sources and consequently many HDR_Prepper nodes in your script you can hit the “Set all to this folder” button to make all other HDR_Prepper nodes use the same output path.
The “Light Name” is the name of the output for the given light that you are removing. Therefore each light needs to have a unique name, because otherwise they will just overwrite each other. If you have multiple lights of the same type (e.g. multiple computer monitors that illuminate the scene) you can call one of them “screen” or “screen1″ for example, select all the other nodes which are used for the other screens and hit “Set selected to this name”. That way the selected HDR_Preppers will be called like the current one numbered numerically.
The “Env HDR Output” section deals with outputting the cleaned HDR. You can give it a name, specify a format of your choice and choose wheter to convolve the output or not. Once your settings are set you just have to hit “Create Env Output” and the corresponding nodes will be created with the settings you have chosen. Keep in mind that you need to have the EnvConvole Gizmo installed, otherwhise this section won’t work.

Aaaand again, demos explain it best, so here you go :) :

HDR Prepper Update (Nuke Gizmo) from Julius Ihle on Vimeo.

The gizmo itself can be obtained HERE.

(So far only been tested on Linux but should work regardless of the OS.)

Sooner or later there’s always a project where lot’s of things have to be removed. Sometimes there’s not only the quantity but also the quality of work required to get good looking results. There are probably not a lot of people out there who love doing this, but it has to be done, so here are a few snippets of tips I learned over the last few months.

The first one is rather straight forward. It can give a good base for wire removal on moving shots where the wire is also moving. First of all stabilize your shot with a Tracker or a track from Mocha. After that you can time offset that stabilized clip a few frames until the wire has moved to another spot. Now just reapply the motion that you previously stabilized on the same reference frame. That way you will have essentially pretty much the same plate but the wire being offset. Now it’s just a matter of painting and keymixing to get a good base for a working wire removal.

The second one requires a bit more work. It’s pretty useful for wire removals aswell. You first of all need a proper set geometry of the shot you are working on aswell as a matchmoved camera. As soon as you got both into Nuke just go ahead and project the framerange through the moving camera onto the setgeometry. Pick a good frame where you can see most of the range you need to work, freeze the camera at that point and use it to render the sequence through a scanline renderer. What you now have is the whole sequence which is properly stabilized. If there is a bigger camera move and you want to get access to the whole stabilization you can add a crop below the renderer to ensure you encompass everything you need. At this point you can do a comparatively easy cleanup on your stabilized shot. To get back to your actual movement from the shot just your cleaned up stabilization through the frozen camera from before back onto the set geometry and scanline-render it through your shot camera. The description might be a bit cryptic, so here’s a quick screenshot which probably gives a better visual sense of what is going on :)