animations in CAVE mode

Hi all,

I am new to Paraview and hoping to get some help with animations in ‘cave’ configuration.

I’m starting small with a sample blood flow dataset from ANL: https://www.alcf.anl.gov/user-guides/vis-paraview-red-blood-cell-tutorial.

When moving or scaling the dataset, the interaction is flawlessly smooth. However, stepping through the time series is quite slow, about 1 step/sec, even with geometry caching enabled.

Looking at the timer log, I see the task causing the slowdown is ‘FullRes Data Migration’, taking over half a second every time step. When running locally, I don’t see this step happening and the steps take much less time (~0.01 sec in the timer log after cached).

Any help speeding up this animation would be much appreciated!

Some basic info about my current set up:

  • 35 x “worker” nodes with 16-core Intel Xeon CPU, 2 NVIDIA GTX 1080s, 64 Gb RAM
  • 1 x “master” node, same system config
  • 70 x 4K LG 3D TVs, arranged around a sphere (70 unique viewports)
  • 40 Gbps network between nodes
  • paraview v5.4.1
  • 70 pvserver instances (2 per node, 1 per screen)
  • data mounted from NFS but i have also tried copying to each node with same result - its not much data… yet :slight_smile:

Thanks!

1 Like

This is indeed a limitation of the current implementation. In the current implementation, the geometry caching is done at the wrong end – it’s cached on the data processing side and not on the rendering side. For CAVE, we clone data i.e. all geometry from all ranks is duplicated for each tile so that interactive rendering can happen without data movement. However, since the caching for temporal data happens on the data processing side, the data movement has to happen when timestep is changed.

It’s fixable, but would need some development to move the caching location.

How long would that take to fix ? How can we help

Here is what we see now

Haha! that’s awesome! despite the slow play speed, that’s pretty cool!

I am looking into it now…I need to refresh my memory on some of these components as it’s been a while since I looked at them, but I’ll keep you posted.

Thanks Utkarsh!
Ping if there is anything we can investigate on our end.

status update: I’m making progress. I still need a few more days to make the changes merge ready but things so far are looking promising. Here’s a comparision between 5.6 and paraview with my changes, both using animation caching.

1 Like

Hey,

This work looks amazing!
I am currently trying to display an animation in VR-ParaView using HTC-VIVE, but still could not find the option…
Is that what you guys are working on? If so, when are you plan to release it?
If not, do you guys have any idea whats going on with that?

Thanks in advance,
Lee-or

This is related somehow, but will require more work to work in VR.
This is discussed here : Paraview Animations not working in VR

If you want to test the changes out, the merge-request is here. I still have a few more things to do before this can be merged.

Hi Utkarsh,
and thank you for all your work on this problem.
Was anybody able to actually play the paraview animations (and see with no “flashing”) using the goggles?
Thank you in advance.

@Christos, there’s definitely more work that will follow to ensure there’s no flashing when using goggles that @martink intends to continue working on, however what I am working is the first step.

Hi Utkarsh,
and thank you for your reply.
Do you think there is any workaround or a temporary solution for that?

Hi Utkarsh,
and thank you for your answer.
If I understand correctly no one was able to hit play and actually watch the animation through the goggles using OpenVR, Is that right? Is that a question of libraries? Will use older versions change something?
The only work around I have found (that is not actually a solution) is to move forward one step at a time by clicking with the mouse. Is there any workaround to this issue?

Thank you again.

That is correct, AFAIK.

no, going to older versions of ParaView will not impact this.

There are no workarounds that I am aware of. mr-3597 should land soon. After which, there needs to some more fine tuning on the OpenVR plugin side before animations in VR become fully functional.

Hi @utkarsh.ayachit,

Wow, remote/parallel rendering animations is much faster now, looks fantastic! Many thanks.

I am seeing a new issue in the CAVE, though. When I launch in cave mode, I get a blank white screen on the worker nodes. Client side renders as expected. Any ideas about what could be causing this?

yup, the fix for that is under development here. For a quick fix, just apply this change to VTK and it should overcome this issue. The commit had to be reverted due to some other issues. The MR under development attempts to fix it properly on ParaView side itself.

1 Like

quick fix works. thanks again!

cool! Mind sharing a video of the playback in action? I am curious how it compares to the previous video. thanks!

here’s that same dataset running in the CAVE: