[Bf-committers] questions about particles and collisions

[Ronan Ducluzeau]

When you are using emitter particles, your main interest is particles flow.
You don't really care of particle-to-emitter collision, most of times
emitter is not rendered.

Particles can be ejected from somewhere. Most of times, emitter is out of
sight.
They are raindrops that comes from sky or balls that comes
hole of a bag or sparks from a fire or solar arborescence ...

If your emitter is supposed to be hole or a plasma thing, you don't expect
to see a barrier that allows emission of particles in one direction but
blocks them in the opposite direction.

A simple planar surface is easier to manipulate to indicate emission
direction than adding vertex group or texture to limit emission to a small
part of a complex mesh.
Use case of particles on a complex mesh is often synonym to a
disintegration of that mesh through an explode modifier.
Here is could be useful.
But we have a fracture modifier build that will give better rigid bodies
collisions taking account shapes of fragments.

In 2.4x, particles could be emitted from dying particles.
We could emit raindrops that would die on floor and then provoke emission
of smaller more numerous particles.

2016-06-03 3:05 GMT+02:00 David Jeske <davidj at gmail.com>:

> Lukas, thanks for your response.
>
> At the root of my puzzling is the question... Is an explicit check to
> assure a particle system only collides with a collision modifier on it's
> emitter that appears *before* itself sufficient to allow self collisions?
> It seems like it might be, and I'm wondering if there is any specific
> reason it's not (situations where the collision modifier 'save state' might
> be invalidated during the evaluation of modifiers that come after it on the
> stack).
>
> I could see how manual initial particle collision avoidance control could
> be useful, and it would be pretty easy to add. Is this something artists
> would like to have? Likewise, do you know if artists miss the fact that
> particles don't currently have support for collision groups?
>
> The applicability of the billiard ball example is lost on me, as afaik,
> blender doesn't currently support particle-to-particle collisions.
>
> I should disclaim that I don't have a stance on whether particle-to-emitter
> collisions are good to add or not. Some part of me wants them in so to make
> blender more consistent, but I recognize that isn't always a good reason to
> add the complexity.
>
> For me this is currently a fact-finding mission to better understand
> particle-to-emitter collision issues, because I would like to have
> hair-to-emitter collisions. They are motivated by an actual use case, whose
> value I think is more obvious. However, after experimenting with
> hair-to-emitter collisions, it appears that current interpenetration
> problems with the cloth/hair sim need to be fixed before hair-to-emitter
> collisions would be practically useful.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>