Nested particle systems?

[skinnytorus]

Hi, guys.
I've noticed that there can be just 2 levels of particles (parent emitter -->spawning emitter).
But what keeps us from adding one or more levels of particles above (in the case of sMode actually 'below') the two? Performance issues?

[francis]

Here is a trick: turn your renderer into a group (with ctrl+shift+G). Once you have done this, you can put local modifiers inside the renderer. By nesting this technique several times you should be able to do emit particles > emit particles > emit particles ...

[skinnytorus]

Thanks! That's a really cool technique, man. I just LOVE it!
But I stumble over the same old problem again: there's no easy way to stop all the particle systems at once.
I have to create a parameter to drive sim speeds of all of them. This makes experimenting with different particle setups a chore.

Why won't you make a global variable (readable by all particle systems) and a switch in Preferences to let the Timeline control particle simulation (on/off)? That should be a cheap and simple trick imho. What do you think?

[martin]

Indeed, it is a simple trick, but maybe a bit too cheap.. It wouldn't benefit other use cases than that particular one it seems (unless someone has some other examples where such a switch could be necessary?)

A solution to that would be the Particle events and actions, which have been on the drawing board for a month now, and that we'd like to start to implement for the next release (ideally !!). Those events are a bit of a refactoring for the particles so we'll see how long it'll take, but this would allow you to simulate different particle systems within just one, not needing a second or third "Emit particles" modifier to do that.

The "Emit particles" in that case would only be used to emit particles from a mesh (fbx, box, plane...). One particle system would satisfy the *nested * scenario, and your problem with the simulation speed not being shared would vanish !

This one seems like the one true solution

[skinnytorus]

Hi, @Martin.

Indeed, it is a simple trick, but maybe a bit too cheap.. It wouldn't benefit other use cases than that particular one it seems (unless someone has some other examples where such a switch could be necessary?)

Sorry, but I can't agree with you on this one. Take a look around - most (if not all) 3d and compositing apps freeze particles at Timeline Stop command. Please, consider that working on a shot/effect involves composition of multiple elements and a particle system is just one of such elements. In order to focus on a certain element of the scene the designer absolutely needs being undistracted by other moving elements. In my opinion, that's common practice, man.

Imagine this: you're working on a cutscene with a dialogue of 3 characters and... miraculously you just can't stop their animation and edit their gestures and articulations at critical moments of the scene - you have to do it on the fly while playing the scene over and over. This will start to get on your nerves pretty soon, eh? That's basically what I'm talking about.

A solution to that would be the Particle events and actions, which have been on the drawing board for a month now, and that we'd like to start to implement for the next release (ideally !!). Those events are a bit of a refactoring for the particles so we'll see how long it'll take, but this would allow you to simulate different particle systems within just one, not needing a second or third "Emit particles" modifier to do that.

Sounds cool. Thanks! Please also consider allowing the user to use different particle renderers before and after events. And, please, see if you can add more particle emission modes. One shot, Contunuous, Burst (at equal or random time intervals). A cool feature would be a Particle Delay parameter allowing to delay the particle simulation in time without keyframing the emission rate.

[martin]

That's true, we need a deeper integration of particles into timelines. We need to be able to seek in a particle animation for that, so we have to bake it (quite a big feature !).
The short term solution is to expose a parameter and connect the other sim speed to it, like you do (I know it's not the fastest option though).

But luckily your post actually quite on topic for what we are currently developing
We are currently enforcing the concept of "main timeline", kind of like in after effects or blender, where one scene has one timeline, hard linked to it.
We could maybe link the manipulation of that main timeline to the state of the particle simulators within the same compo (resetting the timeline resets all simulators, playing plays them and pausing pauses them). Could have an option in that timeline offering to link it or not to the particle systems.

That's not the same as the true playback/seek in a baked particle animation, but it seems like it could very well cover the scenario you are talking about. A more intuitive approach to Smode for content designers and animators.

I'm adding it in the internal issue tracking system

[skinnytorus]

Thanks a bunch, pal!
You'll see that eventually this approach will pay off.

[skinnytorus]

Hi, @Martin

We could maybe link the manipulation of that main timeline to the state of the particle simulators within the same compo (resetting the timeline resets all simulators, playing plays them and pausing pauses them). Could have an option in that timeline offering to link it or not to the particle systems.

I'm testing the latest beta. Looks like I'm out of luck with that feature for sMode 7.7. Or there's yet hope?

[martin]

Sorry, not yet ! But there have been a lot of progress on main animations, so we're getting a lot closer to it

[skinnytorus]

Cool! Thanks for the update