# Efficient data storage for real-time simulation

2 views (last 30 days)
Linus on 20 Mar 2013
I am currently working on a real-time simulation using MATLAB and MEX-files. I have a triangulated mesh of ~2000 vertices and ~4000 faces stored in two matrices v (Nx3, N:number of vertices and 3-dimensions) and f. I am using a mass-spring model to simulate deformations, for which I am constantly pulling and inserting data from the vertex matrix v to calculate displacements, distances, spring-forces etc. The reason why I am storing in Nx3 format is to be able to plot using trisurf(f,v(:,1), v(:,2), v(:,3)).
I am currently not reaching my target updates of 20 iterations/sec (currently around ~11 iterations/sec) and the profiler does not really target any specific area in the code for improvement. I am wondering if maybe a different approach to store the vertices may be more efficient? E.g. storing the vertices in a 3*Nx1 long vector instead. This would not make it suitable for trisurf though. Thoughts or comments?
Current version, pseudo-code:
for t=1:T
for i = 1:N
%Pull vertex i
xi = v(i,:); %xi = [x_i y_i z_i]
for k = 1:numConn(i) %number of connections numConn(i) is precomputed
%Pull a vertex
j=connection(k,i); %j equals a row in v, i.e a vertex
xj=v(j,:);
%Distance
xij=xi-xj;
d = sqrt(xij*xij');
end
...
%Update
v(i,:)=v(i,)+f(d,xi,vj,t);
end
%Plot
trisurf(f,v(:,1),v(:,2),v(:,3));
drawnow;
end
Linus on 21 Mar 2013
Edited: Linus on 21 Mar 2013
It is true that the 1:numConn(i) loop contains the most expensive calculations, however, the loop is short as the numConn(i) is ususally less than 20 (meaning that each vertex is connected to roughly 20 other vertices) and I am not sure if threading this part may actually produce a speedup. As of now I am wondering if I should let MATLAB do all the pre-processing and drawing, leaving the actual mass-spring calculations and post-processing to MEX-files. I think that rearranging v into a vector instead of a matrix would improve cache-performance as lookups become more local.

Wouter on 20 Mar 2013
You could try to update these lines:
trisurf(f,v(:,1),v(:,2),v(:,3));
drawnow;
Into:
if ~exist('htri','var')
htri = trisurf(f,v(:,1),v(:,2),v(:,3));
else
set(htri,'vertices',v); % use if faces (f) do not change
% set(htri,'vertices',v,'faces',f); % use if both vertices
% % and faces change
end
drawnow
This might be faster as you then do not run the entire trisurf function again.
Linus on 20 Mar 2013
Edited: Linus on 20 Mar 2013
You are correct, the connections stay the same and are pre-computed. It is not possible to vectorize the inner-loop completely (and vectorizing smaller parts actually makes it slower, probably because of JIT). The connections between vertices are not "well-structured" i.e. there does not exist a "connection pattern" between vertices. I have updated the pseudo-code.

Linus on 12 Apr 2013
The solution I went with was rewriting the most time-consuming parts into MEX-files. This gave me a 2x increase which put the bottleneck on the drawnow command (this matter is thus solved). I will accept Wouter's answer since it was indeed helpful.