{"id":64,"date":"2014-10-28T09:35:08","date_gmt":"2014-10-28T13:35:08","guid":{"rendered":"https:\/\/blogs.mathworks.com\/graphics\/?p=64"},"modified":"2015-01-20T16:08:51","modified_gmt":"2015-01-20T21:08:51","slug":"makingthingsmove","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/graphics\/2014\/10\/28\/makingthingsmove\/","title":{"rendered":"Making Things Move"},"content":{"rendered":"

After my post about using MATLAB Graphics from Simulink<\/a>, Aditya had a great question about using this technique for 3D animations. This is a really interesting area, and I really wanted to use a 3D example for that post. Unfortunately I couldn't come up with one that was simple enough to fit into that blog post. But if you do decide to explore this area on your own, or even if you're doing 3D animations without Simulink, there are some tricks you should probably know about.<\/p>

Today we're going to look at one technique for getting good performance when you're doing 3D animations with MATLAB Graphics, although this technique can also be useful in 2D in some cases.<\/p>

I don't have a good STL model handy for us to animate, so I'm going to start with some spheres. Well, not spheres really, more like lumpy potatoes.<\/p>

We'll start with a set of random points on the surface of a sphere. The simplest way to do that is to use a random number generator to select random values for latitude and longitude. But that doesn't look very good because you get a lot of points at the poles and not many points at the equator.<\/p>

A better approach is to stretch the distribution using the following transform:<\/p>

$$longitude = 2 \\pi a - pi$$<\/p>

$$latitude = \\cos^{-1}(2 b - 1)$$<\/p>

rng(0)\r\nnpts = 1000;\r\nlon = 2*pi*rand(1,npts) - pi;\r\nlat = acos(2*rand(1,npts) - 1);\r\nx = cos(lon).*cos(lat);\r\ny = cos(lon).*sin(lat);\r\nz = sin(lon);\r\n<\/pre>
Once we have these points, we can draw them using scatter3<\/a>.<\/p>
hs = scatter3(x,y,z,'filled'<\/span>);\r\naxis vis3d<\/span>\r\n<\/pre>\"\" 
But we want surfaces for this example, not points. We can use convhull for this. The convhull command<\/a> gives us the \"convex hull\" of the points. In other words, the smallest, convex polyhedron which encloses all of the points. It returns the polyhedron as a list of triangles which we can pass straight into the patch command like this:<\/p>
ax = gca;\r\ntris = convhull(x,y,z);\r\nh = patch('Faces'<\/span>,tris,'Vertices'<\/span>,[x', y', z']);\r\nh.FaceColor = ax.ColorOrder(2,:);\r\n<\/pre>\"\" 
Let's stop to make that look a little nicer. I wrote the following little helper function because we'll want to make several pictures look the same.<\/p>
function<\/span> init3dview()\r\n  axis vis3d<\/span>\r\n  xlim([-3 3])\r\n  ylim([-3 3])\r\n  zlim([-3 3])\r\n  view(3)\r\n  camlight\r\n<\/pre>
init3dview()\r\nh.EdgeColor = 'none'<\/span>;\r\ndelete(hs);\r\n<\/pre>\"\" 
What is the Greek name for a 1,000 sided polyhedron? A millihedron? Or a kilohedron?<\/p>
Now that we know how to draw these blobs, let's look at how to animate them. The obvious way to do this is to add an offset to the Vertices property in the inner loop. For two blobs moving randomly, that would look something like this:<\/p>
cla\r\nrng(0)\r\nax = gca;\r\n% Create a couple of spheres<\/span>\r\nnspheres = 2;\r\ng = gobjects(1,nspheres);\r\ncolors = ax.ColorOrder;\r\nfor<\/span> i=1:nspheres\r\n    offset = randn(1,3);\r\n    g(i) = patch('Faces'<\/span>,tris,'Vertices'<\/span>,[x',y',z']+repmat(offset,[npts 1]));\r\n    g(i).FaceColor = colors(i,:);\r\n    g(i).EdgeColor = 'none'<\/span>;\r\nend<\/span>\r\ninit3dview()\r\n\r\n% Now move them around by setting the Vertices property<\/span>\r\ntic\r\nfor<\/span> i=1:100\r\n    for<\/span> j=1:nspheres\r\n        offset = randn(1,3)\/100;\r\n        g(j).Vertices = g(j).Vertices + repmat(offset,[npts 1]);\r\n    end<\/span>\r\n    drawnow;\r\nend<\/span>\r\ntoc\r\n<\/pre>
Elapsed time is 2.099485 seconds.\r\n<\/pre>\"\" 
As you can see, the performance isn't bad. I get about 45 frames per second on my machine. But when we're doing animations, we always want to look for more performance. This allows us to animate more complex models, and it also gives us more compute time for our simulation, which might be something a bit more complicated than a random number generator.<\/p>
There's actually a faster way to do this. What's happening when we change the patch's Vertices property is that we're sending all of the new vertices over to the graphics card. When we do this, the memory bandwidth between the memory which the CPU uses and the memory on the graphics card can become a bottleneck.<\/p>
It's much better to park the vertices on the graphics card and just send a small description of the motion. The hgtransform function<\/a> is perfect for this job. It just sends a 4x4 matrix which describes the transformation instead of resending all of the data.<\/p>
cla\r\nrng(0)\r\nax = gca;\r\n% Create a couple of spheres again, put hang them off hgtransform objects.<\/span>\r\nnspheres = 2;\r\ng = gobjects(1,nspheres);\r\ncolors = ax.ColorOrder;\r\nfor<\/span> i=1:nspheres\r\n    offset = randn(1,3);\r\n    % Create an hgtransform<\/span>\r\n    g(i) = hgtransform;\r\n    g(i).Matrix = makehgtform('translate'<\/span>,offset);\r\n    % Use it as the Parent of the patch<\/span>\r\n    p = patch('Faces'<\/span>,tris,'Vertices'<\/span>,[x',y',z'],'Parent'<\/span>,g(i));\r\n    p.FaceColor = colors(i,:);\r\n    p.EdgeColor = 'none'<\/span>;\r\nend<\/span>\r\ninit3dview()\r\n\r\n% Now move them around by setting the Matrix property on the hgtransforms.<\/span>\r\ntic\r\nfor<\/span> i=1:100\r\n    for<\/span> j=1:nspheres\r\n        offset = randn(1,3)\/100;\r\n        g(j).Matrix = g(j).Matrix * makehgtform('translate'<\/span>,offset);\r\n    end<\/span>\r\n    drawnow;\r\nend<\/span>\r\ntoc\r\n<\/pre>
Elapsed time is 0.423583 seconds.\r\n<\/pre>\"\" 
On my machine I get more like 200 frames per second with this approach. Of course the exact performance is a function of a lot of variables such as the number of objects you're animating, the number of triangles in each object, and the type of graphics card in your computer. For example, here's what I get when I vary the number of blobs.<\/p>
\"\" <\/p>
I always like to add that grey line at 24 frames per second to my performance charts. That's because that is roughly the \"flicker fusion rate\"<\/a> of the human visual system. If our animation is slower than that, it will look \"choppy\". So this chart is telling us that things aren't going to look good if we go past 4 blobs with the Vertices property approach, but with the hgtransform approach I can basically use as many as I would like.<\/p>
It also depends which version of MATLAB you're using. For example, this is what I get when I run the same example with R2014a.<\/p>
\"\" <\/p>
But in general this hgtransform approach will be at least as fast as the changing the data approach, and often quite a bit better.<\/p>
So that's a useful thing to know if you want to animate 3D objects, like my caffeinated blobs here.<\/p>
\"\" <\/p>
In future posts we'll discuss other tricks for getting the best performance out of MATLAB Graphics. Do you have some tricks you use?<\/p>