Nuke Tips – Normalize Depth Pass

Time to Conform to Normality

Another short Nuke Tips so without further ado let’s normalise/normalize!

If you output a Pz (depth) image plane from Houdini’s Mantra and read it in Nuke, you’ll see it as a solid flat colour and wonder why it doesn’t match the view in the Render tab or Mplay in Houdini.

What happened is Houdini remap the Pz data by normalising the min/max value to a viewable range for the artist.

So here’s what we can do to make it viewable (and usable for various compositing tasks) in Nuke.

  • Shuffle the depth channel to RGB and alpha to… Alpha. (this step can be skipped if you prefer to manipulate the depth channel directly)
  • Optional but you can use the CurveTool node and use the Max Luma Pixel operator to find the brightest pixel in the depth channel.
  • Use Grade node to remap the black and white point. Typically you can leave the blackpoint at 0 and set the whitepoint to the brightest pixel.
  • Another optional step but in case there is no valid sky dome geometry to represent the sky depth, you can fake it by using a Constant node with a value way higher than the brightest pixel and merge it using Under if you been following the above steps.
  • To adjust the midpoint of the depth, tweak the Gamma value.

This is the end result:

Here’s the node graph setup for your reference:

Why Normalize Depth Pass?

Seeing a solid colour in the viewer is not exactly practical!

This tutorial is more for Mantra way of handling the depth pass where it renders depth using the distance from the camera.

Pixels that are nearer to the camera are closer to zero and pixels that are further from the camera are represented by the distance from the camera.

Imagine you have a building geometry that are 100 units away from the camera, the pixel value will be approximately 100.

Traditionally most renderer will offer options to set the near and far clip value to render the depth pass but this are destructive as we “bake” the possible depth range to fit into the final depth render. Unless you render and export the depth pass at least in 16-bit Half Float or better 32-bit Float (which can be overkill unless you need the highest accuracy during compositing).

Further Reading/Viewing

Learn How to Render and composite Z-Depth in Houdini:

Houdini Rendering to Z-depth with Mantra (Pz) (Japanese):

Houdini – ZDepth Passes (Japanese):

Tutorial – Demystifying Camera Depth Passes in Maya Mental Ray:

The right way to render a depth pass:

VRayZDepth using 3ds Max:

VRayZDepth using Maya:

Houdini Tips – Fetch Cam Attributes for Imported Cam

Let’s Play Fetch and Blend with the Cameraman!

This is with default Houdini scale units (Meter).

Play around until it match whatever you’re doing from the original 3D software.

  1. Create Null and scale it (typically 0.01 for Max/Maya using CM although I’m unsure if units affect the total scale).
  2. Parent imported camera to it.
  3. Create Fetch node and fetch the transform in the Imported Camera node (e.g. /obj/s001c001_CAM_1203_v001.ABC/s001c001_CAM_trans)
  4. Create Blend node and parent it to Fetch. Only select the Transform and Rotation as the whole idea is to not inherit the Scale!)
  5. Create Camera node and configure it to match your imported camera settings.
  6. Parent the camera to Blend and verify it. Done!

If something looks off… repeat until it works.

And here’s the screenshots of the settings with the relevant parameters highlighted:

21 Jan 2018 Update: It seems that leaving the Weight 1 at 1 is a bad idea as it messes up the near and far clipping of the camera. Set it to 0 to fix the issue while still inheriting the translation and rotation of the imported camera.

What’s the Reason?

It is simply a BAD IDEA to scale a camera since it will result in wacky rendering artifact especially volumetric like PyroFX etc.

By scaling the imported camera with a null, all the attributes will be multiply by the new value.

Instead, we create a new camera in Houdini and retrieve the relevant attributes while maintaining the original scale when it was created.

Remember to NOT USE this scaled camera for renders! It will looks fine on the viewport but a disaster when rendering.

2018 Roadmap for taukeke

Happy New Year 2018 to my dear visitors!

This will be a short post on the planned content that hopefully will see the light of the day–

Before we proceed, check out the updated Demo Reel page with my FX works for the 3DCG anime Infini-T Force.

Since I’m still working on my Houdini FX reel (multitasking a lot of roles as a complete generalist is time consuming), I jot down a lot of tips that I’ll be sharing as… Houdini Tips!

The Roadmap

With the addition of Houdini Tips, I’ll be compiling useful Houdini and any VFX resources links on a dedicated page instead of spreading out as multiple posts.

It will gear towards artists who have experience in either 3ds Max or Maya though the node based workflow means a complete newbie to Houdini are at high risk of being admitted to the ICU.

If you manage to survive the Nuke workflow, Houdini does offer genuine quality of life improvement for FX tasks.

Also I’m a firm believer of quality yet lengthy tutorials like my recent gizmo creation for Nuke (which I still need to fix due to a bug that I overlook) so the following is what I’ve in mind:

Q1 2018

  • Preparing 3DCG Animation for Multi-Channel EXR Compositing in Nuke
  • More Nuke Tips and Houdini Tips

Q2 2018

  • General Python Coding in Everyday Production
  • More Nuke Tips and Houdini Tips

Q3 2018

  • Generic Project Management for Indie 3DCG VFX
  • More Nuke Tips and Houdini Tips

Q4 2018

  • I Got No Idea What This Will Be About
  • More Nuke Tips and Houdini Tips

Hopefully all goes according to plan!

In Other News…

…I’m currently available if any studios are looking for FX Artist (especially those from the 3DCG/VFX movie industry) but I’m stubborn in that I want to fully grasp the fundamentals of Houdini before working full time again.

Last But Not Least

Not to sound like a generic old wise man, if you’re a student or interested to join this industry… please learn Python or scripting like MEL Script (Maya) and Maxscript (3ds Max)!

Having those skills will be very handy in improving the rapid iterations when you’re working on a shot. Sadly I only got serious in learning to code by the tail end of the last project when I’m still working under the supervision of Digital Frontier Japan.

A lot of tedious repetitive tasks when working on the FX for GANTZ: O can be improved if I knew how to write a working MEL Script or Maxscript but that is another story that I’ll cover in the future.

Hmm I’m forgetting something… oh yeah do learn Houdini if you’re doing FX works!

Nuke Tips – Procedural Film Scratch (Creating Gizmo) Part 3

The Last Part in the Trilogy of Procedural Film Scratch

Apology for the delay as I got busy prepping BG (Background ) assets for my Houdini reel for the past weeks.

Here’s the link to the first two parts of the tutorials.

Nuke Tips – Procedural Film Scratch (Creating Gizmo) Part 1

Nuke Tips – Procedural Film Scratch (Creating Gizmo) Part 2

The EXPR Dilemma

First of all, there is a particular issue that I missed out in Part 2 on the use of TCL expression in Nuke.

I’ll let the following screenshots explained the issues.

Just in case for users who relies on machine translation when reading this post, to use the value of a variable in another variable, we need to use expr for it to evaluate properly.

Slight Modification to Scratch

If you’re up to the challenge, you can give the user choices in selecting the look of the scratch. Problem is I’m lazy and decided to modify the look of the scratch directly in the RotoPaint node.

Here’s how the new curly scratch looks.

Adding Chromatic Aberration

There are a few Chromatic Aberration (CA) gizmo out there at Nukepedia but let’s create our own version here.

Ok maybe the node graph above is pretty complicated since it involves extra nodes as part of the gizmo.

The following node graph shows a simple construction to fake CA effect.

The idea here is to scale a particular channel (usually the Red channel) in a radial zoom which the GodRays node does. You can try scaling using the Transform node but it creates an unnatural looking CA but might be appropriate depending on the look you’re after.

The following BG render from my upcoming Houdini FX reel demonstrates the difference between both methods.

With that out of the way, let’s look at how to export our gizmo for others to use.

Exporting the Gizmo

Before that, we want to write a simple Help description whenever the user hovers over the question mark icon at the top right of the properties panel.

Just right click on an empty area at the gizmo properties and choose Edit help.

Well the help stuff are optional but it can be beneficial to write a short and critical information about the gizmo. You don’t want the user to be left in the dark!

Finally remember to set a default value for all the gizmo parameters before we export it.

Exporting the gizmo is as easy as going to the Node tab and choose export as gizmo…

So we have export the gizmo… now what we can do with it?

You can either place it in the .nuke folder in the Home directory (the path varies between OS) and go to Other -> All Plugins -> Update to access the gizmo through the Tab menu.


Refer to the official documentation on how to access the custom gizmo:

The Finale of the Gizmo Trilogy

So we have reached the end of this three part tutorials and hopefully you have learned something useful from it.

One thing that I’ll love to add to the custom gizmo is an icon if you’re planning to access it from a custom menu and Dan Sturm wrote a good article on setting up a Nuke Gizmo icons.

As a reward, here’s how I abused the very gizmo that I created on a random train footage that I found on YouTube.

Still here?

You can download the tkk_FilmScratch gizmo by clicking this link and I’ll probably upload it over at Nukepedia in the near future after some minor modifications.

Happy Gizmo Nuking!

Nuke Tips – Procedural Film Scratch (Creating Gizmo) Part 2

Previously in Part 1 of Creating a Procedural Film Scratch Gizmo

In Part 1, we covered the process of creating a gizmo from scratch and ensuring the custom user knobs are working through the use of expression.

Albeit simple, the gizmo creation process is easy to learn but hard to master if we want to create a complex gizmo (take a look at some of the popular gizmo over at Nukepedia and study the node graph).

By the end of this tutorial, we’ll be able to generate this result using the gizmo:

What’s Covered in Part 2?

If you are looking for a complete walkthrough of creating this gizmo, I’m afraid to say that I’ll be covering the critical aspect of the gizmo creation only as it is better to get the hang of creating several basic gizmos before attempting this part.

As long you have the understanding of the following, you are good to go in troubleshooting the gizmo creation:

  1. TCL/Python Expression
  2. Using Variables in Nuke
  3. Google (or any major search engine)

Without further ado, let’s take a look at the node graph layout which can be further develop in the future.

Do not confuse this with an organisation chart–

Do take note that renaming nodes inside a gizmo are not necessary so you can leave the default name that Nuke generate like Reformat1, Transform3, Shuffle2 and so on.

Create scratch using RotoPaint

Just draw a line and you’re done!

Serious answer, it is better to setup a Reformat node with a low resolution (ideally lower than 512×512) since you don’t want Nuke to draw a high resolution scratch for faster calculation.

If you need higher res for a 4K Ultra HD output, feel free to bump it up according to your requirements.

Setting up Variables in Nuke

The best way to setting up variables in Nuke is to use a Text node and write it out in the Node tab instead of the Text tab.

To setup a variable in Nuke using TCL, use the following format:

[set variablename value]

[set variablename [value node.parameter] ]


projwidth [set projwidth [value root.format.width]]

projheight [set projheight [value root.format.height]]

minX [set minX $projwidth/3]

maxX [set maxX $projwidth/5]

minY [set minY $projheight/4]

maxY [set maxY $projheight/4]

You’ll notice there is a variablename prefix before the square brackets in the example above. It is to help us identify the variable as Nuke will only return the value of the expression in the square brackets. Here is more random examples:

month [set month November] = month November

rainamount [set rainamount 1000] = rainamount 1000

petrolJellySmear [set petrolJellySmear [value Blur1.size]] = petrolJellySmear 80

So how do we use the variables? Just append it with a $ prefix like $month and $rainamount in your expression although we can use it anywhere within Nuke like in the following example:

Using expression on Transform node for animation

To procedurally generate the animation of the scratch, expression is the way to go as you’ll unlikely to keyframe every single frame manually!

As I’m not an expert in mathematics algebra, do visit the excellent Nuke Wave Expressions by Cameron Carson to get a good idea on generating the desire animation curves.

In the above screenshot, you can see the expressions with the variables that I set up earlier.

If you have the Transform node active, you can preview the animation curve of the expression through the Curve Editor tab and the animation path on the Viewer tab.

After playing around with the various parameters in the expression, it is time to duplicate the transform node to allow us to configure the amount of visible scratches on the gizmo using the switch node.

Duplicate and expression tweak for variation

Once you’re happy with a particular expression, it is time to duplicate it and slightly modify the expression to generate another variation.

In the above node graph, the setup allow us to use the Switch node to control the amount of scratches by using expression to link the number on the Switch node with a pulldown choice knob.

Create dust speckle using…

…Noise node?

Nothing much to see here. Just tweak to your heart content to get the appearance of a flickering dust speckle and don’t forget to link the useful parameters to the custom user knobs.

Setup User Knobs to Access Relevant Parameters

The usual stuff. Add or pick the knobs that you will be using for the gizmo.

Do note that you can use HTML tags to customise the appearance of the Text knob as shown above with the bold tag <b></b>.

The current user knob layout for this tutorial.

As not every film scratch needs to be white on black background, I added an invert checkbox (linked to an Invert node) to allow for black on white background.

Depending on the situation, it can be redundant since a user can manually add their own invert node after the gizmo node.

Still it is nice to have the option built into the gizmo to save the trouble for the users.

Next in Part 3, Chromatic Aberration and Exporting Gizmo

For Part 3, we’ll be adding a Chromatic Aberration toggle (heh) and wrap it up by exporting the gizmo.

Hopefully you find Part 2 useful in your quest to create a custom gizmo that will save the universe. Just kidding.

Here’s another version of the procedural film scratch just by adjusting a few parameters on the gizmo.

See you next time in Part 3!

Further Reading