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

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

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

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

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

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

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

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

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.

Getting textures from Mari to Maya is pretty straight forward. Once you understand the Workflow it’s pretty fast. But what if you have a complex model, or even multiple models, each with multiple channels and lot’s of UV-Patches? It can be VERY time-consuming setting up each and every texture by hand.

Luckily there is already a script on Creative Crash which does just that. However this doesn’t seem to work for some people, including me. I’m not techy enough to narrow the problem down and I could use a refresh of my scripting “skills” so I tried to make a similar script myself using Python.
I came up with something that works on everything I tested. However it does have a somewhat humble workflow due to my inability to script properly, so you have to do a few extra steps. :) So what does it do?
It’s basically doing a couple of things: It renames all the file nodes according to the name of the input file. On each connected place2dtexture node it then uses the name of the input file nodes, therefore setting the translation to put each patch in the right spot. For this to work, the files need to have the $UDIM flag at the very end of the file name when exporting the textures from Mari. After setting the default color to black on each file node it then connects them to a layered texture so they can be added up. At this stage you can connect that layeredTexture to your shader.

You use it this way:
-select the textures you want to have connected for one channel (e.g. diffuse, spec, etc.)
-graph those textures in the hypershade so that you see all the textures and their corresponding place2dtextures
-select all the file and placement nodes in the work area
-execute the script

So far it worked on a few scenes I tested. If you encounter problems, don’t hesitate to ask me! In any case you should first try to get the other script from Kushal Goenka which I linked in the top of this article. His one is more straight forward, my version of this script is mainly for people who cannot use the other script.
 DOWNLOAD HERE
I hope somebody will find this helpfull! :)

So I recently got a new Harddrive and set up my System pretty much the same way like before. However I faced a bug in all recent Maya Versions which made it impossible to reach submenus in the Marking Menus in Maya. After endless fiddling I stumbled across the reason:

This glitch seems to happen on all recent Maya versions, all Linux distros and all nvidia driver versions if you have a dual-monitor set up where both displays have different resolutions. If the “Position” is set to “Absolute” rather than a fixed parameter this glitch happens. I know specific settings… But maybe someone might find this usefull…
Now that this one’s out of the way – rock on!