EddieOffermann dot com

A few weeks ago, I posted a video covering the process of relighting rendered CG elements in a compositing tool like Shake using a surface normals pass.

Since that covered normals-based relighting of rendered cg elements, I thought I'd write an article that takes the concept a little farther and should stretch the reader's mind on what's possible with this sort of approach.

The earlier tutorial covered something that naturally can be accomplished by going back to the original scene in your 3d application, adjusting lighting and re-rendering: but I think there are times when we want to adjust the lighting primarily in the compositing application but want more than some masked-off gamma correction, lifts and crushes. So it's handy, then, to be able to apply an effect more similar to real-world lighting and that's what a rendered surface normals pass will enable us to do.

But what about real world imagery? Can this same technique be applied to live action footage just as it can be on a CG element?

Absolutely!

You'll want to start with a few elements like the following:

A full-color image like the above picture of a farmhouse. Under ideal conditions, you'd have an image with very diffuse lighting: something with a lot of bounce light or an exterior on an overcast day. The idea here is that there are relatively few real shadows in the image. The reality is that you won't have that very often and you'll have to use what you've got. You may decide that the shadows that do exist need to be painted out before you continue. I haven't done that for this example, but you'd be hard pressed to find a high end effects project that relit a real world environment and didn't remove the existing shadows at some point in the pipeline.

The above image is a matte of the farmhouse pictured above. You'll probably need to generate something like this for your scene if you haven't already.

A surface normals pass of a polysphere with its shading set to be as unsmooth as possible. I prefer this because I have a better feeling of where these surfaces are facing than I do straight from a sphere. It makes it like a special kind of color palette so I can perform the next step:

Next, I roto out a super-simple normal map of the surface in the image. This can be more or less complicated, depending on how much detail you want in the relight. If the surfaces are softer, you may want to blur the resulting image some: this will soften the transitions. Pick colors for each of your surfaces from the faces of the polysphere normal pass, making sure to keep parallel faces the same color as you interactively create a normal pass for your real-world element.

Then, I set up the OpaqueWhite OneLight Plus node as described in the normals relighting video here. Shake users can download the tool for free here.

It'll look similar to this:

Over on the right, you see where I've created the interactive surface normals pass. Those are groups with a few quickshapes and Mult nodes layered to create the interactive normals. In this case, since I didn't build out the ground and the barn next to the farmhouse, I chose to use the alpha from the interactive normals as the matte for the OW_OneLight+ node instead of the matte extraction I showed above. A smoothly blended surface for the ground, and a couple blurred normal shapes for the trees could make this quite convincing.

On the left, the fade leading into the over and the mix node to mix the whole thing back together is just one way of tweaking the levels of relighting that you're doing.

I posted a really short render of the light source moving across so that you can get an idea of what can be done. I kept it fairly subtle, and keep in mind that a little more work to create normals data for the ground, barn and trees would be required for a real project.

Moving footage naturally requires animated roto work to generate the interactive surface normals pass (keep the colors the same unless the element itself is moving!), and more complex objects with broader camera moves can be relit if you:

1. Build 3d geometry to match the visible elements
2. matchmove that geometry to match the footage
3. render a surface normals pass of those elements
4. use that rendered surface normals pass to relight the live footage.

In a future installment, I'll describe a method to generate surface-normals data by painting a bump map onto an image. In the meantime, I'll leave it as an exercise to the curious reader: how could you convert a simple greyscale height map into surface normals data in Shake?

I noticed the other day that my own 2d crowd generation software tool (DynaCyc) is ranking higher on google than Massive Software's listing for their incredible 3d crowd sim software.

In fact, if you google "Crowd Generation" there are two hits for my own websites before theirs comes up.

While DynaCyc is nowhere near as sophisticated for generating realistic behavior (it's more of a dynamic matte painting tool than a crowd generator - I created it for doing plants and trees to algorithmically make forests and such), it's pretty cool that I'm placing so well.

I really need to get the tutorial for my uv remapping tool recorded so that people can start using it. At the moment, though, I'm working 12-14 hrs a day, 6 days a week scripting some fancy animation pipeline tools.

The funny bit is something I've come to realize of the last couple days: while I fully grasp the minutiae of what I do, some of what I'm doing just baffles me in the big picture. I wrote a tool for "recasting" an animation from one space to another. For instance, if there's an object in a shot done during previs, and that original object has a particular animation on it, and there's a camera with a camera angle that we like... but the object itself is given a different animation in our scene because it has to fit in the "world" relative to other objects and be moving at a certain speed, reach a certain place at a certain time... I can take the camera motion from the original animation and transform it to the new shot maintaining the relationship between the camera and the element... while replacing that element's animation.

That's tricky... but I know how to make it happen and I've embodied it in a deceptively simple tool.

Separately, I worked out a method for stitching multiple animated shots containing a common object and many separate cameras together. The object's motion remains constant, and the cameras follow it along the path. Additionally, I developed a method for steering that element so that I can change its motion, adjusting the cameras to follow it.

That last one works using the first tool... so they end up all being connected to each other.

Once that happens, it feels like magic. I no longer understand the big picture: how we now have nearly a hundred separate shots stitched seamlessly together, but with different animation... and still working with the cameras and tracked objects matching to the footage? That starts to get away from me... I can conceptualize it as steps, as stages to reach a goal... I can break it down into its component parts: but the whole big process I understand only in that way: as big steps. I don't hold the whole thing in my head at once, though I use the tools that make it happen several times a day.

What's also funny is how much I'm even animating at this point... and I'm no animator, believe me. Let me write you a few expressions, though, and I can sometimes fake it.

Spent most of the day today working on my website, building another tutorial, and refining the uv-pass retexturing tool.

I had a long time to wait on a couple renders that I'm using in the tutorial, so I kept tweaking the interface. The original version of the tool was created about 3 years ago - and the underlying code hasn't changed. I have gotten a little pickier about how my tools should work though. If there's a process that I'm going to want to do most of the time I use the tool (whether it's a Shake Tool, a MEL or Python tool in Maya, a Sizzle Script, etc, that process should be built into the tool itself. It saves time and annoyance and makes the tool complete.

As a result, I ended up with a tool I like even more. Unfortunately... I won't be posting the real update tonight. It's late, I haven't recorded the final version of the tutorial yet, and I still need to package the latest set of tools for download.

As I'd mentioned before, this blog is going to get more technical and I'll be spawning off a personal blog shortly. For now, bear with me non-technical readers: I'm about to talk geek for a bit. When I was teaching at FullSail, a lot of my "curriculum development" time, as well as a substantial portion of my free time, was spent doing R&D on advanced topics - things that are done at a handful of visual effects studios around the world, or even things that nobody was doing yet except in university settings.

Things like relighting using what's called a bent normals pass (a special render pass that contains information about the direction a point on the face of an object is pointing) - a process that enables you to gain a fair bit of control over how the rendered object appears to be lit, long after the frames have left the render farm. Other experimental tools like an algorithmic forest and crowd generator, or today's topic: retexturing in the comp, instead of at rendertime.

There are a couple of tools for doing this already: basically, you render out a diffuse color pass, full intensity colors, no shading, but instead of finished shaders, the elements are textured with these especially bright and colorful red/green gradients. The color of each pixel corresponds to its relative location on the UV map, so even after the texture is wrapped around an object and that object viewed from an arbitrary camera position, each pixel still holds information about its original position in UV texture space.

Now, most of the tools I've seen for this sort of thing will apply one texture to one UV pass. Certainly an exciting demonstration, but hardly practical: a typical scene will often have dozens of texture maps at the very least, frequently hundreds, even thousands. Naturally, each of these may be rendered as a separate UV pass, and each separate element brought into the comp: but that can make for some pretty unwieldy scenes and a headache to maintain all those passes in the pipeline. Re-render an animation, and the number of potential UV-passes can quickly make each iteration into a big undertaking.

Of course, if you're dealing with 8-bits per channel UV-coordinate textures, like a typical JPEG, then your possible texture size to project onto that is fairly small. 256x256 to be exact, and for practical reasons, maybe only about half of that. Hardly anyone even uses textures that small in games these days, let alone feature films. If you crank those UV-coordinate textures up to 16-bpc, now you wind up with some pretty impressive texture space: each of the red and green channels can now represent up to 65,536 coordinates: the equivalent of 16 4096-pixel-wide textures. Even if we want to be similarly conservative like in our above estimate, you can see where I'm going with this...

So my tool, which I call "OpaqueWhite ReMap Plus" uses nice, big UV coordinate textures, all generated by your rendering application in 16 or 32 bits per channel, rendered as described above as an unshaded UV-coordinate pass and is designed to accept up to 16 separate textures at a time, anywhere from 256x256 to 8192x8192. I provide a collection of high-res, high-bit-depth UV-coordinate textures for users to set up their render with, and a tool that is able to interpret the data from that render pass and automatically re-plot the texture in the render-specific UV space.

There's a lot more stuff going up on the site shortly. It's ALMOST THERE, I swear. To those that might be interested, you can learn a little more about and (soon) download my Shake Tools here.