[Raza Ahmad]

Thanks, Michael… interesting looking tool. I’ll take it for a spin and see if I can find a working mechanic in there.

[Raza Ahmad]

What I’m trying to think of right now is a way I might be able to drive many instances of the beam effect using an array of data in an expression. I think that might be a good path, but I haven’t explored it yet.

[Raza Ahmad]

😀

Hello again, Dave.

Totally agree with you. It would be much simpler to use a mask or even the write on tool, I landed on the particular solution (and the even more complicated but more reliable Plexus solution) due to scale issues.

One of the reasons this needs to some kind of semi-automated system is due to the amount of data I’m animating. The position data for the null is actually coming from a python script that’s chewing on an even larger set of data and then outputs it in AE copy paste friendly format. This is a single line, but the final project would have many hundreds of lines each with its own data that needs to pixel accurate. I reduced the project to just a single instance of my situation to help illustrate the error, it isn’t representative of the whole.

I would frankly probably be better off building this viz in processing I just haven’t had the bandwidth to port the project to that system yet.

Mask: No easy pathway for automating the position data. Connects to a % driven animation system, which given that a line may grow 10 pixels one frame, 100 pixels the next frame and so on adds a lot of complicated math that I am unprepared to handle when it comes to figuring out how much the line moves at each frame/keyframe.

Write-on: Can’t produce enough ‘dots’ for fast traveling keyframes. Line not consistently thick due to limitations of the plug-in.

Native particle gens: I can’t recall why I gave up on this one, but for some reason after pursuing this I felt moving to particular was necessary. May have been a similar issue to Write-on.

Other plugins explored: Connect Layers (doesn’t do sequential linking 🙁 ) and Lines Creator (not scalable automatically).

Particular: Easy to get what I want, but the flickering frames plague me.

Plexus: Currently working to do what I want, but animation options are limited (using the beam system combined with a mechanic to duplicate nulls and then move then based on their order to manage the motion distance) but really render and machine heavy once I get up to hundreds and hundreds of lines. Particular was handling the weight a bit better.

Thanks for your advice as always. You’re a huge asset to all of us here.

[Raza Ahmad]

MUCH more render-efficient!

Thanks for the great tip, Kevin.

[Raza Ahmad]

Thanks for the tip, Kevin…

Going to experiment with this now…

[Raza Ahmad]

I know this is probably photographically non-ideal, but:

The simplest option I see here is to only move physical (as in in the real world camera) in one shot, the one where you are dollying in to talent.

The second shot, camera with wipers, would just shoot it with a static camera, if you are using RED or similar you could leverage extra resolution here.

You 3D track your dolly shot, making careful note of lens length and height and marker distance (AND FOCUS POSITIONS!) to get a spacially accurate 3D Solve, then inject your windshield as a 3D layer between the virtual camera and your physical dolly shot, and use the 3D motion track + focus data to realistically blur out the windsheild imagery as your camera moves, ultimately moving past the layer via a very quick dissolve or single frame transition.

Not sure… that would be the $0 film school idea.

[Raza Ahmad]

I think the problem here is you’re moving the map and not the car. This needs to mimic real life.

The way I would do this is to set up the map, arrow and a single camera pointing down looking at the arrow correctly centered on the map.

Then, make the Camera parented to the Arrow. Arrow is parent, camera is child. Now lock the camera and map, and animate the arrow along the road, turning as it goes. If this gets wonky at corners and bends (I can’t see why it would), you could do a pickwhip for X/Y position (only) properties from arrow to camera and X rotation properties and avoid the child relationship.

It seems this would be most easily animated by keyframe and not expression. If you had the map moving at a constant rate, it would feel wrong at turns and corners, where in theory the car would slow down or perhaps stop before making its turns, to say nothing of acceleration/deceleration/cruise speed.

[Raza Ahmad]

It’s a good suggestion.

I haven’t used Sure Target in a long time, I kind of put it in the same bucket as Ease and Wizz… super useful in a pinch, but once you go down that road, you spend hours fighting it to try and tweak your animation curves and flow.

Could be it’s time to revisit them both and see if they’ve aged well.

Thanks for the idea.

[Raza Ahmad]

Alright, well this is pretty hacky but it works.

Step 1:

Put another Null — the ‘tracker’ null – in the same comp as all the other Nulls (fortunately my nulls are named numerically).

Step 2: Attach this code to the ‘tracker’ null’s position property.


//t=frame number
t=timeToFrames(t = time + thisComp.displayStartTime, fps = 1.0 / thisComp.frameDuration, isDuration = false);
//set min/max for the nulls to pull from numerically
if (t<1) {t=1};
if (t>100){t=100};
// assemble a string to seek
y=t.toString();
z='Null-'+y;
//get position from that null
thisComp.layer(z).transform.position


Step 3:
Bake expression to keyframes, stretch and do all other bits.

a work in progress, i’d still love to hear a better solution if you have one.

[Raza Ahmad]

Tried and failed:
Extract position data using an XML export of the project. Position data is obfuscated, or at least not matching the format from a keyframe copy paste.