mirror of
https://github.com/PixarAnimationStudios/OpenSubdiv
synced 2024-11-09 22:00:06 +00:00
A few incremental updates to a number of documentation pages
This commit is contained in:
barfowl
parent
0172b9ae5f
commit
4543c9f8bc
@ -35,64 +35,61 @@ with subdivision surfaces (including older versions of OpenSubdiv).
|
||||
Compatibility with OpenSubdiv 2.x
|
||||
=================================
|
||||
|
||||
**Vertex Interpolation Options**
|
||||
|
||||
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, the following changes have been implemented:
|
||||
|
||||
* Legacy modes of the *"smoothtriangle"* rule have been removed (as they
|
||||
were never actually enabled in the code). Values for *"TriangleSubdivision"*
|
||||
are now:
|
||||
|
||||
* TRI_SUB_CATMARK - Catmull-Clark weights (default)
|
||||
* TRI_SUB_SMOOTH - "smooth triangle" weights
|
||||
|
||||
* The naming of the standard creasing method has been changed from *Normal*
|
||||
to *Uniform*. Values for *"CreasingMethod"* are now:
|
||||
|
||||
* CREASE_UNIFORM - the standard integer subtraction per level
|
||||
* CREASE_CHAIKIN - use Chaikin averaging around vertices
|
||||
|
||||
A conscious choice was also made to change the behavior of Chaikin creasing
|
||||
in the presence of infinitely sharp edges (most noticeable at boundaries).
|
||||
Previously the inclusion of the infinite sharpness values a semi-sharp edge
|
||||
from decaying to zero. Infinitely sharp edges are now excluded from the
|
||||
Chaikin averaging yielding a much more predictable and desirable result.
|
||||
Since this feature has received little use (only recently activated in
|
||||
RenderMan) now seemed a good time to make the change.
|
||||
The refactoring of OpenSubdiv 3.0 data representations presented a unique
|
||||
opportunity to revisit some corners of the subdivision specification and
|
||||
remove or update some legacy features. Below are some of the changes made that
|
||||
may affect compatibility with other software and previous versions of
|
||||
OpenSubdiv.
|
||||
|
||||
**Face-varying Interpolation Options**
|
||||
|
||||
Face-varying interpolation options have been consolidated into a single enum
|
||||
with one additional choice new to 3.0. No functionality from 2.x has been
|
||||
removed -- just re-expressed in what we hope is a simpler and more
|
||||
comprehensible form.
|
||||
|
||||
Face-varying interpolation was previously defined by a "boundary interpolation"
|
||||
enum with four modes and an additional boolean "propagate corners" option,
|
||||
which was little understood. The latter was only used in conjunction with one
|
||||
of the four modes, so it was effectively a unique fifth choice. Deeper analysis
|
||||
of all of these modes revealed unexpected and undesirable behavior in some common
|
||||
cases -- to an extent that could not simply be changed -- and so additions have
|
||||
been made to avoid such behavior.
|
||||
which was little understood, i.e.:
|
||||
|
||||
All choices are now provided through a single "linear interpolation" enum --
|
||||
intentionally replacing the use of "boundary" in its naming as the choice also
|
||||
affects interior interpolation. The naming now reflects the fact that
|
||||
interpolation is constrained to be linear where specified by the choice.
|
||||
* void HbrMesh::SetFVarInterpolateBoundarMethod(InterpolateBoundaryMethod) const;
|
||||
|
||||
* void HbrMesh::SetFVarPropagateCorners(bool) const;
|
||||
|
||||
The latter was only used in conjunction with one
|
||||
of the four modes ("edge and corner"), so it was effectively a unique fifth
|
||||
choice. Closer inspection of all of these modes also revealed some unexpected
|
||||
and undesirable behavior in some common cases -- to an extent that could not
|
||||
simply be changed -- and so an additional mode was added to avoid such behavior.
|
||||
|
||||
All choices are now provided through a single "linear interpolation" enum,
|
||||
desribed and illustrated in more detail in the overview of
|
||||
`Face-Varying Interpolation <subdivision_surfaces.html#face-varying-interpolation-rules>`__.
|
||||
The use of "boundary" in the name of the enum was intentionally removed
|
||||
as the choice also affects interior interpolation. The new use of "linear"
|
||||
is now intended to reflect the fact that interpolation is constrained to be
|
||||
linear where specified by the choice applied.
|
||||
|
||||
All five of Hbr's original modes of face-varying interpolation are supported
|
||||
(with minor modifications where Hbr was found to be incorrect in the presence
|
||||
of semi-sharp creasing). An additional mode has also been added to allow for
|
||||
additional control around T-junctions where multiple disjoint face-varying
|
||||
regions meet at a vertex.
|
||||
of semi-sharp creasing). An additional mode ("corners only") has also been
|
||||
added to avoid some of the undesired side-effects of some existing modes.
|
||||
|
||||
The new values for the *"FVarLinearInterpolation"* are:
|
||||
The new values for the *"Sdc::Options::FVarLinearInterpolation"* enum and its
|
||||
equivalents for HbrMesh's InterpolateBoundaryMethod and PropagateCorners flag
|
||||
are as follows (ordered such that the set of linear constraints applied is
|
||||
always increasing -- from completely smooth to completely linear):
|
||||
|
||||
========================= ==============================================================
|
||||
FVAR_LINEAR_NONE smooth everywhere (formerly "edge only")
|
||||
FVAR_LINEAR_CORNERS_ONLY sharpen corners only (new)
|
||||
FVAR_LINEAR_CORNERS_PLUS1 sharpen corners and some junctions (formerly "edge and corner")
|
||||
FVAR_LINEAR_CORNERS_PLUS2 sharpen corners and more junctions (formerly "edge and corner + propagate corner")
|
||||
FVAR_LINEAR_BOUNDARIES piecewise linear edges and corners (formerly "always sharp")
|
||||
FVAR_LINEAR_ALL bilinear interpolation (formerly "bilinear") (default)
|
||||
========================= ==============================================================
|
||||
============================ ================================== =========================
|
||||
Sdc FVarLinearInterpolation Hbr FVarInterpolateBoundaryMethod Hbr FVarPropogateCorners
|
||||
============================ ================================== =========================
|
||||
FVAR_LINEAR_NONE k_InterpolateBoundaryEdgeOnly N/A (ignored)
|
||||
FVAR_LINEAR_CORNERS_ONLY N/A N/A
|
||||
FVAR_LINEAR_CORNERS_PLUS1 k_InterpolateBoundaryEdgeAndCorner false
|
||||
FVAR_LINEAR_CORNERS_PLUS2 k_InterpolateBoundaryEdgeAndCorner true
|
||||
FVAR_LINEAR_BOUNDARIES k_InterpolateBoundaryAlwaysSharp N/A (ignored)
|
||||
FVAR_LINEAR_ALL k_InterpolateBoundaryNone N/A (ignored)
|
||||
============================ ================================== =========================
|
||||
|
||||
Aside from the two "corners plus" modes that preserve Hbr behavior, all other
|
||||
modes are designed so that the interpolation of a disjoint face-varying region
|
||||
@ -104,39 +101,132 @@ sharp creasing applied within the region, and nowhere else). This is not true
|
||||
of the "plus" modes, and they are named to reflect the fact that more is taken
|
||||
into account where disjoint regions meet.
|
||||
|
||||
These should be illustrated in more detail elsewhere in the documentation
|
||||
(where exactly?) and with the example shapes and viewers.
|
||||
Differences between the modes can be seen in the regression shapes with the
|
||||
prefix "catmark_fvar" -- which were specifically created for that purpose.
|
||||
|
||||
**Vertex Interpolation Options**
|
||||
|
||||
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, the following changes have been implemented:
|
||||
|
||||
* The naming of the standard creasing method has been changed from *Normal*
|
||||
to *Uniform*. Values for *"Sdc::Options::CreasingMethod"* are now:
|
||||
|
||||
============== ====================================
|
||||
CREASE_UNIFORM standard integer subtraction per level (default)
|
||||
CREASE_CHAIKIN Chaikin (non-uniform) averaging around vertices
|
||||
============== ====================================
|
||||
|
||||
* Legacy modes of the *"smoothtriangle"* rule have been removed (as they
|
||||
were never actually enabled in the code). Values for
|
||||
*"Sdc::Options::TriangleSubdivision"* are now:
|
||||
|
||||
=============== =================
|
||||
TRI_SUB_CATMARK Catmull-Clark weights (default)
|
||||
TRI_SUB_SMOOTH "smooth triangle" weights
|
||||
=============== =================
|
||||
|
||||
These should have little impact since one is a simple change in terminology
|
||||
as part of a new API while the other was removal of an option that was never
|
||||
used.
|
||||
|
||||
**Change to Chaikin creasing method**
|
||||
|
||||
In the process of re-implementing the Chaikin creasing method, observations
|
||||
lead to a conscious choice to change the behavior of Chaikin creasing in the
|
||||
presence of infinitely sharp edges (most noticeable at boundaries).
|
||||
|
||||
Previously the inclusion of the infinite sharpness values in the averaging
|
||||
of sharpness values that takes place around a vertex would prevent a
|
||||
semi-sharp edge from decaying to zero. Infinitely sharp edges are now
|
||||
excluded from the Chaikin (non-uniform) averaging yielding a much more
|
||||
predictable and desirable result, e.g. where the sharpness assignment is
|
||||
actually uniform at such a vertex, the result will now behave the same as
|
||||
the Uniform method.
|
||||
|
||||
Since this feature has received little use (only recently activated in
|
||||
RenderMan) now seemed the best time to make the change before more widespread
|
||||
adoption.
|
||||
|
||||
**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.
|
||||
While extremely powerful, Hierarchical Edits come with additional maintenance
|
||||
and implementation complexity. Support for them in popular interchange formats
|
||||
and major DCC applications has either been dropped or was never implemented.
|
||||
As a result, the need for Hierarchical Edits is too limited to justify the cost
|
||||
and support for them and they have therefore been removed from the 3.0 release
|
||||
of OpenSubdiv. Dropping support for Hierarchical Edits allows for significant
|
||||
simplifications of many areas of the subdivision algorithms.
|
||||
|
||||
While the 3.0 release does not offer direct support for Hierarchical Edits, it
|
||||
is hoped that the architectural changes and direction of 3.0 will facilitate
|
||||
their application for those wishing to use them -- though not always in the
|
||||
same optimized context. As with many other features, consideration for
|
||||
increased support will be considered based on demand and resources.
|
||||
|
||||
**Non-Manifold Topology**
|
||||
|
||||
OpenSubdiv 2.x and earlier was limited to dealing with meshes whose topology
|
||||
was manifold -- a limitation imposed by the use of Hbr. With 3.0 no longer
|
||||
using Hbr, the manifold restriction has also been removed.
|
||||
|
||||
So 3.0 will support a superset of the meshes supported by 2.x. Non-manifold
|
||||
meshes that are acceptible to 3.0 however will likely not work with 2.x or
|
||||
earlier.
|
||||
|
||||
|
||||
Compatibility with RenderMan
|
||||
============================
|
||||
|
||||
(More detail to come...)
|
||||
Since RenderMan and OpenSubdiv versions prior to 3.0 share a common library
|
||||
(Hbr), some differences between RenderMan and OpenSubdiv are covered in the
|
||||
section of compatibility with OpenSubdiv 2.x.
|
||||
|
||||
Conscious deviations (incompatibilities):
|
||||
While there are features between RenderMan and OpenSubdiv that are not
|
||||
compatibile, there are also other differences that may be presence due to
|
||||
differences in the implementations of similar features. Given the common
|
||||
past between RenderMan and OpenSubdiv (and potential expectations arising
|
||||
from it), mention of both is warranted here.
|
||||
|
||||
- non-manifold topology
|
||||
- choice of new face varying interpolation option ("corners only")
|
||||
- use of Chaikin creasing with boundaries or infinitely sharp edges
|
||||
- lack of hierarchical edits support
|
||||
Incompatibilities
|
||||
+++++++++++++++++
|
||||
|
||||
Corrections to Hbr's behavior (differences):
|
||||
OpenSubdiv and RenderMan will be incompatible when certain features are used
|
||||
that are not common to both. While described in the 2.x compatibility
|
||||
section, they are listed briefly here.
|
||||
|
||||
- smooth face varying interpolation in presence of dart vertices
|
||||
- smooth face varying interpolation with fractional sharpness
|
||||
- Chaikin creasing in general
|
||||
**OpenSubdiv Features Not Supported by RenderMan**
|
||||
|
||||
Improved accuracy (differences):
|
||||
* non-manifold meshes
|
||||
|
||||
- ordering of weight application (most prevalent with high-valence vertices)
|
||||
- limit positions and tangents for arbitrary valence
|
||||
- potential use of double precision masks
|
||||
* choice of the "corners only" face varying interpolation option
|
||||
|
||||
|
||||
**RenderMan Features Not Supported by OpenSubdiv**
|
||||
|
||||
* hierarchical edits (as of 3.0, may be subsequently re-introduced)
|
||||
|
||||
|
||||
Other Differences
|
||||
+++++++++++++++++
|
||||
|
||||
**Smooth Face-Varying Interpolation with Creasing**
|
||||
|
||||
There have been two discrepancies noted in the way that face-varying data is
|
||||
interpolated smoothly in the presense of creases:
|
||||
|
||||
* interpolation around a dart vertex
|
||||
|
||||
* lack of blending for fractional sharpness, i.e. only integer sharpness
|
||||
|
||||
**The Chaikin Creasing Method**
|
||||
|
||||
* use of Chaikin creasing with boundaries or infinitely sharp edges
|
||||
|
||||
* subtle shape differences due to Hbr's use of "predictive sharpness"
|
||||
|
||||
**Numerical Precision**
|
||||
|
||||
* improved with OSD's ordering of weight application (most prevalent with
|
||||
high-valence vertices)
|
||||
|
||||
@ -414,19 +414,24 @@ See Osd::GLLegacyGregoryPatchTable for additional details.
|
||||
Changes to Subdivision
|
||||
======================
|
||||
|
||||
The refactoring of OpenSubdiv 3.0 data representations presents a unique
|
||||
The refactoring of OpenSubdiv 3.0 data representations presented a unique
|
||||
opportunity to revisit some corners of the subdivision specification and
|
||||
remove or update some legacy features. Below are some of the changes made that
|
||||
affect compatibility with other software and previous versions of OpenSubdiv.
|
||||
For more details please see the Subdivition Compatibility Guide<compatibility.html>.
|
||||
remove or update some legacy features -- none of which was taken lightly.
|
||||
More details are provided in
|
||||
`Subdivision Compatibility Guide <compatibility.html>`__, while the
|
||||
following offers a quick overview:
|
||||
|
||||
* All face-varying interpolation options have been combined into a single enum.
|
||||
|
||||
* Vertex interpolation options have been renamed or removed:
|
||||
|
||||
* Vertex Interpolation Options changed.
|
||||
* Legacy modes of the *"smoothtriangle"* triangle have been removed.
|
||||
* The naming of the standard creasing method has changed from *Normal* to *Uniform*.
|
||||
|
||||
* Face-varying Interopation options have changed.
|
||||
* Unused legacy modes of the *"smoothtriangle"* option have been removed.
|
||||
|
||||
* Hierarchical Edits support has been removed.
|
||||
* The averaging of Chaikin creasing with infinitely sharp edges has changed.
|
||||
|
||||
* Support for Hierarchical Edits has been removed.
|
||||
|
||||
|
||||
Build Support for Combining 2.x and 3.0
|
||||
|
||||
@ -34,20 +34,22 @@
|
||||
Release 3.0.0
|
||||
=============
|
||||
|
||||
Release 3.0.0 is a major release with many significant improvements and
|
||||
changes. For more information on the following, please see
|
||||
`Introduction to 3.0 <intro_30.html>`__
|
||||
|
||||
**New Features**
|
||||
- Updated coding style with namespaces
|
||||
- Faster subdivision using less memory
|
||||
- Introduction of Stencil Tables
|
||||
- Faster, simple GPU kernels
|
||||
- Unified adaptive shaders
|
||||
- Single Crease Patch
|
||||
- New Irregular Patch approximations
|
||||
- Support for non-manifold topology
|
||||
- Simpler conversion of topology
|
||||
- Face-Varying topology
|
||||
- Face-Varying data specified topologically
|
||||
- Introduction of Stencil Tables
|
||||
- Single Crease Patch
|
||||
- Irregular Patch approximations
|
||||
- Elmination of fixed valence tables
|
||||
- New coding style
|
||||
- Faster, simpler GPU kernels
|
||||
- Unified adaptive shaders
|
||||
- More documentation and tutorials
|
||||
- For more, information please see `Introduction to 3.0 <intro_30.html>`__
|
||||
|
||||
|
||||
Release 3.0.0 RC2
|
||||
|
||||
@ -122,34 +122,40 @@ On a quad example:
|
||||
Face-Varying Interpolation Rules
|
||||
================================
|
||||
|
||||
Face-varying data is used when discontinuities are required in the data over the
|
||||
surface -- mostly commonly the seams between disjoint UV regions.
|
||||
Face-varying data can follow the same interpolation behavior as vertex data, or it
|
||||
can be constrained to interpolate linearly around selective features from corners,
|
||||
boundaries, or the entire interior of the mesh.
|
||||
|
||||
The following rules can be applied to face-varying data interpolation:
|
||||
The following rules can be applied to face-varying data interpolation -- the
|
||||
ordering here applying progressively more linear constraints:
|
||||
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
| Mode | Behavior |
|
||||
+================================+===============================================+
|
||||
| **FVAR_LINEAR_NONE** | smooth everywhere the mesh is smooth |
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
| **FVAR_LINEAR_CORNERS_ONLY** | sharpen corners only |
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
| **FVAR_LINEAR_CORNERS_PLUS1** | sharpen corners plus some junctions |
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
| **FVAR_LINEAR_CORNERS_PLUS2** | sharpen corners plus more junctions and darts |
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
| **FVAR_LINEAR_BOUNDARIES** | piecewise linear boundary edges and corners |
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
| **FVAR_LINEAR_ALL** | linear interpolation everywhere |
|
||||
+--------------------------------+-----------------------------------------------+
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
| Mode | Behavior |
|
||||
+================================+=============================================================+
|
||||
| **FVAR_LINEAR_NONE** | smooth everywhere the mesh is smooth |
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
| **FVAR_LINEAR_CORNERS_ONLY** | sharpen (linearly interpolate) corners only |
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
| **FVAR_LINEAR_CORNERS_PLUS1** | CORNERS_ONLY + sharpening of junctions of 3 or more regions |
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
| **FVAR_LINEAR_CORNERS_PLUS2** | CORNERS_PLUS1 + sharpening of darts and concave corners |
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
| **FVAR_LINEAR_BOUNDARIES** | linear interpolation along all boundary edges and corners |
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
| **FVAR_LINEAR_ALL** | linear interpolation everywhere (boundaries and interior) |
|
||||
+--------------------------------+-------------------------------------------------------------+
|
||||
|
||||
These rules cannot make the interpolation of the face-varying data smoother than
|
||||
that of the vertices. The presence of sharp features of the mesh created by
|
||||
sharpness values, boundary interpolation rules, or the subdivision scheme itself
|
||||
(e.g. Bilinear) take precedence.
|
||||
|
||||
Face-varying interpolation using the catmark_fvar_bound1 regression shape:
|
||||
All face-varying interpolation modes illustrated in UV space using the
|
||||
catmark_fvar_bound1 regression shape -- a simple 4x4 grid of quads segmented
|
||||
into three UV regions (their control point locations implied by interpolation
|
||||
in the FVAR_LINEAR_ALL case):
|
||||
|
||||
.. image:: images/fvar_boundaries.png
|
||||
:align: center
|
||||
|
||||
@ -45,25 +45,9 @@ namespace Sdc {
|
||||
/// The intent is that these sets of options be defined at a high-level and
|
||||
/// propagated into the lowest-level computation in support of each subdivision
|
||||
/// scheme. Ideally it remains a set of bit-fields (essentially an int) and so
|
||||
/// remains light weight and easily passed down by value.
|
||||
/// remains light weight and easily passed around by value.
|
||||
///
|
||||
|
||||
//
|
||||
// BETA NOTES:
|
||||
// Several of these options are being reconsidered in light of the divergence of
|
||||
// OSD 3.0 from Hbr. In some cases the options can be expressed more clearly and free
|
||||
// of any RenderMan legacy for future use. Details are noted below:
|
||||
// "VtxBoundaryInterpolation"
|
||||
// - its effect is to sharpen edges/corners, but edges are always sharpened
|
||||
// - the "None" case serves no purpose (and would be discouraged)
|
||||
// "FVarLinearInterpolation":
|
||||
// - the new "corner only" mode will sharpen corners and NEVER sharpen smooth
|
||||
// boundaries, which we believe to be expected when sharping corners -- the
|
||||
// old "edge and corner" mode would sharpen boundaries under some situations
|
||||
// (e.g. more than three fvar values at a vertex)
|
||||
// "NonManifoldInterpolation":
|
||||
// - rules still need to be defined and implemented
|
||||
//
|
||||
class Options {
|
||||
public:
|
||||
enum VtxBoundaryInterpolation {
|
||||
|
||||
Loading…
Reference in New Issue
Block a user