An Old Daguerreotype

I found this in an antiques store in Jersey. I think I'll make a show about him;)

Many thanks to Rick Vicens for some outstanding character design work. Also Jack Ehrbar for modeling and myself for a few things.

He's a character we're working on for an internal project. Not much else to be said yet, but I like the image.

Delays

Sorry for the delay in the linear light workflow guides. I got very busy with impending chaos at MotR. We are moving soon, and undergoing some changes in partnerships. It's been all my time to focus on the company.

I do have the next "linear" post nearly finished tho, so I hope to get it online soon. Sorry again for the long delay.

The Brokenmusicbox

My cousin Tony and his sweetie Kim just released their first album under the name, "The Brokenmusicbox." Beautiful stuff with some perhaps Michael Penn influenced instrumentation. You can find a link to their sparse site on my friends list to the right, but here's a nice little writeup on a music blog that has some info - link


Update: You can buy the cd here:
CDbaby

Digital distribution is coming soon.

Linear Workflow Introduction

This is the first post in what may end up being a series. There's a lot to cover on the topic, but not so much I can't stuff it into a blog. Lets get started.

You probably know what the idea of a linear work flow is already, but for the sake of those that do not, here is a very brief explanation:

A linear work flow exploits the fact that your renderer works internally in float (linear) space. It generates data that 8-bit output clips away, as it is gamma encoded for monitor display. What a shame. That data is very useful in your post-production compositing and color adjusts.

If you are not familiar with the differences between 8-bit, and 32-bit (float) images, or the concept of gamma encoding for display, then you may want to study a bit before progressing. There are some great books out there to get you up to speed. The HDRI Handbook is very well written, and I would recommend it highly. Online, there are a ton of sites that discuss hdri, which in computer graphics, was the beginning of the linear work flow concept. Learn about hdri, and you'll have a much better grasp of the process.

You may wonder what the big deal is, since you've been rendering wonderful images in 8-bit for years. The big deal I suppose, comes down to a few major issues:

1. Physical accuracy
You can be as physically accurate as you want (or have the patience to deal with); all the way to real-world candelas.
2. Realistic lighting
This is a lengthy issue, but lights in CG have traditionally been "cheated" via a linear falloff, or no falloff at all. This is because the linear response of lights are not being properly gamma adjusted in normal work flows. This goes all the way back to how phong and blinn work as estimations of real lighting response. We can and should evolve beyond that with realistic materials that respond to light properly. This is the reason there are so many new MR (architectural) shaders. They are built to respond correctly in a linear work flow.
3. Greater adjustability in post
32float or 16float has the ability to deal with huge color and exposure adjustments. Given a true float compositing environment like Fusion, most filters you use will respond more realistically. Motion blurs, and glows, for example, will behave in a more natural and photographic way.

Others have posted long before this, on the process, but I have found specific information out there lacking, other than in books. So I'd like to discuss it a bit further. One great post that started as a vray-specific tutorial, has slightly expanded to mention maya/MR and others. Thanks to Robert Nederhorst for this link. It also discusses gamma, so if you're not familiar enough with that Greek letter, read this.

motrMatteShadows Beta

So Jeff finished an internal tool for MR in Maya. It assists with using the Matte Shadow Production shader in Maya2008. To be specific, this tool automates the process outlined in Zap's Production Shader Examples. Read Zap's post to get familiar with the process. He basically outlines 2 modes of use. First, he renders the BG Plate in the shot, which we can describe as a LookDev mode. Next, some connection switching will allow for a final renderPass mode, where the BG plate is omitted. This is to generate output for later compositing.

The script below is a tool to generate and connect the required nodes automatically (setup), then easily switch between the lookDev and renderPass mode on the fly. It's not fancy, but it does the job. Also not a lot of error-checking. There is some, but if you delete the nodes it creates, the toggle will stop working. Hey, it's an early version;)

Remember, you will first need some things:
Maya2008, and you should unhide the production shaders via this cgtalk post. Otherwise, you may get missing node errors. Once you've got them unhidden, this script becomes useful. Use by placing the script into an active scripts directory on your system and typing in the command line, "motrMatteShadows 1;" 1 is for setup and lookDev mode. For the renderPass mode, type again, with a "2". I suggest creating 2 bu tons on your shelf for 1 and 2.

The first time you run it (in mode 1), it will create all the shading and camera nodes needed. Yes, it creates a new camera. Go ahead and graph it, and you will see the new connections. It also creates a matteShadow material. You should also graph that in Hypershade (and it's ShadingGroup).

While this early script creates a bunch of nodes for you, and toggles between 2 setups, it doesn't fill in all the blanks yet. We will try to work on that a bit more later. For now, you'll need to do the following steps yourself... Don't worry, they're easy:

1. After graphing the camera in Hypershade, you'll see 2 blank texture nodes. One pipes into mirrorball, and the other into cameramap. place the mirrorball image into the mirrorball texture, and your background plate into the cameramap texture. Since the same texture nodes are piped into your matteShadow material as well, this is all you really have to do.
2. You'll probably want to see the background plate in your viewport, so you'll have to make your own imagePlane for now. Use the same file you used for the cameramap texture. When rendering, you should set the alphaGain of the imagePlane to "0"

Set up your scene elements and do some test renders in mode 1. When you are happy with the overall look, set the script to mode 2 for rendering. You can toggle back and forth at any time to adjust with the bg plate in the render view.

There is a good deal to work on with this script yet. I'd like to start it with a UI, that asks right away for your mirrorball and bgPlate images. Also, it should have an option to auto-build your image plane. Perhaps in a bit. For now, I hope this is useful to someone, even in this rough state.

download
motrMatteShadows ver 0.3
(right click, save target as)

FG Point Density Optimization

Just a quick note to help speed up hires renders that use FinalGather. The new method is easier to setup in maya 8 and 2008. Accuracy can now often be left at low levels like the default of 100 and still provide smooth results, but some things to keep in mind regarding the new method...

a point density of 1 relates to the default layout of FG points. These points are normally set in a hexagonal sort of layout (really just offset rows) every 10 pixels or so. The "Point Density" value adjusts this. The default value of 1 is usually a very fine starting place, and many may never have to change the Point Density value. However, as resolutions get larger, and much larger for print images, this can be detrimental. The number of FG points that are created is resolution dependent. The larger your image, the more FG points will be added (still every 10 pixels or so). This is normally a wise thing, as the larger you render, the more FG detail you should need.

In practice, however, you probably don't need all the FG point detail (Density) you did for your lowres tests. Something that is nice to know is the following relationship:

If you double your image size (from 640 to 1280 for example) you are squaring the number of FG points. 2x2... if you leave your density at 1. If you quarter the density to .25, you will exactly match the FG points used in your 640 render. Since the render is now larger, your FG solution will probably not be quite detailed enough. A nice compromise might be to set Point Density to .5 thereby doubling (but not squaring) your FG points. This could provide much faster FG performance for higher res renders.

1280 is not a very hires render, so this example may not provide very high quality... but it illustrates an optimization that can make a huge difference for print-res renders (if you're into that sort of thing). If I'm rendering a print res at 10x640 (or 6400 pixels wide), that's a LOT of FG points. I would plug .01 into density to match the same FG points used in my 640 test. This will obviously look poor, but the render would be very fast. Finding the right relationship may be a bit of trial and error, but there is certainly a medium number of points that will retain enough FG detail, and still allow for fast rendertimes. I might start a 6400 render at a density of .1 for a nice speed optimization.

Good luck.

Universe = Doily?

Every once in a while, I'm bound to post things I'm interested in, that may not be about 3d lighting...

Given the nerd factor of anyone that might read this blog, I'm guessing no-one will be bothered much. My occasional off-topic posts (like this one) should still be of interest to said readers.

This guy, Garrett Lisi seems to have a basis for a unified theory of the universe that includes gravity, does not include 11+ dimensions, and in general has simplicity and elegance that say a certain fibourous, loopy theory does not. While this article isn't heavy on the science, it is inspiring!