Digital Artform

vector $birthPos = eval("pointOnCurve -top 1 -pr "+$tVal+" curve1");

vector $velocityVal = <<0.0, -1.0, 0.0>>;

particleShape1.position = $birthPos;

float $tVal3D_x, $tVal3D_y, $tVal3D_z;
$tVal3D_x = 0.0;
$tVal3D_y = $tVal * 100;
$tVal3D_z = time * 0.1;
$tVal3D = <<$tVal3D_x, $tVal3D_y, $tVal3D_z>>;

float $noiseDrag = -1 * (pow(abs(noise($tVal3D)),4)) * 0.25;
$velocityVal = <<$velocityVal.x, $noiseDrag, $velocityVal.z>>;

Voila. Perfect compositing of premultiplied 3D CG in Photoshop.

Here's the "wrong way" once again, for comparison.

Posted by digital artform at 10:23 PM | Comments (14)

August 25, 2005

Hue Falloff in Maya Lights

The typical CG light only loses luminosity as it rolls off from direct to oblique illumination. That can look dull.

Here's a technique for introducing angle-based hue falloff into the light for a richer look.

The basic idea is to calculate the "facing ratio" not of the camera's view of an object, but of the light's view of the object, and to map that light facing ratio through a ramp and back into the light's color attribute.

Here's a brief overview:

1) Get the world position of the point being shaded by using the samplerInfoNode.

2) Get the world position of the light using the lightInfo node.

3) Subtract (1) from (2) to get a vector from the surface point to the light.

4) Get the surface normal in camera space using the samplerInfo node.

5) Convert the surface normal to world space using a vectorProduct node set appropriately.

6) Take the dot product of (3) and (5) using another vectorProduct node set to "dot product" -- this is the light facing ratio.

7) Clamp the light facing ratio (6) to between 0 and 1.

8) Run the facing ratio intoi the V-coordinate of a V-ramp set to colors of your choice.

9) Loop the output of the ramp back into the light color.

You now have angle-based hue falloff built into the light.

To explore this in detail, download the maya scene file:
hueFalloffLight.ma

You can use any surface shaders you wish to use on the objects. All the color falloff action is in the light

Posted by digital artform at 10:53 PM | Comments (2)

July 31, 2005

Maya 7

Alias unveiled Maya 7 before a large and enthusiastic crowd at its SIGGRAPH '05 Alias Users Group meeting in Los Angeles tonight. Maya 7 looks to be a great update of the popular product.

This is by no means a comprehensive review, but here are a few new features that caught my eye:

Alias has extensively overhauled Maya 7's render layer architecture. One benefit of this revision for users in the print industry is that Maya 7 can output render layers to Photoshop layers in .psd image format.

Maya also integrates well with Adobe Illustrator files. The software can reference and (for example) automatically bevel an Illustrator format logo. Should the Illustrator artwork be altered, the change reveals itself in the Maya scene file as an updated model.

Maya 7 now offers the ability to paint blend weights onto blend shapes, and to "bake out" the results of such blends as new blend shape objects. Paint on one side of a face and a smile now becomes a sneer. Remodel one blend shape (to add an eye-patch, for example) and that change makes itself present in all related blend shapes.

Thanks probably to the influence of Alias's acquisition of Kaydara MotionBuilder 7, Maya 7 now supports full body IK. Pull on an arm and the effect propogates realistically throughout the rest of the body. Animators can also remodel already skeleton-rigged objects with relative ease.

Maya 7's fluid computations have been improved to allow finer voxel resolutions, which greatly enhances the look of the 3D fluid effects.

Duncan Brinsmeade concluded the evening with a demonstration of significant enhancements to Maya 7's toon shader. Thanks to the toon shader's tight integration with Maya Paint Effects, the user now has great control over line quality, color, wiggliness, motion and weight. Maya 7 users can create a variety of non-photorealistic crosshatching, engraving, and watercolor looks, over-extend lines as if in architectural renderings, light edges of objects with single-pixel-width edge glints, and even "hack" the shader into producing "ripped cloth" looks and "ocean wakes" at points of intersection between one surface and another.

A 64-bit version of Maya is in the works for future release, but it was far enough along for Alias to offer a glimpse of it.

Maya 7 is available for download to Platinum Customers as early as August 1. Pricing is unchanged.

Posted by digital artform at 09:58 PM | Comments (7)

July 30, 2005

UV Map Now or UV Map Later

With a little tinkering and the right movie as input, you can make a displacement node perform UV mapping within Shake, putting an ordinary still image into motion.

Instead of mapping an image onto an object, map absolute UV addresses.

By subtracting a reference pattern of untransformed UV addresses from a sequence of transformed addresses, you create an image of relative offsets, which is exactly what a Shake displacement node wants as input.

This means you can render an animation now, and decide later what image you wish to UV map onto that object.

By blurring the transformed UV's you can get some freaky warp effects.

For some additional background, check out:
Smear Now or Smear Later

UPDATE 1/20/2006

Here's a correction which shows the right expressions to be used.

Posted by digital artform at 09:34 PM | Comments (12)

July 22, 2005

Wave Generating Mel Script Shader

Make some waves with this custom Maya shader which uses a MEL script to generate concentric spherical waves of animated light and darkness. It's a 3D texture, so it will flow over any objects you create. The waves emanate from a Maya locator.

Step 1
Make some objects. Give them a Lambert shader.

In the example above, the plane is 20 x 20 units in the xz-plane.

Step 2
Make a Maya locator. The locator will serve to control the 3D texture. Why a locator? Just to demonstrate how to use one in this way.

Step 3
Into the hypershade drop the following nodes: a samplerInfo node, and a vectorProduct node. Set the vectorProduct node to do a point-matrix multiply.

Step 4
For the point input of the vectorProduct, use the pointObj output of the samplerInfo node. For the matrix input to the vectorProduct, use the worldInverseMatrix of the locator.

This should have the effect of expressing points on your object in the coordinate system of the locator.

You'll be able to move the wave source around by moving the locator around.

Step 5
Into the script editor place the following MEL script.

float $currentPt[3];

lambert2.colorR = $waveColor[0]*.5+.5;
lambert2.colorG = $waveColor[1]*.5+.5;
lambert2.colorB = $waveColor[2]*.5+.5;

Do you see the bold .02 scaling the noise function in the MEL script above? Increase the .02 to something more like 2.0, and you'll see random bunching in the waves.

Adjust to taste.

You are getting very sleepy. Verrr-rr-ry sleepy.

Posted by digital artform at 11:59 PM | Comments (7)

June 04, 2005

Motion Blur

Suppose you want to go at a linear rate from point A to point B in four frames. Where would you be at frame 1? At frame 2? At 3? At 4? You probably imagine points along a line similar to one pictured above.

Here's the thing, though: frames are not points in time. Frames are periods of time. It's not even meaningful to use the phrase at frame 1. Saying at frame 1 is like saying at September.

Think of it this way:

Suppose you wanted to walk from New York to Los Angeles over the course of a year. Suppose you set out at the beginning of the first day of winter. Where would you be at winter? At spring? At summer? At fall?

This confusion over how to represent time is why most 3D packages have a "fencepost error" that causes them to handle motion blur in a kludgey way.

Here's a link to an old (pre-blog) web page of mine that develops this motion blur idea further.

***

...and while this has nothing to do with time from an animator's standpoint, you might be interested in some thoughts on time from a cosmological standpoint from Peter Lynds

Posted by digital artform at 09:11 AM | Comments (0)

April 12, 2005

Final Gather Rim Light

Need to render that climactic "end of act 3" dash from the exploding building or self-destructing mothership?

With Final Gather, you can make some nice rim lighting.

Make some stuff.

Turn on Final Gather in Mental Ray.

Make the background environment of the rendering camera some color other than black if you wish. It will be treated as incoming light to the Final Gathering occlusion shader.

Put a plane behind the object. Give its incandescence channel a bright color.

Express the color of the background plane's incandescence in Hue Saturation Value (HSV) space. Turn the Value up much greater than 1.0 -- in this case, I've turned it up to 5.0

To create an even greater "wrap-around" effect, warp the plane into a shallow bowl shape.

Hide the incandescent object by turning it invisible to primary rays.

** If you need to synch the light spill to an exploding mothership, try mapping a movie of the explosion onto the invisible incandescent objet.
Remember to turn the value of the color gain on the movie up nice and high.

Posted by digital artform at 05:21 PM | Comments (5)

April 08, 2005

Renderman for Maya

I attended the unveiling of Pixar's Renderman for Maya product at the Gnomon school in Hollywood last night. The event was well-attended and the presentation took place in a sound stage large enogh to accomodate a large screen video projection system which showed the software to good effect.

Maya users looking for a sophisticated alternative to the native Maya renderer have been able to use Mental Ray for some time now, and at no additional cost. The Renderman route was until now a relatively expensive and somewhat more difficult one.

Before the advent of Renderman for Maya, the "friendliest" front-end for Renderman within a Maya context, to my knowledge, was the SLIM plugin. The basic workflow for SLIM users entailed leaving the Maya renderer as soon as possible, and using SLIM-based shaders and mapping coordinate systems developed not within the Maya hypershade, but within a node-based environment known as a SLIM palette.

Maya for Renderman obviates the need for this additional shader design environment. Maya users will now build Renderman shaders within the Maya hypershade. The "feeling" of using Renderman for Maya appears to be similar to that of using Mental Ray. The familiar Maya interface remains largely the same, with the addition of new Renderman-specific tabs and attributes.

Renderman has many well-known strengths. It looks great, and (having been forged in the fires of Pixar's hardcore production demands) can handle complex displacements and extensive camera and object motion blur without suffering a big performance hit. Renderman executes all of its particle rendering within software, which allows the user to do more sophisticated, shader-driven control than does some of Maya's (hardware-rendered) particles. Renderman's "Deep Shadows" technique gives the Maya user access to beautifully rendered shadows from particles, fur, and hair.

This is a tempting plug-in with some small drawbacks:

Unlike Mental Ray, Renderman for Maya costs an additional $995/seat.

While Renderman does have a subsurface scattering algorithm, and an occlusion shader, it does not seem, on the whole, to place as much emphasis on Global Illumination techniques as does Mental Ray.

Renderman for Maya is designed to put the production-proven power of Renderman into the hands of the small to medium PC- and Mac-based CG houses. Pixar has no immediate support for a Linux version.

Posted by digital artform at 11:39 AM | Comments (9)

January 14, 2005

Sample a Maya File Texture

To sample a Maya file texture node at a certain pixel, you need to feed the file node the correct U and V values.

In this example, the middle pixel of the texture map, at the place where U = V = 0.5, is a rusty brown color.

I've created a ramp with the color (0.5, 0.5, 0.5) and mapped the R and G output values of the ramp to the U and V input values of the file texture node. The result? The very brown color you'd expect.

Let's try something a little more interesting...

Here's the texture UV-mapped in the usual way onto two NURBS patches, a torus and a plane.

The results are as you would expect.

By connecting the UV channels of the object to the surface shader red and green colors, we can visualize the natural UV coordinates of the NURBS surfaces.

Suppose instead of accepting the natural "default" UV values that come "baked" into the NURBS surfaces, we supply our own. Since the objects have been conveniently modeled small and near the world origin they happen (because I planned it this way) to sit in the cubical region of world space with corners at (0,0,0) and (1,1,1)

Instead of letting the file texture node get the usual UV values, lets pass world space X to U and world space Y to V.

We have just mathematically modelled an XY planar projection without using a Maya projection node.

If you know the math, you can make all kinds of projectors and other fun textural things for yourself.

Caveat

If you try to do this any Maya 4.5 and later, you may need to implement a workaround: if you try to REPLACE 2dplacement uv info with your own exotic math, Maya detects this as a missing placement node and ignores user-supplied uv info, going into a default behavior instead. If however you KEEP the placement node, but multiply its data by zero, you can SUM it with your own exotic math, thereby "tricking" Maya into accepting some very slick shader math right in the hypershade.

I could do some very exotic "slit-scan" effects on animated file textures if I could map a unique frame number or frame offset to every pixel, but Maya seems to allow the frame number to be updated once per frame, not once per pixel.

Posted by digital artform at 08:09 PM | Comments (3)

January 02, 2005

Jittered Tiles

Continuous noise in red and green, when applied to the offsetU and offsetV attributes of a tiled UV map, can create the impression of "digital ripple glass."

Download continuousNoise.mb Maya 6 scene file

Discrete noise, when similarly applied, can shake a repeating array of UV-mapped textures seemingly "out of its grid," adding variety to your 3D CG work.

Download discreetNoiseUV_8.mb Maya 6 scene file

The idea is to cause discrete noise to become tiled at the same rate as a texture map is tiled. If the noise is red and green, and if red and green are connected to the offsetU and offsetV attributes of a place2dTexture node, then the tiles can be "jittered" out of place. In the example above, I have created a "dimmer switch" in the form of a one-color gray ramp which, when multiplied by the output of the discrete noise function, can cause the tiles to drift out of their normally rigid grid positions.

Some Caveats
You don't have to use a ramp as your tile texture. You can use a file node containg any image you wish. Just make sure the subject of the tile is surrounded by a big fat bland border. You are not actually altering the grid, you are only rattling a small texture around within that grid. If your texture does not sit within a big fat bland border, you will destroy the illusion. For best results, surround your texture figure with a big region of transparency.

If you "turn up the dimmer" too high, you will knock the textures into the borders between "cells" and destroy the illusion. If you want more density or closer packing, you'll have to use more layers and transparency mapping. If you work at it, you can use quantized noise to weave one layer randomly over and under another layer, or color correct or rotate individual cells.

The use of gray blocks of noise and a wacky ramp full of yellows, reds, greens, and blacks to turn 1-dimensional (gray) offsets into 2-dimensional (red and green UV) offsets is a total kludge. The noise function shoud be the sum of a blocky red function added to a blocky green function.

I have tried many times to get this to work. There seems to be a particularly ugly Maya bug which prevents this from succeeding. The red offsets work fine alone. Ditto the green. But when you try to sum them, they turn into stripes, or cause Maya to freeze, or work in hardware rendering but crash in software rendering.

UPDATE:

The 2-color noise works fine in Maya 4:
Download file

The 2-color noise fails badly in Maya 6 software rendering, although it seems to work in the Maya 6 hardware renderer:
Download file

Posted by digital artform at 05:43 PM | Comments (4)

December 29, 2004

Randomly Shuffled Texture Tiles

This image was created with 3 randomly shuffled tiles. It uses discrete tiled noise

...and a limited set of texture map tiles to create the illusion of randomness and variety.

Let's begin.

Set up some discrete tiled noise as described here.
Or simply download the Maya 6 scene file discreteNoise.mb from here

You'll need that recipe -- be sure to follow that link!

Set up a number of V-ramps. You'll need as many ramps as you have tiles to shuffle. If you intend to shuffle 3 texture maps, you'll need three ramps. You are by no means limited to three.

Set the interpolation in the V-ramps to "None" and design them so that they are razor sharp black and white bands. Make sure the white portions of the bands (when all the ramps are considered together) exactly cover [0..1] V-parameter space without either underlapping or overlapping.

Run the quantized noise through the V-ramps by connecting the red channel of the noise outColor to the vCoord of the ramp input.

Notice what happens to the ramps after these connections are made. They become white blocks.

The "lower white-banded" ramp now becomes the set of all noise blocks that were dark gray.

The "middle white-banded ramp" now becomes the set of all noise blocks that were middle gray.

The "upper white-banded" ramp now becomes the set of all noise blocks that were bright gray.

Those blocks will become mattes that will control the presence or absence of one tile or another.

In effect we tile the objects three times over. Once with a solid grid of nothing but tile A, once with a solid grid of nothing but tile B, and once with a solid grid of nothing but tile C. Tricky compositing (from within the Maya shader) accomplishes the "shuffling."

By multiplying the grid of textures by the appropriate mattes, and by adding all the pieces together with the layered texture node, we cover the entire object with random textures.

If you forget to "repeat tile" the textures, you'll end up with this. The noise is a grid of blocks, so the textures must be a matching grid of blocks.

The noise in this case is tiled into a 10x10 grid, so you'll need to make sure you go into the place2dTexture node of each map and set the "repeats" for the texture tiling so as to create the same 10x10 grid of repeated textures.

Like so.

Remember: you can add more tiles and more ramps, just make sure you set the ramp spaces accordingly.

By adjusting the ramp ranges, you can skew the proportions by which each tile is represented.

If you create off-center features in your tiles (like the stars and moons above) and if you enable the "mirror" option in the place2dTexture nodes, you can "jiggle the grid" a little more and further the illusion of variety.

I understand Renderman may have this "shuffled texture" functionality built into it. Maya should add it.

Posted by digital artform at 04:47 PM | Comments (4)

Discrete Tiled 2D Noise

If you quantize the noise function into discrete tiles, you can do all sorts of fun things with it. Let's look at how to do this here, and why you'd want to do this in the next entry.

Start with continuous 2D (UV-based) noise.

Disconnect the usual connection by which the noise function gets its UV information.

Open the Expression Editor, and enter the following equations:

noise1.uCoord=trunc(place2dTexture1.outU*10)/10;
noise1.vCoord=trunc(place2dTexture1.outV*10)/10;

The Hypershade will create an Expression Node and connect it accordingly.

Congratulations, you now have quantized noise. If you use it right, you can do things like create "shuffled" texture tiles.

Download Maya 6 scene file discreteNoise.mb

Read on to see how

Posted by digital artform at 04:31 PM | Comments (6)

December 27, 2004

Lollipop Mapping

When you UV map a sphere, you normally expect distortion at the North and South poles. If you preprocess your texture map in the right way, you can hide the North pole completely, at the expense of an "extra bad" South pole.

Think of it as wrapping paper over a lollipop.

An un-prepared image wraps around a sphere in Maya as expected.

With the usual North and South poles.

Use Photoshop to "pre-distort" the texture map. Choose filters > distort > polar coordinates. Be sure to choose the "polar to rectangular" option.

Now you have no North Pole!

...at the expense of an "extra bad" South Pole -- which you can hide either through careful choice of camera angles, or through the use of a second, upside-down texture map, carefully merged (at the equator) with the first map, so that the end result is a sphere with no visual poles at all.

Posted by digital artform at 12:43 AM | Comments (2)

December 13, 2004

Transparency Mapping and Matte Lines

When your Maya transparency map's RGB channels precisely fit its alpha channel, you must take special steps in order to avoid matte lines. Here's how to use the multiply/divide node to "unpremultiply" the RGB channels, and how to use the conditional node to avoid "division-by-zero" errors.

Here's a texture map I wish to transparency map onto a card in Maya. It consists of sharp text, blocky antialiased text, and a soft abstract swirl.

Here's the precisely-fitting alpha channel that will control the "transparency" of the card.

Here's the shader that one would normally use for such a thing.

Here are the sorry results. Matte lines, anyone?

The first step toward fixing the problem is to fool Maya into causing the RGB channels of the transparency map to "overshoot" the alpha channel. I do this by using the multiply/divide node to divide the RGB values by the alpha values.

Since the alpha channel very likely contains zeroes, and because division by zero is undefined, I use a conditional node to detect zero pixels in the alpha channel.

If the conditional node sees a zero as input, it returns a zero as output. If the conditional node sees anything but zero in the alpha channel, it returns the quotient "RGB over alpha" as output.

Here's what that looks like.

Now when I return the alpha channel to its job of controlling the transparency of the card...

...the matte lines are gone -- even the subtle ones around the supposedly sharp (but still antialiased) text.

I find it particularly frustrating that I can't implement this workflow when creating Maya particles in the form of sprites with alpha channels, but this level of sophistication is, I believe, not implementable in the sprite hardware renderer.

Here are some additional pages I put together on the subject --

Alpha Channel as a HOLDBACK MATTE:
http://www.digitalartform.com/archives/2004/10/alpha_channel_a_1.html

Alpha Channel as a CLIPPING CHANNEL:
http://www.digitalartform.com/archives/2004/10/alpha_channel_a.html

Here's a somewhat related entry on

Three Color RGB Values in the Transparency Channel

Posted by digital artform at 05:17 PM | Comments (4)

November 25, 2004

Nodal Point Pan and Tile: Part 3

In this simple tutorial I take two images and stitch them together into a continuous nodal point camera pan. To keep things simple, I'm using images from a computer generated scene, but the principles apply just as well to live action.

Here's image number 1.

Image 1 is a rendered view of a (rather garish) 3D scene. In this example I used a default Maya camera with the lens set to 20 mm.

Here's image 2.

Image 2 is a another rendered view of the same scene, only this time the camera was rotated -75 degrees around the Y-axis.

I allowed a little overlap in the images, so that you could better see the "hookup" between the two. That funny little tilted "egg" on the far right of image 1 is the same object as the one on the far left of image 2.

We're ready. Let's begin:

Step 1
Model a plane with the same aspect ratio as that of image 1 and map image 1 onto the plane.

Make the plane any size you wish, but place it as far from the camera as is necessary to have the plane exactly fill frame.

Step 2
Make a second plane to the same specs and make sure that it, too, fills the frame. Map image 2 onto plane 2.

Step 3
Now rotate plane 2 away from plane 1 in the exact same way that camera 2 was rotated away from camera 1 when the original images were made.

In this example, image 2 was rendered after a -75 degree pan away from image 1, therefore you must y-rotate plane 2 those same -75 degrees away from plane 1.

Congratulations. You're done.

No stitching needed. No cylindrical maps needed. No spherical maps needed. No kidding. You are absolutely done.

Here's the setup as seen from a "God's eye view." The two images are mapped onto flat planes. The flat planes are slammed right through each other. The corner between the two planes is a sharp angle. When you view the two planes from the right place, none of those details matters.

Leave the "God's eye view" and go back down to the place where the planes fill frame. See for yourself what a pan across those two planes looks like:

In this animation, I tinted the two planes two different shades of color so that you can see where one ends and the other begins. Notice how the lines and edges flow seamlessly from one image to the other. From this special place, the images are not "broken" across the corner between the two walls at all.

In this animation I used the two images in their untinted form, and I zoomed in a bit before panning across the two planes in order to hide the corner. Now the illusion is perfect.

That's all there is to it.

If you take care to even out the lighting and tweak any lens distortion, you can do this exact same technique using live action photos instead of rendered CG images.

... okay, want to see one more image worked in? How about one at a crazier angle?

Here's a third image. It was rendered with the camera at angles 10, -30, and -20 around the X-, Y-, and Z-axes.

That means image 3 goes on card 3, and card 3 gets the same crazy X, Y, and Z rotations.

When you look at this trio of cards through the correct camera, all of the textures on them align in seamless perfection.

...I purposely tinted card 3 a little bit and lowered the focal length of the rendering camera a bit so that you could more easily see where card 3 begins and ends and interpenetrates the other two cards. If I were to remove the tint and zoom in a bit, the seamless illusion across all three cards would again be perfect.

Feel free to play around with this yourself.

There are two Maya scene files that are independent of each other.

One renders the environment into the still images you'll need.
(Camera1 renders frame 1 and Camera 2 renders frame 2)

environment.mb

The other maps those still images onto cards and pans across the cards to create the moving panoramic background.

viewPlanes.mb

The scenes files above are Maya 6 files. To keep sizes small, I have used only procedural textures in environment.mb It's your job to render the two images from environment.mb using camera1 and camera2, and to attach the rendered images to the cards in viewPlanes.mb by editing the "file" nodes accordingly.

And finally...

...this is a "nodal point pan and tilt" shot. Rotate the cameras all you want (as if they were on tripods). If you translate the cameras (as if they were on dollys) you'll start to break the effectiveness of the illusion.

Posted by digital artform at 12:19 AM | Comments (1)

November 20, 2004

ColorTalk

Although I only recently learned about the "secret" functionality while browsing an art forum, Painter seems to have been playing with the idea of adding a programmer-friendly procedural image creation and manipulation function called ColorTalk to its famously artist-oriented software since version 3.

I decided to take a closer look at ColorTalk as it continues to unofficially exist in Painter IX.

ColorTalk is a terse little language that allows the user to write functions that operate on the pixels in an image. To access it in Painter IX, hit the n key.

When I first heard about it, I was excited to jump in and start using it. I've had a lot of experience with similar kinds of applications, and expected to find it useful to me right away.

Maybe I'd write a Mandelbrot set generator in it for Painter -- that could be a fun test, and wouldn't take too long.

Then I saw that ColorTalk had no looping. Nor did it offer any "if-then" conditional statements. I lowered my ambitions.

Next I thought, "let me see if I can make a bunch of thin horizontal lines using a sine wave." Although a pattern like that can be useful for making tv screen effects, my main goal was to explore. "Let's see," I thought, "how many lines should I make? Hm, a few hundred, anyway."
That's when I saw that the only numbers even PERMISSIBLE are 1, 2, 3, and 4, and some decimals that have to be dragged and dropped into the window.

bottom line:

This is a cool beginning for something that appears to have never been followed through on. In its present state, ColorTalk appears to me to be an odd toy-like curiosity.

The fact that the software can produce continuous grads tells me it works okay internally, but I I notice banding problems, and I believe the software suffers from greatly limited bit depth. What's more, the user is severely constrained as to what numbers he or she can even EXPRESS as input to the program.

Considering it's a "secret" function, ColorTalk is better than nothing -- but only just barely. Anything useful you can do with it you can do more easily through Painter's GUI. Anything "slick" you'd like to try doing with ColorTalk you are likely to find impossible to do with it in its current state.

I want to stress that ColorTalk is an unofficial feature of Painter, and so the software does not merit criticism, per se. I offer these comments more as an evaluation of how the software strikes me in its present form.

I think ColorTalk holds great promise, and would be a welcome addition to Painter. I encourage Corel to flesh Color Talk out into a full-fledged feature. I think I would use it a lot. And if I'm wrong about my evaluation of it, if I'm "missing the boat" here, I'd like to hear more.

Additional links:

http://kaburaya.pobox.ne.jp/eng/colortalk_general.htm

ftp://ftp.corel.com/pub/Painter/Misc/ColorTalk_Tech_Note.pdf

Posted by digital artform at 12:31 PM | Comments (0)

November 15, 2004

Camera Projection Fun

Here, for fun, is a short tutorial on how to turn a 2D photograph into a 3D animation using Maya camera mapping. The move you see is entirely virtual. This technique forms a useful basis for "view-dependent texturing" of foreground objects, as well as for imposing a 3D move on a 2D matte painting background.

Here's a simple photo of a cardboard box sitting on the floor.

Here's a "clean plate" of the floor alone. I retouched it a bit in Photoshop to let a little of the original box remain around the base. This little trick lets me be a little sloppy in alignment later on.

Using measurents from a ruler, I match model a virtual box with the same proportions. I don't sweat the details (like the folded cardboard flaps on top) - I keep it simple.

I create camera 1 and position it so that the 3D wireframe box I modelled lines up with the photograph of the box.

I create a second camera -- camera 2 -- and match it precisely to camera one by editing its attributes, and by using point- and aim-constraints.

I use "perspective projection" from camera 2 to project the image of the box onto the virtual box. I use the same camera to project the "clean floor" plate onto a matched position virtual floor object.

To eliminate blurry mapping artifacts on the box, I found I had to turn off filtering in the file node.

The trick of this project is to decouple camera 1 from camera 2 -- to break the constraints so that the projecting camera and the rendering camera are no longer in the same place.

Notice how my original box photo shows three sides visible on the box. When designing my animation, I purposely chose an initial position that hid one of the three box sides, and revealed it over the course of the move. The reveal of the third side makes for a fun, unexpected surprise.

I first started using camera mapping in in the Eighties, although the technique itself was already well-known to some in the CG world before then. The concept of camera projection is older than CG itself, and was used to great effect in analog form in the theater world for decades.

When the photograph matches the foreground object, and when the projection can be made to "stick" to the object while the object flexes (through reference objects, or projection of UV's into vertices) then camera projection can be used as the basis for creating view-dependent texture maps.

When the photograph matches the background, it can be used to impose a 3D move on a 2D matte painting.

When the photograph contains an object with no matching 3D geometry, (as it does in this test I tried in 1992) the photographic object can appear normal when viewed from one place, and "painted on the wall" or "cast like a shadow" when viewed from another place.

Conversely, when a 3D object exists but is not represented in the photograph, the 3D object can, when viewed from the right place, vanish like a chameleon into the background. Look at the character "Reptile" in the movie Mortal Kombat, to see this technique in action.

UPDATE 1/16/2006
Here are some fun "real world" examples of the principles of camera projection in action:

Felice Varini: Denial of Perspective

Kurt Wenner: Amazing Sidewalk Chalk Artist

Posted by digital artform at 12:10 AM | Comments (15)

October 30, 2004

Camera Projection Misalignment

You can have a lot of fun with camera mapping. Here's a Maya camera mapping tutorial I put together. I find, however, that setting up an accurate Maya camera projection is more confusing than it should be. Using the default settings introduces a misalignment between the rendering camera and the projecting camera.

Here's an image of four spheres. It was rendered with a new camera (Camera 1) with all settings reset to their default values.

Here's a test slide prepared using the render from Camera 1. It's nothing fancy - just a simple Photoshop-generated negative of the image rendered by Camera 1.

I have created a second camera - Camera 2. I have assigned this camera reset, default settings. I'm going to project the test slide rendered by Camera 1 onto the geometry rendered by Camera 2.

Since the projecting camera (Camera 2) and the original rendering camera (Camera 1) have identical attributes, the image projected by Camera 2 should precisely fit onto the geometry rendered by Camera 1.

Here's the first render. You can see from the presence of the slide's white background on the spheres that there is a misalignment. This is a problem.

Here's my attempt to solve the problem by changing the "fit type" of the projection.

Finally we have a correct alignment of projected image and rendered image. Let's look at one more (better?) method of achieving this alignment...

This time, I've changed the gate of the projection.

This method also achieves a correct alignment, and may be the preferred method.

Oh, one last thing...

If you are using Slim and Renderman and you want to get accurate camera projection in Maya, look here.

UPDATE 12/11/05
Your best bet is to find the rendering camera at the frame you wish and simply duplicate it, rather than building a new camera from scratch and trying to match parameters.

Posted by digital artform at 10:51 AM | Comments (0)

October 25, 2004

Avoiding Ugly Color Falloff in 3D

A standard shader has a boring color falloff. Most painters, when rendering a surface which turns away from light, will identify (or invent) a reason to introduce a shift in the hue of a surface as it darkens. One way you can do this in 3D is to map a color ramp to light falloff.

A standard shader, in this case a cyan-colored Lambert shader, is usually implemented inside the renderer as a multiplication of a base color and a grayscale Lambert falloff.

When color fallos off in this way, it can go through muddy, dull midtones.

If you remap the falloff with a ramp, you can give it a richer look. For details on one way to do this, read on...

Start with a Surface Shader node.

Add a ramp. They default to V-ramps. Connect the output of the V-0ramp to the Out Color of the Surface Shader.

Add a Lambert to the V-Ramp. (Did you know you can do that?)

The Lambert falls off through shades of gray. That means the red, green, and blue channels of the output color of the Lambert are identical. Since they are identical, choose any channel you like (I chose the green channel in this case) and connect it to the V input of the UV coordinate input of the ramp.

(I chose the V input because the ramp defaults to a V-ramp. If I had changed it to a U-ramp, I would have used the U input.)

Here's a default ramp.

Here's a render of the objects using the default ramp.

Adjust a pleasing falloff into the ramp...

...and you'll achieve a pleasing falloff in the lighting of the rendered objects.

This kind of hue falloff is common in Renderman shaders. I don't see it done a lot in Maya shaders.

If you are uncomfortable using a Surface Shader as your final base shader, you can use other shaders that are more to your liking. I haven't done a lot of work chaining one shader into another as I did above; perhaps you have. If not, you might have fun experimenting along those lines.

Here's a related link:
Avoiding Ugly Grads in 2D

UPDATE 8/25/2005
Here's a much better way of doing the same thing:

Instead of using surface shaders, it creates Hue Falloff Directly in the Maya Light where one could argue it really belongs.

Posted by digital artform at 10:58 PM | Comments (2)

October 20, 2004

Nodal Point Pan and Tile: Part 2

A good way to set up a nodal point pan and tile is to camera project a series of images onto the inner surface of a sphere from a projection point in the exact center of that sphere.

I'm starting with a photograph I took which is full of straight lines going off in various directions. It's a photo of the inside of a parking garage. I've enhanced some of the garage's natural lines in red, and I've added a border in blue around the edges of the image.

Next I place a camera in the center of a sphere of arbitrary radius. Notice how when viewed from the center of the sphere, the longitude lines of the sphere become perfectly straight vertical lines. This is because longitude lines are great circles, and when we are in the center of the sphere, we are also in the center of each of those longitude circles, so they aim edge-on directly at us and therefore appear to be lines.

When I use camera projection to place the image of the parking garage onto the inner surface of the sphere, the image appears curved. The red lines appear curved, and the blue border lines also appear curved.

The only reason they appear curved, however, is because I am viewing the image from a place other than the center of the sphere.

If I were to go to the center of the spere, all the lines would appear straight.

Here is an animation of the curved frame wandering around on the curved sphere surface. Notice that from this vantage point in the center of the sphere, it looks like a simple rotated rectangle.

Here's the exact same animation as seen from a point other than the center of the sphere. From here you can see what is really going on.

Why do the curved red and blue lines appear straight when viewed from the center of the circle? Because when projected, they become great circles.

I lined up the edges of some purple circles along a couple of the red lines, just to show how the lines are, in fact, great circles.

Remember, the idea of a great circle is that the 2D center of the circle is in the same place as the 3D center of the sphere.

UPDATE 12/27/2004:

Here's a guy named
Dick Termes who goes out of his way to make sure the viewer is not at the center of the sphere:

http://www.boingboing.net/2004/12/27/spherical_paintings.html

The idea that points in space can be represented as if viewed from the center of a sphere has formed the basis of Astronomical observation since at least the time of Aristotle.

Posted by digital artform at 07:42 PM | Comments (0)

October 11, 2004

Nodal Point Pan and Tile: Part 1

A level camera creates vertical lines that are vertical. An upwardly tilted camera creates vertical lines that converge to a vanishing point high above.

It's hard to imagine how to stitch those together. For a good intuitive grasp of what goes on in nodal point pan and tile work, try this simple experiment in Maya.

Place a perspective camera inside a sphere of any radius you like. (try changing the radius of the sphere. Notice the change has no effect on the sphere as seen from the perspective camera.)

Make the sphere "live," and draw a little street scene on it. A road. Some trees. Whatever you like. Notice how the longitude lines of the sphere are all perfectly straight lines. That's because they are actually "great circles" around the sphere aimed directly edge-on at you in the center of the sphere.

The lines you drew look straight to you, but to an outside observer they too are great circles curving around the sphere.

Tilt the camera up. Notice that from the point of view of the camera, the longitude lines remain straight, although they now converge to a vanishing point above. Draw in some clouds if you like.

Tilt up some more. Add some more clouds, if you like. The idea is to fill in the rest of the environment - or at least to understand the perspective change the environment undergoes during a nodal point pan or tilt.

Now tilt down. Notice the straight lines of the road continue to look straight, even though they are actually wrapped around the sphere.

Fill in some more of the road, if you like.

Pan sideways and add a building. Why not? As long as you remain in the exact center of the sphere, the illusion of straight lines will continue to hold true.

If you leave the center of the sphere, the illusion of straight lines will be lost, and the true curvature will emerge. That would be bad.

The whole point of this technique is to preserve the illusion of straight lines remaining straight. You are modelling a nodal point pan and tile camera move, as if you are shooting live action footage from a tripod. Don't leave the center of the sphere.

UPDATE 12/27/2004:

Here's a guy named
Dick Termes who goes out of his way to make sure the viewer is not at the center of the sphere:

http://www.boingboing.net/2004/12/27/spherical_paintings.html

The idea that points in space can be represented as if viewed from the center of a sphere has formed the basis of Astronomical observation since at least the time of Aristotle.

Posted by digital artform at 11:41 PM | Comments (0)