Usdskel causes polygons to render faceted - without normals

Community USD
1

We’re experiencing an issue in rendering Crowds with usdskel, whereby all the geometry that is saved as polygons is dropping the normals information at rendertime - and appearing as faceted. We lose the nice smooth normals, exported from our assets.

Our only workaround, has been to force the meshes to render with subdivision, which appears smooth but increases the amount of geometry - making it hard to scale up a crowd.

Our pipeline currently uses Houdini and Renderman, and according to Pixar - who confirmed this issue - the USD is culling the normal attributes somehow.
Has anyone else seen this, and found a solution?

2

Sharing an example asset. (see attached)
And these explicit instructions, from a colleague:

Repro steps

  • Sublayer this usd file: skelroot_example_v002.usda
  • Render through the included camera
  • The mesh renders facetted
  • Prune the Skeleton prim /character/skeleton
  • The mesh renders smooth (you may have to restart the render)

Tested in Solaris with Houdini 19.5.959, Renderman 25.3_2333134, Karma.

Karma

Karma auto-smoothes meshes without normals. You may need to set Cusp Angle to 0 via a Render Geometry Settings to see the facetting. This is equivalent to Renderman’s Smooth Polygon property and doesn’t solve the problem of losing the normals authored on the model.

Minimal Setup

The bug only happens with a working SkelRoot asset, meaning at the minimum you need:

  • A Skeleton prim
  • A SkelRoot prim with a skel:skeleton relationship pointing to the Skeleton prim
  • A mesh with skel:jointIndices and skel:jointWeights primvars

Removing any one of these 3 things fixes the normals.

skelroot_example_v002.usda (61.1 KB)

3

Just a guess by looking at the file quickly, but have you tried using face normals instead of vertex normals? Currently it looks like it has the same count as the number of vertices, while looking at other polygonal meshes it seems to be using the face count instead so maybe that is throwing it off somehow?

4

Actually scratch that, seems to be the same for the UsdSkel sample from Pixar too, no matter what normals I put in.

5

I think this is likely because the Hydra skinning computation (both CPU, and Storm’s GPU computation) doesn’t handle deforming normals, and so they’re forced to be recomputed post-skinning

6

Just to followup from offline discussions about this… @cameronwhite is correct; this is a known limitation, and handling authored normals efficiently in UsdSkel computations is a potential concern… we’re working with the RenderMan team to prioritize this work.

1 Like