Switch layer in a particle layer

[Greenlaw]

@ Maestral: Haha! When animators synchronize!

I hadn't posted my example yesterday because this second example is where I ran into a problem. At the time, I wanted to try fixing it first, but then after lunch, I just forgot...



But I don't think I'll bother now. Moho's particle emitter apparently always emits randomly in 3D space, even when there is no actual depth--in other words affecting 2D stacking order, and there is no way to fix the stacking order. (Maybe in a future version?)

I'll post the two project files shortly.

[Greenlaw]

Here we go...

ParticlesSwitchProjects.zip

Version A is the first one with the particle spread out, and version B is the one with the overlap.

If anyone has a fix for version B, let me know. I don't think it's possible, though.

(Note: I think the z-depth trick I tried is still in there, and it's possible I didn't set it up correctly because I was in a hurry, and then I abandoned it.)

[Greenlaw]

All that said, I think if I were doing this effect, instead of using particles, I would just push the repeating items along a path, and switch to a different set of items with the Smart Bone. This way, I wouldn't have to worry about randomness occurring, and I would also have more control over the speed.

This was a fun exercise, though!

[synthsin75]

Moho's particle emitter apparently always emits randomly in 3D space, even when there is no actual depth--in other words affecting 2D stacking order, and there is no way to fix the stacking order. (Maybe in a future version?)

Well, even though the emitter has a height and width, it's still only a 2D plane. So no 3D space to work with.
In that case, it's probably best to do separate particles for fore, middle, and background.


EDIT: Well, if the bottom emitter layer is 3D rotated (with zero width, height, or depth for the particle), it does seem to sort them in 3D space properly.

[Greenlaw]

EDIT: Well, if the bottom emitter layer is 3D rotated (with zero width, height, or depth for the particle), it does seem to sort them in 3D space properly.

Yeah, that's what I meant: it doesn't consistently fire off the particles from front to back or back to front...which I wouldn't expect it to without an option to fix the layer positions (meaning the 'stacking order') of the particles. Currently, it is possible that one particle may be in front of the previously emitted particle, and the next one may be behind...as seen in version B.

So, not a bug, just the way it works.

[Greenlaw]

Hmm...if the option existed, what would you call it?

I guess it would be something like a '2D Stacking Order' list with the options:

- Random
- Always in Front
- Always in Back

Just spit-balling.

[synthsin75]

Hmm...if the option existed, what would you call it?

I guess it would be something like a '2D Stacking Order' list with the options:

- Random
- Always in Front
- Always in Back

Just spit-balling.

So when a particle lifetime ends, it restarts either at the top, bottom, or random in the stack?
That sounds like a great feature request.

I'd call the option "Spawn" for where you want new particles to spawn from.

[hayasidist]

Apparently, Greenlaw and I arrived at the same conclusion.

says the content isn't viewable in my region? (Europe / UK)

[synthsin75]

Apparently, Greenlaw and I arrived at the same conclusion.

says the content isn't viewable in my region? (Europe / UK)

I think imgur image host is banned in the UK.

[hayasidist]

Apparently, Greenlaw and I arrived at the same conclusion.

says the content isn't viewable in my region? (Europe / UK)

I think imgur image host is banned in the UK.

good grief! you're right -- it's probably the "online safety" act!! (requires sites that host (some, potentially) NSFW etc material to implement strict age-verification methods - or ban access)

[hayasidist]

Here we go...

Version A is the first one with the particle spread out, and version B is the one with the overlap.

If anyone has a fix for version B, let me know. I don't think it's possible, though.

it looks to me as though the overlap is because of the emitter cycle restart -- it's on the 6th , 11th etc particle -- so it goes 1,2,3,4,5 stacking on top of each other then particle 6 is particle 1 of the second cycle so its 6 under 5 then 7,8,9,10 on top of each other. IOW its internal to the particle system and I'm of the opinion that this isn't something fixable in the user-end of particles.

[Greenlaw]

Hmm...I think you're onto something. I increased the lifetime of the particles and killed the keyframes in the Switch, and got this...



I'm not sure what's resetting the emitter, though. Does switching to show a different emitter do that?

I guess it would make sense if Moho was trying to minimize processing by stopping what isn't visible, but it's not really doing that here because there's no gap between the particles when we return to them.

Oops! Gotta go...will come back to this later.

[Greenlaw]

Ok, I'm back. I'm not sure the emitter is being reset because if the default behavior is to always place the newest particle in front of everything, even if the emitter was being 'reset', the next particle would still be in front of everything.

In version B, I still don't know why the stacking order gets mixed up after a while, though. I might take another look at the setup later this morning. (But I don't really want to spend too much time on this.)

[Greenlaw]

Oh! It's the particle death that resets the order! I don't know why the order randomly changes, but that must be the trigger.



When I extend the life, as in the previous example (I think it was 400 frames,) they maintain their stacking order.

Okay, moving on...I think.

[Greenlaw]

Okay, one more test before I go: I cranked the lifetime up to 400 frames, and sure enough, the layer order changed at around frame 400, when the first particle dies. Not sure why the following particles dying don't affect the order.

I wanted to know if the 'drift to back' keyframes I added to the sprite had any effect in keeping the order up to that point, so I removed the keys. I noticed a tiny shift when I deleted the keys, but no, the result was visually the same when played.