[Stuart Simpson]

Okay this seems to work, although I’m sure it can be made more elegant!

Basically, only the z depth seems to affecting the opacity now, not any of the other position coordinates.

I’ve added my own novice understanding of what’s happening so please feel free to correct and improve for the benefit of others 🙂

// SETTING THE CONTROLS //
startFade = thisComp.layer("opacity controller").effect("start")("Slider");
endFade = thisComp.layer("opacity controller").effect("end")("Slider");

// CONVERTING THE COORDIANTES //
C = comp("MASTER").activeCamera; // SELECTS THE CAMERA LAYER IN THE MASTER COMP //
CL = comp("MASTER").layer(thisComp.name); // SELECTS THE PRE-COMP IN THE MASTER COMP //
CLTRANS = CL.toWorld(toWorld(anchorPoint)); // CONVERTS THE PRE COMP LAYER ANCHOR TO WORLD COORDINATES //
CTRANS = C.toWorld([0,0,0]); // CONVERTS THE CAMERA LAYER POSITION TO WORLD COORDINATES //

// CALCULATING THE FADE //
ZONE = CLTRANS[2];
ZTWO = CTRANS[2];
d = length(ZONE, ZTWO);
linear(d,startFade,endFade,0,100)

[Stuart Simpson]

Hi all,

If I’m reading this correctly I have the same issue. I’ve been using this Dan’s expression (below) for the opacity of a series of layers. With the camera in a master comp and the 3D layers in a pre-comp within the Master comp (the pre-comp is a 3D layer in the master comp with transformations collapsed).

The problem is the x-position seems to be affecting the opacity and I need just the z position. Any ideas greatly appreciated! 🙂

startFade = thisComp.layer("opacity controller").effect("start")("Slider");
endFade = thisComp.layer("opacity controller").effect("end")("Slider");
C = comp("MASTER").activeCamera;
CL = comp("MASTER").layer(thisComp.name);
CL.toWorld(toWorld(anchorPoint));
d = length(CL.toWorld(toWorld(anchorPoint)),C.toWorld([0,0,0]));
linear(d,startFade,endFade,100,0)

[Stuart Simpson]

Hi Dave,

Thank you for the prompt response! We’re working collaboratively / remotely with partners hence the problem – pre-pipeline we’d normally ensure we have the same installation on our machines.

Anyway.. Just tried Plexus 2.1.1 on the machine with the problem (windows AE CC 2015 previously running 2.0.10) and it seems to have the sync between the Null and points render, and at the moment all looking good.

Fingers crossed problem solved!

All the best

Stuart

[Stuart Simpson]

Thanks guys. Over a decade of using AE in broadcast design I’ve been used to thinking of that all important intended end display, and yes those thin lines are a pain in traditional broadcast media!

However, end design and intended purpose aside – the reason I didn’t think this was a display issue was that over a whole 3D grid of lines it was one section of a verticle line that had the flicker and it just didn’t look like the artifacting I’d expect from a moving line, or for that matter any bunch of pixels. Perhaps a better description would be a pulse of ocillating thickness than a glitching flicker 😉

Interstingly moving a visually similar width line (so the same actual displayed pixels) at the same speed but created via a different method (stroke of a path say) didn’t reproduce the same result. It not being down to depth of field or camera viewing simulation (which often causes that sort of problem) this made me think it’s something to do with how Pleuxs is calculating the display width of the line?

Anyway… Problem patched with the work arounds above! Just interested to know in the background a bit as it might help solve problems in the future and the Plexus forum hadn’t been much help 🙂

[Stuart Simpson]

Hi Kalle,

Thanks for the response, good idea! In the end I rotated the Plexus cube by 2.5 degrees on one axis which didn’t effect the design and seemed to reduce the flicker enough.

I don’t suppose you have any idea why this happens? Presumably this is something to do with the maths of how Plexus figures out the lines? I’ve not encountered this with some other line creation methods, for example path strokes before (when viewed within After effects on monitor displays).

All the best

🙂

[Stuart Simpson]

Wow scratch that. Copying and pasting the expression noticed the 1 typo…. Couldn’t see the wood for the trees as they say!

So now when I scrub the values tween and when I stop the mask redraws but when I preview it stays the same shape!?!

I’ve posted this as a separate issue now too!

Stu

Okay, edit to the above… I think it’s because I only have a trial of the plugin and RAM preview only comes with full version…. But phew, sorted…

[Stuart Simpson]

Wow scratch that. Copying and pasting the expression noticed the 1 typo…. Couldn’t see the wood for the trees as they say! Sorted…

🙂

[Stuart Simpson]

Thanks for getting back to me Michael, I’ll try posting this problem separately to see if anyone has the answer.

I’d recommend trying that plugin I mentioned. It has the option to link vertices to nulls to.

Stu

[Stuart Simpson]

Okay so go it calling the values from the comments of the reference layer (The comments call on key frame values that are in the animating layer).

But it seems to be jumping to those values at the layer marker, rather than easing between the values called by the two layer markers.

I must admit this is a bit outside my comfort zone so any help much appreciated!

m = thisComp.layer("reference").marker;

// set the previous and next marker key values

Keystart = 0;
if (m.numKeys > 0)
{ Keystart = m.nearestKey(time).index;
if (m.key(Keystart).time > time) Keystart--;
}
Vstart = REST;
if (Keystart > 0)
{ Vstart = eval(m.key(Keystart).comment);
}

Keyend = Keystart+1;
if (Keyend > m.numKeys)
{Keyend = Keystart;
}
Vend = REST;
if (Keyend > 1)
{ Vend =eval( m.key(Keyend).comment);
}

// set the previous and next marker key time

Vstime = time;
if (Keystart > 0)
{ Vstime = m.key(Keystart).time;
}

Vetime = time;
if (Keyend > 1)
{ Vetime = m.key(Keystart).time;
}

// finally the ease expression

ease(time, Vstime, Vetime, Vstart, Vend)

[Stuart Simpson]

Yup that’s what I thought, but…

I’ve just found the BAO Mask Avenger plugin which allows you to edit masks vertices and tangents in real time with key frame friendly position properties. So almost there!

So now I just have to be able to use the comments property of the markers on a reference layer to trigger which key frames are being used to tween between. Currently I have ten possible position key frames that I want to animate between.

So I mighty choose position 1 at frame 10 to tween between position 5 at frame 30 and then back to position 3 at frame 35.

I’ve found some of Dan’s expressions that map markers to an in and out point only, but not sure how to adapt that for more than 2 markers.

Any ideas?