Report: Heat
Kernel Signature
Method 2
We therefore used a more advanced method to
sample the time points. For each model, sample
100 points in the logarithmically scale over the
time interval [tmin, tmax], where:
Dafne van Kuppevelt, Vikram
Doshi, Seçkin Savaşçı
𝑡𝑚𝑖𝑛 =
4 ln 10
𝜆𝑒𝑛𝑑
Introduction
𝑡𝑚𝑎𝑥 =
4 ln 10
𝜆2
Here 𝜆2 is the second eigenvalue and 𝜆𝑒𝑛𝑑 is
the last eigenvalue.
Method
There are several ways to use the Heat Kernel
Signature to compute the distance between
objects. We tried and implemented four
different methods, each being an improvement
on the previous one. In all our methods we
compute a feature vector for each model and
compute the distance between models using
the L2-norm on this feature vectors.
Method 1
Our initial crude method was to compute the
sum of the HKS for all vertices:
𝑁
𝐻𝐾𝑆𝑆𝑢𝑚𝑡 = ∑ 𝑘𝑡 (𝑥, 𝑥)
𝑥=1
We compute this for 8 different t’s, uniformly
sampled on the logarithmic scale on [-4, 2]. This
results in a feature vector of length 8 for each
model.
The disadvantage of this method is that the t’s
are fixed among all models and relatively
arbitrary chosen. Thus the time points may not
be very representative for the model: for
example in a larger model it takes more time
for the heat to spread.
We then again compute 𝐻𝐾𝑆𝑆𝑢𝑚𝑡 for each
time point and retrieve a feature vector of
length 100 for each model. We noticed that the
𝐻𝐾𝑆𝑆𝑢𝑚𝑡 remains almost unchanged for t >
tmax as it is mainly determined by the
eigenvector 𝛷2.
Method 3
We can approximate the HKS by using only 300
eigenvalues and eigenvectors. We then get:
300
𝑘𝑡 (𝑥, 𝑥) = ∑ 𝑒 −𝜆𝑡 𝛷𝑖 (𝑥)𝛷𝑖 (𝑥)
𝑖=1
𝑁
𝐻𝐾𝑆𝑆𝑢𝑚𝑡 = ∑ 𝑘𝑡 (𝑥, 𝑥)
𝑥=1
We again sample the time points on a
logarithmically scale over the time interval
[tmin, tmax], but now
4 ln 10
𝑡𝑚𝑖𝑛 =
𝜆300
This method requires significantly less
computation than the previous method, since
we only need to calculate 300 eigenvalues and
eigenvectors. Also the computation for the HKS
of one vertex takes less time, namely O(300)
instead of O(N).
Method 4
In the previous methods, we sum over all
vertices to get the signature of the complete
model. This means that points on the model are
not compared to corresponding points on
another model. To accomplish this in the fourth
method we find 200 distinct feature points on
the model. These feature points have the
highest local maxima, using multi scaling:
𝑑[𝑡𝑚𝑖𝑛,𝑡𝑚𝑎𝑥] (𝑥, 𝑥 ′ )
𝑡=𝑚𝑎𝑥
𝑘𝑡 (𝑥, 𝑥)
𝑁
∑ 𝑘𝑡 (𝑥, 𝑥 )
𝑡=𝑡𝑚𝑖𝑛 𝑖=1
= ∑
−
− 𝑘𝑡 (𝑥′, 𝑥′)
∑𝑁
𝑖=1 𝑘𝑡 (𝑥′, 𝑥′)
This results in a feature vector of length 200 for
each model.
Implementation
As soon as we became confident and we had a
consensus about the ideas in our reference
paper, we started implementation. Rather than
implementing all sequence together, we divided
our implementation into 4 stages: Initial Parser
is where we compute laplacian matrices from
3D models and eigen values and vectors from
those laplacian matrices; using eigen values and
vectors, we calculate HKS values in HKS
Calculation stage; we focused on matching and
distance calculations in Retrival ; In
Visualization, we visualize our results of HKS.
Initial Parser
Initial parser contains the operations that we
must do only once. These include computation
of laplacian matrices and eigen values &
vectors. The main challenge in this stage is to
find efficient techniques that we can use the
results of this stage in later stages easily.
a. Computing Laplacian Matrices
We thought that it is the best practice to
implement the overall project without using any
external libraries. Our goal was to implement a
method that parses 3d models and outputs
laplacian matrices to text files, one by one. Our
first successful implementation was using
integers for keeping each element of the
resulting laplacian matrix; also it was giving
output in human readable format. But the tests
showed that it was slow and too much space
consuming. Our test cases showed that if we
wanted to parse every model, it would take
more than 2 hours to finish. Also for the largest
models (in terms of vertex count), it would go
beyond x86 address space. To be more precise,
our largest model has 45000 vertices, which
results in a matrix data structure of size
45000 ∗ 45000 ∗ 4 𝐵 = 7.54 𝐺𝐵 which is
greater than our accessible address space (2 GB,
OS restriction) in Windows, also greater than
232 Bytes which we can address in x86.
We come up with a solution; reducing our
matrix and using a bit to represent each
element of the matrix. Laplacian matrix is a
sparse symmetric matrix, where one can
compute the diagonal values by traversing the
corresponding row or column. So we decided to
store only lower triangular part of it and we
omitted the diagonal part because it can be
computed by row traversal. Resulting data –if
these ideas are implemented- was a lower
triangular matrix without the diagonal part; and
by definition of the Laplacian matrix, this part
could only contain -1 or 0. So we replaced -1
with 1, so each element could be stored using a
bit. If program calls an upper triangle’s element
we send the lower part correspondence, and if
the diagonal part elment is needed, we
compute it on the fly. By using this schema, we
were able to parse all files in 2 minutes
including the largest ones that we couldn’t
parse in previous method. To be more precise
again, then we needed only
45000∗44999
2
𝑏𝑖𝑡𝑠 =
120 𝑀𝐵 space for each file. Result was a ~64X
compression.
b. Computing Eigen Vectors & Values
Computing eigen values and vectors is a
challenging problem, because of its high
complexity. As we stated before, at first we
tried to implement our own eigen decomposer.
But after some considerable effort, we didn’t
manage to implement a working version, so we
decided to use a 3rd party library for eigen
decomposition. In literature, there are
specialized techniques - such as Lanczos
algorithm- for different kind of matrices, so we
had to find a good library that fits to our input
laplacian matrices which are sparse symmetric
matrices. Search for a library that had a
specialized eigen decomposer for our type of
matrices failed, so we started to try every
library that we could find on the web, and
evaluated them.
library
Math.NET
DotNumerics
CenterSpace
Eigen(C++)
Time to compute
20+ mins
2 mins
30+ mins
2 hours
Table 3: Evaluation results for 2000 vertex model
Figure 1: Simple Model
Table 1: Our First Implementation
Table 2: Compressed Implementation
Next decision we made is deciding the storage
format for these laplacian matrices. Our first
implementation was giving a human readable
text file, which we converted the values to
strings, added white spaces and line feeds for
readability, but that meant we were making our
parsing time longer because of such formatting;
also we had to come up with a loader that loads
these matrices into memory when we need it.
We eventually decided to serialize our matrix
data to files. With this decision, our resulting
files were no more human-readable, but we
could simply deserialize it in our program and
use it whenever we wanted.
After the evaluation of some libraries, we
decided use DotNumerics library. Using
DotNumerics, we found a solution to eigen
decomposion, but it had some drawbacks in our
project:


We must ignore the largest ~40
matrices: DotNumerics uses double
precision for storing matrix elements,
even if DotNumerics have a symmetric
matrix data storage class, it results in
huge memory need which is more than
x86 architecture can provide for the
largest matrices.
We need to create a library copy of our
laplacian matrices during parsing,
because DotNumerics uses LAPACK
routines under the hood and that
means we cannot use our low -storageneeded matrix format as an input for
Eigen Decomposition Methods.
We also continued using serialization for
outputs of the library. Computed eigen values
and vectors are serialized to corresponding
files.
Retrival
Visualization & Proof of
correctness
Performance
c. An experimental Approach for Future
Implementations
Although we used DotNumerics thru our project
and ignore the largest matrices, we came up
with a prototype for future work. Our prototype
is written in C++ rather than C#, uses Intel Math
Kernel Library©, Boost and a tweaked version
of Armadillo libraries. Prototype parser runs on
x64 architecture, and it takes only 10 seconds to
compute eigen values and eigen vectors of a
2000 vertex model( To remind you,
DotNumerics does the same job in 2 mins). We
had two main reasons for developing this
prototype. At first, today’s CPUs are mostly x64
capable, and we wanted to see how better it
could be if we run the same implementation on
x64. Secondly, an x86 Windows OS limits the
available memory to 2 GB per process; but we
need more memory than that if we want to
parse the largest matrices.
HKS Calculation
Conclusion