UsdGeomTetMesh: unexpected imaging behavior with primvars

cameronwhite commented 3 months ago

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

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

jesschimein commented 3 months ago

Filed as internal issue #USD-9659

spiffmon commented 3 months ago

Well then… it seems we’ve completely neglected to specify primvar behavior yet for TetMesh. Assuming the primvars are specified for the tetMesh and not the surface, the constant, uniform, varying, and vertex (same as varying, here, since no basis function) interpolations should be “extractable” using the surface indices.

We’ll need to figure out what faceVarying should mean for a tetMesh… any thoughts?

On Thu, May 9, 2024 at 10:15 AM jesschimein @.***> wrote:

Filed as internal issue #USD-9659

— Reply to this email directly, view it on GitHub https://github.com/PixarAnimationStudios/OpenUSD/issues/3082#issuecomment-2103076145, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPOU2GGCLMHIEIDUACNZJLZBOVKRAVCNFSM6AAAAABHPD5UQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTGA3TMMJUGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

cameronwhite commented 3 months ago

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

nvmkuruc commented 3 months ago

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.)

cameronwhite commented 3 months ago

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?

nvmkuruc commented 3 months ago

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.)

PixarAnimationStudios / OpenUSD