Architecture Overview

Because the OpenSubdiv software is intended to run on a variety of computing resources, the API architecture has to accomodate a fairly complex matrix of interoperations. In order to achieve the requisite flexibility, the code structure is both layered and modular.

Opt-In Features

One of the fundamental requirement of all our API's design patterns is the opt-in implementation of features. Because most of the algorithms are used within the constraints of interactive applications, we want to provide optimal code paths wherever possible.

Therefore, client-code should always have the option to opt-out of the memory and processing costs of any given feature that is not used.

API Layers

From a top-down point of view, OpenSubdiv is comprised of several layers, some public, and some private.

Layers list in descending order:

• Osd (OpenSubdiv)
• Far (Feature Adaptive Representation)
• Vtr (Vectorized Topological Representation)
• Sdc (Subdivision Core)

Client mesh data enters the API through the Far layer. Typically, results will be collected from the Osd layer. However, it is therefore possible to use functionality from Far without introducing any dependency on Osd.

Although there are several entry-points to provide topology and primitive variable data to OpenSubdiv, eventually everything must pass through the private Vtr and Sdc representations for topological analysis.

See Using the Right Tools for more in-depth coverage.

Representation vs. Implementation Layers

One of the core performance goals of our subdivision algorithms is to leverage interactive performance out of massively parallel code execution wherever possible. In order to support a large diversity of compute architectures it is critical to stream the geometric data to the compute kernels in the most optimal way.

Data structures that are efficient for topology analysis during the pre-computation stage are not very good candidates for parallel processing. Our layered structure reflects this requirement: topology analysis and other pre-computation tasks are delegated to "representation" layers, while the actual execution of computations has been moved to an "implementation" layer.

Representation layers are for general purpose algorithms and differenciated by the requirements placed on data represenation. See Multiple Representations for more details.

The Implementation layer contains hardware and API-specific implementations. In order to minimize code redundancy and bugs, we strive to reduce device-specific computation logic to the most simplistic expression possible (in many cases as simple as series of multiply-ads).

Multiple Representations

The coarse mesh of a subdivision surface is represented by a collection of components that maintain relationships to each other.

For instance:

• vertex to incident edge
• edge to origin and destination vertex
• face to edges

This allows authoring applications to easily access "neighboring" components in order to make topology edits or manipulate properties of the components themselves. The key to achieving efficient many-core processing is to reduce data interdependencies. However, by definition, the bulk of topological mesh data is the very description of these connections (dependencies) between vertices.

This is why OpenSubdiv provides specific representations for mesh data:

• Vtr is a vectorized topology-only representation
• Far is a feature adaptive serialized representation

A typical workflow would be to manipulate the topology in authoring applications, maybe using Hbr or a similar relational representation for common editing operations. Once the topology of the mesh has stabilized, it is processed into a serialized form that can then be evaluated at interactive framerates. The serialized form is embodied by Far, which can then be migrated by device-specific functions in Osd.

Feature Adaptive Subdivision

Because of the high-performance apsects, one of the main goals of the OpenSubdiv set of APIs is to compartmentalize subdivision rules from interpolation computations, which can then be dispatched to discrete compute devices, including a variety of GPUs.

The data paths for the feature adaptive algorithm layered over the OpenSubdiv architecture:

Vtr serves both as a private, efficient, intermediate topological description and as the custodian of the Catmull-Clark (and Loop) subdivision rules. Far is used to leverage these rules in order to produce serialized topological tables.

The remaining computations have been reduced to extremely simple forms of interpolation, which can be dispatched to a variety of discrete computation platforms.

Using the Right Tools

OpenSubdiv's tiered interface offers a lot flexibility to make your application both fast and robust. Because navigating through the large collection of classes and features can be challenging, here is a flow-chart that should help sketch the broad lines of going about using subdivisions in your application.

General client application requirements:

Flow-chart: