Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

anim8.m plays the vizualisation slower than the choosen speed. #36

Closed
Ipuch opened this issue Dec 20, 2018 · 6 comments
Closed

anim8.m plays the vizualisation slower than the choosen speed. #36

Ipuch opened this issue Dec 20, 2018 · 6 comments
Labels

Comments

@Ipuch
Copy link

Ipuch commented Dec 20, 2018

Hi,

I tried to use your useful anim8 tool to vizualise my musculoskeletal simulation of CusToM. I used it on Matlab 2018a, on a Windows 10 with the following config:
image

However the function is not playing the simulation at real speed. Do you have any idea how to do it ?

One of my explanation is that the animStruct is too large to be handle by the anim8.m function.

tuto2_muscleforce

Here it is the link with a zip of the figure and the animStruct.
Best regards,

Pierre

@Kevin-Mattheus-Moerman
Copy link
Member

Hi @Ipuch thanks for using GIBBON and for testing anim8. The short answer to your question is to speed things up by grouping things together into a single handle or a single one property. The long answer is below.

You've probably found the timing setting icon on the top left right? Using this button you can set the pause time between frames:
screenshot from 2018-12-21 09-27-37
Set the time step to 0 to see what your current maximum speed is. The maximum speed at which the animation can play is limited by the speed of your computer and the amount of stuff MATLAB needs to for each time step. For each step it needs to loop over and update all the properties (i.e. set stuff like 'XData' , 'Color'). It seems you have formulated the animation using:

  1. Many time steps (203)
  2. Many properties and handles (610)

First of all skipping every second step would speed things up. However I can imagine one would not like to do that. Instead you could try to reduce the number of properties/handles you vary. Essentially it seems to be you are altering only 2 things, coordinates, and colors. If you can frame this using 2 handles you can achieve the maximum speed. So you should try to "group" things together. In the HELP_anim8 example below I animate a bouncing bunny consisting of e.g. 12144 faces and 6074 vertices. I can however animate it rapidly because a single handle (the graphics handle to the bunny patch object) is used for only 3 properties 'FaceColor','Vertices','FaceAlpha'. So I can change color, coordinates and transparency at a good speed. If I had tried to control the positions/properties of each face or vertex using a separate handle this would never have worked as efficiently due to the looping required.

figure4

For this bunny I create the plot using: hp=gpatch(F,V,'b'). This type of graphics object (patch graphics) is very versatile and handy because you can changes 'Vertices' in one go (so you do not need to set 'XData', 'YData', and 'ZData'). Also it has 'CData' allowing you to colormap the color of faces and/or edges. (see HELP_gpatch). Although usually F represents faces, you can also have it represent edges. E.g. you could define the entire wireframe skeleton using a nx2 array E (edges) and an mx3 array V (Vertices). Next you could use hp=gpatch(E,V,C);, here C could be 'b' for blue or 'k' for black but you can also spatially vary color by making it a vertex color array. I.e. set it as a mx1 array if you want it to be colormapped or as a mx3 array if it is to represent RGB colors.
See the demo DEMO_febio_0009_cube_discrete_springs, at the end it renders 1000 edges like this:
figure3

Looking at your simulation perhaps you can group things into:

  1. 1 skeleton handle with the property 'Vertices' changing in time
  2. 1 point set handle where you change 'XData', 'YData', and 'ZData' in time
  3. 1 vector (quiver) handle where you change I think 3 properties.

So perhaps you only have 7 things to update over time in this way.

BTW your quiver vectors can also be created using patch graphics see also HELP_quiverVec (which provides 3D vectors that are colormapped too and it allows you to change 'Vertices' too).

Let me know if this helps.

@Ipuch
Copy link
Author

Ipuch commented Jan 3, 2019

Thank you for your quick and complete answer.

Indeed, I had many time steps and many handles. I had 203 time steps at 200Hz which gave 1.01 sec simulations.

Here it is what I've tried to get real time vizualisation:

  • I set pause time of the anim8.m cFigure to 0. I didn't succeed to get real-time visualisation.

  • I reduced the number of vizualised objects. I only "gpatched" experimental markers in blue and models markers in orange. I didn't succeed to get real-time visualisation.

  • I gathered markers (blue ones and orange ones separetely) in the same object, allowing me to do only two gpatch by frames. I didn't succeed to get real-time visualisation.

  • I divided the frame rate by 5 and reduced the order of the geosphere from 3 to 1. And it seems like I had faster visualisation.

Here is some extra steps, I've tried.

  • I gathered orange and blue markers in the same gpatch.
  • I used two gpatch to generate the skeleton and the muscles.
  • I used quiver3Dpatch to create external forces data (measured and predicted). Changing only Vertices in the AnimStruct as you recommended.

At the end, it seems like it is more than two time faster than the previous visualisation for the same frame rate at 200Hz.
figure3


Subsequent questions:

  • Is there an easy way to verify if my "anim8.m" visualisation is real-time ?
  • Is there a systematic to way to export the gif ensuring its frame rate ?
  • How can I save a cFigure and an anim8 visualisation to open it later with Matlab?

@Kevin-Mattheus-Moerman
Copy link
Member

Sounds like you are getting there. Using large markers for the points rather than actual spheres will be faster than. You could use patch graphics for markers in this way (note the use of a giant dummy face):

cFigure; 
f=1:1:size(V,1); %Dummy face so we can use patch but face is not plotted as color is off
% C=rand(size(V,1),1); %Colormapped colors
C=rand(size(V,1),3); %nx3 RGB color array, e.g. [1 0 0] is red
hp=patch('Faces',f,'Vertices',V,'FaceColor','none','FaceVertexCData',C,'EdgeColor','none');
hp.Marker='o';
hp.MarkerFaceColor='flat';
hp.MarkerEdgeColor='k';
hp.MarkerSize=25;
axisGeom; 
drawnow;

Then you can update the vertices with hp.Vertices. The array C can be used to define RGB colors (which in your face do not change in time).

Is there an easy way to verify if my "anim8.m" visualisation is real-time ?

Since we are using MATLAB to actually draw all the graphics things in real time, as fast as we can, this is really difficult. It depends on your system and how your system resources are currently used. In the anim8 function I use a pause time which is corrected for by the amount of time the graphics updating took. If the update was fast we wait up to the desired time value. However if the graphics update took longer than the desired pause time the code will not wait and quickly move on. I suppose I could create a real time step indicator on the figure. If that time step matches the desired it is truly real time. If something like this sounds good, could you open a feature request issue for this?
Note that an alternative would be to grab screenshots using code and to play this in real time. That would be feasible as one would just be updating a picture in real time. However I think the benefit and purpose of anim8 is to remain 3D and interactive so we can pan/zoom/rotate the view while it is playing. That, I suppose, comes at the cost of extra computational time.

Is there a systematic to way to export the gif ensuring its frame rate ?

Yes. The export figure widget can be used to export a gif animation (it relies on export_fig). It is activated by the gif icon on the right. The gif export uses the actual desired pause time (not the one resulting from graphics updating issue) as the pause time between gif frames. These gifs should then play in real time (provided the image resolution is not too high such that your system is able to update frames at the desired speed).

gifexport

How can I save a cFigure and an anim8 visualisation to open it later with Matlab?

I have done this before so would need to dig it up, it is not difficult to do. Currently saving the figure does not save my custom GUI items so it does not work. However if we save the anim8 structure as well as the figure we can restore everything again by calling the anim8 function again. Something like this could function as a save/import operation for anim8 stuff. If you want this, would you be able to post this as a feature request?

@Kevin-Mattheus-Moerman
Copy link
Member

Any luck with this? Let me know how you are getting on.

@Ipuch
Copy link
Author

Ipuch commented Jan 14, 2019

Thank you again for the tip and everything.
However, I previously choose the spheres because of this issue with the markers.

viz1
viz2

When using this visualization it looks cartoon-like. However, when I zoom in, the markersize is not function of the zoom. So there is a lack of 3D visualization when using markers. Unless you know an easy way to update the size ?
Anyway, it goes faster, so i may keep it !

I suppose I could create a real time step indicator on the figure. If that time step matches the desired it is truly real time. If something like this sounds good, could you open a feature request issue for this?

Yes.

However I think the benefit and purpose of anim8 is to remain 3D and interactive so we can pan/zoom/rotate the view while it is playing. That, I suppose, comes at the cost of extra computational time.

I agree.

These gifs should then play in real time

I didn't succeed to generate real-time gif.

Something like this could function as a save/import operation for anim8 stuff. If you want this, would you be able to post this as a feature request?

Yes !

Can you tell me how to post a feature request ?

@Kevin-Mattheus-Moerman
Copy link
Member

By feature request I meant to open an issue here where you ask for that feature.

About the markers. Yes I think markers are line/dot data which matlab appears to draw as a certain number of pixels rather than a fixed size, so yeah they change size when you zoom.

BTW if you not like that the markers have edges drawn you can do hp.MarkerEdgeColor='none'(if hp is the handle for the patch object).

Alternatively you could draw the markers using patch data but base them on a Platonic solid (see HELP_platonic_solid) so you'll have 4 faces (tetrahedron) up to the 20 face icosahedron.

I'll close this issue for now but let me know if you need more help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants