omino pixel blog

Back to the cubes. This Pixel Bender generator shows a volume subdivided into cubes, and constrained to a spherical limit.

And here’s the source code.

Can’t wait to start incorporating this stuff into After Effects CS4… but haven’t uncovered any details on exactly how Pixel Bender integrates to it. Presumably some magic parameters may tell you things like the source or dest extant, and maybe you can add “typing” information to parameters. Looking for links… since it may be a little while before I can afford to upgrade.

I was trying to do something else. But, as you well know, sometimes bugs are really cool. Here’s my bug of the night. Click Go, once, and Scramble a few times.

Geometrical interpretation: a perfectly nonreflective sphere is in each cubical cell, getting cross-sected just like the cubes.

And here’s the source code. It’s based on “cubes” from a few posts back.

Featuring mix(), clamp(), and dot().

Very often I need a simple linear-gradient in After Effects, and end up sing the four-color gradient because that’s all I can find. And so, here, for your perusal, is a Pixel Bender implementation of a Linear Gradient Generator.

After that, we’ll see the code, and after that, a quick review of the math.

Here is the .swf. (With some improvements on the Pixel Bender viewer — you can drag any float2 parameters as points, now.)

Isn’t that fun? Well, I’m easily amused.

The Code

Here’s the Pixel Bender code.

kernel Gradient 
{
    output pixel4 dst;
    parameter float2 p1<minValue:float2(0,0);maxValue:float2(400,400);defaultValue:float2(10,10);>;
    parameter float2 p2<minValue:float2(0,0);maxValue:float2(400,400);defaultValue:float2(130,130);>;

    parameter float3 color1<defaultValue:float3(0,0,0);>;
    parameter float3 color2<defaultValue:float3(1,1,1);>;

    void evaluatePixel() 
    {
        float2 co = outCoord();
        
        // shift everything relative to p1.
        float2 uv = co - p1;
        float2 xy = p2 - p1;

        // the math.
        float g = dot(uv,xy) / dot(xy,xy);
        g = clamp(g,0.0,1.0);

        // the color.
        dst.a = 1.0;
        dst.rgb = mix(color1,color2,g);
    }
}

The Math

I’m ok at math, but not always fluent in it. I can remember what a matrix is, but not necessarily exactly what a cross-product is. Maybe you’re like me. In which case this quick run through the math and logic behind the gradient fill will be quite useful in your own Pixel Bender bending!

And be assured, a few pages of high-school-algebra-style scribblings, and the occasional google (How do I invert a rotation again? What’s the formula for perspective?) really can lead to workable results. Good clean fun!

Let’s go.

Consider a trivial gradient, where our two control points are at (0,0) and (1,0). That would be easy! Just take the x-value of any pixel, and that’s your color. (That is, the position on the ramp between your two gradient colors.)

By the way, this picture is from Ron Avitzur’s “Graphing Calculator”. The story of its development is legendary; less well known is that it’s actually a very powerful and useful tool.

I found the easiest way to think about a general two-point gradient was to ask, “How do we rotate and scale our control points back to this trivial gradient?” And let’s assume that the first control point is always at (0,0).

Here is matrix for a basic rotation, which moves any input point by a rotation around (0,0):

[1]

A rotate-and-scale matrix looks like that, times a constant on each element.

We want to think of our general gradient as a transformation on the trivial gradient. Let’s say our second control point is (X,Y), and our first control point is (0,0) as mentioned above. The rotate-and-scale matrix being applied, conceptually, is:

[2]

To figure out the 0-to-1 trivial position of any of our input points, we need to invert it. A matrix inversion looks like:

[3]

So, we invert the second equation [2] by plugging it in to [3] and get:

[4]

Now, let’s call each pixel position of our output (U,V). For our gradient, we actually don’t care about the resulting Y position; just X gives us our gradient value. So we get:

[5]

Now, the definition of the dot product of (A1,A2,A3,…) and (B1,B2,B3,…) is (A1B1 + A2B2 + A3B3 + …). So, from the above, UV+XY is, conveniently, (U,V) dot (X,Y). Similarly, X² + Y² is (X,Y) dot (X,Y).

And now, when you read this part of the code a second time, it should be much clearer what’s going on:

    void evaluatePixel() {
        float2 co = outCoord();
        
        // shift everything relative to p1.
        float2 uv = co - p1;
        float2 xy = p2 - p1;

        // the math.
        float g = dot(uv,xy) / dot(xy,xy);
        g = clamp(g,0.0,1.0);

        // the color.
        dst.a = 1.0;
        dst.rgb = mix(color1,color2,g);
    }

Simple and useful!

Next up, soon, more cubes.

Featuring distance().

One of the important games we play while writing a script or software — or other kinds of black boxes, too — is, “How can we tell what’s going on inside?”

Modern debuggers in modern programming languages make this a nearly-solved problem. Sometimes. Maybe it’s a new language and the tools aren’t there yet, or maybe you’re too cheap to purchase them. Or maybe you just like debugging with print statements. That’s cool.

In the case of Pixel Bender, I’ve been lately using several float2 variables to represent locations on the input or output. It turns out to be quite handy to drop “print” markers right in the output, to better see what’s going on.

The trick is extremely simple. If the distance to float2 value is within a few pixels, draw a color. Here’s the code to do it. It should be done last, after other pixel computations. That way it can be easily commented out or deleted before shipping.

        float p1Dist = distance(p1,outCoord());
        if(p1Dist < 3.0)
            dst.rgb = float3(1,0,0); // draw red
        else if (p1Dist < 5.0)
            dst.rgb = float3(0,0,0); // black outline

Handy!

Haven't figured out how to stamp little text figures into the output yet. You'd need to decompose your desired output on a per-pixel decision tree... would be an interesting logic-reduction problem, but perhaps impractical. It would be possible and useful to stamp 3 floating point values as "special debug pixels" at (0,0) and other easy to find locations.

At any rate, here's the whole kernel, ready for copy-and-pasting.

<languageVersion : 1.0;>
kernel DebugMarkers<namespace:"ns";vendor:"omino.com";version:1;> {
    input image4 src;
    output pixel4 dst;
    parameter float2 p1<minValue:float2(0,0);maxValue:float2(400,400);>;
    parameter float2 p2<minValue:float2(0,0);maxValue:float2(400,400);>;

    void evaluatePixel() {
        float2 co = outCoord();
        dst = sampleNearest(src,co);
        float p1Dist = distance(p1,co);
        if(p1Dist < 3.0)
            dst.rgb = float3(1,0,0);
        else if (p1Dist < 5.0)
            dst.rgb = float3(0,0,0);
        float p2Dist = distance(p2,co);
        if(p2Dist < 3.0)
            dst.rgb = float3(0,1,0);
        else if(p2Dist < 5.0)
            dst.rgb = float3(1,1,1);
    }
}