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

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

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

One of the great things about Katana is the ability to have a simple compositor right within your lighting/lookdev environment. I have been using its 2D features more or less extensively throughout the last couple of projects. It’s quite handy to tweak your HDR that you’re using right before you plug it into an environment light, without the need to go into Nuke again if you’re doing just smaller tweaks. Unfortunately Katana’s 2D interface lacks quite a few things that would make it a valueable alternative to Nuke for preparation tasks, because you have to wire more things together. So I was working on a few ‘gizmos’ to make the process a bit less cumbersome.

When I’m doing lookdev I usually try a lot of different environments to test my shading in. Now it could be that you would want to rotate each HDR slightly differently because maybe the main lightsource should come from a different direction. As rotating the envlight everytime you test a new HDR isn’t non-destructive at all I built a simple group that imitates Photoshop’s offset feature:

The maximum offset distance is defined by the image width/height. So if the input image has a width of 2048 pixels you cannot offset it more than +/-2048 pixels in x.

Also in case one decides to go for an environment-only lighting workflow you still want to have a good control over the individual lights in your HDR. This workflow gives you less control, as you cannot move individual lights around, but is much quicker to set up. When going this route it helps if you can still tweak the intensity of the individual lights within the HDR and maybe slightly adjust their color. So I mashed together a very simple group that emulates Nuke’s default Keyer-Node. It outputs the resulting key into the alpha while leaving RGB untouched. Controls should be self-explanatory.

Now this might work for some cases. As the name implies, it’s just a simple keyer however. Here’s another example HDR:

Let’s say one would like to grade the sky, because we are a bit picky about the blue shade of it :) If you were to try to use the simple keyer you would not be able to properly isolate just the sky because the sun and the bright screen-left building also have very high values in the blue channel. So I created a slightly more sophisticated keyer for those kind of purposes:

Hm, interface-wise it looks pretty much the same like the other keyer… What’s so fancy about it? This one does not work on one channel at a time, but instead looks at the difference between channels. If you were to set it to blue, like in this example, it will basically just isolate the areas in which the blue channel has higher values than the average of red and green. Apart from that it also features the option to pull a saturation key, pretty much identical to Nuke (Colorspace RGB->HSV or Keyer set to “saturation”), except for the fact that it works in linear space, instead of sRGB.
Here’s an example matte overlay when isolating a matte with this Keyer – as you can see the sky is quite well isolated and does not include the sun or other bright bits of the image:

So without having to wire up a whole lot of stuff one can get masks comparatively quick. What I personally like to do is having one base image that I can use for mask inputs. I just wire my mattes for the individual lights together so that I have the different lights isolated in R,G,B and A. So after I have my keys I can crop out the areas I want and recombine them using my “channel_shuffle” group. Controls are quite simple. One has to specify which channel they want to use as an input and into which channel the input should output to (similar to Nuke’s shuffle node… with a less pretty interface :) ). That way you can quickly get one RGBA matte using crops to isolate the different keys:

Then it’s just a matter of using them on a gain-node for example to tweak the exposure of the individual lights.

Example file is HERE to play with.