Emit particles from vertices and at regular intervals

skinnytorus 2017-10-14 19:59:21 UTC #1

Hi, guys.
I currently don't see ways to do the following things:
1) Restrict particle emission only to vertices of a mesh with faces (emission always spreads over the entire polygon surface of the model unless restricted by a mask).
2) Emit particles at regular intervals from multiple emission places (e.g. vertices, faces, etc.) Emission time is always a bit random.

Correct me if I'm wrong, but these are among 'must have' features of a modern particle system. Please, see what can be done. Thank you.

Skinny

martin 2017-10-27 14:13:29 UTC #2

Hey !
There is no way to restrict the emission to edges yet.
But you can emit particles on vertices using a "Compute" before the "Emit particles" modifier.

Without compute:

With compute:

I'm not entirely sure I understand what you mean by "from multiple emission places". But to emit particles at regular intervals, you can either use the "Emit now" trigger (animated in a timeline to make it emit regularly/automatically) with a zero emission rate, or you can use the emit particles rule/emit particles node modifier and animate in a timeline their emission rates!

Hope this helps!

skinnytorus 2017-10-28 19:16:57 UTC #3

Hi, Martin.

Great. Thanks for the tip!

By saying that I meant "emit from multiple source geo simultaneously (i.e. multiple points, faces, etc.)".

Looks too complicated. If I were you I would make it an attribute of the particle emitter (something like "Emission Randomness" ratio). To connect moving particles you use Motion Lines, but in order to keep the scene performance stable you have to kill their tail. What I want is to use Connect Points instead thus making the motion lines "immortal". For this I need to keep the distance between the particles as regular as possible. That's why I'm not overfond of the idea of animating the Emit Now each time I want this effect. What do you think?

vincent 2017-10-30 10:59:54 UTC #4

In that case maybe better to use a random point generator and a repeat ? That's what I usually do when I want to use stable connect point on particles.

martin 2017-10-30 11:04:40 UTC #5

Okay, I understand what you mean.
Indeed, a randomness factor seems like a good addition to cover those cases, it's something I've encountered already and will look into it.

martin 2017-10-30 14:20:11 UTC #6

Okay so what I did is that instead of using a random factor to determine how much a particle should be simulated at the first frame it exists, I used a standard interpolation, based on the number of particles that should be emitted.

That means that their will be no more randomness in the position of particles (which is especially visible at high speeds / high "simulation speed" value). That should fix your issue of arbitrarily spaced particles!

Available in the next beta

skinnytorus 2017-10-30 15:23:23 UTC #7

Hi, guys.

Repeat + Size? Great idea, but as far as I know, size donesn't follow emitter mesh normals (aka extrude along normals). Displacement does. By the way, an option to resize along normals for the Repeat operator wouldn't hurt. It's a nice old-school way of faking volumes.

@Martin
Cool. But wouldn't it be a problem if randomness in emitting particles is needed for the scene? Say, I want to make a scene with repeated blaster fire (like in Star Wars). The volleys (sputrs) will need to be a bit irregular. Otherwise, they risk to look unnatural. IMO an option (called Regular Emission or something like that) will be a better choice than a permanent tweak - more space for improvisation means better creativity

martin 2017-10-30 16:04:15 UTC #8

Well, we're talking about the interpolation in between frames, so this new behavior just gets rid of the small "arbitrary" randomness within a frame (based on frame rate, particles speed, simulation speed and emission rate). It allows to have a nice steady stream of particles instead of something a bit noisy.
After that if you want to add randomness to the emission you can control the emission rate with a cue (with a noise function).

We could now add a randomness factor on the particles emission rate do do what you are talking about (like for life random, speed random, ect). But that would mean adding two new parameters:
- emission rate variation
- emission rate variation speed
Those two parameters can easily be reproduced by a cue with a noise function, so the questions are:

Is adding those two parameters a significant time gain for the user?
Is adding randomness in the emission rate something that is done often by graphic designers? Is it an option we see often in other software with particles?

What do you think @Skinnytorus, @vincent.armongn ?

vincent 2017-10-30 16:10:42 UTC #9

Hum, I don't think it is prioritary to add thoses for several reasons, first being that we already can do that with a simple function cue over any parameter, then it complexify uselessly the particles emitter (to my point of view) and finally, considering all the features we have yet to implement, I think we can leave this one aside.

vincent 2017-10-30 16:14:22 UTC #10

Moreover you have way more control over the "randomness" of any parameter using a cue than with hardcoded function. As a function cue already have all the needed tools and work the same on any other parts of the soft. So it seems more consistent to me.

skinnytorus 2017-10-30 16:33:07 UTC #11

Guys, I got your point. I know that sMode does many things in its own way and this is great. But my point of view is more based on comparison with other particle systems on the market rather than sMode's peculiarity.

Most new sMode users will be delighted to see familiar parameters seen in other particle systems available in sMode out of the box. The very idea that you can drive emission time by noise comes with time and a bit of sweat. You must admit that understanding sMode's potential takes time and effort. While making a choice the user first looks for familir features and how immediately accessible they are. He doesn't wanna look under the hood. For me adding the above mentioned 2 options (emission rate variation and emission rate variation speed) would be a good point in overall user-friendliness.

I personally accept either way you are suggesting, but since you're moving in the direction of AE, you must be ready that a lot of users will require similar features that are easily accessible. By the way, Houdini team has changed their ways likewise