mirror of
https://github.com/PixarAnimationStudios/OpenSubdiv
synced 2024-11-09 22:00:06 +00:00
manuelk
parent
cd17c87cb1
commit
94fc47a9db
@ -65,14 +65,17 @@ if (DOCUTILS_FOUND AND PYTHONINTERP_FOUND)
|
||||
|
||||
set(RST_FILES
|
||||
api_overview.rst
|
||||
intro.rst
|
||||
cmake_build.rst
|
||||
code_examples.rst
|
||||
dxviewer.rst
|
||||
far_overview.rst
|
||||
getting_started.rst
|
||||
glviewer.rst
|
||||
glbatchviewer.rst
|
||||
hbr_overview.rst
|
||||
intro.rst
|
||||
limiteval.rst
|
||||
osd_overview.rst
|
||||
painttest.rst
|
||||
ptexviewer.rst
|
||||
release_notes.rst
|
||||
|
||||
@ -42,7 +42,7 @@ 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
|
||||
@ -55,7 +55,7 @@ processing costs of any given feature that is not used.
|
||||
----
|
||||
|
||||
Layers
|
||||
******
|
||||
======
|
||||
|
||||
From a top-down point of view, OpenSubdiv is comprised of 3 layers : **Hbr**,
|
||||
**Far** and **Osd**.
|
||||
@ -73,18 +73,6 @@ dependency on either Far or Osd.
|
||||
|
||||
----
|
||||
|
||||
Data and Workflows
|
||||
******************
|
||||
|
||||
Data flows are mostly 1-directional, from top to bottom as a number of algorithms
|
||||
are preparing the coarse mesh data to be refined and passing their results to
|
||||
the next element in the processing chain.
|
||||
|
||||
.. image:: images/api_data_flow.png
|
||||
:align: center
|
||||
|
||||
----
|
||||
|
||||
Representation vs. Implementation Layers
|
||||
****************************************
|
||||
|
||||
@ -103,6 +91,18 @@ layers.
|
||||
|
||||
----
|
||||
|
||||
Data Flows
|
||||
**********
|
||||
|
||||
Data flows are mostly 1-directional, from top to bottom as a number of algorithms
|
||||
are preparing the coarse mesh data to be refined and passing their results to
|
||||
the next element in the processing chain.
|
||||
|
||||
.. image:: images/api_data_flow.png
|
||||
:align: center
|
||||
|
||||
----
|
||||
|
||||
Multiple Representations
|
||||
************************
|
||||
|
||||
@ -141,131 +141,23 @@ be migrated by the device-specific functions in Osd.
|
||||
|
||||
----
|
||||
|
||||
Hierarchical Boundary Representation (Hbr)
|
||||
==========================================
|
||||
Feature Adaptive Subdivision
|
||||
============================
|
||||
|
||||
Hbr is an interconnected topological data representation. The high level of vertex
|
||||
connectivity information makes this representation well suited for creation and
|
||||
editing purposes. It is however inefficient for interactive refinement operations:
|
||||
Separate objects are allocated for each vertex and edge with pointers to neighboring
|
||||
vertices and edges.
|
||||
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.
|
||||
|
||||
Hbr is also the lowest-level subdivision library in Pixar's `Photorealistic RenderMan`.
|
||||
The data paths for the feature adaptive algorithm layered over the OpenSubdiv
|
||||
architecture:
|
||||
|
||||
----
|
||||
|
||||
Half-edge Data Structure
|
||||
************************
|
||||
|
||||
The current implementation is based on a half-edge data structure.
|
||||
|
||||
.. image:: images/half_edge.png
|
||||
:align: center
|
||||
|
||||
----
|
||||
|
||||
Half-edge cycles and Manifold Topology
|
||||
**************************************
|
||||
|
||||
Because half-edges only carry a reference to their opposite half-edge, a given
|
||||
edge can only access a single neighboring edge cycle.
|
||||
|
||||
.. image:: images/half_edge_cycle.png
|
||||
:align: center
|
||||
|
||||
This is a fundamental limitation of the half-edge data structure, in that it
|
||||
cannot represent non-manifold geometry, in particular fan-type topologies. A
|
||||
different approach to topology will probably be necessary in order to accomodate
|
||||
non-manifold geometry.
|
||||
|
||||
----
|
||||
|
||||
Templated Vertex Class
|
||||
**********************
|
||||
|
||||
The vertex class has been abstracted into a set of templated function accesses.
|
||||
Providing Hbr with a template vertex class that does not implement these functions
|
||||
allows client-code to use Hbr as a pure topological analysis tool without having
|
||||
to pay any costs for data interpolation. It also allows client-code to remain in
|
||||
complete control of the layout of the vertex data : interleaved or non-interleaved.
|
||||
|
||||
----
|
||||
|
||||
Feature Adaptive Representation (Far)
|
||||
=====================================
|
||||
|
||||
Far is a serialized topoloigcal data representation.Far uses hbr to create and
|
||||
cache fast run time data structures for table driven subdivision of vertices and
|
||||
cubic patches for limit surface evaluation. `Feature-adaptive <subdivision_surfaces.html#feature-adaptive-subdivision>`__
|
||||
refinement logic is used to adaptively refine coarse topology near features like
|
||||
extraordinary vertices and creases in order to make the topology amenable to
|
||||
cubic patch evaluation. Far is also a generic, templated algorithmic base API
|
||||
that clients in higher levels instantiate and use by providing an implementation
|
||||
of a vertex class. It supports these subdivision schemes:
|
||||
|
||||
----
|
||||
|
||||
OpenSubdiv (Osd)
|
||||
================
|
||||
|
||||
Osd contains client-level code that uses Far to create concrete instances of
|
||||
meshes. These meshes use precomputed tables from hbr to perform table-driven
|
||||
subdivision steps with a variety of massively parallel computational backend
|
||||
technologies. Osd supports both `uniform subdivision <subdivision_surfaces.html#uniform-subdivision>`
|
||||
and adaptive refinement with cubic patches. With uniform subdivision the
|
||||
computational backend code performs Catmull/Clark splitting and averaging on
|
||||
each face. With adaptive subdivision the Catmull/Clark steps are used to compute
|
||||
the CVs of cubic patches, then the cubic patches are tessellated on with GLSL or DirectX.
|
||||
|
||||
OpenSubdiv enforces the same results for the different computation backends with
|
||||
a series of regression tests that compare the methods to each other.
|
||||
|
||||
The OpenSubdiv layer is comprised of 3 maine modules : Refine, Draw and Eval.
|
||||
|
||||
.. image:: images/api_osd_modules.png
|
||||
|
||||
These modules are identified by their name spaces (**OsdRefine**, **OsdDraw**,
|
||||
**OsdEval**) and encapsulate atomic functationality. The vertex data is carried
|
||||
in interoperable buffers that can be exchanged between modules.
|
||||
|
||||
The typical use pattern is to pose the coarse vertices of a mesh for a given frame.
|
||||
The buffer is submitted to the **Refine** module which applies the subdivision rules
|
||||
and produces refined control vertices. This new buffer can be passed to the **Draw**
|
||||
module which will put them on screen.
|
||||
|
||||
However, the same buffer of refined control vertices could be passed instead to
|
||||
the **Eval** module (and be projected onto another surface for instance) before
|
||||
being sent for display to the **Draw** module.
|
||||
|
||||
.. container:: impnotip
|
||||
|
||||
* **Important**
|
||||
|
||||
Face-varying smooth data interpolation is currently not supported in Osd.
|
||||
"Smooth UV" modes of various DCC applications are not supported (yet).
|
||||
|
||||
----
|
||||
|
||||
OsdRefine
|
||||
*********
|
||||
|
||||
The Refine module contains the code paths that manage the application of the
|
||||
subdivision rules to the vertex data.
|
||||
|
||||
----
|
||||
|
||||
OsdDraw
|
||||
*******
|
||||
|
||||
The Draw module manages interactions with discrete display devices and provide
|
||||
support for interactive drawing of the subdivision surfaces.
|
||||
|
||||
----
|
||||
|
||||
OsdEval
|
||||
*******
|
||||
|
||||
The Eval module provides computational APIs for the evaluation of vertex data at
|
||||
the limit, ray intersection and point projection.
|
||||
.. image:: images/osd_layers.png
|
||||
|
||||
Hbr serves both as an advanced topological description and the custodian of the
|
||||
Catmull-Clark (and Loop) subdivision rules. Far is then 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.
|
||||
|
||||
@ -69,16 +69,18 @@ ________
|
||||
Optional
|
||||
________
|
||||
|
||||
- `GLEW <http://glew.sourceforge.net/>`__ (Windows/Linux only)
|
||||
- `CUDA <http://www.nvidia.com/object/cuda_home_new.html>`__
|
||||
- `OpenCL <http://www.khronos.org/opencl/>`__
|
||||
- `GLFW <https://github.com/glfw/glfw>`__ (required for standalone examples
|
||||
and some regression tests)
|
||||
- `Ptex <http://ptex.us/>`__ (support features for ptex textures and the
|
||||
ptexViewer example)
|
||||
- `Zlib <http://www.zlib.net/>`__ (required for Ptex under Windows)
|
||||
- `GLEW <http://glew.sourceforge.net/>`__ (Windows/Linux only)
|
||||
- `CUDA <http://www.nvidia.com/object/cuda_home_new.html>`__
|
||||
- `OpenCL <http://www.khronos.org/opencl/>`__
|
||||
- `DX11 SDK <http://www.microsoft.com/>`__
|
||||
- `Docutils <http://docutils.sourceforge.net/>`__
|
||||
- `GLFW <https://github.com/glfw/glfw>`__ (required for standalone examples
|
||||
and some regression tests)
|
||||
- `Docutils <http://docutils.sourceforge.net/>`__ (required for reST-based documentation)
|
||||
- `Python Pygments <http://www.pygments.org/>`__ (required for Docutils reST styling)
|
||||
- `Doxygen <www.doxygen.org/>`__
|
||||
|
||||
----
|
||||
|
||||
|
||||
Binary file not shown.
52
documentation/far_overview.rst
Normal file
52
documentation/far_overview.rst
Normal file
@ -0,0 +1,52 @@
|
||||
..
|
||||
Copyright 2013 Pixar
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License
|
||||
and the following modification to it: Section 6 Trademarks.
|
||||
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 for reproducing
|
||||
the content of the NOTICE file.
|
||||
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
|
||||
either express or implied. See the License for the specific
|
||||
language governing permissions and limitations under the
|
||||
License.
|
||||
|
||||
|
||||
FAR Overview
|
||||
------------
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:backlinks: none
|
||||
|
||||
Feature Adaptive Representation (Far)
|
||||
=====================================
|
||||
|
||||
Far is a serialized topoloigcal data representation.Far uses hbr to create and
|
||||
cache fast run time data structures for table driven subdivision of vertices and
|
||||
cubic patches for limit surface evaluation. `Feature-adaptive <subdivision_surfaces.html#feature-adaptive-subdivision>`__
|
||||
refinement logic is used to adaptively refine coarse topology near features like
|
||||
extraordinary vertices and creases in order to make the topology amenable to
|
||||
cubic patch evaluation. Far is also a generic, templated algorithmic base API
|
||||
that clients in higher levels instantiate and use by providing an implementation
|
||||
of a vertex class. It supports these subdivision schemes:
|
||||
|
||||
Factories & Tables
|
||||
==================
|
||||
|
||||
Subdivision Tables
|
||||
==================
|
||||
|
||||
Patch Tables
|
||||
============
|
||||
@ -66,7 +66,7 @@ need to create a free Github account and clone a fork of the OpenSubdiv reposito
|
||||
|
||||
Submissions to the main code trunk can be sent using Git's pull-request mechanisms.
|
||||
Please note that we are using the git flow tools so all changes should be made to
|
||||
our 'dev' branch. Before we can accept submissions however, we will need a signed
|
||||
our *dev* branch. Before we can accept submissions however, we will need a signed
|
||||
`Contributor's License Agreement <intro.html#contributing>`__.
|
||||
|
||||
----
|
||||
@ -77,7 +77,7 @@ Branches & Git Flow
|
||||
Since version 1.1.0, OpenSubdiv has adopted the `Git Flow
|
||||
<http://nvie.com/posts/a-successful-git-branching-model/>`__ branching model .
|
||||
|
||||
Our active development branch is named 'dev' : all new features and buf fixes should
|
||||
Our active development branch is named *dev* : all new features and buf fixes should
|
||||
be submitted to this branch. The changes submitted to the dev branch are periodically
|
||||
patched to the 'master' branch as new versions are released.
|
||||
|
||||
@ -86,8 +86,8 @@ _____________________
|
||||
|
||||
The Git Flow `tools <https://github.com/nvie/gitflow>`__ are not a requisite for
|
||||
working with the OpenSubdiv code base, but new work should always be performed in
|
||||
the 'dev' branch, or dedicated feature-branches. By default, a cloned repository
|
||||
will be pointing to the 'master' branch. You can switch to the 'dev' branch using
|
||||
the *dev* branch, or dedicated feature-branches. By default, a cloned repository
|
||||
will be pointing to the 'master' branch. You can switch to the *dev* branch using
|
||||
the following command:
|
||||
|
||||
.. code:: c++
|
||||
@ -134,7 +134,7 @@ ______________
|
||||
Direct push access to the OpenSubdiv master repository is currently limited to a
|
||||
small internal development team, so external submissions should be made by sending
|
||||
`pull-requests <https://help.github.com/articles/using-pull-requests>`__ from
|
||||
forks of our 'dev' branch.
|
||||
forks of our *dev* branch.
|
||||
|
||||
----
|
||||
|
||||
|
||||
99
documentation/hbr_overview.rst
Normal file
99
documentation/hbr_overview.rst
Normal file
@ -0,0 +1,99 @@
|
||||
..
|
||||
Copyright 2013 Pixar
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License
|
||||
and the following modification to it: Section 6 Trademarks.
|
||||
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 for reproducing
|
||||
the content of the NOTICE file.
|
||||
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
|
||||
either express or implied. See the License for the specific
|
||||
language governing permissions and limitations under the
|
||||
License.
|
||||
|
||||
|
||||
HBR Overview
|
||||
------------
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:backlinks: none
|
||||
|
||||
|
||||
Hierarchical Boundary Representation (Hbr)
|
||||
==========================================
|
||||
|
||||
Hbr is an interconnected topological data representation. The high level of vertex
|
||||
connectivity information makes this representation well suited for creation and
|
||||
editing purposes. It is however inefficient for interactive refinement operations:
|
||||
Separate objects are allocated for each vertex and edge with pointers to neighboring
|
||||
vertices and edges.
|
||||
|
||||
Hbr is also the lowest-level subdivision library in Pixar's `Photorealistic RenderMan`.
|
||||
|
||||
----
|
||||
|
||||
Half-edge Data Structure
|
||||
========================
|
||||
|
||||
The current implementation is based on a half-edge data structure.
|
||||
|
||||
.. image:: images/half_edge.png
|
||||
:align: center
|
||||
|
||||
----
|
||||
|
||||
Half-edge cycles and Manifold Topology
|
||||
======================================
|
||||
|
||||
Because half-edges only carry a reference to their opposite half-edge, a given
|
||||
edge can only access a single neighboring edge cycle.
|
||||
|
||||
.. image:: images/half_edge_cycle.png
|
||||
:align: center
|
||||
|
||||
This is a fundamental limitation of the half-edge data structure, in that it
|
||||
cannot represent non-manifold geometry, in particular fan-type topologies. A
|
||||
different approach to topology will probably be necessary in order to accomodate
|
||||
non-manifold geometry.
|
||||
|
||||
----
|
||||
|
||||
Templated Vertex Class
|
||||
======================
|
||||
|
||||
The vertex class has been abstracted into a set of templated function accesses.
|
||||
Providing Hbr with a template vertex class that does not implement these functions
|
||||
allows client-code to use Hbr as a pure topological analysis tool without having
|
||||
to pay any costs for data interpolation. It also allows client-code to remain in
|
||||
complete control of the layout of the vertex data : interleaved or non-interleaved.
|
||||
|
||||
----
|
||||
|
||||
Boundary Interpolation Rules
|
||||
============================
|
||||
|
||||
**Hbr** recognizes 4 rule-sets of boundary interpolation:
|
||||
|
||||
+------------------------------------+
|
||||
| Interpolation Rule-Sets |
|
||||
+====================================+
|
||||
| k_InterpolateBoundaryNone |
|
||||
+------------------------------------+
|
||||
| k_InterpolateBoundaryEdgeOnly |
|
||||
+------------------------------------+
|
||||
| k_InterpolateBoundaryEdgeAndCorner |
|
||||
+------------------------------------+
|
||||
| k_InterpolateBoundaryAlwaysSharp |
|
||||
+------------------------------------+
|
||||
BIN
documentation/images/osd_backends.png
Normal file
BIN
documentation/images/osd_backends.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
BIN
documentation/images/osd_context_controller.png
Normal file
BIN
documentation/images/osd_context_controller.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
BIN
documentation/images/osd_controllers.png
Normal file
BIN
documentation/images/osd_controllers.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
documentation/images/osd_controllers_example0.png
Normal file
BIN
documentation/images/osd_controllers_example0.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
documentation/images/osd_controllers_example1.png
Normal file
BIN
documentation/images/osd_controllers_example1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
documentation/images/osd_layers.png
Normal file
BIN
documentation/images/osd_layers.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
documentation/images/osd_modules.png
Normal file
BIN
documentation/images/osd_modules.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
@ -42,11 +42,11 @@ Introduction
|
||||
OpenSubdiv is a set of open source libraries that implement high performance
|
||||
subdivision surface (subdiv) evaluation on massively parallel CPU and GPU
|
||||
architectures. This codepath is optimized for drawing deforming surfaces with
|
||||
static topology at interactive framerates. The resulting limit surface are a match
|
||||
static topology at interactive framerates. The resulting limit surfaces are a match
|
||||
for Pixar's Renderman specification within numerical precision limits.
|
||||
|
||||
OpenSubdiv is a code API which we hope to integrate into 3rd. party digital
|
||||
content creation tools. It is **not** an application nor a tool that can be used
|
||||
content creation tools. It is **not** an application, nor a tool that can be used
|
||||
directly to create digital assets.
|
||||
|
||||
----
|
||||
@ -67,8 +67,8 @@ approximation errors to be magnified.
|
||||
|
||||
Maya and Pixar's proprietary Presto animation system can take 100ms to subdivide
|
||||
a character of 30,000 polygons to the second level of subdivision (500,000 polygons).
|
||||
By doing the same thing in 3ms, OpenSubdiv allows the user to see the smooth,
|
||||
accurate limit surface at all times.
|
||||
Being able to perform the same operation in less than 3ms allows the user to interact
|
||||
with the smooth, accurate limit surface at all times.
|
||||
|
||||
.. image:: images/efficient_subdivision.png
|
||||
:height: 400px
|
||||
|
||||
@ -43,14 +43,15 @@
|
||||
<li><a href="subdivision_surfaces.html#manifold-geometry">Topology</a></li>
|
||||
<li><a href="subdivision_surfaces.html#semi-sharp-creases">Semi-Sharp Creases</a></li>
|
||||
<li><a href="subdivision_surfaces.html#hierarchical-edits">Hierarchical Edits</a></li>
|
||||
<li><a href="subdivision_surfaces.html#uniform-subdivision">Uniform</a></li>
|
||||
<li><a href="subdivision_surfaces.html#feature-adaptive-subdivision">Feature Adaptive</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="api_overview.html">APIs Overview</a>
|
||||
<ul>
|
||||
<li><a href="api_overview.html#architecture">Architecture</a></li>
|
||||
<li><a href="api_overview.html#hierarchical-boundary-representation-hbr">Hbr</a></li>
|
||||
<li><a href="api_overview.html#feature-adaptive-representation-far">Far</a></li>
|
||||
<li><a href="api_overview.html#opensubdiv-osd">Osd</a></li>
|
||||
<li><a href="hbr_overview.html">Hbr</a></li>
|
||||
<li><a href="far_overview.html">Far</a></li>
|
||||
<li><a href="osd_overview.html">Osd</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="using_osd.html">Using OpenSubdiv</a>
|
||||
|
||||
204
documentation/osd_overview.rst
Normal file
204
documentation/osd_overview.rst
Normal file
@ -0,0 +1,204 @@
|
||||
..
|
||||
Copyright 2013 Pixar
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License
|
||||
and the following modification to it: Section 6 Trademarks.
|
||||
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 for reproducing
|
||||
the content of the NOTICE file.
|
||||
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing,
|
||||
software distributed under the License is distributed on an
|
||||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
|
||||
either express or implied. See the License for the specific
|
||||
language governing permissions and limitations under the
|
||||
License.
|
||||
|
||||
|
||||
OSD Overview
|
||||
------------
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:backlinks: none
|
||||
|
||||
OpenSubdiv (Osd)
|
||||
================
|
||||
|
||||
**Osd** contains client-level code that uses *Far* to create concrete instances of
|
||||
meshes. These meshes use precomputed tables from *Hbr* to perform table-driven
|
||||
subdivision steps with a variety of massively parallel computational backend
|
||||
technologies. **Osd** supports both `uniform subdivision <subdivision_surfaces.html#uniform-subdivision>`__
|
||||
and `adaptive refinement <subdivision_surfaces.html#feature-adaptive-subdivision>`__
|
||||
with cubic patches.
|
||||
|
||||
----
|
||||
|
||||
Modular Architecture
|
||||
====================
|
||||
|
||||
With uniform subdivision the computational backend code performs Catmull-Clark
|
||||
splitting and averaging on each face.
|
||||
|
||||
With adaptive subdivision, the Catmull/Clark steps are used to compute the CVs
|
||||
of cubic Bezier patches. On modern GPU architectures, bicubic patches can be
|
||||
drawn directly on screen at very high resolution using optimized tessellation
|
||||
shader paths.
|
||||
|
||||
.. image:: images/osd_layers.png
|
||||
|
||||
Finally, the general manipulation of high-order surfaces also requires functionality
|
||||
outside of the scope of pure drawing.
|
||||
|
||||
Following this pattern of general use, **Osd** can be broken down into 3 main
|
||||
modules : **Compute**, **Draw** and **Eval**.
|
||||
|
||||
.. image:: images/osd_modules.png
|
||||
:align: center
|
||||
|
||||
The modules are designed so that the data being manipulated can be shared and
|
||||
interoperated between modules (although not all paths are possible).
|
||||
|
||||
These modules are identified by their name spaces (**OsdRefine**, **OsdDraw**,
|
||||
**OsdEval**) and encapsulate atomic functationality. The vertex data is carried
|
||||
in interoperable buffers that can be exchanged between modules.
|
||||
|
||||
The typical use pattern is to pose the coarse vertices of a mesh for a given frame.
|
||||
The buffer is submitted to the **Refine** module which applies the subdivision rules
|
||||
and produces refined control vertices. This new buffer can be passed to the **Draw**
|
||||
module which will draw them on screen.
|
||||
|
||||
However, the same buffer of refined control vertices could be passed instead to
|
||||
the **Eval** module (and be projected onto another surface for instance) before
|
||||
being sent for display to the **Draw** module.
|
||||
|
||||
----
|
||||
|
||||
OsdCompute
|
||||
**********
|
||||
|
||||
The Compute module contains the code paths that manage the application of the
|
||||
subdivision rules to the vertex data. This module is sufficient for uniform
|
||||
subdivision applications.
|
||||
|
||||
----
|
||||
|
||||
OsdDraw
|
||||
*******
|
||||
|
||||
The Draw module manages interactions with discrete display devices and provide
|
||||
support for interactive drawing of the subdivision surfaces.
|
||||
|
||||
----
|
||||
|
||||
OsdEval
|
||||
*******
|
||||
|
||||
The Eval module provides computational APIs for the evaluation of vertex data at
|
||||
the limit, ray intersection and point projection.
|
||||
|
||||
|
||||
OpenSubdiv enforces the same results for the different computation backends with
|
||||
a series of regression tests that compare the methods to each other.
|
||||
|
||||
|
||||
|
||||
.. container:: impnotip
|
||||
|
||||
* **Important**
|
||||
|
||||
Face-varying smooth data interpolation is currently not supported in **Osd**.
|
||||
"Smooth UV" modes of various DCC applications are not supported (yet).
|
||||
|
||||
----
|
||||
|
||||
Cross-Platform Implementation
|
||||
=============================
|
||||
|
||||
One of the key goals of OpenSubdiv is to achieve as much cross-platform flexibility
|
||||
as possible and leverage all optimized hardware paths where available. This can
|
||||
be very challenging however, as there is a very large variety of plaftorms and
|
||||
matching APIs available, with very distinct capabilities. The following chart
|
||||
illustrates the matrix of back-end APIs supported for each module.
|
||||
|
||||
.. image:: images/osd_backends.png
|
||||
:align: center
|
||||
|
||||
Since the **Compute** module performs mostly specialized interpolation computations,
|
||||
most GP-GPU and multi-core APIs can be deployed. If the end-goal is to draw the
|
||||
surface on screen, it can be very beneficial to move as much of these computations
|
||||
to the same GPU device in order to minimize data transfers.
|
||||
|
||||
For instance: pairing a CUDA **Compute** back-end to an OpenGL **Draw** backend
|
||||
could be a good choice on hardware and OS that supports both. Similarly, a
|
||||
DX11 HLSL-Compute **Compute** back-end can be paired effectively with a DX11
|
||||
HLSL-Shading **Draw** back-end. Some pairings however are not possible, as there
|
||||
may be no data inter-operation paths available (ex: transferring DX11 compute SRVs
|
||||
to GL texture buffers).
|
||||
|
||||
----
|
||||
|
||||
Contexts & Controllers
|
||||
======================
|
||||
|
||||
At the core of **Osd** modularization is the need for inter-operating vertex buffer
|
||||
data between different APIs. This is achieved through a *"binding"* mechanism.
|
||||
|
||||
Binding Vertex Buffers
|
||||
**********************
|
||||
|
||||
Each back-end manages data of 2 types: specific to each primitive manipulated
|
||||
(topology, vertex data...), and general state data that is shared by all the
|
||||
primitives (compute kernels, device ID...). The first type is contained in a
|
||||
"Context" object, the latter manipulated through a singleton "Controller".
|
||||
|
||||
.. image:: images/osd_context_controller.png
|
||||
:align: center
|
||||
|
||||
The Context itself holds the data that is specific to both the primitive and
|
||||
the operation that needs to be appled (ex: *"drawing"*). It also owns multiple
|
||||
buffers of vertex data. Contexts and Controller each have a specific back-end
|
||||
API, so only matching back-ends can be paired (ex: an OpenCL Context cannot be
|
||||
paired with a CUDA Controller).
|
||||
|
||||
Vertex Buffer Inter-Op
|
||||
**********************
|
||||
|
||||
When a Controller needs to perform an operation, it *"binds"* the Context, which
|
||||
is the trigger to move the vertex data into the appropriate device memory pool
|
||||
(CPU to GPU, GPU to GPU...).
|
||||
|
||||
.. image:: images/osd_controllers.png
|
||||
:align: center
|
||||
|
||||
|
||||
In practice, a given application will maintain singletons of the controllers for
|
||||
each of the modules that it uses, and pair them with the Contexts associated with
|
||||
each primitive. A given primitive will use one Context for each of the modules that
|
||||
it uses.
|
||||
|
||||
Example
|
||||
*******
|
||||
|
||||
Here is an example of client code implementation for drawing surfaces using a
|
||||
CUDA **Compute** module and an OpenGL **Draw** module.
|
||||
|
||||
.. image:: images/osd_controllers_example1.png
|
||||
:align: center
|
||||
|
||||
The client code will construct an OsdCudaComputeController and OsdCudaComputeContext
|
||||
for the **Compute** stage, along with an OsdGLDrawController and an OsdGLDrawContext.
|
||||
|
||||
The critical components are the vertex buffers, which must be of type OsdCudaGLVertexBuffer.
|
||||
The Contexts and Controllers classes all are specializations of a templated *"Bind"*
|
||||
function which will leverage API specific code responsible for the inter-operation
|
||||
of the data between the API-specific back-ends.
|
||||
|
||||
@ -47,8 +47,8 @@ patch surfaces are limited to 2-dimensional topologies, which only describes a
|
||||
very small fraction of real-world shapes. This fundamental parametric limitation
|
||||
requires authoring tools to implementat at least the following functionalities:
|
||||
|
||||
1. smooth trimming
|
||||
2. seams stitching
|
||||
- smooth trimming
|
||||
- seams stitching
|
||||
|
||||
Both trimming and stitching need to guarantee the smoothness of the model both
|
||||
spatially and temporally as the model is animated. Attempting to meet these
|
||||
@ -90,12 +90,13 @@ Manifold Geometry
|
||||
|
||||
Continuous limit surfaces require that the topology be a two-dimensional
|
||||
manifold. It is therefore possible to model non-manifold geometry that cannot
|
||||
be subdivided to a smooth limit.
|
||||
be represented with a smooth C2 continuous limit. The following examples show
|
||||
typical cases of non-manifold topological configurations.
|
||||
|
||||
----
|
||||
|
||||
Fan
|
||||
+++
|
||||
Non-Manifold Fan
|
||||
++++++++++++++++
|
||||
|
||||
This "fan" configuration shows an edge shared by 3 distinct faces.
|
||||
|
||||
@ -103,10 +104,16 @@ This "fan" configuration shows an edge shared by 3 distinct faces.
|
||||
:align: center
|
||||
: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
|
||||
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.
|
||||
|
||||
----
|
||||
|
||||
Disconnected Vertex
|
||||
+++++++++++++++++++
|
||||
Non-Manifold Disconnected Vertex
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
A vertex is disconnected from any edge and face.
|
||||
|
||||
@ -114,25 +121,65 @@ A vertex is disconnected from any edge and face.
|
||||
:align: center
|
||||
:target: images/nonmanifold_vert.png
|
||||
|
||||
This case is fairly trivial: there is no possible way to exact a limit surface here,
|
||||
so the vertex simply has to be flagged as non-contributing, or discarded gracefully.
|
||||
|
||||
----
|
||||
|
||||
Boundary Interpolation Rules
|
||||
============================
|
||||
|
||||
XXXX
|
||||
These rules control how boundary edges are interpolated. 4 rule-sets can be applied to
|
||||
vertex, varying and face-varying data:
|
||||
|
||||
**None**
|
||||
|
||||
Debug mode, boundary edges are "undefined"
|
||||
|
||||
**EdgeOnly**
|
||||
|
||||
No boundary interpolation behavior should occur
|
||||
|
||||
**EdgeAndCorner**
|
||||
|
||||
All the boundary edge-chains are sharp creases and that boundary
|
||||
vertices with exactly two incident edges are sharp corners
|
||||
|
||||
**AlwaysSharp**
|
||||
|
||||
All the boundary edge-chains are sharp creases; boundary vertices
|
||||
are not affected
|
||||
|
||||
|
||||
----
|
||||
|
||||
Semi-Sharp Creases
|
||||
==================
|
||||
|
||||
It is possible to modify the subdivision rules to create piecewise smooth surfaces
|
||||
containing infinitely sharp features such as creases and corners. As a special
|
||||
case, surfaces can be made to interpolate their boundaries by tagging their boundary
|
||||
edges as sharp.
|
||||
|
||||
However, we've recognized that real world surfaces never really have infinitely
|
||||
sharp edges, especially when viewed sufficiently close. To this end, we've added
|
||||
the notion of semi-sharp creases, i.e. rounded creases of controllable sharpness.
|
||||
These allow you to create features that are more akin to fillets and blends. As
|
||||
you tag edges and edge chains as creases, you also supply a sharpness value that
|
||||
ranges from 0-10, with sharpness values >=10 treated as infinitely sharp.
|
||||
|
||||
It should be noted that infinitely sharp creases are really tangent discontinuities
|
||||
in the surface, implying that the geometric normals are also discontinuous there.
|
||||
Therefore, displacing along the normal will likely tear apart the surface along
|
||||
the crease. If you really want to displace a surface at a crease, it may be better
|
||||
to make the crease semi-sharp.
|
||||
|
||||
|
||||
.. image:: images/gtruck.jpg
|
||||
:align: center
|
||||
:height: 300
|
||||
:target: images/gtruck.jpg
|
||||
|
||||
XXXX
|
||||
|
||||
----
|
||||
|
||||
Hierarchical Edits
|
||||
|
||||
@ -37,6 +37,15 @@ Using OpenSubdiv
|
||||
Using OpenSubdiv
|
||||
================
|
||||
|
||||
.. list-table:: **OpenGL examples**
|
||||
:class: quickref
|
||||
:widths: 50 50
|
||||
|
||||
* - | `Compiling & Linking <using_osd_compile.html>`_
|
||||
| `Textures <using_osd_textures.html>`_
|
||||
- | `Manipulating Topology <using_osd_hbr.html>`_
|
||||
|
||||
|
|
||||
|
||||
|
||||
|
||||
|
||||
@ -288,21 +288,6 @@ remaining to validate the mesh:
|
||||
Boundary Interpolation Rules
|
||||
============================
|
||||
|
||||
**Hbr** recognizes 4 rule-sets of boundary interpolation:
|
||||
|
||||
+------------------------------------+
|
||||
| Interpolation Rule-Sets |
|
||||
+====================================+
|
||||
| k_InterpolateBoundaryNone |
|
||||
+------------------------------------+
|
||||
| k_InterpolateBoundaryEdgeOnly |
|
||||
+------------------------------------+
|
||||
| k_InterpolateBoundaryEdgeAndCorner |
|
||||
+------------------------------------+
|
||||
| k_InterpolateBoundaryAlwaysSharp |
|
||||
+------------------------------------+
|
||||
|
||||
|
||||
The rule-set can be selected using the following accessors:
|
||||
|
||||
*Vertex* and *varying* data:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user