- 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
- new RST pages for our excample code
- fix doxygen documentation link from the nav tab
- fix cmake build rules (still not quite working as intended)
- adding API RST documentation all around
GLFW 3.0.1 made the reshape callback explicit. Since we are using it to setup some framebuffers,
we need to call this function ourselves before starting the main-loop.
fixes#181
- fix FindGLFW.cmake to match the new locations
- fix all viewer & examples to build with 3.0, 3.0.1 and 3.0.2
Note : ptxViewer and paintTest do not work with 3.0.1 and 3.0.2 (yet)
- Replaced EvalData and EvalVertexData classes with a simpler DataStream class that only
accesses a single data stream, binds and unbinds it
- DataStream has both an input and an output version which avoids much of the const-ness
const-related ambiguity of the previous design pattern
- Vertex, varying and face-varying data now all have a dedicate struct (VertexData, VaryingData, FaceVaryingData)
as a way of gathering the various data-streams required to perform sampling
- renamd some "Buffers" into "Tables" for better naming consistency with Far
- remove PatchMap from FarPatchTables
- add a new FarPatchMap quad-tree class (constructed from FarPatchTables)
- refactor the EvalLimitController to use the quad-tree search instead of a
serial loop access
fixes#174
that do not have that type of data
- fix some regression shapes that had "empty" uv values
(including some minor topo surgery that luckily appears to not break
regression baselines)
set all the point colors (if face-varying data is missing on the test shape for instance)
and we don't want random values creeping from unset memory allocations.
- minor refactoring of the LimitEvalContext to accomodate all the data buffers
- pushing some minor sub-patch functionality back to FarPatchParams
- extend example code with randomly generated varying vertex colors
and adding the requisite accessors
Note : all our example code goes through the same boiler-plate texture
binding code - we might want to move it as a member function of the DrawContext.
