-
Flickering particles in Particular
I’m using Particular to draw a line across the screen (basically a null travels around the screen. the particle production count is driven by its speed in order to produce an evenly thick line of particles that last for the duration of the comp).
The particles themselves are basic Spheres, and pretty much every dynamic is turned off (gravity, air, motion). Static particles are produced in varying quantity when the null moves. Nothing if the Null is static. The particle life is > the length of the comp. Everything is expression driven.
Simple concept and it works fine. EXCEPT for the dreaded flickering particle situation.
Randomly, at certain frames no particles will render (i.e. the line will disappear) only to reappear a frame later.
Much googling has shown me this has surfaced many times, but it usually seems to be connected to Spite based particles. The solves there-in work as well, kind of. Changing a parameter (like the Seed) will cause that frame to return, but will cause another frame to start experiencing the error.
The solve would be to step through frame by frame and pick a Seed where the glitch doesn’t occur for each frame. It’s not a scalable solution. There is no solve that I have found to make all frames render correctly all the time. I’ve even tried stuff like rapidly oscillating the emitter in Z-space to try and prevent particles stacking. To no avail.
AEP is attached for the curious.
I have a thread out to Trapcode support and will update if they have any sage advice.
-
4 Replies
-
😀
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.
-
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.
-
You might consider Ouroboros as a tool. It gives you quite a bit of cool stroking power in AE. You can base it off of a motion path too. 🙂
– The Great Szalam
(The ‘Great’ stands for ‘Not So Great, in fact, Extremely Humble’)No trees were harmed in the creation of this message, but several thousand electrons were mildly inconvenienced.
-
Thanks, Michael… interesting looking tool. I’ll take it for a spin and see if I can find a working mechanic in there.
Reply to this Discussion! Login or Sign Up