pflow particle selections

[super gnu]

for a nice change im doing some particle work.

butterflies!


getting some nice results using random walk to give an approximation of fluttery behaviour.

trouble is a) some end up trapped in little "knots" in the noise field, or just look odd.

and b) client requires no butterflies enter the bottom 40 pixels of the screen.


b) i have been trying to solve with inverse gravity with a strong falloff so as they get close to the bottom they are repelled, and also with a deflector.. neither seem to work even remotely reliably.. deflector particularly seems useless letting loads of particles through.. gravity is better but if they come too fast it doesnt have the strength to deflect unless i crank it up, and if i do that, then slow particles get shot upwards too fast.


anyway my backup for b) and only solution for a) was to manually select troublesome particles and simply delete them, using split selected and delete.



infuriatingly though, having set this up, when i start selecting particles, every selection seems to change a random seed somewhere, so all the particles move.. meaning the ones i need to select change..... that way lies madness and no particles.


any advice beyond "dont use pflow" or "you just need to code a custom operator" ?

[super gnu]

i had a brainwave and made a mesher of my system, then put an edit poly on it and deleted the problem elements.. worked fine in the viewport but deletions seem to be ignored when rendering... joy.

[super gnu]

on another note, id also love to figure out a way to smooth off the sudden changes in speed and direction ive got going on. ive got a drag force in there, but it doesnt really do what i want, i dont actually think it affects rotation at all. some kind of inertia operator...

[super gnu]

ok so im getting a pattern here.. think of a good way to solve something, then get another problem as a result.


ive wired my butterfly so that when the particle is moving up, it uses a shape instance of a flapping butterfly

then if the speed drops below +1z goes to another event with an instance of a gliding butterfly.

bit jerky transition but works quite well overall.

apart from.. i have "mapping object" in my global event.. the butterflies pick the colour of the object they are born on. worked fine until now, but once i enable the looping events to control fly/glide, the mapping changes seemingly at random.. since i have no other mapping in the flow ( the shape instances have mapping unticked) why is it jumping the mapping around?

if i turn off the new events, all is fine again.


i have mapping object set to "once" and its in global as i said.


i even tried instancing the same operator to the top of every event... seemed to change the frequency it happened. but didnt resolve the issue.



im guessing there are not a lot of pflow experts here, as my last request didnt exactly burn down the forum...

any good pflow forums i can nag?

[wxyz]

Can you use the built-in Box 3? Anselm has some good training:
http://incendii.com/training/?cat=71

[vance3d]

i think for the deletion to work as you have described it you'd have to make sure the integration step of the particle system was the same in the viewport as it is in the render. by default the viewport is set to full frame where as the render is set to half frame so your particles in the viewport would actually not be representative of what is rendering.

V Miller

[simmsimaging]

ok so im getting a pattern here.. think of a good way to solve something, then get another problem as a result.

If that doesn't summarize the entire career of a CG artist then nothing does.

Not sure if you use Krakatoa, but it comes with a useful collision operator that would help for this - bit it's a pricey fix for just this problem if you don't need it

[joconnell]

If that doesn't summarize the entire career of a CG artist then nothing does.

+1

Back in the max 1 days where there were no forums as such and you'd to try everything to get even basic results, one of the 7 methods that didn't work for one thing became the one method that worked for something else. I miss having time to just play around

[super gnu]

ok im rapidly developing a -real- dislike for pflow.. no matter how i arrange my flows im constantly getting random issues.

*mapping that is set once in the global event changing randomly on only some particles...

*particles randomly disappearing -sometimes random odd ones, then after a couple of unrelated tweaks, whole branches of the flow dissapearing at seemingly random times.

* my latest problem is if i try to re-initialise particle births using the shape texture operator ( which worked fine until now, and nothing related to it has changed as far as im aware) now freezes max at 40%

i took this simple job on and now its taking rather more days than me or my client would expect.

does anyone else have these kinds of issues with pflow? i can find almost nothing online.

[joconnell]

Yep - particle flow is in some ways an utter heap of shit. It's very quick to sketch things out but it's a total resource hog and if you so much as look at it the wrong way, it'll go into an update cycle and kill your machine for a bit. It's not you, it's her

[super gnu]

well that makes me feel a little better.. but unfortunately im still stuck. hopefully there are some pflow gurus on here (do they exist?) who can chip in with hacks and suggestions. what im trying to do is really very simple by particle standards..

i have a character who dissolves into a cloud of butterflies. birth by texture with an animated gradient wipe, with the same gradient masking out the character in post as it dissolves. they use "mapping object" to pick up the colour under where they are born.

the particles are then split by every 2nd particle, with each half going to an identical branch, apart from the wind is in opposite directions so the butterflies fly off both sides of the screen.

i have a random walk to make them bob around, and the only complexish bit, a speed test that splits off any particles moving down, moves them to a "gliding" event, and does a new shape instance, not animated, with "get current shape" ticked. this means when the particles are travelling down, the wing animation stops. after an age test to stop them changing too often, they are tested again to see if they are going up or down. if up, they are looped back into the original event where they are flapping. if not, they start the "gliding" event again.

i doubt its a problem with my setup as the two branches are identical, but i get one half dissapearing at random. all i can say is it seems to be related to the material static operator somehow, and ive also just stopped (for now) the problem by turning the integration step to one frame.. was on 1/8th to try to fix things!

would be working fine, apart from all the stupid issues. resource hogging and update delays are not the problem, its only 300 odd particles. they do have an animated group as the object source, with pointcache on the wings, as they originally had a flex modifier to make them curl as they flap, but again apart from random bugs this is working as expected.

[joconnell]

Yeah it must be something to do with the character wipe on / wipe off thing. Would it be worth after they've left the initial spawn, switching them to a material that has no reference to that gradient wipe thing at all? Like does it all render fine with a dumb material where you're not masking them on?

[YoyoBoy]

Perhaps it would be more manageable if you didn't try to do it all with one system?

[super gnu]

you mean have the left and right clouds in different systems ..or? id have to figure out a way to spawn the particles at non overlapping locations. i guess vertex selections or split 50% of the faces of the emitter.


joconnell: the wipe thing is a "birth by texture" just to control emission.. animated b/w map gradually covering the character from edges to centre.

the material itself is the same as the girl character, mapped onto the emitter. this gives the particles the colour of the pixel under them when they spawn.. its necessary for the project that i have this behaviour if you can suggest another way to achieve this.. i do remeber bobo having a script to do this, but that was before the object mapping operator was available i believe.

i just dont understand why it is so unstable? if i turn off branches that control glide/flap, it seems more stable, but also if i turn off the "material static" it also seemed to work better( a load of missing particles reappeared when i turned it off, then stayed there when i turned it back on again, only to dissapear next render. ) ...im not sure if it worked perfectly with those disables though, ive been flipping operators on and off randomly for days.

to be honest its playing a lot better now, as i said, turning the integration to one frame seems to be working (fingers crossed) im having to do some other bits a longer way around as a result of this, but at least im getting something i can render at the mo..