Particle Flow Discussion

#5675

Yeah, don’t drag with Drag LOL

http://vimeo.com/14207113 << very nice! working on a setup, woudl be a great vfx wars topic. Sandwomen - No pain, no grain!

And in case you missed the news today: RayFire 1.51 with rebar released and new website

#5676

ParticleFlow Forrest By Height Plane for Evermotion.org :slight_smile:

#5677

Nice tut, interesting technique :slight_smile:

#5678

hey!
while i await my vray render results… i thought i would doodle with pflow scripting, i wanted to create a particle seeking particle system (without using any plugins) i got the idea from the lecture on bobo’s intermediate pflow scripting DVD (amazing dvd, kicking myself for not having bought it before). here is a viewport grab…

and the setup…

also [attached max 2010 file] enjoy :wink:

some things which i realized while working on this… a) you cannot delete particles of a pflow system or read its float,vector and matrix channel from another pflow system, but you can read the position, speed channels … (i tried using $target_pfs.useFloat = true inside the on channelsUsed handler of $source_pfs, but this gives script error) please correct me if i am wrong
b) is it possible to assign particles an avoid behavior (like in a crowd system) in pflow? the particles are assigned a target and also they must avoid certain objects while tracking the target… like in the movie wanted the bullet dodges objects and hits the correct target

i guess these kind of things are easily done with thinking particles?

thanks! :slight_smile:

#5679

Interesting setup :slight_smile: Btw, why do you need 3 separate pflows? You can have 3 births in a single pflow, maybe then you’ll be able to make them communicate easier.

On the seeking-avoidance - it’s just a set of rules, like repulsing forces/velocities when distance to neighbor is too low and so on. Definitely doable with Box3 and TP, and a bit hard with vanilla PF :slight_smile:

#5680

thanks for the post!

if i used only 1 flow then i will have only 1 particle id counter… i used 1 pflow system to generate particle ids for source particles and another to generate particle ids for target particles. This way the source particle with id 1 attacks target particle with id 1 and a source particle with id 45 attacks target particle with id 45 (in one single flow i will not be able to distinguish source and target particles since there is only 1 particle id generator so there is only 1 particle with id 45 or 1) i could have used a spawn test operator iniside the source_pfs to simulate explosion but then after every explosion the particle id’s would be offset by (number of particles spawned) (say the source_pfs generates 5 particles before a collision and per collision 50 particles are spawned then the following particle ids will be generated 1,2,3,4,5,51… when the particle with id 51 is generated (by source_pfs) it has to wait for the target_pfs to generate particle with id 51 but the next particle generated by target_pfs is 6… stoping the flow) so i used seperate flows and i made them communicate with persistent global arrays! hope i made the setup clear :slight_smile:

**ah i just figured the simplest way of creating avoidance behavior is by using Udeflector with 0 bounce along with a findTarget test and a script operator to normalize the speed vector and multiply it by a constant to remove any acceleration!

thanks!

#5681

You gotta get box3 or TP - you can assign whatever velocity vectors you wish, much easier for doing these setups :slight_smile: Btw - using the particle ID like that does seem awkward, are you sure you can’t do it in any better way? There’s groups in box1 - meaning in max 2010+ also, you should be able to do this stuff with them, I think.

#5682

thanks for the post!

There’s groups in box1 - meaning in max 2010+ also, you should be able to do this stuff with them, I think.

hmm… i will give it a shot with the group, selection operators i have to check if particles split into different groups can be accessed via scripting if so then it would be possible to map particles in 1 group as source and particles in another group as target particles… but i am not really optimistic since they were a let down earlier (see post no. 5668 and 5669 of this thread) …

You gotta get box3 or TP - you can assign whatever velocity vectors you wish

yep on top of my list. TP a bit pricy though :frowning: hopefully will have it by xmas :slight_smile: i like the fume fx 2 + TP R4 bundle offer

thanks! :slight_smile:

#5683

box #2 problem - having a Shape issue. Why is the Scale operator not working properly for Event 2? It does not properly fit the sim shape hull to the re-scaled Event 2 shape - in fact, the PhysX Shape op in Event 2 acts strange. I’ve tried moving the ops around and it still won’t fit snug to the scaled cubes.

max 2010 file - thoughts welcome, thanks :smiley:

@ HornBerger - cool, could you save it out as max 2010 perhaps?

EDIT: Not sure why yet, but it works after I added in Event 3 to flow :hmm:

#5684

box #2 problem - having a Shape issue. Why is the Scale operator not working properly for Event 2? It does not properly fit the sim shape hull to the re-scaled Event 2 shape

i tried the setup with event03 like shown in the snapshot… it seems like the physX shape operator can only be assigned once for a particular birth operator of a physX world :S (if you enable the physX shape in event01 the same problem occurs again, i.e the physX shape does not fit the cubes in event02, you could even remove the event03 and connect the collision test output to event 02 then disable the physX shape operator of event01 and place the scale operator above the physX shape operator in event02 and the problem goes away for cubes in event02)

@ HornBerger - cool, could you save it out as max 2010 perhaps?

check the previous post… i reuploaded the file

thanks! :slight_smile:

#5685

@ HornBerger - thanks - your flow is very cool :twisted:

yea - I did notice the PhysX Shape op is causing a lot of these strange things to happen, and this happens often when I scale the shape - appreciate it :scream:

#5686 
 It works in this case because you have not assigned the PhysX shape in the first event, so particles haven't got a collision shape yet.
 
 AFAIK PhysX itself doesn't support changing topology within the simulation, we have wished since beta days for animated shapes within Birth Group and this was the apparent restriction.
 
 With a simple flow like this you can use this technique:
 Be aware that this is not a supported method, most PhysX Test ops will not work using this technique but all PhysX ops work without issue (well ones I have tested anyway, some config may bunk out)

BTW cool setup HornBerger :wink:

#5687

A-ha, man, that must be why this issue happens in using PhysX Shape particles.

  • Thanks Johnny :wise:
#5688

I should clarify, no changing topology in particle shapes, collision objects can have changing topology.

#5689

Did you guys see Tyson Ibele’s fxwars entry?

http://forums.cgsociety.org/showpost.php?p=6644831&postcount=62

holy smoke…roughly 3 weeks in his spare time.

#5690

http://forums.cgsociety.org/showpos…31&postcount=62

wow, work of a true autodesk master indeed!

#5691

Contests should only be open to regular humans :wink:

#5692

Messing around with Box #2. max 2010 file below :slight_smile:

Open file and Bake it out, first using substeps 14, and it looks fine. At frame 80 a wind is keyed to push it over. Switch is off, glue set to rigid and unbreakable. Clear cache and change substeps to 24+, bake again, and watch what happens at end, hehe.

How come more substeps cause the glued grid to jiggle and flex? Friction maybe?

  • Thanks :hmm:

#5693

It’s Spasmatress, the break dancing plane!!!

i lowered the glue solver factor from 1.0 to 0.5 and it was gone :slight_smile: falls like an oak…i think if the rigidity is too stiff it causes internal turmoil in that case. Also try different Anchor Placements, might help.
http://www.orbaz.com/documentation/particleflowtools/box2/animations/PhysXGlueRigid_SolverFactor.html

#5694

@ Ansi & Johnny - great info. Flow had a curious reaction (good idea on anchors) :smiley: