Posts Tagged ‘c#’

Using glfw background window in matlab mex thread

Monday, April 3rd, 2017

A while ago, I tried to get glfw playing nicely with matlab’s mex files. I didn’t quite succeed.

My current project requires “GP-GPU” programming. I’m currently using glfw’s “background window” feature to create an OpenGL context. My first tests show that matlab’s mex will play nicely if glfwTerminate() is never called:

#include <igl/opengl/glfw/background_window.h>
#include <mex.h>
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
  GLFWwindow * window;
  igl::opengl::glfw::background_window(window);
  glfwDestroyWindow(window);
  //glfwTerminate();
}

You can compile this (on mac os x) with:

mex( ...
  '-largeArrayDims','-DMEX','CXXFLAGS=$CXXFLAGS -std=c++11', ...
  'LDFLAGS=\$LDFLAGS -framework Foundation -framework AppKit -framework Accelerate -framework OpenGL -framework AppKit -framework Carbon -framework QuartzCore -framework IOKit ', ...
  '-I/usr/local/igl/libigl//external/nanogui/ext/eigen/', ...
  '-I/usr/local/igl/libigl/include', ...
  '-I/usr/local/igl/libigl/external/nanogui/ext/glfw/include/', ...
  '-L/usr/local/igl/libigl/lib/','-lglfw3', ...
  'background_glfw.cpp');

I don’t know why including glfwTerminate() causes matlab to sometimes crash. The error report is impossible to read and seems to have something to do with Quartz.

Friday, January 6th, 2017

Like clockwork, my matlab updates have gotten out of sync with Xcode updates. It seems like fixing this SDK error always requires a different hack each year. This year I got the error:

No supported compiler or SDK was found. For options, visit
http://www.mathworks.com/support/compilers/current_release/. 

To fix it, I replaced all occurrences of 10.9 with 10.11 in /Applications/MATLAB_R2017a.app/bin/maci64/mexopts/clang{++,}_maci64.xml

I’m still getting linker warnings:

ld: warning: object file was built for newer OSX version (10.11) than being linked (10.9)

For now, I’m assuming that I can ignore them. We’ll see how far that gets me.

Trouble building opencv_contrib extras, can’t find unsupported/Eigen

Monday, May 23rd, 2016

I ran into a problem compiling the opencv_contrib modules.

Just running a vanilla cmake then make:

cmake -DOPENCV_EXTRA_MODULES_PATH=../opencv_contrib/modules ..
make

produced the error:

/Users/ajx/Downloads/opencv/opencv_contrib/modules/rgbd/src/odometry.cpp:41:10: fatal error: 'unsupported/Eigen/MatrixFunctions' file not found
#include <unsupported/Eigen/MatrixFunctions>

It seems the problem is that cmake was finding Eigen in /Library/Frameworks/Eigen.Framework/. I don’t even know how that Eigen got installed. Homebrew? Does it ship with Mac OS X now? In any case, I fixed the issue by pointing cmake directly to my homebrew’s Eigen installation:

cmake -DOPENCV_EXTRA_MODULES_PATH=../opencv_contrib/modules -DEIGEN_INCLUDE_PATH=/usr/local/include/eigen3/ ..

Simple “parallel for” using C++11 std::thread

Thursday, February 25th, 2016

It seems like Apple’s built-in clang will never support OpenMP. I really used OpenMP only for its #omp parallel for. Now that C++11 has support for multi-threading, I tried to write a very basic parallel for without OpenMP.

#include <vector>
#include <thread>
#include <iostream>

int main(int argc, char *argv[])
{
  const size_t nloop = 11;

  // Serial version
  {
    // Pre loop
    std::cout<<"serial:"<<std::endl;
    // loop over all items
    for(int i = 0;i<nloop;i++)
    {
      // inner loop
      {
        const int j = i*i;
        std::cout<<j<<std::endl;
      }
    }
    // Post loop
    std::cout<<std::endl;
  }

  // Parallel version
  // number of threads
  const size_t nthreads = std::thread::hardware_concurrency();
  {
    // Pre loop
    std::cout<<"parallel ("<<nthreads<<" threads):"<<std::endl;
    std::vector<std::thread> threads(nthreads);
    std::mutex critical;
    for(int t = 0;t<nthreads;t++)
    {
      threads[t] = std::thread(std::bind(
        [&](const int bi, const int ei, const int t)
        {
          // loop over all items
          for(int i = bi;i<ei;i++)
          {
            // inner loop
            {
              const int j = i*i;
              // (optional) make output critical
              std::lock_guard<std::mutex> lock(critical);
              std::cout<<j<<std::endl;
            }
          }
        },t*nloop/nthreads,(t+1)==nthreads?nloop:(t+1)*nloop/nthreads,t));
    }
    std::for_each(threads.begin(),threads.end(),[](std::thread& x){x.join();});
    // Post loop
    std::cout<<std::endl;
  }
}

It’s not as simple as slapping down #omp parallel for but it’s really just a few lines above and below the for loop. It can even determine the number of cores available and handle simple atomic operations.

Code and presentation slides for Nested Cages

Monday, February 1st, 2016

nested cages teaser

We’ve released the source code and presentation slides for our paper Nested Cages, presented last November at SIGGRAPH Asia 2015.

Run executable in debugger immediately, return if successful

Saturday, January 2nd, 2016

Here’re the flags for the lldb debugger to run a binary my_bin in the debugger immediately and return to the prompt if there were no errors. But if, say, an assertion fires, then it will stop as usual:

lldb -b -o r my_bin

CGAL’s cmake file overriding all cmake flags

Wednesday, December 30th, 2015

I recently ran into many annoying issues with the way that CGAL has setup its default use with CMake. One issue is that its use of CMAKE_SOURCE_DIR instead of PROJECT_SOURCE_DIR makes it impossible to add CGAL via add_subdirectory. As far as I can tell CGAL must always be “installed” and then found using find_package. This makes it difficult to package up source code that will install and build all dependencies via cmake.

The second issue is that cmake suggests:

find_package(CGAL REQUIRE)
include(${CGAL_USE_FILE})

But the include(${CGAL_USE_FILE}) line is like dropping a bomb all over your cmake settings. I tried to prevent this by adding above it:

set(CGAL_DONT_OVERRIDE_CMAKE_FLAGS TRUE)

But this has no effect due to cmake nonsense. Instead adding CACHE seems to work:

set(CGAL_DONT_OVERRIDE_CMAKE_FLAGS TRUE CACHE BOOL "Force CGAL to maintain CMAKE flags")

So, I guess, the cmake entry for cgal should be:

find_package(CGAL REQUIRE)
include(${CGAL_USE_FILE})
set(CGAL_DONT_OVERRIDE_CMAKE_FLAGS TRUE CACHE BOOL "Force CGAL to maintain CMAKE flags")

dyld symbol not found, matlab c++

Sunday, December 27th, 2015

I upgrade to the newest Matlab 2015b and suddenly got some unexpected runtime errors in my command line programs compiled with matlab:

dyld: Symbol not found: _mxDestroyArray
  Referenced from: /Users/ajx/./.main
  Expected in: /usr/lib/libSystem.B.dylib
 in /Users/ajx/./.main

I finally tracked this down to a problem in my DYLD_FALLBACK_LIBRARY_PATH. The path to matlab was there but after /usr/lib/ and for some reason that order was throwing off the dynamic linker. I put the matlab path first and that fixed the problem.

CGAL gotcha when trying to modify coordinates of a point etc.

Saturday, December 12th, 2015

Today I ran into a CGAL gotcha. If you try to directly modify, say, the x-coordinate of a point like this:

#include <CGAL/Point_2.h>
#include <CGAL/Exact_predicates_exact_constructions_kernel.h>
#include <iostream>
int main(int argc, char * argv[])
{
  using namespace std;
  using namespace CGAL;
  Point_2<CGAL::Epeck> A(0,0);
  Point_2<CGAL::Epeck> B(1,2);
  A.x() = B.x();
  cout<<"A: "<<A.x()<<","<<A.y()<<endl;
}

The program will silently compile without warning or error, but the run time behavior is not what you’d expect. The program prints:

A: 0,0

That is, A was unchanged by the line A.x() = B.x();

The CGAL doc suggests instead always creating a new point: A = Point_2(B.x(),A.y()); Too bad.

Libigl tutorial entry for physics upsampling with biharmonic coordinates

Tuesday, July 28th, 2015

I’ve added a tutorial entry describing biharmonic coordinates and linking to an example using it to run a “physics” simulation on a coarse mesh and upsample it to a high-resolution mesh:

octopus physics biharmonic coordinates

Read more about in our upcoming SIGGRAPH paper Linear Subspace Design for Real-Time Shape Deformation.