Packed RBD motion blur clarification Tweet

[renderingz]

Hi, could we get some clarification on how motion blur on packed RBD sims is being handled?

It only seems to work when deformation blur is checked on the Octane ROP, but it looks like this is actually calculating the deformation motion blur based on the unpacked full resolution geometry's points rather than treating it as a bunch of individual objects transforms?

It's incredibly inefficient, and increases render times by 10x. Redshift doesn't do this, it uses transformation blur for both object level transforms and packed-sop level transforms.

I have v attributes, I've even tried instancing the RBD rest geometry on to points as a workaround and ticking "instancing MB computed from velocity attribute" in the Octane Object Parms but this does nothing.

In it's current form, motion blur is basically unusable on RBD sims. Really needs to be sorted out.

[renderingz]

Could we get some info on this?

I have a 5m poly packed RBD sim, and with deformation blur it shoots the render times from 2min to 40mins on 2x4090s when movement is quick. I can't finish the project with times like this.

There must be a way to make this work using regular object motion blur or translation motion blur, like Redshift does?

[juanjgon]

Can you please share an example scene with your workflow? I'm not sure to understand what the problem could be. The packed geo is expanded to regular geometry and the motion blur is computed from the mesh deformations.

Thanks,
-Juanjo

[renderingz]

Can you please share an example scene with your workflow? I'm not sure to understand what the problem could be. The packed geo is expanded to regular geometry and the motion blur is computed from the mesh deformations.

Thanks,
-Juanjo

Hi Juanjo - what you describe here is the problem. Packed RBDs should be treated like a bunch individual objects not deforming meshes. As the redshift plugin dev, I'm sure you're familiar with how they do it - object motion blur is used for packed transforms as well as object transforms. This is a much quicker and more efficient method. The current octane implementation is literally unworkable, the increase in extraction and render time caused by this inefficient motion blur method renders it useless.

[juanjgon]

As far as I know, the Redshift plugin does the same, so this is why I'm asking for a repro scene to try to find the problem on the Octane side.

Thanks,
-Juanjo

[juanjgon]

Yep, I'm not sure what's going on with your scene. I've been testing a simple rbd fracture scene here that includes packed fragments and both the scene extraction time and rendering times are the same in Octane and Redshift. In fact, Octane is a bit faster.

I'm going to need your scene to try to find the problem.

Thanks,
-Juanjo

[renderingz]

Thanks for investigating; I'll send you a scene in the next day or so.

One thing to note - packed RBD motion blur in Redshift works without using deformation blur. It works using only "transformation" blur which is the same technique used for OBJ level transforms. I bet if you tried the same test but with a very high poly RBD sim, your results would be closer to mine. It doesn't take a lot of resources to compute deformation blur on an object that's around 1000 polygons. Deformation blur is also boosted by RTX in Octane so that would also account why in this simple test Octane would perform better.