motion blur questions

[rdg]

One reason I often don't use motionblur is:

I really don't under stand how to use it in a predictable way.

segment_solved.tar.gz

The attached file constanly produced segmentation fault when rendering frame 133/1345 with motion blur turned on.

After investigating the issue, I realized I need:

* a trailSOP to compute the velocity

* "geometry velocity blur" ticked in geo1

* geo time samples > 1

which results in the images above.

scaling the velocity doesn't look like an option as this would remove the mblur from the other frames.

mantra warn that geo1 got changing topology - but hey - a particle system often got changing topology, doesn't it?

so my humble question is:

how can I mblur stuff like this?

transformationBlur doesn't work, as nothing is deforming

velocityBlur procuces strange results

and

deformationBlur is not recomended fdor particles - according to the wiki - and I really don't know how to enable it.

Georg

Edited April 19, 2008 by rdg

[3__]

computing the velocity of the template points 1st seems to work.

fault.hipnc

[rdg]

computing the velocity of the template points 1st seems to work.

no - I doesn't or what am I missing?

[rdg]

looks like the answer is:

Don't try to be smarter than you are.

I added sin($F) and cos($F) as normals to my points to make the object rotate.

If I rotate them with a $F in a translateSOP everthing renders as expected - whatever one expects in this case anyway.

.

[crunch]

Don't try to be smarter than you are.

I added sin($F) and cos($F) as normals to my points to make the object rotate.

I can't look at the .hip file right now, but for motion blur (which evaluates geometry at sub-frame intervals), you should probably use $FF (floating point frame number) instead of $F (the integer frame number.

With a shutter time of 0.5, you may or may not get motion blur depending on rounding.

[Jason]

Something to be aware of: The Trail SOP relies on a stable point count in order to calculate velocities - which often makes it unusable with particle systems because particles are dying and being born. For this you'd need a version of the Trail SOP that can calculate velocities based on the unique particle 'id' attribute.

[rdg]

should probably use $FF (floating point frame number)

right. Forgot about it - again.

As using functions to create particle spins can't be that unusual.

For this you'd need a version of the Trail SOP that can calculate velocities based on the unique particle 'id' attribute.

Is this a must-have or a -should-exist?

[symek]

(...) For this you'd need a version of the Trail SOP that can calculate velocities based on the unique particle 'id' attribute.

What apparently can be done in VEX or CHOPs after all, if I'm not wrong...

Edited April 21, 2008 by SYmek

[3__]

no - I doesn't or what am I missing?

sorry I assumed the changing template point count was obvious and there was something changing in the

copied geometry. should check more carefully.

mblur by unique ID sounds great. it should be for all geometry, not just particles.

here's an old and frustrating thread on the matter of unique IDs:

http://www.sidefx.com/index.php?option=com...patial+topology

-cpb