hi guys,

I've been trying to find out more about this but haven't found much information. I have a set of points that Are rotating with a torque force applied. I copy a set of grass blades onto the points and packed them using the copy sops option to pack geometry.

However, I can't seem to get rotational motion blur out of my grass blades. Seems that they are only being blurred along v. Does anyone know how to achieve this?

Thanks
Nelson

Have turn on “Use Template Point Attributes” on attribute tab of copy sop?

quinton84
hi guys,

I've been trying to find out more about this but haven't found much information. I have a set of points that Are rotating with a torque force applied. I copy a set of grass blades onto the points and packed them using the copy sops option to pack geometry.

However, I can't seem to get rotational motion blur out of my grass blades. Seems that they are only being blurred along v. Does anyone know how to achieve this?

Thanks
Nelson

Hi, if you increase the motion segments, you'll get much more accurate sub-frame motion blur.

In the attached .hip file

- 2 motion segments: 2.31 GB, 48 seconds
- 4 motion segments: 2.34 GB, 52 seconds
- 9 motion segments: 2.39 GB, 55 seconds

If you disable the packing in the SOP network, the 9 segment render takes 9.4 GB and 30 minutes.

PradeepBarua
Have turn on “Use Template Point Attributes” on attribute tab of copy sop?

Yes. I have “Use Template Point Attributes” turned on.

Hi Mark,

I opened up your scene and noticed that the difference was that I was causing my rotations by using the orient attribute and not rotating it with a transform.

The reason is because I am using a particle system with a torque force to spin my instanced geometry around.

I find that by using a copy sop to instance the geometry onto the particles with packed primitives, rotational motion blur calculation looks wrong. especially for geometry samples >2.

If I used the copy sop on a set of points from a grid that are rotating via a vopsop that applies a sin function to the orient, rotational motion blur seems correct.

Finally if I take the same particles and I used either point instance procedural shader or a instance object, the rotational motion blur looks correct.

All of the images are done with a “geo time sample” of 6 unless otherwise stated. I've also disabled “Geometry Velocity Blur” on the Sampling tab of the objects that are rendered.

I'm not sure what causes the odd rotational motion blur here. Although I could have a quick fix by simply using an instance object instead of a copy sop.

quinton84
Hi Mark,

I opened up your scene and noticed that the difference was that I was causing my rotations by using the orient attribute and not rotating it with a transform.

The reason is because I am using a particle system with a torque force to spin my instanced geometry around.

I find that by using a copy sop to instance the geometry onto the particles with packed primitives, rotational motion blur calculation looks wrong. especially for geometry samples >2.

If I used the copy sop on a set of points from a grid that are rotating via a vopsop that applies a sin function to the orient, rotational motion blur seems correct.

Finally if I take the same particles and I used either point instance procedural shader or a instance object, the rotational motion blur looks correct.

All of the images are done with a “geo time sample” of 6 unless otherwise stated. I've also disabled “Geometry Velocity Blur” on the Sampling tab of the objects that are rendered.

I'm not sure what causes the odd rotational motion blur here. Although I could have a quick fix by simply using an instance object instead of a copy sop.

So, I think the issue has to do with sub-frame evaluation of the geometry.

The way multiple geometry samples works, is that houdini evaluates the SOP at the shutter open and shutter close and saves that to the IFD.

If you turn off integer frames, and look at the geometry at sub-frame intervals, you'll see that because of the particle sampling, there are discrete jumps between the rotations on the packed geometry.

So, if there are 3 segments, houdini will evaluate at frame 90.5, 90.75, 91.0 (depending on the shutter offset).

If you look at the actual sub-frame geometry, you'll see that frame 90.5 and 90.75 evaluate to the same geometry – so mantra will “hold” that geometry and then suddenly switch to the geometry for frame 91.0.

I may have the frame numbers off, but hopefully you get the idea.

The way to fix this is to use a timeblend SOP after OUT_pts. However, there's a hitch – the time blend SOP doesn't blend the orient attribute by default. So, to work around that, you need to put the orient values into the Cd and uv attributes, do the time blend, then pull the attributes out of Cd and uv and put them back in the orient attribute.

You can do this using a Point Wrangle:

@Cd = set(@orient.x, @orient.y, @orient.z);
@uv = set(@orient.w, 0, 0);

Then the timeblend, then another point wrangle

@orient = set(@Cd.r, @Cd.g, @Cd.b, @uv.x);

Followed by an attribute SOP to delete the Cd/uv attributes.

Thanks Mark!
This is exactly as you said.

It did not occur to me that I would not be getting some sort of interpolated subframe data with particles.

And that “hack” of passing orient through cd and uv to get timeblend to interpolate the data is wicked awesome! :wink: