Open cameronwhite opened 3 months ago
Filed as internal issue #USD-9659
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: @.***>
Here are my thoughts (coming from my use case of converting UsdGeomTetMesh to Houdini's geometry format and vice versa):
uniform
meaning one value per tet would be sensible, and constant and varying/vertex are straightforwardfaceVarying
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 tetrahedronsI'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.)
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?
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.)
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 withuniform
orfaceVarying
interpolation. For example, if there is auniform
primvar with a value for each tetrahedron, this may not match the ordering or number of surface triangles. The attached files demonstrate this withprimvars:displayColor
, showing the TetMesh side by side with the expected result as a MeshSteps to Reproduce
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.System Information (OS, Hardware)
Ubuntu 22.04
Package Versions
USD 24.03