[vtkusers] VTK pipeline & rendering strategies
Ken Martin
ken.martin at kitware.com
Wed Nov 30 09:20:51 EST 2016
OK, so for that use case you could be rerunning the pipeline every time and
you want to minimize that. My suggestion would be
1) if it fits in memory (say 4 gig) then precompute all the
timesteps/frames, storing each in a polydata/mapper/actor and then turn on
the visibility of the timestep you want, keep all the actors in the
renderer, just change visibility so that one is on at a time.
2) make sure you only have the points you need. Aka
lastFilter->GetOutput()->GetPoints()->GetNumberOfPoints(), given that you
are starting with a 4 million cell mesh you want to make sure all those
points are not still around. If they are you need to use a filter to remove
them so you only have the points needed. All points get sent to the
graphics card so this can make a big difference if you prune unused points.
3) if possible reuse parts of your pipeline/data, insert your scalars as
close to the end as you can. Even for (1) this will save memory.
4) if all your timesteps are bigger than 4gig, but would fit in main
memory, then precompute all the PolyData's for them and then just change
the mapper->SetInput() each frame. This will be slower than (1) as the data
will be uploaded to the graphics card each frame, but at least the pipeline
computation part will be skipped.
Hope that gives you some ideas.
Thanks!
Ken
On Wed, Nov 30, 2016 at 3:08 AM, Andrea Gavana <andrea.gavana at gmail.com>
wrote:
> Hi Ken & All,
>
> On 29 November 2016 at 17:16, Ken Martin <ken.martin at kitware.com> wrote:
>
>> The ReportCapabilities() method on RenderWindow provides a lot of
>> information. You can do something like
>>
>> renWin->Render();
>> const char *info = renWin->ReportCapabilities();
>> cerr << info;
>>
>> or some sort of message box that displays info. That should tell you what
>> is being used for your rendering by VTK.
>>
>> If you are changing your data, then modified is fine, but then the first
>> render after you change data will be slow because it is re executing the
>> pipeline to account for the new data. So really the use case matters here.
>> If you have a GUI pulldown with a few different scalar fields then a 0.25
>> second delay on the first render is a non issue. All renders after that
>> first one (until you change the data again) will be super fast.
>>
>> If you are trying to make an animation loop where you change the data
>> every frame then you either have to cache the data or deal with the delay.
>> Simple caching of the data means creating a filter/mapper/actor for each
>> timestep/scalarfield and just turning the visibility on for the one you
>> currently want rendered, leaving the others off. After one time through the
>> loop it should be fast assuming it fits in memory.
>>
>
>
> That is exactly what I am trying to do, a timestepped animation of various
> properties over time. If I don't do the animation, the rendering is of
> course super-fast, but that was not my issue :-) . The issue was related to
> changing the scalars and re-display the grid.
>
> By the way, I have run your snippet of code using the ReportCapabilities()
> method on the render window... It's fairly long and a bit impenetrable to
> me, I'll put it at the end just in case anyone is interested in taking a
> look at it...
>
> I have also run the recommendation from David to check what backend was
> used for rendering with this code:
>
> rw = vtk.vtkRenderWindow()
> print rw.GetRenderingBackend()
>
> And it prints out "OpenGL2".
>
> I will try to think about your approach of caching and see if it can be
> integrated in my application without too much headache...
>
> Thank you again for all your support, it is much appreciated!
>
> Andrea.
>
>
>
> ********************************************************************
> Output of renWin.ReportCapabilities()
>
> OpenGL vendor string: NVIDIA Corporation
> OpenGL renderer string: Quadro 6000/PCIe/SSE2
> OpenGL version string: 4.5.0 NVIDIA 347.88
> OpenGL extensions:
> GL_AMD_multi_draw_indirect
> GL_ARB_arrays_of_arrays
> GL_ARB_base_instance
> GL_ARB_blend_func_extended
> GL_ARB_buffer_storage
> GL_ARB_clear_buffer_object
> GL_ARB_clear_texture
> GL_ARB_clip_control
> GL_ARB_color_buffer_float
> GL_ARB_compressed_texture_pixel_storage
> GL_ARB_conservative_depth
> GL_ARB_compute_shader
> GL_ARB_compute_variable_group_size
> GL_ARB_conditional_render_inverted
> GL_ARB_copy_buffer
> GL_ARB_copy_image
> GL_ARB_cull_distance
> GL_ARB_debug_output
> GL_ARB_depth_buffer_float
> GL_ARB_depth_clamp
> GL_ARB_depth_texture
> GL_ARB_derivative_control
> GL_ARB_direct_state_access
> GL_ARB_draw_buffers
> GL_ARB_draw_buffers_blend
> GL_ARB_draw_indirect
> GL_ARB_draw_elements_base_vertex
> GL_ARB_draw_instanced
> GL_ARB_enhanced_layouts
> GL_ARB_ES2_compatibility
> GL_ARB_ES3_compatibility
> GL_ARB_ES3_1_compatibility
> GL_ARB_explicit_attrib_location
> GL_ARB_explicit_uniform_location
> GL_ARB_fragment_coord_conventions
> GL_ARB_fragment_layer_viewport
> GL_ARB_fragment_program
> GL_ARB_fragment_program_shadow
> GL_ARB_fragment_shader
> GL_ARB_framebuffer_no_attachments
> GL_ARB_framebuffer_object
> GL_ARB_framebuffer_sRGB
> GL_ARB_geometry_shader4
> GL_ARB_get_program_binary
> GL_ARB_get_texture_sub_image
> GL_ARB_gpu_shader5
> GL_ARB_gpu_shader_fp64
> GL_ARB_half_float_pixel
> GL_ARB_half_float_vertex
> GL_ARB_imaging
> GL_ARB_indirect_parameters
> GL_ARB_instanced_arrays
> GL_ARB_internalformat_query
> GL_ARB_internalformat_query2
> GL_NV_internalformat_sample_query
> GL_ARB_invalidate_subdata
> GL_ARB_map_buffer_alignment
> GL_ARB_map_buffer_range
> GL_ARB_multi_bind
> GL_ARB_multi_draw_indirect
> GL_ARB_multisample
> GL_ARB_multitexture
> GL_ARB_occlusion_query
> GL_ARB_occlusion_query2
> GL_ARB_pipeline_statistics_query
> GL_ARB_pixel_buffer_object
> GL_ARB_point_parameters
> GL_ARB_point_sprite
> GL_ARB_program_interface_query
> GL_ARB_provoking_vertex
> GL_ARB_robust_buffer_access_behavior
> GL_ARB_robustness
> GL_ARB_sample_shading
> GL_ARB_sampler_objects
> GL_ARB_seamless_cube_map
> GL_ARB_separate_shader_objects
> GL_ARB_shader_atomic_counters
> GL_ARB_shader_bit_encoding
> GL_ARB_shader_draw_parameters
> GL_ARB_shader_group_vote
> GL_ARB_shader_image_load_store
> GL_ARB_shader_image_size
> GL_ARB_shader_objects
> GL_ARB_shader_precision
> GL_ARB_query_buffer_object
> GL_ARB_shader_storage_buffer_object
> GL_ARB_shader_subroutine
> GL_ARB_shader_texture_image_samples
> GL_ARB_shader_texture_lod
> GL_ARB_shading_language_100
> GL_ARB_shading_language_420pack
> GL_ARB_shading_language_include
> GL_ARB_shading_language_packing
> GL_ARB_shadow
> GL_ARB_sparse_buffer
> GL_ARB_sparse_texture
> GL_ARB_stencil_texturing
> GL_ARB_sync
> GL_ARB_tessellation_shader
> GL_ARB_texture_barrier
> GL_ARB_texture_border_clamp
> GL_ARB_texture_buffer_object
> GL_ARB_texture_buffer_object_rgb32
> GL_ARB_texture_buffer_range
> GL_ARB_texture_compression
> GL_ARB_texture_compression_bptc
> GL_ARB_texture_compression_rgtc
> GL_ARB_texture_cube_map
> GL_ARB_texture_cube_map_array
> GL_ARB_texture_env_add
> GL_ARB_texture_env_combine
> GL_ARB_texture_env_crossbar
> GL_ARB_texture_env_dot3
> GL_ARB_texture_float
> GL_ARB_texture_gather
> GL_ARB_texture_mirror_clamp_to_edge
> GL_ARB_texture_mirrored_repeat
> GL_ARB_texture_multisample
> GL_ARB_texture_non_power_of_two
> GL_ARB_texture_query_levels
> GL_ARB_texture_query_lod
> GL_ARB_texture_rectangle
> GL_ARB_texture_rg
> GL_ARB_texture_rgb10_a2ui
> GL_ARB_texture_stencil8
> GL_ARB_texture_storage
> GL_ARB_texture_storage_multisample
> GL_ARB_texture_swizzle
> GL_ARB_texture_view
> GL_ARB_timer_query
> GL_ARB_transform_feedback2
> GL_ARB_transform_feedback3
> GL_ARB_transform_feedback_instanced
> GL_ARB_transform_feedback_overflow_query
> GL_ARB_transpose_matrix
> GL_ARB_uniform_buffer_object
> GL_ARB_vertex_array_bgra
> GL_ARB_vertex_array_object
> GL_ARB_vertex_attrib_64bit
> GL_ARB_vertex_attrib_binding
> GL_ARB_vertex_buffer_object
> GL_ARB_vertex_program
> GL_ARB_vertex_shader
> GL_ARB_vertex_type_10f_11f_11f_rev
> GL_ARB_vertex_type_2_10_10_10_rev
> GL_ARB_viewport_array
> GL_ARB_window_pos
> GL_ATI_draw_buffers
> GL_ATI_texture_float
> GL_ATI_texture_mirror_once
> GL_S3_s3tc
> GL_EXT_texture_env_add
> GL_EXT_abgr
> GL_EXT_bgra
> GL_EXT_bindable_uniform
> GL_EXT_blend_color
> GL_EXT_blend_equation_separate
> GL_EXT_blend_func_separate
> GL_EXT_blend_minmax
> GL_EXT_blend_subtract
> GL_EXT_compiled_vertex_array
> GL_EXT_Cg_shader
> GL_EXT_depth_bounds_test
> GL_EXT_direct_state_access
> GL_EXT_draw_buffers2
> GL_EXT_draw_instanced
> GL_EXT_draw_range_elements
> GL_EXT_fog_coord
> GL_EXT_framebuffer_blit
> GL_EXT_framebuffer_multisample
> GL_EXTX_framebuffer_mixed_formats
> GL_EXT_framebuffer_multisample_blit_scaled
> GL_EXT_framebuffer_object
> GL_EXT_framebuffer_sRGB
> GL_EXT_geometry_shader4
> GL_EXT_gpu_program_parameters
> GL_EXT_gpu_shader4
> GL_EXT_multi_draw_arrays
> GL_EXT_packed_depth_stencil
> GL_EXT_packed_float
> GL_EXT_packed_pixels
> GL_EXT_pixel_buffer_object
> GL_EXT_point_parameters
> GL_EXT_polygon_offset_clamp
> GL_EXT_provoking_vertex
> GL_EXT_rescale_normal
> GL_EXT_secondary_color
> GL_EXT_separate_shader_objects
> GL_EXT_separate_specular_color
> GL_EXT_shader_image_load_store
> GL_EXT_shader_integer_mix
> GL_EXT_shadow_funcs
> GL_EXT_stencil_two_side
> GL_EXT_stencil_wrap
> GL_EXT_texture3D
> GL_EXT_texture_array
> GL_EXT_texture_buffer_object
> GL_EXT_texture_compression_dxt1
> GL_EXT_texture_compression_latc
> GL_EXT_texture_compression_rgtc
> GL_EXT_texture_compression_s3tc
> GL_EXT_texture_cube_map
> GL_EXT_texture_edge_clamp
> GL_EXT_texture_env_combine
> GL_EXT_texture_env_dot3
> GL_EXT_texture_filter_anisotropic
> GL_EXT_texture_integer
> GL_EXT_texture_lod
> GL_EXT_texture_lod_bias
> GL_EXT_texture_mirror_clamp
> GL_EXT_texture_object
> GL_EXT_texture_shared_exponent
> GL_EXT_texture_sRGB
> GL_EXT_texture_sRGB_decode
> GL_EXT_texture_storage
> GL_EXT_texture_swizzle
> GL_EXT_timer_query
> GL_EXT_transform_feedback2
> GL_EXT_vertex_array
> GL_EXT_vertex_array_bgra
> GL_EXT_vertex_attrib_64bit
> GL_EXT_import_sync_object
> GL_NVX_shared_sync_object
> GL_IBM_rasterpos_clip
> GL_IBM_texture_mirrored_repeat
> GL_KHR_context_flush_control
> GL_KHR_debug
> GL_KHR_robust_buffer_access_behavior
> GL_KHR_robustness
> GL_KTX_buffer_region
> GL_NV_bindless_multi_draw_indirect
> GL_NV_bindless_multi_draw_indirect_count
> GL_NV_blend_equation_advanced
> GL_NV_blend_square
> GL_NV_command_list
> GL_NV_compute_program5
> GL_NV_conditional_render
> GL_NV_copy_depth_to_color
> GL_NV_copy_image
> GL_NV_depth_buffer_float
> GL_NV_depth_clamp
> GL_NV_draw_texture
> GL_NV_ES1_1_compatibility
> GL_NV_ES3_1_compatibility
> GL_NV_explicit_multisample
> GL_NV_fence
> GL_NV_float_buffer
> GL_NV_fog_distance
> GL_NV_fragment_program
> GL_NV_fragment_program_option
> GL_NV_fragment_program2
> GL_NV_framebuffer_multisample_coverage
> GL_NV_geometry_shader4
> GL_NV_gpu_program4
> GL_NV_gpu_program4_1
> GL_NV_gpu_program5
> GL_NV_gpu_program5_mem_extended
> GL_NV_gpu_program_fp64
> GL_NV_gpu_shader5
> GL_NV_half_float
> GL_NV_light_max_exponent
> GL_NV_multisample_coverage
> GL_NV_multisample_filter_hint
> GL_NV_occlusion_query
> GL_NV_packed_depth_stencil
> GL_NV_parameter_buffer_object
> GL_NV_parameter_buffer_object2
> GL_NV_path_rendering
> GL_NV_pixel_data_range
> GL_NV_point_sprite
> GL_NV_primitive_restart
> GL_NV_register_combiners
> GL_NV_register_combiners2
> GL_NV_shader_atomic_counters
> GL_NV_shader_atomic_float
> GL_NV_shader_buffer_load
> GL_NV_shader_storage_buffer_object
> GL_NV_texgen_reflection
> GL_NV_texture_barrier
> GL_NV_texture_compression_vtc
> GL_NV_texture_env_combine4
> GL_NV_texture_multisample
> GL_NV_texture_rectangle
> GL_NV_texture_shader
> GL_NV_texture_shader2
> GL_NV_texture_shader3
> GL_NV_transform_feedback
> GL_NV_transform_feedback2
> GL_NV_uniform_buffer_unified_memory
> GL_NV_vertex_array_range
> GL_NV_vertex_array_range2
> GL_NV_vertex_attrib_integer_64bit
> GL_NV_vertex_buffer_unified_memory
> GL_NV_vertex_program
> GL_NV_vertex_program1_1
> GL_NV_vertex_program2
> GL_NV_vertex_program2_option
> GL_NV_vertex_program3
> GL_NV_video_capture
> GL_NVX_sysmem_buffer
> GL_NVX_conditional_render
> GL_NVX_gpu_memory_info
> GL_NV_shader_thread_group
> GL_KHR_blend_equation_advanced
> GL_SGIS_generate_mipmap
> GL_SGIS_texture_lod
> GL_SGIX_depth_texture
> GL_SGIX_shadow
> GL_SUN_slice_accum
> GL_WIN_swap_hint
> WGL_EXT_swap_control
> PixelFormat Descriptor:
> depth: 24
> class: TrueColor
> buffer size: 32
> level: 0
> renderType: rgba
> double buffer: True
> stereo: False
> hardware acceleration: True
> rgba: redSize=8 greenSize=8blueSize=8alphaSize=8
> aux buffers: 4
> depth size: 24
> stencil size: 0
> accum: redSize=16 greenSize=16blueSize=16alphaSize=16
>
> ********************************************************************
>
>
>
>
>
>
>
>
>
>>
>> Hope that helps!
>> Ken
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 29, 2016 at 11:01 AM, Andrea Gavana <andrea.gavana at gmail.com>
>> wrote:
>>
>>> Hi Ken,
>>>
>>> Thank you for your answer. So it seems to me that I should not call
>>> grid.Modified() if I only change the scalars? In my script there is almost
>>> no pipeline, I.e. I have:
>>>
>>> Grid --> Mapper --> Actor
>>>
>>> No filters, no updating, no nothing.
>>>
>>> I will try your loop example tomorrow from my work computer. Also, how
>>> can I know if the rendering engine is using the GPU? I have a fairly
>>> powerful machine at work, able to run commercial 3D visualization software
>>> (on a geological scale) with multi-million cells with no problem...
>>>
>>> Thank you again!
>>>
>>> Andrea.
>>>
>>> On Tue, 29 Nov 2016 at 16:37, Ken Martin <ken.martin at kitware.com> wrote:
>>>
>>>>
>>>> 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.:
>>>>
>>>>
>>>> VTK with OpenGL2 can render 500 million cells/second on a laptop GPU.
>>>> If you are seeing performance significantly off from that and think you are
>>>> using a GPU then something is wrong. To do timings do not rely on
>>>> GetLastRenderTimeInSeconds but rather time a render loop like ala
>>>>
>>>> startTimer
>>>> for (i = 0; i < 500; i++)
>>>> {
>>>> renWin->Render();
>>>> }
>>>> endTimer
>>>> print elapsedTime/500;
>>>>
>>>>
>>>>
>>>> grid.GetCellData().SetScalars(data)
>>>> grid.Modified()
>>>> renwin.Render()
>>>>
>>>>
>>>> The render above is a first render, in that it is the first render
>>>> after you modified your data. The entire
>>>> pipeline has to be run then. You are probably timing how has the
>>>> pipeline can be modified and recalaculated when you change your data.
>>>>
>>>>
>>>>
>>>> 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-paravie
>>>> w\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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>
>>
>> --
>> 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.
>>
>
>
--
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/20161130/c35d2ed8/attachment.html>
More information about the vtkusers
mailing list