[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