2
$\begingroup$

This seems like the kind of thing that would be easy, or at least possible, but I'm having trouble finding information on it.

As a test I've created a PNG image sequence of a sparkle, shimmer, or whatever you want to call it.

Sparkle image sequence as an animated GIF

And you can imagine what this might look like on an object:

A twinkling monkey as a test object

Here is my node setup in Cycles, which displays and animates on UV-mapped meshes, but so far has not worked at all with particles. It uses the black-and-white image sequence as an alpha mask.

A PNG image sequence is being used as a mask controlling transparency

What I want is for each particle, once it is born, to start on frame 1 of the PNG sequence, and either die or stop animating at the final frame 20 (which is blank). So each sparkle would appear for a brief flash and then be gone. And I am hoping Blender is clever enough to treat each particle's image sequence as unique and beginning at a different time relative to that particle's spawning, not relative to the scene and twinkling all together in unison.

For now I want to do this in Cycles, but in the future probably in Blender Render too. So mainly this is a Cycles question, but solutions for Blender Render are also very welcome.

Thanks in advance for any help.

$\endgroup$
  • 1
    $\begingroup$ FYI: blender.stackexchange.com/questions/52892/… $\endgroup$ – lemon Mar 13 '17 at 17:29
  • $\begingroup$ @lemon Thanks! Actually, I was wondering about that. Is the best alternative to use constraints to make image planes that always face the Camera? $\endgroup$ – Mentalist Mar 13 '17 at 18:19
  • $\begingroup$ To be checked in this case: do the dupli objects inherit of constraints? If not, this can interest you blender.stackexchange.com/questions/67207/… as here you should give the wanted orientation in the same principle $\endgroup$ – lemon Mar 14 '17 at 5:34
  • $\begingroup$ @lemon Thanks for the link! That looks interesting. I've found a simpler way to get textured plane particles to face my camera, and I will post more details about this soon. Also, the Cycles material is showing up fine and animating. So at this point the only big question remaining is: how to get each particle's texture to animate timed to the particle's lifespan. $\endgroup$ – Mentalist Mar 14 '17 at 9:44
  • 1
    $\begingroup$ Update: I've now got particle textures animating to particle lifespans, so I believe this question is solved. I will do just a bit more testing and post an answer in the coming days in case others are curious. $\endgroup$ – Mentalist Mar 15 '17 at 16:03
8
$\begingroup$

There are two parts to this question: making the particles face the camera, and then making the particles animated. I will address each separately.

Billboard Particles

This functionality is currently not supported in Cycles. That is not to say, however, that it is impossible.

One simple approach is to parent a plane to the center of mass of the object, set a tracking constraint to the camera, set the particle system to dupli-object, and enable parent rotation to the particles:

Dupli-object properties

With this method, not all of the particles are technically facing the camera perfectly. But I have found that the camera has to be pretty close to the object for it to be noticeable, so unless you are using a fish-eye lens or are trying to get macro shots, this should be acceptable for 99% of cases. The distortion also adds a bit of randomness to the size which can sometimes be desirable.

The other approach is to create another scene which renders using the internal engine, wherein billboard particles are supported, and then link the two objects. For this to work, you will have to configure a camera in Blender internal which functions the same as the one you have in cycles. This can take some time, because each engine deals with camera settings differently. Here's a Reddit post going into more details if you wish to do this.

You could also probably develop a script or a add-on which adds functionality. Unfortunately I don't know enough about Blender add-ons to detail this approach any further.

Animated Particles

tl;dr: there's a node in Blender called Particle Info which can be used in conjunction with a sprite-sheet to animate particles using some Math.

I'm surprised that people have deemed this "impossible." It just takes a (complicated) node setup. I'm going to assume you know some basic discrete mathematics to set this up. You will need a custom mapping node, which you can either download or make yourself from this post. You will also need a Math.floor node which you can, again, either make yourself or download in this pack.

The first step is to convert your image sequence into a sprite-sheet. You can either manually do this in Photoshop or write a simple script to do this for you. This tutorial will detail how to do this with just 1 row, as seen in my example:

example spritesheet

Note that it is perfectly possible to have more than one row, but it just takes some extra effort in the node editor.

Next, create a plane set it as a dupli-object for the emitter. This will be the master particle. UV unwrap the plane and configure it to be exactly the size of the first particle as shown here:

UV unwrap the plane like so

The only thing left is the material. As it turns out, there's a node in Blender that gives all the information necessary to create animated particles like this called the Particle Info node. I was surprised I hadn't known about this already, since it seems so useful. The two values we want are Lifetime and Age.

The approach will be different depending on how you made your sprite-sheet, so a basic knowledge of math functions will be useful. You can find many guides to dealing with spreadsheets in game design online, but I don't think its necessary.

The basic approach is to translate the uv mapping of the plane depending on how long the particle has been alive. So, for instance, right as the particle is spawned, it is on frame 1 (and has been translated 0 pixels to the right). Halfway through, it will be on whatever the middle frame is. So, if there are 16 frames in the animation, it will be on frame 8, and will have been pushed 7 tiles over.

The node gives us lifetime and age. Dividing age by lifetimes gives a ratio from 0 to 1 that corresponds to how long the particle has been alive. Multiplying by the amount of frames in the particle animation gives a number that corresponds to the amount of tiles the uv needs to be shifted to the right, plus some extra decimal information that isn't necessary (since you never want to translate the uv, say, half of a tile). You can cut this off with a Math.floor node, giving all the information necessary to make it work.

Hopefully that all makes sense. Here's my node setup (applied to the plane) for the example sparkle animation with 16 frames shown earlier:

Node setup

  1. This divides the age of the particle by the lifetime, giving a percentage of how complete the animation should be (as detailed earlier)
  2. This multiplication corresponds to how many frames there are in the particle's animation
  3. You have to floor this so that, for instance, you don't shift over by half of a tile
  4. This is the amount to slide over for each tile. For me it is always the reciprocal of the amount of frames, because a value of 1 will wrap around an entire time. I recommend using the Node Wrangler add-on to mess with this node directly to figure out the right value
  5. Simply plugging everything into the custom mapping node in the x category, because there is one row

This will ultimately give you a vector which you can use on the sprite sheet as an image texture, which you can then use in your material as normal.

My final result (with some custom scaling and some other changes in the emitter) looks like this:

final result

Note: I sometimes worry that I'm being patronizing to those that do know math, but I also understand that a lot of artists do not know much math, so I'd like to explain the node setup rather than just handing it out and not explaining it. Please tell me if my explanation is confusing and I will be happy to clear it up!

$\endgroup$
  • $\begingroup$ Thank you for the high quality answer! Please don't ever assume I know math, lol. I can imagine how adding another row (another dimension) could enable random color variations or some similar functionality... cool possibilities. Re-reading the comments it looks like I got it at least partially working and neglected to post an answer - which is good because I like your approach better (I seem to recall solving the facing problem with a 1-bone rig with all 4 face verts parented to it. I don't remember if I ever got the texture animations randomized.) $\endgroup$ – Mentalist Jun 24 '18 at 4:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.