Giters

PixarAnimationStudios / OpenUSD

Universal Scene Description

Home Page:http://www.openusd.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

UsdGeomTetMesh: unexpected imaging behavior with primvars

cameronwhite opened this issue · comments

commented

Description of Issue

Hydra displays UsdGeomTetMesh by showing its surface triangles, but this appears to also pass along any primvars from the tet mesh to the triangle mesh without further validation, which can cause problems with uniform or faceVarying interpolation.
For example, if there is a uniform primvar with a value for each tetrahedron, this may not match the ordering or number of surface triangles.
The attached files demonstrate this with primvars:displayColor, showing the TetMesh side by side with the expected result as a Mesh

Steps to Reproduce

  1. From the attached file (tetmesh_primvars.zip ), open either of the .usda files in usdview. One file has the same number of tets as surface triangles and shows the colors being displayed in an unexpected order, and then other contains a single tet where the colors aren't displayed by Storm due to the primvar having fewer values than the number of surface triangles.

tetmesh_1
tetmesh_2

System Information (OS, Hardware)

Ubuntu 22.04

Package Versions

USD 24.03

commented

Filed as internal issue #USD-9659

commented
commented

Here are my thoughts (coming from my use case of converting UsdGeomTetMesh to Houdini's geometry format and vice versa):

  • I'd expect the primvars to be specified for the tetmesh since that's what the primitive represents, and the list of surface faces is just an optimization. Being able to encode values for interior tets is also valuable, e.g. for custom simulation-related data
  • uniform meaning one value per tet would be sensible, and constant and varying/vertex are straightforward
  • faceVarying could mean one value per vertex per tetrahedron (4 values per tet, matching tetVertexIndices), allowing each tet to have unique values at shared vertices. This also matches how Houdini's (confusingly-named) "vertex" attributes behave for tetrahedrons
commented

I'm inclined to argue that for uniform to be consistent with the "per patch" definition of primvar interpolation should be per tet face (4 values per tet) and for faceVarying to be per point per tet face (12 values per tet).

Potential use case-- consider a user that is trying to specify display colors or uv parameterizations which has two triangles on the same tet visible.

(Long term, it may make sense for primvars interpolation to become primitive specific, as we find ourselves increasingly using primvars for more and more data and more and more geometry types.)

commented

Yeah, for rendering purposes those definitions would match how the surface triangles would be displayed if they were a separate Mesh primitive. If that is important, I would advocate for additional interpolation modes to express per-tet and per-tet-vertex values for data interchange, simulation, etc

FWIW, In Houdini neither of those definitions for uniform and faceVarying can be expressed for tetrahedra. If you needed the ability to do that, using a separate polygon mesh for rendering would be the typical approach (and would reduce the memory overhead from having 12 values per interior tet, unless these were specified only for surface triangles)

I'd be interested to hear what interpolation modes other DCC's can express for tetrahedra?

commented

I buy that because tets are volumetric, they aren't really representing a traditional UV patch and so you have some flexibility with the current definitions.

(Long term, it would be ideal if primvar specifications were more Gprim specific.)