So this is what I want to achieve:
However in 2.78c it changes all particles simultaneously:
I was guided to look into node editor and do follows:
But it didn’t change the color from yellow to red. Am I missing something? Nothing was wrong in particle settings either
Come on…
Your setup actually works okay for particles changing over time, but you want it distributed across all the particles all at once? If have size randomness, you could use that as a sort of randomness value, which would sample the color at random points, but if you want an actual randomness value you’d probably do well to upgrade to 2.80 or later and use Cycles render. What you’ve got will work for particles changing over time, though, which is cool in and of itself.
No. I don’t want all particles change color at once (which is easy to do by just keyframing RGB). I want them to change particle color over lifetime (as shown in very first image). In truth, I want them change alpha as well.
And NO! I DON’T TAKE 2.8 OR CYCLES FOR ANSWER!!! I want solution for 2.7 and 2.7 only! It’s not too much to ask!
< not a troll> why don’t you want to upgrade to the 2.90 LTS version ? </not a troll>
Due to lack of internal render. Cause without it making materials would be a waste of braincells. Plus it could be too heavy for my pc.
To me, Materials in Internal Render are less intuitive than Cycles nodes, but that’s just me I guess.
Dividing the age by the lifetime (or vice-versa?) is the correct way to do it. I’m fiddling with stuff right now, and it has just come to my attention (too late lol) that you want it with halo rendering. I don’t know how to make that work, unfortunately. I’ll keep testing, though.
An alternative could be just to render the particles as solid and blur them in post?
What is that supposed to mean?
Anyway, so how am I gonna make particle color, alpha, size or other setting change over lifetime in 2.7 and with internal render?
Particle age divided by particle life time, plug value into color ramp with colors you want, plug into color value of extended material, plug into color output. Repeat for the second color ramp with white to black, plug that into the alpha value of the material output. Make the emission value greater than 1, like 16 or 64, or even higher. Make sure particles are on a separate render layer. Use that renderlayer in the compositor and either apply fog glow or just blur the particles to make them look like halos. THIS TECHNIQUE DOES NOT WORK FOR HALO RENDERING! You must used solid rendering and use post processing to blur the particles out.
I would also highly recommend that you download the Sobotka’s Filmic Color Management to put into 2.78, as that would produce more accurate color and luminosity values. Overexposed points will be white, but still glow their color when the compositor glares or blurs it.
Then what technique DOES work for Halo rendering?
Does this work in internal render?
Then what technique DOES work for Halo rendering?
I wouldn’t have a clue, sorry. I offered you the best alternative I can come up with. Why do you need halo rendering? Wouldn’t rendering them solid and blurring them afterwards produce a similar or basically the same effect?
Does this work in internal render?
Yes it does. The color management settings work across all (or at least the stock) rendering engines. Or well, it did when I installed it.
I doubt that about solid spheres. Using textured planes might work, but they need to be facing camera all the time or something. You know, billboards
Well that’s easy enough to do. I’ve made those before. They mostly work as particles, afaik, but I think it’d be fine.
On the other hand…
Rendered image before compositing
I think blurring solid spheres might work. But billboards would too. Just render out a white fuzzy circle either with or without alpha, but if you don’t do alpha make sure it’s on a black background. Use the alpha channel/black and white image as a mask. Then use the colors generated by the particle information to color it in.
To make billboards, it’s as easy as putting a copy rotations constraint on to the object you want billboarded, making it copy all axes, and setting the camera as the target. A locked track would work as well, possibly even more accurate to a sprite.
Anyway, I hope this helps you. Your prerequisites required some thinking, but I think it will work out.
If you’re ever able to, EEVEE and Cycles can produce some pretty amazing results, and I highly encourage you use them. But BI has some stuff in it that’s pretty unique, and I keep coming back to it every now and then.
Guess I could try that method of yours then. Vranho (who seems to still use 2.4 or something) also provided a solution that works in 2.7 and internal render
Why do people still use such old versions!? It’s nuts! So many new features to use, so many quality of life improvements. 2.78 is one thing, but 2.4?!
The older versions just fulfill their needs. And not only some people find them easier than newer versions, but also more comfortable. 2.7, for example, has everything I need except stars panel that didn’t deserve to be removed either. What it has better to 2.4 is particle hair system, ambient occlusion, indirect lighting, animation syncing and that some things like IK’s are easier to set up. Addons are easy to install too.
All versions of Blender have their benefits and pros, and because of this they all deserve to be supported too. No matter how old, no matter what is better or worse in each, if somebody needs help with them, they deserve that help. That’s equality.
Same goes with render farms - including SheepIt. It’s not right for them to end support to older Blender versions, as it only restricts people’s possibilities to get their animations finalized.
Here’s Vrahno’s channel and videos btw. Hopefully this’ll teach you the worth and benefits of the internal render:
I’ve seen Vrahno’s work, mostly his BIONICLE stuff. I still don’t really understand anyone wouldn’t upgrade for the new features, bug fixes, and quality of life improvements. But I suppose that’s their prerogative.
