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
Cheers
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 Position
port 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 ;)