Flickering first iteration instead of smooth fade in

Hi guys,

Trying to smoothly fade-in the newest element of a z-values iterated object using the Make Unlit Image Shader and playing with its “Opacity” port.

However, it usually flickers instead of fading in, like 15 flickers for 1 fade-in.
It’s probably just an easy solution but I’m stuck ;)

If anybody has an idea, comp joined. Thanks


Fade In First Iteration.vuo (8.34 KB)

I hope this can help you, see attached:

Fade in Opacity Colour List Enqueue Layers.vuo (5.36 KB)

This has been bugging me all weekend and I still have not found an answer to fix it.

The problem is because the iteration which you want to replace is still there, cut list is not functioning.
The fading iteration is just being placed on top of the existing one.
I think you need to build the iterations with a different method or maybe someone else can figure it out.

Thanks a lot @scratchpole for looking into it.

Yeah I don’t understand what’s going on.
Your composition made me wanna run tests on the most basic possible composition, and even adding a Spin Off Event node to be sure the Smooth With Duration reset port gets hit before its target port, but saving the composition and watching the video frame by frame, I can still see it flickers the solid color before fading-in.

Don’t know if it’s a bug, or we really overseeing something really obvious ;)

Composition and video attached

Flickering Layer Opacity Enqueue.vuo (4.46 KB)

In your most recent composition, the problem is that the Make RGB Color node is executing too early. You’re firing an event right when the composition starts, which goes down the line to create a random color, adjust its opacity, and render the colored square. That event slips in before the first event comes through Smooth with Duration. So before Smooth with Duration has a chance to set the opacity to 0, you’ve executed the node one time with opacity 1.

You can see this by feeding the output of Make RGB Color into Display Console Window or Record and Play Values. Look at the first line/item in the output: opacity (alpha) is 1. In subsequent lines/items, opacity goes to 0 and gradually increases from there.

When I have problems like this involving timing, I find that it usually helps to involve fewer events/triggers rather than more. You can get rid of the Fire on Start and Spin Off Event, and instead use an Allow First Event (Non-Flickering Layer Opacity Enqueue.vuo). That reduces your composition from 4 event streams down to 2. Oh, actually, you can reduce it further by replacing the Fire Periodically with an Allow Periodic Events (Non-Flickering Layer Opacity Enqueue 2.vuo). That brings you down to 1 event stream (Render Layers to Window : Requested Frame). That gets everything synchronized and it’s easier to understand what’s going on.

Flickering Layer Opacity Enqueue - Record.vuo (5.1 KB)

Non-Flickering Layer Opacity Enqueue.vuo (4.23 KB)

Non-Flickering Layer Opacity Enqueue 2.vuo (4.31 KB)

To answer your original question, if you’re open to other coloring besides flat/unlit, another option would be to use lighting to fade in objects as they move closer. Add a light to the scene and limit its range to cover only the closer objects.

Fade in moving closer.vuo (6.05 KB)

Thanks a bunch @jstrecker !

While your solution really does solve the problem, I admit I don’t really understand why my composition did not work since I thought Fire On Start would hit the Set Positionport of Smooth With Duration first because a) to reach the Make HSL Color it has to execute Make Random Value first, whereas Smooth With Duration is hit directly, and b) because I thought Spin Off Event would add a delay, allowing Smooth With Duration to be reset first. So somehow I guess Smooth With Duration takes longer to execute.

if you’re open to other coloring besides flat/unlit, another option would be to use lighting to fade in objects as they move closer

Thanks for that too, however the uploaded composition is a simplified version of enqueued objects with transparent unlit image areas.

Anyway, thanks for the fixes !! I guess with some hold nodes it would be possible too, but your solution is elegant.  

Your reasoning about the Fire on Start and Spin Off Event is mostly correct. But here is the missing part: When the event from Fire on Start reaches Smooth with Duration, the input port that it hits has a wall, so the event is blocked. In other words, the event doesn’t pass through to the output port of Smooth with Duration.

The first event that does go all the way through Smooth with Duration comes from Render Layers to Window : Requested Frame, about 1/60 second later.

1 Like

the input port that it hits has a wall, so the event is blocked

Time for me to give the manual section about walls a read again ;)