Particle Velocity Blur

[kodiak]

Hi od[force]rs,

I'm working on an effect that involves particles rendered with velocity blur in prman (but mantra makes no difference) where I get excessive blur because of the camera animation relative to the particles.

I was asked by compositing to reduce the amount of camera blur or kill it completely (to be added in comp), still keeping the velocity blur of the particles themselves.

Now what I did (and actually I did this on a previous show where it was working out quite well for those shots) is get the camera in the fx OTL, calculate its velocity vector (transform only for now) and substract that from my particle velocities with some weighting. I get the right amount of blurs, but sometimes the particle velocity directions get completely screwed up, although there isn't an obvious change in the camera translation path.

I would have two questions:

- is there any other way to approach this (ie. kill camera blur but keep velocities). I'm thinking about creating a new camera at each frame on the fly and use that to render the particles. But this makes it quite difficult to have an adjustable contribution. Another approach would be to reduce the shutter angle considerably and upscale the velocity vectors, but I also need matte objects to blur properly, so that's a no go.

- anything else to keep in mind when calculating the velocity vectors? For now, I'm only calculating the transform of the camera (as there isn't much visible pan in those shots), how would you go with doing the same for rotation as well?

Any thoughts appreciated.

Thanks,

Andras

[MADjestic]

Hey, obviously you've been thinking about that already, but what about rendering separate passes for your particles and the rest, using different camera setups?

[HyFrmn]

Maybe I am over simplifying the problem, but couldn't you scale the velocity with point a sop ($VX * 0.1 as an expression for velocity)?

~Marshall

[doc]

Now what I did (and actually I did this on a previous show where it was working out quite well for those shots) is get the camera in the fx OTL, calculate its velocity vector (transform only for now) and substract that from my particle velocities with some weighting. I

the problem may be that you aren't factoring the blur that results from the rotation of the camera. This can be significant, objects that

are further away will blur more because they have "moved" farther in camera space.

There's a vex function(can't remember what it''s called off the top of my head) that allows you too retrieve an objects transformation matrix (this contains trans, rot, scale info)

with an optional argument to get retrieve it at a particular frame. If you get the matrix at $F and $F+1 then you should be able to calculate the positions

of the points(relative to the camera) at $F(camP) and $F+1(camPnext). Getting the velocity from here should be easy CamV=(camPnext-camP)*$FPS.

Subtract camV from v and you should be good to go.

Hope that helps

L

Edited March 1, 2008 by doc

[kodiak]

Hi doc,

Thanks for the suggestion. Sorry for not updating this thread as I was progressing through this but it was a lot more active on another mailing list and went through couple of variations with this. Unfortunately I didn't come to a 100% reliable solution just yet.

There are two approaches that could be taken from what I can see.

- Camera space change: like the one you're suggesting, can be achieved various ways, through object merges, through vops, through vex..etc. I tried some of these and they seem to be consistent, still they don't seem to produce the right results (I admit in some of the more complex cases there might have been implementation problems as well). You would expect these to work, however I have a gut feeling that without introducing a projection model to the whole thing, it's not going to cut it (changing focal length on some of the shots).

- Projection techniques: I tried toNDC-ing the vectors..etc, but these didn't give me proper solution either.

At the end I managed to fix it to an extent that it can be comped, but I don't have a 100% working reliable solution. I'm not even quite sure its possible, to be honest. This would suppose that the calculated camera blur and the real camera blur are calculated exactly the same way, and chances are they're not. So it's difficult to even just setup a proper testing scene for this.

Someone could prove me wrong, I would be glad

[old school]

Download the FX tools and place the rain in your scene. In there is one method to grab and manipulate the camera transforms. The various nodes are heavily commented. There is an option to blend in and out the camera's transforms so you can exaggerate the camera's motion if you wish.

[kodiak]

Download the FX tools and place the rain in your scene. In there is one method to grab and manipulate the camera transforms. The various nodes are heavily commented. There is an option to blend in and out the camera's transforms so you can exaggerate the camera's motion if you wish.

Hi Jeff,

Thanks for sharing, it might be helpful for people trying to understand the problem. Unfortunately it doesn't help my case (or in fact the general case). If you read my original post, I already had translation only blur compensation worked out a the start (as it's really straightforward to do), but it's less than satisfying with any kind of more complex camera animation. Besides, the method in the Rain asset is using a quite limited approach considering the various places the camera animation can come from (think parenting for example).

So (even though it doesn't seem too urgent now), I'm still looking for a more plausible solution (or at least theory).

Thanks,

Andras