I was wondering, when using a cloner set to Object mode, linked to a thinking particle group, is there a way to control clone colour value using the particle age?
looks like there was a thread about this already! https://www.cineversity.com/forums/viewthread/681/
ah so it looks like you are keyframing the material channel, wow I didn’t know doing so would blend between the separate material values…
But this doesn’t seem to be based on individual particle age.. just the timeline?
-I guess instead of age, I mean, % of lifetime, as I’d like them to fade in after birth and fade out just before death
I could animate the texture of the clones, then it would play out from point of birth, but I am wondering if its possible to use the clone colour value instead, as it would be much more versatile and effector friendly
I was wondering, with lifetime variation set to high, the “Life” parameter seems to always output same value, I think, if it showed the life after variation, this could be sent to range mapper?
This is exactly the way I currently set up for you. Edit, I added the link below/edit
Use the Range Mapper!
I was just exploring some ideas: Talk to you soon.
Life, is set by the Generator, e.g., Storm, or with additional TP-Nodes later on, e.g., Set Data or PDie: If there is no “Life Variation” in the value, then yes, it will be the same.
Just to play with some option, as the Plain Effector allows to use Blend Modes. With Falloff in the mix, things like “Life Fast Die Young” (Janis Joplin) could be expressed in colors.
Cool! Looks like I’m on the right path.
Right, so my plan is to simply map the colour to alpha channel, so the particle fades in and out of existence
So my plan was to add the “Life” output from PGetData to the range mapper Input Upper parameter, but it looks like this makes all the colours go crazy when the Life Variation in PStorm is set high, I uploaded example here: https://www.dropbox.com/s/ueezledcfut3vv3/bellMod_CV2_r18_drs_17_MGtp_01.c4d?dl=0
The problem with this simple set up is, that particles which might die before reaching the end of the scene, will create an index shift in the PPass Node.
To keep it simple, the Life [-parameter] needs to be as large as the Variant could bring it down, but even the lowest Life value needs to be larger than the Scene duration.
Which needs in return a different Gradient to get the effect. As a side effect, one would suggest to use the UID NODE to give each Particle a unique ID number [UID], but that wouldn’t work with the Cloner, as the number/index for the Cloner isn’t counting then in the same way. So the “Weight-information” would be given to the UID but the Cloner would take the the ID number from zero to current max clones. Hence my hint about complexity… All of that would be avoided by letting the Particle survive.
Let me know if that works for you.
As a side note, if the particles only fly from the emitter away, a simple spherical fall off could do the trick, but I guess, it ifs not that simple.
mm great Idea, I’ll keep messing about with it. Thanks! Yeah I did consider using a falloff effector, all the troubles start when I add variance on the life, which I’m now thinking may be unnecessary for my scene!
Yes, please explore how this method works—as long as it fills one group, and those never leave (die) the group. As long as it stays in a group the Cloner has an equivalent in numbers and so in Index. Anything else goes really into some complexity. In the XP-Poll you will find the Unique ID number node, but that keeps counting up, but the Cloner uses the ID for existing clones and doesn’t count “forward”. I hope that makes sense.
Here is a little idea, to keep the complexity low, that works with the variant parameter without screwing things up. I know you wrote it is not really needed, but for the sake of this thread
It keeps the Life of the particles above the scene time, to keep the particles and the clones “in sync”.
The main idea was to move the particles from the first group (green) into the next group (blue) at an certain age. For each group the age is written into the weight tag. I used a Spline Curve in the Range Mapper, to have your fade in fade out (Alfa) need already into the values. Just a Bell like curve.
The next group goes then from group entry age with a certain time as in the group before. This could go to the next group to the next, etc.
The key, or better the two key elements were here to give each particle a unique ID and have all sub groups under a parent group. The parent group goes then into the Cloner. The unique ID creates a connection between particle and weight entry, so no jumping values. Using the initial speed (velocity and reseting he position helps to create this option.
If all groups would have the same duration, a User Data Slider could be the central parameter for simplicity in use. Just a thought.
I will need some time to understand what’s happening exactly in the xpresso tag, I’m not that experienced with TP.
I have a vague idea of what you mean, but its quite over my head, when i get more time to study this file I think I will understand. Either way I think this will be extremely useful.
It follows the requirements of a shorter than scene duration life span.
Which produces a black color early on in particle’s life, as well as in the late part, anything else is gradually white around the mid point. See Range Mapper Spline. Which can be read out by the MG Color Shader.
All child objects that are initially not used are switched to not seen Editor/Renderer.
This is a set up for 100 particles (based on the TP-Storm settings, which means never more than 100 particles in the scene). I used here an Disc, as it can be set to a number of shapes, triangle, square, up to a disc and all with a hole or as “slice”. Click on the Selection Object to select all 100, to adjust them in the Attribute Manager.
