A truly CPU-only version ?

[dougepps]

Trying to get an only-cpu test program going and can't seem to.

Should I be able to ? I.e. simpleCpu wants to use glBuffers for vertex positions (I think, just now getting into it).

Thanks guys !

-doug

[prideout]

Yes, your app can be truly CPU-only if you're okay with uniform subdivision rather than adaptive. Instead of OsdCpuGLVertexBuffer, just use OsdCpuVertexBuffer.

To extract the refined vertices, call BindCpuBuffer() to get a pointer to its data. To extract refined quads, call GetFaceVertices(level) on the far mesh.

On Mon, Feb 4, 2013 at 12:06 PM, Doug Epps notifications@github.com wrote:

Trying to get an only-cpu test program going and can't seem to.

Should I be able to ? I.e. simpleCpu wants to use glBuffers for vertex positions (I think, just now getting into it).

Thanks guys !

-doug

— Reply to this email directly or view it on GitHubhttps://github.com/PixarAnimationStudios/OpenSubdiv/issues/111.

[manuelk]

I think our "simpleCPU" example name may be misleading : the example still uses GL/GLUT to display the tessellated geometry on screen. Here we are referring to the fact that our Compute stages only rely on a single-thread CPU implementation. Looking at the code in the example itself, I am seeing that it's also still using glut, which we are phasing out as a dependency : looks like we have some cleanup to do...

For CPU only code, you may want to take a look at the hbr_regression and far_regression code : although it is not a representation of how OSD works by any means, the FAR regression might give you an idea of how the compute kernel system works.

Let me know if you are having problems w/ cmake & build.

[dougepps]

Great thanks.

I'm really looking for the most brain-dead simple "here's a point-polygons style set of vertices" build a osdMesh out of them, then get some points on the limit-surface.
Then I'll work my way up to HierarchicalEdits, which is really why I want to use the magic of OSD rather then my lame version.

I think the thing I want to leverage is the simpleCpu thing, but maybe not.

right now it feels like the examples don't build for me. I may not be using git right, but they're not included in the Cmake file (and on my OSX machine the _add_glut_executable isn't working).

thanks !

-doug

On Feb 4, 2013, at 12:51 PM, Manuel Kraemer notifications@github.com wrote:

I think our "simpleCPU" example name may be misleading : the example still uses GL/GLUT to display the tessellated geometry on screen. Here we are referring to the fact that our Compute stages only rely on a single-thread CPU implementation. Looking at the code in the example itself, I am seeing that it's also still using glut, which we are phasing out as a dependency : looks like we have some cleanup to do...

For CPU only code, you may want to take a look at the hbr_regression and far_regression code : although it is not a representation of how OSD works by any means, the FAR regression might give you an idea of how the compute kernel system works.

Let me know if you are having problems w/ cmake & build.

— Reply to this email directly or view it on GitHub.

[dougepps]

Teasing apart the far regression tests seems like the most-simple-looking thing.

I'd like to add face varying texture coords to it, is there somewhere to look for that ?

(all I can find are xyz-style meshes). I think I want to add something to the Hbr mesh that's face-varying ?

[manuelk]

I see. In the head version we have recently switched away from Glut to GLFW and the simpleCPU example is currently busted on OSX. I'll go do a build on my Mac and see if something else has broken recently.

For looking at hierarchical edits, the glViewer (formerly known as glutViewer) is a good example of applying OSD and some of the test shapes actually have hierarchical edits. This example should build on OSX with the feature adaptive code disabled (since no GL 4.x).

Any chance you could please paste me the command line that you are runming with cmake as well as the spewage ?

PS : for facevarying texture coordinates the mayaViewer example shows how to manipulate a uv layout from Maya.

[dougepps]

It feels like something is just in a semi-re-factored state.

In examples/CMakeLists.txt the add_subdirectory(simpleCpu) is commented out. If I un-comment it I get:

CMake Error at examples/simpleCpu/CMakeLists.txt:101 (_add_glut_executable): Unknown CMake command "_add_glut_executable".

My process is: % git clone https://github.com/PixarAnimationStudios/OpenSubdiv.git % cd OpenSubdiv/ % mkdir build % cd build % cmake ../ % make (edit CMakeLists.txt and comment out FindMaya () as that doesn't work for me, not sure why) % make -- All is well ! --- % vi ../examples/CMakeLists.txt # un-comment add_subdirectory(simpleCpu) % cmake ../ -- bad things --

OSX 10.8.2 % cmake --version cmake version 2.8.9

I don't think I've done anything evil to my cmake, though it is installed via homebrew.

Thanks, I'm happily hacking away at the examples trying to get textures, having a ball !

-doug

[manuelk]

The --bad things-- spewage from cmake is actually what i am after. I would highly recommend cloning GLFW 3.0 from git and building it (i just did and it worked, although i had to remove a readme.html from their install cmake script) as it will enable glViewer, our main code example.

I have had the chance to try building OSD on my Mac and these are the issues that i have run into :

• Maya plugins will not work and i'll take them out of the OSX build until we have a solution
• simpleCPU is also out of date and will similarly be removed on OSX
• glViewer builds but runs into shader compiling errors at run-time

I'll post fixes.

M.

[dougepps]

from cmake: -- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is Clang 4.1.0 -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - yes -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - yes -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Compiling OpenSubdiv version RELEASE_CANDIDATE_1_0 -- Using cmake version 2.8.9 -- Try OpenMP C flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Success -- Try OpenMP CXX flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [/openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-Qopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-openmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-xopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [+Oopenmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-qsmp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP CXX flag = [-mp] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Could NOT find OpenMP (missing: OpenMP_CXX_FLAGS) -- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
-- Found OpenCL: /System/Library/Frameworks/OpenCL.framework (Required is at least version "1.1") -- Found CUDA: /usr/local/cuda (found suitable version "4.0", required is "4.0") -- Found GLFW: /usr/local/include (found suitable version "2.7.6", required is "2.7.0") -- Could NOT find PTex (missing: PTEX_INCLUDE_DIR PTEX_LIBRARY) (Required is at least version "2.0") CMake Warning at CMakeLists.txt:233 (message): OpenMP was not found : support for OMP parallel compute kernels will be diabled in Osd. If your compiler supports OpenMP directives, please refer to the FindOpenMP.cmake shared module in your cmake installation.

CMake Warning at CMakeLists.txt:250 (message): OpenGL 4.2 was not found : support for GLSL transform feedback kernels will be disabled in Osd. If you have an OpenGL SDK installed (version 4.2 or above), please refer to the FindOpenGL.cmake shared module in your cmake installation.

CMake Warning at CMakeLists.txt:263 (message): OpenGL 4.3 was not found : support for GLSL compute shader kernels will be disabled in Osd. If you have an OpenGL SDK installed (version 4.3 or above), please refer to the FindOpenGL.cmake shared module in your cmake installation.

CMake Warning at CMakeLists.txt:303 (message): Ptex was not found : the OpenSubdiv Ptex example will not be available. If you do have Ptex installed and see this message, please add your Ptex path to FindPTex.cmake in /Users/DougEpps/subd/pure/OpenSubdiv/cmake or set it through the PTEX_LOCATION cmake command line argument or environment variable.

CMake Warning at CMakeLists.txt:317 (message): Maya was not found : the OpenSubdiv mayaViwer plugin will not be available. If you do have Maya installed and see this message, please add your Maya path to FindMaya.cmake in /Users/DougEpps/subd/pure/OpenSubdiv/cmake or set it through the MAYA_LOCATION cmake command line argument or environment variable.

CMake Error at examples/simpleCpu/CMakeLists.txt:101 (_add_glut_executable): Unknown CMake command "_add_glut_executable".

-- Configuring incomplete, errors occurred!

[manuelk]

This is looking pretty good actually : if you can comment out the simpleCPU example in examples/CMakeLists you should be able to get an error-free run of cmake.

Then in your build directory try: xcodebuild -target glViewer

The binary should be somewhere under build/bin/glViewer

The viewer should be running on OSX 10.8 (the issues i am seeing seem to be tied to my 10.7 version). The glViewer is not the easiest to tease apart, but most the action is in the createOsdMesh with tidbits left in the display() callback.

Going back to your earlier request of obtaining limit samples from a coarse mesh : this is part of our "Eval" module API and this is current work in progress. Dirk made a first check-in this week-end with an example called "evalTest" that is currently commented out (in examples/CMakeLists.txt). This might be closer to what you are looking for - with the caveat that this is a hard-hat area that is likely subject to change quite extensively (current deadline is August 2013).

Hope this helps.

M.