[Bf-committers] questions about particles and collisions

Ronan Ducluzeau zeauron at gmail.com
Sun Jun 5 20:45:58 CEST 2016


In case of a cascade of emission with such bounces, it could be useful.

But actual particles are not able of that.

2016-06-05 20:43 GMT+02:00 Ronan Ducluzeau <zeauron at gmail.com>:

> 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
>>
>
>


More information about the Bf-committers mailing list