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

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:

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.

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.)

Primitive Variables are a really cool way to get variation in Renderman Shading Networks. As it requires adding Attributes to your Shape Nodes within Maya to control the variation it can be quite time consuming to set it up. So I was trying an attempt to build an interface that helps a bit with the set up.The GUI let’s you choose a name, the PrimVar type and min/max values of which it will randomly pick floating point numbers within that range. It is also possible to just use integers with the according checkbox. The GUI is far from being pretty or well organized, but it does the job. :)

As I am a bit short on time however I just had the time to properly make use of Float PrimVars as that’s what I need for a current project I’m doing. As with all my scripts they are not written very well, but should be kind of readable. So feel free to modify it as needed. I hope I will find the time soon to make the other types work properly.
So for example using 3 PrimVars with just one shader on all objects results in loads of variation… Which is always a good thing :)

Additionally as you can see there is also an “Object ID” part in the GUI. It let’s you add integer PrimVars with increasing values for each object. At the same time it will add an AOV with the same name like the primvar (of course this custom AOV has to be set up in Slim beforehand).
An alternative approach to making Object ID’s would be having distinct floating point values for each object. So the value that get’s assigned by the script corresponds to the value that is being rendered within the Object ID AOV. For example object 3, that has the Object ID primvar value of 3 assigned has a value of 3,3,3,3 for RGBA. The good part is that it is very easy to set up, but one may run into aliasing issues when dealing with very thin geometry for example. To make use of this technique I also prepared a Nuke Gizmo that handles these kind of Object ID’s and has a slider to separate them.

Also here’s a quick demo:

Simple PrimVar Helper Script from Julius Ihle on Vimeo.

So hopefully I will find some time to complete the script, but for now if anyone’s interested feel free to grab it from HERE.

CG fur always has the tendency to look very clean and soft. To break up the structure and to give a bit more realism I like to mix it with a bit of dirt, e.g. some leafs or sticks in the fur of a character walking through the woods. Here’s a quick rundown on what I’m doing to achieve this using Yeti and Renderman within Maya.Let’s start with a simple sphere and some clumpy fur on it to get started. This is my base fur setup.

What I’m doing next is to create another YetiNode on the same Mesh. This will be (one of) my dirt layers. In this example I’d like to have some leafs between the fur strands. For this I’m going to use polyPlanes with textures on them. So to distribute those planes along my sphere I need to first of all get some guide strands lain out. To make the planes take the direction of the fur I have to create a custom comb attribute which I’ll call “dirt_dir” in this example. So after comb’ing the grown fur with the groom I’m going to create yet another comb which has a comb attribute called “dirt_dir” in it.

Next I’ll import the planes which are supposed to hold the leafs and instance them on the fur strands. For the alignment I’m going to choose my “dirt_dir” attribute to make the planes align along the fur strands. For this to work I have to set the “Instance To” to “Elements.

To get a bit more variation and randomness one can also change the alignment, scale and twist variation as well as tick the “Deform” checkbox in the “Objects” tab.
Alright, now that this is setup you can assign a simple Shader which holds a leaf texture for example and render and you’ll have a bit of dirt between the fur. However I personally like to have a bit more control over things in comp, so let’s take this a step further. I’m going to set up an AOV which holds the color and alpha of the leafs respectively, but the actual fur render will not contain the leafs at all. To set this up, I just map the leaf’s color to the diffuse and the leaf’s alpha to the mask input of a GPSurface Shader. Also I will turn up the transparency to full white because I don’t want the leafs to appear in the actual beauty render.

For more information on how to set up custom AOV’s in Slim there’s a nice explanation over at pixar.

When rendered and everything is set up correctly something like this should come out:

Of course with a bit more sophisticated than just planes with textures on them one can get really nice results while still maintaining a lot of control. One thing I might add is that the color AOV of the dirt  should actually be rendered without the fur being visible. Otherwise as you can see it will be held out by the fur aswell, which could lead to premultiplication issues in comp. In this example it’s not really obvious but there might be cases where you should be aware of it.