vray motion blur and shape instanced particles.

[super gnu]

as the title says..


i have a butterfly with flapping wings in a pflow.

apart from the nightmare that is rendering pflow with mblur ( prep taking 25x longer than render etc..)

ive noticed i dont get proper moblur on the wings. i can increase the geometry samples but i just get an effect like the old "object motion blur" in max.. a number of overlaid wing shapes with no blend between them.

i could of course turn up the geometry samples to 16 or something... but that would take my already stupid prep time to the moon.

is this a bug or just how it is..?

[Morbid Angel]

did you check your pflow evaluation during render? If you select your pflow node and go to system management, integration step is set to half frame, try lower value and see if it helps.

[vlado]

is this a bug or just how it is..?

I'm afraid that's how it is for the moment.

Another solution could be to use a script to attach actual instances to the particles and animate those, in the end bypassing PFlow altogether. But this will only work if the number of particles is constant for the entire animation...

Best regards,
Vlado

[super gnu]

number of particles is constant, but the animations of the shape instances are set to synchronise with a particular event (when they start moving) and then swap between flapping and non flapping versions based on how they are moving. sounds like a bit of a brain strain to attach instances in this case.

@morbid: ive tried every combination of geometry samples and integration steps possible. it changes the number of subsamples to the wing motion, but does not do a blend between the subsamples as you would expect.

im looking into caching options but i dont know if a) they would do moblur any better and b) wether they would take just as long to calculate as the render prep time im struggling with.

[Morbid Angel]

Hmm, this could be why the motion blur is weird. So you are swapping between two different geometries?

[super gnu]

its the same geometry just in a different shape instance operator, with "get current shape" ticked and "animated" unticked, so it freezes at the current frame of animation until its looped back to the animated one.. however this isnt the issue, i get the same with a single shape instance.

[Morbid Angel]

I did a quick test, I guess its some sort of limitation as vlado mentioned.

[super gnu]

to be honest right now its the least of my worries.. i can crank up the substeps and geometry samples until it renders pretty smooth.. does mean my rendertimes go from 1 minute to closer 15 a frame (for 300 particles)

-almost everything im touching in pflow either doesnt work ( often intermittently) or breaks something else. im beginning to doubt my sanity. i dont do particle work often, but im sure in the past i didnt have such a ludicrous amount of issues with it..

[joconnell]

What I'd be tempted to do, for speed reasons as much as anything is have slightly less variation in your particle flow automatic group switching and then make long sequences of flapping to gliding and back to flapping that you can point cache. Make a new pflow system that has your take off into flap and glide but make the system pretty rigidly follow the timings when you're transitioning between glide and flap. Bake out the particles to animated nulls and then parent on an instance of the point cached butterfly. You'll have to do maybe 5 variations of animation timings and thus 5 particle flow systems to do the movement, but you'll have the movement you want, the visual complexity you want and far faster render times without pflow's bullshit.

[super gnu]

lol sounds good.. ill keep it for future reference.. my deadline is tomorrow morning. i spent 5 days of budget on a 15 second clip, and im still not particularly happy with it. hope client is less critical than me.

i did also try animating the butterfly doing a fairly random flap/glide, with associated gain and loss of altitude, then linking that to the flow.. possibly my mistake was to keep the strong random direction changes in pflow, meaning at times the butterflies were obviously gliding up and flapping down.

i could have linked the butterfly to a node with random (but believable) movement on it then given the target particles a much smoother path. having said that i can see a load of issues with that approach too. i really did think doing it this way in pflow was the best way, and had it actually done what it should, id have finished days ago.

[joconnell]

Sure. Things like Xmesh and Krakatoa can help with a lot of this thing, pflow finished development in 2005 with oleg developing various upgrades and trying to integrate them via a back door with the releases of box #1,#2 and #3, but the main engine itself hasn't been touched in ages. It's nowhere near perfect.

[super gnu]

man. sometimes id just love put my pointiest shoes on and give the whole of autodesk a massive kick up the arse.