[vtkusers] VTK pipeline & rendering strategies

[Andrea Gavana]

Hi David,

I wish I could do that. The CFD simulator spits out result files that are
easily tens of GB of data, and clearly I can't load all that stuff inside
my tool at once. The simulator itself produces smaller "support" output
files that only contain "pointers" to where the results are stored in the
big output files (pointers in the file.seek sense).

Andrea.

On Mon, 28 Nov 2016 at 17:39, David Lonie <david.lonie at kitware.com> wrote:

> +1 to what other Dave said. I'd also point out that you can simply add all
> of the potential scalars you'd like to use to the point/cell/field data as
> named arrays, and then use the vtkMapper::SelectColorArray method to select
> the property to use for visualization.
>
> This way, the threshold/DSSF pipeline would only execute once and will
> produce a dataset with all of the property arrays filtered to just the
> active set. Changing the visible scalars at the mapper level will not cause
> the pipeline to re-execute.
>
> On Mon, Nov 28, 2016 at 7:35 AM, Andrea Gavana <andrea.gavana at gmail.com>
> wrote:
>
> Dear All,
>
>      I am working with some stuff coming out of CFD simulations, and in
> the current work the simulator produces a 3D grid (unstructured grid made
> of hexahedrons). The full grid is about 4 million cells, but due to other
> settings in the simulator the number of "active" cells in the simulation
> ends up being "only" 270,000. In order to visualize all this, I create a
> vtkUnstructuredGrid to hold the full grid, use a vtkThreshold to remove the
> "inactive" cells and then use a vtkDataSetMapper to visualize the resulting
> active grid:
>
> vtkUnstructuredGrid --> vtkThreshold --> vtkDataSetMapper --> vtkActor
>
> However, the rendering speed for the 270,000 cells grid is quite low - it
> takes about one second to display a new property by using SetScalars on the
> output of vtkThreshold. So I thought of using a vtkDataSetSurfaceFilter on
> the output of vtkThreshold to try and speed up the rendering. So, the
> current visualization strategy I have implemented is the following:
>
> vtkUnstructuredGrid --> vtkThreshold --> vtkDataSetSurfaceFilter -->
> vtkPolyDataMapper --> vtkActor
>
> This is still as slow as my first approach, and I also have a couple of
> questions - which stems from my ignorance in VTK things:
>
> 1. When I load (from the simulator outputs) a new property (cell-based)
> and I assign its values to the original vtkUnstructuredGrid (by using
> SetScalars on it), do all the filters (vtkThreshold and
> vtkDataSetSurfaceFilter) need to be re-run? If yes, why? I am not changing
> the active/inactive cells nor the geometry of the grid, only assigning
> different scalars. And, if yes, is there any way to tell the pipeline:
> "look, I've only changed the scalars, there's no need to re-run all the
> thresholds and surface filters *again*"?
>
> 2. Is there any other pipeline style or visualization technique in VTK or
> any settings whatsoever that could bring down the rendering time (memory is
> not that much of a concern)? Basically, what I have a the moment - in terms
> of timing - is as follows:
>
> Reading data from simulator: 0.042 seconds
> Create VTK array with data : 0.002 seconds
> Call to SetScalars         : 0.000 seconds
> Create Lookup Table        : 0.001 seconds
> Render on screen           : about 1 second
>
>
> Thank you in advance for any suggestion, my apologies for the long message.
>
> Andrea.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20161128/86c77b99/attachment.html>