[vtkusers] VTK pipeline & rendering strategies
Andrea Gavana
andrea.gavana at gmail.com
Tue Nov 29 10:00:14 EST 2016
Hi Ken,
On 29 November 2016 at 15:42, Ken Martin <ken.martin at kitware.com> wrote:
> When talking rendering times it is helpful to specify if you are talking
> first frame or subsequent frame times. As others have mentioned the first
> frame time can include executing the entire pipeline plus building a number
> of rendering structures etc. The subsequent render time is the time after
> all of that prep has been done and can be quite different. Knowing what
> time you are talking about helps us figure out what the issue could be. If
> you change the data then, you are back to a first frame time typically.
>
> 270K cells is trivially small from a subsequent frame render time
> perspective. Building those structures from a 4 million cell unstructured
> grid though I could see taking a second on the first frame. ala
>
> yourLastFilter->Update() // pipeline calc time
> renWin->Render() // first frame render time
> for (int i = 0; i < 500; i++)
> {
> // no data changes here
> renWin->Render(); // subsequent frame render time
> }
>
>
>
The timing are all taken after the first rendering. I have a little GUI
with a VTK render window and a single button. Every time I press the button
new data is randomly generated and I time the rendering only process, i.e.:
grid.GetCellData().SetScalars(data)
grid.Modified()
renwin.Render()
And I have a little rendering listener setup like this:
renderer.AddObserver(vtk.vtkCommand.EndEvent, self.OnEndEvent)
def OnEndEvent(self, caller, dummy1=None, dummy2=None, dummy3=None):
timeInSeconds = caller.GetLastRenderTimeInSeconds()
fps = 1.0/timeInSeconds
print timeInSeconds, fps
However, I realized that the simulator outputs the grid with a lot of
redundant information - i.e., duplicated points. So I did the following:
clean = vtk.vtkExtractUnstructuredGrid()
clean.SetInputData(grid.GetOutput())
clean.MergingOn()
clean.CellClippingOn()
clean.SetCellMinimum(0)
clean.SetCellMaximum(nx*ny*nz)
clean.Update()
the "clean" grid contains far far far less points than the original one (as
the coincident points have been merged), and the rendering is much faster -
about 0.24 seconds or 4.2 fps. Now, if there was a way to tell the
rendering engine to ignore the points (i.e., don't render the points, I
only care about the cells...) that would be even better :-) .
Thank you again for all your hints.
Andrea.
>
>
>
> On Tue, Nov 29, 2016 at 3:39 AM, Andrea Gavana <andrea.gavana at gmail.com>
> wrote:
>
>> Dear All,
>>
>>
>> On 28 November 2016 at 16:12, Andrea Gavana <andrea.gavana at gmail.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> thank you for your answer. I will put some more comments inline too.
>>> Any insight or suggestion is more than welcome.
>>>
>>> On 28 November 2016 at 15:40, David E DeMarle wrote:
>>>
>>>> Responses inline. Mostly though, make sure you are using the "OpenGL2"
>>>> rendering backend, which is the default for 7.0 and 7.1.
>>>>
>>>
>>>
>>> I am using VTK 7.0 through the Python bindings (the official ones from
>>> the Kitware website here:
>>>
>>> http://www.vtk.org/download/
>>>
>>>
>>> So I was assuming that the rendering backend was already OpenGL2... is
>>> there any way to check if this is really the case?
>>>
>>> Also, I have tried to load my dataset in ParaView, and ParaView seems to
>>> be doing some kind of black magic on my vtkUnstructuredGrid as I get these
>>> kind of messages when I load the vtk file:
>>>
>>> Warning: In C:\bbd\df0abce0\source-paraview\VTK\Rendering\VolumeOpenGL2\
>>> vtkOpenGLProjectedTetrahedraMapper.cxx, line 251
>>>
>>> vtkOpenGLProjectedTetrahedraMapper (000000000D3CAA60): Missing FBO
>>> support. The algorithm may produce visual artifacts.
>>>
>>>
>>>
>>>
>>> Which, I believe, is telling me that ParaView is not doing what I am
>>> doing but maybe using some kind of volume-based rendering - when I rotate
>>> the grid the (almost cube-shaped) cells becomes subdivided in small
>>> triangles, when I stop interacting with them they go back to their normal
>>> appearance. It would be nice to know what ParaView is doing though, and
>>> also what "FBO support" means :-). I also noticed that ParaView is slightly
>>> faster in changing the displayed property - maybe 2 or 3 times faster than
>>> my bare-bone script.
>>>
>>>
>>>
>>
>> Just to add some more information: it is true that ParaView is faster in
>> the re-rendering when I switch to another property, but it also shows heavy
>> visual artifacts (i.e., cells with multiple colors in them?!? - see
>> attached screenshot). So, if I understood it correctly, ParaView uses some
>> kind of volume rendering of my vtkUnstructuredGrid (although I didn't ask
>> it to... should it not use the default vtkDataSetMapper?).
>>
>> Based on my original pipeline:
>>
>> vtkUnstructuredGrid --> vtkThreshold --> vtkDataSetMapper --> vtkActor
>>
>> I have tried everything I know to speed up the re-rendering of the grid,
>> I actually operate directly on the output of vtkThreshold (that is still a
>> vtkUnstructuredGrid), so I simply throw away the original grid. With and
>> without ImmediateModeRendering, with and without backface culling. My best
>> improvements so far took the rendering time from 1.04 seconds to 0.94
>> seconds... so not much of an improvement :-) .
>>
>> I am of course open to any suggestions anyone may have on the rendering
>> part - assuming that my geometry is fixed (it is not, but I'll worry about
>> that later...), basically only on the process:
>>
>> vtkUnstructuredGrid.SetScalars(my_data)
>> vtkUnstructuredGrid.Modified()
>> vtkRenderWindow.Render()
>>
>> And of course - if there are other visualization strategies I may use,
>> please shout :-)
>>
>> Thank you.
>>
>> Andrea.
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> 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:
>>>>>
>>>>>
>>>> DataSetMapper internally does vtkDataSetSurfaceFilter->vtkPolyDataMapper
>>>> when given something other than PolyData, so not surprising that it isn't
>>>> faster.
>>>>
>>>>
>>>>> 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*"?
>>>>>
>>>>>
>>>> Yes they do, since the Executive classes' Modified time tracking is not
>>>> fine grained enough to know the difference, and few if any of the filters
>>>> would know how to update just the changed portions.
>>>>
>>>>
>>>>> 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:
>>>>>
>>>>>
>>>> Yes, use OpenGL"2". Modern OpenGL programming techniques make it up to
>>>> hundreds of times faster than the Legacy fixed function "OpenGL" backend.
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee. Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20161129/03bfc0db/attachment-0001.html>
More information about the vtkusers
mailing list