Subdivision Schemes and Options in Sdc

The creation of a new TopologyRefiner requires specification of a subdivision scheme and a set of options that are applicable to all schemes. With HbrMesh, the scheme was specified by declaring a static instance of a specific subclass of a subdivision object, and the options were specified with a number of methods on the different classes.

Such general information about the schemes has now been encapsulated in the Sdc layer for use throughout OpenSubdiv. The subdivision scheme is now a simple enumerated type (Sdc::SchemeType) and the entire set of options that can be applied to a scheme is encapsulated in a single simple struct of flags and enumerated types (Sdc::Options).

Specifying Face Varying Topology and Options

Both the way in which face varying data is associated with a mesh and the options used to control its interpolation have changed. The documentation on Compatibility with OpenSubdiv 2.x details the equivalence of interpolation options between Hbr and the new Sdc::Options::FVarLinearInterpolation enum, while the section on Face Varying Interpolation illustrates their effects.

Face varying data is now specified by index rather than by value, or as often stated, it is specified topologically. Just as vertices for faces are specified by indices into a potential buffer of positions, face varying values are specified by indices into a potential buffer of values. Both vertices and face varying values (frequently referred to as FVarValues in the API) are assigned and associated with the corners of all faces.

In many cases this will simplify representation as many common geometry container formats such as Obj or Alembic specify texture coordinates the same way. For other cases, where a value per face-corner is provided with no indication of which values incident each vertex should be considered shared, it will be necessary to determine shared indices for values at each vertex if any non-linear interpolation is desired.

Ordering of Refined Vertices

The FarMesh was previously responsible for refining an HbrMesh -- generating new vertices and faces in successive levels of refinement in the FarSubdivisionTables. Vertices were grouped and reordered from the native ordering of HbrMesh so that vertices requiring similar processing were consecutive. Such grouping alleviated most of the idiosyncrasies of HbrMesh's native ordering but not all.

Far::ToplogyRefiner is inherently a collection of refinement levels, and within each refined level (so excluding the base level), all components are still grouped for the same reasons. There are two issues here though:

• the ordering of these groups has changed (though an option exists to preserve it)
• the ordering of components within these groups is not guaranteed to have been preserved

Vertices in a refined level are grouped according to the type of component in the parent level from which they originated, i.e. some vertices originate from the center of a face (face-vertices), some from an edge (edge-vertices) and some from a vertex (vertex-vertices). (Note that there is a conflict in terminology here -- face-vertices and edge-vertices most often refer to vertices incident a face or edge -- but for the sake of this discussion, we use them to refer to the component from which a child vertex originates.)

The following table shows the ordering of these groups in 2.x and the two choices available in 3.0. The option is the orderVerticesFromFacesFirst flag that can be set in the Option structs passed to the uniform and adaptive refinement methods of TopologyRefiner:

The decision to change the default ordering was based on common feedback; the rationale was to allow a trivial mapping from vertices in the cage to their descendants at all refinement levels. While the grouping is fundamental to the refinement process, the ordering of the groups is internally flexible, and the full set of possible orderings can be made publicly available in future if there is demand for such flexibility.

The ordering of vertices within these groups was never clearly defined given the way that HbrMesh applied its refinement. For example, for the face-vertices in a level, it was never clear which face-vertices would be first as it depended on the order in which HbrMesh traversed the parent faces and generated them. Given one face, HbrMesh would often visit neighboring faces first before moving to the next intended face.

The ordering with Far::TopologyRefiner is much clearer and predictable. Using the face-vertices as an example, the order of the face-vertices in level N+1 is identical to the order of the parent faces in level N from which they originated. So if we have face-vertices V'i, V'j and V'k at some level, originating from faces Fi, Fj and Fk in the previous level, they will be ordered in increasing order of i, j and k. For uniform refinement the ordering of face vertices V'i will therefore exactly match the ordering of the parent faces Fi. For adaptive or otherwise sparse refinement, the subset of Vi will be ordered similarly, just with components missing from those not refined.

The same is true of all vertices, i.e. edge-vertices and vertex-vertices, and also for other components in refined levels, i.e. the child faces and edges.

For child faces and edges, more than one will originate from the same parent face or edge. In addition to the overall ordering based on the parent faces or edges, another ordering is imposed on multiple children originating from the same face or edge. They will be ordered based on the corner or end-vertex with which they are associated.

In the case of refined faces, another way to view the ordering is to consider the way that faces are originally defined -- by specifying the set of vertices for the corners of each face, often aggregated into a single large array. The ordering of the set of refined faces for each level will correspond directly to such an array of vertices per face in the previous level.

Controller Objects

The API-specific ComputeController has been replaced with the Evaluator. It reflects the fact that stencil compute batches are significantly simpler than subdivision table compute batches.

The name "Evaluator" was chosen with the hope that is more meaningful than the generic "ComputeController" moniker: the Evaluator evaluates stencil and patch tables.

In the 2.x code base, subdiv level buffers were always required to be allocated contiguously, however in 3.0 with the shift to stencil tables, this strict allocation scheme is no longer required. As a result, the EvalStencils() and EvalPatches() methods now accept both a source and a destination descriptor.

Also note that OsdVertexDescriptor has been renamed, however it's data members and semantic purpose remains the same:

ComputeContext, DrawContext

ComputeContext and DrawContext have been replaced with API-specific StencilTable and PatchTable objects, for example Osd::GLStencilTableSSBO.

EvalLimitContext

The data stored in EvalLimitContext has been merged into the Evaluator class as well.

EvalCoords have been moved into their own type, Osd::PatchCoords. The primary change here is that the PTex face ID is no longer part of the data structure, rather the client can use a Far::PatchMap to convert from PTex face ID to a Far::PatchTable::PatchHandle.

OsdMesh

While not strictly required, OsdMesh is still supported in 3.0 as convenience API for allocating buffers. OsdMesh serves as a simple way to allocate all required data, in the location required by the API (for example, GPU buffers for OpenGL).

OsdKernelBatch

No translation, it is no longer part of the API.

OsdVertex

No translation, it is no longer part of the API.

End Cap Strategies

By default, OpenSubdiv uses Gregory patches to approximate the patches around extraordinary vertices at the maximum isolation level, this process is referred to as "end-capping".

If ENDCAP_BSPLINE_BASIS is specified to PatchTableFactory::Options, BSpline patches are used, which gives less accuracy, but it makes possible to render an entire mesh in a single draw call. Both patches require additional control points that are not part of the mesh, we refer to these as "local points". In 3.0, the local points of those patches are computed by applying a stencil table to refined vertices to construct a new stencil table for the local points.

Since this new stencil table is topologically compatible with the primary stencil table for refinement, it is convenient and efficient to splice those stencil tables together. This splicing can be done in the following way:

Far::StencilTable const *refineStencils =
                              Far::StencilTableFactory::Create(topologyRefiner);

Far::PatchTable cosnt *patchTable =
                              Far::PatchTableFactory::Create(topologyRefiner);

Far::StencilTable const *localPointStencils =
                                  patchTable->GetLocalPointStencilTable();

Far::StencilTable const *splicedStencils =
        Far::StencilTableFactory::AppendLocalPointStencilTables(topologyRefiner,
                                                          refineStencils,
                                                          localPointStencils);

NOTE: Once the spliced stencil table is created, the refined stencils can be released, but the local point stencils are owned by patchTable, it should not be released.

OpenSubdiv 3.0 also supports 2.x style Gregory patches, if ENDCAP_LEGACY_GREGORY is specified to PatchTableFactory::Options. In this case, such an extra stencil splicing isn't needed, however clients must still bind additional buffers (VertexValence buffer and QuadOffsets buffer).

See Osd::GLLegacyGregoryPatchTable for additional details.