- 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)
Gregory patch shaders rely on a correct estimate of the maximum valence of the vertices in the mesh.
In the current feature adaptive analysis, we stop at level 1, the center vertex of the heptagon is
never traversed, and its high valence is therefore not recorded. The fix is to take advantage of the
first pass and use the number of vertices in the coarse faces to catch those high-sided non-quads that
would generate high valence vertices that may not be revisited in the second pass.
These functions are exclusive to uniformly subdivided topology. With the recent refactoring
of PatchTables and the generalization of topology, uniform meshes only retain the topology
of the highest level of subdivision by default. These functions are now fixed to reflect the
change.
- 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
- defined a fallback value for ROTATE
- made GetPatchLevel() a macro to avoid
referencing gl_PrimitiveID from vertex shaders
- fixed float array initializers
- trivial return if Gregory specific patch data is set
- or iterate through the patch-arrays until an adaptive patch is found (REGULAR,...,GREGORY_BOUNDARY)
fixes#173
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