animated deflector geometry in pflow.. help?

[super gnu]

ok vfx guys.. hm..


im trying to do a very simple ( i thought) effect in pflow where a mesh triggers particle spawning when it collides with another mesh. basically for simple dust puffs.



Unfortunately from what i can see, the moment a mesh is animated, it is ignored by all the deflectors in 3dsmax.

this sucks bigtime. any of you vfx heads have a neat trick that doesnt involve getting thinkingparticles? rather overkill methinks!

p.s. i did try the mparticles collision node, but it just didnt do anything.

i also tried my old favourite distancetex, and using it to drive a "birth texture" node, but the results were weird and didnt match the texture.

i read somewhere that krakatoa has its own collision node for pflow.. will this work with animated meshes?


edit: i got something working by flipping the whole idea round, and using lock/bond to attach seed particles to the animated mesh, and getting those to spawn when they hit the static scene geometry.. -however, im still in a similar position, as i need the spawned particles to "puff out" away from the impact. at the moment, they just expand into the animated object, and trail out behind it.

i cant avoid this unless i use the animated object as a deflector.

i tried using "speed by surface" but none of the options there give anything like the right motion.




just in case anyone has a quick fix, im attaching my test scene. obviously in this simple example i could animate a few "speed by icon" or similar to push the particles in the right direction manually, but the final scene will be much more complex, and im trying to avoid placing hundreds of manual deflectors etc around the scene.

dust generator.zip

[super gnu]

ok managed to get something working ok, had to play with the collision spawn speed settings.. managed to get someting going in approximately the right direction that i can work with.

[super gnu]

i cant -believe- there is no way to get animated geometry to work as a deflector in particle flow. its embarrassingly poor.

i read oleg's comments on the pflow forum, and he described the max geometry deflectors as "legacy" features that would not be updated to work properly.. how can they be legacy features if there is no replacement? they are the only deflectors that pflow has....

[Joelaff]

See below.

[Joelaff]

I looked at your scene, and I still can't figure out what you are trying to do.
Try a uDeflector. Add some thickness (shell) to your roll. Also, make it so the roll does not overlap itself or some collisions will fail. The roll should have a little thickness and move lit a real carpet rolling up, where it does not overlap itself.

Also you can try lower the integration step in the PF Source settings (for viewport and render).

[super gnu]

hm.. i tried udeflector.. i also tried uomniflect.. in fact by now ive tried pretty much everything. both of them fail to produce an collisions the moment you animate the mesh of an object. from what ive read on the orbaz website, this is a known issue, and the mesh deflectors simply dont work with deforming geometry.

the final geometry will not have intersecting faces.. that was a simplified file i did quick to send out.. all my testing here since has been with non-intersecting stuff.




do you mean to tell me you have deforming geometry working as a deflector in pflow? really? id love to see an example.


here is a scene set up as you describe.. - no collisions for me, and ive got the integration step at 1/8th frame.


udeflector.zip



keyframed objects (position, rotation, possibly scale) are fine. its when the mesh itself is animated as in this example.



basically i wish the unrolling carpet (well its actually a road) to generate a "bow wave" of dust from the floor, as it unrolls. simple i thought.

i wish to spawn a load of particles when the carpet hits the particles scattered on the floor geometry, and have them repelled by the carpet so they fly away from it. obviously beyond that there is playing with gravity, splitting particles off to be dust or heavier chunks etc etc. but thats the basic setup.

i now have a few options for generating the "hit" particles in the right place ( group operator set to "inside volume" , birth texture operator and distance tex, spawn particles on carpet, hold them there with lock/bond, and have the ground as a static deflector) but all of them have issues, and none of them can provide the correct motion vector for the spawned particles.

ive got various things that half work now, but i have some major limitations that are causing me nothing but headaches.

1: the "carpets" scale up from 0 at the beginning, whilst also being animated unrolling linked to a dummy. i thought of linking a normal deflector to the dummy and using that, but due to the scaling, the dummy does not stay in alignment with the leading edge of the carpet.

2: the setup has to be very automatic, as there are a crapload of "carpets" animating at different times, angles and speeds.. im certainly not wanting to hand keyframe standard deflectors to match the front surface of each.

3: the "bow wave" has to move -away- from the front of the carpet. without the carpet as a proper deflector, this is quite problematic to achieve.

[Joelaff]

Here is a simple scene with a deformed (Bend modifier) object colliding with particles.

Does that help?

PFlowBend.zip

[Joelaff]

2: the setup has to be very automatic, as there are a crapload of "carpets" animating at different times, angles and speeds.. im certainly not wanting to hand keyframe standard deflectors to match the front surface of each.

What if you attached a deflector of some sort to the gizmo of the bend that you use to animate the bend? Just thinking out loud. Probably get the fastest results just animating an emitter throwing particles out from the leading edge... ??

[super gnu]

yeah that would be the best option but as i mentioned, :

1: the "carpets" scale up from 0 at the beginning, whilst also being animated unrolling linked to a dummy. i thought of linking a normal deflector to the dummy and using that, but due to the scaling, the dummy does not stay in alignment with the leading edge of the carpet.

[super gnu]

Here is a simple scene with a deformed (Bend modifier) object colliding with particles.

Does that help?

[ATTACH]28115[/ATTACH]

well.. kinda, - it works as a collision object , but only when its not animating. if you adjust your keyframes so the object is animating during the time the particles are hitting it, they do not trigger collisions. easier to see this if you change the display type of the particles after collision.PFlowBend_modified.zip

[Joelaff]

Not at a workstation right now, but what if you use an xform modifier for the animation?

Or maybe you could rig up a null which is itself in world space (no parent) using something like ExposeTM ?

[super gnu]

i do have a solution on this theme. scaling of carpet is done by xform, so if i create an "emitter" with the same axis point, instance the xform to it, then select the faces, move them to the correct position, and use "linked xform" to link only the faces to the dummy object, it stays in the right place realtive to the carpet leading edge.. however i then need to hand keyframe the emitter on and off (i drop it down into a box that kills the particles) at the start and end of each carpet unroll.

i also need to hand keyframe it to compensate for curves in the road (im just going to call it a road from now on.. they are roads. i dunno why i got stuck on carpets.) and hand keyframe it for changes in road width.

i have about 200 roads to do , so im not very happy -at all- with this solution.


i dont quite understand your second suggestion though? a null in world space using expose TM? could you provide more detail?


ive also realised why "speed by surface" etc are not working properly.. since the road scales up until about 25% unrolled, then continues to unroll at 100% scale for the remaining 75% time, the particle motion is very inconsistent.

it makes sense because when the road is scaling up, the faces are sliding along. once the scale stops, they are only translated by the unrolling effect.. so the direction of movement inherited by the particles changes drastically as soon as the scaling of the road stops. -its actually usable (particles fire forwards from road) while the road is scaling up, but as soon as it stops scaling, the particles go straight up or down. )


i actually have several working methods to generate the particles along the leading edge of the unrolling road, the issue really is the movement direction of the particles.

argh i think my painful method is the only one to use .

if i was a scripter i could probably at least script the creation and initial placement of each emitter, before hand adjusting keyframing.. would save 5 mins per road i guess..

[super gnu]

the absolute ideal would be if i could persuade particles to move on a surface, in the direction of a b/w gradient. (i.e. from black to white)

that way, i could emit them via whatever method, then use a distancetex to force the particles to radiate out from the road. dont suppose youve ever heard of a way to do this?

i did have one idea, which was to use vraybump2normal to convert the distancetex into a normal map, and use that to drive a "speed by surface" set to xyz from rgb (or whatever its called)

needless to say it just didnt really do anything like i was hoping.

[Joelaff]

Here is a version of your modified version of my test with mParticles that seems to do what you want. I used the pFlow Collision WSM. I had to increase substeps in the mPWorld.

I am still not sure I totally get what you want to do. But if the idea is leading edge dust then I think I would try to see how I could animate an emitter object to follow the leading edge.

Or is the idea dust coming off the entire carpet (road) ? Could you use the road itself (or a lower poly version) as an emitter and just texturemap it with an animated greyscale texturemap to get the emission where and when you want it?

[super gnu]

yeah its leading edge dust and small rubble, like its causing some damage to the underlying ground as it unrolls. a small bow-wave of larger chunks, and a cloud of dust raised and dispersing quickly with the wind. all the bits are in place, only issue i have is persuading the particles to fly away from the leading edge in a nice way that works for every road i add to the sim, without loads of manual work.

anyway ive got my longwinded process down to a few minutes per section of the road. ill probably go with that. ive already spent 4 very long days on trying to do something i thought would be a quick extra i could easily add. (client is expecting it now :P)

- could probably have manually keyframed all the road sections by now. doh.


i already tried with mparticles (ive literally tried about 20 different approaches).. the pflow collision object doesnt play well -at all- with objects that change size. the collision primitives it places at each face are of a fixed size, so if you generate them at the start of the sequence, they are tiny and dont collide with anything once the faces expand, or, if you generate them after the scale-up, they are too big at the start..

also, once i finally got some actual collisions going, it was *so* damn slow, immediately discounted it for a scene with millions of particles. ill check your file, maybe i missed something!


- i actually wrote to Oleg at Orbaz, and to my surprise, he replied. i asked about wether it was possible to get particles to accelerate from dark areas on a map towards lighter areas, across a surface. with that i could use distance tex to define the particle birth zone, and the initial direction of movement, fully automatic.

he replied that it would indeed be possible with box3, and sent me a couple of examples of maps controlling particle movement. unfortunately for me, the box 3 data flows look like heiroglyphics. so i would not have a clue how to modify them for my purpose.