So last year about this time I was doing some motion & comp work for a pair of cinematics for a big ol’ video game. One of my shots involved having these indicators moving across a screen with a hexagonal tile grid, and the art director wanted the indicators to snap from one tile to the next, giving it a much choppier, digital feel.

It took a while (longer than I’d care to admit, but alas) to get this expression put together. I won’t claim that it’s the best (or even most efficient) way, but if anyone has any suggestions on how I can optimize it please let me know!

The Code

L = thisComp.layer("Control");
P = thisComp.layer("Motion Path - Hex");

xPos = P.transform.position[0];
yPos = P.transform.position[1];

cSize = L.effect("Cell Size")("Slider");
xOffset = L.effect("X Offset")("Slider");
yOffset = L.effect("Y Offset")("Slider");

// Convert size value into distance values between cells
cWidth = cSize*.75;
cHeight = cSize*13/15;

// Find new X and Y positions
yNew = yPos - yPos % cHeight + cHeight/2;
xNew = xPos - (xPos % cWidth) + (((yNew - cHeight/2).toFixed(2)/cHeight).toFixed(2) % 1) * (cWidth/2);

// Check for even/odd column, adjust properly
if (!(xNew % (cWidth*2) == 0)) yNew += cHeight/2;

// Implement offset
[xNew + xOffset, yNew+yOffset]

The Explanation

One thing to note is that this is using YY_HexTex by Andrew Yang to generate the hexagonal grid. As such, it’s adapted specifically for it though it’s fairly easy to swap it out for a premade grid.

The way this works is by looking at the current position, snapping the values to the centre of a grid, then checking to see whether you’re in an even or odd column and adjusting the y-value again accordingly. At the very end, we add in the user-controlled offset so that our layer lines up with the grid properly.

Another thing to notice is that line 17 invokes two uses of toFixed(). If they’re not included, AE has trouble working with some really long decimals and the results tend to go a bit awry. This looks messy in the code, but it’s the only fix I could find.

The Application

To the left, you can see that without snapping, our snazzy little man will just spin around the path– that’s what  we’d expect.

To the right, Mr. Tieman will still follow the path, although now it’ll keep its movement constrained to the hex grid. Stay classy, Tieman.

This can be used for all sorts of FUI/interface work, as hex grids seem to be ubiquitous these days. Or, you know, for your latest and greatest Settlers of Catan fan vid, if you’re into that sort of thing.

If you want to use this on a 3d layer, it’ll take some rejigging to get it to put together, but it should prove an adequate challenge for anyone familiar with expression work.

The AEP

Here’s the link: ZL_SnapToHex.zip (22kb). This was created in CS5.5, but I saved out a CS5 version and included it in the zip.

Once you have it open, play with the “Control” layer sliders to explore different results. You’ll have to adjust the offset values to fit the grid properly.

This AEP requires YY_HexTex to work. If you’re interested in a plugin-free solution, leave a comment or email me and I’ll set something up.

I’ve got two expressions that produce similar (yet different!) results– both define the position for a point along a line, though one is controlled by % completion from one point to the next (0-1), the other by the distance (in pixels) from the start point.

Here’s the code.

% Along A Line

p1 = thisComp.layer("Point_01").transform.position;
p2 = thisComp.layer("Point_02").transform.position;
mult = thisComp.layer("HELPER").effect("Percent")("Slider");

p1 + mult * (p2-p1);

The first three lines are just setting up our links; first to the points, then to our controller. The math here is that last line. This is essentially taking the the line as a vector, scaling its length based on the multiplier, then moves it to the first point.

Distance Along A Line

p1 = thisComp.layer("Point_01").transform.position;
p2 = thisComp.layer("Point_02").transform.position;
mult = thisComp.layer("HELPER").effect("Distance")("Slider");

p1 + mult*(p2-p1)/length(p1,p2);

In this example, we’re normalizing the vector by dividing it by its length so that it uses units / pixels as opposed to %. This way we can have a point, say, 200 pixels away from another, along a line.

In the first example, our new point moves relative to the other two, whereas the distance-based on will always be that same distance along the line, regardless of how close or far the lines are. Without any sort of limiting, your points in both examples can go beyond either point along that same line– I’ve included a solution for this in my AEP, but that’s just one way to do it.

Here’s the link: PointAlongLine.aep (406kb)

In today’s thrilling post I’m going to cover how to limit the number of digits after a decimal while working with expressions. While I know of a few ways to go about doing this, I’m going to cover the toFixed method.

(As an aside, another option is toPrecision() which limits the number of significant digits, but the practical applications of using over toFixed() are few and far.)

So. Simply, toFixed(x) limits the number of digits to after its decimal point to x, by rounding up; let’s take a look, using random. I’m going to give sample results, by the way, for the sake of showing examples.

random(1);
// Result: 0.66781947055548

We’ve got a really long number here, and that’s damned unseemly. Let’s say you were doing some interface work and needed a number to change every frame– this probably wouldn’t work. Too many digits! Don’t worry– that’s where toFixed() comes in.

random(1).toFixed(3);
// Result: 0.668

See, now that we’ve added toFixed, and told it to limit the result to 3 digits post-decimal, our result looks much, much cleaner.

This doesn’t just work with random numbers, though! Pretty much any number can be shortened this way.

// position is [967.337125645, 541]
transform.position[0].toFixed(3);
// Result: 967.337

That’s all I really wanted to go over for today– if you’ve got any questions about this stuff, feel free to leave a comment / send an email!

The main concern is that AE evaluates the entire expression at every frame– there’s no persistence. So any for or while loop will run through in its entirety per frame. If you tried, say, to execute some code while the time is less than 1 second:

while (time < 1){
    // code
}

You’d find AE caught in an infinite loop– on the first frame of your comp, the time will ALWAYS be less than 1 second in– and so it’ll time out. From my poking about online, the majority of uses seem to be accumulating data from prior frames.

I’ve created a mockup of how this works. It counts (and displays) the number of frames a layer is spent above [note: I mean above visually, not greater-than or less-than] a certain y-value. While not the most practical thing around, it should give you a good sense of how to use it.

Here’s the code:

L = thisComp.layer("STAR POWER");
curFrame = 0;
hitCount = 0;

while (curFrame <= timeToFrames(time)){
    if (L.transform.position.valueAtTime(framesToTime(curFrame))[1] <= 300){
        hitCount++;
    }
    curFrame++;
}

hitCount

Let’s break it down.

First, we establish the target layer (“STAR POWER”), and we create a variable for the hit count (the number of times the layer goes above 300), and another for the iterations of the loop.

We then create the while loop. It keeps incrementing the counter until it’s at the same frame the comp is currently on– that’s how it runs.

Inside that loop, it looks at the the position of the target layer at all previous frames, and if the y-value is above 300, it increments the hit counter and displays that.

If you were so inclined, you could rewrite the same loop as either a for loop or a do while loop. Below you’ll find a link to download an AEP with comps containing all three for the price of none!

Here’s the link: ForWhileDo.aep (352kb)

New site, new reel, new blog.

This space will mostly be used to showcase AE expressions that I’ve written and/or adapted for my use, and to discuss projects and problems I’m working.

With that in mind, I’ll try to release AEPs with anything I discuss.

If there’s anything you’d like to see covered (expressions or otherwise), let me know in a comment or email and I’ll try to get to it as soon as possible!

As ever, feedback’s welcome.

Zack