vtkCompositePolyDataMapper2 with very large numbers of blocks slow

Support
1

We have some cases that will have > 50,000 blocks in the input to vtkCompositePolyDataMapper2. Should we expect to see inefficiencies in rendering speed in particular (e.g. camera rotation)? We could modify the code that writes this data to combine the blocks into say < 50 - should we expect that to help? The cell count would remain the same so not clear to us.

2

Hi Ben, 50,000 is a large number of blocks, so I wouldn’t be surprised you are running into overhead that affects rendering speed. If you can reduce the number of blocks as described with the same number of cells, that should improve rendering speed dramatically.

3

We have had projects where tens of thousands of blocks are common and have been able to get interactive rendering.

  1. What is your framerate need? Is this for VR? Are the block geometries or field values changing frequently?
  2. Have you benchmarked to see where the actual time is spent? We had some issues with geometry uploads to the GPU occurring more frequently than needed, We have also seen some issues on macos with line-rendering becoming very slow that are unrelated to dataset complexity (line thicknesses > 1 cause trouble). But once we worked through these performance was acceptable. Going to multiple hundreds-of-thousands of blocks could cause problems.
4

David,

Profiling is ongoing so nothing to report just yet. We did a trial run of massaging the data ahead of time reducing the # of blocks from 35k to 20 (yes, two-zero) and saw about a 3x improvement in frame rate.

We would be okay with 5+ FPS - but unfortunately many of our systems lack true GPUs so have to rely on Mesa. Currently we are seeing around ~0.5 FPS with 35k blocks.

5

If your geometry does not change from frame to frame, you should mark it as static no pipeline updates can be omitted for each render.

6

I’m not familiar with that. Can you point me at the API?

7

Here is the method in vtkMapper, which the composite mapper inherits.

8

David - thanks. That doesn’t appear to be our issue - we are pretty careful about managing geometry updates (e.g. marking mappers as Modified). We tried calling StaticOn and it had no measurable impact on FPS.

Our real issue here is lack of GPU on many systems our customers use so we are fighting an uphill battle.

9

Until you have some concrete performance measurements, there’s not much I can say. I’ve learned the hard way not to assume I know what the source of the performance problem is…