Document animation : Performance issue

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
mario52
Veteran
Posts: 4673
Joined: Wed May 16, 2012 2:13 pm

Re: Document animation

Post by mario52 »

hi
i cleaning your macro (without modify your formules)

modify the line

Code: Select all

 inputAngle = i * 10                                      # modify this value for vitesse 

for the speed (here i * 10, modify example i * 50)

Code: Select all

import FreeCAD, FreeCADGui, Part
from FreeCAD import Base
from PySide import QtCore
import math

global inputAngle
global SateliteRaduis

def updateScene():
	global SateliteRaduis
	global inputAngle
	factor = inputAngle / (1.0 + N1 / N3)
	outputAngle = N1 / N3 * factor ;
	SateliteAngle = (N1 / N3 - N1 / N2)*factor;
	outputAngleRad=outputAngle * 3.141592618/180.0;
	
	FreeCAD.activeDocument().getObject("Fusion").Placement = App.Placement(App.Vector(0,0,0),App.Rotation(App.Vector(1,0,0),inputAngle));
	FreeCAD.activeDocument().getObject("Fusion002").Placement = App.Placement(App.Vector(0,0,0),App.Rotation(App.Vector(1,0,0),outputAngle));
	FreeCAD.activeDocument().getObject("Fusion001").Placement = App.Placement(
		App.Vector(0,-SateliteRaduis*math.sin(outputAngleRad),SateliteRaduis*math.cos(outputAngleRad)),
		App.Rotation(App.Vector(1,0,0),SateliteAngle));

N1 = 11.0;
N2 = 15.0;
N3 = N1 + 2 * N2;
inputAngle=0.0
module=FreeCAD.activeDocument().getObject("InvoluteGear").module
SateliteRaduis = (N1+N2)*module/2.0 ;

for i in range(360):    # number turn
    updateScene();
    inputAngle = i * 20                                      # modify this value for vitesse    
    print i
    Gui.updateGui()                                        # rafraichi l'ecran
    FreeCADGui.updateGui()                                 # rafraichi l'ecran

here other idea for code Faire pivoter sur 360° and other if search "animation"

mario
Maybe you need a special feature, go into Macros_recipes and Code_snippets, Topological_data_scripting.
My macros on Gist.github here complete macros Wiki and forum.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: Document animation

Post by plgarcia »

Hello,

The Idea is not to implement the formulas in python what I know is working fine, but using the formulas in the model.

My scrpt (not perfect at all) is using timers to have normally the same speed whatever the speed of the computer. But it is not the purpose of this post.

To make more clear I will cut my script in 2.
- One version not using the formulas and calculations in python (in fact the one as you modify is probably fine).
- One relying on the formulas, then not calculating in python the position of the Out shaft and Fusion001 because the formulas in the model should do that.
- I also changed the programs and model not to end-up with an negative angle for Fusion001 orientation that inverts the axis of the rotation (the explanation of the +360 in the previous formula).

https://www.dropbox.com/s/tfwbw9xwtig01 ... FCStd?dl=0

The problem is that the second one either do not work or is very slow when uncommenting line 70. My purpose is that there should be a way to use formulas almost as efficient as not using them.

That is a FreeCAD optimisation matter (or use of the appropriate functions) not a matter of optimizing the script itself.

As far as I know, this can not work with a 0.16 version of FreeCAD as a bug about angle in formula has been solved in the 0.17, and I do not think it has been reported to the 0.16.
animGearExampleNoFormulas.FCMacro
(2.65 KiB) Downloaded 51 times
animGearExampleWithFormulas.FCMacro
(2.34 KiB) Downloaded 48 times
I make some videos hopefully tonight.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: Document animation

Post by plgarcia »

Ok here is a short Video:

1 run the script with formulas and no recompute.
You can see that only the inShaft moves, but the colors of In shaft, out shat and Fusion001 are greyed (a bug for sure) but in this case that formulas have robably been evaluated but the objets have not been relocated on the view.

The second is entirely control by python. Obviously the capture tool I use too many ressources. It is usually more smooth.

Then I have modified the script using Formulas (the first one) to add recompute and start it. It works, the objects are weel positionned (as long as the angle stay small and are not altered by the conversion in quaternion), the formulas are right, but it is slow.

Here is the video.
Sory I removed the video as its size is 1.7 Gb.

Regards
Pascal Garcia
Last edited by plgarcia on Tue Nov 21, 2017 9:29 am, edited 1 time in total.
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Document animation

Post by eivindkvedalen »

plgarcia wrote: Mon Nov 20, 2017 4:23 pm Ok here is a short Video:

1 run the script with formulas and no recompute.
You can see that only the inShaft moves, but the colors of In shaft, out shat and Fusion001 are greyed (a bug for sure) but in this case that formulas have robably been evaluated but the objets have not been relocated on the view.

The second is entirely control by python. Obviously the capture tool I use too many ressources. It is usually more smooth.

Then I have modified the script using Formulas (the first one) to add recompute and start it. It works, the objects are weel positionned, the formulas are right, but it is slow.
I've now tested your file and macro, and see that it is slow when recomputed. This is because with formulas, no shortcuts are taken, and necessary objects are recomputed. So from this perspective every thing works as expected. Now, I have tried to replace the fusions with compounds, and that speeds things up quite a bit (but I haven't compared to your non-formula version).

I think the fact that changing orientation or location of a fusion triggers a complete recompute is something that should be looked into, because as it does not change the shape, there should be no reason to actually do the new boolean operation (I haven't confirmed that this is actually what happens, but because the recompute operation is so slow, I assume OCC's boolean functions are invoked).

Eivind
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: Document animation

Post by plgarcia »

I completely agree with that.
The script and model can be optimized that’s obvious.
But I should be able to get almost the same performances with formulas or with everything computed in the macro.
If not it is because there is some unnecessary processing triggered, and that should be looked at.

I made the same changes on my side and performances is far better.

Shall I report a bug for this unnecessary calultaions ?

Shall I also report a bug for the problem of colors lost as soon as the Placement of some kinds of parts (boolean agregation compound and may be others) is changed either by hand, formulas or macros ?
Last edited by plgarcia on Wed Nov 22, 2017 10:35 pm, edited 1 time in total.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: Document animation

Post by plgarcia »

I modified the macros not to rely on timer that should make execution time constant
3600 executions ar done on my PC
- in 11,8 seconds without formulas and therefore no recompute.
- in 66,8 seconf with formulas and therefore with recompute

Performance is better but significantly affected.

https://www.dropbox.com/s/eaznsq29jy2b8 ... FCStd?dl=0
animGearExampleNoFormulas2.FCMacro
(2.92 KiB) Downloaded 46 times
animGearExampleWithFormulas.FCMacro
(2.34 KiB) Downloaded 41 times
Using formulas works slowly but the position of the objects is correct as long as the angle of In is <360°. After the transformation in quatenion changes the direction of the orientation and the value of the angle. That is why one can see these oscilations. That is the object of the pull request I made, and I build this example to illustrate that.
Ugarciaz
Posts: 1
Joined: Mon Mar 25, 2019 8:34 pm

Re: Document animation

Post by Ugarciaz »

microelly2 wrote: Mon Nov 20, 2017 7:29 am One first idea is to use clones of your parts instead of the fusions itself.
Animation will become slow if the models are complex,
I store the pictures of each step into a file and create a video clip after the slow animation
here an example:
phpBB [video]
Hi microelly2 im developing some animation in order to make some virtual commissioning videos and as you said the more complex my models are the more slow it behaves, so im wondering if you have some tips i can apply to have a better performance. Im using freecad 0.17 on windows platform and i have used the clone tool to make it simple. I have seen that when i have a model but it isnt compound in order to make a kinematic chain dependency its animation is ok, however when i apply the compound tool automatically it slows the animation. Many thanks for the animation tool.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: Document animation : Performance issue

Post by plgarcia »

Hello,
Sorry for that late answer.
Yes the issue is still the same.
The problem with the angles is solved for quite a long time now. However, it is not your problem.

Performance issues are of different type:
- The performance of open cascade first. The idea is then to use parts that Open Cascade processes quicker as a clone instead of a more complex part.
- The way the FreeCAD triggers the calculations.

When using constraints and formula it seems that calculations are triggered many times, or at least were triggered many times by the time I made some analysis. I am not sure that when using constraints there is a way to avoid that, as all parts may need to be in the right position to apply further constraints. At least, this can surely be optimized.

In the example I provided, I animate in two different ways:
- Setting all constraints and formulas in the model, and this is very slow.
- Setting no constraints and no formula, what leads to better performances.

With no formulas the positions of the different parts are all set by the script, by setting attributes to the different moving parts. Therefore the script has to know about the geometry of the scene (in the updateScene() function). In this case, FreCAD calculations are triggered only once when all positions are set, what avoid any multiple calculations, and the speed in this example is ok.

Improving the speed and performances requires quite an important restructuring of FreeCAD, that is an important effort and some organization and agreements needs to be setup before.

Regards
Pascal Garcia
bleber
Posts: 259
Joined: Thu Jun 30, 2016 5:12 pm

Re: Document animation : Performance issue

Post by bleber »

Hi.
I suggest to use a more dedicated program to animate, export to Blender and you can animate with pithon or a game engine integrated, and if you like make a video.
Search for or go to https://www.blender.org, free and opes source.
plgarcia
Posts: 310
Joined: Wed Jun 17, 2015 9:47 pm
Location: Near Paris (France)

Re: Document animation : Performance issue

Post by plgarcia »

Hello,
I agree when you want god animation FreeCAD will never be the right tool for that. You will not make Shrek movie with FreeCAD.

But When you are designing something it is quite interesting to make some animations, moving the different parts around to see if every fits, if what you design can be mounted, if when moving there are unforeseen collisions, etc.

FreeCAD is a design tool that should be capable of that.

About one year ago I had quite a close look to the code and spent hundreds of hours starting some restructuring tests, and my very strong belief at this stage is that FreeCAD needs some software redesign so improve different things, management of the colors, different glitches, unnecessary multiple calculations in different cases that leads to lack of performances emphasized by the poor OpenCascade performances.

I also think that an abstraction layer to the underlying 3D Engine OpenCascade should be introduced to be able to:
- centralize everything related to the 3D engine,
- Improving the usage of the engine
- eventually replace OpenCascade by other 3D engine bringing better performances and having less glitches, and eventually leave the choice to the user of the 3D Engine.

OpenCascade does not provide yet any support to the use of GPU such as Cuda.

That are just my views but it would be a heavy job to do that kind of restructuring, that would need the support of experienced people in software design and architecture.

Regards
Pascal Garcia
Post Reply