particle deflector permeability

[Bobo]

Is there a deflector or something that allows x% of particles to go through, while the rest get deflected? I'm fairly new to Max Particles, with more experience in Blender's Particles - where the basic deflector gives me a permeability setting.

Ideas?

Yes, look at the DynaFlect and OmniFlect Deflectors.
The DynaFlect ones let you specify a percentage of particles to collide and bounce off, leaving the rest pass through.
The OmniFlect ones let you specify a percentage of particles to collide and reflect, and a percentage of particles to Refract (thus both passing through and changing direction in the process).
They come in Planar (P), Spherical (S) and Universal (U) flavours (Universal using geometry object).

Also, shameless plug ahead, the commercial version of the Krakatoa particle rendering and management plugin comes with a Collision operator (http://software.primefocusworld.com/software/support/krakatoa/krakatoa_collision_test.php) that is several orders of magnitude faster and also has the ability to pass through a percentage of particles. For heavy scenes (millions of particles colliding with millions of polygons) it is the way to go. But this is just FYI, I don't expect anyone to spend money on that ;)

[antimatter289]

Thanks Bobo
not sure why I didn't try those ones :banghead:

[OlegB]

Bobo,

The "Animated Geometry" option is not clear to me from the docs. Is it only in regards to the transform matrix of the reference geometry mode? Is it possible to have animated surface of the geometry?

Thanks,
Oleg B.

[Bobo]

Bobo,

The "Animated Geometry" option is not clear to me from the docs. Is it only in regards to the transform matrix of the reference geometry mode? Is it possible to have animated surface of the geometry?

Thanks,
Oleg B.

Hi Oleg,

I will try to rewrite that part of the doc.

In short, it is the same as the Animated Shape checkboxes in all your PFlow operators.
PRS animation is always taken into account, the checkbox handles animated vertices by rebuilding the kdtree on each interpolation step (which makes it slower, of course).

The note in the doc means that if you have a static mesh, the validity interval will be respected and the kdtree will NOT be rebuilt even if Animated Geometry is checked, so it will still be as fast, with or without the checkbox checked.

The checkbox is meant to be unchecked if the mesh IS animated but you would prefer to ignore that and use the frame 0 state of the mesh on all frames (for example for fast previews etc.)

[OlegB]

Do you have any collision leakage with no PRS animation and a heavy surface animation?

Thanks,
Oleg B.

[Bobo]

Do you have any collision leakage with no PRS animation and a heavy surface animation?

Thanks,
Oleg B.

I am quite sure we have some, but there is also the option to perform multiple collisions per step which usually solves most of the leaking. Basically it builds the kdtree, calculates a collision and then continues to collide using the resulting changed velocity, allowing for a kind of sub-step handling without increasing the integration step. But this handles mostly very concave surfaces (like a plane with a very strong noise) where particles could get caught in a wrinkle. I will have to test a bit more how it reacts to very quickly changing meshes - I actually expect it to leak some...

[OlegB]

Thanks for clarification, Bobo.

Oleg B.

[Bobo]

Thanks for clarification, Bobo.

Oleg B.

Ok, so I tested it today.
I created a 100x100 segments plane and added a Noise modifier with Fractal on, Z Strength of 100.0 and checked Animate leaving the default settings.
Then I created a standard PFlow streaming down 20K particles onto the plane and used the Krakatoa Collision.

With default settings, it leaked about 30% of the particles.
When I increased the Max.Number of Collisions, it leaked a bit less, but that did not solve the problem.
But changing the Collision Offset to 1.0 (thus performing the collision a frame in advance where the particles is still a bit away from the surface) fixed the problem completely. It does not look too off as it is difficult to tell when a particle will really hit. I tried using lower Offset values and it started leaking at around 0.6.

So I changed the integration step to 1/2 frame and using an Offset of 0.5 produced a clean result too. So it looks like setting the offset to about the Integration step value is the way to go in our case.

I know this is sort of cheating it, but it works ;)

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.