Merge pull request #403 from c64kernal/dev_docfixes

Dev docfixes

documentation/far_overview.rst

@@ -274,9 +274,6 @@ with 16, 12, 9 and 4 control vertices respectively.
     that we can eventually get rid of the current re-ordering step applied
     to the control vertex indices.
 
-    We also intend to consolidate all bi-cubic patch types into using 16
-    control vertices, which will deprecate the *Boundary* and *Corner* types.
-
 Patch Transitions
 *****************
 
@@ -330,7 +327,7 @@ created by combining the list of control vertices from the 1-ring.
 With iterative subdivision, each refinement step is dependent upon the previous
 subdivision step being completed, and a substantial number of steps may be
 required in order approximate the limit : each subdivision step incurs an
-O(4:superscript:`n`) growing amount of computations.
+O(4\ :superscript:`n`) growing amount of computations.
 
 Instead, once the weights of the contributing coarse control vertices for a
 given refined vertex have been factorized, it is possible to apply the stencil

documentation/intro.rst

@@ -40,7 +40,7 @@ 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 
+architectures. This code path is optimized for drawing deforming surfaces with 
 static topology at interactive framerates. The resulting limit surfaces are a match
 for Pixar's Renderman specification within numerical precision limits.
 

documentation/osd_overview.rst

@@ -118,8 +118,8 @@ a series of regression tests that compare the methods to each other.
 
    * **Beta Issues**
 
-      Face-varying smooth data interpolation is currently not supported in **Osd**.
-      "Smooth UV" modes of various DCC applications are not supported (yet).
+      Face-varying smooth data interpolation is currently only supported in 
+      **Osd** through refinement and limit points but not in the PatchTables.
 
 ----
 
@@ -146,6 +146,7 @@ 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

documentation/release_notes.rst

@@ -147,7 +147,7 @@ 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 fewer driver overheads. The new stencil
+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).
 
@@ -341,19 +341,19 @@ functionality that has long been missing from evaluation and display.
 
 Enabling workflows at larger scales will require improvements on several fronts:
 
-* Handle more primitives, but with fewer overheads:
+* Handle more primitives, but with less overhead:
 
-    * Reduce Compute kernel launches,which we will achieve using stencils instead
+    * Reduce Compute kernel launches, which we will achieve using stencils instead
       of subdivision tables
     * Reduce Draw calls by addressing the combinatorial explosion of tessellation
       shaders
-    * Provide back-ends for next-gen APIs (D3D12, Mantle, Metal, GL 5.x)
+    * Provide back-ends for next-gen APIs (D3D12, Mantle, Metal, Vulkan, etc.)
 
 * Handle more semi-sharp creases: feature isolation needs to become much more
   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
+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,

documentation/roadmap.rst

@@ -118,7 +118,7 @@ A means to control edge curvature
 ++++++++++++++++++++
 
   Implement Osd::Draw Context & Controllers for next-gen GPU APIs such as
-  Mantle, Metal, DX12, GL Next.
+  Mantle, Metal, DX12, Vulkan.
 
 Regression testing
 ++++++++++++++++++

documentation/sdc_overview.rst

@@ -38,8 +38,8 @@ Subdivision Core (Sdc)
 
 Sdc is the lowest level layer in OpenSubdiv.  Its intent is to separate
 the core subdivision details from any particular representation of a mesh
-(it was previously bound to Hbr) to facilate other classes both internal
-and external to OpenSubdiv generating consistent results.
+(it was previously bound to Hbr) to facilitate the generation of consistent
+results to other mesh representations, both internal and external to OpenSubdiv.
 
 The functionality can be divided roughly into three sections:
 
@@ -86,7 +86,7 @@ into a single object (the equivalent of an integer in this case) that are passed
 around to other Sdc classes and/or methods and are expected to be used at a higher
 level both within OpenSubdiv and externally.  By aggregating the options and
 passing them around as a group, it allows us to extend the set easily in future
-without the need to rewire a lot of interfaces to accomodate the new choice.
+without the need to rewire a lot of interfaces to accommodate 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.
 
@@ -164,7 +164,7 @@ minimize the amount of code specific to each scheme.
 The computation of mask weights for subdivided vertices is the most significant
 contribution of Sdc. The use of semi-sharp creasing with each
 non-linear subdivision scheme complicates what are otherwise simple
-masks detemined solely by the topology, and packaging that functionality to
+masks determined solely by the topology, and packaging that functionality to
 achieve both the generality and efficiency desired has been a challenge.
 
 Mask queries are defined in the *Scheme* class template, which has
@@ -299,10 +299,10 @@ Methods dealing with the collections of weights defining a mask are typically
 parameterized by a *MASK* template parameter that contains the weights.  The set of
 mask weights is currently divided into vertex-weights, edge-weights and
 face-weights -- consistent with previous usage in OpenSubdiv and providing some
-useful correllation between the full set of weights and topology.  The
+useful correlation between the full set of weights and topology.  The
 vertex-weights refer to parent vertices incident the parent component from which a
 vertex originated, the edge-weights the vertices opposite incident edges of the
-parent, and the face-weights the center of indicent parent faces.  Note the latter
+parent, and the face-weights the center of incident parent faces.  Note the latter
 is **NOT** in terms of vertices of the parent but potentially vertices in the child
 originating from faces of the parent.  This has been done historically in
 OpenSubdiv but is finding less use -- particularly when it comes to providing

documentation/subdivision_surfaces.rst

@@ -43,7 +43,7 @@ bicubic patches such as BSplines or NURBS.
 
 However, while they do provide a reliable smooth limit surface definition,
 bi-cubic patch surfaces are limited to 2-dimensional topologies, which only
-describes a very small fraction of real-world shapes. This fundamental
+describe a very small fraction of real-world shapes. This fundamental
 parametric limitation requires authoring tools to implement at least the
 following functionalities:
 
@@ -130,15 +130,13 @@ gracefully.
 
     **Beta Issues**
 
-    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.
+    As of 3.0.0 Beta release, most non-manifold configurations (with the 
+    exception of degenerate edges) are supported for refinement and subdivision.
+    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.
 
 
 ----

documentation/using_osd_compile.rst

@@ -62,5 +62,5 @@ Here are example commands for building an OpenSubdiv application on several arch
     **Note:**
     
     HBR uses the offsetof macro on a templated struct, which appears to spurriously set off a 
-    warning in both gccc and Clang. It is recommended to turn the warning off with the
+    warning in both gcc and Clang. It is recommended to turn the warning off with the
     *-Wno-invalid-offsetof* flag.

documentation/vtr_overview.rst

@@ -82,20 +82,6 @@ Others exist to represent the following:
     * common low-level utilities, e.g. simple array classes
 
 
-.. container:: notebox
-
-    **Beta Issues**
-
-    Being intended for internal use, any changes to *Vtr* should not impact public
-    interfaces.  Regardless, its worth noting some of the work planned:
-
-        * improve non-manifold support to handle degenerate edges
-        * potential nesting of FVar classes within *Level* and *Refinement*
-        * potential specializations for regular *Levels* and *Refinements*
-
-    Priority will be given to satisfying functional needs.
-
-
 Vtr::Level
 ==========