Efficient handling of Face-Varying Data

[manuelk]

Starting a thread to gather conclusions about OSD's (mis)handling of face-varying data:

Question: ask if there's a way to have UV information packed into the buffer object as well.

UV coordinates can come in 2 flavors: varying (one coordinate per vertex) or face-varying (one coordinate per vertex per face).

• Varying UVs: one coordinate value per vertex but cannot represent seams in the layout, which severely limits the topology (ex: ground planes)
• Face-varying (fvar) UVs: accounts for boundaries (seams) in the UV layout, but forces the duplication of the UV data instead (one coordinate per vertex per face). Additional considerations: fvar data has 4 modes of boundary interpolation (bilinear and 3 variations of bicubic interpolation). Currently OSD's implementation is limited to the bilinear mode.

---

Problem 1: currently OSD passes interpolated fvar data to its subdivided quads (uniform) or patches (adaptive). This data is not only very large (follows the subdivision growth pattern) but it is also highly redundant : if we do not support smooth interpolation, then only the coordinates at the corner of the parent coarse face are needed. In that case, the per-face bitfield data from FarPatchParam is sufficient to interpolate fvar data correctly from within the shaders.

Solution 0: provide a way to pass the fvar data directly to the FarMeshFactory and create a set of access macros in the PatchCommon shader section to interpolate the data for the client code.

---

Problem 2: fvar data is large (8 floats / face) and highly redundant. Most game engines work around this by cutting-up the mesh topology and duplicating edges & vertices along fvar data seams. While this works for polygonal geometry, it breaks the limit surface continuity of subdivided geometry.

Solution 1: cut-up the mesh, but extend the duplication along seams to the 1-ring faces, and tag those as holes.

Solution 2: launch an optional additional compute kernel pass that would unroll vertices along face-varying seams so that the resulting vertex buffer object could support simplified drawing of face-varying data. The advantage of this strategy is that it does not incur the vertex data interpolation cost for the duplicated 1-ring and is transparent to the original topology.

---

We should definitely implement solution (0) ASAP as a way of limiting the damage when applying UVs to uniform subdivisions. In the long run, having a code-path for solution (2) seems like a worthwhile further optimization.

Thanks to Aras, David, Julian & Takahito for their input on this.

[jcowles]

To give an update here, these are being addressed as part of the 3.0 and 3.1 releases.

[jtran56]

Filed as internal issue #151681.

[barfowl]

As Jeremy noted, these were addressed as part of the 3.0 and 3.1 releases. Considerable documentation on the handling of face-varying data was provided in the 3.0 release notes.