Sync'ing the 'dev' branch with the 'feature_3.0dev' branch at commit 68c6d11fc36761ae1a5e6cdc3457be16f2e9704a
The branch 'feature_3.0dev' is now locked and preserved for historical purposes.
* assembler kernels are based on the C implementation in neonKernel.cpp
* enable assembler kernel functions in neonComputeController.cpp with #define USE_ASM_KERNELS 1
* added public functions to `FarMeshFactory` that duplicate, rearrange, and split vertices
* added supporting protected functions to `FarCatmarkSubdivisionTablesFactory` and `FarPatchTablesFactory`
This makes it possible to use use bilinear subdivisions which
corresponds to Blender's simple subdivisions.
Most of the changes doesn't break any existing API because of
using default values. it's only C-API function which now expects
an extra argument.
This doesn't entirely work because it uses adaptive evaluator
which gives some unwanted curvatures when using bilinear scheme.
Basically title says it all, now it's possible to pass
subdivision scheme to the OsdUtilMesh::Initialize().
It's a last argument with default to CATMARK so it doesn't
break existing code.
Unused argument `pass` was defined in the CUDA kernel and it was never
passed to this function from the C++ code. This argument is also wasn't
used by the function itself.
Solved by checking on run-time whether texture buffer objects
are supported.
When building with GLEW library doing compile-time check is
not enough, because actual information about existing features
is only known on runtime.
This only makes ti so CPU backend works, GLSL backends still
requires some work if we want them to make working. Not sure
it worth doing this now.
* added `OsdMeshInterface::GetFarMesh` and `OsdMesh::GetFarMesh` to match `OsdGLMesh` and `OsdD3D11Mesh`
* added `interleaved` argument to `OsdMesh::Refine` to match `OsdMeshInterface::Refine`
* The CATMARK_QUAD_FACE_VERTEX kernel calculates the face-vertex for a quadrilateral face. It applies to every face after the first subdivision step, and may be applied for the first subdivision step of a quadrilateral coarse mesh.
* The CATMARK_TRI_QUAD_FACE_VERTEX kernel calculates the face-vertex for a triangle or quadrilateral face. It may be applied for the first subdivision step of a coarse mesh composed of triangles and/or quadrilaterals.
* Both kernels calculate each face-vertex using four vertex indices (triangles are specified by repeating the third index). Therefore neither kernel uses the F_ITa codex table, and instead the first vertex offset in the F_IT index table is stored in the FarKernelBatch's table offset.
If the system has CLEW installed (which is detected by recently
added FindCLEW routines) then OpenSubduv would be compiled against
this library.
It makes binaries and libraries more portable across the systems,
so it's possible to run the same binary on systems with and without
OpenCL SDK installed.
The most annoying part of the change is updating examples to load
OpenCL libraries, but ideally code around controllers and interface
creation is to be de-duplicated anyway.
Based on the pull request #303 from Martijn Berger
- Some missing includes of <algorithms> in order to have
stdd::min() and similar functions.
- Need to cast numIndices and numNVerts to int explicitly
in order to solve warning treated as an error about
precision loss.
- Can't do vector[0] for an empty vector, it'll generate
a runtime range check error.
- MSVC only works fine with make_pair(foo, bar) syntax,
without explicit template substitution here. Otherwise
weird 'can't cast int to int&&' errors are happening.
- It used to create _computeContext twice.
- Ownership of refiner didn't set properly, because
Initialize() forces evaluator to drop ownership.
So now ownership sets after initialization from
topology.
Moved transient states (current vertex buffer etc) to controller.
ComputeContext becomes constant so that it's well suited for coarse-grain
parallelism on cpu.
Client-facing API has changed slightly - limitEval example has been adjusted
- fix some variable names (private vs. public)
- implement constructors to guarantee initialized pointers (d'oh)
- add a 'Reset' method to unbind buffers
Note: while the new contexts have been cleaned up, we now have a fair amount of duplicated code in the controllers...
Moved transient states (current vertex buffer etc) to controller.
ComputeContext becomes constant so that it's well suited for coarse-grain
parallelism on cpu.
Useful for cases when some parts of the pipeline needs to know the
topology object. Simply helps saving memory so topology from the
evaluatgor can be re-used for stuff like HbrMesh creation.
This way external application might check whether it need to
re-create evaluator from scratch or it might re-use existing
one without storing extra data from it's side.
TODO: Tags are still not accessible via C-API, it's marked as
to be solved later when it becomes more clear what is the best
way to expose them and when there'll be a real application to
test the tags.
All kernels take offset/length/stride to apply subdivision partially in each vertex elements.
Also the offset can be used for client-based VBO aggregation, without modifying index buffers.
This is useful for topology sharing, in conjunction with glDrawElementsBaseVertex etc.
However, gregory patch shader fetches vertex buffer via texture buffer, which index should also
be offsetted too. Although gl_BaseVertexARB extension should be able to do that job, it's a
relatively new extension. So we use OsdBaseVertex() call to mitigate the compatibility
issue as clients can provide it in their way at least for the time being.
Moved transient states (current vertex buffer etc) to controller.
ComputeContext becomes constant so that it's well suited for coarse-grain
parallelism on cpu. The prims sharing same topology (ComputeContext) can
be refined simultaneously by having mutiple compute controllers.
Client facing API doesn't change.
- fix the vertesIsBSpline logic to correctly recognize these sharp corner vertices
- fix another bug where a loop was missing vertices from from quad faces with 2
non-consecutive boundaries
fixes#294
- add a limit evaluation method to EvalLimitController that allows
client code to directly pass the output buffer without binding it
to the Context (the call only computes vertex interpolation of a
single sample)
- switch the OsdUtilAdaptiveEvaluator to use the new method from the controller
and stop stomping member
- cleanup buffer and member variables no longer used
- cleanup initialization logic to be better aware of uniform / adaptive
- add some assert sanity checks in the cpuEvalLimitKernels
fixes#293
* rolled getNumFVarVertices into allocateTables
* renamed tessellate to triangulateQuads (technically speaking, Loop scheme uses a trivial triangulation)
* condensed the pointer arithmetic used for triangulating the data tables
* maintainance work on the D3D11 specialization of OsdMesh to bring it in line with the other template specializations
* updated the facePartition example to derive PartitionedMesh from OsdMesh in order to allow other vertex buffer and compute controller configurations
* added the numVertexElements argument to Osd*DrawContext::Create, which is used to initialize the patch arrays when calling OsdDrawContext::ConvertPatchArrays
* removed the unused level argument from Osd*DrawContext::_initialize
* maintenance work on CL/D3D11 bindings to get them to compile
Before this change the given function used to fail silently in
cases topology is bad or uniform evaluator initialization failed.
This used to leave evaluator in a state which is not usable for
further processing but callee function would never know this and
will likely crash later when evaluating subdivision limit surface.
Ideally error message or code need to be passed to the calle, but
that's marked as TODO for now.
Issue was that evaluator.SetCoarsePositions() is expecting number
of floats in the array to be passed, but the C-API function used
to pass number of vertices there.
* instantiates FarPatchTables with face-varying data for a single uniform subdivision level, or for an adaptively subdivided mesh
* face-varying data is not regenerated if data for multiple uniform subdivision levels is present
Delete scheme specialized subdivision tables. The base class FarSubdivisionTables
already has all tables, so we just need scheme enum to identify which scheme
the subdivision tables belong to.
This brings a lot of code cleanups around far factory classes.
* replace void* of all kernel applications with CONTEXT template parameter.
It eliminates many static_casts from void* for both far and osd classes.
* move the big switch-cases of far default kernel launches out of Refine so
that osd controllers can arbitrary mix default kernels and custom kernels.
* change FarKernelBatch::kernelType from enum to int, clients can add
custom kernel types.
* remove a back-pointer to farmesh from subdivision table.
* untemplate all subdivision table classes and template their compute methods
instead. Those methods take a typed vertex storage.
* remove an unused argument FarMesh from the constructor of subdivision
table factories.
minor code cleanups:
- change Descriptor::iterator to use a static vector instead of overly complicated logic
- change the private factory PatchType struct for better readability
- variable name changes
Prevent boundaryEdgeNeighbors[2] from being overrun when an interior
vertex has more than 2 boundary neighbor vertices. The fix is applied
to the GLSL / HLSL and CPU implementations.
Note: this appears to fix long-standing problems with Gregory patches,
but i am not entirely convinced that this fixes the general case.
fixes#259
Also:
- Add a _numVertices member to cpuSmoothNormalContext (for memory reset function)
- Fix memory reset function in cpuSmoothNormalContext (was performing redundant memsets)
- Add a resetMemory boolean to cpuSmoothNormalContext to make reset step optional (default is off)
- added a _stringify function to top CMakeLists
- switched all stringification tasks to use the macro
- all suffixes are now .gen.h instead of .inc (to help cmake track dependencies)
Further leverage cmake object libraries to share object files for CPU
and GPU OSD libraries, avoiding duplicate complation for dynamic/static
build passes.
CMake restricts object library inputs to header and source files, so the
.inc files were renamed to .gen.h (which seems like a better name
anyway) to make CMake happy.
Also updated the .gitignore file to ignore .gen.h files.
Conflicts:
opensubdiv/osd/CMakeLists.txt
- set OBJECT targets for osd cpu & gpu libs, and use the obj target for
static and dynamic linking
- add a new examples_common_obj OBJECT target
- replace direct source dependencies to obj target in all examples CMakeLists
This change makes it possible to not re-compile the same source files
multiple times when they are used in multiple targets. Thanks to jcowles
for uncovering the CMake functionality.
Note: it seems that multi-process build is working again (gmake -j <x>)
An object library allows other build targets to use the object files
from this library.
The change introduces osd_static_cpu_obj which is consumed by
osd_static_cpu.
This will be useful for emscripten integration where we cant use the
compiled library, rather it will use the object files, targeting
osd_static_cpu_obj.
Do feature adaptive refinement, then use the cpuEvalLimit API to evaluate
grids of points on faces.
Test harness is tessellateObjFile which has a -blender option to trigger
the gridding tessellation code.
The new table accomodates verts with valence up to 20.
Dr. DeRose provided me with a python script to generate the tables, but wants to
investigate a closed-form alternative to pre-computed tables.
Also: our logic is incorrect - it is missing adjacent face-points in the
interpolation (apparently this has been incorrect since day 1). Further fixes
coming next year...
fixes#246
The logic that invalidates the vertices in the control stencil and
the cached bspline patch weights was not triggering correctly.
Hopefully this new bit of logic should clear up some of the incorrect results.
fixes#246
Limit tangent stencil crease rule was accumulating the wrong vertices. This
change switches from using an Hbr operator to using a less efficient std::list,
but allows us to rotate around the vertex from an arbitrary starting incident
edge.
The values returned are "plausible", but more extensive testing would be required
to validate this new code.
fixes#246
Important notice: all client shader code must have following functions and compose them to osd intrinsic shaders (vertex/tessEval/tessControl)
mat4 OsdModelViewMatrix()
mat4 OsdProjectionMatrix()
mat4 OsdModelViewProjectionMatrix()
float OsdTessLevel()
int OsdGreogryQuadOffsetBase()
int OsdPrimitiveIdBase()
We probably should write a utility class for basic binding of them, to make client code simpler.
The tangents were only scaled in the "bail-out" code branch that
pushes vertices to the limit and performs bi-linear interpolation.
Now we are also scaling the bi-cubic patch interpolation code branch.
There may be another code path left to fix (as well as some pointers
being currently unchecked)
fixes#243
The previous fix pointed far indexing tables to the origin vertex
of duped singular verts.
This fix goes one step further and actually shifts all vertex indexing
to start at the end of the coarse mesh vertices, using the space for
data that was previously occupied by duplicated singular verts.
The consequence is that client code no longer needs to duplicate vertex
data in vertex buffers (huzzah !).
- fix FarSubdivisionTablesFactory to shift factory vertex table offsets using Hbr's
singular verts map
- fix schema table factories (Catmark, Loop...) to correctly use these offsets
- remove vertex data duplication code from osdPolySmooth example
- remove some (unrelated) cruft from glViewer example
- shape_utils unfortunately still needs to dubplicate the singular verts to
allow the coarse edge drawing in our example viewers to work correctly
(although it could be fixed to avoid data duplication too...)
fixes#241
- Add a vector of index pairs to HbrMesh to track the index of a split
vertex and its origin vertex
- Correct the Far remap tables in FarSubdivisionTablesFactory to point split
vertices to their origin instead of themselves
- Fix regression/common/shape_utils.h to use the new HbrMesh::GetSplitVertices()
method.
- Fix the osdPolySmooth example to use the new HbrMesh::GetSplitVertices()
method.
- Add a paragraph to the documentation
fixes#241
Moving Takahito's implementation into the core API:
- added <gl/d3d11>PtexCommon.<glsl/hlsl> shader code
- added control to enable Ptex common trunk in <gl/d3d11>DrawRegistryBase classes
- fixed GL & D3D11 ptexViewer examples to use the new API
- implement virtual accessors in FarSubdivision tables that return a Scheme enum
- implement a safe typeid comparison in FarMeshFactory to get the same information
from Hbr subdivision classes
fixes#240
The Chaikin crease interpolation mode seems to be broken:
- Catmark / Loop / Bilinear are passing the wrong halfedge vertex to the
SubdivideCreaseWeight function which results in sub-edge crease weights
being swapped
- the loop that iterates over adjacent edges needs to check against both
the original edge and its opposite, otherwise it may be incorrectly
accumulated into summation of these adjacent edges (with a 0.25 weight)
The proposed fix:
- Swaps the Dest/Org vertex passed to the SubdivideCreaseWeight (and
we probably want Julian to confirm that this the correct fix)
- Checks against both the original edge and its opposite in the iteration
over adjacent edges
- Replaces the std::vector based query with an HbrHalfedgeOperator for
better performance (hopefully)
The similar fix to OpenSubdiv been reviewed by Tony DeRose.
Also in the fix:
- fix "obj" tag parsing of the smooth triangle tag that was incorrectly
associated with the crease method (and reporting the wrong errors)
- add regression shapes for both Loop & Catmark schemes to hbr_regression
- add same shapes to the glViewer
- improve hbr_regression output to be more readable
- add command-line argument parsing to hbr_regression
- add functionality to dump an obj file when regression fails for comparison
fixes#235
Getting there, this code is being tested with Presto deformers and is working well. Valgrind reports no memory errors with the simple projectTest test harness.
set HBR_ADAPTIVE before including hbr code. Also use an ifndef in
far/meshFactory.h so that code can be included where someone else has
already defined HBR_ADAPTIVE.
For face-varying interpolation, sharpness should be interpreted as an
infintely sharp boundary. Hbr implements this correctly for vertex
sharpness, but inconsistently for edge sharpness: both the fvarbits
cache and methods that gather face-varying sharpness need to be corrected.
fixes#231
New text:
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.
- Adding FarStencilTables and FarStencilTablesFactory classes
- Adding Osd EvalStencil context & controllers for CPU, OMP and TBB backends
- Adding the code example glStencilViewer
- Adding reST documentation
- Changing version to 2.2.0_dev
- Fix HbrMesh::Unrefine function
- Fix "CanEval" function in OsdVertexBufferDescriptor
Note 0: there is no stencil support for hierarchical edits
Note 1: there is no support for face-varying data stencils yet
Note 2: the current stencil factory is lazy but the caching system is not re-entrant
