AuroraMiddleware/OpenSubdiv
1
0
Fork 0
mirror of https://github.com/PixarAnimationStudios/OpenSubdiv synced 2024-12-24 08:41:18 +00:00
Code Issues Releases Wiki Activity

Minor updates to documentation preceding Beta release.

Browse Source
This commit is contained in:
barfowl 2015-01-08 19:07:35 -08:00
parent 1ea80096b5
commit 0b7ba6a604
8 changed files with 215 additions and 179 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
documentation/api_overview.rst
View File

@ -67,7 +67,7 @@ Layers list in descending order:
* **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
be collected from the Osd layer. However, it is possible to use
functionality from Far without introducing any dependency on Osd.
Although there are several entry-points to provide topology and primitive variable
@ -98,7 +98,7 @@ has been moved to an "implementation" layer.
.. image:: images/api_representations.png
**Representation** layers are for general purpose algorithms and differenciated by
**Representation** layers are for general purpose algorithms and differentiated by
the requirements placed on data represenation. See `Multiple Representations`_ for
more details.

53
documentation/far_overview.rst
View File

@ -80,17 +80,6 @@ public interface to all of the improvements proposed, they potentially warrant
the most attention. Far::TopologyRefiner is purely topological and it is the
backbone used to construct or be associated with the other table classes in Far.
.. container:: notebox
**Beta Issues**
Interface issues needing attention:
* TopologyRefiner::Refine() needs more options (bundled in struct)
* TopologyRefiner::Interpolate() methods need revisiting
* considering simplifying TopologyRefiner interface overall -- may expose
TopologyLevel for public inspection
* specialization of TopologyRefinerFactory<MESH> needs more work
Far::TopologyRefiner
********************
@ -101,27 +90,27 @@ topology of an arbitrarily refined subdivision hierarchy to support the
construction of `stencil tables <#patch-tables>`__, `patch tables
<#patch-tables>`__, etc.
Aside from public access to topology, *TopologyRefiner::Refine(...)* is
internally where simple specifications of refinement (currently uniform or
feature-adaptive with a level argument) will be translated into refinement
operations within Vtr. Feature-adaptive refinement is a special case of
*"sparse"* or *"selective"* refinement, and so the feature-adaptive logic
exists internal to TopologyRefiner and translates the feature-analysis into a
simpler topological specification of refinement to Vtr.
Aside from public access to topology, TopologyRefiner has public refinement
methods (currently *RefineUniform()* and *RefineAdapative()*) where simple
specifications of refinement will be translated into refinement operations
within Vtr. Feature-adaptive refinement is a special case of *"sparse"* or
*"selective"* refinement, and so the feature-adaptive logic exists internal
to TopologyRefiner and translates the feature-analysis into a simpler
topological specification of refinement to Vtr.
.. image:: images/topology_refiner.png
:align: center
The longer term intent is that the public Refine(...) operation eventually be
overloaded to allow clients more selective control of refinement. While
The longer term intent is that the public Refine...(...) operations eventually
be overloaded to allow clients more selective control of refinement. While
TopologyRefiner is a purely topological class, and so free of any definitions
of vertex data, the public interface has been extended to include templated
functors that allow clients to interpolate primitive variable data.
methods that allow clients to interpolate primitive variable data.
Far::TopologyRefinerFactory
***************************
Consistent with other classes in Far instances of TopologyRefiner are created
Consistent with other classes in Far, instances of TopologyRefiner are created
by a factory class -- in this case Far::TopologyRefinerFactory. This class
is an important entry point for clients its task is to map/convert data in a
client's mesh into the internal `Vtr <vtr_overview.html>`__ representation as
@ -133,8 +122,8 @@ Since a client' mesh representation knows best how to identify the topological
neighborhoods required, no generic implementation would provide the most
direct means of conversion possible, and so we rely on specialization. For
situations where mesh data is not defined in a boundary representation, a
simple container for raw mesh data is provided along with a Factory
specialized to construct TopologyRefiners from it.
simple container for raw mesh data is provided (TopologyDescriptro) along
with a Factory specialized to construct TopologyRefiners from it.
So there are two ways to create TopologyRefiners:
@ -143,13 +132,25 @@ So there are two ways to create TopologyRefiners:
* specialize TopologyRefinerFactory<class MESH> for more efficient
conversion
XXXX <insert blurb about Descriptor>
TopologyDescriptor is a simple struct with pointers to raw mesh data in a
form common to mesh constructors. Topologically, the minimal requirement
consists of:
* the number of vertices and faces of the mesh
* an array containing the number of vertices per face
* an array containing the vertices assigned to each face
These last two define one of the six topological relations that are needed
internally by Vtr, but this one relation is sufficient to construct the rest.
Additional members are available to assign sharpness values per edge and/or
vertex, hole tags to faces, or to define multiple sets (channels) of
face-varying data.
Specialization of TopologyRefinerFactory<class MESH> should be done with care
as the goal here is to maximize the performance of the conversion and so
minimize overhead due to runtime validation. The template provides the
high-level construction of the required topology vectors of the underlying
Vtr, with the requirement that two methods will be specialized with the
Vtr. It requires the specification/specialization of two methods with the
following purpose:
* specify the sizes of topological data so that vectors can be pre-allocated

2
documentation/osd_overview.rst
View File

@ -116,7 +116,7 @@ a series of regression tests that compare the methods to each other.
.. container:: impnotip
* **Important**
* **Beta Issues**
Face-varying smooth data interpolation is currently not supported in **Osd**.
"Smooth UV" modes of various DCC applications are not supported (yet).

142
documentation/release_notes.rst
View File

@ -128,7 +128,7 @@ 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 and
Far. but can also provide client-code with an existing implementation of their
Far but can also provide client-code with an existing implementation of their
own with the details to make that implementation consistent with OpenSubdiv.
The documentation for Sdc can be found `here <sdc_overview.html>`__
@ -200,31 +200,44 @@ 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 Sdc boundary interpolation enum has been renamed
*"VtxBoundaryInterpolation"*, with the following values:
* Between the Alpha and Beta releases, the naming of the boundary
interpolation enum was renamed *"VtxBoundaryInterpolation"*, with
the following values:
* VTX_BOUNDARY_NONE - (default)
* VTX_BOUNDARY_NONE (default)
* VTX_BOUNDARY_EDGE_ONLY
* VTX_BOUNDARY_EDGE_AND_CORNER
Funcationality remains unchanged.
* Legacy modes of the *"smoothtriangle"* rule have been removed. Values for
*"CreasingMethod"* are now:
Functionality remains unchanged.
* 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:
* The current implementation of the *"Chaikin"* rule shows small
* CREASE_UNIFORM - the standard integer subtraction per level
* CREASE_CHAIKIN - use Chaikin averaging around vertices
The current implementation of the *"Chaikin"* rule shows small
numerical differences with results obtained from Hbr in 2.x releases.
Considering that the feature is rarely used and that the current
implementation is likely the more correct one, we are considering
declaring the current implementation as *the standard*. We will
review input from the community on this matter during Alpha and Beta
release cycles.
implementation is likely the more correct one, we consider the
current implementation as *the standard*. Aside from a conscious
deviation at boundaries (where infinitely sharp creases are now excluded
from the averaging in 3.0 to allow proper decay of a semi-sharp edge
to 0), all other deviations found have been identified as flaws in the
implementation of 2.x (and are not easily corrected).
We will review input from the community on this matter during the Beta
release cycle.
In these cases, features are not being removed but simply re-expressed in what
is hoped to be a clearer interface.
In all cases, features in active use are not being removed but simply
re-expressed in what is hoped to be a clearer interface.
We will welcome feedback and constructive comments as we deploy these changes.
We hope to converge toward a general consensus and lock these APIs by the end
@ -233,20 +246,47 @@ of Beta cycle.
Face-varying Interpolation Rules
********************************
Currently, all 5 of Hbr's legacy modes of face-varying interpolation
are supported (with minor modifications where Hbr has been found to
be incorrect). Additional modes have also been added to allow for
better control around T-junction face-varying topologies.
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.
The new FVarLinearInterpolation enums are:
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.
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.
The new values for the *"FVarLinearInterpolation"* are:
* FVAR_LINEAR_NONE - smooth everywhere ("edge only")
* FVAR_LINEAR_CORNERS_ONLY - sharpen corners only
* FVAR_LINEAR_CORNERS_PLUS1 - ("edge corner")
* FVAR_LINEAR_CORNERS_PLUS2 - ("edge and corner + propagate corner")
* FVAR_LINEAR_BOUNDARIES - sharpen all boundaries ("always sharp")
* FVAR_LINEAR_BOUNDARIES - piecewise linear edges and corners ("always sharp")
* FVAR_LINEAR_ALL - bilinear interpolation ("bilinear") (default)
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
is not affected by changes to other regions that may share the same vertex. So
the behavior of a disjoint region should be well understood and predictable
when looking at it in isolation (e.g. with "corners only" one would expect to
see linear constraints applied where there are topological corners or infinitely
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 are illustrated in more detail elsewhere in the documentation, the tutorials
and the example shapes.
Hierarchical Edits
******************
@ -266,12 +306,6 @@ Our intentions as open-source developers 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 locked and are ready for Beta release.
With the 'Beta' release cycle, we hope to give stake-holders a time-window to
provide feedback on decisions made and changes in the code that may impact
them. Our Beta code is likely not feature-complete yet, but the general
@ -284,39 +318,25 @@ may include bug fixes as well as new features.
.. container:: notebox
**Beta Issues**
The following is a short list of issues or details that we may still have
to change before the master release:
#. Refactor Far::TopologyRefiner interpolation functions:
Templated interpolation methods such as Interpolate<T>(),
InterpolateFaceVarying<T>(), Limit<T>() are not finalized yet. Both
the methods prototypes as well the interface required for **T** are
likely to change before release.
#. Topology entry-point API:
The *advanced* topology entry point interface in
Far::TopologyRefinerFactory is not final yet. Some protected
accessors are likely to be renamed, added or removed before release.
**Beta Features**
The following is a short list of features that hopefully will land before
the master release:
#. Limit Masks:
Currently, Sdc generates weighted masks to interpolate *vertex* and
*face-varying* primvar data between subdivision levels. We want to
add functionality to evaluate closed-form evaluation of weight masks
to interpolate primvar data at the limit.
#. Non-linear Face-varying Patches:
While the fundamental refinement and interpolation of face-varying
data is correct, it has been and remains linearly approximated in
the patches created in Far that are most used for evaluation and
display. We want to update the patch tables to support non-linear
patches for the face-varying data.
#. Implement arbitrary and discrete limit stencils:
Subdivision tables have been replaced with discrete vertex stencils.
We would like to add functionality for stencils to push these
vertices to the limit. This work is contingent on the implementation
of limit masks.
#. Improved Robustness with Non-Manifold Topology:
With the replacement of Hbr with Vtr in 3.0, many non-manifold
topologies can be represented and effectively subdivided. One
situation that was deferred is that of a "degenerate edge", i.e an
edge that has the same vertex at both ends. Plans are to update
the refinement code within Vtr to do something reasonable in these
cases.
----
@ -324,9 +344,10 @@ may include bug fixes as well as new features.
3.x Release Cycle RoadMap
=========================
Within the 3.x release cycle we would like to address many of the issues related
to scaling the application of subdivision surfaces to large amounts of
primitives within typical graphics pipelines.
Within the 3.x release cycle we would like to continue to address many of the
issues related to scaling the application of subdivision surfaces to large amounts
of primitives within typical graphics pipelines, as well as complete other
functionality that has long been missing from evaluation and display.
Enabling workflows at larger scales will require improvements on several fronts:
@ -342,6 +363,15 @@ Enabling workflows at larger scales will require improvements on several fronts:
efficient to allow for complete creative freedom in using the feature.
* Faster topology analysis
As for missing functionality, as the potential standard for evaluation and display
of subdivision surfaces, OpenSubdiv is still lacking in its support of subdivision
schemes other than Catmark -- specifically Loop. Ultimately the same level of
performance and functionality achieved with Catmark should be available for Loop,
which is more effective in dealing with triangle-based meshes. With the refactoring
of the core refinement code in 3.0, much more of the supporting code for the schemes
can be shared so we have already reduced the effort to bring Loop up to par with
Catmark. We hope to take steps in this direction in an upcoming 3.x release.
Release 2.x
===========

19
documentation/roadmap.rst
View File

@ -37,27 +37,10 @@ Roadmap
For more details, please see the `Release Notes <release_notes.html>`_.
3.0 Alpha Releases (Q3 2014):
* complete rewrite of the CPU subdivision core (collaboration with DWA)
* new intermediate topology representation
* new flexible topology front-ends
* clarification of face-varying interpolation rules
* support for non-manifold topology
* large performance gains in topology analysis code
* optimized adaptive isolation of edge creases
* faster evaluation with stencil factorization
* better numerical support around extraordinary vertices
* support for Loop subdivision
* deprecation of hierarchical edits
* deprecation of subdivision tables
3.0 Beta Releases (Q4 2014 / Q1 2015):
3.0 Beta Releases (Q1 2015):
* subdivision 'specification' evaluation from users & community
* implement API for discrete limit evaluation
* support for bi-cubic face-varying interpolation (discrete & limit)
* support for Loop limit evaluation

51
documentation/sdc_overview.rst
View File

@ -45,7 +45,7 @@ The functionality can be divided roughly into three sections:
* types, traits and options for the supported subdivision schemes
* computations required to support semi-sharp creasing
* computing mask weights for subdivided vertices for all schemes
* computations for mask weights of subdivided vertices for all schemes
Overall the approach taken was to extract the functionality at as low a
level as possible. In some cases they are not far from being simple global
@ -59,30 +59,21 @@ set of subdivision schemes that are supported. It is not intended to be
a general framework for defining customized subdivision schemes.
.. container:: notebox
**Beta Issues**
Changes under consideration:
* *<MASK>* face-weights to support face-centers and/or original vertices
* merging *Sdc::TypeTraits<T>* into *Sdc::Scheme<T>* as static methods
* static initialization of creasing constants (for smooth and
infinitely sharp)
* how to document template paremeter interfaces, e.g. *<MASK>*,
*<FACE>*, etc.?
Types, Traits and Options
=========================
The most basic type is the enum *Sdc::Type* that identifies the fixed set of
The most basic type is the enum *Sdc::SchemeType* that identifies the fixed set of
subdivision schemes supported by OpenSubdiv: *Bilinear*, *Catmark* and *Loop*.
With this alone, we intend to avoid all dynamic casting issues related to the
scheme by simply adding members to the associated subclasses for inspection.
In addition to the type enum itself, a class defining a set of
*TypeTraits<Type TYPE>* for each scheme is provided along with the required
specializations for each scheme.
In addition to the type enum itself, a class defining a fixed set of traits
associated with each scheme is provided. While these traits are available as
static methods in the interface of a class supporting more functionality for each
scheme (to be described shortly), the *SchemeTypeTraits* provide queries of the
traits for a variable of type *Sdc::SchemeType* -- enabling parameterization
of code by the value of a trait without templates or virtual inheritance (a
simple internal table of traits is constructed and trivially indexed).
The second contribution is the collection of all variations in one place that can
be applied to the subdivision schemes, i.e. the boundary interpolation rules,
@ -99,6 +90,13 @@ without the need to rewire a lot of interfaces to accomodate the new choice.
Clients can enables new choices at the highest level and be assured that they will
propagate to the lowest level where they are relevant.
Unlike other "options" structs used elsewhere to specify variations of a
particular method, *Sdc::Options* defines all options that affect the shape of
the underlying limit surface of a subdivision mesh. Other operations at higher
levels in the library may have options that approximate the shape and so create
a slightly different appearance, but *Sdc::Options* is a fundamental part of
the definition of the true limit surface.
Creasing support
================
@ -150,16 +148,17 @@ for temporary use.
Scheme-specific support
=======================
While the TypeTraits class provides traits for each subdivision scheme supported
by OpenSubdiv (i.e. *Bilinear*, *Catmark* and *Loop*), the Scheme class
provides methods for computing the various sets of weights used to compute new
While the SchemeTypeTraits class provides traits for each subdivision scheme
supported by OpenSubdiv (i.e. *Bilinear*, *Catmark* and *Loop*), the Scheme class
provides these more directly, along with methods for computing the various sets
of weights used to compute new
vertices resulting from subdivision. The collection of weights used to compute
a single vertex at a new subdivision level is typically referred to as a
*"mask"*. The primary purpose of the Scheme class is to provide such masks in a
manner both general and efficient.
Each subdivision scheme has its own values for its masks, and each are provided
as specializations of the template class *Scheme<Type TYPE>*. The intent is to
as specializations of the template class *Scheme<SchemeType TYPE>*. The intent is to
minimize the amount of code specific to each scheme.
The computation of mask weights for subdivided vertices is the most significant
@ -220,10 +219,8 @@ interior case that often dominates. More on that in the details of the Scheme c
Given that most of the complexity has been moved into the template parameters for
the mask queries, the Scheme class remains fairly simple. Like the Crease class,
it is instantiated with a set of Options to avoid them cluttering the interface.
It is currently little more than three methods for the mask queries for each vertex
type. The set of masks may need to be extended in future to include limit masks
and (potentially) masks for face-varying data sets (whose neighborhoods may vary in
their definition).
It is currently little more than a few methods for the limit and refinement masks
for each vertex type, plus the few fixed traits of the scheme as static methods.
The mask queries have been written in a way that greatly simplifies the
specializations required for each scheme. The generic implementation for both

88
documentation/subdivision_surfaces.rst
View File

@ -106,10 +106,10 @@ This "fan" configuration shows an edge shared by 3 distinct faces.
:target: images/nonmanifold_fan.png
With this configuration, it is unclear which face should contribute to the
limit surface, as 3 of them share the same edge (which incidentally breaks
limit surface, as three of them share the same edge (which incidentally breaks
half-edge cycles in said data-structures). Fan configurations are not limited
to 3 incident faces: any configuration where an edge is shared by more than
2 faces incurs the same problem.
to three incident faces: any configuration where an edge is shared by more than
two faces incurs the same problem.
----
@ -130,11 +130,15 @@ gracefully.
**Beta Issues**
As of 3.0.0 Beta release, support for non-manifold topology is not available
yet. The topology factories are currently set to report warnings when
non-manifold configurations are encountered and implicitly treat them as
sharp boundaries. We intend to fully specify and implement a set of
of interpolation rules in a future release of OpenSubdiv.
As of 3.0.0 Beta release, non-manifold topology has limited support. Most
non-manifold configurations (with the exception of degenerate edges) are
supported for refinement and subdivision. But some factories, such as the
patch tables, do not support them. The interpolation associated with
non-manifold features currently treats them as infinitely sharp features --
smooth rules are possible but exactly what they should be is unclear. We
intend to fully specify and implement a set of interpolation rules in a
future release of OpenSubdiv. Until then the results should be considered
undefined.
----
@ -142,11 +146,7 @@ gracefully.
Boundary Interpolation Rules
============================
Boundary interpolation rules control how boundary face edges and face-varying
data are interpolated.
Vertex Data
***********
Boundary interpolation rules control how boundary edges and vertices are interpolated.
The following rule sets can be applied to vertex data interpolation:
@ -156,13 +156,13 @@ The following rule sets can be applied to vertex data interpolation:
| **VTX_BOUNDARY_NONE** | No boundary interpolation behavior should occur |
| | (debug mode - boundaries are undefined) |
+----------------------------------+----------------------------------------------------------+
| **VTX_BOUNDARY_EDGE_ONLY** | All the boundary edge-chains are sharp creases and |
| | boundary vertices with exactly two incident edges are |
| | sharp corners |
+----------------------------------+----------------------------------------------------------+
| **VTX_BOUNDARY_EDGE_AND_CORNER** | All the boundary edge-chains are sharp creases; boundary |
| **VTX_BOUNDARY_EDGE_ONLY** | All the boundary edge-chains are sharp creases; boundary |
| | vertices are not affected |
+----------------------------------+----------------------------------------------------------+
| **VTX_BOUNDARY_EDGE_AND_CORNER** | All the boundary edge-chains are sharp creases and |
| | boundary vertices with exactly one incident face are |
| | sharp corners |
+----------------------------------+----------------------------------------------------------+
On a quad example:
@ -171,26 +171,37 @@ On a quad example:
:target: images/vertex_boundary.png
Face-varying Data
*****************
----
The following rule sets can be applied to face-varying data interpolation:
Face-Varying Interpolation Rules
================================
+--------------------------------+------------------------------------------+
| Mode | Behavior |
+================================+==========================================+
| **FVAR_LINEAR_NONE** | smooth everywhere ("edge only") |
+--------------------------------+------------------------------------------+
| **FVAR_LINEAR_CORNERS_ONLY** | sharpen corners only |
+--------------------------------+------------------------------------------+
| **FVAR_LINEAR_CORNERS_PLUS1** | "edge corner" |
+--------------------------------+------------------------------------------+
| **FVAR_LINEAR_CORNERS_PLUS2** | "edge and corner" + "propagate corner" |
+--------------------------------+------------------------------------------+
| **FVAR_LINEAR_BOUNDARIES** | sharpen all boundaries ("always sharp") |
+--------------------------------+------------------------------------------+
| **FVAR_LINEAR_ALL** | bilinear interpolation ("bilinear") |
+--------------------------------+------------------------------------------+
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 to the entire interior of the mesh.
The following rules can be applied to face-varying data interpolation:
+--------------------------------+-----------------------------------------------+
| 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 |
+--------------------------------+-----------------------------------------------+
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.
Unwrapped cube example:
@ -198,11 +209,6 @@ Unwrapped cube example:
:align: center
:target: images/fvar_boundaries.png
Propagate Corners
+++++++++++++++++
Face-varying interpolation mode 2 (*EdgeAndCorner*) can further be modified by
the application of the *Propagate Corner* flag.
----

35
documentation/vtr_overview.rst
View File

@ -60,6 +60,13 @@ indexable set (i.e. a vector or array) of vertices, edges and faces. The index
of a component uniquely identifies it and properties are retrieved by referring
to it by index.
It's worth qualifying the term "topological" here and elsewhere -- we generally
refer to "topology" as "subdivision topology" rather than "mesh topology". A
subdivision hierarchy is impacted by the presence of semi-sharp creasing, as
the subdivision rules change in response to that creasing. So subdivision
topology includes the sharpness values assigned to edges and vertices that
affect the semi-sharp creasing.
The two primary classes in *Vtr* consist of:
* `Vtr::Level <#vtrlevel>`__ - a class representing complete vertex topology
@ -74,9 +81,6 @@ Others exist to represent the following:
* mapping between face-varying topology at successive levels
* common low-level utilities, e.g. simple array classes
Contents along with current issues being addressed. More details may be
provided in the headers themselves.
.. container:: notebox
@ -85,10 +89,7 @@ provided in the headers themselves.
Being intended for internal use, any changes to *Vtr* should not impact public
interfaces. Regardless, its worth noting some of the work planned:
* addition of more per-component tags to propogate with refinement
(e.g. holes, etc.)
* encapsulation of any scheme-specific code into classes specific to the
schemes
* improve non-manifold support to handle degenerate edges
* potential nesting of FVar classes within *Level* and *Refinement*
* potential specializations for regular *Levels* and *Refinements*
@ -172,11 +173,22 @@ strictly necessary after the refinement. Just as with construction, whatever
classes are privileged to construct a *Level* are likely those that will be
privileged to prune its contents when needed.
The current implementation of Level is far from optimal though -- there are
opportunities for improvement. After one level of subdivision, the
faces in a Level will be either all quads or tris. Having specializations
for these cases and using the more general case in support of N-sided faces
for the base level only is one possibility. Levels also allocate dozens of
vectors in which to store all data. Since these vectors are of fixed size
once created, they could be aggregated by partitioning one or a smaller
number of larger block of memory into the desired pieces. The desire to
make some of these improvements is part of why Vtr is not directly exposed
for public use and instead exposed via Far.
Vtr::Refinement
===============
While `Vtr::Level <#vtrlevel>`__ contains the topology for a subdivision level,
While `Vtr::Level <#vtrlevel>`__ contains the topology for each subdivision level,
*Vtr::Refinement* is responsible for creating a new level via refinement of an
existing one, and for maintaining the relationships between the components in
the parent and child levels. So a simplified view of a subdivision hierarchy
@ -199,6 +211,13 @@ topological features of interest (creases and extra-ordinary vertices). The
intent is to eventually provide more flexibility to facilitate the refinement
of particular regions of interest or more dynamic/adaptive needs.
*Refinement* has also been subclassed according to the type of topological
split being performed, i.e. splitting all faces into quads or tris via the
*QuadRefinement* and *TriRefinement* subclasses. As noted with *Vtr::Level*,
there is further room for improvement in memory and/or performance here by
combining more optimal specializations for both *Refinement* and *Level* --
with consideration of separating the uniform and sparse cases.
Parent-child and child-parent relationships
*******************************************