I’ve trying to work around this issue but could not find any solution.
I am using PV5.8 with Ospray to create an animation. In my workflow I have four transform filter which are updated at each step in order to move my objects and save an image.
Unfortunately the memory usage of PV keeps increasing frame after frame up to the point where PV is killed.
At the begiining I was using the animation view to update the transform filters and save the animation. I found some old messages explaining it could be buggy, so I moved to a more manual process where I creater a python script that changes the transform filters and write an image.
After loading a state file I have this code:
t1 = FindSource('transform1')
t2 = FindSource('transform2')
t3 = FindSource('transform3')
t4 = FindSource('transform4')
# save animation
print("Saving animation...")
nbOfSteps = 200
for t in range(0, nbOfSteps):
t1.Transform.Rotate = [0.0, -t*100./nbOfSteps, 0.0]
t2.Transform.Rotate = [0.0, -t*100./nbOfSteps, 0.0]
t3.Transform.Rotate = [0.0, 0.0, t*10./nbOfSteps]
t4.Transform.Rotate = [0.0, -t*10./nbOfSteps, 0.0]
renderView1.Update()
WriteImage('./Anim/frame_'+str(int(t))+'.png')
Unfortunatly even like this, the memory usage is still increasing.
Interestingly, if I remove the update of t1 and t2 on which I applied an Ospray material, then I don’t have memory issues anymore! The two other transforms t3 and t4 have a texture on them and not a material.
Did someone already have issues combining PV animations and Ospray materials?
Hey Vincent, OSPRay is a memory and CPU hog. The kitware people can probably provide better answers but here are a couple simple things I’ve found that help:
• Instead of extract block, use extract surface and only load in cell arrays/etc that are actually needed
• Run your python script with pvbatch instead launching it with python
• Also, instead of actually transforming the geometry, can you just change the view for each timestep? That will be a significantly less memory intensive process.
Thanks Marston for tips and tricks. Indeed I am using pvbatch but that did not help in that case.
I will try to change the view instead of transforming the object to see if it helps.
However, I think I found something interesting. Up to now I was using “Value index” on the two transforms that was causing issues in my initial post. If I put an aluminum material on them, and run the exact same animation I don’t have memory issues anymore. I also use the same look up table of other objects in my scene, but I don’t transform these ones and thus I don’t have any memory issues with them either.
So it looks like the combination of the “value index” and the transform might duplicate some objects in memory and not free them when they should.
I’ll try to reproduce this issue on a simple case that I could share.
@Dave_DeMarle I can confirm the issue is related somehow to the use of the value indexed material.
Here are three files, one python script that can be ran with pvbatch and two state files. One state file is using the aluminum as material and the other one is using the value indexed with the value 0 being aluminum.
It ends up the direct use of aluminum material is working fine while the indirect use of it through the value indexed causes memory to grow frame after frame. Although the case is rather small you can clearly see the increase in memory usage through the first ten steps.
You can comment/uncomment lines in the python script to switch between the two state files.
N.B: you may need to change the path towards materials in the state file to make it work I guess.