[vtkusers] VTK pipeline & rendering strategies

Andrea Gavana andrea.gavana at gmail.com
Wed Nov 30 03:08:17 EST 2016


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-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.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/73703fbe/attachment-0001.html>


More information about the vtkusers mailing list