Incorrect motion blur with varying amount of instances

[xsisupport]

Describe the bug
For each instance created by an Instancer LOP, the prototype also shows up in the render.
The attached scene has this setup:

• point instancer with changing point count per frame
• velocity blur (because of changing point count)
• pscale set on points with a marked scale difference from prototypes
• multiple time samples exists (whether with a cache node or when written to usd file)

If you write out a usd file and then load it as a sublayer, it has the same problem.
Note that Karma didn't render the sublayer properly either.

The viewport renders were a bit erratic. As I played around with the scene, the motion blur would disappear sometimes. Then come back. Then the problem would go away and I had to re-load the scene to repro again.

Repro data set

support_case_00031665.zip

Screenshots
If you increase the shutter size, you can clearly see it's the prototype torus that renders:

Sometimes, not always, if you add an Arnold Render Settings LOP and enable Ignore Motion Blur, you also see the prototype torii:

In a new Houdini scene, with the usda loaded as a Sublayer, this is what Karma rendered (in the original scene, the Karma render was ok):

Used Software Versions

• Arnold: Latest
• Houdini

[autodesk-oss-arnold-bot]

Issue synced internally to ARNOLD-15915

[xsisupport]

Motion/velocity blur in general doesn't seem to work. Here's two more scene files.
point_instancer_blur.zip

[marcantoinep]

Hi, I'm the person who reported this bug. Is this being worked on? We won't be able to upgrade htoa version until this is fixed.

[cpichard]

Hi @marcantoinep , we are going to have a look at it during this sprint.

[marcantoinep]

Great, thanks a lot

[cpichard]

Hi @marcantoinep , I had a look today, the problem comes from the SamplePrimvar function, which, as it names says, samples the primvars on a time range. However when the number of instance changes between frames then this function returns an incorrect number of instances, probably the lesser number of the considered frames used for sampling. As the issue is coming from hydra, both Arnold and Karma have the issue. I made a workaround today for hydra, we should have a fix very soon.

[marcantoinep]

Great, I did notice that Karma was also doing weird stuff (streaks) on new points in a frame. Thanks for that!

Now, this changing point count ticket was updated with another issue (much worse) that I flagged on March 17th, which is that since htoa-6.3.7.0, there's simply no motion blur on point instancing, regardless of changing point count, or velocity( ie it's broken with constant point count on time sampled geo). This is the major blocker for us.
Is this also being addressed?

Edit:
If I might add, I was not thrilled that the new issue about no motion blur in point instancer was lumped into this existing ticket. First, even though it's about point instancers, it's not related to two of the terms of the original ticket (changing point count and velocity blur). Secondly, it's a regression bug, that alone should have warranted a standalone ticket. Finally, it makes communication more complicated. End of rant.

[cpichard]

Hi @marcantoinep , I checked the second issue you mentioned, the motion blur is in fact not rendered the first time the image is rendered (or restarted). It looks like the shutter range is not set during the first render, I'll make a ticket and look for a solution.

[marcantoinep]

Great, thanks a lot! (and sorry for the previous rant, it's just that this issue was a bit of a gut punch because we want to benefit from the cool new stuff!)