//EDIT: Now there’s also a really cool VFX and Animation Reel with some fun stuff! REEL LINK

Constraining things in Katana works well, but can seem somewhat limited if you are coming from a full-featured 3D application. One of the things that can potentially give you headaches is a missing option for “maintaining offset” when you are constraining one object or a lightrig to something else. While this is generally not an issue when you are doing LookDev (as your assets most likely have zero’d out transforms) it can be a bit frustrating to not have that option when you are working on shots, so here’s my hacky way of maintaining constraint-offsets.

Every now and then you have to constraint lights to an object in your scene. Generally the best practice is to create a rig in the Gaffer node and constraint it before adding any lights. That way you don’t have to worry about fixing anything later. If you are a day-dreamer like me however it may happen that you add a rig and all your lights to your object before you constraint anything:

Consequently when you come to the point of constraining your parent rig (which was most likely in the origin) will move to your constraint target and offset all the carefully placed lights you just created:

Bummer… However luckily with a few steps you can re-center your rig to where it was before constraining it.
To do that first of all add a ConstraintResolve Node. This will convert the constraint data into a matrix to give you the actual world-space position. The resulting numbers for the matrix visible in the Attributes-Tab may not really be too much of a help right off the bat. You can add a TransformEdit Node and plug in your constrained rig into the path to to show you the actual transforms:

Now that you know where your rig has been moved to you can reverse this transformation. There are a couple of ways to do that but I personally like to do it in a separate rig:
-Add a new child-rig to the rig you have constrained to your object and move all your lights below it
-Copy over the transform values from your TransformEdit Node to your constraintOffset rig and negate them (-22 becomes 22 // 749 becomes -749 // etc.)
-Inverse the transformOrder (Scale Rotate Translate becomes Translate Rotate Scale, etc.) and the rotationOrder (XYZ becomes ZYX, etc.). This is assuming you have used the defaults in your rig – adjust them if you have used different orders.

This way your constraintOffset rig should be perfectly centered out again and your lights should be where they belong:

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

The original question came up under the post of my HDR Prepper Gizmo for Nuke:

I have a question, how do you adjust your lights that are skewed and need to be formatted to fit your area lights? Do you adjust your arealights scale to match your bounding boxes? This example is kind of made for this scenario however there are many lights that are distorted and need to be flattened for your arealights. Im curious as to how your workflow solves this.

Which is a more than valid question as I have used a very simple-to-work-on example when I was demoing this Gizmo. However more than often in production the HDR’s you receive will most likely either have lights or other objects you might need to remove at the poles of the LatLong environment map.

A good example for it is this HDR map that I got from HERE:

 
All the lights on the ceiling (especially the one circled in red) would be very hard to paint out like this and you would need to distort it heavily to get it straight and map it on an arealight.

Luckily there’s a node available in Nuke, that is called SphericalTransform. With this node you can convert between different environment map conventions (Latlong, Mirror ball, etc.). One thing you can do is convert your input Latitude / Longitude map to a cubic map. Visually what you can imagine what it’s doing is that it seemingly puts you in the middle of the environment map (at the original position of the camera) and allows you to look around from that point of view. The output will be undistorted from the point of view of the camera (provided you set your output format to a square format):

As you can see in this example I rotated my input around so that it looks at the ceiling and directly at the light that I am trying to remove. Now that exact light is nice and square and very easy to paint out:

Or you could also use this handy little thingy: HDR Prepper Gizmo ;)

Once that is done you can convert it back from Cube to Lat Long map with another Spherical Transform Node. There are 2 things to watch out for to make sure it matches your original HDR orientation:

• Make sure your Input Rotation Order is the inverse of your first Spherical Transform (e.g. ZXY -> YXZ)
• Negate all the numbers from your first Spherical Transform (e.g. 90 becomes -90 and vice-versa)

You can then either make sure your alpha is completely opaque before converting it back to LatLong and merge it on top of your original or Keymix it back in in exactly the areas where you need it.

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

I have recently started getting into Shader Writing in OSL (actually rather Pattern Writing just to not get frustrated too quickly :-) ). To start things off I wrote a simple Pattern that lets you create a life 3d mask in your shading network that can be used to alter different shading effects in very particular areas of an object without the need to paint texture masks. On top of that being OSL it should work in any renderer that supports it (e.g. PRMan/RIS, Cycles in Blender, VRay, etc).

The Pattern itself only has a few simple controls:

PMask OSL Pattern inside Maya with RenderMan (PxrOSL Node)

Here’s a quick explanation:
Mapping – determines whether to use world- or object-space for the 3d mask (choose PWorld or PRef). Unfortunately the PxrOSL node in Maya ignores shader metadata for creating a nice dropdown menu here (Blender users might be luckier :)).
Radius – The X, Y, Z (-> R, G, B) scale of the spherical mask.
Whitepoint – Values below 1 will move the core towards the outside edge
Blackpoint – Values above 0 will move the outside edge towards the core
Gamma – Can be used to increase or decrease the falloff

All of these parameters are mappable, too! In the case of this Tool this has some very nice benefits.

The first one is that you can create a locator for example and map its translation to the Pos input. If you are using PWorld as your Mapping type it will use the world space coordinates so wherever you move the locator the mask will go as well. However assuming you are not animating the locator this will be a static mask in worldspace and any objects which are animated will swim through the mask.
If you want your mask to follow your object you can set the Mapping to PRef. This will use the coordinates of the objects translation and deformation from a reference position (zero’d out transforms) and will make the mask stick to the object wherever it’s going. Keep in mind that the Origin for the position (0,0,0) is always wherever the object has zero’d out transforms. This means that you might need an offset if you have frozen your transforms at one point. Another alternative would be to parent or constraint a locator to a moving object and leave the Mapping set to PWorld.
To double-check the coordinates the OSL node allows you to output PWorld and PRef for debugging purposes (you can take the RGB color values of a point in the render as your Pos value).

Also most of the time a simple sphere is not very desirable, so you can also map the radius with other procedurals or textures to break up its shape.

Because this is based on position data it’s completely independent of the object’s UV’s.

You can download it HERE.

Here’s a quick demo video:

3D Position Masks in OSL for Shading Networks from Julius Ihle on Vimeo.

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

One of the worst things to sample for any brute-force ray tracer are specular highlights / reflections with a low roughness in motion blur. Even worse so on fine displacements or bump. And EVEN more worse with lots of small highlights. When all of these things come together sampling these highlights in motionblur is going to become really hard and with conventional methods you will end up having to rely on extemely high AA samples and even then the highlight-streaks will most likely still be dotty… And you won’t make any friends if they have to paint these streaks smooth in Comp :) So during the crunch time of a recent project I was brain storming with some of my collegues how this could potentially be fixed without needing too much samples and I’ve been working on implementing that idea which seems to work quite nicely.

If you try to sample this speedy fella in an environment like that with this look you will inevitably end up with streaky specs.

So how do you fix it without changing the look? Let’s say you have a simple scene like the following:

In this case I’m using Arnold, but the base concept is the same with any renderer. Low roughness on the specs + bumpy surface + lots of harsh highlights result in something like this when you turn on motionblur:

This one already has 12 AA samples + 2 light samples. It won’t get much smoother just cranking up the samples, but trust me it will render longer :) One way to smooth the streaks out however would be to increase the roughness and decrease the bump / displacement.

That looks way better. However the problem with this is that these adjustments will affect the look a lot and the asset will look very different in non-motionblurred frames. So let’s make it work only when the character is in motionblur.
Most renderers offer some sort of a node that allows you to extract the motion vectors from a moving object, which basically define what distance each point on an object travels from one frame to another in XYZ.

As you can see we get quite big values for this frame just outputting the raw motion vectors. It’s very important that they are in a raw format and not normalized, because otherwise you won’t have the actual movement distance but just something normalized (positive values between 0-1) to make it better visible.
Now these negative values won’t help us much. Eventually we want to be able to use this infortmation as a mask to switch between rough/blurry (for motion blur areas) and sharp reflections (for non-motionblurred areas).
So let’s make sure these values are always absolute.

This way no matter what the motionvector outputs, they will always be positive. Now we need to convert this to a float to make it useable as a mask. In this case a simple RGB to luminance won’t quite cut it as you will have a weighted average of the movement in X,Y and Z. You can use a max or a sum of all the three channels to always make sure you grab the biggest motion.

The only thing left to do is to bring the whole thing into a suitable normalized range to be able to use it as a mask. How you are remapping it, depends on at which point you want to completely switch from one roughness to the other. If you have your usual range/remap node you can specify with the input max at which point the value of the resulting mask should be 1. If I’d set it to 30 for example, as soon as the motionvector reaches a value of 30 it will result in a white mask and it will smoothly blend to 0 for areas/frames with no motion. We can use this mask then to mix between 2 roughness and bump values or textures. This way we retain the look of the original asset and have nice and smooth motion blur.
Here’s a before and after frame with this method. Both have the same sampling settings

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

Judging from some messages I received recently there seems to be an ongoing interest on using Linux at home on your Desktop. Some people might want to try it out, because they are searching for an alternative to Windows or OS X or just because they want to try out something new and explore the possibilities of Linux. But there are a few things to consider before getting into the world of Linux and most people are a bit overwhelmed at where to start exactly so I will try to give some tips that helped me personally in setting up a working system, alongside some examples why Linux is my personal favorite.

Is Linux really for me?
Before you get started you should ask yourself one main question: Will I really benefit from using Linux? You might have heard that pretty much all big VFX facilities use Linux as their man operating system, but that doesn’t necessarily mean it’s a good choice for your home setup, too. Bigger studios use it as their main platform, because traditionally the VFX industry has always been Unix-based. When the SGI (Irix) train went downhill the most obvious choice to convert to was Linux. It had several advantages: It also was a Unix-based system, so transferring over the pipelines built on Irix was a fairly straight forward process. Also it was cost-efficient, because first of all Linux in itself is free and it wasn’t bound to proprietary hardware. Linux in general scales very well in a multi-user multi-software environment where access-time to many (large!) files by many different users/computers at the same time is as crucial as it is in VFX. With Linux being open source studios also had the freedom to modify the operating system in whichever way they wanted which allows for huge flexibility because you can tailor every component of the OS to be as efficient as possible on the hardware you put it on and to do whatever you want it to do.
Due to that flexibility the performance of Linux usually is at least up to par with Windows and OS X, often times even out-performing other OS’s in terms of rendering speed and OpenGL performance.
Now that might all sound well and nice for bigger companies but what about home-use?
First and foremost question: Will my applications run on Linux? Quite a simple answer: Some will, some won’t. To find out which software has native Linux support is quite easy by checking the system requirements of the software in question. Nowadays most vendors for serious CG & VFX applications do provide native Linux support for most of their software. Pretty much everything from The Foundry (Nuke, Mari, Katana, Modo), Maya, Mudbox, Houdini, Clarisse, Mocha, Silhouette, UVLayout and a lot more. Likewise most plugins and extensions, like 3rd party renderers provide Linux support as well. However if your workflow is centered around ZBrush, 3ds Max and Photoshop Linux will not be for you.
Also it depends a bit on how tech-savy you are and how much you are willing to learn and explore. While nowadays you don’t have to utilize the command line as much as a few years back you still have to go there ocassionally because it’s either faster that way or because there’s no GUI solution (yet). That is not to scare you away from the command line, because while it may seem daunting at first a big part of how you interact with the system is often times faster through  the shell and it’s not really difficult to get the hang of it either. For starters I’d recommend this article, which gives a much better introduction to the shell than I could ever give :)
But Linux is not only for geeky command-line nerds. Most of the modern Desktop Environments that you can use with Linux offer amazingly intuitive concepts that make working, especially with CG apps, extremely comfortable. I’ll get into more of that later.

So WHICH flavor…?
As you may or may not know Linux is just the Kernel – the core of the operating system that is responsible for allocating the hardware resources to the programs running on your system. For using it in conjuction with things like a graphical user interface and utility applications there are several distributions of Linux available – Ubuntu, Fedora, Mint, OpenSuse and hundreds more. They all ship with different Desktop Environments and applications. And this is kind of the area where new users have trouble starting. Because of the overwhelming number of choices it’s hard to know which one to pick.
But fortunately the VFX industry has more more or less standardized on RPM-based systems. Most studios pick CentOS for 3 simple reasons: It has a very long support cycle (7 years), it’s a free version of Redhat Enterprise Linux which is built with a high focus on stability and scalability and it’s the primary system that most Software vendors support (Autodesk, The Foundry, SideFX, etc.). That doesn’t mean that you cannot use debian-based distro like Ubuntu or Linux Mint, but going the CentOS route generally seems to be the more obvious choice.
At the time of writing this article, most studios are on CentOS 6. CentOS 7 has been released a good while back and might be a better choice for home-use, especially if you are on a Laptop, as it features a newer kernel and generally more up-to-date drivers for newer hardware.

… and Desktop environments?
Just like there are hundreds of distributions, there are also almost as many desktop environments… sigh.. even more choice. This is a bit of a tougher one, because there are many very good choices. At the time of writing a lot of the bigger studios are either using Gnome 2 or KDE.
On Windows or OS X you basically have the desktop environment that ships with the OS. Both systems have Desktop environments that work really well, but you are slightly limited on customizing them to fit your needs. On Linux you can choose between a multitude of desktop environments, that allow you tailoring your Desktop to do exactly what you want it to do. You Can have multiple panels (windows-style), docks (OS X-style), and lots of stuff inbetween with tons of nice widgets that really can easy your workflow.
Gnome 2 is the standard Desktop environment in CentOS 6, which a lot of the bigger companies are using as their primary system. It is a good mix of being low on resources and still features a good amount of customizability. However CentOS 6 is one of the last major distribution using it as it has been replaced by Gnome 3 now. So what about Gnome 3? While it arguably has a very nice look to it, the problem with Gnome 3 is that it heavily relies on your hardware, especially the graphics card, to render various desktop effects that cannot be turned off. It also stripped down a lot of the customization options that have been present in Gnome 2. There are alternatives however. MATE, which is a fork of Gnome 2 that is aiming to keep the traditional Desktop alive and XFCE, which is a very light Desktop environment that offers similar a similar feel to Gnome 2.
KDE is probably a good choice if you are coming from a traditional Windows Desktop, as it has a similar default layout. The real power of KDE however lies in it’s customizability. It’s one of the most flexible Desktop environments and you can set pretty much every option for anything you can imagine. By default KDE can however be quite a memory hog and hungry on computer resources. Luckily due to its flexibility it can be adjusted to use very little resources, while still remaining highly configurable.
If you are working in a studio and you would like to find out which Desktop Environment is currently in use, you can open a terminal and execute echo $XDG_CURRENT_DESKTOP or echo $DESKTOP_SESSION to print out the current DE.

OK, enough of the boring text, let’s have a look at some of my favorite Linux Desktop usability tricks. I’ll focus on Gnome 2/MATE and KDE, but most features apply to other Linux Desktop environments, too.

Quickly moving / resizing your windows.
On Windows or OS X when you want to move a window you have to click-drag the title bar. Similarly you can only resize floating by click-dragging the corners of windows.
On Linux you have modifier that allow quickly accessing these functions. For example you can assign the windows-key as a window-modifier key. That way you can hold the windows key down and move a window by just clicking and dragging anywhere on it. And use the windows-key and middle mouse or right-mouse click-drag to resize it depending on what corner you are closest to.

Keeping windows always on top.
Let’s face it: You never have enough space for all of these floating windows, right? Let’s say you are modeling something and you need to keep a reference image somewhere around. In Linux you can keep windows always on top for quick reference:

Rolling windows up, instead of minimizing them.
The more windows you have opened simultaniously the more messy your task-bar becomes. This gets especially bad with applications that have lots of floating windows (like Maya). Instead of minimizing them, you can just roll them up to minimize them to their window decoration. They are always on your finger tips but hardly take any space. Most commonly this can be set by double-clicking the title bar for example.

Multiple Desktops.
Coming from OS X (or by now, even Windows 10), you’ll be happy to find that Linux also features multiple Desktops. If you haven’t used them yet, you’ll love it. Linux also takes this functionality one step further, by making it really easy to move windows around to a different workspace.

Filebrowser-fun:
Most file-browsers support tabs, just like web-browsers. You can quickly jump to another directory by editing the location-bar (usually Ctrl+L in most file browsers).
Also Nautilus (File-browser on Gnome) has this really awesome to select files or folders by pattern via Edit – Select Items Matching… (Ctrl+S)

Similarly Dolphin (File-browser on KDE) has a Filter bar under Tools – Show Filter Bar (Ctrl+I). Additionally it allows you to split your view in the file browser for working quickly in 2 directories. If you want to get familiar with the command line you can also enable a Terminal display that live-updates your file browser with the commands you enter

Panel Addons
Most Desktop Environments work with panels. Those panels have widgets that you can put on them. You can constantly monitor your system activity, switch your workspaces, place shortcuts for files and folders, and so on and so forth.

Those are my personal favorites. Along with some other things this makes working in Linux a real bless in my opinion.

And while Linux has its benefits, there are also downsides. Due to its customizability in pretty much every aspect it also has somewhat of a learning curve, so if your goal is to simply install the OS and get going like you would if you were new to OS X or Windows, you’ll have a bad time. There are times when you have to use the command line and while it is an extremely powerful tool, most people tend to not really like it that much. On the bright side, Linux supports pretty much any hardware without the need to install additional drivers – mice, keyboards, external sound cards, wifi-sticks, you name it. However if you are one of the unlucky guys that has that one piece of proprietary hardware for which there is no Linux support you’ll be left in the dark. Likewise with software. Most free apps are available on Linux through repositories just like they are on Windows or Mac OS – VLC, OpenOffice, Firefox, Chrome, Skype, etc. However if you have to compile stuff for your system, because it is not available for your distribution it will end up in frustration.

That being said, if you are working in a studio environment that uses Linux as their main OS and it’s set up properly you will be able to enjoy its benefits without needing to worry about the technical nitty-gritties, because this is what IT will take care of :)

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

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:

The new RIS mode introduced in RenderMan 19 is a completely new render-engine that is very different from REYES. Being a brute force path tracer (uni- and bidirectional modes) it works much more like other renderers that follow a similar approach (e.g. Arnold). That approach aims to make the render process more simple and interactive. And while I personally don’t like it completely yet it seems to get widely adopted in the film industry and we all have to adjust to it sooner or later :)
The good thing about RIS is that it offers a much more interactive way of working. The interface and controls are much simpler now and offer easier controls to tweak your renders. However this comes at the price that compared to Reyes I have seen final rendering times increase by 3-6 times, because all the hacks are removed for a “physically plausible” workflow.
Now because there is not a lot of stuff you can tweak to squeeze rendering times it is important to understand how sampling in RIS works. RIS uses importance sampling, which in layman terms means instead of uniformly sampling an area above the hemisphere it concentrates samples around the areas that are more important (e.g. brighter, higher solid angle, etc.). Here’s a good example comparison with 2 objects – just 1 high contrast environment light importance sampled vs uniformly sampled (same number of samples):

Importance sampling is the standard sampling method in PRMan (both REYES and RIS) due to its obvious benefits.
The main settings in the render globals that control the quality of the final image are the following:
Min Samples
Max Samples
Pixel Variance
Light Samples
Bxdf Samples
Indirect Samples

The way it works is fairly straight forward: Min- and MaxSamples are a global setting for every kind of sampling in your scene (AA, Light, Shader, GI Sampling). The amount of Samples for each of those will never be higher than MaxSamples and never lower than Min Samples.
The parameter to control whether the Sampling biases towards Min or Max Samples is the Pixel Variance. Starting with Min Samples RIS will check the contrast (=noise) between the current sampling-point and those around it. If that contrast is higher than the value specified for Pixel Variance it will adaptively continue to shoot more Samples for that point until the contrast is equal or lower to the Pixel Variance (with Max Samples as a maximum). Therefore a lower Pixel Variance will increase the likelyhood of more rays being fired and therefore a better quality image (and also longer rendering time).
As noted before the problem with just using Min/MaxSamples/Pixel Variance as your global is that it affects all the Sampling in your scene. So if your shadows are grainy for example, but speculars, GI, motion blur, etc look clean, increasing the MaxSamples or reducing the Pixel Variance might give you clean shadows but also waste samples for all other sampling methods in your scene.
Therefore you also have Sampling controls for Lights, Bxdf’s and Indirect rays. Which one of them to use in a particular scenario depends on a couple of factors.
Indirect is the most obvious knob. Increasing it will spawn more indirect rays after the first bounce (=rays that cannot be directly connected back to a light source). This inhabits indirect diffuse, indirect specular (reflection/refraction) and subsurface. You can gain finer control over the sampling counts on each of these by changing the SampleMode from “bxdf” to “manual”. That way you can specify exact values for a given indirect ray type.
When to use LightSamples vs BxdfSamples isn’t quite as obvious at first. It depends on what kind of surface you are shading. The main indicator here is the lobe of the BXDF. Let’s say you have a plain diffuse material. Increasing the Bxdf samples in that case won’t benefit you much, because a diffuse surface naturally has a very wide lobe. That way increasing the sampling on the Shader will result in a lot of wasted samples:

Note that all the renders are scaled up crops to better show the sampling problems.
However if you are using Light-Sampling things get a lot more efficient as you are now shifting the importance towards the lights:

In comparison to get a similarly clean image by solely adjusting the Min/MaxSamples and PixelVariance and leaving LightSamples at its default of 1 you will waste a lot of rendertime to get the same result:

As you might have guessed for direct specular shading that has a very tight lobe (=more mirror-like) it works the exact opposite. Because the lobe is so narrow adjusting light Samples globally will most likely not reduce noise as it’s very unlikely for all the lights to have an effect on the given point of shading:

…increasing the Bxdf Samples however is way more efficient:

And once again, just using Min/MaxSamples and PixelVariance to adjust the quality wastes more time than needed:

Now, what about rough speculars? Often times reflections are having a broader lobe which sits somewhere inbetween that of a rather mirror-like specular and a diffuse lobe. In that case you have to mix between Light- and Bxdf Samples. Due to RIS taking advantage of multiple importance sampling it tries to automatically allocate samples that make the most sense for the current shadingpoint. But as a general rule of thumb I personally found that for a roughness of ~30% using the same value for Light- and Bxdf Samples gives a good starting point. If the spec gets more shiny you bias towards Bxdf Sampling and if it gets rougher you bias towards Light Sampling.

Once the direct light components are noise-free, indirect noise tends to be a bit harder to tackle as this will be the main source of noise most of the time. Often times unfortunately adjusting Indirect Samples will only get you so far until render times start to explode:

The MaxSpecularDepth in this scene and on the objects is 4. As you can see even with 10 indirect samples the render isn’t really as smooth as it should be. Luckily you have 2 more options that can help eliminate noise. Clamp Depth and Clamp Luminance. Sampling Fireflies usually happen when there is a big contrast between higher and lower luminance sampling points. The clamp controls try to get rid of those brighter samples to reduce the noise. If you for example set the clamp depth to 2 and the clamp luminance to 1 it means that starting from the 2nd bounce of the light path (be it diffuse, specular or subsurface) the sample intensity will be clamped to 1, meaning no samples at this depth have a higher value than the one specified in the clamp luminance:

As you can see the resulting image is much cleaner. I was even able to reduce the indirect samples and still get a cleaner result and lower rendering time. However you also have to be careful to not set your clamp luminance too low as this might produce too washed-out-looking bounces.
You can also control indirect sampling through the Roulette Depth/Threshold Control. This will randomly terminate a percentage of samples (threshold) at a given depth. The default values of 4 for roulette depth and 0.2 for roulette threshold means that starting at the 4th bounce of light 20% of the samples will randomly be terminated. This control is useful if you have a lot of light bounces and want to get rid of unneccesserely low-importance samples at larger depths. And while it reduces render times nicely it also reduces quality at the same time, so those controls should be used with caution.

As a general workflow what personally worked best for me is to usually
1) Adjust Min-/MaxSamples and PixelVariance until I get clean Anti-Aliasing and motion blur (..and DOF).
2) Check the diffuse_direct AOV for noise and increase Light Samples if needed
3) Check the specular_direct AOV for noise and balance between increasing Bxdf/Light samples Samples if needed (depending on spec roughness)
4) Check diffuse_indirect, specular_indirect and subsurface and increase indirect Samples as needed
5) Try to play with Roulette Depth/Threshold & Clamp Depth/Luminance to eliminate fireflies

I always try to not go higher than needed with Min-/MaxSamples and PixelVariance. They tend to be the most sensitive control and increase render times the most.
Also often times globally adjusting a sampling type may be excessive when only one light/surface produces noise. For lights you can adjust samples individually, which is quite cool if you have a scene with lots of lights but only the shadows from your keylight are noisy for example. Unfortunately individual sampling controls for controlling the sampling on shaders are not exposed in the out-of-the-box pixar shaders, so unless you create your own you have to adjust Bxdf samples globally.

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

During the last year I luckily had some time to spend on digging a bit deeper into Katana. From working on assets and shots I experienced some moments where I thought it’d be great to have some basic tools to help get the job done just a little bit quicker. So whenever I had a bit of spare time I was developing some Macros/Gizmos/Tools to help artists on some common problems.

Katana Macro/Tool Dev from Julius Ihle on Vimeo.

One of the tools is a macro that helps managing multiple lights. Based on a CEL you can freely modify exposed shading and transform parameters. This especially comes in handy in scenes with bigger environments that have to be lit with multiple light sources. It also features some randomization controls for lightcolor and rotation & scale.

Next up we occasionally had some shots that required very accurate light cookies/gobos based on the plate. On recent shows we for example had some shots of characters walking through the woods with quite direct lighting which caused very complex noticeable shadows from the tree’s branches and leaves. In some scenes one could get away with putting just some random lightcookies as projectors (slidemaps) on the lights, but others needed a more accurate solution. This is a macro I have been working on which automates the whole process:

It basically works this way: You project the plate through the render camera onto the set geometry and render that result back through the light source which will should give you a proper light gobo. Now, there are usually a few things to consider, like the camera’s focal length, pre/post transformations of the plate to match the light’s scale and so on which all depends on the way the slidemap is implemented into the shader. On this one no one had to worry about it, because it’s all handled automatically :) The only drawback is that the generation of the resulting cookie involves a 2-step rendering process (projection on geo and post-tweaks) which makes it not as interactive as it could be, but luckily those renders go through really quick at least.

Here’s a quick run through on a previous set up which is based on the same technique, but a bit more manual and goes through Nuke. This should also work with really any setup that requires building accurate light cookies.
Say this is your light setup (in this case in Katana, but could be Maya, Houdini, or whatever):

You replicate the same thing in Nuke importing the same camera and set geometry. You project the plate through the rendercam onto the set geometry and copy over the light transformations from your 3D package into a new camera, which you then render through:

The tricky part is getting the correct settings for focal length, etc. on your camera that resembles the light, which involves a bit trial and error. You can then just desaturate the map and grade, paint and do all the fancy comp stuff to make it do what you want and then use it on your lights:

When the guys from FX do their magic and blow things up into thousands of pieces that’s always awesome. Anyone in comp is usually happy if you provide them ID’s for just about anything so, provided the FX cache contains separate geometry pieces or face-sets that’s pretty straight forward with this ID randomizer:

When Lookdev’ing assets it always helps to ensure some consistency between the renders. While we had templates that managed chrome- and greyballs and rendercameras, we didn’t have a setup for the turntable itself… Well, now we have:

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m

In the process of trying to streamline things a bit more in my day-to-day workflow I have recently been working on a hand-full of small helper tools. One of them is a small set of scripts that handle the conversion of a selection of files to Arnold & RenderMan’s native .tx/.tex files from the filebrowser… because people like the GUI, right? :)
Unfortunately for anyone out there on Windows or OS X they won’t be of much use I’m afraid. If you are on Linux and using Gnome or KDE as your Desktop environment (others may work, too) this might come in handy. The file conversion is being handled on a selection of files through the standard right-click context menu:

Upon clicking you will be presented with a little pop-up menu that allows you to enter additional options for the conversion if needed. Anything that’s noted in the -help docs of the respective commands should work in the dialog boxes. Upon specifying your options there’s time to grab another cup of coffee… The progress bar will let you know when it’s done :)

By default it is assumed that the bin folders of Arnold and RPS are part of your $PATH environment variable, but if you need to change it the code should be fairly easy to read (although it looks a bit messy because it’s 1 line :) ) and can be modified to suit your needs. The dialogs are using KDialog and zenity (for KDE and Gnome respectively), but those should come by default depending on what desktop you are using.

To use them on KDE put the attached .desktop files in ~/.kde/share/kde4/services/ or /usr/share/kde4/services/ (for all users).
For Gnome you need to install nautilus-actions and import the attached .schemas files. Once that’s done just restart nautilus/dolphin or log out and log back in again.

Tested on my laptop with CentOS 7 (KDE 4.10.5) and my trusty old CentOS 5 testbox (Gnome 2.16.0). Unfortunately I don’t have my main workstation around to test it on CentOS 6, but it should work there as well.
//Edit: Now also tested & confirmed working on CentOS 6.

Arnold .tx Converter for KDE
Arnold .tx Converter for Gnome
PRMan .tex Converter for KDE
PRMan .tex Converter for Gnome

 
_________________________________________________
If this post has helped you in any way you can express your gratefulness by using the Donate Button below to buy me a coffee! :)

3M5xNSV7g2NzVpHMqzYKhgoKJZ8CWa644m