# Clarification on valid topology for UsdGeomMesh face indices

**URL:** <https://forum.aousd.org/t/clarification-on-valid-topology-for-usdgeommesh-face-indices/2382>\
**Category:** USD\
**Created:** [April 18, 2025, 12:38am UTC](https://forum.aousd.org/t/clarification-on-valid-topology-for-usdgeommesh-face-indices/2382 "2025-04-18T00:38:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![deadpin](https://avatars.discourse-cdn.com/v4/letter/d/43a26b/32.png) [@deadpin](https://forum.aousd.org/u/deadpin)\
**Post date:** [April 18, 2025, 12:38am UTC](https://forum.aousd.org/t/clarification-on-valid-topology-for-usdgeommesh-face-indices/2382/1 "2025-04-18T00:38:07Z")

</div>

Given the following `faceVertexCounts` and `faceVertexIndices` is it really expected that the following shape is valid?

```auto
int[] faceVertexCounts = [4]
int[] faceVertexIndices = [0, 1, 3, 0] # or [0, 1, 3, 1] or [0, 1, 1, 3] etc...

```

If an application has invariants on the index values within a face to not be duplicates, what should that implementation do when encountering such values? The vast majority of assets we’ve seen are “ok” but every so often we encounter a mesh where a few faces, out of many thousands, are like this.

Note: that this is slightly different than a “more valid” situation where there’s an actual duplicate vertex. E.g. if there’s an index “2” who’s vertex position is exactly the same as another vertex’s position. That case is fine.

---

<div class="post-metadata">

**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\
**Post date:** [April 18, 2025, 7:33am UTC](https://forum.aousd.org/t/clarification-on-valid-topology-for-usdgeommesh-face-indices/2382/2 "2025-04-18T07:33:59Z")

</div>

I’d also be curious to know this. We recently hit this when importing an asset into Maya [UsdGeomMesh degenerate triangles discarded · Issue #4194 · Autodesk/maya-usd · GitHub](https://github.com/Autodesk/maya-usd/issues/4194) which I think is the same issue you’re describing.

---

<div class="post-metadata">

**Author:** ![deadpin](https://avatars.discourse-cdn.com/v4/letter/d/43a26b/32.png) [@deadpin](https://forum.aousd.org/u/deadpin)\
**Post date:** [April 19, 2025, 5:45am UTC](https://forum.aousd.org/t/clarification-on-valid-topology-for-usdgeommesh-face-indices/2382/3 "2025-04-19T05:45:14Z")

</div>

Aye, yes, basically the same issue. In our case, we are a bit worse than your bug there. A prototype fix on our side, to prevent the recently discovered asserts, _could_ auto-fix the geometry before loading in the UVs. But that auto-fix will render all downstream indices broken; ergo the normals and UVs won’t be loaded at all since their sizes won’t match. We load positions, faces/edges, normals, and then attributes (which includes the UVs), in that order, and the problem is detected at the face/edge stage.

This is a tough issue. I know that the industry’s mantra is “the show must go on”, “at any cost”, but that might mean defining what happens with such topology. If Maya is going to entertain a fix to that bug, other DCCs might have to as well. That will not come for free in development or runtime costs.

---

<div class="post-metadata">

**Author:** ![dhruvgovil](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/dhruvgovil/32/3_2.png) [@dhruvgovil](https://forum.aousd.org/u/dhruvgovil)\
**Post date:** [April 22, 2025, 1:34pm UTC](https://forum.aousd.org/t/clarification-on-valid-topology-for-usdgeommesh-face-indices/2382/4 "2025-04-22T13:34:02Z")

</div>

I’ve shared this and the other nurbs issue with the geometry working group and will try and get an answer soon.

I don’t think I’d personally advocate for Maya to fix it. Our engineer would prefer to have Maya raise an error to the user since there’s likely a lot of edge cases.