mirror of
https://github.com/PixarAnimationStudios/OpenSubdiv
synced 2024-12-27 02:10:24 +00:00
Reorganized Release Notes
Modified Release Notes to be a brief overview of the 3.0 release features, while moving the descriptive text to a new section that outlines the major changes in 3.0 grouped along with the Porting Guide and Subdivision Compatibility document.
This commit is contained in:
George ElKoura
parent
0e5b504bca
commit
a51456963c
@ -83,6 +83,7 @@ if (DOCUTILS_FOUND AND PYTHONINTERP_FOUND)
|
|||||||
glviewer.rst
|
glviewer.rst
|
||||||
hbr_overview.rst
|
hbr_overview.rst
|
||||||
intro.rst
|
intro.rst
|
||||||
|
intro_30.rst
|
||||||
license.rst
|
license.rst
|
||||||
mod_notes.rst
|
mod_notes.rst
|
||||||
maya_osdpolysmooth.rst
|
maya_osdpolysmooth.rst
|
||||||
|
|||||||
257
documentation/intro_30.rst
Normal file
257
documentation/intro_30.rst
Normal file
@ -0,0 +1,257 @@
|
|||||||
|
..
|
||||||
|
Copyright 2013 Pixar
|
||||||
|
|
||||||
|
Licensed under the Apache License, Version 2.0 (the "Apache License")
|
||||||
|
with the following modification; you may not use this file except in
|
||||||
|
compliance with the Apache License and the following modification to it:
|
||||||
|
Section 6. Trademarks. is deleted and replaced with:
|
||||||
|
|
||||||
|
6. Trademarks. This License does not grant permission to use the trade
|
||||||
|
names, trademarks, service marks, or product names of the Licensor
|
||||||
|
and its affiliates, except as required to comply with Section 4(c) of
|
||||||
|
the License and to reproduce the content of the NOTICE file.
|
||||||
|
|
||||||
|
You may obtain a copy of the Apache License at
|
||||||
|
|
||||||
|
http://www.apache.org/licenses/LICENSE-2.0
|
||||||
|
|
||||||
|
Unless required by applicable law or agreed to in writing, software
|
||||||
|
distributed under the Apache License with the above modification is
|
||||||
|
distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||||
|
KIND, either express or implied. See the Apache License for the specific
|
||||||
|
language governing permissions and limitations under the Apache License.
|
||||||
|
|
||||||
|
|
||||||
|
Introduction to the 3.0 Release
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
.. contents::
|
||||||
|
:local:
|
||||||
|
:backlinks: none
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
Release 3.0
|
||||||
|
===========
|
||||||
|
|
||||||
|
OpenSubdiv 3.0 represents a landmark release, with profound changes to the core
|
||||||
|
algorithms, simplified APIs, and streamlined GPU execution. Providing
|
||||||
|
faster, more efficient, and more flexible subdivision code remains our
|
||||||
|
principal goal. To achieve this, OpenSubdiv 3.0 introduces many
|
||||||
|
improvements that constitute a fairly radical departure from previous
|
||||||
|
versions.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
Improved Performance
|
||||||
|
********************
|
||||||
|
|
||||||
|
Release 3.0.0 of OpenSubdiv introduces a new set of data structures and
|
||||||
|
algorithms that greatly enhance performance over previous versions.
|
||||||
|
|
||||||
|
**Faster Subdivision**
|
||||||
|
|
||||||
|
A major focus of the 3.0 release is performance. It should provide
|
||||||
|
"out-of-the-box" speed-ups close to an order of magnitude for topology refinement
|
||||||
|
and analysis (both uniform and adaptive).
|
||||||
|
|
||||||
|
**Introducing 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 penalties from
|
||||||
|
fences or force additional kernel launches. Most of these dependencies have now
|
||||||
|
been factorized 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, with less driver overhead. The new stencil
|
||||||
|
tables Compute back-end is supported on all the same platforms as previous
|
||||||
|
releases (except GCD).
|
||||||
|
|
||||||
|
**Faster, Simpler GPU Kernels**
|
||||||
|
|
||||||
|
On the GPU side, the replacement of subdivision tables with stencils greatly
|
||||||
|
reduces bottlenecks in compute, yielding as much as a 4x interpolation speed-up.
|
||||||
|
At the same time, stencils reduce the complexity of interpolation to a single
|
||||||
|
kernel launch per primitive, a critical improvement for mobile platforms.
|
||||||
|
|
||||||
|
As a result of these changes, compute batching is now trivial, which in turn
|
||||||
|
enabled API simplifications in the Osd layer.
|
||||||
|
|
||||||
|
**Unified Adaptive Shaders**
|
||||||
|
|
||||||
|
Adaptive tessellation shader configurations have been greatly simplified. The
|
||||||
|
number of shader configurations has been reduced from a combinatorial per-patch
|
||||||
|
explosion down to a constant two global configurations. This massive improvement
|
||||||
|
over the 2.x code base results in significantly faster load times and a reduced
|
||||||
|
per-frame cost for adaptive drawing.
|
||||||
|
|
||||||
|
Similar to compute kernel simplification, this shader simplification has resulted
|
||||||
|
in additional simplifications in the Osd layer.
|
||||||
|
|
||||||
|
**Single Crease Patch**
|
||||||
|
|
||||||
|
OpenSubdiv 3.0 newly implements efficient evaluation of semi-smooth
|
||||||
|
creases(*) using single crease patches. With this optimization,
|
||||||
|
high-order edge sharpness tags can be handled very efficiently for both
|
||||||
|
computation time and memory consumption.
|
||||||
|
|
||||||
|
(*) Niessner et al., Efficient Evaluation of Semi-Smooth Creases in
|
||||||
|
Catmull-Clark Subdivision Surfaces. Eurographics (Short Papers). 2012.
|
||||||
|
|
||||||
|
**New Irregular Patch Approximations**
|
||||||
|
|
||||||
|
While "legacy" Gregory patch support is still available, we have introduced
|
||||||
|
several new options for representing irregular patches: Legacy Gregory, fast
|
||||||
|
Gregory Basis stencils, and BSpline patches. Gregory basis stencils provide
|
||||||
|
the same high quality approximation of Legacy Gregory patches, but execute
|
||||||
|
considerably faster with a simpler GPU representation. While BSpline patches
|
||||||
|
are not as close an approximation as Gregory patches, they enable an entire
|
||||||
|
adaptively refined mesh to be drawn with screen space tessellation via a
|
||||||
|
single global shader configuration (Gregory Basis patches require one
|
||||||
|
additional global shader configuration).
|
||||||
|
|
||||||
|
The new implementations of the GregoryBasis and BSpline approximations relax
|
||||||
|
the previous max valence limit. Users are still encouraged to use models with
|
||||||
|
vertices of low valence for both improved model quality and performance.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
Topological Flexibility
|
||||||
|
***********************
|
||||||
|
|
||||||
|
Given repeated limitations experienced with Hbr as the primary topological
|
||||||
|
entry point, OpenSubdiv 3.0 introduces a new *intermediate* topological
|
||||||
|
representation, named **Vtr** (Vectorized Topology Representation). Vtr is
|
||||||
|
much more efficient for the kinds of topological analysis required by Far
|
||||||
|
and additionally is more flexible. 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.
|
||||||
|
|
||||||
|
Though Vtr is insulated from public access by a topology container in Far (the
|
||||||
|
Far::TopologyRefiner) -- allowing it to be enhanced in future independent of the
|
||||||
|
public API -- documentation for Vtr can be found `here <vtr_overview.html>`__
|
||||||
|
|
||||||
|
**Now Supporting Non-manifold Topology**
|
||||||
|
|
||||||
|
With topology conversion no longer constrained by Hbr, OpenSubdiv is no
|
||||||
|
longer restricted to meshes of manifold topology. With one exception
|
||||||
|
(non-triangles with Loop subdivision), any set of faces and vertices that can
|
||||||
|
be represented in common container formats such as Obj or Alembic can be
|
||||||
|
represented and subdivided. With future efforts to bring the functionality
|
||||||
|
for the Loop scheme up to par with Catmark, that last remaining topological
|
||||||
|
restriction will hopefully be removed.
|
||||||
|
|
||||||
|
**Simpler Conversion of Topology**
|
||||||
|
|
||||||
|
Several entry-points are now available for client topology, rather than the
|
||||||
|
single incremental assembly of an HbrMesh that previously existed. The new
|
||||||
|
topological relationships can be populated using either a high-level interface
|
||||||
|
where simplicity has been emphasized, or a more complex lower-level interface
|
||||||
|
for enhanced efficiency.
|
||||||
|
|
||||||
|
**Face Varying Topology**
|
||||||
|
|
||||||
|
Previously, face-varying data had 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 (indices) to
|
||||||
|
these **vertices** for the corner of each face, face-varying topology is
|
||||||
|
defined from a set of **values** and integer references (indices) to these
|
||||||
|
**values** for the corner 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. Note that the number of **vertices** and
|
||||||
|
**values** will typically differ, but since indices are assigned to the
|
||||||
|
corners of all faces for both, the total number of indices assigned to all
|
||||||
|
faces will be the same.
|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
**No more fixed valence tables**
|
||||||
|
|
||||||
|
All tables that restricted the valence of a vertex to some relatively small
|
||||||
|
table size have now been removed. Limit properties of extra-ordinary vertices
|
||||||
|
are computed for arbitrary valence and new patch types no longer rely on small
|
||||||
|
table sizes.
|
||||||
|
|
||||||
|
The only restriction on valence that exists is within the new topology
|
||||||
|
representation, which restricts it to the size of an unsigned 16-bit integer
|
||||||
|
(65,535). This limit could also be removed, by recompiling with a certain
|
||||||
|
size changed from 16- to 32-bits, but doing so would increase the memory cost
|
||||||
|
for all common cases. We feel the 16-bit limit was a reasonable compromise.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
Subdivision Core (Sdc)
|
||||||
|
**********************
|
||||||
|
|
||||||
|
In consideration of the past (Hbr), present (Vtr) and future representations,
|
||||||
|
all low-level details fundamental to subdivision and the specific subdivision
|
||||||
|
schemes have 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 and
|
||||||
|
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>`__
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
New Source-Code Style
|
||||||
|
*********************
|
||||||
|
|
||||||
|
OpenSubdiv 3.0 replaces naming prefixes with C++ namespaces for all API layers,
|
||||||
|
bringing the source style more in line with contemporary specifications
|
||||||
|
(mostly inspired from the `Google C++ Style Guide
|
||||||
|
<http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml>`__).
|
||||||
|
|
||||||
|
The large-scale changes introduced in this release generally break compatibility
|
||||||
|
with existing client-code. However, this gives us the opportunity to effect
|
||||||
|
some much needed updates to our code-style guidelines and general conventions,
|
||||||
|
throughout the entire OpenSubdiv code-base. We are hoping to drastically
|
||||||
|
improve the quality, consistency and readability of the source code.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
New Tutorials
|
||||||
|
*************
|
||||||
|
|
||||||
|
Documentation has been re-organized and fleshed out (although there is still a
|
||||||
|
lot of work remaining). Because the "code examples" have been generally overly
|
||||||
|
complicated, with this release we are introducing a number of new `tutorials
|
||||||
|
<tutorials.html>`__. We are trying to keep these tutorials as simple as
|
||||||
|
possible, with no external dependencies (although some of them generate OBJ or
|
||||||
|
Maya MEL scripts as a way of visualizing the output). We are planning on releasing
|
||||||
|
more tutorials as time and resources allow.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
Porting Guide
|
||||||
|
*************
|
||||||
|
|
||||||
|
Please see the `Porting Guide <porting.html>`__. for help on how to port
|
||||||
|
existing code written for OpenSubdiv 2.x to the new 3.0 release.
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
Subdivision Compatibility
|
||||||
|
*************************
|
||||||
|
|
||||||
|
The 3.0 release has changed some of the subdivision rules. The list of major
|
||||||
|
changes is outlined in the `Subdivision Compatibility <compatibility.html>`__.
|
||||||
|
document.
|
||||||
@ -41,10 +41,11 @@
|
|||||||
<li><a href="roadmap.html">Roadmap</a></li>
|
<li><a href="roadmap.html">Roadmap</a></li>
|
||||||
</ul>
|
</ul>
|
||||||
<p></p>
|
<p></p>
|
||||||
<li>Porting and Compatibility</li>
|
<li><a href="intro_30.html">Introduction to 3.0</a></li>
|
||||||
<ul>
|
<ul>
|
||||||
|
<li><a href="intro_30.html">Major Changes in 3.0</a></li>
|
||||||
<li><a href="porting.html">Porting Guide: 2.0 to 3.0</a></li>
|
<li><a href="porting.html">Porting Guide: 2.0 to 3.0</a></li>
|
||||||
<li><a href="compatibility.html">Subdivision Compatibility Guide</a></li>
|
<li><a href="compatibility.html">Subdivision Compatibility</a></li>
|
||||||
</ul>
|
</ul>
|
||||||
<p></p>
|
<p></p>
|
||||||
<li><a href="mod_notes.html">Modeling Tips</a>
|
<li><a href="mod_notes.html">Modeling Tips</a>
|
||||||
|
|||||||
@ -22,8 +22,8 @@
|
|||||||
language governing permissions and limitations under the Apache License.
|
language governing permissions and limitations under the Apache License.
|
||||||
|
|
||||||
|
|
||||||
3.0.0 Release Notes
|
3.0 Release Notes
|
||||||
------------------------
|
-----------------
|
||||||
|
|
||||||
.. contents::
|
.. contents::
|
||||||
:local:
|
:local:
|
||||||
@ -31,276 +31,64 @@
|
|||||||
|
|
||||||
----
|
----
|
||||||
|
|
||||||
Release 3.0
|
Release 3.0.0
|
||||||
===========
|
=============
|
||||||
|
|
||||||
OpenSubdiv 3.0 represents a landmark release, with profound changes to the core
|
**New Features**
|
||||||
algorithms, simplified APIs, and streamlined GPU execution. Providing
|
- Faster subdivision using less memory
|
||||||
faster, more efficient, and more flexible subdivision code remains our
|
- Introduction of Stencil Tables
|
||||||
principal goal. To achieve this, OpenSubdiv 3.0 introduces many
|
- Faster, simple GPU kernels
|
||||||
improvements that constitute a fairly radical departure from previous
|
- Unified adaptive shaders
|
||||||
versions.
|
- Single Crease Patch
|
||||||
|
- New Irregular Patch approximations
|
||||||
----
|
- Support for non-manifold topology
|
||||||
|
- Simpler conversion of topology
|
||||||
Improved Performance
|
- Face-Varying topology
|
||||||
********************
|
- Elmination of fixed valence tables
|
||||||
|
- New coding style
|
||||||
Release 3.0.0 of OpenSubdiv introduces a new set of data structures and
|
- More documentation and tutorials
|
||||||
algorithms that greatly enhance performance over previous versions.
|
- For more, information please see `Introduction to 3.0 <intro_30.html>`__
|
||||||
|
|
||||||
**Faster Subdivision**
|
|
||||||
|
Release 3.0.0 RC2
|
||||||
A major focus of the 3.0 release is performance. It should provide
|
=================
|
||||||
"out-of-the-box" speed-ups close to an order of magnitude for topology refinement
|
|
||||||
and analysis (both uniform and adaptive).
|
**New Features**
|
||||||
|
- Documentation updates
|
||||||
**Introducing Stencil Tables**
|
- far_tutorial_3 updates for the multiple face-varying channels
|
||||||
|
- maya example plugin interpolates a UV channel and a vertex color channel
|
||||||
OpenSubdiv 3.0 replaces the serialized subdivision tables with factorized
|
|
||||||
stencil tables. Subdivision tables as implemented in 2.x releases still contain
|
**Bug Fixes**
|
||||||
a fairly large amount of data inter-dependencies, which incur penalties from
|
- Fixed a LimitStencilTableFactory bug, which returns an invalid table
|
||||||
fences or force additional kernel launches. Most of these dependencies have now
|
- PatchParam encoding changed to support refinement levels up to 10
|
||||||
been factorized away in the pre-computation stage, yielding *stencil tables*
|
- Added Xinerama link dependency
|
||||||
instead.
|
- Fixed MSVC 32bit build problem
|
||||||
|
- Fixed minor cmake issues
|
||||||
Stencils remove all data dependencies and simplify all the computations into a
|
- Fixed glViewer/farViewer stability bugs
|
||||||
single trivial kernel. This simplification results in a faster pre-computation
|
|
||||||
stage, faster execution on GPU, with less driver overhead. The new stencil
|
|
||||||
tables Compute back-end is supported on all the same platforms as previous
|
Release 3.0.0 RC1
|
||||||
releases (except GCD).
|
=================
|
||||||
|
|
||||||
**Faster, Simpler GPU Kernels**
|
**Changes**
|
||||||
|
- Far::TopologyRefiner was split into several classes to clarify and focus
|
||||||
On the GPU side, the replacement of subdivision tables with stencils greatly
|
the API. Specifically, all level-related methods were moved to a new
|
||||||
reduces bottlenecks in compute, yielding as much as a 4x interpolation speed-up.
|
class Far::TopologyLevel for inspection of a level in the hierarchy.
|
||||||
At the same time, stencils reduce the complexity of interpolation to a single
|
Similarly, all methods related to client "primvar" data, i.e. the suite
|
||||||
kernel launch per primitive, a critical improvement for mobile platforms.
|
of Interpolate<T>() and Limit<T>() methods, were moved to a new class
|
||||||
|
Far::PrimvarRefiner.
|
||||||
As a result of these changes, compute batching is now trivial, which in turn
|
|
||||||
enabled API simplifications in the Osd layer.
|
- Interpolation of Vertex and Varying primvars in a single pass is no longer
|
||||||
|
supported. As a result, AddVaryingWithWeight() is no longer required and
|
||||||
**Unified Adaptive Shaders**
|
InterpolateVarying() must be called explicitly, which calls
|
||||||
|
AddWithWeight(), instead of AddVaryingWithWeight().
|
||||||
Adaptive tessellation shader configurations have been greatly simplified. The
|
|
||||||
number of shader configurations has been reduced from a combinatorial per-patch
|
- The Osd layer was largely refactored to remove old designs that were
|
||||||
explosion down to a constant two global configurations. This massive improvement
|
originally required to support large numbers of kernel and shader
|
||||||
over the 2.x code base results in significantly faster load times and a reduced
|
configurations (thanks to stencils and unified shading).
|
||||||
per-frame cost for adaptive drawing.
|
|
||||||
|
|
||||||
Similar to compute kernel simplification, this shader simplification has resulted
|
Release 3.0.0 Beta
|
||||||
in additional simplifications in the Osd layer.
|
|
||||||
|
|
||||||
**Single Crease Patch**
|
|
||||||
|
|
||||||
OpenSubdiv 3.0 newly implements efficient evaluation of semi-smooth
|
|
||||||
creases(*) using single crease patches. With this optimization,
|
|
||||||
high-order edge sharpness tags can be handled very efficiently for both
|
|
||||||
computation time and memory consumption.
|
|
||||||
|
|
||||||
(*) Niessner et al., Efficient Evaluation of Semi-Smooth Creases in
|
|
||||||
Catmull-Clark Subdivision Surfaces. Eurographics (Short Papers). 2012.
|
|
||||||
|
|
||||||
**New Irregular Patch Approximations**
|
|
||||||
|
|
||||||
While "legacy" Gregory patch support is still available, we have introduced
|
|
||||||
several new options for representing irregular patches: Legacy Gregory, fast
|
|
||||||
Gregory Basis stencils, and BSpline patches. Gregory basis stencils provide
|
|
||||||
the same high quality approximation of Legacy Gregory patches, but execute
|
|
||||||
considerably faster with a simpler GPU representation. While BSpline patches
|
|
||||||
are not as close an approximation as Gregory patches, they enable an entire
|
|
||||||
adaptively refined mesh to be drawn with screen space tessellation via a
|
|
||||||
single global shader configuration (Gregory Basis patches require one
|
|
||||||
additional global shader configuration).
|
|
||||||
|
|
||||||
The new implementations of the GregoryBasis and BSpline approximations relax
|
|
||||||
the previous max valence limit. Users are still encouraged to use models with
|
|
||||||
vertices of low valence for both improved model quality and performance.
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
Topological Flexibility
|
|
||||||
***********************
|
|
||||||
|
|
||||||
Given repeated limitations experienced with Hbr as the primary topological
|
|
||||||
entry point, OpenSubdiv 3.0 introduces a new *intermediate* topological
|
|
||||||
representation, named **Vtr** (Vectorized Topology Representation). Vtr is
|
|
||||||
much more efficient for the kinds of topological analysis required by Far
|
|
||||||
and additionally is more flexible. 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.
|
|
||||||
|
|
||||||
Though Vtr is insulated from public access by a topology container in Far (the
|
|
||||||
Far::TopologyRefiner) -- allowing it to be enhanced in future independent of the
|
|
||||||
public API -- documentation for Vtr can be found `here <vtr_overview.html>`__
|
|
||||||
|
|
||||||
**Now Supporting Non-manifold Topology**
|
|
||||||
|
|
||||||
With topology conversion no longer constrained by Hbr, OpenSubdiv is no
|
|
||||||
longer restricted to meshes of manifold topology. With one exception
|
|
||||||
(non-triangles with Loop subdivision), any set of faces and vertices that can
|
|
||||||
be represented in common container formats such as Obj or Alembic can be
|
|
||||||
represented and subdivided. With future efforts to bring the functionality
|
|
||||||
for the Loop scheme up to par with Catmark, that last remaining topological
|
|
||||||
restriction will hopefully be removed.
|
|
||||||
|
|
||||||
**Simpler Conversion of Topology**
|
|
||||||
|
|
||||||
Several entry-points are now available for client topology, rather than the
|
|
||||||
single incremental assembly of an HbrMesh that previously existed. The new
|
|
||||||
topological relationships can be populated using either a high-level interface
|
|
||||||
where simplicity has been emphasized, or a more complex lower-level interface
|
|
||||||
for enhanced efficiency.
|
|
||||||
|
|
||||||
**Face Varying Topology**
|
|
||||||
|
|
||||||
Previously, face-varying data had 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 (indices) to
|
|
||||||
these **vertices** for the corner of each face, face-varying topology is
|
|
||||||
defined from a set of **values** and integer references (indices) to these
|
|
||||||
**values** for the corner 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. Note that the number of **vertices** and
|
|
||||||
**values** will typically differ, but since indices are assigned to the
|
|
||||||
corners of all faces for both, the total number of indices assigned to all
|
|
||||||
faces will be the same.
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
**No more fixed valence tables**
|
|
||||||
|
|
||||||
All tables that restricted the valence of a vertex to some relatively small
|
|
||||||
table size have now been removed. Limit properties of extra-ordinary vertices
|
|
||||||
are computed for arbitrary valence and new patch types no longer rely on small
|
|
||||||
table sizes.
|
|
||||||
|
|
||||||
The only restriction on valence that exists is within the new topology
|
|
||||||
representation, which restricts it to the size of an unsigned 16-bit integer
|
|
||||||
(65,535). This limit could also be removed, by recompiling with a certain
|
|
||||||
size changed from 16- to 32-bits, but doing so would increase the memory cost
|
|
||||||
for all common cases. We feel the 16-bit limit was a reasonable compromise.
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
Subdivision Core (Sdc)
|
|
||||||
**********************
|
|
||||||
|
|
||||||
In consideration of the past (Hbr), present (Vtr) and future representations,
|
|
||||||
all low-level details fundamental to subdivision and the specific subdivision
|
|
||||||
schemes have 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 and
|
|
||||||
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>`__
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
New Source-Code Style
|
|
||||||
*********************
|
|
||||||
|
|
||||||
OpenSubdiv 3.0 replaces naming prefixes with C++ namespaces for all API layers,
|
|
||||||
bringing the source style more in line with contemporary specifications
|
|
||||||
(mostly inspired from the `Google C++ Style Guide
|
|
||||||
<http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml>`__).
|
|
||||||
|
|
||||||
The large-scale changes introduced in this release generally break compatibility
|
|
||||||
with existing client-code. However, this gives us the opportunity to effect
|
|
||||||
some much needed updates to our code-style guidelines and general conventions,
|
|
||||||
throughout the entire OpenSubdiv code-base. We are hoping to drastically
|
|
||||||
improve the quality, consistency and readability of the source code.
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
New Tutorials
|
|
||||||
*************
|
|
||||||
|
|
||||||
Documentation has been re-organized and fleshed out (although there is still a
|
|
||||||
lot of work remaining). Because the "code examples" have been generally overly
|
|
||||||
complicated, with this release we are introducing a number of new `tutorials
|
|
||||||
<tutorials.html>`__. We are trying to keep these tutorials as simple as
|
|
||||||
possible, with no external dependencies (although some of them generate OBJ or
|
|
||||||
Maya MEL scripts as a way of visualizing the output). We are planning on releasing
|
|
||||||
more tutorials as time and resources allow.
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
RC2 Release Notes
|
|
||||||
==================
|
|
||||||
|
|
||||||
Release Candidate 2 includes following bug fixes and updates.
|
|
||||||
|
|
||||||
* Documentation updates
|
|
||||||
|
|
||||||
* API fixes
|
|
||||||
|
|
||||||
* Fixed a LimitStencilTableFactory bug, which returns an invalid table
|
|
||||||
|
|
||||||
* PatchParam encoding changed to support refinement levels up to 10
|
|
||||||
|
|
||||||
* Build issue fixes
|
|
||||||
|
|
||||||
* Added Xinerama link dependency
|
|
||||||
|
|
||||||
* Fixed MSVC 32bit build problem
|
|
||||||
|
|
||||||
* Fixed minor cmake issues
|
|
||||||
|
|
||||||
* Examples/Tutorials fixes and updates
|
|
||||||
|
|
||||||
* Fixed glViewer/farViewer stability bugs
|
|
||||||
|
|
||||||
* far_tutorial_3 updates for the multiple face-varying channels
|
|
||||||
|
|
||||||
* maya example plugin interpolates a UV channel and a vertex color channel
|
|
||||||
|
|
||||||
RC1 Release Notes
|
|
||||||
==================
|
|
||||||
|
|
||||||
Release Candidate 1 is a short-lived release intended for stabilization before
|
|
||||||
the official 3.0 release. The APIs are now locked restricted to bug fixes and
|
|
||||||
documentation changes.
|
|
||||||
|
|
||||||
It's been a very active beta cycle and we've received and incorporated great
|
|
||||||
feedback. A larger than expected subset of the API has changed since the beta
|
|
||||||
release, to the overall benefit of the library. These changes lay a strong
|
|
||||||
foundation for future, stable 3.0 point releases.
|
|
||||||
|
|
||||||
Notable API changes in between 3.0-beta and 3.0-RC1 include:
|
|
||||||
|
|
||||||
* Far::TopologyRefiner was split into several classes to clarify and focus
|
|
||||||
the API. Specifically, all level-related methods were moved to a new
|
|
||||||
class Far::TopologyLevel for inspection of a level in the hierarchy.
|
|
||||||
Similarly, all methods related to client "primvar" data, i.e. the suite
|
|
||||||
of Interpolate<T>() and Limit<T>() methods, were moved to a new class
|
|
||||||
Far::PrimvarRefiner.
|
|
||||||
|
|
||||||
* Interpolation of Vertex and Varying primvars in a single pass is no longer
|
|
||||||
supported. As a result, AddVaryingWithWeight() is no longer required and
|
|
||||||
InterpolateVarying() must be called explicitly, which calls AddWithWeight(),
|
|
||||||
instead of AddVaryingWithWeight().
|
|
||||||
|
|
||||||
* The Osd layer was largely refactored to remove old designs that were
|
|
||||||
originally required to support large numbers of kernel and shader
|
|
||||||
configurations (thanks to stencils and unified shading).
|
|
||||||
|
|
||||||
Beta Release Notes
|
|
||||||
==================
|
==================
|
||||||
|
|
||||||
Our intentions as open-source developers is to give as much access to our code,
|
Our intentions as open-source developers is to give as much access to our code,
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user