Release Notes

Release Notes



Content under development....

images/construction.png

General 3.x RoadMap

Within the 3.x release cycle we would like to address first and foremost many of the issues related to scaling the application of subdivision surfaces to large volumes of primitives within typical graphics pipelines.

Enabling workflows at larger scales will require improvements on several fronts:

  • Handle more primitives, but with fewer overheads:

    • Reduce Compute kernel launches using stencils instead of subdivision tables
    • Reduce Draw calls by addressing the combinatorial explosion of tessellation shaders
    • Provide back-ends for next-gen APIs (D3D12, Mantle, Metal, GL 5.x)
  • More semi-sharp creases: feature isolation needs to become much more efficient to allow for complete creative freedom in using the feature.

  • Faster topology analysis

Release 3.0

OpenSubdiv 3.0 represents a landmark release with very profound changes to the core algorithms. While providing faster, more efficient, and more flexible subdivision code remains our principal goal, OpenSubdiv 3.0 introduces many improvements that constitute a fairly radical departures from our previous code releases.

Improved performance

OpenSubdiv 3.0 introduces new data structures and algorithms that greatly enhance performance over previous versions. The 3.0 release focuses mostly on the CPU side, and should provide "out-of-the-box" speed-ups close to an order of magnitude for topology refinement and analysis (both uniform and adaptive).

On the GPU side, the replacement of subdivision tables with stencils allows us to remove several bottlenecks in the Compute area that can yield as much as 4x faster interpolation on CUDA platforms. At the same time, stencils also reduce the dozens of kernel launches required per primitive to a single one (this was a known issue on certain mobile platforms). Compute calls batching is now trivial.

New topology entry-points

OpenSubdiv 3.0 introduces several new entry-points for client topology. Previous releases force client applications to define and populate instances of an Hbr half-edge topology representation. For many applications, this representation is both redundant and inefficient.

OpenSubdiv 3.0 introduces a new intermediate topological representation, named Vtr (Vectorized Topology Representation). The topological relationships held by Vtr can populated using either a high-level interface where simplicity has been emphasized, or a lower-level interface for enhanced efficiency (still under construction). Vtr is much more efficient for the kinds of topological analysis required by Far and additionally is more flexible in that it supports the specification of non-manifold topology.

As a result, Hbr is no longer a core API of OpenSubdiv. While the code is marked as deprecated, it will remain in the source distribution for legacy and regression purposes.

New treatment of face-varying data

With Hbr no longer the entry point for clients, OpenSubdiv 3.0 provides a new interface to face-varying data. Previous versions required FVar data to be assigned by value to the vertex for each face, and whether or not the set of values around a vertex was continuous was determined by comparing these values later. In some cases this could result in two values that were not meant to be shared being "welded" together.

Face-varying data is now specified topologically. Just as the vertex topology is defined from a set of vertices and integer references to these vertices for the vertex of each face, face-varying topology is defined from a set of values and integer references to these values for the vertex of each face. So if values are to be considered distinct around a vertex, they are given distinct indices and no comparison of values is ever performed.

This ensures that OpenSubdiv's face-varying topology matches what is specified in common geometry container formats like Obj or Alembic. It also allows for more efficient processing of face-varying values during refinement, and so the cost of interpolating a set of face-varying data should now be little more than the cost of interpolating a similar set of vertex data (depending on the number of distinct face-varying values versus the number of vertices).

Subdivision Core

In consideration of the existing representations, Hbr and Vtr, all low-level details fundamental to subdivision and the specific subdivision schemes has been factored into a new low-level layer (the lowest) called Sdc. This layer encapsulates the full set of applicable options, the formulae required to support semi-sharp creasing, the formulae for the refinement masks of each subdivision scheme, etc.

Sdc provides the low-level nuts and bolts to provide a subdivision implementation consistent with OpenSubdiv. It is used internally by Vtr but can also provide clients with an existing implementation of their own with the details to make that implementation consistent with OpenSubdiv.

Stencil Tables

OpenSubdiv 3.0 replaces the serialized subdivision tables with factorized stencil tables. Subdivision tables as implemented in 2.x releases still contain a fairly large amount of data inter-dependencies which incur pernalties for using more fences or kernel launches. Most of these dependencies have now been factorised away in the pre-computation stage, yielding stencil tables instead.

Stencils remove all data dependencies and simplify all the computations into a single trivial kernel. This simplification results in a faster pre-computation stage, faster execution on GPU, and fewer driver overheads. The new stencil tables Compute back-end is supported on all the same platforms as previous releases.

Subdivision Specification Changes

The refactoring of OpenSubdiv 3.0 data representations presents a unique opportunity to revisit some corners of the subdivision specification and remove or update some legacy features.

Since the various options are now presented through a new API (Sdc rather than Hbr), based on the history of some of these options and input from interested parties, some of these are being reconsidered:

  • the creasing method 'Normal' has been renamed 'Uniform'
  • considering the renaming of the 'boundary interpolation' enum and its choices
  • same as above for 'face varying boundary interpolation'

In these cases, features are not being removed but simply re-expressed in what is hoped to be a clearer interface.

Hierarchical Edits

Currently Hierarchical Edits have been marked as "extended specification" and support for hierarchical features has been removed from the 3.0 release. This decision allows for great simplifications of many areas of the subdivision algorithms. If we can identify legitimate use cases for hierarchical tags, we will consider re-implementing them in future releases, as time and resources allow.

Alpha Release Notes

Our intentions as open-source developpers is to give as much access to our code, as early as possible, because we value and welcome the feedback from the community.

The 'alpha' release moniker means to us that our code is still far from being finalized. Although we are now close from being feature complete, our public-facing interfaces are still subject to change. Therefore, we do not recommend this version of OpenSubdiv be used in client applications until both features and interfaces have been finalized in an official 'Beta' Release.

The following is a short list of featurs and issues that will be addressed during the alpha cycle:

  1. Support for Loop and Bilinear schemes (consistent with 2.x)
  2. Refactor Interpolate<>(), InterpolateFaceVarying<>() et al
  3. Complete all face-varying boundary interpolation interpolation rules
  4. Arbitrary-location limit stencils
  5. Limit Masks
  6. Tagging and recognition of faces as Holes
  7. Complete the accelerated conversion from client mesh to Far::TopologyRefiner
  8. Misc Sdc / Vtr / Far code cleanup & documentation

Release 2.x

Previous releases