## Archive for May, 2014

### Compiling pardiso matlab interface finding wrong gfortran dylib

Wednesday, May 28th, 2014

I tried to compile the pardiso mex interface for matlab and got a very annoying linker error upon running:

Invalid MEX-file '/Users/ajx/.../pardisoinit.mexmaci64':
dlopen(/Users/ajx/.../pardisoinit.mexmaci64, 6): Symbol
Referenced from: /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
Expected in: /Applications/MATLAB_R2014a.app/sys/os/maci64/libgfortran.3.dylib
in /usr/local/lib/libpardiso500-MACOS-X86-64.dylib


The problem seems to be that matlab is finding gfortran.3.dylib in its own directory path rather than the one that pardisoinit was linked to. These libraries are also unfortunately different. I think there’s an otool/install_name_tool trick for this, but so far I’m using this hack. I replace the libgfortran.3.dylib in Matlab with the one from gcc:

mv /Applications/MATLAB_R2014a.app/sys/os/maci64/libgfortran.3.dylib /Applications/MATLAB_R2014a.app/sys/os/maci64/libgfortran.3.dylib.off
cp /opt/local/lib/libgcc/libgfortran.3.dylib /Applications/MATLAB_R2014a.app/sys/os/maci64/libgfortran.3.dylib


So far this hasn’t messed up anything else in MATLAB, but I guess, without knowing better, it’s only a matter of luck. Too bad pardiso doesn’t seem to support mac and isn’t open source.

### Fixing Pardiso libraries

Wednesday, May 28th, 2014

Here’s what I did to get pardiso’s dynamic libraries working on mac os x:

sudo mv ~/Downloads/libpardiso500-MACOS-X86-64.dylib /usr/local/lib
sudo ln -s /usr/local/lib/libpardiso500-MACOS-X86-64.dylib /usr/local/lib/libpardiso.dylib
sudo install_name_tool -id /usr/local/lib/libpardiso500-MACOS-X86-64.dylib /opt/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libgomp.1.dylib /opt/local/lib/libgcc/libgomp.1.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libgcc_s.1.dylib /opt/local/lib/libgcc/libgcc_s.1.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib


I think there’s a fancier way to do this using @rpath, but these hardcoded paths got me rolling at least

Monday, May 26th, 2014

I’ve run into this issue before, when using the siggraph latex template. I get an error:

! Undefined control sequence.
<argument> \citename


It’s tricky to track down. It seems the problem is that the siggraph style is defining cite but then it’s getting wiped out but an included package. In my case I need to remove an unneeded:

\usepackage{cite}


Then the problem went away.

### Bounded Biharmonic Weights iPad App

Thursday, May 8th, 2014

Stefan Messmer, a student at ETH, has designed an iPad app called Animato implementing our bounded biharmonic weights for real-time shape deformation. Check out this tutorial video:

And download the app from the appstore.

### Implementing a queue in matlab

Wednesday, May 7th, 2014

Here’s a basic queue in MATLAB you could save in queue_array.m

% http://www.cs.bu.edu/teaching/c/queue/array/types.html
% Extending handle is very important!!
% See http://stackoverflow.com/a/13867697/148668
classdef queue_array < handle
properties ( Access = public )
elems = zeros(1,1);
first = 0;
last = 0;
end
methods
function this = Queue()
end
function push(this,elem)
this.last = this.last+1;
if this.last > numel(this.elems)
elems = [elems;zeros(numel(elems),1)];
end
this.elems(this.last) = elem;
end
function ret = empty(this)
ret = this.last-this.first == 0;
end
function elem = front(this)
if this.empty()
error('Empty Queue');
end
elem = this.elems(this.first+1);
end
function pop(this)
this.first = this.first + 1;
if (this.last-this.first)<0.25*numel(this.elems)
this.elems = this.elems(this.first+1:this.last);
this.first = 0;
this.last = numel(this.elems);
end
end
end
end


It implements push,pop,front and empty. It does some resizing to amortize the costs, but you could also just preallocate with a certain size n.

However, using this as a class is going to be slow. Instead, you should use this as a reference and include the variables elems, first, last in your scope, removing all the this.s. This will be much faster (like 250x times faster).

It wouldn’t be to much work to make this a circular implementation which would then probably reallocate and copy less often. But if you can put an upper bound on the number of pushes then just use that as your initial size (assuming it fits into memory).

Comparing pushing to the back and appending to a matlab array (elems(end+1) = elem) this is equivalent: amortized constant with occasional expensive reallocates.

Comparing to popping from front and slicing out the back of a matlab array (elems = elems(2:end)) this is much faster.

This is really less a lesson about implementing a queue and more an assertion that elems = elems(2:end) causes a lot of reallocation and should be avoided. Things are off the charts worse if you use A(1) = []. Here’s a comparison for popping 10,000 elements:

### MATLAB classes are slow

Wednesday, May 7th, 2014

I was surprised to find out just how much overhead object-orient programming is in matlab. Consider this simple class:

classdef SlowWrapper < handle
properties ( Access = public )
A = [];
next = 0;
end
methods
function this = SlowWrapper(n)
this.A = zeros(n,1);
end
function set_next(this,a)
this.next = this.next+1;
this.A(this.next) = a;
end
end
end


Then if I call set_next 100000 times like this:

slow_wrapper = SlowWrapper(10e5);
tic;
for x = 1:numel(slow_wrapper.A)
slow_wrapper.set_next(x);
end
toc;


I see:

Elapsed time is 24.575752 seconds.


If instead I used primitives outside of a class and use inline code like this:

A = zeros(10e5,1);
next = 0;
tic;
for x = 1:numel(A)
next = next+1;
A(next) = x;
end
toc


I see

Elapsed time is 0.095078 seconds.


That’s a 258x slow down!

Update: Stupidly it’s slightly faster if you use the convention set_next(slow_wrapper,x); instead but only by about a 1.2x improvement.

### Tangible and Modular Input Device for Character Articulation at Emerging Technologies, SIGGRAPH 2014

Friday, May 2nd, 2014

My colleagues, Daniele Panozzo, Oliver Glauser, Cedric Pradalier, Otmar Hilliges, Olga Sorkine-Hornung and I will be presenting our new input device at the Emerging Technologies demo hall at SIGGRAPH 2014. We put our extended abstract on our project page. See you at e-tech!

### Tangible and Modular Input Device for Character Articulation project page

Friday, May 2nd, 2014

My colleagues, Daniele Panozzo, Oliver Glauser, Cedric Pradalier, Otmar Hilliges, Olga Sorkine-Hornung and I have just submitted the camera ready version of paper “Tangible and Modular Input Device for Character Articulation” to be presented at ACM SIGGRAPH 2014. I’ve put up a Tangible and Modular Input Device for Character Articulation page where you can find the preprint version of the article, videos and an OpenHardware description so you can build your own device!

### Abstract

Articulation of 3D characters requires control over many degrees of freedom: a difficult task with standard 2D interfaces. We present a tangible input device composed of interchangeable, hot-pluggable parts. Embedded sensors measure the device’s pose at rates suitable for real-time editing and animation. Splitter parts allow branching to accommodate any skeletal tree. During assembly, the device recognizes topological changes as individual parts or pre-assembled subtrees are plugged and unplugged. A novel semi-automatic registration approach helps the user quickly map the device’s degrees of freedom to a virtual skeleton inside the character. User studies report favorable comparisons to mouse and keyboard interfaces. Our device provides input for character rigging and automatic weight computation, direct skeletal deformation, interaction with physical simulations, and handle-based variational geometric modeling.