Now a ComputeController is passed as an
argument to OsdMesh::Create(). This is
a better match to the underlying object
model and can be much more efficient for
compute controllers that have expensive
resources, e.g. compiled shader kernels.
Fixes#103
- make sure HBR passes down the hole tag to children when subdividing faces
- minor API modification : allow to unset the hole flag on a face
- modify uniform / adaptive FarMeshFactory to be aware of the flag
- make the FarSubdivisionTableFactory assert when finding unconnected HBR vertices (as it should)
* Uniform subdivision :
The refinement scheme only creates faces & vertices necessary
to maintain the one-ring around the edges of a hole, so this solution
is quite efficient.
* Adaptive subdivision :
At the moment we are still performing full topological analysis on holes and
only skipping patches associated to holes. This is sub-optimal in 2 ways :
1. the topological analysis can potentially be cranking on a lot of unnecessary
geometry
2. even though we may not be drawing the patches, the compute stage is still
applying kernels on all the control vertices of these patches.
We will have to revisit feature adaptive subdivision & holes, so keep the issue active.
fixes#78
- add bool OsdGLDrawContext::SupportsAdaptiveTessellation() method
- modify glViewer to use that instead of #ifdefs
Note : this is not the final word on this as OSD really needs a more comprehensive
system to provide run-time information about available features to the client code.
fixes#111
Model the GL VB after D3D11 one, where there are no data read backs, however this means
an extra memory copy of the buffer. 4th level uniform subdiv on Car, glGetBufferSubData
was taking 50% of CPU time before (actual subdiv 22%), now that is gone. Full CPU Draw
62ms -> 54ms, looks like most of overhead now is just waiting on GL queries).
In example code, GLUT has been replaced with GLFW so that glViewer/ptexViewer can run on OSX (10.7 or later).
OSX note: still have some problem with clang, may need to explicitly specify gcc on cmake cmdline
-DCMAKE_CXX_COMPILE=/usr/bin/g++
fixes#98
- remove the GL error check in cudaGLVertexBuffer :
* unrelated GL errors left on the stack were triggering erroneous
vertexBuffer allocation errors
* we should not be checking for GL errors here anyway (as most other
buffer allocations aren't checked either)
- add some pointer checking in the GL / D3D drawContexts in case the
vertexBuffer pointers passed are NULL
- add some additional typedefs in OsdError to report some of the new
CUDA / GL related errors
- still need to change these changes with other compilers (MSVC / clang...)
- had to add a -Wno-invalid-offsetof for GCC (still need to test w/ other compilers) : apparently gcc 4.4 is somewhat incorrect in tagging our templated class as POD.
- had to change fvarData.h to initialize bitfields to 0 as gcc generates truncated int warnings when trying to initialize 31 bits to -1
- in mesh.h replaced original tbb::concurrent_vector with std::vector until a better solution can be found
Fixes#93
This avoids adaptive tessellation artifacts near silhouette edges
by using the projected diameter of an edge's bounding sphere
rather than the length of the projected edge itself.
There is a nice writeup of this by Bryan Dudash of NVIDIA at:
https://developer.nvidia.com/content/dynamic-hardware-tessellation-basics
- [Feature Adaptive GPU Rendering of Catmull-Clark Surfaces](http://research.microsoft.com/en-us/um/people/cloop/tog2012.pdf).
- New API architecture : we are planning to lock on to this new framework as the basis for backward compatibility, which we will enforce from Release 1.0 onward. Subsequent releases of OpenSubdiv should not break client code.
- DirectX 11 support
- and much more...
There seems to be a bug in clang: despite the fact that FarMeshFactory is
declared to be a friend class from FarSubdivisionTables, clang protests that
VertexKernelBatch is not accessable.
This hack adds an #ifdef __clang__ block to make that structure public and keep
Far compiling under OSX.
- All data representation classes are now single-templated for a vertex class 'U'
- All constructors / instancing code has been moved into "Factory" functions that are dual-templated
for two vertex classes <class T, class U=T>. This allows hbr specialization with a placeholder
vertex flass 'T' for faster analysis without paying interpolation costs, while far can still specialize
a fully implemented vertex class 'U' with full subdivision functionality.
- Some preliminary clean-up work on FarVertexEditTables with the addition of a FarVertexEdit class
as a replacement for the former HbrVertedEdit which was introducing back dependencies on hbr. The
implementation is very lightweight. Some slight renaming / cleanup of the code, with some more to
be done.
- there are no more dependencies on hbr (not even #include) from far's data structure !
Notes :
- the FarDispatcher mechanism has become somewhat awkward and should be re-evaluated when refactoring osd.
- the "Factory" pattern survives this round of refactoring until we can find something better.
Closes#34