100,000 names in AE….how?

[Nick Hill]

I think you’d be insane to try this in AE 😉

I can only think of two ways to do it – either you load one text layer with a massive string representing all 100,000 names (not practical, would probably bust the maximum length of the string, and you wouldn’t be able to position any of the text) or you create 100,000 layers, one for each name. Until Adobe think of some kind of efficient way to instance layers, this would likely kill your CPU and memory instead of the graphics card. Plus it would be horrendously slow. I’ve done things before with only a few hundred layers which are all controlled with the same expression code linked to expression controls, and depending on how complex the expressions are I tend to get between 1 and 3 fps on an 8-core machine.

Also, it sounds like each name has an associated date determining its position. There is no way of storing data like this in AE efficiently.

It sounds like what you’ve got already works pretty well – is it Flash or Processing or something? I don’t really get why you want to change it…

[Filip Vandueren]

By ‘Scroll upwards’ do you mean they actually move, or just that the opacity moves up ?
Also, if you just have the names in chronological order, I’m guessing it doesn’t actually matter that the X-position is exactly correlated to the date, right ? just that the first one is in the lowerleft, and the last one is in the upper -right, counting up in semitransparant (slightly slanted) columns, that are center-justified.

Also what kind of timing are we talking about here. If each of the 100.000 name is highlighted for 1 frame, we’re still looking at a comp of about 70 minutes…

Anyway, I’m figuring it out now, I’ve got a comp working with 1000 nmaes, takes about 6 seconds per frame.
Optimizing because I think I have a better idea.

I’ll get back to you.

[Filip Vandueren]

Mkay,

a solution where there’s a textlayer that contains all the names, and animation is only done with text-selectors works in theory, but is not scale-able to 100k names, because the positioning of the names must be recalculated every frame eventhough they’re still.

My solution is this:

1 invisible textlayer holds 100k names, one name per line.
one BG layer is just a bunch of jibberish (this can be rendered totally correctly once and re-imported as a still), but with this many names, it’s indistinguishable if the actual names still line up when they’re faded out.

the top- text layer displays 1 name per frame, (looked up from the invisible layer) in the correct position.
The echo effect makes sure this trails off.
with 100.000 names I’m at about 1 second per frame rendering time.

[Peter Whittaker]

Sorry for not getting back sooner, was isolated from the interwebs!

Wow Filip, impressive. To clarify, what happens is that the names themselves don’t move, but just change opacity. The opacity change moves up the screen, and each name fades back to, say, 10% opacity.

The speed of the “scrolling” is about 15 names per second, so based on your calc that’s 70 mins / 15 = ~5 mins total comp time.

Some backstory: this is a list of names and dates of death. We have it running in Quartz Composer in OS X. We have to do something similar with a layer of pre-rendered text for the background munge, but its the actual names in the right positions, just copied and pasted from the Quartz composition into Photoshop in smallish chunks.

Re the assumption that the X-pos isn’t important, you’re mostly correct. The interesting thing we’ve found from having an accurate X-pos per name is you see changes in density across the screen, showing as lighter or darker bands. This adds some natural variance to the texture of the screen, and also shows that, for instance, more people die in winter than summer.