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
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...
- 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
mutex class with Lock / Unlock public functions.
- remove Mutex implementation from Hbr (and revert to original PRman code)
- provide a Mutex class stub in osd
- add some forward declarations in OsdMesh to limit some of the mutex spills
- #include <osd/mutex.h> where needed (little hackish until we can refactor
some of far better)
- remove ILM_BASE from some CMakeLists
Closes#48
where it can cause havoc downstream, and move vertexBuffers into the cpp
file to avoid gl.h inclusion and to fix dynamic cast issues. These were
found during Presto integration.
- modify shape_utils to return a vector of coarse vertices when creating an hbr mesh
- minor cleanup of osd mesh and the addition of a vector parameter in the creator to
save the remapping between the hbr mesh progenitor and the current serialized osd mesh.
- minor fallout modifications to the glutViewer & far regression code
Notes :
- the dual template of far is causing a lot of complications
-> suggest finding a way to isolate the T template to the factory code.
-> far needs a concept of a vector of vertex & varying data (to abstract the vertex buffer
away from osd)
-> the dispatched mechanism is awkward and needs refactoring
-> suggest moving the default CPU kernels away from the subdivision tables
-> suggest finding a way to completely untemplate the tables (we might need a templated
factory function though)
-> osd should be able to call delete on the far mesh to get rid of all the CPU-bound data
once the GPU data has been laid-out.
Closes#18.
kernel, call OsdKernelDispatcher::Factory::Register() and keep the integer
result value as kernel handle.
Attempted to elimiate registering function from client code, but currently
disabled (in kernelDispatcher.cpp) because of Maya plugin doesn't work with cuda
kernel.
glutViewer creates kernel menu dynamically according to linked kernels.
Fix a bug of maya plugin crashes.
Closes#14
- use find_package(OpenMP) to test that the compiler supports OMP
(looks like the "express" versions of MSVC do not)
- if not available, make sure that osd does not register those
compute kernels (but does register the CPU standalone ones)
- similar refinements on other dependencies (Maya, CUDA) where
the build "opts in" depending on which libs are found.
some CMakeLists still need more cleanup...
Closes#9
specification (how many elements exists in the buffer).
client will create OsdVertexBuffer and provide it as an argument of
OsdMesh::Subdivide() function. It would be more flexible and hopefully matches
various use cases.
Since each dispatcher has to accept arbitrary vertex buffer, introduced a simple
shader registry into glslDispatcher. It will configure shaders for given vertex
elements on demand (for now, just works only for varying buffer).
Fixed cuda kernel's GL resource leakage. Since cuda GL interop seems one-way,
OsdCudaVertexBuffer manages vertex updating instead of just using
OsdGpuVertexBuffer.
Cleaned up some kernel codes and renamed ambiguous names.
