From dave.demarle at kitware.com Tue Feb 2 16:09:02 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 2 Feb 2016 16:09:02 -0500 Subject: [vtk-developers] VTK 7.0.0 Message-ID: Howdy, VTK 7.0.0 is released! For details see: https://blog.kitware.com/vtk-7-0-0/ A big round of applause to everyone who helped make it happen. enjoy! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Tue Feb 2 16:42:13 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 2 Feb 2016 16:42:13 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Geoff- I pushed an in progress version of VoxelGrid. As well as a hierarchical points binner. This is a work in progress so be forewarned. In particular, VoxelGrid does not yet interpolate its attributes yet. This is because I've got another branch in VTK for point interpolation, including interpolation kernels, that must ripen and placed in master first. Then the interpolation will be easy to add. W On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder wrote: > Okay I have a quick and dirty design for "file" format and algorithmic > approach that I'll start implementing shortly. We'll clean it up with time. > Any feedback is welcome. > > The data file format has three basic logical parts, which could be written > into separate files or one file, whatever. 1) metadata, 2) offsets, and 3) > sorted points. > > The key idea is that the points are in sorted order, beginning with level > 0 root node, followed by level 1 bins (8 bins) and their points, and level > 2 bins (64 bins) and their points, and so on. The points are just a > contiguous array of x-y-z, x-y-z, of type float or double (user specified), > etc. Data attributes could be stored in similar fashion (all easily > changeable depending on what you prefer). Since the number of points in > each bin is variable and may even be zero, this is where the offsets come > into play. (Note that points are not repeated, and statistically sampled as > you suggest ~1/(total number of bins)*NumberOfPoints points in each bin.) > > The offsets are integral values that simply refer to a position in the > sorted points array corresponding to the beginning of each bin. So (level > 0, bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), > (1,7), (2,0), (2,1), ... you get the idea. For your example of a 3-level > octree, there would be 73 offset values (or T=73 total bins). Note that if > offset_i == offset_(i+1) then there are zero points in the bin referred to > by offset_i. We can also represent the offsets with different integral > types depending on the number of points (to save memory). > > The metadata contains something like (assuming multiple separate files, > which of course can be memory mapped, etc): > NumberOfPoints #npts > NumberOfLevels #numLevels > Divisions 2 2 2 > Bounds (xmin,xmax,ymin,ymax,zmin,zmax) > Points type "points.file" > Offsets type "offsets.file" > Array type numComp "scalars.file" > Array type numComp "vectors.file" > > Note that the Divisions are variable, the structure does not have to be an > octree. This is useful to produce bins that are closer to uniform shape, or > even create a 2.5D, sorta flat binning tree (e.g. z-divisions always == 1). > > Algorithmic approach: (this can easily be threaded): > For every point p_i in the input point cloud, generate a random number r > (0<=r<1). Assume that there are T total bins. > The probability (assuming an octree) that p_i is in level 0: is 1/T; in > level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into > proportional subranges that r maps into. Thus r will randomly select which > level of the tree a point belongs in. > > Once p_i is assigned a level, compute a hash index h_i which consists of > the (i,j,k) bin index added to T_l, there T_l is the total number of bins > at the beginning of level l. This hash index is the key to get the sort in > the right order; using the level information is a way to segment the bins > from different levels into contiguous runs. > > Now sort the points based on this hash index. The sort is where most of > the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted > points list. Next create the offsets array by running through the sorted > hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's > easy to do, and can even be done in parallel.) > > From the mapper point of view: knowing the bounds, divisions, current > level, and (i,j,k) bin index it is possible to construct a local bounding > box for each bin. Then there is direct access to the list of points in each > bin (through the offsets). And of course since this is a hierarchy of > uniform bins, you can easily perform view culling etc. and choose the > appropriate level for LODs. > > That's it in a nutshell. Unfortunately I've got lots of pointy-haired boss > stuff to do so this might take a bit to complete, but I'd really like to > get a prototype class written this week > (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) > Initially I'll have this class build the data structures, with a special > back-door method to write the data out. Later on we'll decide if we need to > separate this backdoor IO into a separate class, etc. > > Best, > W > > > On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin > wrote: > >> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a >> simple ascii X Y Z R G B type format that I usually immediately convert to >> VTK XML format as that is far faster and more compact. So unfortunately PTS >> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some >> bounding box metadata. >> >> Ken >> >> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Ken- >>> >>> I am totally with you. I am writing some simple stuff at the moment like >>> VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to >>> get my head around the challenges and serve as a stop gap until our better >>> stuff comes along. I really like your idea and I do plan to implement this; >>> it's really not too hard to do from what I understand and given the pieces >>> available in VTK. >>> >>> So I'll wrap up this simple VoxelGrid and then take a crack at the beast >>> you've envisioned. The two major pieces seems to be 1) create a class that >>> builds the hierarchical structure, and 2) write a reader/writer pair that >>> can perform associated IO. In an earlier email you mentioned a PTS reader >>> that you made improvement to; is this a good exemplar data format or do you >>> have a better starting point? >>> >>> It seems I have a homework assignment for the weekend :-) >>> >>> Best, >>> W >>> >>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >>> wrote: >>> >>>> Nice, can I make a specific request Will? :-) Part of what I want to do >>>> for large point clouds is something like the following: >>>> >>>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>>> pieces (but not the data) >>>> >>>> 2) Read in the first piece and use it for rendering >>>> >>>> 3) In the background read in more pieces, as they are loaded make them >>>> available to the mapper >>>> >>>> 4) The mapper based on the current camera parameters and bounding boxes >>>> of the pieces intelligently selects what pieces to render. This provides a >>>> happy fast interactive experience leading to world peace. >>>> >>>> For this to work well my thought was to have the pieces be broken up in >>>> a special way sort of like an octree but a spatial hash etc would be just >>>> as good as long as it is hierarchical and structured. Think of breaking up >>>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the >>>> data covering the entire bounding box. The next eight pieces also each >>>> contain about 1/73 of the data each constrained by their octant of the >>>> bounding box. Same idea for the next 64 boxes, they are just one level >>>> further down. This would work really well for a smart mapper providing >>>> fast first render plus fast LOD/subsequent renders. I can implement 1-4 >>>> pretty quickly. >>>> >>>> But .... for it to work I need someone to create the 73 piece file the >>>> right way. (it does not have to be 73, and clearly some of those 73 will be >>>> empty, it just needs to be hierarchical and structured so that a group of >>>> pieces can be represented at a lower level of detail by some other piece) >>>> My gut feeling was to have the LOD pieces use actual points of the dataset >>>> (not centroids or similar) that way as more pieces are loaded we are just >>>> providing more detail, not replacing fake data (centroids) with real data. >>>> But really either approach is pretty easy to implement in the mapper. The >>>> latter approach just means the entire dataset footprint is larger because >>>> some of the points are not part of the full res dataset because you >>>> generated them. >>>> >>>> I could be totally off base but that was my gut feeling on rendering > >>>> 2GB point clouds in a nice zippy manner. >>>> >>>> TLDR: I want someone to write a filter/writer subclass to create a >>>> special 73 piece vtk file :-) >>>> >>>> Ken >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> Geoff- >>>>> >>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>>> threaded and seems to be fast. >>>>> >>>>> Question for you before I push the work to the repository: averaging >>>>> points in each bin provides a nice subsampled point position. But what do >>>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>>> could be averaged too. There are however other options like finding the >>>>> closest point to the subsampled point and using those attribute values, or >>>>> if you want to get really fancy, using an interpolation kernel to >>>>> interpolate to the subsampled point. >>>>> >>>>> Thoughts? >>>>> W >>>>> >>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> Thanks for the feedback. I have some downsampling filters in the >>>>>> works now, I'll let you know when I have something ready. >>>>>> >>>>>> BTW we are on a similar path. PCL is awesome, but we have some common >>>>>> workflows that would be better served with more compact software >>>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>>> knock of a small kernel of capability to achieve this. >>>>>> >>>>>> Best, >>>>>> W >>>>>> >>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>>> wrote: >>>>>> >>>>>>> Hi Will, >>>>>>> >>>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>>> from some point cloud data. I have some initial pre processing steps that >>>>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>>>> eliminate the PCL dependency and use exclusively vtk. My point >>>>>>> cloud data grows very large over time with a lot of redundant points so its >>>>>>> very important to downsample them onto uniform spacing ( >>>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>>>> before processing them in vtk. Would it make sense to add something like >>>>>>> this to your library? >>>>>>> >>>>>>> Geoff >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>>>> will.schroeder at kitware.com> wrote: >>>>>>> >>>>>>>> FYI- I have committed an initial set of filters for performing >>>>>>>> point cloud processing. Any feedback or suggestions are welcome as this is >>>>>>>> an initial prototype. The work is currently available as a remote module to >>>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>>> >>>>>>>> A couple of notes: >>>>>>>> + Right now I am using vtkPolyData to represent the point cloud via >>>>>>>> a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created >>>>>>>> to save on memory. >>>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>>> + There is a general framework for filtering point clouds via the >>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>>> filters also have an optional, second output which contains any points >>>>>>>> removed from the input. >>>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>>> implicit function). Some of these names are inspired by PCL >>>>>>>> names. >>>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>>> although I have not done much testing. >>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>>> wrote that is very fast. >>>>>>>> >>>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>>>> try to educate myself, so be forewarned. >>>>>>>> >>>>>>>> Best, >>>>>>>> W >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Search the list archives at: >>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> William J. Schroeder, PhD >>>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>>> 28 Corporate Drive >>>>>> Clifton Park, NY 12065 >>>>>> will.schroeder at kitware.com >>>>>> http://www.kitware.com >>>>>> (518) 881-4902 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> William J. Schroeder, PhD >>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>> 28 Corporate Drive >>>>> Clifton Park, NY 12065 >>>>> will.schroeder at kitware.com >>>>> http://www.kitware.com >>>>> (518) 881-4902 >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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. >>>> >>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. - Building the World's Technical Computing Software >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >>> >> >> >> >> -- >> 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. >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpwright at gmail.com Wed Feb 3 08:24:44 2016 From: gpwright at gmail.com (Geoff Wright) Date: Wed, 03 Feb 2016 13:24:44 +0000 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Hi Will, Looks good! I like the use of SMP. I'll definitely try it out once the interpolation is in place, it will be great to eliminate PCL as a dependency. Regards, Geoff On Tue, Feb 2, 2016 at 4:42 PM Will Schroeder wrote: > Geoff- > > I pushed an in progress version of VoxelGrid. As well as a hierarchical > points binner. This is a work in progress so be forewarned. In particular, > VoxelGrid does not yet interpolate its attributes yet. This is because I've > got another branch in VTK for point interpolation, including interpolation > kernels, that must ripen and placed in master first. Then the interpolation > will be easy to add. > > W > > On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Okay I have a quick and dirty design for "file" format and algorithmic >> approach that I'll start implementing shortly. We'll clean it up with time. >> Any feedback is welcome. >> >> The data file format has three basic logical parts, which could be >> written into separate files or one file, whatever. 1) metadata, 2) offsets, >> and 3) sorted points. >> >> The key idea is that the points are in sorted order, beginning with level >> 0 root node, followed by level 1 bins (8 bins) and their points, and level >> 2 bins (64 bins) and their points, and so on. The points are just a >> contiguous array of x-y-z, x-y-z, of type float or double (user specified), >> etc. Data attributes could be stored in similar fashion (all easily >> changeable depending on what you prefer). Since the number of points in >> each bin is variable and may even be zero, this is where the offsets come >> into play. (Note that points are not repeated, and statistically sampled as >> you suggest ~1/(total number of bins)*NumberOfPoints points in each bin.) >> >> The offsets are integral values that simply refer to a position in the >> sorted points array corresponding to the beginning of each bin. So (level >> 0, bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), >> (1,7), (2,0), (2,1), ... you get the idea. For your example of a 3-level >> octree, there would be 73 offset values (or T=73 total bins). Note that if >> offset_i == offset_(i+1) then there are zero points in the bin referred to >> by offset_i. We can also represent the offsets with different integral >> types depending on the number of points (to save memory). >> >> The metadata contains something like (assuming multiple separate files, >> which of course can be memory mapped, etc): >> NumberOfPoints #npts >> NumberOfLevels #numLevels >> Divisions 2 2 2 >> Bounds (xmin,xmax,ymin,ymax,zmin,zmax) >> Points type "points.file" >> Offsets type "offsets.file" >> Array type numComp "scalars.file" >> Array type numComp "vectors.file" >> >> Note that the Divisions are variable, the structure does not have to be >> an octree. This is useful to produce bins that are closer to uniform shape, >> or even create a 2.5D, sorta flat binning tree (e.g. z-divisions always == >> 1). >> >> Algorithmic approach: (this can easily be threaded): >> For every point p_i in the input point cloud, generate a random number r >> (0<=r<1). Assume that there are T total bins. >> The probability (assuming an octree) that p_i is in level 0: is 1/T; in >> level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into >> proportional subranges that r maps into. Thus r will randomly select which >> level of the tree a point belongs in. >> >> Once p_i is assigned a level, compute a hash index h_i which consists of >> the (i,j,k) bin index added to T_l, there T_l is the total number of bins >> at the beginning of level l. This hash index is the key to get the sort in >> the right order; using the level information is a way to segment the bins >> from different levels into contiguous runs. >> >> Now sort the points based on this hash index. The sort is where most of >> the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted >> points list. Next create the offsets array by running through the sorted >> hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's >> easy to do, and can even be done in parallel.) >> >> From the mapper point of view: knowing the bounds, divisions, current >> level, and (i,j,k) bin index it is possible to construct a local bounding >> box for each bin. Then there is direct access to the list of points in each >> bin (through the offsets). And of course since this is a hierarchy of >> uniform bins, you can easily perform view culling etc. and choose the >> appropriate level for LODs. >> >> That's it in a nutshell. Unfortunately I've got lots of pointy-haired >> boss stuff to do so this might take a bit to complete, but I'd really like >> to get a prototype class written this week >> (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) >> Initially I'll have this class build the data structures, with a special >> back-door method to write the data out. Later on we'll decide if we need to >> separate this backdoor IO into a separate class, etc. >> >> Best, >> W >> >> >> On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin >> wrote: >> >>> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a >>> simple ascii X Y Z R G B type format that I usually immediately convert to >>> VTK XML format as that is far faster and more compact. So unfortunately PTS >>> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some >>> bounding box metadata. >>> >>> Ken >>> >>> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> Ken- >>>> >>>> I am totally with you. I am writing some simple stuff at the moment >>>> like VoxelGrid as sort of a "drop-in" replacements for PCL workflows; >>>> mostly to get my head around the challenges and serve as a stop gap until >>>> our better stuff comes along. I really like your idea and I do plan to >>>> implement this; it's really not too hard to do from what I understand and >>>> given the pieces available in VTK. >>>> >>>> So I'll wrap up this simple VoxelGrid and then take a crack at the >>>> beast you've envisioned. The two major pieces seems to be 1) create a class >>>> that builds the hierarchical structure, and 2) write a reader/writer pair >>>> that can perform associated IO. In an earlier email you mentioned a PTS >>>> reader that you made improvement to; is this a good exemplar data format or >>>> do you have a better starting point? >>>> >>>> It seems I have a homework assignment for the weekend :-) >>>> >>>> Best, >>>> W >>>> >>>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >>>> wrote: >>>> >>>>> Nice, can I make a specific request Will? :-) Part of what I want to >>>>> do for large point clouds is something like the following: >>>>> >>>>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>>>> pieces (but not the data) >>>>> >>>>> 2) Read in the first piece and use it for rendering >>>>> >>>>> 3) In the background read in more pieces, as they are loaded make them >>>>> available to the mapper >>>>> >>>>> 4) The mapper based on the current camera parameters and bounding >>>>> boxes of the pieces intelligently selects what pieces to render. This >>>>> provides a happy fast interactive experience leading to world peace. >>>>> >>>>> For this to work well my thought was to have the pieces be broken up >>>>> in a special way sort of like an octree but a spatial hash etc would be >>>>> just as good as long as it is hierarchical and structured. Think of >>>>> breaking up the volume into 1 + 8 + 64 pieces. The first piece contains >>>>> ~1/73 of the data covering the entire bounding box. The next eight pieces >>>>> also each contain about 1/73 of the data each constrained by their octant >>>>> of the bounding box. Same idea for the next 64 boxes, they are just one >>>>> level further down. This would work really well for a smart mapper >>>>> providing fast first render plus fast LOD/subsequent renders. I can >>>>> implement 1-4 pretty quickly. >>>>> >>>>> But .... for it to work I need someone to create the 73 piece file the >>>>> right way. (it does not have to be 73, and clearly some of those 73 will be >>>>> empty, it just needs to be hierarchical and structured so that a group of >>>>> pieces can be represented at a lower level of detail by some other piece) >>>>> My gut feeling was to have the LOD pieces use actual points of the dataset >>>>> (not centroids or similar) that way as more pieces are loaded we are just >>>>> providing more detail, not replacing fake data (centroids) with real data. >>>>> But really either approach is pretty easy to implement in the mapper. The >>>>> latter approach just means the entire dataset footprint is larger because >>>>> some of the points are not part of the full res dataset because you >>>>> generated them. >>>>> >>>>> I could be totally off base but that was my gut feeling on rendering > >>>>> 2GB point clouds in a nice zippy manner. >>>>> >>>>> TLDR: I want someone to write a filter/writer subclass to create a >>>>> special 73 piece vtk file :-) >>>>> >>>>> Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> Geoff- >>>>>> >>>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>>>> threaded and seems to be fast. >>>>>> >>>>>> Question for you before I push the work to the repository: averaging >>>>>> points in each bin provides a nice subsampled point position. But what do >>>>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>>>> could be averaged too. There are however other options like finding the >>>>>> closest point to the subsampled point and using those attribute values, or >>>>>> if you want to get really fancy, using an interpolation kernel to >>>>>> interpolate to the subsampled point. >>>>>> >>>>>> Thoughts? >>>>>> W >>>>>> >>>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>>>>> will.schroeder at kitware.com> wrote: >>>>>> >>>>>>> Thanks for the feedback. I have some downsampling filters in the >>>>>>> works now, I'll let you know when I have something ready. >>>>>>> >>>>>>> BTW we are on a similar path. PCL is awesome, but we have some >>>>>>> common workflows that would be better served with more compact software >>>>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>>>> knock of a small kernel of capability to achieve this. >>>>>>> >>>>>>> Best, >>>>>>> W >>>>>>> >>>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Will, >>>>>>>> >>>>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>>>> from some point cloud data. I have some initial pre processing steps that >>>>>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>>>>> eliminate the PCL dependency and use exclusively vtk. My point >>>>>>>> cloud data grows very large over time with a lot of redundant points so its >>>>>>>> very important to downsample them onto uniform spacing ( >>>>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>>>>> before processing them in vtk. Would it make sense to add something like >>>>>>>> this to your library? >>>>>>>> >>>>>>>> Geoff >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>>>>> will.schroeder at kitware.com> wrote: >>>>>>>> >>>>>>>>> FYI- I have committed an initial set of filters for performing >>>>>>>>> point cloud processing. Any feedback or suggestions are welcome as this is >>>>>>>>> an initial prototype. The work is currently available as a remote module to >>>>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>>>> >>>>>>>>> A couple of notes: >>>>>>>>> + Right now I am using vtkPolyData to represent the point cloud >>>>>>>>> via a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells >>>>>>>>> created to save on memory. >>>>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>>>> + There is a general framework for filtering point clouds via the >>>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>>>> filters also have an optional, second output which contains any points >>>>>>>>> removed from the input. >>>>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>>>> implicit function). Some of these names are inspired by PCL >>>>>>>>> names. >>>>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>>>> although I have not done much testing. >>>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>>>> wrote that is very fast. >>>>>>>>> >>>>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>>>>> try to educate myself, so be forewarned. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> W >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Search the list archives at: >>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> William J. Schroeder, PhD >>>>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>>>> 28 Corporate Drive >>>>>>> Clifton Park, NY 12065 >>>>>>> will.schroeder at kitware.com >>>>>>> http://www.kitware.com >>>>>>> (518) 881-4902 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> William J. Schroeder, PhD >>>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>>> 28 Corporate Drive >>>>>> Clifton Park, NY 12065 >>>>>> will.schroeder at kitware.com >>>>>> http://www.kitware.com >>>>>> (518) 881-4902 >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> William J. Schroeder, PhD >>>> Kitware, Inc. - Building the World's Technical Computing Software >>>> 28 Corporate Drive >>>> Clifton Park, NY 12065 >>>> will.schroeder at kitware.com >>>> http://www.kitware.com >>>> (518) 881-4902 >>>> >>> >>> >>> >>> -- >>> 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. >>> >> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Wed Feb 3 09:43:56 2016 From: xabivtk at gmail.com (Xabi Riobe) Date: Wed, 3 Feb 2016 15:43:56 +0100 Subject: [vtk-developers] Master vs Release v6 maintenance In-Reply-To: <20151030185646.GB8203@megas.khq.kitware.com> References: <20151019150730.GA30474@megas.khq.kitware.com> <20151030185646.GB8203@megas.khq.kitware.com> Message-ID: Hi Ben, I'm wondering what is the plan for 6.3.x branch, if there will be some tag for a release with mailing list anouncement in parallel of "main" vtk releases, or if the release-6.3 branch will be updated when fixes are required and it's up to users to check it? Regards, Xabi 2015-10-30 19:56 GMT+01:00 Ben Boeckel : > On Fri, Oct 30, 2015 at 14:35:05 -0400, Shawn Waldon wrote: > > Yes, it is on the gitlab side. Target and merge against master means > that > > you should create a merge request to merge into master rather than a > merge > > request that asks to merge into the 6.3 release branch. Merging into > > master is the default, so just don't change your merge request to point > at > > 6.3 and it is fine. > > Note that when VTK7 is branched, 6.3 (well, 6.x is probably a better > name for it) will likely be cut off and be its own target. I'll need to > verify the kwrobot can still handle such merge requests. For now though, > getting things into master is still possible and should be done. > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Wed Feb 3 10:26:24 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 3 Feb 2016 10:26:24 -0500 Subject: [vtk-developers] VTK 7.0.0 In-Reply-To: References: Message-ID: Congratulations on the release! The Python 3 support is particularly exciting. ITK 4.9.0 was also released today, and it is worth noting that the ITKVtkGlue modules that bridges ITK-VTK pipelines now also supports Python 3 wrapping! On Tue, Feb 2, 2016 at 4:09 PM, David E DeMarle wrote: > Howdy, > > VTK 7.0.0 is released! For details see: > > https://blog.kitware.com/vtk-7-0-0/ > > A big round of applause to everyone who helped make it happen. > > enjoy! > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From andy.bauer at kitware.com Wed Feb 3 11:09:30 2016 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 3 Feb 2016 11:09:30 -0500 Subject: [vtk-developers] Tuple ordering of 2nd order tensors and changes to vtkCellDerivatives Message-ID: Hi, I wanted to inform everyone that there is some inconsistencies in the way 2nd order tensors are represented in VTK data arrays. The vtkGradientFilter outputs in C/row-major ordering while the vtkCellDerivatives filter outputs in Fortran/column-major ordering. There are other inconsistencies to this as well. Officially, VTK uses C/row-major ordering for tuples. An example of this is the vtkCell::Derivatives() method ( http://www.vtk.org/doc/nightly/html/classvtkCell.html#aff3d8332e9d7d556a9d2e9f91173d068). Martin Genet has brought this inconsistency to light with his work on vtkCellDerivatives in changing this to row-major ordering output. 40e05b6a is his commit that fixed this issue for the filter, its documentation and how vector_gradient and strain are computed in the VTK numpy interface. He additionally removed the vtkTensor which was only used by vtkCellDerivatives to transpose the 2nd order tensor's output. There may be other 2nd order tensor ordering inconsistencies in VTK that should be cleaned up as well and we hope to address those ASAP. The most difficult of these will likely be in the readers that bring in 2nd order tensors. I would encourage those that are familiar with specific readers to spend a couple of minutes verifying the correct ordering from them. I'll be adding in notes about this fix to Documentation/Doxygen/ChangesVTK-7-1.md shortly. Best regards, Andy ps. A big thanks to Martin for his fixes and his patience on getting this through! This is his second and third commit to VTK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Feb 3 11:17:02 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 3 Feb 2016 11:17:02 -0500 Subject: [vtk-developers] Master vs Release v6 maintenance In-Reply-To: References: <20151019150730.GA30474@megas.khq.kitware.com> <20151030185646.GB8203@megas.khq.kitware.com> Message-ID: <20160203161702.GB1800@megas.kitware.com> On Wed, Feb 03, 2016 at 15:43:56 +0100, Xabi Riobe wrote: > I'm wondering what is the plan for 6.3.x branch, if there will be some tag > for a release with mailing list anouncement in parallel of "main" vtk > releases, or if the release-6.3 branch will be updated when fixes are > required and it's up to users to check it? There will probably be a 6.4 at some point. I don't know of an exact timeline right now. --Ben From bill.lorensen at gmail.com Wed Feb 3 11:22:59 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 3 Feb 2016 11:22:59 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Will, When I try to build the latest I get: /Users/lorensen/ProjectsGIT/VTK/Remote/vtkPointCloud/vtkVoxelGrid.cxx:76: error: ?class vtkStaticPointLocator? has no member named ?GetBucketIds? On Wed, Feb 3, 2016 at 8:24 AM, Geoff Wright wrote: > Hi Will, > > Looks good! I like the use of SMP. I'll definitely try it out once the > interpolation is in place, it will be great to eliminate PCL as a > dependency. > > Regards, > Geoff > > > On Tue, Feb 2, 2016 at 4:42 PM Will Schroeder > wrote: >> >> Geoff- >> >> I pushed an in progress version of VoxelGrid. As well as a hierarchical >> points binner. This is a work in progress so be forewarned. In particular, >> VoxelGrid does not yet interpolate its attributes yet. This is because I've >> got another branch in VTK for point interpolation, including interpolation >> kernels, that must ripen and placed in master first. Then the interpolation >> will be easy to add. >> >> W >> >> On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder >> wrote: >>> >>> Okay I have a quick and dirty design for "file" format and algorithmic >>> approach that I'll start implementing shortly. We'll clean it up with time. >>> Any feedback is welcome. >>> >>> The data file format has three basic logical parts, which could be >>> written into separate files or one file, whatever. 1) metadata, 2) offsets, >>> and 3) sorted points. >>> >>> The key idea is that the points are in sorted order, beginning with level >>> 0 root node, followed by level 1 bins (8 bins) and their points, and level 2 >>> bins (64 bins) and their points, and so on. The points are just a contiguous >>> array of x-y-z, x-y-z, of type float or double (user specified), etc. Data >>> attributes could be stored in similar fashion (all easily changeable >>> depending on what you prefer). Since the number of points in each bin is >>> variable and may even be zero, this is where the offsets come into play. >>> (Note that points are not repeated, and statistically sampled as you suggest >>> ~1/(total number of bins)*NumberOfPoints points in each bin.) >>> >>> The offsets are integral values that simply refer to a position in the >>> sorted points array corresponding to the beginning of each bin. So (level 0, >>> bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), (1,7), >>> (2,0), (2,1), ... you get the idea. For your example of a 3-level octree, >>> there would be 73 offset values (or T=73 total bins). Note that if offset_i >>> == offset_(i+1) then there are zero points in the bin referred to by >>> offset_i. We can also represent the offsets with different integral types >>> depending on the number of points (to save memory). >>> >>> The metadata contains something like (assuming multiple separate files, >>> which of course can be memory mapped, etc): >>> NumberOfPoints #npts >>> NumberOfLevels #numLevels >>> Divisions 2 2 2 >>> Bounds (xmin,xmax,ymin,ymax,zmin,zmax) >>> Points type "points.file" >>> Offsets type "offsets.file" >>> Array type numComp "scalars.file" >>> Array type numComp "vectors.file" >>> >>> Note that the Divisions are variable, the structure does not have to be >>> an octree. This is useful to produce bins that are closer to uniform shape, >>> or even create a 2.5D, sorta flat binning tree (e.g. z-divisions always == >>> 1). >>> >>> Algorithmic approach: (this can easily be threaded): >>> For every point p_i in the input point cloud, generate a random number r >>> (0<=r<1). Assume that there are T total bins. >>> The probability (assuming an octree) that p_i is in level 0: is 1/T; in >>> level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into >>> proportional subranges that r maps into. Thus r will randomly select which >>> level of the tree a point belongs in. >>> >>> Once p_i is assigned a level, compute a hash index h_i which consists of >>> the (i,j,k) bin index added to T_l, there T_l is the total number of bins at >>> the beginning of level l. This hash index is the key to get the sort in the >>> right order; using the level information is a way to segment the bins from >>> different levels into contiguous runs. >>> >>> Now sort the points based on this hash index. The sort is where most of >>> the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted >>> points list. Next create the offsets array by running through the sorted >>> hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's >>> easy to do, and can even be done in parallel.) >>> >>> From the mapper point of view: knowing the bounds, divisions, current >>> level, and (i,j,k) bin index it is possible to construct a local bounding >>> box for each bin. Then there is direct access to the list of points in each >>> bin (through the offsets). And of course since this is a hierarchy of >>> uniform bins, you can easily perform view culling etc. and choose the >>> appropriate level for LODs. >>> >>> That's it in a nutshell. Unfortunately I've got lots of pointy-haired >>> boss stuff to do so this might take a bit to complete, but I'd really like >>> to get a prototype class written this week >>> (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) >>> Initially I'll have this class build the data structures, with a special >>> back-door method to write the data out. Later on we'll decide if we need to >>> separate this backdoor IO into a separate class, etc. >>> >>> Best, >>> W >>> >>> >>> On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin >>> wrote: >>>> >>>> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a >>>> simple ascii X Y Z R G B type format that I usually immediately convert to >>>> VTK XML format as that is far faster and more compact. So unfortunately PTS >>>> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some >>>> bounding box metadata. >>>> >>>> Ken >>>> >>>> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder >>>> wrote: >>>>> >>>>> Ken- >>>>> >>>>> I am totally with you. I am writing some simple stuff at the moment >>>>> like VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly >>>>> to get my head around the challenges and serve as a stop gap until our >>>>> better stuff comes along. I really like your idea and I do plan to implement >>>>> this; it's really not too hard to do from what I understand and given the >>>>> pieces available in VTK. >>>>> >>>>> So I'll wrap up this simple VoxelGrid and then take a crack at the >>>>> beast you've envisioned. The two major pieces seems to be 1) create a class >>>>> that builds the hierarchical structure, and 2) write a reader/writer pair >>>>> that can perform associated IO. In an earlier email you mentioned a PTS >>>>> reader that you made improvement to; is this a good exemplar data format or >>>>> do you have a better starting point? >>>>> >>>>> It seems I have a homework assignment for the weekend :-) >>>>> >>>>> Best, >>>>> W >>>>> >>>>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >>>>> wrote: >>>>>> >>>>>> Nice, can I make a specific request Will? :-) Part of what I want to >>>>>> do for large point clouds is something like the following: >>>>>> >>>>>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>>>>> pieces (but not the data) >>>>>> >>>>>> 2) Read in the first piece and use it for rendering >>>>>> >>>>>> 3) In the background read in more pieces, as they are loaded make them >>>>>> available to the mapper >>>>>> >>>>>> 4) The mapper based on the current camera parameters and bounding >>>>>> boxes of the pieces intelligently selects what pieces to render. This >>>>>> provides a happy fast interactive experience leading to world peace. >>>>>> >>>>>> For this to work well my thought was to have the pieces be broken up >>>>>> in a special way sort of like an octree but a spatial hash etc would be just >>>>>> as good as long as it is hierarchical and structured. Think of breaking up >>>>>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the >>>>>> data covering the entire bounding box. The next eight pieces also each >>>>>> contain about 1/73 of the data each constrained by their octant of the >>>>>> bounding box. Same idea for the next 64 boxes, they are just one level >>>>>> further down. This would work really well for a smart mapper providing fast >>>>>> first render plus fast LOD/subsequent renders. I can implement 1-4 pretty >>>>>> quickly. >>>>>> >>>>>> But .... for it to work I need someone to create the 73 piece file the >>>>>> right way. (it does not have to be 73, and clearly some of those 73 will be >>>>>> empty, it just needs to be hierarchical and structured so that a group of >>>>>> pieces can be represented at a lower level of detail by some other piece) My >>>>>> gut feeling was to have the LOD pieces use actual points of the dataset (not >>>>>> centroids or similar) that way as more pieces are loaded we are just >>>>>> providing more detail, not replacing fake data (centroids) with real data. >>>>>> But really either approach is pretty easy to implement in the mapper. The >>>>>> latter approach just means the entire dataset footprint is larger because >>>>>> some of the points are not part of the full res dataset because you >>>>>> generated them. >>>>>> >>>>>> I could be totally off base but that was my gut feeling on rendering > >>>>>> 2GB point clouds in a nice zippy manner. >>>>>> >>>>>> TLDR: I want someone to write a filter/writer subclass to create a >>>>>> special 73 piece vtk file :-) >>>>>> >>>>>> Ken >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder >>>>>> wrote: >>>>>>> >>>>>>> Geoff- >>>>>>> >>>>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>>>>> threaded and seems to be fast. >>>>>>> >>>>>>> Question for you before I push the work to the repository: averaging >>>>>>> points in each bin provides a nice subsampled point position. But what do >>>>>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>>>>> could be averaged too. There are however other options like finding the >>>>>>> closest point to the subsampled point and using those attribute values, or >>>>>>> if you want to get really fancy, using an interpolation kernel to >>>>>>> interpolate to the subsampled point. >>>>>>> >>>>>>> Thoughts? >>>>>>> W >>>>>>> >>>>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder >>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks for the feedback. I have some downsampling filters in the >>>>>>>> works now, I'll let you know when I have something ready. >>>>>>>> >>>>>>>> BTW we are on a similar path. PCL is awesome, but we have some >>>>>>>> common workflows that would be better served with more compact software >>>>>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>>>>> knock of a small kernel of capability to achieve this. >>>>>>>> >>>>>>>> Best, >>>>>>>> W >>>>>>>> >>>>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Will, >>>>>>>>> >>>>>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>>>>> from some point cloud data. I have some initial pre processing steps that I >>>>>>>>> use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >>>>>>>>> PCL dependency and use exclusively vtk. My point cloud data grows very >>>>>>>>> large over time with a lot of redundant points so its very important to >>>>>>>>> downsample them onto uniform spacing ( >>>>>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before >>>>>>>>> processing them in vtk. Would it make sense to add something like this to >>>>>>>>> your library? >>>>>>>>> >>>>>>>>> Geoff >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> FYI- I have committed an initial set of filters for performing >>>>>>>>>> point cloud processing. Any feedback or suggestions are welcome as this is >>>>>>>>>> an initial prototype. The work is currently available as a remote module to >>>>>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>>>>> >>>>>>>>>> A couple of notes: >>>>>>>>>> + Right now I am using vtkPolyData to represent the point cloud >>>>>>>>>> via a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells >>>>>>>>>> created to save on memory. >>>>>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>>>>> + There is a general framework for filtering point clouds via the >>>>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>>>>> filters also have an optional, second output which contains any points >>>>>>>>>> removed from the input. >>>>>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>>>>> implicit function). Some of these names are inspired by PCL names. >>>>>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>>>>> although I have not done much testing. >>>>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>>>>> wrote that is very fast. >>>>>>>>>> >>>>>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>>>>> suggestions for other filters to write are welcome (to round out some of the >>>>>>>>>> core functionality). The repository is in flux as I try crazy ideas and try >>>>>>>>>> to educate myself, so be forewarned. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> W >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Powered by www.kitware.com >>>>>>>>>> >>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>> >>>>>>>>>> Search the list archives at: >>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>> >>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> William J. Schroeder, PhD >>>>>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>>>>> 28 Corporate Drive >>>>>>>> Clifton Park, NY 12065 >>>>>>>> will.schroeder at kitware.com >>>>>>>> http://www.kitware.com >>>>>>>> (518) 881-4902 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> William J. Schroeder, PhD >>>>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>>>> 28 Corporate Drive >>>>>>> Clifton Park, NY 12065 >>>>>>> will.schroeder at kitware.com >>>>>>> http://www.kitware.com >>>>>>> (518) 881-4902 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> William J. Schroeder, PhD >>>>> Kitware, Inc. - Building the World's Technical Computing Software >>>>> 28 Corporate Drive >>>>> Clifton Park, NY 12065 >>>>> will.schroeder at kitware.com >>>>> http://www.kitware.com >>>>> (518) 881-4902 >>>> >>>> >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. - Building the World's Technical Computing Software >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >> >> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From xabivtk at gmail.com Wed Feb 3 11:26:01 2016 From: xabivtk at gmail.com (Xabi Riobe) Date: Wed, 3 Feb 2016 17:26:01 +0100 Subject: [vtk-developers] Master vs Release v6 maintenance In-Reply-To: <20160203161702.GB1800@megas.kitware.com> References: <20151019150730.GA30474@megas.khq.kitware.com> <20151030185646.GB8203@megas.khq.kitware.com> <20160203161702.GB1800@megas.kitware.com> Message-ID: Fine, thanks for the information ! 2016-02-03 17:17 GMT+01:00 Ben Boeckel : > On Wed, Feb 03, 2016 at 15:43:56 +0100, Xabi Riobe wrote: > > I'm wondering what is the plan for 6.3.x branch, if there will be some > tag > > for a release with mailing list anouncement in parallel of "main" vtk > > releases, or if the release-6.3 branch will be updated when fixes are > > required and it's up to users to check it? > > There will probably be a 6.4 at some point. I don't know of an exact > timeline right now. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Wed Feb 3 11:30:49 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 3 Feb 2016 11:30:49 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Bill- I added a couple of methods to point locator and need to push them. I'll do that shortly, sorry for the hassle. It'll be later today, W On Wed, Feb 3, 2016 at 11:22 AM, Bill Lorensen wrote: > Will, > > When I try to build the latest I get: > /Users/lorensen/ProjectsGIT/VTK/Remote/vtkPointCloud/vtkVoxelGrid.cxx:76: > error: ?class vtkStaticPointLocator? has no member named > ?GetBucketIds? > > On Wed, Feb 3, 2016 at 8:24 AM, Geoff Wright wrote: > > Hi Will, > > > > Looks good! I like the use of SMP. I'll definitely try it out once the > > interpolation is in place, it will be great to eliminate PCL as a > > dependency. > > > > Regards, > > Geoff > > > > > > On Tue, Feb 2, 2016 at 4:42 PM Will Schroeder < > will.schroeder at kitware.com> > > wrote: > >> > >> Geoff- > >> > >> I pushed an in progress version of VoxelGrid. As well as a hierarchical > >> points binner. This is a work in progress so be forewarned. In > particular, > >> VoxelGrid does not yet interpolate its attributes yet. This is because > I've > >> got another branch in VTK for point interpolation, including > interpolation > >> kernels, that must ripen and placed in master first. Then the > interpolation > >> will be easy to add. > >> > >> W > >> > >> On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder > >> wrote: > >>> > >>> Okay I have a quick and dirty design for "file" format and algorithmic > >>> approach that I'll start implementing shortly. We'll clean it up with > time. > >>> Any feedback is welcome. > >>> > >>> The data file format has three basic logical parts, which could be > >>> written into separate files or one file, whatever. 1) metadata, 2) > offsets, > >>> and 3) sorted points. > >>> > >>> The key idea is that the points are in sorted order, beginning with > level > >>> 0 root node, followed by level 1 bins (8 bins) and their points, and > level 2 > >>> bins (64 bins) and their points, and so on. The points are just a > contiguous > >>> array of x-y-z, x-y-z, of type float or double (user specified), etc. > Data > >>> attributes could be stored in similar fashion (all easily changeable > >>> depending on what you prefer). Since the number of points in each bin > is > >>> variable and may even be zero, this is where the offsets come into > play. > >>> (Note that points are not repeated, and statistically sampled as you > suggest > >>> ~1/(total number of bins)*NumberOfPoints points in each bin.) > >>> > >>> The offsets are integral values that simply refer to a position in the > >>> sorted points array corresponding to the beginning of each bin. So > (level 0, > >>> bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), > (1,7), > >>> (2,0), (2,1), ... you get the idea. For your example of a 3-level > octree, > >>> there would be 73 offset values (or T=73 total bins). Note that if > offset_i > >>> == offset_(i+1) then there are zero points in the bin referred to by > >>> offset_i. We can also represent the offsets with different integral > types > >>> depending on the number of points (to save memory). > >>> > >>> The metadata contains something like (assuming multiple separate files, > >>> which of course can be memory mapped, etc): > >>> NumberOfPoints #npts > >>> NumberOfLevels #numLevels > >>> Divisions 2 2 2 > >>> Bounds (xmin,xmax,ymin,ymax,zmin,zmax) > >>> Points type "points.file" > >>> Offsets type "offsets.file" > >>> Array type numComp "scalars.file" > >>> Array type numComp "vectors.file" > >>> > >>> Note that the Divisions are variable, the structure does not have to be > >>> an octree. This is useful to produce bins that are closer to uniform > shape, > >>> or even create a 2.5D, sorta flat binning tree (e.g. z-divisions > always == > >>> 1). > >>> > >>> Algorithmic approach: (this can easily be threaded): > >>> For every point p_i in the input point cloud, generate a random number > r > >>> (0<=r<1). Assume that there are T total bins. > >>> The probability (assuming an octree) that p_i is in level 0: is 1/T; in > >>> level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into > >>> proportional subranges that r maps into. Thus r will randomly select > which > >>> level of the tree a point belongs in. > >>> > >>> Once p_i is assigned a level, compute a hash index h_i which consists > of > >>> the (i,j,k) bin index added to T_l, there T_l is the total number of > bins at > >>> the beginning of level l. This hash index is the key to get the sort > in the > >>> right order; using the level information is a way to segment the bins > from > >>> different levels into contiguous runs. > >>> > >>> Now sort the points based on this hash index. The sort is where most of > >>> the work is done and we'll use vtkSMPTools::Sort(). This produces a > sorted > >>> points list. Next create the offsets array by running through the > sorted > >>> hash indices, etc. (I've done this before in vtkStaticPointsLocator, > it's > >>> easy to do, and can even be done in parallel.) > >>> > >>> From the mapper point of view: knowing the bounds, divisions, current > >>> level, and (i,j,k) bin index it is possible to construct a local > bounding > >>> box for each bin. Then there is direct access to the list of points in > each > >>> bin (through the offsets). And of course since this is a hierarchy of > >>> uniform bins, you can easily perform view culling etc. and choose the > >>> appropriate level for LODs. > >>> > >>> That's it in a nutshell. Unfortunately I've got lots of pointy-haired > >>> boss stuff to do so this might take a bit to complete, but I'd really > like > >>> to get a prototype class written this week > >>> (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) > >>> Initially I'll have this class build the data structures, with a > special > >>> back-door method to write the data out. Later on we'll decide if we > need to > >>> separate this backdoor IO into a separate class, etc. > >>> > >>> Best, > >>> W > >>> > >>> > >>> On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin > >>> wrote: > >>>> > >>>> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a > >>>> simple ascii X Y Z R G B type format that I usually immediately > convert to > >>>> VTK XML format as that is far faster and more compact. So > unfortunately PTS > >>>> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds > some > >>>> bounding box metadata. > >>>> > >>>> Ken > >>>> > >>>> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder > >>>> wrote: > >>>>> > >>>>> Ken- > >>>>> > >>>>> I am totally with you. I am writing some simple stuff at the moment > >>>>> like VoxelGrid as sort of a "drop-in" replacements for PCL > workflows; mostly > >>>>> to get my head around the challenges and serve as a stop gap until > our > >>>>> better stuff comes along. I really like your idea and I do plan to > implement > >>>>> this; it's really not too hard to do from what I understand and > given the > >>>>> pieces available in VTK. > >>>>> > >>>>> So I'll wrap up this simple VoxelGrid and then take a crack at the > >>>>> beast you've envisioned. The two major pieces seems to be 1) create > a class > >>>>> that builds the hierarchical structure, and 2) write a reader/writer > pair > >>>>> that can perform associated IO. In an earlier email you mentioned a > PTS > >>>>> reader that you made improvement to; is this a good exemplar data > format or > >>>>> do you have a better starting point? > >>>>> > >>>>> It seems I have a homework assignment for the weekend :-) > >>>>> > >>>>> Best, > >>>>> W > >>>>> > >>>>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin > > >>>>> wrote: > >>>>>> > >>>>>> Nice, can I make a specific request Will? :-) Part of what I want to > >>>>>> do for large point clouds is something like the following: > >>>>>> > >>>>>> 1) Open a VTK multipiece file and read in the bounding boxes of the > >>>>>> pieces (but not the data) > >>>>>> > >>>>>> 2) Read in the first piece and use it for rendering > >>>>>> > >>>>>> 3) In the background read in more pieces, as they are loaded make > them > >>>>>> available to the mapper > >>>>>> > >>>>>> 4) The mapper based on the current camera parameters and bounding > >>>>>> boxes of the pieces intelligently selects what pieces to render. > This > >>>>>> provides a happy fast interactive experience leading to world peace. > >>>>>> > >>>>>> For this to work well my thought was to have the pieces be broken up > >>>>>> in a special way sort of like an octree but a spatial hash etc > would be just > >>>>>> as good as long as it is hierarchical and structured. Think of > breaking up > >>>>>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 > of the > >>>>>> data covering the entire bounding box. The next eight pieces also > each > >>>>>> contain about 1/73 of the data each constrained by their octant of > the > >>>>>> bounding box. Same idea for the next 64 boxes, they are just one > level > >>>>>> further down. This would work really well for a smart mapper > providing fast > >>>>>> first render plus fast LOD/subsequent renders. I can implement 1-4 > pretty > >>>>>> quickly. > >>>>>> > >>>>>> But .... for it to work I need someone to create the 73 piece file > the > >>>>>> right way. (it does not have to be 73, and clearly some of those 73 > will be > >>>>>> empty, it just needs to be hierarchical and structured so that a > group of > >>>>>> pieces can be represented at a lower level of detail by some other > piece) My > >>>>>> gut feeling was to have the LOD pieces use actual points of the > dataset (not > >>>>>> centroids or similar) that way as more pieces are loaded we are just > >>>>>> providing more detail, not replacing fake data (centroids) with > real data. > >>>>>> But really either approach is pretty easy to implement in the > mapper. The > >>>>>> latter approach just means the entire dataset footprint is larger > because > >>>>>> some of the points are not part of the full res dataset because you > >>>>>> generated them. > >>>>>> > >>>>>> I could be totally off base but that was my gut feeling on > rendering > > >>>>>> 2GB point clouds in a nice zippy manner. > >>>>>> > >>>>>> TLDR: I want someone to write a filter/writer subclass to create a > >>>>>> special 73 piece vtk file :-) > >>>>>> > >>>>>> Ken > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder > >>>>>> wrote: > >>>>>>> > >>>>>>> Geoff- > >>>>>>> > >>>>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. > It's > >>>>>>> threaded and seems to be fast. > >>>>>>> > >>>>>>> Question for you before I push the work to the repository: > averaging > >>>>>>> points in each bin provides a nice subsampled point position. But > what do > >>>>>>> you think we should do for attributes (e.g., scalars, vector, > etc.)? These > >>>>>>> could be averaged too. There are however other options like > finding the > >>>>>>> closest point to the subsampled point and using those attribute > values, or > >>>>>>> if you want to get really fancy, using an interpolation kernel to > >>>>>>> interpolate to the subsampled point. > >>>>>>> > >>>>>>> Thoughts? > >>>>>>> W > >>>>>>> > >>>>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Thanks for the feedback. I have some downsampling filters in the > >>>>>>>> works now, I'll let you know when I have something ready. > >>>>>>>> > >>>>>>>> BTW we are on a similar path. PCL is awesome, but we have some > >>>>>>>> common workflows that would be better served with more compact > software > >>>>>>>> environments, and with minimal IO and/or data transfer. So we're > trying to > >>>>>>>> knock of a small kernel of capability to achieve this. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> W > >>>>>>>> > >>>>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright > > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Will, > >>>>>>>>> > >>>>>>>>> This is good to see. I'm currently using VTK to generate > surfaces > >>>>>>>>> from some point cloud data. I have some initial pre processing > steps that I > >>>>>>>>> use PCL (point cloud library) for, and then a vtk stage that > converts PCL > >>>>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to > eliminate the > >>>>>>>>> PCL dependency and use exclusively vtk. My point cloud data > grows very > >>>>>>>>> large over time with a lot of redundant points so its very > important to > >>>>>>>>> downsample them onto uniform spacing ( > >>>>>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html > ) before > >>>>>>>>> processing them in vtk. Would it make sense to add something > like this to > >>>>>>>>> your library? > >>>>>>>>> > >>>>>>>>> Geoff > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> FYI- I have committed an initial set of filters for performing > >>>>>>>>>> point cloud processing. Any feedback or suggestions are welcome > as this is > >>>>>>>>>> an initial prototype. The work is currently available as a > remote module to > >>>>>>>>>> VTK (vtkPointCloud) via this repository: > >>>>>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git > >>>>>>>>>> > >>>>>>>>>> A couple of notes: > >>>>>>>>>> + Right now I am using vtkPolyData to represent the point cloud > >>>>>>>>>> via a vtkPoints instance. There are no vtkVertex, vtkPolyVertex > cells > >>>>>>>>>> created to save on memory. > >>>>>>>>>> + The classes will process as input any vtkPointSet dataset > >>>>>>>>>> + There is a general framework for filtering point clouds via > the > >>>>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, > these > >>>>>>>>>> filters also have an optional, second output which contains any > points > >>>>>>>>>> removed from the input. > >>>>>>>>>> + Current filters include vtkRadiusOutlierRemoval, > >>>>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points > using an > >>>>>>>>>> implicit function). Some of these names are inspired by PCL > names. > >>>>>>>>>> + All filters are threaded using vtkSMPTools using a threaded > >>>>>>>>>> locator (vtkStaticPointLocator) so I believe that this is > relatively fast, > >>>>>>>>>> although I have not done much testing. > >>>>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that > Ken > >>>>>>>>>> wrote that is very fast. > >>>>>>>>>> > >>>>>>>>>> As usual comments and suggestions are requested. In particular > any > >>>>>>>>>> suggestions for other filters to write are welcome (to round > out some of the > >>>>>>>>>> core functionality). The repository is in flux as I try crazy > ideas and try > >>>>>>>>>> to educate myself, so be forewarned. > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> W > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Powered by www.kitware.com > >>>>>>>>>> > >>>>>>>>>> Visit other Kitware open-source projects at > >>>>>>>>>> http://www.kitware.com/opensource/opensource.html > >>>>>>>>>> > >>>>>>>>>> Search the list archives at: > >>>>>>>>>> http://markmail.org/search/?q=vtk-developers > >>>>>>>>>> > >>>>>>>>>> Follow this link to subscribe/unsubscribe: > >>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> William J. Schroeder, PhD > >>>>>>>> Kitware, Inc. - Building the World's Technical Computing Software > >>>>>>>> 28 Corporate Drive > >>>>>>>> Clifton Park, NY 12065 > >>>>>>>> will.schroeder at kitware.com > >>>>>>>> http://www.kitware.com > >>>>>>>> (518) 881-4902 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> William J. Schroeder, PhD > >>>>>>> Kitware, Inc. - Building the World's Technical Computing Software > >>>>>>> 28 Corporate Drive > >>>>>>> Clifton Park, NY 12065 > >>>>>>> will.schroeder at kitware.com > >>>>>>> http://www.kitware.com > >>>>>>> (518) 881-4902 > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Powered by www.kitware.com > >>>>>>> > >>>>>>> Visit other Kitware open-source projects at > >>>>>>> http://www.kitware.com/opensource/opensource.html > >>>>>>> > >>>>>>> Search the list archives at: > >>>>>>> http://markmail.org/search/?q=vtk-developers > >>>>>>> > >>>>>>> Follow this link to subscribe/unsubscribe: > >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> William J. Schroeder, PhD > >>>>> Kitware, Inc. - Building the World's Technical Computing Software > >>>>> 28 Corporate Drive > >>>>> Clifton Park, NY 12065 > >>>>> will.schroeder at kitware.com > >>>>> http://www.kitware.com > >>>>> (518) 881-4902 > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> 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. > >>> > >>> > >>> > >>> > >>> -- > >>> William J. Schroeder, PhD > >>> Kitware, Inc. - Building the World's Technical Computing Software > >>> 28 Corporate Drive > >>> Clifton Park, NY 12065 > >>> will.schroeder at kitware.com > >>> http://www.kitware.com > >>> (518) 881-4902 > >> > >> > >> > >> > >> -- > >> William J. Schroeder, PhD > >> Kitware, Inc. - Building the World's Technical Computing Software > >> 28 Corporate Drive > >> Clifton Park, NY 12065 > >> will.schroeder at kitware.com > >> http://www.kitware.com > >> (518) 881-4902 > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Thu Feb 4 08:54:07 2016 From: xabivtk at gmail.com (Xabi Riobe) Date: Thu, 4 Feb 2016 14:54:07 +0100 Subject: [vtk-developers] Bug in vtkCamera::Elevation Message-ID: Hi, There is an issue in vtkCamera::Elevation if the angle is 90. It is 100% reproductible with VS2013 if compiled in 64bits, otherwise the rounding epsilon makes it work by chance. I'm willing to fix it in GitLab but first i would like your opinion about the best way to do it. with a simple example of a plane in a renderer, and a call to renderer->GetActiveCamera()->Elevation(90) What happens in the call stack of vtkCamera::Elevation : vtkCamera::SetPosition() vtkCamera::ComputeViewTransform vtkPerspectiveTransform::SetupCamera vtkMath::Cross(viewUp,viewPlaneNormal,viewSideways); where viewUp and viewPlaneNormal are both (0,1,0) so viewSideways is (0,0,0) leading to bad camera parameters. Here comes the VS13+64bits configuration case, when with others, viewSideways is luckily different than 0 What do you think of applying the rotation to the viewUp vector in vtkCamera::Elevation before the call to SetPosition? Should we put a warning in vtkPerspectiveTransform::SetupCamera when vtkMath::Normalize returns 0? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Feb 4 17:39:04 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 4 Feb 2016 15:39:04 -0700 Subject: [vtk-developers] Bug in vtkCamera::Elevation In-Reply-To: References: Message-ID: Hi Xabi, I think it's a good fix, note that the Pitch() method probably has the same issue. It will break backwards compatibility, however, because currently the Elevation() method leaves the ViewUp unchanged. So any code that calls Elevation() and then calls Azimuth() will give a different result after your fix. Does anyone know why the Elevation() and Pitch() methods leave the ViewUp unchanged? - David On Thu, Feb 4, 2016 at 6:54 AM, Xabi Riobe wrote: > Hi, > > There is an issue in vtkCamera::Elevation if the angle is 90. > > It is 100% reproductible with VS2013 if compiled in 64bits, otherwise the > rounding epsilon makes it work by chance. > > I'm willing to fix it in GitLab but first i would like your opinion about > the best way to do it. > > with a simple example of a plane in a renderer, and a call to > renderer->GetActiveCamera()->Elevation(90) > > What happens in the call stack of vtkCamera::Elevation : > vtkCamera::SetPosition() > vtkCamera::ComputeViewTransform > vtkPerspectiveTransform::SetupCamera > > vtkMath::Cross(viewUp,viewPlaneNormal,viewSideways); > > where viewUp and viewPlaneNormal are both (0,1,0) so viewSideways is > (0,0,0) leading to bad camera parameters. > Here comes the VS13+64bits configuration case, when with others, > viewSideways is luckily different than 0 > > What do you think of applying the rotation to the viewUp vector in > vtkCamera::Elevation before the call to SetPosition? > Should we put a warning in vtkPerspectiveTransform::SetupCamera > when vtkMath::Normalize returns 0? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Fri Feb 5 05:09:14 2016 From: xabivtk at gmail.com (Xabi Riobe) Date: Fri, 5 Feb 2016 11:09:14 +0100 Subject: [vtk-developers] Bug in vtkCamera::Elevation In-Reply-To: References: Message-ID: Yes the fix will be for both Elevation and Pitch and i think it makes sense for the ViewUp to be modified, but you are wright to raise the backwards compatibility issue... I could set the computed ViewUp before the call to SetPosition and set back the old one after, that would fix the main problem and keep backwards compatibility. I can be ok with that but it feels odd to me... If no one comes with a better solution in a couple of days will push that one. For the warning in vtkPerspectiveTransform::SetupCamera i have second thoughts, as VTK in general does not check stuff like that and let the responsibility to the caller. What do you think? 2016-02-04 23:39 GMT+01:00 David Gobbi : > Hi Xabi, > > I think it's a good fix, note that the Pitch() method probably has the > same issue. > > It will break backwards compatibility, however, because currently the > Elevation() > method leaves the ViewUp unchanged. So any code that calls Elevation() and > then calls Azimuth() will give a different result after your fix. > > Does anyone know why the Elevation() and Pitch() methods leave the ViewUp > unchanged? > > - David > > > On Thu, Feb 4, 2016 at 6:54 AM, Xabi Riobe wrote: > >> Hi, >> >> There is an issue in vtkCamera::Elevation if the angle is 90. >> >> It is 100% reproductible with VS2013 if compiled in 64bits, otherwise the >> rounding epsilon makes it work by chance. >> >> I'm willing to fix it in GitLab but first i would like your opinion about >> the best way to do it. >> >> with a simple example of a plane in a renderer, and a call to >> renderer->GetActiveCamera()->Elevation(90) >> >> What happens in the call stack of vtkCamera::Elevation : >> vtkCamera::SetPosition() >> vtkCamera::ComputeViewTransform >> vtkPerspectiveTransform::SetupCamera >> >> vtkMath::Cross(viewUp,viewPlaneNormal,viewSideways); >> >> where viewUp and viewPlaneNormal are both (0,1,0) so viewSideways is >> (0,0,0) leading to bad camera parameters. >> Here comes the VS13+64bits configuration case, when with others, >> viewSideways is luckily different than 0 >> >> What do you think of applying the rotation to the viewUp vector in >> vtkCamera::Elevation before the call to SetPosition? >> Should we put a warning in vtkPerspectiveTransform::SetupCamera >> when vtkMath::Normalize returns 0? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Feb 5 06:54:53 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 5 Feb 2016 06:54:53 -0500 Subject: [vtk-developers] Bug in vtkCamera::Elevation In-Reply-To: References: Message-ID: This is a known problem since 1993 when VTK was first written. It is presumed to be an application-level issue. That is, if you are flying over terrain, you do not want to be messing with the view up, otherwise the elevation, pitch, etc. lose their meaning. As evidence of this check out VTK/Interaction/Style/vtkInteractionStyleTerrain which has explicit commentary about dealing with the north pole singularity. Then look at vtkInteractorStyleTrackballCamera, vtkInteractorStyleJoystickCamera, etc. They all have explicit calls to camera->OrthogonalizeViewUp() which is added to address the view up singularity. Best, W On Thu, Feb 4, 2016 at 8:54 AM, Xabi Riobe wrote: > Hi, > > There is an issue in vtkCamera::Elevation if the angle is 90. > > It is 100% reproductible with VS2013 if compiled in 64bits, otherwise the > rounding epsilon makes it work by chance. > > I'm willing to fix it in GitLab but first i would like your opinion about > the best way to do it. > > with a simple example of a plane in a renderer, and a call to > renderer->GetActiveCamera()->Elevation(90) > > What happens in the call stack of vtkCamera::Elevation : > vtkCamera::SetPosition() > vtkCamera::ComputeViewTransform > vtkPerspectiveTransform::SetupCamera > > vtkMath::Cross(viewUp,viewPlaneNormal,viewSideways); > > where viewUp and viewPlaneNormal are both (0,1,0) so viewSideways is > (0,0,0) leading to bad camera parameters. > Here comes the VS13+64bits configuration case, when with others, > viewSideways is luckily different than 0 > > What do you think of applying the rotation to the viewUp vector in > vtkCamera::Elevation before the call to SetPosition? > Should we put a warning in vtkPerspectiveTransform::SetupCamera > when vtkMath::Normalize returns 0? > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Fri Feb 5 07:59:09 2016 From: xabivtk at gmail.com (Xabi Riobe) Date: Fri, 5 Feb 2016 13:59:09 +0100 Subject: [vtk-developers] Bug in vtkCamera::Elevation In-Reply-To: References: Message-ID: Ok now it looks clear to me, thanks for the explanation Will. So i'll just fix the 90? issue. 2016-02-05 12:54 GMT+01:00 Will Schroeder : > This is a known problem since 1993 when VTK was first written. It is > presumed to be an application-level issue. That is, if you are flying over > terrain, you do not want to be messing with the view up, otherwise the > elevation, pitch, etc. lose their meaning. > > As evidence of this check out > VTK/Interaction/Style/vtkInteractionStyleTerrain which has explicit > commentary about dealing with the north pole singularity. Then look at > vtkInteractorStyleTrackballCamera, vtkInteractorStyleJoystickCamera, etc. > They all have explicit calls to camera->OrthogonalizeViewUp() which is > added to address the view up singularity. > > Best, > W > > On Thu, Feb 4, 2016 at 8:54 AM, Xabi Riobe wrote: > >> Hi, >> >> There is an issue in vtkCamera::Elevation if the angle is 90. >> >> It is 100% reproductible with VS2013 if compiled in 64bits, otherwise the >> rounding epsilon makes it work by chance. >> >> I'm willing to fix it in GitLab but first i would like your opinion about >> the best way to do it. >> >> with a simple example of a plane in a renderer, and a call to >> renderer->GetActiveCamera()->Elevation(90) >> >> What happens in the call stack of vtkCamera::Elevation : >> vtkCamera::SetPosition() >> vtkCamera::ComputeViewTransform >> vtkPerspectiveTransform::SetupCamera >> >> vtkMath::Cross(viewUp,viewPlaneNormal,viewSideways); >> >> where viewUp and viewPlaneNormal are both (0,1,0) so viewSideways is >> (0,0,0) leading to bad camera parameters. >> Here comes the VS13+64bits configuration case, when with others, >> viewSideways is luckily different than 0 >> >> What do you think of applying the rotation to the viewUp vector in >> vtkCamera::Elevation before the call to SetPosition? >> Should we put a warning in vtkPerspectiveTransform::SetupCamera >> when vtkMath::Normalize returns 0? >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Feb 5 11:10:39 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 11:10:39 -0500 Subject: [vtk-developers] TestImageDataLIC2D test failures In-Reply-To: <94447f2e4aacd8749aeae25fe827176a@mail.gmail.com> References: <94447f2e4aacd8749aeae25fe827176a@mail.gmail.com> Message-ID: <56B4C97F.8040409@kitware.com> On 10/16/2015 11:52 AM, Ken Martin wrote: > That garbage (or slightly different garbage) is in the valid images > as well from OpenGL1, so I suspect the issue has been present for > a long time. You can see a black line along the left edge that > does not look right. I?ll try to take a quick look soon to see if > the issue is easy to find/fix unless someone else wants to :-) This test is still consistently failing on several machines: https://open.cdash.org/testSummary.php?project=11&name=vtkRenderingLICOpenGL2Cxx-TestImageDataLIC2D&date=2016-02-05 Now it is not just a column of corruption but the entire test image is simply blank. -Brad From bill.lorensen at gmail.com Fri Feb 5 11:10:55 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Feb 2016 11:10:55 -0500 Subject: [vtk-developers] VTK OpenGL2 Shaders Message-ID: Folks, Is there documentation on how to write glsl shaders for VTK? Bill -- Unpaid intern in BillsBasement at noware dot com From pieper at isomics.com Fri Feb 5 11:31:48 2016 From: pieper at isomics.com (Steve Pieper) Date: Fri, 5 Feb 2016 11:31:48 -0500 Subject: [vtk-developers] VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: Hi Bill - Great question - I'm looking forward to hear what folks have been doing in this respect. For me, I have two classes I have been testing with Slicer - one that manages 3D textures and one that implements shaders [1,2]. We worked on it at project week [3] and I'm liking how it works. -Steve [1] https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h [2] https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h [3] http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen wrote: > Folks, > > Is there documentation on how to write glsl shaders for VTK? > > Bill > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Feb 5 12:11:35 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 5 Feb 2016 12:11:35 -0500 Subject: [vtk-developers] VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: Not to my knowledge. Although we talked about it at-least having an API so that folks can replace the shader or ember new shader code to the existing one. Also, having some common convention would be nice. Thanks, On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper wrote: > Hi Bill - > > Great question - I'm looking forward to hear what folks have been doing in > this respect. > > For me, I have two classes I have been testing with Slicer - one that > manages 3D textures and one that implements shaders [1,2]. We worked on it > at project week [3] and I'm liking how it works. > > -Steve > > [1] > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h > > [2] > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h > > [3] > http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL > > On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen > wrote: > >> Folks, >> >> Is there documentation on how to write glsl shaders for VTK? >> >> Bill >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Feb 5 13:11:27 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 5 Feb 2016 13:11:27 -0500 Subject: [vtk-developers] TestImageDataLIC2D test failures In-Reply-To: <56B4C97F.8040409@kitware.com> References: <94447f2e4aacd8749aeae25fe827176a@mail.gmail.com> <56B4C97F.8040409@kitware.com> Message-ID: I would bet this is a driver issue aka the typical Linux driver sometimes shows black images issue. No clue what it is. If you get a chance try running the test interactively and see if it works. If it does then I bet it is a driver/xserver/timing thing. e.g. grabbing the buffer returns black because something happened too fast. I see the same issue hit random tests on some other linux systems when they do a ctest -j 8 etc. Or it could be something completely else. On Fri, Feb 5, 2016 at 11:10 AM, Brad King wrote: > On 10/16/2015 11:52 AM, Ken Martin wrote: > > That garbage (or slightly different garbage) is in the valid images > > as well from OpenGL1, so I suspect the issue has been present for > > a long time. You can see a black line along the left edge that > > does not look right. I?ll try to take a quick look soon to see if > > the issue is easy to find/fix unless someone else wants to :-) > > This test is still consistently failing on several machines: > > > https://open.cdash.org/testSummary.php?project=11&name=vtkRenderingLICOpenGL2Cxx-TestImageDataLIC2D&date=2016-02-05 > > Now it is not just a column of corruption but the entire test > image is simply blank. > > -Brad > > -- 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: From ken.martin at kitware.com Fri Feb 5 13:20:30 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 5 Feb 2016 13:20:30 -0500 Subject: [vtk-developers] VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: Here is some info from an old email on customizing the polydatamapper shaders. The PointGaussianMapper also supports custom shaders and there is an example of that in Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx Thanks Ken 2) *CUSTOM SHADERS* - Added support for customizing the default PolyDataMapper shaders. You can now modify or completely replace the default VTK shadersusing methods such as AddShaderReplacement: replaces a strings in the current shader SetVertexShaderCode: replaces the default shader template with your own AddObserver(vtkCommand::UpdateShaderEvent,...) These methods (and similar others) give you a great degree on control of the VTK PolyData shaders. There are examples/tests in Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. Through the UpdateShaderEvent you can modify the default VTK uniforms or your own uniforms as desired. There is currently not a general purpose easy API for binding your own data arrays to attributes but we may add one at some point in the future. Currently VTK will send down the default attributes for you to use in your shader (position, normal, tcoords, colors, etc) On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Not to my knowledge. Although we talked about it at-least having an API so > that folks can replace the shader or ember new shader code to the existing > one. Also, having some common convention would be nice. > > Thanks, > > > > > On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper wrote: > >> Hi Bill - >> >> Great question - I'm looking forward to hear what folks have been doing >> in this respect. >> >> For me, I have two classes I have been testing with Slicer - one that >> manages 3D textures and one that implements shaders [1,2]. We worked on it >> at project week [3] and I'm liking how it works. >> >> -Steve >> >> [1] >> https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h >> >> [2] >> https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h >> >> [3] >> http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL >> >> On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen >> wrote: >> >>> Folks, >>> >>> Is there documentation on how to write glsl shaders for VTK? >>> >>> Bill >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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: From brad.king at kitware.com Fri Feb 5 14:54:40 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 14:54:40 -0500 Subject: [vtk-developers] TestImageDataLIC2D test failures In-Reply-To: References: <94447f2e4aacd8749aeae25fe827176a@mail.gmail.com> <56B4C97F.8040409@kitware.com> Message-ID: <56B4FE00.5010204@kitware.com> On 02/05/2016 01:11 PM, Ken Martin wrote: > I would bet this is a driver issue aka the typical Linux driver > sometimes shows black images issue. On hythloth it runs with a software mesa GL implementation. It happens every time and is not spurious. > try running the test interactively and see if it works The test does not create a render window interactor and does not respond to the -I command-line option :( -Brad From Gerrick.Bivins at halliburton.com Fri Feb 5 15:16:48 2016 From: Gerrick.Bivins at halliburton.com (Gerrick Bivins) Date: Fri, 5 Feb 2016 20:16:48 +0000 Subject: [vtk-developers] [EXTERNAL] Re: VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: So are these not valid anymore? http://www.vtk.org/Wiki/Shader_In_VTK http://www.vtk.org/Wiki/images/3/39/Vtk_shaders_tudelft_tut.pdf Or am I misunderstanding the question? Gerrick From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ken Martin Sent: Friday, February 05, 2016 12:21 PM To: Aashish Chaudhary Cc: VTK Developers; Steve Pieper Subject: [EXTERNAL] Re: [vtk-developers] VTK OpenGL2 Shaders Here is some info from an old email on customizing the polydatamapper shaders. The PointGaussianMapper also supports custom shaders and there is an example of that in Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx Thanks Ken 2) CUSTOM SHADERS - Added support for customizing the default PolyDataMapper shaders. You can now modify or completely replace the default VTK shadersusing methods such as AddShaderReplacement: replaces a strings in the current shader SetVertexShaderCode: replaces the default shader template with your own AddObserver(vtkCommand::UpdateShaderEvent,...) These methods (and similar others) give you a great degree on control of the VTK PolyData shaders. There are examples/tests in Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. Through the UpdateShaderEvent you can modify the default VTK uniforms or your own uniforms as desired. There is currently not a general purpose easy API for binding your own data arrays to attributes but we may add one at some point in the future. Currently VTK will send down the default attributes for you to use in your shader (position, normal, tcoords, colors, etc) On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary > wrote: Not to my knowledge. Although we talked about it at-least having an API so that folks can replace the shader or ember new shader code to the existing one. Also, having some common convention would be nice. Thanks, On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper > wrote: Hi Bill - Great question - I'm looking forward to hear what folks have been doing in this respect. For me, I have two classes I have been testing with Slicer - one that manages 3D textures and one that implements shaders [1,2]. We worked on it at project week [3] and I'm liking how it works. -Steve [1] https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h [2] https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h [3] http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen > wrote: Folks, Is there documentation on how to write glsl shaders for VTK? Bill -- Unpaid intern in BillsBasement at noware dot com _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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: From ken.martin at kitware.com Fri Feb 5 15:58:57 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 5 Feb 2016 15:58:57 -0500 Subject: [vtk-developers] CDash offine? Message-ID: Just hangs for me right now ... -- 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: From bill.lorensen at gmail.com Fri Feb 5 16:09:51 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Feb 2016 16:09:51 -0500 Subject: [vtk-developers] [EXTERNAL] Re: VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: They look old to me. I am interested in the OpenGL2 rendwering backend. Perhaps an expert will comment. On Fri, Feb 5, 2016 at 3:16 PM, Gerrick Bivins wrote: > So are these not valid anymore? > > http://www.vtk.org/Wiki/Shader_In_VTK > > http://www.vtk.org/Wiki/images/3/39/Vtk_shaders_tudelft_tut.pdf > > > > Or am I misunderstanding the question? > > Gerrick > > > > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of > Ken Martin > Sent: Friday, February 05, 2016 12:21 PM > To: Aashish Chaudhary > Cc: VTK Developers; Steve Pieper > Subject: [EXTERNAL] Re: [vtk-developers] VTK OpenGL2 Shaders > > > > Here is some info from an old email on customizing the polydatamapper > shaders. The PointGaussianMapper also supports custom shaders and there is > an example of that in > Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx > > Thanks > > Ken > > > > 2) CUSTOM SHADERS - Added support for customizing the default > PolyDataMapper shaders. You can now modify or completely replace the default > VTK shadersusing methods such as > > > > AddShaderReplacement: replaces a strings in the current shader > SetVertexShaderCode: replaces the default shader template with your own > > AddObserver(vtkCommand::UpdateShaderEvent,...) > > > > These methods (and similar others) give you a great degree on control of the > VTK PolyData shaders. There are examples/tests in > Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. > Through the UpdateShaderEvent you can modify the default VTK uniforms or > your own uniforms as desired. There is currently not a general purpose easy > API for binding your own data arrays to attributes but we may add one at > some point in the future. Currently VTK will send down the default > attributes for you to use in your shader (position, normal, tcoords, colors, > etc) > > > > > > On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary > wrote: > > Not to my knowledge. Although we talked about it at-least having an API so > that folks can replace the shader or ember new shader code to the existing > one. Also, having some common convention would be nice. > > > > Thanks, > > > > > > > > > > On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper wrote: > > Hi Bill - > > > > Great question - I'm looking forward to hear what folks have been doing in > this respect. > > > > For me, I have two classes I have been testing with Slicer - one that > manages 3D textures and one that implements shaders [1,2]. We worked on it > at project week [3] and I'm liking how it works. > > > > -Steve > > > > [1] > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h > > > > [2] > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h > > > > [3] > http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL > > > > On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen > wrote: > > Folks, > > Is there documentation on how to write glsl shaders for VTK? > > Bill > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > > | http://www.kitware.com/company/team/chaudhary.html > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > > 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. > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Fri Feb 5 16:16:04 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 5 Feb 2016 16:16:04 -0500 Subject: [vtk-developers] TestImageDataLIC2D test failures In-Reply-To: <56B4FE00.5010204@kitware.com> References: <94447f2e4aacd8749aeae25fe827176a@mail.gmail.com> <56B4C97F.8040409@kitware.com> <56B4FE00.5010204@kitware.com> Message-ID: OK using https://open.cdash.org/index.php?project=VTK&filtercount=4&showfilters=1&filtercombine=and&field1=site/string&compare1=63&value1=hythloth&field2=buildstarttime/date&compare2=83&value2=2015-12-01&field3=buildname/string&compare3=64&value3=OpenGL1&field4=buildname/string&compare4=64&value4=External the test passed on https://open.cdash.org/viewUpdate.php?buildid=4148832 (Dec 13th 2015) as well as lots of times before then. It has consistently failed since then. The changes listed for the failing build are here: https://open.cdash.org/viewUpdate.php?buildid=4148832 with authors of: KWSys Upstream David Gobbi Ben Boekle Utkarsh Bill Lorensen Brad King none of the changes particularly look like an issue to me but I have not looked closely. I suppose we could try doing a git bisect of that day to see if a particular change introduced the failure (or exposed a pre existing issue) or if there was a system change that introduced the issue. Ken On Fri, Feb 5, 2016 at 2:54 PM, Brad King wrote: > On 02/05/2016 01:11 PM, Ken Martin wrote: > > I would bet this is a driver issue aka the typical Linux driver > > sometimes shows black images issue. > > On hythloth it runs with a software mesa GL implementation. > It happens every time and is not spurious. > > > try running the test interactively and see if it works > > The test does not create a render window interactor and does not > respond to the -I command-line option :( > > -Brad > > -- 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: From ken.martin at kitware.com Fri Feb 5 16:17:50 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 5 Feb 2016 16:17:50 -0500 Subject: [vtk-developers] [EXTERNAL] Re: VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: I believe that is from the old OpenGL backend. - Ken On Fri, Feb 5, 2016 at 4:09 PM, Bill Lorensen wrote: > They look old to me. I am interested in the OpenGL2 rendwering backend. > > Perhaps an expert will comment. > > > On Fri, Feb 5, 2016 at 3:16 PM, Gerrick Bivins > wrote: > > So are these not valid anymore? > > > > http://www.vtk.org/Wiki/Shader_In_VTK > > > > http://www.vtk.org/Wiki/images/3/39/Vtk_shaders_tudelft_tut.pdf > > > > > > > > Or am I misunderstanding the question? > > > > Gerrick > > > > > > > > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf > Of > > Ken Martin > > Sent: Friday, February 05, 2016 12:21 PM > > To: Aashish Chaudhary > > Cc: VTK Developers; Steve Pieper > > Subject: [EXTERNAL] Re: [vtk-developers] VTK OpenGL2 Shaders > > > > > > > > Here is some info from an old email on customizing the polydatamapper > > shaders. The PointGaussianMapper also supports custom shaders and there > is > > an example of that in > > Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx > > > > Thanks > > > > Ken > > > > > > > > 2) CUSTOM SHADERS - Added support for customizing the default > > PolyDataMapper shaders. You can now modify or completely replace the > default > > VTK shadersusing methods such as > > > > > > > > AddShaderReplacement: replaces a strings in the current shader > > SetVertexShaderCode: replaces the default shader template with your own > > > > AddObserver(vtkCommand::UpdateShaderEvent,...) > > > > > > > > These methods (and similar others) give you a great degree on control of > the > > VTK PolyData shaders. There are examples/tests in > > Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. > > Through the UpdateShaderEvent you can modify the default VTK uniforms or > > your own uniforms as desired. There is currently not a general purpose > easy > > API for binding your own data arrays to attributes but we may add one at > > some point in the future. Currently VTK will send down the default > > attributes for you to use in your shader (position, normal, tcoords, > colors, > > etc) > > > > > > > > > > > > On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary > > wrote: > > > > Not to my knowledge. Although we talked about it at-least having an API > so > > that folks can replace the shader or ember new shader code to the > existing > > one. Also, having some common convention would be nice. > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper > wrote: > > > > Hi Bill - > > > > > > > > Great question - I'm looking forward to hear what folks have been doing > in > > this respect. > > > > > > > > For me, I have two classes I have been testing with Slicer - one that > > manages 3D textures and one that implements shaders [1,2]. We worked on > it > > at project week [3] and I'm liking how it works. > > > > > > > > -Steve > > > > > > > > [1] > > > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h > > > > > > > > [2] > > > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h > > > > > > > > [3] > > > http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL > > > > > > > > On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen > > wrote: > > > > Folks, > > > > Is there documentation on how to write glsl shaders for VTK? > > > > Bill > > -- > > Unpaid intern in BillsBasement at noware dot com > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > > > > > -- > > > > | Aashish Chaudhary > > | Technical Leader > > | Kitware Inc. > > > > | http://www.kitware.com/company/team/chaudhary.html > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > > > > > -- > > > > 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. > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- 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: From rebecca at xetta.io Fri Feb 5 16:28:33 2016 From: rebecca at xetta.io (Rebecca Wise) Date: Fri, 5 Feb 2016 13:28:33 -0800 Subject: [vtk-developers] vtk-developers Digest, Vol 142, Issue 10 In-Reply-To: References: Message-ID: <8192D394-EAB9-40EB-B452-2B5F056F239A@xetta.io> Unsubscribe > On Feb 5, 2016, at 1:17 PM, vtk-developers-request at vtk.org wrote: > > Send vtk-developers mailing list submissions to > vtk-developers at vtk.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://public.kitware.com/mailman/listinfo/vtk-developers > or, via email, send a message with subject or body 'help' to > vtk-developers-request at vtk.org > > You can reach the person managing the list at > vtk-developers-owner at vtk.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vtk-developers digest..." > > > Today's Topics: > > 1. CDash offine? (Ken Martin) > 2. Re: [EXTERNAL] Re: VTK OpenGL2 Shaders (Bill Lorensen) > 3. Re: TestImageDataLIC2D test failures (Ken Martin) > 4. Re: [EXTERNAL] Re: VTK OpenGL2 Shaders (Ken Martin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 5 Feb 2016 15:58:57 -0500 > From: Ken Martin > To: VTK Developers > Subject: [vtk-developers] CDash offine? > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Just hangs for me right now ... > > > -- > 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: > > ------------------------------ > > Message: 2 > Date: Fri, 5 Feb 2016 16:09:51 -0500 > From: Bill Lorensen > To: Gerrick Bivins > Cc: VTK Developers , Steve Pieper > > Subject: Re: [vtk-developers] [EXTERNAL] Re: VTK OpenGL2 Shaders > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > They look old to me. I am interested in the OpenGL2 rendwering backend. > > Perhaps an expert will comment. > > > On Fri, Feb 5, 2016 at 3:16 PM, Gerrick Bivins > wrote: >> So are these not valid anymore? >> >> http://www.vtk.org/Wiki/Shader_In_VTK >> >> http://www.vtk.org/Wiki/images/3/39/Vtk_shaders_tudelft_tut.pdf >> >> >> >> Or am I misunderstanding the question? >> >> Gerrick >> >> >> >> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of >> Ken Martin >> Sent: Friday, February 05, 2016 12:21 PM >> To: Aashish Chaudhary >> Cc: VTK Developers; Steve Pieper >> Subject: [EXTERNAL] Re: [vtk-developers] VTK OpenGL2 Shaders >> >> >> >> Here is some info from an old email on customizing the polydatamapper >> shaders. The PointGaussianMapper also supports custom shaders and there is >> an example of that in >> Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx >> >> Thanks >> >> Ken >> >> >> >> 2) CUSTOM SHADERS - Added support for customizing the default >> PolyDataMapper shaders. You can now modify or completely replace the default >> VTK shadersusing methods such as >> >> >> >> AddShaderReplacement: replaces a strings in the current shader >> SetVertexShaderCode: replaces the default shader template with your own >> >> AddObserver(vtkCommand::UpdateShaderEvent,...) >> >> >> >> These methods (and similar others) give you a great degree on control of the >> VTK PolyData shaders. There are examples/tests in >> Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. >> Through the UpdateShaderEvent you can modify the default VTK uniforms or >> your own uniforms as desired. There is currently not a general purpose easy >> API for binding your own data arrays to attributes but we may add one at >> some point in the future. Currently VTK will send down the default >> attributes for you to use in your shader (position, normal, tcoords, colors, >> etc) >> >> >> >> >> >> On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary >> wrote: >> >> Not to my knowledge. Although we talked about it at-least having an API so >> that folks can replace the shader or ember new shader code to the existing >> one. Also, having some common convention would be nice. >> >> >> >> Thanks, >> >> >> >> >> >> >> >> >> >> On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper wrote: >> >> Hi Bill - >> >> >> >> Great question - I'm looking forward to hear what folks have been doing in >> this respect. >> >> >> >> For me, I have two classes I have been testing with Slicer - one that >> manages 3D textures and one that implements shaders [1,2]. We worked on it >> at project week [3] and I'm liking how it works. >> >> >> >> -Steve >> >> >> >> [1] >> https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h >> >> >> >> [2] >> https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h >> >> >> >> [3] >> http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL >> >> >> >> On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen >> wrote: >> >> Folks, >> >> Is there documentation on how to write glsl shaders for VTK? >> >> Bill >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> -- >> >> | Aashish Chaudhary >> | Technical Leader >> | Kitware Inc. >> >> | http://www.kitware.com/company/team/chaudhary.html >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> -- >> >> 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. >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers > > > > -- > Unpaid intern in BillsBasement at noware dot com > > > ------------------------------ > > Message: 3 > Date: Fri, 5 Feb 2016 16:16:04 -0500 > From: Ken Martin > To: Brad King > Cc: VTK Developers , David Gobbi > > Subject: Re: [vtk-developers] TestImageDataLIC2D test failures > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > OK using > > https://open.cdash.org/index.php?project=VTK&filtercount=4&showfilters=1&filtercombine=and&field1=site/string&compare1=63&value1=hythloth&field2=buildstarttime/date&compare2=83&value2=2015-12-01&field3=buildname/string&compare3=64&value3=OpenGL1&field4=buildname/string&compare4=64&value4=External > > the test passed on > > https://open.cdash.org/viewUpdate.php?buildid=4148832 (Dec 13th 2015) as > well as lots of times before then. It has consistently failed since then. > The changes listed for the failing build are here: > > https://open.cdash.org/viewUpdate.php?buildid=4148832 with authors of: > > KWSys Upstream > David Gobbi > Ben Boekle > Utkarsh > Bill Lorensen > Brad King > > none of the changes particularly look like an issue to me but I have not > looked closely. > > I suppose we could try doing a git bisect of that day to see if a > particular change introduced the failure (or exposed a pre existing issue) > or if there was a system change that introduced the issue. > > Ken > > > > > >> On Fri, Feb 5, 2016 at 2:54 PM, Brad King wrote: >> >>> On 02/05/2016 01:11 PM, Ken Martin wrote: >>> I would bet this is a driver issue aka the typical Linux driver >>> sometimes shows black images issue. >> >> On hythloth it runs with a software mesa GL implementation. >> It happens every time and is not spurious. >> >>> try running the test interactively and see if it works >> >> The test does not create a render window interactor and does not >> respond to the -I command-line option :( >> >> -Brad > > > -- > 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: > > ------------------------------ > > Message: 4 > Date: Fri, 5 Feb 2016 16:17:50 -0500 > From: Ken Martin > To: Bill Lorensen > Cc: VTK Developers , Steve Pieper > > Subject: Re: [vtk-developers] [EXTERNAL] Re: VTK OpenGL2 Shaders > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I believe that is from the old OpenGL backend. - Ken > > On Fri, Feb 5, 2016 at 4:09 PM, Bill Lorensen > wrote: > >> They look old to me. I am interested in the OpenGL2 rendwering backend. >> >> Perhaps an expert will comment. >> >> >> On Fri, Feb 5, 2016 at 3:16 PM, Gerrick Bivins >> wrote: >>> So are these not valid anymore? >>> >>> http://www.vtk.org/Wiki/Shader_In_VTK >>> >>> http://www.vtk.org/Wiki/images/3/39/Vtk_shaders_tudelft_tut.pdf >>> >>> >>> >>> Or am I misunderstanding the question? >>> >>> Gerrick >>> >>> >>> >>> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf >> Of >>> Ken Martin >>> Sent: Friday, February 05, 2016 12:21 PM >>> To: Aashish Chaudhary >>> Cc: VTK Developers; Steve Pieper >>> Subject: [EXTERNAL] Re: [vtk-developers] VTK OpenGL2 Shaders >>> >>> >>> >>> Here is some info from an old email on customizing the polydatamapper >>> shaders. The PointGaussianMapper also supports custom shaders and there >> is >>> an example of that in >>> Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx >>> >>> Thanks >>> >>> Ken >>> >>> >>> >>> 2) CUSTOM SHADERS - Added support for customizing the default >>> PolyDataMapper shaders. You can now modify or completely replace the >> default >>> VTK shadersusing methods such as >>> >>> >>> >>> AddShaderReplacement: replaces a strings in the current shader >>> SetVertexShaderCode: replaces the default shader template with your own >>> >>> AddObserver(vtkCommand::UpdateShaderEvent,...) >>> >>> >>> >>> These methods (and similar others) give you a great degree on control of >> the >>> VTK PolyData shaders. There are examples/tests in >>> Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. >>> Through the UpdateShaderEvent you can modify the default VTK uniforms or >>> your own uniforms as desired. There is currently not a general purpose >> easy >>> API for binding your own data arrays to attributes but we may add one at >>> some point in the future. Currently VTK will send down the default >>> attributes for you to use in your shader (position, normal, tcoords, >> colors, >>> etc) >>> >>> >>> >>> >>> >>> On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary >>> wrote: >>> >>> Not to my knowledge. Although we talked about it at-least having an API >> so >>> that folks can replace the shader or ember new shader code to the >> existing >>> one. Also, having some common convention would be nice. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper >>> wrote: >>> >>> Hi Bill - >>> >>> >>> >>> Great question - I'm looking forward to hear what folks have been doing >> in >>> this respect. >>> >>> >>> >>> For me, I have two classes I have been testing with Slicer - one that >>> manages 3D textures and one that implements shaders [1,2]. We worked on >> it >>> at project week [3] and I'm liking how it works. >>> >>> >>> >>> -Steve >>> >>> >>> >>> [1] >> https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h >>> >>> >>> >>> [2] >> https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h >>> >>> >>> >>> [3] >> http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL >>> >>> >>> >>> On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen >>> wrote: >>> >>> Folks, >>> >>> Is there documentation on how to write glsl shaders for VTK? >>> >>> Bill >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> >>> >>> -- >>> >>> | Aashish Chaudhary >>> | Technical Leader >>> | Kitware Inc. >>> >>> | http://www.kitware.com/company/team/chaudhary.html >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> >>> >>> -- >>> >>> 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. >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > -- > 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: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > ------------------------------ > > End of vtk-developers Digest, Vol 142, Issue 10 > *********************************************** From ldelgass at gmail.com Sat Feb 6 14:14:05 2016 From: ldelgass at gmail.com (Leif Delgass) Date: Sat, 6 Feb 2016 14:14:05 -0500 Subject: [vtk-developers] VTK 7.0 segfault in vtkContourFilter with UseScalarTree Message-ID: In VTK 7.0, I am getting a segfault in vtkContourFilter when setting UseScalarTreeOn(), but not supplying a ScalarTree pointer. This worked in VTK 6.3, since the filter would create a default vtkSimpleScalarTree if a ScalarTree wasn't supplied. However, it seems that in the following commit, the code was changed so that now a default ScalarTree (a vtkSpanSpace) is only supplied if the input is an unstructured grid. https://gitlab.kitware.com/vtk/vtk/commit/8ae05d907d5b047be79574cf8cc0c3c9a816e51c#4ec6be05bae9bbde34d3583e844cc26dfc4e91ea_574_589 Restoring the deleted block from vtkContourFilter.cxx:574:589 in the above commit fixes the problem for me. I haven't made a test/repro case, but this should be fairly simple to reproduce, just: 1. Attach a data set that isn't an unstructured grid (e.g. a vtkStructuredGrid), to a vtkContourFilter. 2. Generate a couple of isovalues in the filter. 3. Set UseScalarTreeOn() in the filter and update/run the filter. -Leif -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Sat Feb 6 19:33:08 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Sat, 6 Feb 2016 19:33:08 -0500 Subject: [vtk-developers] VTK 7.0 segfault in vtkContourFilter with UseScalarTree In-Reply-To: References: Message-ID: Thanks Leif, I suspect that I am the culprit. I'm traveling on and off but I'll make a fix as soon as I can. Best, W On Sat, Feb 6, 2016 at 2:14 PM, Leif Delgass wrote: > In VTK 7.0, I am getting a segfault in vtkContourFilter when setting > UseScalarTreeOn(), but not supplying a ScalarTree pointer. This worked in > VTK 6.3, since the filter would create a default vtkSimpleScalarTree if a > ScalarTree wasn't supplied. However, it seems that in the following > commit, the code was changed so that now a default ScalarTree (a > vtkSpanSpace) is only supplied if the input is an unstructured grid. > > > https://gitlab.kitware.com/vtk/vtk/commit/8ae05d907d5b047be79574cf8cc0c3c9a816e51c#4ec6be05bae9bbde34d3583e844cc26dfc4e91ea_574_589 > > Restoring the deleted block from vtkContourFilter.cxx:574:589 in the above > commit fixes the problem for me. > > I haven't made a test/repro case, but this should be fairly simple to > reproduce, just: > > 1. Attach a data set that isn't an unstructured grid (e.g. a > vtkStructuredGrid), to a vtkContourFilter. > 2. Generate a couple of isovalues in the filter. > 3. Set UseScalarTreeOn() in the filter and update/run the filter. > > -Leif > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Mon Feb 8 09:07:18 2016 From: xabivtk at gmail.com (Xabi Riobe) Date: Mon, 8 Feb 2016 15:07:18 +0100 Subject: [vtk-developers] Bug in vtkCamera::Elevation In-Reply-To: References: Message-ID: I pushed a fix : https://gitlab.kitware.com/vtk/vtk/merge_requests/1194 2016-02-05 13:59 GMT+01:00 Xabi Riobe : > Ok now it looks clear to me, thanks for the explanation Will. > > So i'll just fix the 90? issue. > > > 2016-02-05 12:54 GMT+01:00 Will Schroeder : > >> This is a known problem since 1993 when VTK was first written. It is >> presumed to be an application-level issue. That is, if you are flying over >> terrain, you do not want to be messing with the view up, otherwise the >> elevation, pitch, etc. lose their meaning. >> >> As evidence of this check out >> VTK/Interaction/Style/vtkInteractionStyleTerrain which has explicit >> commentary about dealing with the north pole singularity. Then look at >> vtkInteractorStyleTrackballCamera, vtkInteractorStyleJoystickCamera, etc. >> They all have explicit calls to camera->OrthogonalizeViewUp() which is >> added to address the view up singularity. >> >> Best, >> W >> >> On Thu, Feb 4, 2016 at 8:54 AM, Xabi Riobe wrote: >> >>> Hi, >>> >>> There is an issue in vtkCamera::Elevation if the angle is 90. >>> >>> It is 100% reproductible with VS2013 if compiled in 64bits, otherwise >>> the rounding epsilon makes it work by chance. >>> >>> I'm willing to fix it in GitLab but first i would like your opinion >>> about the best way to do it. >>> >>> with a simple example of a plane in a renderer, and a call to >>> renderer->GetActiveCamera()->Elevation(90) >>> >>> What happens in the call stack of vtkCamera::Elevation : >>> vtkCamera::SetPosition() >>> vtkCamera::ComputeViewTransform >>> vtkPerspectiveTransform::SetupCamera >>> >>> vtkMath::Cross(viewUp,viewPlaneNormal,viewSideways); >>> >>> where viewUp and viewPlaneNormal are both (0,1,0) so viewSideways is >>> (0,0,0) leading to bad camera parameters. >>> Here comes the VS13+64bits configuration case, when with others, >>> viewSideways is luckily different than 0 >>> >>> What do you think of applying the rotation to the viewUp vector in >>> vtkCamera::Elevation before the call to SetPosition? >>> Should we put a warning in vtkPerspectiveTransform::SetupCamera >>> when vtkMath::Normalize returns 0? >>> >>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Feb 8 11:26:44 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 8 Feb 2016 11:26:44 -0500 Subject: [vtk-developers] TestImageDataLIC2D test failures In-Reply-To: References: <94447f2e4aacd8749aeae25fe827176a@mail.gmail.com> <56B4C97F.8040409@kitware.com> <56B4FE00.5010204@kitware.com> Message-ID: I'm pretty sure it is a side effect of Utkarsh's change. I'll put in a fix. - Ken On Fri, Feb 5, 2016 at 4:16 PM, Ken Martin wrote: > OK using > > > https://open.cdash.org/index.php?project=VTK&filtercount=4&showfilters=1&filtercombine=and&field1=site/string&compare1=63&value1=hythloth&field2=buildstarttime/date&compare2=83&value2=2015-12-01&field3=buildname/string&compare3=64&value3=OpenGL1&field4=buildname/string&compare4=64&value4=External > > the test passed on > > https://open.cdash.org/viewUpdate.php?buildid=4148832 (Dec 13th 2015) as > well as lots of times before then. It has consistently failed since then. > The changes listed for the failing build are here: > > https://open.cdash.org/viewUpdate.php?buildid=4148832 with authors of: > > KWSys Upstream > David Gobbi > Ben Boekle > Utkarsh > Bill Lorensen > Brad King > > none of the changes particularly look like an issue to me but I have not > looked closely. > > I suppose we could try doing a git bisect of that day to see if a > particular change introduced the failure (or exposed a pre existing issue) > or if there was a system change that introduced the issue. > > Ken > > > > > > On Fri, Feb 5, 2016 at 2:54 PM, Brad King wrote: > >> On 02/05/2016 01:11 PM, Ken Martin wrote: >> > I would bet this is a driver issue aka the typical Linux driver >> > sometimes shows black images issue. >> >> On hythloth it runs with a software mesa GL implementation. >> It happens every time and is not spurious. >> >> > try running the test interactively and see if it works >> >> The test does not create a render window interactor and does not >> respond to the -I command-line option :( >> >> -Brad >> >> > > > -- > 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: From david.gobbi at gmail.com Mon Feb 8 15:39:09 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 8 Feb 2016 13:39:09 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? Message-ID: Hello All, Is there any way for VTK application code to know what SMP backend VTK was configured with? Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujin.philip at kitware.com Mon Feb 8 17:37:58 2016 From: sujin.philip at kitware.com (Sujin Philip) Date: Mon, 8 Feb 2016 17:37:58 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Hi David, There is no official API to find out what the back-end is. I don't think there is a simple hack either. The back-end is supposed to be transparent to the user with the only visible difference being the performance. Why do you want to know? Thanks Sujin On Mon, Feb 8, 2016 at 3:39 PM, David Gobbi wrote: > Hello All, > > Is there any way for VTK application code to know what SMP backend VTK was > configured with? > > Cheers, > - David > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Feb 8 17:50:52 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 8 Feb 2016 15:50:52 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: On Mon, Feb 8, 2016 at 3:37 PM, Sujin Philip wrote: > Hi David, > > There is no official API to find out what the back-end is. I don't think > there is a simple hack either. The back-end is supposed to be transparent > to the user with the only visible difference being the performance. Why do > you want to know? > It's for the new vtkSMPTools implementation of vtkThreadedImageAlgorithm. It would be nice if it could automatically default to using vtkSMPTools if a suitable backend is present, or use vtkMultiThreader if a vtkSMPTools backend is "Sequential" or "Simple". Also, if there is no way to know what the backend is, then isn't it "opaque" rather than "transparent"? :) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmsurti at gmail.com Tue Feb 9 07:23:05 2016 From: dmsurti at gmail.com (Deepak Surti) Date: Tue, 9 Feb 2016 17:53:05 +0530 Subject: [vtk-developers] VTKOpenGLExtensionManager in VTK 7.0? Message-ID: Hi, vtkOpenGLExtensionManager is missing in VTK 7.0 with the default VTK_RENDERING_BACKEND OpenGL2. With the old OpenGL Backend up to VTK 6.3, I did something like this to get hold of the GL Driver, Renderer version etc. ``` ren = vtk.vtkRenderer() renWin = vtk.vtkRenderWindow() renWin.AddRenderer(ren) # Now check the OpenGL metadata using the extension manager em = vtk.vtkOpenGLExtensionManager() em.SetRenderWindow(renWin) renWin.Render() em.Update() vtk_ver = vtk.vtkVersion().GetVTKVersion() gl_driver = em.GetDriverGLVersion() gl_renderer = em.GetDriverGLRenderer() ``` What is the replacement for vtkOpenGLExtensionManager or with OpenGL2 backend, how do I get the above information? Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujin.philip at kitware.com Tue Feb 9 09:13:48 2016 From: sujin.philip at kitware.com (Sujin Philip) Date: Tue, 9 Feb 2016 09:13:48 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Hi David, I get what you are saying. Thanks for the correction :). Why would you want to continue using vtkMultiThreader when Sequential or Simple is used? In fact, now that there is an openmp backend, we should be removing simple. It was only there to ease debugging since tbb had very complex back-traces. Openmp back-traces are much more readable. Do you want the algorithm to be multithreaded even when Sequential is used? I think it should be quite easy to add a compile time "#define" based on VTK_SMP_IMPLEMENTATION_TYPE. Thanks Sujin On Mon, Feb 8, 2016 at 5:50 PM, David Gobbi wrote: > On Mon, Feb 8, 2016 at 3:37 PM, Sujin Philip > wrote: > >> Hi David, >> >> There is no official API to find out what the back-end is. I don't think >> there is a simple hack either. The back-end is supposed to be transparent >> to the user with the only visible difference being the performance. Why do >> you want to know? >> > > It's for the new vtkSMPTools implementation of vtkThreadedImageAlgorithm. > It would be nice if it could automatically default to using vtkSMPTools if > a suitable backend is present, or use vtkMultiThreader if a vtkSMPTools > backend is "Sequential" or "Simple". > > Also, if there is no way to know what the backend is, then isn't it > "opaque" rather than "transparent"? :) > > - David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Feb 9 10:15:31 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 9 Feb 2016 08:15:31 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Hi Sujin, What I want is a clear path for the transition from the current situation (all image filters implemented with vtkMultiThreader) to the eventual destination (all image filters implemented solely with vtkSMPTools). Clearly, we're not at the "destination" yet. The default vtkSMPTools backend is Sequential, which is an unsuitable replacement for vtkMultiThreader for obvious reasons. You say we should remove Simple in favour of OpenMP, but you said the same thing many months ago :) When is that actually going to happen? The VTK imaging pipeline has been multithreaded for nearly as long as VTK has existed, so I'm not going to move forward into a situation where a VTK build with default cmake config causes these filters to run sequential. That would be a nasty surprise to the users who depend on these filters. That's why, at least for the transition period, I want these filters to use the old vtkMultiThreader implementation if the "Sequential" backend is selected. I don't want any nasty surprises for the users of these filters, who expect them to continue to be multi-threaded just as they have been for the past 15 years. - David On Tue, Feb 9, 2016 at 7:13 AM, Sujin Philip wrote: > Hi David, > > I get what you are saying. Thanks for the correction :). > > Why would you want to continue using vtkMultiThreader when Sequential or > Simple is used? In fact, now that there is an openmp backend, we should be > removing simple. It was only there to ease debugging since tbb had very > complex back-traces. Openmp back-traces are much more readable. Do you want > the algorithm to be multithreaded even when Sequential is used? > > I think it should be quite easy to add a compile time "#define" based on > VTK_SMP_IMPLEMENTATION_TYPE. > > Thanks > Sujin > > > On Mon, Feb 8, 2016 at 5:50 PM, David Gobbi wrote: > >> On Mon, Feb 8, 2016 at 3:37 PM, Sujin Philip >> wrote: >> >>> Hi David, >>> >>> There is no official API to find out what the back-end is. I don't think >>> there is a simple hack either. The back-end is supposed to be transparent >>> to the user with the only visible difference being the performance. Why do >>> you want to know? >>> >> >> It's for the new vtkSMPTools implementation of >> vtkThreadedImageAlgorithm. It would be nice if it could automatically >> default to using vtkSMPTools if a suitable backend is present, or use >> vtkMultiThreader if a vtkSMPTools backend is "Sequential" or "Simple". >> >> Also, if there is no way to know what the backend is, then isn't it >> "opaque" rather than "transparent"? :) >> >> - David >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Feb 9 10:28:47 2016 From: sean at rogue-research.com (Sean McBride) Date: Tue, 9 Feb 2016 10:28:47 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: <20160209152847.2140519877@mail.rogue-research.com> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >Why would you want to continue using vtkMultiThreader when Sequential or >Simple is used? In fact, now that there is an openmp backend, we should be >removing simple. It was only there to ease debugging since tbb had very >complex back-traces. Openmp back-traces are much more readable. Do you want >the algorithm to be multithreaded even when Sequential is used? I don't know the APIs you're discussing, so this comment is coming mostly from ignorance, but: are you talking about requiring OpenMP to build VTK? Clang has only very recently added OpenMP support, and IIRC it's not complete. Also, last I checked, Apple's fork of clang doesn't support it at all. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sujin.philip at kitware.com Tue Feb 9 10:46:44 2016 From: sujin.philip at kitware.com (Sujin Philip) Date: Tue, 9 Feb 2016 10:46:44 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: <20160209152847.2140519877@mail.rogue-research.com> References: <20160209152847.2140519877@mail.rogue-research.com> Message-ID: Hi Sean, vtkSMPTools is a framework for implementing multi-threaded algorithms in VTK. It support several backends. The main ones are TBB and OpenMP. There are Kaapi and Simple backends which are no longer supported and will be removed soon. Finally, the default backend is Sequential which is just a single threaded implementation of the framework. After removal of the Kaapi and Simple backend, if you need multithreading support on Clang you would have to use TBB. The Sequential backend will be supported on all platforms. David, I have talked with Berk about this and I will soon make a change to have a compile time macro to check for SMP backend type. I will also finally remove Kaapi and Simple backend as part of this change. Thanks Sujin On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride wrote: > On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: > > >Why would you want to continue using vtkMultiThreader when Sequential or > >Simple is used? In fact, now that there is an openmp backend, we should be > >removing simple. It was only there to ease debugging since tbb had very > >complex back-traces. Openmp back-traces are much more readable. Do you > want > >the algorithm to be multithreaded even when Sequential is used? > > I don't know the APIs you're discussing, so this comment is coming mostly > from ignorance, but: are you talking about requiring OpenMP to build VTK? > Clang has only very recently added OpenMP support, and IIRC it's not > complete. Also, last I checked, Apple's fork of clang doesn't support it > at all. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Feb 9 10:56:31 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 9 Feb 2016 08:56:31 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> Message-ID: Hi Sujin, That sounds good. Even if the choice of backend is transparent as far as using vtkSMPTools is concerned, it's very nice to be able to report which backend was configured. - David On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip wrote: > Hi Sean, > > vtkSMPTools is a framework for implementing multi-threaded algorithms in > VTK. It support several backends. The main ones are TBB and OpenMP. There > are Kaapi and Simple backends which are no longer supported and will be > removed soon. Finally, the default backend is Sequential which is just a > single threaded implementation of the framework. After removal of the Kaapi > and Simple backend, if you need multithreading support on Clang you would > have to use TBB. The Sequential backend will be supported on all platforms. > > David, > > I have talked with Berk about this and I will soon make a change to have a > compile time macro to check for SMP backend type. I will also finally > remove Kaapi and Simple backend as part of this change. > > Thanks > Sujin > > > On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: > >> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >> >> >Why would you want to continue using vtkMultiThreader when Sequential or >> >Simple is used? In fact, now that there is an openmp backend, we should >> be >> >removing simple. It was only there to ease debugging since tbb had very >> >complex back-traces. Openmp back-traces are much more readable. Do you >> want >> >the algorithm to be multithreaded even when Sequential is used? >> >> I don't know the APIs you're discussing, so this comment is coming mostly >> from ignorance, but: are you talking about requiring OpenMP to build VTK? >> Clang has only very recently added OpenMP support, and IIRC it's not >> complete. Also, last I checked, Apple's fork of clang doesn't support it >> at all. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Feb 9 11:02:49 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 9 Feb 2016 11:02:49 -0500 Subject: [vtk-developers] google summer of code 2016 - project ideas and mentor volunteers Message-ID: Hey gang, It is GSoC application time again and we need project ideas and mentors for those projects. See http://www.vtk.org/Wiki/VTK/GSoC_2016 for the idea list and do feel free to edit it directly if you like. The project ideas list is a key part of our application to have VTK taken up and for students to be funded under GSoC. Since most students base their proposals directly on ideas in it, it is also a big part of what we can expect to get out of the summer. So, if you've got ideas for things that you would like to see college/graduate students do with or to VTK over the summer, please add them to the list. Ideally the ideas should have some sort of wow factor (like Andy Bauer's proposal last year for motion amplification in VTK) in order to entice students to apply to VTK over all the other organizations. Each project needs at least one mentor. Advisors should know VTK well and be able to commit to spending something like two to six hours per week advising a remote student. Keep in mind that the coaching and talent development aspect is perhaps the most important goal of GSoC, so mentors should be able to engage their students throughout and attempt to groom them to become regular contributors. thanks David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Feb 9 11:24:18 2016 From: sean at rogue-research.com (Sean McBride) Date: Tue, 9 Feb 2016 11:24:18 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> Message-ID: <20160209162418.1203776060@mail.rogue-research.com> On Tue, 9 Feb 2016 10:46:44 -0500, Sujin Philip said: >vtkSMPTools is a framework for implementing multi-threaded algorithms in >VTK. It support several backends. The main ones are TBB and OpenMP. There >are Kaapi and Simple backends which are no longer supported and will be >removed soon. And this stuff is in Common/Core/SMP? The "Simple" one seems to be based on vtkMultiThreader and thus pthreads (on unix), correct? I've only done a quick grep, but I don't see anything in there about the "Simple" one being deprecated. >Finally, the default backend is Sequential which is just a >single threaded implementation of the framework. After removal of the Kaapi >and Simple backend, if you need multithreading support on Clang you would >have to use TBB. The Sequential backend will be supported on all platforms. Is TBB included in VTK? It doesn't seem to to be. It seems to me that removing the Simple backend would mean that you'd remove a whole bunch of multithreading when building a default build with the default compiler on OS X. That seems horrible. But hopefully I'm misunderstanding things here... Have you thought about using std::thread, std::mutex and the like? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From will.schroeder at kitware.com Tue Feb 9 11:27:00 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 9 Feb 2016 11:27:00 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: <20160209162418.1203776060@mail.rogue-research.com> References: <20160209152847.2140519877@mail.rogue-research.com> <20160209162418.1203776060@mail.rogue-research.com> Message-ID: Sean if you have not done so already you may want to also read the short but sweet vtkSMPTools pdf that Berk wrote. It's a good introduction. W On Tue, Feb 9, 2016 at 11:24 AM, Sean McBride wrote: > On Tue, 9 Feb 2016 10:46:44 -0500, Sujin Philip said: > > >vtkSMPTools is a framework for implementing multi-threaded algorithms in > >VTK. It support several backends. The main ones are TBB and OpenMP. There > >are Kaapi and Simple backends which are no longer supported and will be > >removed soon. > > And this stuff is in Common/Core/SMP? The "Simple" one seems to be based > on vtkMultiThreader and thus pthreads (on unix), correct? > > I've only done a quick grep, but I don't see anything in there about the > "Simple" one being deprecated. > > >Finally, the default backend is Sequential which is just a > >single threaded implementation of the framework. After removal of the > Kaapi > >and Simple backend, if you need multithreading support on Clang you would > >have to use TBB. The Sequential backend will be supported on all > platforms. > > Is TBB included in VTK? It doesn't seem to to be. It seems to me that > removing the Simple backend would mean that you'd remove a whole bunch of > multithreading when building a default build with the default compiler on > OS X. That seems horrible. But hopefully I'm misunderstanding things > here... > > Have you thought about using std::thread, std::mutex and the like? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Feb 9 11:33:40 2016 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 9 Feb 2016 11:33:40 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> Message-ID: Echoing David's earlier comments it would seem like we would want a nice path to convert existing multithreaded algorithms to use vtkSMPTools knowing that vtkSMPTools would not slow down the existing algorithm. Doing #if VTK_SMP_BACKEND == SLOW use vtkMultithreader #else use vtkSMPTools #endif sounds odd. I did not read the pdf so if that is covered in there apologies. On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi wrote: > Hi Sujin, > > That sounds good. Even if the choice of backend is transparent as far as > using vtkSMPTools is concerned, it's very nice to be able to report which > backend was configured. > > - David > > On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: > >> Hi Sean, >> >> vtkSMPTools is a framework for implementing multi-threaded algorithms in >> VTK. It support several backends. The main ones are TBB and OpenMP. There >> are Kaapi and Simple backends which are no longer supported and will be >> removed soon. Finally, the default backend is Sequential which is just a >> single threaded implementation of the framework. After removal of the Kaapi >> and Simple backend, if you need multithreading support on Clang you would >> have to use TBB. The Sequential backend will be supported on all platforms. >> >> David, >> >> I have talked with Berk about this and I will soon make a change to have >> a compile time macro to check for SMP backend type. I will also finally >> remove Kaapi and Simple backend as part of this change. >> >> Thanks >> Sujin >> >> >> On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride >> wrote: >> >>> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >>> >>> >Why would you want to continue using vtkMultiThreader when Sequential or >>> >Simple is used? In fact, now that there is an openmp backend, we should >>> be >>> >removing simple. It was only there to ease debugging since tbb had very >>> >complex back-traces. Openmp back-traces are much more readable. Do you >>> want >>> >the algorithm to be multithreaded even when Sequential is used? >>> >>> I don't know the APIs you're discussing, so this comment is coming >>> mostly from ignorance, but: are you talking about requiring OpenMP to build >>> VTK? Clang has only very recently added OpenMP support, and IIRC it's not >>> complete. Also, last I checked, Apple's fork of clang doesn't support it >>> at all. >>> >>> Cheers, >>> >>> -- >>> ____________________________________________________________ >>> Sean McBride, B. Eng sean at rogue-research.com >>> Rogue Research www.rogue-research.com >>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>> >>> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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: From berk.geveci at kitware.com Tue Feb 9 14:55:37 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 9 Feb 2016 14:55:37 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> Message-ID: A few comments: * I support the path David wants to take. We flushed this out over several months in collaboration with a Google Summer of Code student. It is the best transition strategy given that we have several moving components (see below). * The Simple backend of vtkSMPTools is only there for debugging. Helgrind produces lots of false positives when using TBB so I developed the Simple backend for use with Helgrind. It is not a production backend and pretty much sucks. Now that we haven an OpenMP backend that can be used with Helgrind, Simple must die. I don't see a reason to deprecate it first since it is there only for debugging. This is clearly documented in the PDF will pointed to. * For compilers that do not support OpenMP 3.1, one can (and should) use TBB. TBB is the better backend anyway so I recommend it over OpenMP. * We will not include TBB in VTK. It is an external dependency similarly to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if they want any thread-level parallelism out of VTK. We need to discuss what "in the future" means. * Posix threads, C++11 threads etc. are not the way to go. They are way too low level and require management of thread pools and such to get good scalability. Things that OpenMP and TBB already to well. In general, for the kind of parallel computing we want in VTK, the best tools are high level ones such as parallel for loops etc. Furthermore, OpenMP will be important where we want to get SIMD (vector) parallelism. Auto-vectorization is very imperfect. And there are no C++ primitives that help with SIMD in C++11. * At one point, we will have to get rid of vtkMultiThreader (at least of its use in algorithms, it may still be useful for GUI threads and whatnot). Hopefully, by then OpenMP 3.1 or above will be universally supported so we can make it the default backend. If not though, we'll have to require that people use TBB. Best, -berk On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin wrote: > Echoing David's earlier comments it would seem like we would want a nice > path to convert existing multithreaded algorithms to use vtkSMPTools > knowing that vtkSMPTools would not slow down the existing algorithm. Doing > > #if VTK_SMP_BACKEND == SLOW > use vtkMultithreader > #else > use vtkSMPTools > #endif > > sounds odd. I did not read the pdf so if that is covered in there > apologies. > > > > > On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: > >> Hi Sujin, >> >> That sounds good. Even if the choice of backend is transparent as far as >> using vtkSMPTools is concerned, it's very nice to be able to report which >> backend was configured. >> >> - David >> >> On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip >> wrote: >> >>> Hi Sean, >>> >>> vtkSMPTools is a framework for implementing multi-threaded algorithms in >>> VTK. It support several backends. The main ones are TBB and OpenMP. There >>> are Kaapi and Simple backends which are no longer supported and will be >>> removed soon. Finally, the default backend is Sequential which is just a >>> single threaded implementation of the framework. After removal of the Kaapi >>> and Simple backend, if you need multithreading support on Clang you would >>> have to use TBB. The Sequential backend will be supported on all platforms. >>> >>> David, >>> >>> I have talked with Berk about this and I will soon make a change to have >>> a compile time macro to check for SMP backend type. I will also finally >>> remove Kaapi and Simple backend as part of this change. >>> >>> Thanks >>> Sujin >>> >>> >>> On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride >>> wrote: >>> >>>> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >>>> >>>> >Why would you want to continue using vtkMultiThreader when Sequential >>>> or >>>> >Simple is used? In fact, now that there is an openmp backend, we >>>> should be >>>> >removing simple. It was only there to ease debugging since tbb had very >>>> >complex back-traces. Openmp back-traces are much more readable. Do you >>>> want >>>> >the algorithm to be multithreaded even when Sequential is used? >>>> >>>> I don't know the APIs you're discussing, so this comment is coming >>>> mostly from ignorance, but: are you talking about requiring OpenMP to build >>>> VTK? Clang has only very recently added OpenMP support, and IIRC it's not >>>> complete. Also, last I checked, Apple's fork of clang doesn't support it >>>> at all. >>>> >>>> Cheers, >>>> >>>> -- >>>> ____________________________________________________________ >>>> Sean McBride, B. Eng sean at rogue-research.com >>>> Rogue Research www.rogue-research.com >>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>> >>>> >>>> >>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > 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. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Tue Feb 9 15:11:54 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 9 Feb 2016 15:11:54 -0500 Subject: [vtk-developers] Test failures on dash3 Message-ID: Hi all, The test vtkRenderingOpenGLCxx-TestWin32OpenGLRenderWindow has been failing on dash3 for several weeks now. It seems to be leaking some VTK objects [1]. Can someone take a look at this? Thanks, Shawn [1]: https://open.cdash.org/testDetails.php?test=413527187&build=4228894 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Tue Feb 9 17:56:13 2016 From: lasso at queensu.ca (Andras Lasso) Date: Tue, 9 Feb 2016 22:56:13 +0000 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? Message-ID: > we'll have to require that people use TBB. Are you talking about Intel TBB ? single license starting from $700? Or there are some free replacements? For most of our projects current performance of VTK is already good enough and it is very important to not have any licensing cost or restrictions. So, I would prefer free vtkMultiThreader over expensive Intel TBB, regardless of speed improvements. Andras From: Berk Geveci Sent: February 9, 2016 14:56 To: Ken Martin Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? A few comments: * I support the path David wants to take. We flushed this out over several months in collaboration with a Google Summer of Code student. It is the best transition strategy given that we have several moving components (see below). * The Simple backend of vtkSMPTools is only there for debugging. Helgrind produces lots of false positives when using TBB so I developed the Simple backend for use with Helgrind. It is not a production backend and pretty much sucks. Now that we haven an OpenMP backend that can be used with Helgrind, Simple must die. I don't see a reason to deprecate it first since it is there only for debugging. This is clearly documented in the PDF will pointed to. * For compilers that do not support OpenMP 3.1, one can (and should) use TBB. TBB is the better backend anyway so I recommend it over OpenMP. * We will not include TBB in VTK. It is an external dependency similarly to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if they want any thread-level parallelism out of VTK. We need to discuss what "in the future" means. * Posix threads, C++11 threads etc. are not the way to go. They are way too low level and require management of thread pools and such to get good scalability. Things that OpenMP and TBB already to well. In general, for the kind of parallel computing we want in VTK, the best tools are high level ones such as parallel for loops etc. Furthermore, OpenMP will be important where we want to get SIMD (vector) parallelism. Auto-vectorization is very imperfect. And there are no C++ primitives that help with SIMD in C++11. * At one point, we will have to get rid of vtkMultiThreader (at least of its use in algorithms, it may still be useful for GUI threads and whatnot). Hopefully, by then OpenMP 3.1 or above will be universally supported so we can make it the default backend. If not though, we'll have to require that people use TBB. Best, -berk On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin > wrote: Echoing David's earlier comments it would seem like we would want a nice path to convert existing multithreaded algorithms to use vtkSMPTools knowing that vtkSMPTools would not slow down the existing algorithm. Doing #if VTK_SMP_BACKEND == SLOW use vtkMultithreader #else use vtkSMPTools #endif sounds odd. I did not read the pdf so if that is covered in there apologies. On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: Hi Sujin, That sounds good. Even if the choice of backend is transparent as far as using vtkSMPTools is concerned, it's very nice to be able to report which backend was configured. - David On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: Hi Sean, vtkSMPTools is a framework for implementing multi-threaded algorithms in VTK. It support several backends. The main ones are TBB and OpenMP. There are Kaapi and Simple backends which are no longer supported and will be removed soon. Finally, the default backend is Sequential which is just a single threaded implementation of the framework. After removal of the Kaapi and Simple backend, if you need multithreading support on Clang you would have to use TBB. The Sequential backend will be supported on all platforms. David, I have talked with Berk about this and I will soon make a change to have a compile time macro to check for SMP backend type. I will also finally remove Kaapi and Simple backend as part of this change. Thanks Sujin On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >Why would you want to continue using vtkMultiThreader when Sequential or >Simple is used? In fact, now that there is an openmp backend, we should be >removing simple. It was only there to ease debugging since tbb had very >complex back-traces. Openmp back-traces are much more readable. Do you want >the algorithm to be multithreaded even when Sequential is used? I don't know the APIs you're discussing, so this comment is coming mostly from ignorance, but: are you talking about requiring OpenMP to build VTK? Clang has only very recently added OpenMP support, and IIRC it's not complete. Also, last I checked, Apple's fork of clang doesn't support it at all. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Tue Feb 9 18:31:38 2016 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Tue, 9 Feb 2016 23:31:38 +0000 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? Message-ID: $700? TBB is open-source, GPLv2 with runtime exception: https://www.threadingbuildingblocks.org/licensing -Ken From: vtk-developers > on behalf of Andras Lasso > Date: Tuesday, February 9, 2016 at 3:56 PM To: "Geveci, Berk (External Contact)" >, Ken Martin > Cc: VTK Developers >, David Gobbi > Subject: [EXTERNAL] Re: [vtk-developers] Checking SMP backend at runtime/compiletime? >we'll have to require that people use TBB. Are you talking about Intel TBB ? single license starting from $700? Or there are some free replacements? For most of our projects current performance of VTK is already good enough and it is very important to not have any licensing cost or restrictions. So, I would prefer free vtkMultiThreader over expensive Intel TBB, regardless of speed improvements. Andras From: Berk Geveci Sent: February 9, 2016 14:56 To: Ken Martin Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? A few comments: * I support the path David wants to take. We flushed this out over several months in collaboration with a Google Summer of Code student. It is the best transition strategy given that we have several moving components (see below). * The Simple backend of vtkSMPTools is only there for debugging. Helgrind produces lots of false positives when using TBB so I developed the Simple backend for use with Helgrind. It is not a production backend and pretty much sucks. Now that we haven an OpenMP backend that can be used with Helgrind, Simple must die. I don't see a reason to deprecate it first since it is there only for debugging. This is clearly documented in the PDF will pointed to. * For compilers that do not support OpenMP 3.1, one can (and should) use TBB. TBB is the better backend anyway so I recommend it over OpenMP. * We will not include TBB in VTK. It is an external dependency similarly to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if they want any thread-level parallelism out of VTK. We need to discuss what "in the future" means. * Posix threads, C++11 threads etc. are not the way to go. They are way too low level and require management of thread pools and such to get good scalability. Things that OpenMP and TBB already to well. In general, for the kind of parallel computing we want in VTK, the best tools are high level ones such as parallel for loops etc. Furthermore, OpenMP will be important where we want to get SIMD (vector) parallelism. Auto-vectorization is very imperfect. And there are no C++ primitives that help with SIMD in C++11. * At one point, we will have to get rid of vtkMultiThreader (at least of its use in algorithms, it may still be useful for GUI threads and whatnot). Hopefully, by then OpenMP 3.1 or above will be universally supported so we can make it the default backend. If not though, we'll have to require that people use TBB. Best, -berk On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin > wrote: Echoing David's earlier comments it would seem like we would want a nice path to convert existing multithreaded algorithms to use vtkSMPTools knowing that vtkSMPTools would not slow down the existing algorithm. Doing #if VTK_SMP_BACKEND == SLOW use vtkMultithreader #else use vtkSMPTools #endif sounds odd. I did not read the pdf so if that is covered in there apologies. On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: Hi Sujin, That sounds good. Even if the choice of backend is transparent as far as using vtkSMPTools is concerned, it's very nice to be able to report which backend was configured. - David On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: Hi Sean, vtkSMPTools is a framework for implementing multi-threaded algorithms in VTK. It support several backends. The main ones are TBB and OpenMP. There are Kaapi and Simple backends which are no longer supported and will be removed soon. Finally, the default backend is Sequential which is just a single threaded implementation of the framework. After removal of the Kaapi and Simple backend, if you need multithreading support on Clang you would have to use TBB. The Sequential backend will be supported on all platforms. David, I have talked with Berk about this and I will soon make a change to have a compile time macro to check for SMP backend type. I will also finally remove Kaapi and Simple backend as part of this change. Thanks Sujin On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >Why would you want to continue using vtkMultiThreader when Sequential or >Simple is used? In fact, now that there is an openmp backend, we should be >removing simple. It was only there to ease debugging since tbb had very >complex back-traces. Openmp back-traces are much more readable. Do you want >the algorithm to be multithreaded even when Sequential is used? I don't know the APIs you're discussing, so this comment is coming mostly from ignorance, but: are you talking about requiring OpenMP to build VTK? Clang has only very recently added OpenMP support, and IIRC it's not complete. Also, last I checked, Apple's fork of clang doesn't support it at all. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Tue Feb 9 19:11:56 2016 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 10 Feb 2016 00:11:56 +0000 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy Although the https://www.threadingbuildingblocks.org/faq/10 page tries to clarify dual licensing, it's still not fully clear for me if there is any catch in the open-source license. Can you confirm that TBB in VTK can be used in a commercial software without any restrictions (paying licensing fees, disclosing source code, etc)? Andras From: Moreland, Kenneth [mailto:kmorel at sandia.gov] Sent: February 9, 2016 6:32 PM To: Andras Lasso ; Geveci, Berk (External Contact) ; Ken Martin Cc: VTK Developers ; David Gobbi Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? $700? TBB is open-source, GPLv2 with runtime exception: https://www.threadingbuildingblocks.org/licensing -Ken From: vtk-developers > on behalf of Andras Lasso > Date: Tuesday, February 9, 2016 at 3:56 PM To: "Geveci, Berk (External Contact)" >, Ken Martin > Cc: VTK Developers >, David Gobbi > Subject: [EXTERNAL] Re: [vtk-developers] Checking SMP backend at runtime/compiletime? >we'll have to require that people use TBB. Are you talking about Intel TBB - single license starting from $700? Or there are some free replacements? For most of our projects current performance of VTK is already good enough and it is very important to not have any licensing cost or restrictions. So, I would prefer free vtkMultiThreader over expensive Intel TBB, regardless of speed improvements. Andras From: Berk Geveci Sent: February 9, 2016 14:56 To: Ken Martin Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? A few comments: * I support the path David wants to take. We flushed this out over several months in collaboration with a Google Summer of Code student. It is the best transition strategy given that we have several moving components (see below). * The Simple backend of vtkSMPTools is only there for debugging. Helgrind produces lots of false positives when using TBB so I developed the Simple backend for use with Helgrind. It is not a production backend and pretty much sucks. Now that we haven an OpenMP backend that can be used with Helgrind, Simple must die. I don't see a reason to deprecate it first since it is there only for debugging. This is clearly documented in the PDF will pointed to. * For compilers that do not support OpenMP 3.1, one can (and should) use TBB. TBB is the better backend anyway so I recommend it over OpenMP. * We will not include TBB in VTK. It is an external dependency similarly to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if they want any thread-level parallelism out of VTK. We need to discuss what "in the future" means. * Posix threads, C++11 threads etc. are not the way to go. They are way too low level and require management of thread pools and such to get good scalability. Things that OpenMP and TBB already to well. In general, for the kind of parallel computing we want in VTK, the best tools are high level ones such as parallel for loops etc. Furthermore, OpenMP will be important where we want to get SIMD (vector) parallelism. Auto-vectorization is very imperfect. And there are no C++ primitives that help with SIMD in C++11. * At one point, we will have to get rid of vtkMultiThreader (at least of its use in algorithms, it may still be useful for GUI threads and whatnot). Hopefully, by then OpenMP 3.1 or above will be universally supported so we can make it the default backend. If not though, we'll have to require that people use TBB. Best, -berk On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin > wrote: Echoing David's earlier comments it would seem like we would want a nice path to convert existing multithreaded algorithms to use vtkSMPTools knowing that vtkSMPTools would not slow down the existing algorithm. Doing #if VTK_SMP_BACKEND == SLOW use vtkMultithreader #else use vtkSMPTools #endif sounds odd. I did not read the pdf so if that is covered in there apologies. On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: Hi Sujin, That sounds good. Even if the choice of backend is transparent as far as using vtkSMPTools is concerned, it's very nice to be able to report which backend was configured. - David On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: Hi Sean, vtkSMPTools is a framework for implementing multi-threaded algorithms in VTK. It support several backends. The main ones are TBB and OpenMP. There are Kaapi and Simple backends which are no longer supported and will be removed soon. Finally, the default backend is Sequential which is just a single threaded implementation of the framework. After removal of the Kaapi and Simple backend, if you need multithreading support on Clang you would have to use TBB. The Sequential backend will be supported on all platforms. David, I have talked with Berk about this and I will soon make a change to have a compile time macro to check for SMP backend type. I will also finally remove Kaapi and Simple backend as part of this change. Thanks Sujin On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >Why would you want to continue using vtkMultiThreader when Sequential or >Simple is used? In fact, now that there is an openmp backend, we should be >removing simple. It was only there to ease debugging since tbb had very >complex back-traces. Openmp back-traces are much more readable. Do you want >the algorithm to be multithreaded even when Sequential is used? I don't know the APIs you're discussing, so this comment is coming mostly from ignorance, but: are you talking about requiring OpenMP to build VTK? Clang has only very recently added OpenMP support, and IIRC it's not complete. Also, last I checked, Apple's fork of clang doesn't support it at all. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Wed Feb 10 09:50:20 2016 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Wed, 10 Feb 2016 14:50:20 +0000 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: , Message-ID: Andreas, I am not a lawyer, so I make no claims to my expertise in this, but I'm pretty sure you should be ok. Looking at that same FAQ link you sent is this: Intel? TBB is available under the common open-source software license, GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel? TBB open-source license is exactly the same as that used by the libstdc++ in gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of well-known OSS applications including MySQL, NetBeans, and the Linux kernel. - See more at: https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf So, you if you feel comfortable compiling your code with gcc, you shod be fine. -Ken Sent from my iPad so blame autocorrect. On Feb 9, 2016, at 5:14 PM, Andras Lasso > wrote: Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy Although the https://www.threadingbuildingblocks.org/faq/10 page tries to clarify dual licensing, it?s still not fully clear for me if there is any catch in the open-source license. Can you confirm that TBB in VTK can be used in a commercial software without any restrictions (paying licensing fees, disclosing source code, etc)? Andras From: Moreland, Kenneth [mailto:kmorel at sandia.gov] Sent: February 9, 2016 6:32 PM To: Andras Lasso >; Geveci, Berk (External Contact) >; Ken Martin > Cc: VTK Developers >; David Gobbi > Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? $700? TBB is open-source, GPLv2 with runtime exception: https://www.threadingbuildingblocks.org/licensing -Ken From: vtk-developers > on behalf of Andras Lasso > Date: Tuesday, February 9, 2016 at 3:56 PM To: "Geveci, Berk (External Contact)" >, Ken Martin > Cc: VTK Developers >, David Gobbi > Subject: [EXTERNAL] Re: [vtk-developers] Checking SMP backend at runtime/compiletime? >we'll have to require that people use TBB. Are you talking about Intel TBB ? single license starting from $700? Or there are some free replacements? For most of our projects current performance of VTK is already good enough and it is very important to not have any licensing cost or restrictions. So, I would prefer free vtkMultiThreader over expensive Intel TBB, regardless of speed improvements. Andras From: Berk Geveci Sent: February 9, 2016 14:56 To: Ken Martin Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? A few comments: * I support the path David wants to take. We flushed this out over several months in collaboration with a Google Summer of Code student. It is the best transition strategy given that we have several moving components (see below). * The Simple backend of vtkSMPTools is only there for debugging. Helgrind produces lots of false positives when using TBB so I developed the Simple backend for use with Helgrind. It is not a production backend and pretty much sucks. Now that we haven an OpenMP backend that can be used with Helgrind, Simple must die. I don't see a reason to deprecate it first since it is there only for debugging. This is clearly documented in the PDF will pointed to. * For compilers that do not support OpenMP 3.1, one can (and should) use TBB. TBB is the better backend anyway so I recommend it over OpenMP. * We will not include TBB in VTK. It is an external dependency similarly to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if they want any thread-level parallelism out of VTK. We need to discuss what "in the future" means. * Posix threads, C++11 threads etc. are not the way to go. They are way too low level and require management of thread pools and such to get good scalability. Things that OpenMP and TBB already to well. In general, for the kind of parallel computing we want in VTK, the best tools are high level ones such as parallel for loops etc. Furthermore, OpenMP will be important where we want to get SIMD (vector) parallelism. Auto-vectorization is very imperfect. And there are no C++ primitives that help with SIMD in C++11. * At one point, we will have to get rid of vtkMultiThreader (at least of its use in algorithms, it may still be useful for GUI threads and whatnot). Hopefully, by then OpenMP 3.1 or above will be universally supported so we can make it the default backend. If not though, we'll have to require that people use TBB. Best, -berk On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin > wrote: Echoing David's earlier comments it would seem like we would want a nice path to convert existing multithreaded algorithms to use vtkSMPTools knowing that vtkSMPTools would not slow down the existing algorithm. Doing #if VTK_SMP_BACKEND == SLOW use vtkMultithreader #else use vtkSMPTools #endif sounds odd. I did not read the pdf so if that is covered in there apologies. On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: Hi Sujin, That sounds good. Even if the choice of backend is transparent as far as using vtkSMPTools is concerned, it's very nice to be able to report which backend was configured. - David On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: Hi Sean, vtkSMPTools is a framework for implementing multi-threaded algorithms in VTK. It support several backends. The main ones are TBB and OpenMP. There are Kaapi and Simple backends which are no longer supported and will be removed soon. Finally, the default backend is Sequential which is just a single threaded implementation of the framework. After removal of the Kaapi and Simple backend, if you need multithreading support on Clang you would have to use TBB. The Sequential backend will be supported on all platforms. David, I have talked with Berk about this and I will soon make a change to have a compile time macro to check for SMP backend type. I will also finally remove Kaapi and Simple backend as part of this change. Thanks Sujin On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >Why would you want to continue using vtkMultiThreader when Sequential or >Simple is used? In fact, now that there is an openmp backend, we should be >removing simple. It was only there to ease debugging since tbb had very >complex back-traces. Openmp back-traces are much more readable. Do you want >the algorithm to be multithreaded even when Sequential is used? I don't know the APIs you're discussing, so this comment is coming mostly from ignorance, but: are you talking about requiring OpenMP to build VTK? Clang has only very recently added OpenMP support, and IIRC it's not complete. Also, last I checked, Apple's fork of clang doesn't support it at all. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Wed Feb 10 10:02:59 2016 From: pieper at isomics.com (Steve Pieper) Date: Wed, 10 Feb 2016 10:02:59 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Hi Ken - I agree with Andras that this needs to be carefully considered. We rely on the robustness and consistency of the multithreader and it maxes out our processors for important use cases. Having other options is good, but not if it takes away what already works. The no-GPL rule has been very important to the success of VTK and ITK. I'm not a lawyer either, but libstc++ and the linux kernel are very different because you typically don't ship them with the software because the user has their own copy. Also the TBB "runtime exception specifically" says it only applies to a "free software library" which it doesn't define [1]. A very common interpretation of "free software library" would be that it means other GPL libraries (at least that's what the FSF and RMS would likely say it means). I don't mind the option of linking to TBB, but I wouldn't want to see that be the default path. -Steve [1] https://www.threadingbuildingblocks.org/licensing#runtime-exception On Wed, Feb 10, 2016 at 9:50 AM, Moreland, Kenneth wrote: > Andreas, > > I am not a lawyer, so I make no claims to my expertise in this, but I'm > pretty sure you should be ok. Looking at that same FAQ link you sent is > this: > > Intel? TBB is available under the common open-source software license, > GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel? TBB > open-source license is exactly the same as that used by the libstdc++ in > gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of > well-known OSS applications including MySQL, NetBeans, and the Linux > kernel. - See more at: > https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf > > So, you if you feel comfortable compiling your code with gcc, you shod be > fine. > > -Ken > > Sent from my iPad so blame autocorrect. > > On Feb 9, 2016, at 5:14 PM, Andras Lasso wrote: > > Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy > > > > Although the https://www.threadingbuildingblocks.org/faq/10 page tries to > clarify dual licensing, it?s still not fully clear for me if there is any > catch in the open-source license. > > > > Can you confirm that TBB in VTK can be used in a commercial software > without any restrictions (paying licensing fees, disclosing source code, > etc)? > > > > Andras > > > > *From:* Moreland, Kenneth [mailto:kmorel at sandia.gov ] > *Sent:* February 9, 2016 6:32 PM > *To:* Andras Lasso ; Geveci, Berk (External Contact) < > berk.geveci at kitware.com>; Ken Martin > *Cc:* VTK Developers ; David Gobbi < > david.gobbi at gmail.com> > *Subject:* Re: [vtk-developers] Checking SMP backend at > runtime/compiletime? > > > > $700? TBB is open-source, GPLv2 with runtime exception: > https://www.threadingbuildingblocks.org/licensing > > > > -Ken > > > > *From: *vtk-developers on behalf of > Andras Lasso > *Date: *Tuesday, February 9, 2016 at 3:56 PM > *To: *"Geveci, Berk (External Contact)" , Ken > Martin > *Cc: *VTK Developers , David Gobbi < > david.gobbi at gmail.com> > *Subject: *[EXTERNAL] Re: [vtk-developers] Checking SMP backend at > runtime/compiletime? > > > > >we'll have to require that people use TBB. > > Are you talking about Intel TBB ? single license starting from $700? Or > there are some free replacements? > > > > For most of our projects current performance of VTK is already good enough > and it is very important to not have any licensing cost or restrictions. > So, I would prefer free vtkMultiThreader over expensive Intel TBB, > regardless of speed improvements. > > > > Andras > > > > > *From: *Berk Geveci > *Sent: *February 9, 2016 14:56 > *To: *Ken Martin > *Cc: *VTK Developers ; David Gobbi > > *Subject: *Re: [vtk-developers] Checking SMP backend at > runtime/compiletime? > > > > A few comments: > > > > * I support the path David wants to take. We flushed this out over several > months in collaboration with a Google Summer of Code student. It is the > best transition strategy given that we have several moving components (see > below). > > > > * The Simple backend of vtkSMPTools is only there for debugging. Helgrind > produces lots of false positives when using TBB so I developed the Simple > backend for use with Helgrind. It is not a production backend and pretty > much sucks. Now that we haven an OpenMP backend that can be used with > Helgrind, Simple must die. I don't see a reason to deprecate it first since > it is there only for debugging. This is clearly documented in the PDF will > pointed to. > > > > * For compilers that do not support OpenMP 3.1, one can (and should) use > TBB. TBB is the better backend anyway so I recommend it over OpenMP. > > > > * We will not include TBB in VTK. It is an external dependency similarly > to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if > they want any thread-level parallelism out of VTK. We need to discuss what > "in the future" means. > > > > * Posix threads, C++11 threads etc. are not the way to go. They are way > too low level and require management of thread pools and such to get good > scalability. Things that OpenMP and TBB already to well. In general, for > the kind of parallel computing we want in VTK, the best tools are high > level ones such as parallel for loops etc. Furthermore, OpenMP will be > important where we want to get SIMD (vector) parallelism. > Auto-vectorization is very imperfect. And there are no C++ primitives that > help with SIMD in C++11. > > > > * At one point, we will have to get rid of vtkMultiThreader (at least of > its use in algorithms, it may still be useful for GUI threads and whatnot). > Hopefully, by then OpenMP 3.1 or above will be universally supported so we > can make it the default backend. If not though, we'll have to require that > people use TBB. > > > > Best, > > -berk > > > > On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin > wrote: > > Echoing David's earlier comments it would seem like we would want a nice > path to convert existing multithreaded algorithms to use vtkSMPTools > knowing that vtkSMPTools would not slow down the existing algorithm. Doing > > > > #if VTK_SMP_BACKEND == SLOW > > use vtkMultithreader > > #else > > use vtkSMPTools > > #endif > > > > sounds odd. I did not read the pdf so if that is covered in there > apologies. > > > > > > > > > > On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: > > Hi Sujin, > > > > That sounds good. Even if the choice of backend is transparent as far as > using vtkSMPTools is concerned, it's very nice to be able to report which > backend was configured. > > > > - David > > > > On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: > > Hi Sean, > > vtkSMPTools is a framework for implementing multi-threaded algorithms in > VTK. It support several backends. The main ones are TBB and OpenMP. There > are Kaapi and Simple backends which are no longer supported and will be > removed soon. Finally, the default backend is Sequential which is just a > single threaded implementation of the framework. After removal of the Kaapi > and Simple backend, if you need multithreading support on Clang you would > have to use TBB. The Sequential backend will be supported on all platforms. > > David, > > I have talked with Berk about this and I will soon make a change to have a > compile time macro to check for SMP backend type. I will also finally > remove Kaapi and Simple backend as part of this change. > > Thanks > > Sujin > > > > On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: > > On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: > > >Why would you want to continue using vtkMultiThreader when Sequential or > >Simple is used? In fact, now that there is an openmp backend, we should be > >removing simple. It was only there to ease debugging since tbb had very > >complex back-traces. Openmp back-traces are much more readable. Do you > want > >the algorithm to be multithreaded even when Sequential is used? > > I don't know the APIs you're discussing, so this comment is coming mostly > from ignorance, but: are you talking about requiring OpenMP to build VTK? > Clang has only very recently added OpenMP support, and IIRC it's not > complete. Also, last I checked, Apple's fork of clang doesn't support it > at all. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > -- > > 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. > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Wed Feb 10 09:54:28 2016 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 10 Feb 2016 14:54:28 +0000 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: , Message-ID: Very good. Thank you for the clarification. Andras From: Moreland, Kenneth [mailto:kmorel at sandia.gov] Sent: Wednesday, February 10, 2016 9:50 AM To: Andras Lasso Cc: Geveci, Berk (External Contact) ; Ken Martin ; VTK Developers ; David Gobbi Subject: RE: [vtk-developers] Checking SMP backend at runtime/compiletime? Andreas, I am not a lawyer, so I make no claims to my expertise in this, but I'm pretty sure you should be ok. Looking at that same FAQ link you sent is this: Intel? TBB is available under the common open-source software license, GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel? TBB open-source license is exactly the same as that used by the libstdc++ in gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of well-known OSS applications including MySQL, NetBeans, and the Linux kernel. - See more at: https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf So, you if you feel comfortable compiling your code with gcc, you shod be fine. -Ken Sent from my iPad so blame autocorrect. On Feb 9, 2016, at 5:14 PM, Andras Lasso > wrote: Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy Although the https://www.threadingbuildingblocks.org/faq/10 page tries to clarify dual licensing, it's still not fully clear for me if there is any catch in the open-source license. Can you confirm that TBB in VTK can be used in a commercial software without any restrictions (paying licensing fees, disclosing source code, etc)? Andras From: Moreland, Kenneth [mailto:kmorel at sandia.gov] Sent: February 9, 2016 6:32 PM To: Andras Lasso >; Geveci, Berk (External Contact) >; Ken Martin > Cc: VTK Developers >; David Gobbi > Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? $700? TBB is open-source, GPLv2 with runtime exception: https://www.threadingbuildingblocks.org/licensing -Ken From: vtk-developers > on behalf of Andras Lasso > Date: Tuesday, February 9, 2016 at 3:56 PM To: "Geveci, Berk (External Contact)" >, Ken Martin > Cc: VTK Developers >, David Gobbi > Subject: [EXTERNAL] Re: [vtk-developers] Checking SMP backend at runtime/compiletime? >we'll have to require that people use TBB. Are you talking about Intel TBB - single license starting from $700? Or there are some free replacements? For most of our projects current performance of VTK is already good enough and it is very important to not have any licensing cost or restrictions. So, I would prefer free vtkMultiThreader over expensive Intel TBB, regardless of speed improvements. Andras From: Berk Geveci Sent: February 9, 2016 14:56 To: Ken Martin Cc: VTK Developers; David Gobbi Subject: Re: [vtk-developers] Checking SMP backend at runtime/compiletime? A few comments: * I support the path David wants to take. We flushed this out over several months in collaboration with a Google Summer of Code student. It is the best transition strategy given that we have several moving components (see below). * The Simple backend of vtkSMPTools is only there for debugging. Helgrind produces lots of false positives when using TBB so I developed the Simple backend for use with Helgrind. It is not a production backend and pretty much sucks. Now that we haven an OpenMP backend that can be used with Helgrind, Simple must die. I don't see a reason to deprecate it first since it is there only for debugging. This is clearly documented in the PDF will pointed to. * For compilers that do not support OpenMP 3.1, one can (and should) use TBB. TBB is the better backend anyway so I recommend it over OpenMP. * We will not include TBB in VTK. It is an external dependency similarly to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if they want any thread-level parallelism out of VTK. We need to discuss what "in the future" means. * Posix threads, C++11 threads etc. are not the way to go. They are way too low level and require management of thread pools and such to get good scalability. Things that OpenMP and TBB already to well. In general, for the kind of parallel computing we want in VTK, the best tools are high level ones such as parallel for loops etc. Furthermore, OpenMP will be important where we want to get SIMD (vector) parallelism. Auto-vectorization is very imperfect. And there are no C++ primitives that help with SIMD in C++11. * At one point, we will have to get rid of vtkMultiThreader (at least of its use in algorithms, it may still be useful for GUI threads and whatnot). Hopefully, by then OpenMP 3.1 or above will be universally supported so we can make it the default backend. If not though, we'll have to require that people use TBB. Best, -berk On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin > wrote: Echoing David's earlier comments it would seem like we would want a nice path to convert existing multithreaded algorithms to use vtkSMPTools knowing that vtkSMPTools would not slow down the existing algorithm. Doing #if VTK_SMP_BACKEND == SLOW use vtkMultithreader #else use vtkSMPTools #endif sounds odd. I did not read the pdf so if that is covered in there apologies. On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi > wrote: Hi Sujin, That sounds good. Even if the choice of backend is transparent as far as using vtkSMPTools is concerned, it's very nice to be able to report which backend was configured. - David On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip > wrote: Hi Sean, vtkSMPTools is a framework for implementing multi-threaded algorithms in VTK. It support several backends. The main ones are TBB and OpenMP. There are Kaapi and Simple backends which are no longer supported and will be removed soon. Finally, the default backend is Sequential which is just a single threaded implementation of the framework. After removal of the Kaapi and Simple backend, if you need multithreading support on Clang you would have to use TBB. The Sequential backend will be supported on all platforms. David, I have talked with Berk about this and I will soon make a change to have a compile time macro to check for SMP backend type. I will also finally remove Kaapi and Simple backend as part of this change. Thanks Sujin On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride > wrote: On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >Why would you want to continue using vtkMultiThreader when Sequential or >Simple is used? In fact, now that there is an openmp backend, we should be >removing simple. It was only there to ease debugging since tbb had very >complex back-traces. Openmp back-traces are much more readable. Do you want >the algorithm to be multithreaded even when Sequential is used? I don't know the APIs you're discussing, so this comment is coming mostly from ignorance, but: are you talking about requiring OpenMP to build VTK? Clang has only very recently added OpenMP support, and IIRC it's not complete. Also, last I checked, Apple's fork of clang doesn't support it at all. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Feb 10 10:46:32 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Feb 2016 10:46:32 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Hi Steve, * The default path will be OpenMP. * If your compiler does not support OpenMP, you will need TBB. * If you don't like the performance of OpenMP, you will need TBB. Hopefully, in 1-2 years all compilers will support OpenMP 3.1 or greater so this will be a moot point. We don't plan on removing the multi-threader path tomorrow. Currently, VS supports OpenMP 2, which is totally lame. So that's fishy. I am confident that Clang/LLVM will have the necessary OpenMP support before we remove the vtkMultiThreader implementation. So VS users may need an Intel compiler or use TBB unless MS improves its OpenMP support in a couple years. Given the direction multi/many core is going, low-level thread management in VTK is a thing of the past. On an Intel KNL processor, soon to be available commercially, good performance will require > 200 threads + 16x2 wide vector processing. We can't sit on legacy parallel implementation to properly utilize these processors. Also, please stop the lawyer talk and the nitpicking about the runtime exception. People have been shipping commercial products that utilize libraries with this license for decades without any issues. Furthermore, Intel's intent is clear - they want to enable the sale of their processors - and this is the way they decided to enable it. It is entirely illogical to think that they will then pursue legal action and scare everyone off TBB. If you don't like the TBB license, use OpenMP. Or you are free to implement your own backend outside VTK (the design makes it very easy). PS: We will likely ship all of our binaries with TBB as it gives the best performance currently. Best, -berk On Wed, Feb 10, 2016 at 10:02 AM, Steve Pieper wrote: > Hi Ken - > > I agree with Andras that this needs to be carefully considered. We rely > on the robustness and consistency of the multithreader and it maxes out our > processors for important use cases. Having other options is good, but not > if it takes away what already works. > > The no-GPL rule has been very important to the success of VTK and ITK. > I'm not a lawyer either, but libstc++ and the linux kernel are very > different because you typically don't ship them with the software because > the user has their own copy. Also the TBB "runtime exception specifically" > says it only applies to a "free software library" which it doesn't define > [1]. A very common interpretation of "free software library" would be that > it means other GPL libraries (at least that's what the FSF and RMS would > likely say it means). > > I don't mind the option of linking to TBB, but I wouldn't want to see that > be the default path. > > -Steve > > [1] https://www.threadingbuildingblocks.org/licensing#runtime-exception > > On Wed, Feb 10, 2016 at 9:50 AM, Moreland, Kenneth > wrote: > >> Andreas, >> >> I am not a lawyer, so I make no claims to my expertise in this, but I'm >> pretty sure you should be ok. Looking at that same FAQ link you sent is >> this: >> >> Intel? TBB is available under the common open-source software license, >> GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel? TBB >> open-source license is exactly the same as that used by the libstdc++ in >> gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of >> well-known OSS applications including MySQL, NetBeans, and the Linux >> kernel. - See more at: >> https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf >> >> So, you if you feel comfortable compiling your code with gcc, you shod be >> fine. >> >> -Ken >> >> Sent from my iPad so blame autocorrect. >> >> On Feb 9, 2016, at 5:14 PM, Andras Lasso wrote: >> >> Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy >> >> >> >> Although the https://www.threadingbuildingblocks.org/faq/10 page tries >> to clarify dual licensing, it?s still not fully clear for me if there is >> any catch in the open-source license. >> >> >> >> Can you confirm that TBB in VTK can be used in a commercial software >> without any restrictions (paying licensing fees, disclosing source code, >> etc)? >> >> >> >> Andras >> >> >> >> *From:* Moreland, Kenneth [mailto:kmorel at sandia.gov ] >> *Sent:* February 9, 2016 6:32 PM >> *To:* Andras Lasso ; Geveci, Berk (External Contact) < >> berk.geveci at kitware.com>; Ken Martin >> *Cc:* VTK Developers ; David Gobbi < >> david.gobbi at gmail.com> >> *Subject:* Re: [vtk-developers] Checking SMP backend at >> runtime/compiletime? >> >> >> >> $700? TBB is open-source, GPLv2 with runtime exception: >> https://www.threadingbuildingblocks.org/licensing >> >> >> >> -Ken >> >> >> >> *From: *vtk-developers on behalf of >> Andras Lasso >> *Date: *Tuesday, February 9, 2016 at 3:56 PM >> *To: *"Geveci, Berk (External Contact)" , Ken >> Martin >> *Cc: *VTK Developers , David Gobbi < >> david.gobbi at gmail.com> >> *Subject: *[EXTERNAL] Re: [vtk-developers] Checking SMP backend at >> runtime/compiletime? >> >> >> >> >we'll have to require that people use TBB. >> >> Are you talking about Intel TBB ? single license starting from $700? Or >> there are some free replacements? >> >> >> >> For most of our projects current performance of VTK is already good >> enough and it is very important to not have any licensing cost or >> restrictions. So, I would prefer free vtkMultiThreader over expensive Intel >> TBB, regardless of speed improvements. >> >> >> >> Andras >> >> >> >> >> *From: *Berk Geveci >> *Sent: *February 9, 2016 14:56 >> *To: *Ken Martin >> *Cc: *VTK Developers ; David Gobbi >> >> *Subject: *Re: [vtk-developers] Checking SMP backend at >> runtime/compiletime? >> >> >> >> A few comments: >> >> >> >> * I support the path David wants to take. We flushed this out over >> several months in collaboration with a Google Summer of Code student. It is >> the best transition strategy given that we have several moving components >> (see below). >> >> >> >> * The Simple backend of vtkSMPTools is only there for debugging. Helgrind >> produces lots of false positives when using TBB so I developed the Simple >> backend for use with Helgrind. It is not a production backend and pretty >> much sucks. Now that we haven an OpenMP backend that can be used with >> Helgrind, Simple must die. I don't see a reason to deprecate it first since >> it is there only for debugging. This is clearly documented in the PDF will >> pointed to. >> >> >> >> * For compilers that do not support OpenMP 3.1, one can (and should) use >> TBB. TBB is the better backend anyway so I recommend it over OpenMP. >> >> >> >> * We will not include TBB in VTK. It is an external dependency similarly >> to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if >> they want any thread-level parallelism out of VTK. We need to discuss what >> "in the future" means. >> >> >> >> * Posix threads, C++11 threads etc. are not the way to go. They are way >> too low level and require management of thread pools and such to get good >> scalability. Things that OpenMP and TBB already to well. In general, for >> the kind of parallel computing we want in VTK, the best tools are high >> level ones such as parallel for loops etc. Furthermore, OpenMP will be >> important where we want to get SIMD (vector) parallelism. >> Auto-vectorization is very imperfect. And there are no C++ primitives that >> help with SIMD in C++11. >> >> >> >> * At one point, we will have to get rid of vtkMultiThreader (at least of >> its use in algorithms, it may still be useful for GUI threads and whatnot). >> Hopefully, by then OpenMP 3.1 or above will be universally supported so we >> can make it the default backend. If not though, we'll have to require that >> people use TBB. >> >> >> >> Best, >> >> -berk >> >> >> >> On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin >> wrote: >> >> Echoing David's earlier comments it would seem like we would want a nice >> path to convert existing multithreaded algorithms to use vtkSMPTools >> knowing that vtkSMPTools would not slow down the existing algorithm. Doing >> >> >> >> #if VTK_SMP_BACKEND == SLOW >> >> use vtkMultithreader >> >> #else >> >> use vtkSMPTools >> >> #endif >> >> >> >> sounds odd. I did not read the pdf so if that is covered in there >> apologies. >> >> >> >> >> >> >> >> >> >> On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi >> wrote: >> >> Hi Sujin, >> >> >> >> That sounds good. Even if the choice of backend is transparent as far as >> using vtkSMPTools is concerned, it's very nice to be able to report which >> backend was configured. >> >> >> >> - David >> >> >> >> On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip >> wrote: >> >> Hi Sean, >> >> vtkSMPTools is a framework for implementing multi-threaded algorithms in >> VTK. It support several backends. The main ones are TBB and OpenMP. There >> are Kaapi and Simple backends which are no longer supported and will be >> removed soon. Finally, the default backend is Sequential which is just a >> single threaded implementation of the framework. After removal of the Kaapi >> and Simple backend, if you need multithreading support on Clang you would >> have to use TBB. The Sequential backend will be supported on all platforms. >> >> David, >> >> I have talked with Berk about this and I will soon make a change to have >> a compile time macro to check for SMP backend type. I will also finally >> remove Kaapi and Simple backend as part of this change. >> >> Thanks >> >> Sujin >> >> >> >> On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride >> wrote: >> >> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >> >> >Why would you want to continue using vtkMultiThreader when Sequential or >> >Simple is used? In fact, now that there is an openmp backend, we should >> be >> >removing simple. It was only there to ease debugging since tbb had very >> >complex back-traces. Openmp back-traces are much more readable. Do you >> want >> >the algorithm to be multithreaded even when Sequential is used? >> >> I don't know the APIs you're discussing, so this comment is coming mostly >> from ignorance, but: are you talking about requiring OpenMP to build VTK? >> Clang has only very recently added OpenMP support, and IIRC it's not >> complete. Also, last I checked, Apple's fork of clang doesn't support it >> at all. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> >> >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> >> -- >> >> 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. >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Wed Feb 10 10:55:31 2016 From: pieper at isomics.com (Steve Pieper) Date: Wed, 10 Feb 2016 10:55:31 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: Hi Berk - All I asked is that you think carefully. Thanks for the info. -Steve On Wed, Feb 10, 2016 at 10:46 AM, Berk Geveci wrote: > Hi Steve, > > * The default path will be OpenMP. > * If your compiler does not support OpenMP, you will need TBB. > * If you don't like the performance of OpenMP, you will need TBB. > > Hopefully, in 1-2 years all compilers will support OpenMP 3.1 or greater > so this will be a moot point. We don't plan on removing the multi-threader > path tomorrow. Currently, VS supports OpenMP 2, which is totally lame. So > that's fishy. I am confident that Clang/LLVM will have the necessary OpenMP > support before we remove the vtkMultiThreader implementation. So VS users > may need an Intel compiler or use TBB unless MS improves its OpenMP support > in a couple years. > > Given the direction multi/many core is going, low-level thread management > in VTK is a thing of the past. On an Intel KNL processor, soon to be > available commercially, good performance will require > 200 threads + 16x2 > wide vector processing. We can't sit on legacy parallel implementation to > properly utilize these processors. > > Also, please stop the lawyer talk and the nitpicking about the runtime > exception. People have been shipping commercial products that utilize > libraries with this license for decades without any issues. Furthermore, > Intel's intent is clear - they want to enable the sale of their processors > - and this is the way they decided to enable it. It is entirely illogical > to think that they will then pursue legal action and scare everyone off > TBB. If you don't like the TBB license, use OpenMP. Or you are free to > implement your own backend outside VTK (the design makes it very easy). > > PS: We will likely ship all of our binaries with TBB as it gives the best > performance currently. > > Best, > -berk > > > > On Wed, Feb 10, 2016 at 10:02 AM, Steve Pieper wrote: > >> Hi Ken - >> >> I agree with Andras that this needs to be carefully considered. We rely >> on the robustness and consistency of the multithreader and it maxes out our >> processors for important use cases. Having other options is good, but not >> if it takes away what already works. >> >> The no-GPL rule has been very important to the success of VTK and ITK. >> I'm not a lawyer either, but libstc++ and the linux kernel are very >> different because you typically don't ship them with the software because >> the user has their own copy. Also the TBB "runtime exception specifically" >> says it only applies to a "free software library" which it doesn't define >> [1]. A very common interpretation of "free software library" would be that >> it means other GPL libraries (at least that's what the FSF and RMS would >> likely say it means). >> >> I don't mind the option of linking to TBB, but I wouldn't want to see >> that be the default path. >> >> -Steve >> >> [1] https://www.threadingbuildingblocks.org/licensing#runtime-exception >> >> On Wed, Feb 10, 2016 at 9:50 AM, Moreland, Kenneth >> wrote: >> >>> Andreas, >>> >>> I am not a lawyer, so I make no claims to my expertise in this, but I'm >>> pretty sure you should be ok. Looking at that same FAQ link you sent is >>> this: >>> >>> Intel? TBB is available under the common open-source software license, >>> GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel? TBB >>> open-source license is exactly the same as that used by the libstdc++ in >>> gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of >>> well-known OSS applications including MySQL, NetBeans, and the Linux >>> kernel. - See more at: >>> https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf >>> >>> So, you if you feel comfortable compiling your code with gcc, you shod >>> be fine. >>> >>> -Ken >>> >>> Sent from my iPad so blame autocorrect. >>> >>> On Feb 9, 2016, at 5:14 PM, Andras Lasso wrote: >>> >>> Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy >>> >>> >>> >>> Although the https://www.threadingbuildingblocks.org/faq/10 page tries >>> to clarify dual licensing, it?s still not fully clear for me if there is >>> any catch in the open-source license. >>> >>> >>> >>> Can you confirm that TBB in VTK can be used in a commercial software >>> without any restrictions (paying licensing fees, disclosing source code, >>> etc)? >>> >>> >>> >>> Andras >>> >>> >>> >>> *From:* Moreland, Kenneth [mailto:kmorel at sandia.gov ] >>> >>> *Sent:* February 9, 2016 6:32 PM >>> *To:* Andras Lasso ; Geveci, Berk (External Contact) < >>> berk.geveci at kitware.com>; Ken Martin >>> *Cc:* VTK Developers ; David Gobbi < >>> david.gobbi at gmail.com> >>> *Subject:* Re: [vtk-developers] Checking SMP backend at >>> runtime/compiletime? >>> >>> >>> >>> $700? TBB is open-source, GPLv2 with runtime exception: >>> https://www.threadingbuildingblocks.org/licensing >>> >>> >>> >>> -Ken >>> >>> >>> >>> *From: *vtk-developers on behalf of >>> Andras Lasso >>> *Date: *Tuesday, February 9, 2016 at 3:56 PM >>> *To: *"Geveci, Berk (External Contact)" , Ken >>> Martin >>> *Cc: *VTK Developers , David Gobbi < >>> david.gobbi at gmail.com> >>> *Subject: *[EXTERNAL] Re: [vtk-developers] Checking SMP backend at >>> runtime/compiletime? >>> >>> >>> >>> >we'll have to require that people use TBB. >>> >>> Are you talking about Intel TBB ? single license starting from $700? Or >>> there are some free replacements? >>> >>> >>> >>> For most of our projects current performance of VTK is already good >>> enough and it is very important to not have any licensing cost or >>> restrictions. So, I would prefer free vtkMultiThreader over expensive Intel >>> TBB, regardless of speed improvements. >>> >>> >>> >>> Andras >>> >>> >>> >>> >>> *From: *Berk Geveci >>> *Sent: *February 9, 2016 14:56 >>> *To: *Ken Martin >>> *Cc: *VTK Developers ; David Gobbi >>> >>> *Subject: *Re: [vtk-developers] Checking SMP backend at >>> runtime/compiletime? >>> >>> >>> >>> A few comments: >>> >>> >>> >>> * I support the path David wants to take. We flushed this out over >>> several months in collaboration with a Google Summer of Code student. It is >>> the best transition strategy given that we have several moving components >>> (see below). >>> >>> >>> >>> * The Simple backend of vtkSMPTools is only there for debugging. >>> Helgrind produces lots of false positives when using TBB so I developed the >>> Simple backend for use with Helgrind. It is not a production backend and >>> pretty much sucks. Now that we haven an OpenMP backend that can be used >>> with Helgrind, Simple must die. I don't see a reason to deprecate it first >>> since it is there only for debugging. This is clearly documented in the PDF >>> will pointed to. >>> >>> >>> >>> * For compilers that do not support OpenMP 3.1, one can (and should) use >>> TBB. TBB is the better backend anyway so I recommend it over OpenMP. >>> >>> >>> >>> * We will not include TBB in VTK. It is an external dependency similarly >>> to OpenGL & MPI. In the future, folks will have to get it or have OpenMP if >>> they want any thread-level parallelism out of VTK. We need to discuss what >>> "in the future" means. >>> >>> >>> >>> * Posix threads, C++11 threads etc. are not the way to go. They are way >>> too low level and require management of thread pools and such to get good >>> scalability. Things that OpenMP and TBB already to well. In general, for >>> the kind of parallel computing we want in VTK, the best tools are high >>> level ones such as parallel for loops etc. Furthermore, OpenMP will be >>> important where we want to get SIMD (vector) parallelism. >>> Auto-vectorization is very imperfect. And there are no C++ primitives that >>> help with SIMD in C++11. >>> >>> >>> >>> * At one point, we will have to get rid of vtkMultiThreader (at least of >>> its use in algorithms, it may still be useful for GUI threads and whatnot). >>> Hopefully, by then OpenMP 3.1 or above will be universally supported so we >>> can make it the default backend. If not though, we'll have to require that >>> people use TBB. >>> >>> >>> >>> Best, >>> >>> -berk >>> >>> >>> >>> On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin >>> wrote: >>> >>> Echoing David's earlier comments it would seem like we would want a nice >>> path to convert existing multithreaded algorithms to use vtkSMPTools >>> knowing that vtkSMPTools would not slow down the existing algorithm. Doing >>> >>> >>> >>> #if VTK_SMP_BACKEND == SLOW >>> >>> use vtkMultithreader >>> >>> #else >>> >>> use vtkSMPTools >>> >>> #endif >>> >>> >>> >>> sounds odd. I did not read the pdf so if that is covered in there >>> apologies. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi >>> wrote: >>> >>> Hi Sujin, >>> >>> >>> >>> That sounds good. Even if the choice of backend is transparent as far >>> as using vtkSMPTools is concerned, it's very nice to be able to report >>> which backend was configured. >>> >>> >>> >>> - David >>> >>> >>> >>> On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip >>> wrote: >>> >>> Hi Sean, >>> >>> vtkSMPTools is a framework for implementing multi-threaded algorithms in >>> VTK. It support several backends. The main ones are TBB and OpenMP. There >>> are Kaapi and Simple backends which are no longer supported and will be >>> removed soon. Finally, the default backend is Sequential which is just a >>> single threaded implementation of the framework. After removal of the Kaapi >>> and Simple backend, if you need multithreading support on Clang you would >>> have to use TBB. The Sequential backend will be supported on all platforms. >>> >>> David, >>> >>> I have talked with Berk about this and I will soon make a change to have >>> a compile time macro to check for SMP backend type. I will also finally >>> remove Kaapi and Simple backend as part of this change. >>> >>> Thanks >>> >>> Sujin >>> >>> >>> >>> On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride >>> wrote: >>> >>> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >>> >>> >Why would you want to continue using vtkMultiThreader when Sequential or >>> >Simple is used? In fact, now that there is an openmp backend, we should >>> be >>> >removing simple. It was only there to ease debugging since tbb had very >>> >complex back-traces. Openmp back-traces are much more readable. Do you >>> want >>> >the algorithm to be multithreaded even when Sequential is used? >>> >>> I don't know the APIs you're discussing, so this comment is coming >>> mostly from ignorance, but: are you talking about requiring OpenMP to build >>> VTK? Clang has only very recently added OpenMP support, and IIRC it's not >>> complete. Also, last I checked, Apple's fork of clang doesn't support it >>> at all. >>> >>> Cheers, >>> >>> -- >>> ____________________________________________________________ >>> Sean McBride, B. Eng sean at rogue-research.com >>> Rogue Research www.rogue-research.com >>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> >>> >>> >>> -- >>> >>> 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. >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Feb 10 11:14:29 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Feb 2016 11:14:29 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: No problem. I don't think that we could think this more carefully :-) This work started in 2013. We were contemplating it for a while before then. Since then, we have discussed this in multiple venues, had discussion in the ARB, published multiple papers & reports, had a Google Summer of Code project, used it to improve existing filters and write new ones. Furthermore, VTK-m has been pushing things forward more aggressively so we have a very good idea the extreme end of what needs to be done for good performance. If we want VTK to be relevant 5-10 years from now, we can't be chained to legacy ways of doing things for much longer. So I plan to push aggressively for change including C++ 11 adoption at the end of this year and some sort of path to C++ 17 after that. Adoption of VTK-m. Adoption of frameworks like DIY (https://github.com/diatomic/diy2). Modern OpenGL implementation (check) etc etc. In terms of licensing, I read a lot of stuff on the runtime exception as it applies to libstdc++ etc. I have no concerns about this path. By the way, libstdc++ is not as different as you think. It has a full STL implementation, which is almost entirely embedded in one's code through template instantiation. So without the exception, all binaries compiled with the GNU C++ compiler would be under GPL. And it is possible to link against libstdc++ statically and hence distribute the whole thing as part of the binary. Something we have done. We have also included libstdc++ in binary distributions in the past. Best, -berk On Wed, Feb 10, 2016 at 10:55 AM, Steve Pieper wrote: > Hi Berk - > > All I asked is that you think carefully. Thanks for the info. > > -Steve > > On Wed, Feb 10, 2016 at 10:46 AM, Berk Geveci > wrote: > >> Hi Steve, >> >> * The default path will be OpenMP. >> * If your compiler does not support OpenMP, you will need TBB. >> * If you don't like the performance of OpenMP, you will need TBB. >> >> Hopefully, in 1-2 years all compilers will support OpenMP 3.1 or greater >> so this will be a moot point. We don't plan on removing the multi-threader >> path tomorrow. Currently, VS supports OpenMP 2, which is totally lame. So >> that's fishy. I am confident that Clang/LLVM will have the necessary OpenMP >> support before we remove the vtkMultiThreader implementation. So VS users >> may need an Intel compiler or use TBB unless MS improves its OpenMP support >> in a couple years. >> >> Given the direction multi/many core is going, low-level thread management >> in VTK is a thing of the past. On an Intel KNL processor, soon to be >> available commercially, good performance will require > 200 threads + 16x2 >> wide vector processing. We can't sit on legacy parallel implementation to >> properly utilize these processors. >> >> Also, please stop the lawyer talk and the nitpicking about the runtime >> exception. People have been shipping commercial products that utilize >> libraries with this license for decades without any issues. Furthermore, >> Intel's intent is clear - they want to enable the sale of their processors >> - and this is the way they decided to enable it. It is entirely illogical >> to think that they will then pursue legal action and scare everyone off >> TBB. If you don't like the TBB license, use OpenMP. Or you are free to >> implement your own backend outside VTK (the design makes it very easy). >> >> PS: We will likely ship all of our binaries with TBB as it gives the best >> performance currently. >> >> Best, >> -berk >> >> >> >> On Wed, Feb 10, 2016 at 10:02 AM, Steve Pieper >> wrote: >> >>> Hi Ken - >>> >>> I agree with Andras that this needs to be carefully considered. We rely >>> on the robustness and consistency of the multithreader and it maxes out our >>> processors for important use cases. Having other options is good, but not >>> if it takes away what already works. >>> >>> The no-GPL rule has been very important to the success of VTK and ITK. >>> I'm not a lawyer either, but libstc++ and the linux kernel are very >>> different because you typically don't ship them with the software because >>> the user has their own copy. Also the TBB "runtime exception specifically" >>> says it only applies to a "free software library" which it doesn't define >>> [1]. A very common interpretation of "free software library" would be that >>> it means other GPL libraries (at least that's what the FSF and RMS would >>> likely say it means). >>> >>> I don't mind the option of linking to TBB, but I wouldn't want to see >>> that be the default path. >>> >>> -Steve >>> >>> [1] https://www.threadingbuildingblocks.org/licensing#runtime-exception >>> >>> On Wed, Feb 10, 2016 at 9:50 AM, Moreland, Kenneth >>> wrote: >>> >>>> Andreas, >>>> >>>> I am not a lawyer, so I make no claims to my expertise in this, but I'm >>>> pretty sure you should be ok. Looking at that same FAQ link you sent is >>>> this: >>>> >>>> Intel? TBB is available under the common open-source software license, >>>> GPLv2 with the (libstdc++) runtime exception. Specifically, the Intel? TBB >>>> open-source license is exactly the same as that used by the libstdc++ in >>>> gcc 4.2.1 (and earlier). GPLv2 is the same license used for a variety of >>>> well-known OSS applications including MySQL, NetBeans, and the Linux >>>> kernel. - See more at: >>>> https://www.threadingbuildingblocks.org/faq/10#sthash.IQJJn2NB.dpuf >>>> >>>> So, you if you feel comfortable compiling your code with gcc, you shod >>>> be fine. >>>> >>>> -Ken >>>> >>>> Sent from my iPad so blame autocorrect. >>>> >>>> On Feb 9, 2016, at 5:14 PM, Andras Lasso wrote: >>>> >>>> Intel TBB price: https://software.intel.com/en-us/intel-tbb/try-buy >>>> >>>> >>>> >>>> Although the https://www.threadingbuildingblocks.org/faq/10 page tries >>>> to clarify dual licensing, it?s still not fully clear for me if there is >>>> any catch in the open-source license. >>>> >>>> >>>> >>>> Can you confirm that TBB in VTK can be used in a commercial software >>>> without any restrictions (paying licensing fees, disclosing source code, >>>> etc)? >>>> >>>> >>>> >>>> Andras >>>> >>>> >>>> >>>> *From:* Moreland, Kenneth [mailto:kmorel at sandia.gov ] >>>> >>>> *Sent:* February 9, 2016 6:32 PM >>>> *To:* Andras Lasso ; Geveci, Berk (External Contact) >>>> ; Ken Martin >>>> *Cc:* VTK Developers ; David Gobbi < >>>> david.gobbi at gmail.com> >>>> *Subject:* Re: [vtk-developers] Checking SMP backend at >>>> runtime/compiletime? >>>> >>>> >>>> >>>> $700? TBB is open-source, GPLv2 with runtime exception: >>>> https://www.threadingbuildingblocks.org/licensing >>>> >>>> >>>> >>>> -Ken >>>> >>>> >>>> >>>> *From: *vtk-developers on behalf of >>>> Andras Lasso >>>> *Date: *Tuesday, February 9, 2016 at 3:56 PM >>>> *To: *"Geveci, Berk (External Contact)" , Ken >>>> Martin >>>> *Cc: *VTK Developers , David Gobbi < >>>> david.gobbi at gmail.com> >>>> *Subject: *[EXTERNAL] Re: [vtk-developers] Checking SMP backend at >>>> runtime/compiletime? >>>> >>>> >>>> >>>> >we'll have to require that people use TBB. >>>> >>>> Are you talking about Intel TBB ? single license starting from $700? Or >>>> there are some free replacements? >>>> >>>> >>>> >>>> For most of our projects current performance of VTK is already good >>>> enough and it is very important to not have any licensing cost or >>>> restrictions. So, I would prefer free vtkMultiThreader over expensive Intel >>>> TBB, regardless of speed improvements. >>>> >>>> >>>> >>>> Andras >>>> >>>> >>>> >>>> >>>> *From: *Berk Geveci >>>> *Sent: *February 9, 2016 14:56 >>>> *To: *Ken Martin >>>> *Cc: *VTK Developers ; David Gobbi >>>> >>>> *Subject: *Re: [vtk-developers] Checking SMP backend at >>>> runtime/compiletime? >>>> >>>> >>>> >>>> A few comments: >>>> >>>> >>>> >>>> * I support the path David wants to take. We flushed this out over >>>> several months in collaboration with a Google Summer of Code student. It is >>>> the best transition strategy given that we have several moving components >>>> (see below). >>>> >>>> >>>> >>>> * The Simple backend of vtkSMPTools is only there for debugging. >>>> Helgrind produces lots of false positives when using TBB so I developed the >>>> Simple backend for use with Helgrind. It is not a production backend and >>>> pretty much sucks. Now that we haven an OpenMP backend that can be used >>>> with Helgrind, Simple must die. I don't see a reason to deprecate it first >>>> since it is there only for debugging. This is clearly documented in the PDF >>>> will pointed to. >>>> >>>> >>>> >>>> * For compilers that do not support OpenMP 3.1, one can (and should) >>>> use TBB. TBB is the better backend anyway so I recommend it over OpenMP. >>>> >>>> >>>> >>>> * We will not include TBB in VTK. It is an external dependency >>>> similarly to OpenGL & MPI. In the future, folks will have to get it or have >>>> OpenMP if they want any thread-level parallelism out of VTK. We need to >>>> discuss what "in the future" means. >>>> >>>> >>>> >>>> * Posix threads, C++11 threads etc. are not the way to go. They are way >>>> too low level and require management of thread pools and such to get good >>>> scalability. Things that OpenMP and TBB already to well. In general, for >>>> the kind of parallel computing we want in VTK, the best tools are high >>>> level ones such as parallel for loops etc. Furthermore, OpenMP will be >>>> important where we want to get SIMD (vector) parallelism. >>>> Auto-vectorization is very imperfect. And there are no C++ primitives that >>>> help with SIMD in C++11. >>>> >>>> >>>> >>>> * At one point, we will have to get rid of vtkMultiThreader (at least >>>> of its use in algorithms, it may still be useful for GUI threads and >>>> whatnot). Hopefully, by then OpenMP 3.1 or above will be universally >>>> supported so we can make it the default backend. If not though, we'll have >>>> to require that people use TBB. >>>> >>>> >>>> >>>> Best, >>>> >>>> -berk >>>> >>>> >>>> >>>> On Tue, Feb 9, 2016 at 11:33 AM, Ken Martin >>>> wrote: >>>> >>>> Echoing David's earlier comments it would seem like we would want a >>>> nice path to convert existing multithreaded algorithms to use vtkSMPTools >>>> knowing that vtkSMPTools would not slow down the existing algorithm. Doing >>>> >>>> >>>> >>>> #if VTK_SMP_BACKEND == SLOW >>>> >>>> use vtkMultithreader >>>> >>>> #else >>>> >>>> use vtkSMPTools >>>> >>>> #endif >>>> >>>> >>>> >>>> sounds odd. I did not read the pdf so if that is covered in there >>>> apologies. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Feb 9, 2016 at 10:56 AM, David Gobbi >>>> wrote: >>>> >>>> Hi Sujin, >>>> >>>> >>>> >>>> That sounds good. Even if the choice of backend is transparent as far >>>> as using vtkSMPTools is concerned, it's very nice to be able to report >>>> which backend was configured. >>>> >>>> >>>> >>>> - David >>>> >>>> >>>> >>>> On Tue, Feb 9, 2016 at 8:46 AM, Sujin Philip >>>> wrote: >>>> >>>> Hi Sean, >>>> >>>> vtkSMPTools is a framework for implementing multi-threaded algorithms >>>> in VTK. It support several backends. The main ones are TBB and OpenMP. >>>> There are Kaapi and Simple backends which are no longer supported and will >>>> be removed soon. Finally, the default backend is Sequential which is just a >>>> single threaded implementation of the framework. After removal of the Kaapi >>>> and Simple backend, if you need multithreading support on Clang you would >>>> have to use TBB. The Sequential backend will be supported on all platforms. >>>> >>>> David, >>>> >>>> I have talked with Berk about this and I will soon make a change to >>>> have a compile time macro to check for SMP backend type. I will also >>>> finally remove Kaapi and Simple backend as part of this change. >>>> >>>> Thanks >>>> >>>> Sujin >>>> >>>> >>>> >>>> On Tue, Feb 9, 2016 at 10:28 AM, Sean McBride >>>> wrote: >>>> >>>> On Tue, 9 Feb 2016 09:13:48 -0500, Sujin Philip said: >>>> >>>> >Why would you want to continue using vtkMultiThreader when Sequential >>>> or >>>> >Simple is used? In fact, now that there is an openmp backend, we >>>> should be >>>> >removing simple. It was only there to ease debugging since tbb had very >>>> >complex back-traces. Openmp back-traces are much more readable. Do you >>>> want >>>> >the algorithm to be multithreaded even when Sequential is used? >>>> >>>> I don't know the APIs you're discussing, so this comment is coming >>>> mostly from ignorance, but: are you talking about requiring OpenMP to build >>>> VTK? Clang has only very recently added OpenMP support, and IIRC it's not >>>> complete. Also, last I checked, Apple's fork of clang doesn't support it >>>> at all. >>>> >>>> Cheers, >>>> >>>> -- >>>> ____________________________________________________________ >>>> Sean McBride, B. Eng sean at rogue-research.com >>>> Rogue Research www.rogue-research.com >>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> 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. >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Feb 10 11:19:09 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 10 Feb 2016 09:19:09 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 Message-ID: <1455121149492-5736481.post@n5.nabble.com> Hello everyone, I used to be able to build my android examples just fine. But since I rebuilt vtk I seem to have a problem. I get the following errors: /In file included from /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c: In function 'print_header': /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:191:30: error: 'struct passwd' has no member named 'pw_gecos' if((comma = HDstrchr(pwd->pw_gecos, ','))) { ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:1224:37: note: in definition of macro 'HDstrchr' #define HDstrchr(S,C) strchr(S,C) ^ In file included from /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:192:56: error: 'struct passwd' has no member named 'pw_gecos' n = MIN(sizeof(real_name) - 1, (unsigned)(comma - pwd->pw_gecos)); ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:331:28: note: in definition of macro 'MIN' #define MIN(a,b) (((a)<(b)) ? (a) : (b)) ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:192:56: error: 'struct passwd' has no member named 'pw_gecos' n = MIN(sizeof(real_name) - 1, (unsigned)(comma - pwd->pw_gecos)); ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:331:41: note: in definition of macro 'MIN' #define MIN(a,b) (((a)<(b)) ? (a) : (b)) ^ In file included from /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:193:27: error: 'struct passwd' has no member named 'pw_gecos' HDstrncpy(real_name, pwd->pw_gecos, n); ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:1257:41: note: in definition of macro 'HDstrncpy' #define HDstrncpy(X,Y,Z) strncpy(X,Y,Z) ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:197:27: error: 'struct passwd' has no member named 'pw_gecos' HDstrncpy(real_name, pwd->pw_gecos, sizeof(real_name)); ^ /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:1257:41: note: in definition of macro 'HDstrncpy' #define HDstrncpy(X,Y,Z) strncpy(X,Y,Z) ^ make[3]: *** [ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/H5make_libsettings.dir/H5make_libsettings.c.o] Error 1 make[2]: *** [ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/H5make_libsettings.dir/all] Error 2 make[1]: *** [Examples/Android/VolumeRender/CMakeFiles/VolumeRender-apk-debug.dir/rule] Error 2 make: *** [Examples/Android/VolumeRender/CMakeFiles/VolumeRender-apk-debug.dir/rule] Error 2 / I guess I'm not the only one to whom it's happening since I saw this post as well: http://www.vtk.org/pipermail/vtk-developers/2013-August/014195.html However, no solution is provided in this post. Would you happen to know what's responsible for that error and how I can fix it (or at the very least bypass it)? Thanks in advance -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481.html Sent from the VTK - Dev mailing list archive at Nabble.com. From berk.geveci at kitware.com Wed Feb 10 11:22:38 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Feb 2016 11:22:38 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <1455121149492-5736481.post@n5.nabble.com> References: <1455121149492-5736481.post@n5.nabble.com> Message-ID: Hi Lonni, Do you happen to have an HDF5 distribution on your default include path? I ran into this issue when I installed HDF5 through Homebrew on my Mac. I switched to using system HDF5 and NetCDF to avoid these errors. The problem is that VTK include certain include paths where external libraries reside, such as /usr/local/include, before it includes the internal HDF5 include path. So the HDF5 files in VTK end up being compiled with include files from the system. Best, -berk On Wed, Feb 10, 2016 at 11:19 AM, Lonni Besan?on wrote: > Hello everyone, > > I used to be able to build my android examples just fine. But since I > rebuilt vtk I seem to have a problem. > I get the following errors: > > /In file included from > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c: In > function 'print_header': > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:191:30: > error: 'struct passwd' has no member named 'pw_gecos' > if((comma = HDstrchr(pwd->pw_gecos, ','))) { > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:1224:37: note: in > definition of macro 'HDstrchr' > #define HDstrchr(S,C) strchr(S,C) > ^ > In file included from > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:192:56: > error: 'struct passwd' has no member named 'pw_gecos' > n = MIN(sizeof(real_name) - 1, (unsigned)(comma - pwd->pw_gecos)); > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:331:28: note: in > definition of macro 'MIN' > #define MIN(a,b) (((a)<(b)) ? (a) : (b)) > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:192:56: > error: 'struct passwd' has no member named 'pw_gecos' > n = MIN(sizeof(real_name) - 1, (unsigned)(comma - pwd->pw_gecos)); > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:331:41: note: in > definition of macro 'MIN' > #define MIN(a,b) (((a)<(b)) ? (a) : (b)) > ^ > In file included from > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:193:27: > error: 'struct passwd' has no member named 'pw_gecos' > HDstrncpy(real_name, pwd->pw_gecos, n); > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:1257:41: note: in > definition of macro 'HDstrncpy' > #define HDstrncpy(X,Y,Z) strncpy(X,Y,Z) > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:197:27: > error: 'struct passwd' has no member named 'pw_gecos' > HDstrncpy(real_name, pwd->pw_gecos, sizeof(real_name)); > ^ > /Users/user/VTK/ThirdParty/hdf5/vtkhdf5/src/H5private.h:1257:41: note: in > definition of macro 'HDstrncpy' > #define HDstrncpy(X,Y,Z) strncpy(X,Y,Z) > ^ > make[3]: *** > > [ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/H5make_libsettings.dir/H5make_libsettings.c.o] > Error 1 > make[2]: *** > [ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/H5make_libsettings.dir/all] Error 2 > make[1]: *** > [Examples/Android/VolumeRender/CMakeFiles/VolumeRender-apk-debug.dir/rule] > Error 2 > make: *** > [Examples/Android/VolumeRender/CMakeFiles/VolumeRender-apk-debug.dir/rule] > Error 2 > / > > I guess I'm not the only one to whom it's happening since I saw this post > as > well: http://www.vtk.org/pipermail/vtk-developers/2013-August/014195.html > > However, no solution is provided in this post. > > Would you happen to know what's responsible for that error and how I can > fix > it (or at the very least bypass it)? > > Thanks in advance > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Feb 10 11:24:59 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 10 Feb 2016 09:24:59 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <1455121149492-5736481.post@n5.nabble.com> Message-ID: <1455121499769-5736483.post@n5.nabble.com> No I don't think I do. I actually wanted to add the module NetCDF to my android application, but it did not occur to me that I had to install anything else. Do you reckon that's the source of the issue? -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736483.html Sent from the VTK - Dev mailing list archive at Nabble.com. From david.gobbi at gmail.com Wed Feb 10 11:28:55 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 09:28:55 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: Message-ID: I didn't intend to cause a ruckus with my original question, but this has been a good discussion :) I'll hopefully be merging the new (and, might I add, optional!) vtkSMPTools implementation of the vtk imaging pipeline soon so that people can try it out. Don't worry, the original implementation is still there. To echo Berk what said, the intent is to provide a clear path forward. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Feb 10 11:34:02 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 10 Feb 2016 09:34:02 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <1455121499769-5736483.post@n5.nabble.com> References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> Message-ID: <1455122042573-5736485.post@n5.nabble.com> I think you're right, that's definitely part of the problem. So what would be the step to either cancel the building of this ThirdParty Module, or solve the building problem? The problem arose when I added /-DModule_vtkIONetCDF:BOOL=ON/to my vtkAndroid.cmake. Thus, I tried simply removing it and building again, but I get the error nonetheless. I would actually like to be able to use and include vtkNetCDFReader.h, so if you could indicate the steps necessary that would be great. I'm using MAC OSX El capitan and trying to build for android. Thanks again for helping :) -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736485.html Sent from the VTK - Dev mailing list archive at Nabble.com. From berk.geveci at kitware.com Wed Feb 10 11:39:28 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Feb 2016 11:39:28 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <1455122042573-5736485.post@n5.nabble.com> References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> Message-ID: Now you are pushing the limits of my knowledge :-) I don't know anything about Android builds. I think you have a few options: * Remove the system HDF5 (and NetCDF if you have any). With Homebrew, you can do something like "brew unlink hdf5" & "brew unlink netcdf" * Build & install an Android version of HDF5 and NetCDF and turn on VTK_USE_SYSTEM_HDF5 and VTK_USE_SYSTEM_NETCDF. * Turn off NetCDF. Best, -berk On Wed, Feb 10, 2016 at 11:34 AM, Lonni Besan?on wrote: > I think you're right, that's definitely part of the problem. > So what would be the step to either cancel the building of this ThirdParty > Module, or solve the building problem? > > The problem arose when I added /-DModule_vtkIONetCDF:BOOL=ON/to my > vtkAndroid.cmake. > Thus, I tried simply removing it and building again, but I get the error > nonetheless. > > I would actually like to be able to use and include vtkNetCDFReader.h, so > if > you could indicate the steps necessary that would be great. I'm using MAC > OSX El capitan and trying to build for android. > > Thanks again for helping :) > > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736485.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Feb 10 11:42:08 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 10 Feb 2016 11:42:08 -0500 Subject: [vtk-developers] Remote Module Documentation Message-ID: Steve, I updated the remote module documentation. Let me know of it helps. Bill http://www.vtk.org/Wiki/VTK/Remote_Modules From ben.boeckel at kitware.com Wed Feb 10 11:55:11 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Feb 2016 11:55:11 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> Message-ID: <20160210165441.GB28233@megas.kitware.com> On Wed, Feb 10, 2016 at 11:39:28 -0500, Berk Geveci wrote: > Now you are pushing the limits of my knowledge :-) I don't know anything > about Android builds. I think you have a few options: > > * Remove the system HDF5 (and NetCDF if you have any). With Homebrew, you > can do something like "brew unlink hdf5" & "brew unlink netcdf" Android builds should not be using any system files at all; I really doubt Apple has started shipping them or that brew builds them :) . There are instructions for Android in the repo, but they may need some clarification of OS X. Ken? --Ben From prakeshofficial at gmail.com Wed Feb 10 11:59:07 2016 From: prakeshofficial at gmail.com (rakesh patil) Date: Wed, 10 Feb 2016 22:29:07 +0530 Subject: [vtk-developers] QVTKWidget + Dock/Undocking + MAC OS In-Reply-To: References: Message-ID: Hello, This issue is more of Qt related. I posted this question in their forum. But they redirected me to this forum. I am facing a very strange issue with Dock/Undocking when one of the docked widget is QVTKWidget, only on MAC. I have a centralWidget which contains four tabs. Each tab is an inherited from QWidget. Among these, one widget is QVTKWidget. The issue what I am facing is when I click on the bar and try to undock, the mouse events are lost. I release the mouse button and move the mouse, QVTKWidget keeps moving along with the mouse. I need to click once again on the tab and then it gets undocked fully. Some times while undocking or docking, I observed flickering effect on the renderwindow. It gives feeling like QDockWidget is passing some information/signal to its widgets, which QVTKWidget is not able to process, and other QWidgets are able to process. Has anyone come across this type of scenario? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Feb 10 12:33:40 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 Feb 2016 12:33:40 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <20160210165441.GB28233@megas.kitware.com> References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> Message-ID: Never looked at HDF5 on Android/iOS. Would be a nice fix if someone could update the cmake files to build it nicely there. Ken On Wed, Feb 10, 2016 at 11:55 AM, Ben Boeckel wrote: > On Wed, Feb 10, 2016 at 11:39:28 -0500, Berk Geveci wrote: > > Now you are pushing the limits of my knowledge :-) I don't know anything > > about Android builds. I think you have a few options: > > > > * Remove the system HDF5 (and NetCDF if you have any). With Homebrew, you > > can do something like "brew unlink hdf5" & "brew unlink netcdf" > > Android builds should not be using any system files at all; I really > doubt Apple has started shipping them or that brew builds them :) . > > There are instructions for Android in the repo, but they may need some > clarification of OS X. Ken? > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- 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: From arankin at robarts.ca Wed Feb 10 11:57:47 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 10 Feb 2016 16:57:47 +0000 Subject: [vtk-developers] Python wrapping of namespaces Message-ID: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> Hello all, I am a developer with the PLUS library, and we are having a discussion with regards to class name cleanup/unification. We brought up moving classes into a namespace, but wanted to keep the option of wrapping the library in Python. My colleague mentioned that vtk objects in namespaces were not wrappable in the past, and I was wondering if it is now possible to wrap namespaced classes in python? Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Feb 10 13:02:45 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 10 Feb 2016 13:02:45 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> Message-ID: It should still be possible to configure VTK with netcdf and without hdf5. That of course limits the types of netcdf files you can open (netcdf3 really) though. If that isn't important to you I recommend trying it. The advantage of doing so (or to use a system version if available) is to eliminate the cross-compilation hassles that hdf5 sometimes brings with it. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Feb 10, 2016 at 12:33 PM, Ken Martin wrote: > Never looked at HDF5 on Android/iOS. Would be a nice fix if someone could > update the cmake files to build it nicely there. > > Ken > > On Wed, Feb 10, 2016 at 11:55 AM, Ben Boeckel > wrote: > >> On Wed, Feb 10, 2016 at 11:39:28 -0500, Berk Geveci wrote: >> > Now you are pushing the limits of my knowledge :-) I don't know anything >> > about Android builds. I think you have a few options: >> > >> > * Remove the system HDF5 (and NetCDF if you have any). With Homebrew, >> you >> > can do something like "brew unlink hdf5" & "brew unlink netcdf" >> >> Android builds should not be using any system files at all; I really >> doubt Apple has started shipping them or that brew builds them :) . >> >> There are instructions for Android in the repo, but they may need some >> clarification of OS X. Ken? >> >> --Ben >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > -- > 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. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Feb 10 13:15:17 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 Feb 2016 13:15:17 -0500 Subject: [vtk-developers] Test failures on dash3 In-Reply-To: References: Message-ID: I'm honor bound to admit that this MR caused the issue: https://gitlab.kitware.com/vtk/vtk/merge_requests/992 On Tue, Feb 9, 2016 at 3:11 PM, Shawn Waldon wrote: > Hi all, > > The test vtkRenderingOpenGLCxx-TestWin32OpenGLRenderWindow has been > failing on dash3 for several weeks now. It seems to be leaking some VTK > objects [1]. Can someone take a look at this? > > Thanks, > Shawn > > [1]: https://open.cdash.org/testDetails.php?test=413527187&build=4228894 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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: From david.gobbi at gmail.com Wed Feb 10 13:16:33 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 11:16:33 -0700 Subject: [vtk-developers] Python wrapping of namespaces In-Reply-To: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> References: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> Message-ID: Hi Adam, So PLUS is being used at Robarts now! That's nice, big parts of PLUS were built on top of code that was originally developed at Robarts. Long live open source! The quick answer is, no, you cannot wrap classes within a namespace. The VTK python wrappers only allow namespaces to be used for enum constants. I started working on a solution to this back in 2013, it isn't an easy fix because all the work on the wrappers so far has assumed that everything exists in a single flat namespace. Now of course I would love to complete what I started, but like many of my free-time projects, I have no timeline for when it might be done. - David On Wed, Feb 10, 2016 at 9:57 AM, Adam Rankin wrote: > Hello all, > > > > I am a developer with the PLUS library, and we are having a discussion > with regards to class name cleanup/unification. We brought up moving > classes into a namespace, but wanted to keep the option of wrapping the > library in Python. > > > > My colleague mentioned that vtk objects in namespaces were not wrappable > in the past, and I was wondering if it is now possible to wrap namespaced > classes in python? > > > > Cheers, > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Feb 10 13:26:46 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 Feb 2016 13:26:46 -0500 Subject: [vtk-developers] VTKOpenGLExtensionManager in VTK 7.0? In-Reply-To: References: Message-ID: There is no direct replacement. You could try calling renWin.ReportCapabilities() and extract the pieces you need form it maybe. Thanks Ken On Tue, Feb 9, 2016 at 7:23 AM, Deepak Surti wrote: > Hi, > > vtkOpenGLExtensionManager is missing in VTK 7.0 with the default > VTK_RENDERING_BACKEND OpenGL2. > > With the old OpenGL Backend up to VTK 6.3, I did something like this to > get hold of the GL Driver, Renderer version etc. > > ``` > ren = vtk.vtkRenderer() > renWin = vtk.vtkRenderWindow() > renWin.AddRenderer(ren) > > # Now check the OpenGL metadata using the extension manager > em = vtk.vtkOpenGLExtensionManager() > em.SetRenderWindow(renWin) > renWin.Render() > em.Update() > > vtk_ver = vtk.vtkVersion().GetVTKVersion() > gl_driver = em.GetDriverGLVersion() > gl_renderer = em.GetDriverGLRenderer() > ``` > > What is the replacement for vtkOpenGLExtensionManager or with OpenGL2 > backend, how do I get the above information? > > Thanks, > Deepak > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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: From arankin at robarts.ca Wed Feb 10 14:27:22 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 10 Feb 2016 19:27:22 +0000 Subject: [vtk-developers] Python wrapping of namespaces In-Reply-To: References: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> Message-ID: Hi David, Yes! I was an employee of Gabor back in 2013 and got involved in the community that way. I then moved to Robarts and started a PhD under Terry. Thanks for the information. I like the idea of cleaning things up with a namespace, but we might want python wrapping in the future. Cheers, Adam From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Wednesday, February 10, 2016 1:17 PM To: Adam Rankin Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] Python wrapping of namespaces Hi Adam, So PLUS is being used at Robarts now! That's nice, big parts of PLUS were built on top of code that was originally developed at Robarts. Long live open source! The quick answer is, no, you cannot wrap classes within a namespace. The VTK python wrappers only allow namespaces to be used for enum constants. I started working on a solution to this back in 2013, it isn't an easy fix because all the work on the wrappers so far has assumed that everything exists in a single flat namespace. Now of course I would love to complete what I started, but like many of my free-time projects, I have no timeline for when it might be done. - David On Wed, Feb 10, 2016 at 9:57 AM, Adam Rankin > wrote: Hello all, I am a developer with the PLUS library, and we are having a discussion with regards to class name cleanup/unification. We brought up moving classes into a namespace, but wanted to keep the option of wrapping the library in Python. My colleague mentioned that vtk objects in namespaces were not wrappable in the past, and I was wondering if it is now possible to wrap namespaced classes in python? Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Wed Feb 10 14:36:00 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 10 Feb 2016 14:36:00 -0500 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: Message-ID: very very nice Bill, thanks On Wed, Feb 10, 2016 at 11:42 AM, Bill Lorensen wrote: > Steve, > > I updated the remote module documentation. Let me know of it helps. > > Bill > http://www.vtk.org/Wiki/VTK/Remote_Modules > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Wed Feb 10 14:47:50 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Wed, 10 Feb 2016 14:47:50 -0500 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: Message-ID: +100.. looks great On Wed, Feb 10, 2016 at 2:36 PM, Will Schroeder wrote: > very very nice Bill, thanks > > On Wed, Feb 10, 2016 at 11:42 AM, Bill Lorensen > wrote: > >> Steve, >> >> I updated the remote module documentation. Let me know of it helps. >> >> Bill >> http://www.vtk.org/Wiki/VTK/Remote_Modules >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Wed Feb 10 14:50:20 2016 From: pieper at isomics.com (Steve Pieper) Date: Wed, 10 Feb 2016 14:50:20 -0500 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: Message-ID: Hey Bill - Agreed, this is cool - it should work for a lot of cases. Not sure it exactly works for my use case though, which at least at first is to use this code in a Slicer extension. This means that it's a library that's built after the general purpose VTK is already built. Also because it's part of a Slicer extension there's a different directory layout (the actual C++ code is a couple directories below the top of the git repository). Plus there's other stuff in the CMakeLists.txt files (which might confuse the remote module build?). Is there a way to use the same code and same repository in both scenarios? Thanks, Steve On Wed, Feb 10, 2016 at 2:36 PM, Will Schroeder wrote: > very very nice Bill, thanks > > On Wed, Feb 10, 2016 at 11:42 AM, Bill Lorensen > wrote: > >> Steve, >> >> I updated the remote module documentation. Let me know of it helps. >> >> Bill >> http://www.vtk.org/Wiki/VTK/Remote_Modules >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Wed Feb 10 15:11:20 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 10 Feb 2016 20:11:20 +0000 Subject: [vtk-developers] Python wrapping of namespaces In-Reply-To: References: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> Message-ID: <9a5c138cab224fcf8825891dc7c37b5f@dag2.robarts.ca> Last but not least, is the prefix ?vtk? still required for classes that derive from a vtk class? Cheers, Adam From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Wednesday, February 10, 2016 1:17 PM To: Adam Rankin > Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] Python wrapping of namespaces Hi Adam, So PLUS is being used at Robarts now! That's nice, big parts of PLUS were built on top of code that was originally developed at Robarts. Long live open source! The quick answer is, no, you cannot wrap classes within a namespace. The VTK python wrappers only allow namespaces to be used for enum constants. I started working on a solution to this back in 2013, it isn't an easy fix because all the work on the wrappers so far has assumed that everything exists in a single flat namespace. Now of course I would love to complete what I started, but like many of my free-time projects, I have no timeline for when it might be done. - David On Wed, Feb 10, 2016 at 9:57 AM, Adam Rankin > wrote: Hello all, I am a developer with the PLUS library, and we are having a discussion with regards to class name cleanup/unification. We brought up moving classes into a namespace, but wanted to keep the option of wrapping the library in Python. My colleague mentioned that vtk objects in namespaces were not wrappable in the past, and I was wondering if it is now possible to wrap namespaced classes in python? Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Feb 10 15:11:26 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 13:11:26 -0700 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: Message-ID: Hi Steve, I'm in a similar situation, I have repositories that I want to turn into remote modules, but I also need to be able to build these modules outside of VTK. It's possible to do this (I know because I've done it) but it's messy. There doesn't seem to be a clean way to build proper VTK modules on top of an existing binary VTK. - David On Wed, Feb 10, 2016 at 12:50 PM, Steve Pieper wrote: > Hey Bill - > > Agreed, this is cool - it should work for a lot of cases. Not sure it > exactly works for my use case though, which at least at first is to use > this code in a Slicer extension. This means that it's a library that's > built after the general purpose VTK is already built. Also because it's > part of a Slicer extension there's a different directory layout (the actual > C++ code is a couple directories below the top of the git repository). > Plus there's other stuff in the CMakeLists.txt files (which might confuse > the remote module build?). Is there a way to use the same code and same > repository in both scenarios? > > Thanks, > Steve > > On Wed, Feb 10, 2016 at 2:36 PM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> very very nice Bill, thanks >> >> On Wed, Feb 10, 2016 at 11:42 AM, Bill Lorensen >> wrote: >> >>> Steve, >>> >>> I updated the remote module documentation. Let me know of it helps. >>> >>> Bill >>> http://www.vtk.org/Wiki/VTK/Remote_Modules >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Feb 10 15:19:01 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 13:19:01 -0700 Subject: [vtk-developers] Python wrapping of namespaces In-Reply-To: <9a5c138cab224fcf8825891dc7c37b5f@dag2.robarts.ca> References: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> <9a5c138cab224fcf8825891dc7c37b5f@dag2.robarts.ca> Message-ID: You mean wrt wrapping? Try it and see ;-) It might work, but then again, it might not. I advise that you keep the prefix. If your classes are a singular exceptional case that doesn't use the prefix, then you might be the one who has to do the maintenance :) - David On Wed, Feb 10, 2016 at 1:11 PM, Adam Rankin wrote: > Last but not least, is the prefix ?vtk? still required for classes that > derive from a vtk class? > > > > Cheers, > > Adam > > > > *From:* David Gobbi [mailto:david.gobbi at gmail.com ] > > *Sent:* Wednesday, February 10, 2016 1:17 PM > *To:* Adam Rankin > *Cc:* vtk-developers at vtk.org > *Subject:* Re: [vtk-developers] Python wrapping of namespaces > > > > Hi Adam, > > > > So PLUS is being used at Robarts now! That's nice, big parts of PLUS were > built on top of code that was originally developed at Robarts. Long live > open source! > > > > The quick answer is, no, you cannot wrap classes within a namespace. The > VTK python wrappers only allow namespaces to be used for enum constants. > > > > I started working on a solution to this back in 2013, it isn't an easy fix > because all the work on the wrappers so far has assumed that everything > exists in a single flat namespace. Now of course I would love to complete > what I started, but like many of my free-time projects, I have no timeline > for when it might be done. > > > > - David > > > > > > On Wed, Feb 10, 2016 at 9:57 AM, Adam Rankin wrote: > > Hello all, > > > > I am a developer with the PLUS library, and we are having a discussion > with regards to class name cleanup/unification. We brought up moving > classes into a namespace, but wanted to keep the option of wrapping the > library in Python. > > > > My colleague mentioned that vtk objects in namespaces were not wrappable > in the past, and I was wondering if it is now possible to wrap namespaced > classes in python? > > > > Cheers, > > Adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Feb 10 15:35:41 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Feb 2016 15:35:41 -0500 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: Message-ID: This would be a great thing to have. Is the issue on the CMake infrastructure side? On Wed, Feb 10, 2016 at 3:11 PM, David Gobbi wrote: > Hi Steve, > > I'm in a similar situation, I have repositories that I want to turn into > remote modules, but I also need to be able to build these modules outside > of VTK. It's possible to do this (I know because I've done it) but it's > messy. There doesn't seem to be a clean way to build proper VTK modules on > top of an existing binary VTK. > > - David > > > On Wed, Feb 10, 2016 at 12:50 PM, Steve Pieper wrote: > >> Hey Bill - >> >> Agreed, this is cool - it should work for a lot of cases. Not sure it >> exactly works for my use case though, which at least at first is to use >> this code in a Slicer extension. This means that it's a library that's >> built after the general purpose VTK is already built. Also because it's >> part of a Slicer extension there's a different directory layout (the actual >> C++ code is a couple directories below the top of the git repository). >> Plus there's other stuff in the CMakeLists.txt files (which might confuse >> the remote module build?). Is there a way to use the same code and same >> repository in both scenarios? >> >> Thanks, >> Steve >> >> On Wed, Feb 10, 2016 at 2:36 PM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> very very nice Bill, thanks >>> >>> On Wed, Feb 10, 2016 at 11:42 AM, Bill Lorensen >> > wrote: >>> >>>> Steve, >>>> >>>> I updated the remote module documentation. Let me know of it helps. >>>> >>>> Bill >>>> http://www.vtk.org/Wiki/VTK/Remote_Modules >>>> >>> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Wed Feb 10 15:39:53 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 10 Feb 2016 20:39:53 +0000 Subject: [vtk-developers] Python wrapping of namespaces In-Reply-To: References: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> <9a5c138cab224fcf8825891dc7c37b5f@dag2.robarts.ca>, Message-ID: <75be24ef-6619-4193-92e0-373e5d03362e@email.android.com> OK good to know. My question was meant as more broad in scope. Basically, what features depend on the vtk prefix? I am happy to rtfm if anyone would point me towards the relevant docs. Adam On Feb 10, 2016 3:19 PM, David Gobbi wrote: You mean wrt wrapping? Try it and see ;-) It might work, but then again, it might not. I advise that you keep the prefix. If your classes are a singular exceptional case that doesn't use the prefix, then you might be the one who has to do the maintenance :) - David On Wed, Feb 10, 2016 at 1:11 PM, Adam Rankin > wrote: Last but not least, is the prefix 'vtk' still required for classes that derive from a vtk class? Cheers, Adam From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Wednesday, February 10, 2016 1:17 PM To: Adam Rankin > Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] Python wrapping of namespaces Hi Adam, So PLUS is being used at Robarts now! That's nice, big parts of PLUS were built on top of code that was originally developed at Robarts. Long live open source! The quick answer is, no, you cannot wrap classes within a namespace. The VTK python wrappers only allow namespaces to be used for enum constants. I started working on a solution to this back in 2013, it isn't an easy fix because all the work on the wrappers so far has assumed that everything exists in a single flat namespace. Now of course I would love to complete what I started, but like many of my free-time projects, I have no timeline for when it might be done. - David On Wed, Feb 10, 2016 at 9:57 AM, Adam Rankin > wrote: Hello all, I am a developer with the PLUS library, and we are having a discussion with regards to class name cleanup/unification. We brought up moving classes into a namespace, but wanted to keep the option of wrapping the library in Python. My colleague mentioned that vtk objects in namespaces were not wrappable in the past, and I was wondering if it is now possible to wrap namespaced classes in python? Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Feb 10 15:50:54 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Feb 2016 15:50:54 -0500 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: Message-ID: <20160210205054.GA17082@megas.kitware.com> On Wed, Feb 10, 2016 at 15:35:41 -0500, Berk Geveci wrote: > This would be a great thing to have. Is the issue on the CMake > infrastructure side? Yeah. It's essentially the same problem ParaView has with an external VTK: VTK doesn't export all of its infrastructure macros properly (particularly testing and external data) in an install tree. There are probably other assumptions laying around that other projects trip up on (e.g., some setting VTK has which another project might want to change or the fact that VTK is built from within VTK's source tree). I don't know that an exhaustive (or comprehensive) list of issues exists. It will be something that will kept in mind when CMake 3 features are used in the module system. --Ben From david.gobbi at gmail.com Wed Feb 10 16:00:55 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 14:00:55 -0700 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: <20160210205054.GA17082@megas.kitware.com> References: <20160210205054.GA17082@megas.kitware.com> Message-ID: I was about to reply, but Ben's response is better than what I'd drafted. But that won't stop me from adding a couple more points: The module macros are not as well encapsulated as they could be (they require some undocumented cmake variables to be set). Also, in addition to the fact that all the macros themselves might not be exported yet, I don't know if all the necessary info for built modules is exported, either (especially for "install"). I hadn't even thought about CMake 3, but the extra properties will definitely be a huge help. - David On Wed, Feb 10, 2016 at 1:50 PM, Ben Boeckel wrote: > On Wed, Feb 10, 2016 at 15:35:41 -0500, Berk Geveci wrote: > > This would be a great thing to have. Is the issue on the CMake > > infrastructure side? > > Yeah. It's essentially the same problem ParaView has with an external > VTK: VTK doesn't export all of its infrastructure macros properly > (particularly testing and external data) in an install tree. There are > probably other assumptions laying around that other projects trip up on > (e.g., some setting VTK has which another project might want to change > or the fact that VTK is built from within VTK's source tree). I don't > know that an exhaustive (or comprehensive) list of issues exists. It > will be something that will kept in mind when CMake 3 features are used > in the module system. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Feb 10 16:15:55 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 10 Feb 2016 16:15:55 -0500 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: <20160210205054.GA17082@megas.kitware.com> Message-ID: The remote facility is very simple. Provide a foo.remote.cmake file and in your module create a module.cmake to specify your vtk dependencies. The docs assume you want to make a conventional vtk module,. But, your module can do anything it wants. For example in ITK, there are the Sphinx and ITK Wiki Examples. These both have non-standard directory structures. I am currently working on a remote module for the vtk wiki examples. These will be buildable as a remote module or stand-alone. It is not that difficult. Stay tuned... Bill On Wed, Feb 10, 2016 at 4:00 PM, David Gobbi wrote: > I was about to reply, but Ben's response is better than what I'd drafted. > But that won't stop me from adding a couple more points: > > The module macros are not as well encapsulated as they could be (they > require some undocumented cmake variables to be set). Also, in addition to > the fact that all the macros themselves might not be exported yet, I don't > know if all the necessary info for built modules is exported, either > (especially for "install"). > > I hadn't even thought about CMake 3, but the extra properties will > definitely be a huge help. > > - David > > > On Wed, Feb 10, 2016 at 1:50 PM, Ben Boeckel > wrote: >> >> On Wed, Feb 10, 2016 at 15:35:41 -0500, Berk Geveci wrote: >> > This would be a great thing to have. Is the issue on the CMake >> > infrastructure side? >> >> Yeah. It's essentially the same problem ParaView has with an external >> VTK: VTK doesn't export all of its infrastructure macros properly >> (particularly testing and external data) in an install tree. There are >> probably other assumptions laying around that other projects trip up on >> (e.g., some setting VTK has which another project might want to change >> or the fact that VTK is built from within VTK's source tree). I don't >> know that an exhaustive (or comprehensive) list of issues exists. It >> will be something that will kept in mind when CMake 3 features are used >> in the module system. >> >> --Ben > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Wed Feb 10 16:15:56 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 14:15:56 -0700 Subject: [vtk-developers] Python wrapping of namespaces In-Reply-To: <75be24ef-6619-4193-92e0-373e5d03362e@email.android.com> References: <494e1fb0ee0540308b20b3aaf1881d24@dag2.robarts.ca> <9a5c138cab224fcf8825891dc7c37b5f@dag2.robarts.ca> <75be24ef-6619-4193-92e0-373e5d03362e@email.android.com> Message-ID: TFM for the python wrappers is here, though I'm sure it doesn't have all the detail that you desire: https://raw.githubusercontent.com/Kitware/VTK/master/Wrapping/Python/README_WRAP.txt As much as we would love the wrapping to be perfect, it often depends on heuristics, fallbacks, and other messiness. We test many of the wrapper features insofar as they are needed to wrap VTK itself, so of course we advise people who want to use the wrappers on their code to keep their headers formatted much the same as VTK's own. - David On Wed, Feb 10, 2016 at 1:39 PM, Adam Rankin wrote: > OK good to know. > > My question was meant as more broad in scope. Basically, what features > depend on the vtk prefix? > > I am happy to rtfm if anyone would point me towards the relevant docs. > > Adam > On Feb 10, 2016 3:19 PM, David Gobbi wrote: > You mean wrt wrapping? Try it and see ;-) > > It might work, but then again, it might not. I advise that you keep the > prefix. If your classes are a singular exceptional case that doesn't use > the prefix, then you might be the one who has to do the maintenance :) > > - David > > > On Wed, Feb 10, 2016 at 1:11 PM, Adam Rankin wrote: > >> Last but not least, is the prefix ?vtk? still required for classes that >> derive from a vtk class? >> >> >> >> Cheers, >> >> Adam >> >> >> >> *From:* David Gobbi [mailto:david.gobbi at gmail.com ] >> >> *Sent:* Wednesday, February 10, 2016 1:17 PM >> *To:* Adam Rankin >> *Cc:* vtk-developers at vtk.org >> *Subject:* Re: [vtk-developers] Python wrapping of namespaces >> >> >> >> Hi Adam, >> >> >> >> So PLUS is being used at Robarts now! That's nice, big parts of PLUS >> were built on top of code that was originally developed at Robarts. Long >> live open source! >> >> >> >> The quick answer is, no, you cannot wrap classes within a namespace. The >> VTK python wrappers only allow namespaces to be used for enum constants. >> >> >> >> I started working on a solution to this back in 2013, it isn't an easy >> fix because all the work on the wrappers so far has assumed that everything >> exists in a single flat namespace. Now of course I would love to complete >> what I started, but like many of my free-time projects, I have no timeline >> for when it might be done. >> >> >> >> - David >> >> >> >> >> >> On Wed, Feb 10, 2016 at 9:57 AM, Adam Rankin wrote: >> >> Hello all, >> >> >> >> I am a developer with the PLUS library, and we are having a discussion >> with regards to class name cleanup/unification. We brought up moving >> classes into a namespace, but wanted to keep the option of wrapping the >> library in Python. >> >> >> >> My colleague mentioned that vtk objects in namespaces were not wrappable >> in the past, and I was wondering if it is now possible to wrap namespaced >> classes in python? >> >> >> >> Cheers, >> >> Adam >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Feb 10 16:18:19 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Feb 2016 14:18:19 -0700 Subject: [vtk-developers] Remote Module Documentation In-Reply-To: References: <20160210205054.GA17082@megas.kitware.com> Message-ID: Apologies, the last few messages in this thread had deviated away from remote modules into entirely different territory... On Wed, Feb 10, 2016 at 2:15 PM, Bill Lorensen wrote: > The remote facility is very simple. Provide a foo.remote.cmake file > and in your module create a module.cmake to specify your vtk > dependencies. The docs assume you want to make a conventional vtk > module,. But, your module can do anything it wants. > > For example in ITK, there are the Sphinx and ITK Wiki Examples. These > both have non-standard directory structures. > > I am currently working on a remote module for the vtk wiki examples. > These will be buildable as a remote module or stand-alone. It is not > that difficult. > > Stay tuned... > > Bill > > > On Wed, Feb 10, 2016 at 4:00 PM, David Gobbi > wrote: > > I was about to reply, but Ben's response is better than what I'd drafted. > > But that won't stop me from adding a couple more points: > > > > The module macros are not as well encapsulated as they could be (they > > require some undocumented cmake variables to be set). Also, in addition > to > > the fact that all the macros themselves might not be exported yet, I > don't > > know if all the necessary info for built modules is exported, either > > (especially for "install"). > > > > I hadn't even thought about CMake 3, but the extra properties will > > definitely be a huge help. > > > > - David > > > > > > On Wed, Feb 10, 2016 at 1:50 PM, Ben Boeckel > > wrote: > >> > >> On Wed, Feb 10, 2016 at 15:35:41 -0500, Berk Geveci wrote: > >> > This would be a great thing to have. Is the issue on the CMake > >> > infrastructure side? > >> > >> Yeah. It's essentially the same problem ParaView has with an external > >> VTK: VTK doesn't export all of its infrastructure macros properly > >> (particularly testing and external data) in an install tree. There are > >> probably other assumptions laying around that other projects trip up on > >> (e.g., some setting VTK has which another project might want to change > >> or the fact that VTK is built from within VTK's source tree). I don't > >> know that an exhaustive (or comprehensive) list of issues exists. It > >> will be something that will kept in mind when CMake 3 features are used > >> in the module system. > >> > >> --Ben > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Feb 10 17:15:01 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 10 Feb 2016 15:15:01 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> Message-ID: <1455142501968-5736521.post@n5.nabble.com> Thanks for all the useful help. I'll try to make to make android and hdf5 work together later on as I don't have much time to spend on it these days. I'll be happy to help if you guys investigate it as well. However, now that I'm trying to turn off NetCDF, I can't seem to find what I should do exactly. I removed the module from the vtkAndroid.make, I checked that VTK_USE_SYSTEM_HDF5 and VTK_USE_SYSTEM_NETCDF are off but I still get the same error message: [ 88%] Building C object /ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/H5make_libsettings.dir/H5make_libsettings.c.o In file included from /Users/lonnibesancon/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: /Users/.../VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c: In function 'print_header': /Users/.../VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:191:30: error: 'struct passwd' has no member named 'pw_gecos' if((comma = HDstrchr(pwd->pw_gecos, ','))) {/ (and so on) I'm afraid I don't know what I should do to get over this error. -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736521.html Sent from the VTK - Dev mailing list archive at Nabble.com. From andrew.amaclean at gmail.com Wed Feb 10 17:26:50 2016 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 11 Feb 2016 09:26:50 +1100 Subject: [vtk-developers] Remote Module Documentation Message-ID: "a remote module for the vtk wiki examples" - really looking forward to that Bill! This would be such a nice way to integrate the examples. > ---------- Forwarded message ---------- > From: Bill Lorensen > To: David Gobbi > Cc: VTK Developers , Steve Pieper < > pieper at isomics.com>, Berk Geveci > Date: Wed, 10 Feb 2016 16:15:55 -0500 > Subject: Re: [vtk-developers] Remote Module Documentation > The remote facility is very simple. Provide a foo.remote.cmake file > and in your module create a module.cmake to specify your vtk > dependencies. The docs assume you want to make a conventional vtk > module,. But, your module can do anything it wants. > > For example in ITK, there are the Sphinx and ITK Wiki Examples. These > both have non-standard directory structures. > > I am currently working on a remote module for the vtk wiki examples. > These will be buildable as a remote module or stand-alone. It is not > that difficult. > > Stay tuned... > > Bill > > > On Wed, Feb 10, 2016 at 4:00 PM, David Gobbi > wrote: > > I was about to reply, but Ben's response is better than what I'd drafted. > > But that won't stop me from adding a couple more points: > > > > The module macros are not as well encapsulated as they could be (they > > require some undocumented cmake variables to be set). Also, in addition > to > > the fact that all the macros themselves might not be exported yet, I > don't > > know if all the necessary info for built modules is exported, either > > (especially for "install"). > > > > I hadn't even thought about CMake 3, but the extra properties will > > definitely be a huge help. > > > > - David > > > > > > On Wed, Feb 10, 2016 at 1:50 PM, Ben Boeckel > > wrote: > >> > >> On Wed, Feb 10, 2016 at 15:35:41 -0500, Berk Geveci wrote: > >> > This would be a great thing to have. Is the issue on the CMake > >> > infrastructure side? > >> > >> Yeah. It's essentially the same problem ParaView has with an external > >> VTK: VTK doesn't export all of its infrastructure macros properly > >> (particularly testing and external data) in an install tree. There are > >> probably other assumptions laying around that other projects trip up on > >> (e.g., some setting VTK has which another project might want to change > >> or the fact that VTK is built from within VTK's source tree). I don't > >> know that an exhaustive (or comprehensive) list of issues exists. It > >> will be something that will kept in mind when CMake 3 features are used > >> in the module system. > >> > >> --Ben > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Wed Feb 10 17:35:04 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 10 Feb 2016 17:35:04 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <1455142501968-5736521.post@n5.nabble.com> References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> <1455142501968-5736521.post@n5.nabble.com> Message-ID: Hi, ITK has addressed cross-compiling in its internal HDF5 by using CMAKE_CROSSCOMPILING_EMULATOR [1]: https://github.com/InsightSoftwareConsortium/ITK/blob/1e99a5577559ba4db173bf6e9abc4bedc2c5ac06/Modules/ThirdParty/HDF5/src/itkhdf5/src/CMakeLists.txt#L575-L607 Since VTK does not use CMAKE_CROSSCOMPILING_EMULATOR (yet), this workaround will not work. The proper fix is to get upstream HDF5 to use a CMake try_run for currently tries to be achieved with H5detect and H5make_libsettings. HTH, Matt [1] https://cmake.org/cmake/help/v3.4/variable/CMAKE_CROSSCOMPILING_EMULATOR.html On Wed, Feb 10, 2016 at 5:15 PM, Lonni Besan?on wrote: > Thanks for all the useful help. > I'll try to make to make android and hdf5 work together later on as I don't > have much time to spend on it these days. I'll be happy to help if you guys > investigate it as well. > > However, now that I'm trying to turn off NetCDF, I can't seem to find what I > should do exactly. > I removed the module from the vtkAndroid.make, I checked that > VTK_USE_SYSTEM_HDF5 and VTK_USE_SYSTEM_NETCDF are off but I still get the > same error message: > [ 88%] Building C object > /ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/H5make_libsettings.dir/H5make_libsettings.c.o > In file included from > /Users/lonnibesancon/VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:46:0: > /Users/.../VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c: In function > 'print_header': > /Users/.../VTK/ThirdParty/hdf5/vtkhdf5/src/H5make_libsettings.c:191:30: > error: 'struct passwd' has no member named 'pw_gecos' > if((comma = HDstrchr(pwd->pw_gecos, ','))) {/ (and so on) > > I'm afraid I don't know what I should do to get over this error. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736521.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From lonni.besancon at gmail.com Wed Feb 10 17:37:47 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 10 Feb 2016 15:37:47 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> <1455142501968-5736521.post@n5.nabble.com> Message-ID: <1455143867910-5736524.post@n5.nabble.com> Thanks for the info, but I'm afraid this goes way beyond my skills. I'm going to leave this aside for now as it would be too time-consuming for me. I would very much like however to be able to revert back to a working android build that does not try to build HDF5. -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736524.html Sent from the VTK - Dev mailing list archive at Nabble.com. From dave.demarle at kitware.com Wed Feb 10 17:54:36 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 10 Feb 2016 17:54:36 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <1455143867910-5736524.post@n5.nabble.com> References: <1455121149492-5736481.post@n5.nabble.com> <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> <1455142501968-5736521.post@n5.nabble.com> <1455143867910-5736524.post@n5.nabble.com> Message-ID: if you look closely at the initial output from cmake you will see: -- * vtkhdf5, needed by 2 modules: vtkIOAMR vtknetcdf ok, lets see why those two are on: -- * vtknetcdf, needed by 5 modules: vtkIOMINC vtkIONetCDF vtkIOParallel vtkIOParallelNetCDF vtkexodusII It looks hard to disable netcdf, so instead see edit ThirdParty/netcdf/vtknetcdf/CMakeLists.txt to make sure USE_NETCDF4 stays OFF (line 235 and 237) -- * vtkIOAMR, needed by 6 modules: VTK_Group_StandAlone vtkFiltersAMR-Test-Cxx vtkFiltersAMR-Test-Python vtkIOAMR-Test-Cxx vtkIOGeometry-Test-Cxx vtkIOGeometry-Test-Python Turn off BUILD_TESTING will hit most of that. Then edit IO/AMR/module.cmake to take IO/AMR out of the StandAlone group. Then you'll get netcdf3 and not hdf5. Alternatively you might turn off all Groups and pick and choose just the modules you care about. hth David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Feb 10, 2016 at 5:37 PM, Lonni Besan?on wrote: > Thanks for the info, but I'm afraid this goes way beyond my skills. > > I'm going to leave this aside for now as it would be too time-consuming for > me. > I would very much like however to be able to revert back to a working > android build that does not try to build HDF5. > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736524.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Feb 10 18:05:44 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 10 Feb 2016 18:05:44 -0500 Subject: [vtk-developers] Windows Intel HD 2000 not working with new rendering backend Message-ID: Hi, I have a Windows 7 64 bit machine, glewinfo offers the following summary: GLEW version 1.13.0 Reporting capabilities of pixelformat 3 Running on a Intel(R) HD Graphics 2000 from Intel OpenGL version 3.1.0 - Build 9.17.10.3347 is supported In a new Tomviz build I see the following failure: ERROR: In C:\bbd\e04ad53c\build\paraview\src\paraview\VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, line 590 vtkWin32OpenGLRenderWindow (00000000029E7990): GL version 2.1 with the gpu_shader4 extension is not supported by your graphics driver but is required for the new OpenGL rendering backend. Please update your OpenGL driver. If you are using Mesa please make sure you have version 10.6.5 or later and make sure your driver in Mesa supports OpenGL 3.2. Is our effective minimum version for OpenGL 3.2 now? It looks like I have the latest drivers, and so I am guessing I would need to switch back to the old backend or buy a graphics card for the machine. The 3.2 section looks like this, >From an application development perspective, is there API that I could use to present a friendlier message to our users? Is 3.2 effectively the minimum, it looks like this card has everything up to 3.1 and then lacks several 3,2 features. From marcus.hanwell at kitware.com Wed Feb 10 18:08:54 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 10 Feb 2016 18:08:54 -0500 Subject: [vtk-developers] Windows Intel HD 2000 not working with new rendering backend In-Reply-To: References: Message-ID: On Wed, Feb 10, 2016 at 6:05 PM, Marcus D. Hanwell wrote: > Hi, > > I have a Windows 7 64 bit machine, glewinfo offers the following summary: > > GLEW version 1.13.0 > Reporting capabilities of pixelformat 3 > Running on a Intel(R) HD Graphics 2000 from Intel > OpenGL version 3.1.0 - Build 9.17.10.3347 is supported > > In a new Tomviz build I see the following failure: > > ERROR: In C:\bbd\e04ad53c\build\paraview\src\paraview\VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, > line 590 > > vtkWin32OpenGLRenderWindow (00000000029E7990): GL version 2.1 with the > gpu_shader4 extension is not supported by your graphics driver but is > required for the new OpenGL rendering backend. Please update your > OpenGL driver. If you are using Mesa please make sure you have version > 10.6.5 or later and make sure your driver in Mesa supports OpenGL 3.2. > > Is our effective minimum version for OpenGL 3.2 now? It looks like I > have the latest drivers, and so I am guessing I would need to switch > back to the old backend or buy a graphics card for the machine. The > 3.2 section looks like this, > GL_VERSION_3_2: MISSING --------------- glFramebufferTexture: OK glGetBufferParameteri64v: MISSING glGetInteger64i_v: MISSING > > From an application development perspective, is there API that I could > use to present a friendlier message to our users? Is 3.2 effectively > the minimum, it looks like this card has everything up to 3.1 and then > lacks several 3,2 features. Tomviz ultimately ends up segfaulting, I can add Qt code to detect 3.2 and fail if not available if that is effectively our minimum. It would be great to be able to support these cards, but if not possible I would like to offer a simpler error message without crashing. Thanks, Marcus From ken.martin at kitware.com Wed Feb 10 18:36:09 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 Feb 2016 18:36:09 -0500 Subject: [vtk-developers] Windows Intel HD 2000 not working with new rendering backend In-Reply-To: References: Message-ID: You can use renWin->SupportsOpenGL() to see if the system is supported. It tries to do this gracefully. The minimum requirement right now is OpenGL 2.1 with the shader4 extension. >From what I can see on the web intel HD 2000 should support that but clearly glew does not think so. Maybe the shader4 extension is not exposed on the 2.1 context? On Wed, Feb 10, 2016 at 6:08 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Wed, Feb 10, 2016 at 6:05 PM, Marcus D. Hanwell > wrote: > > Hi, > > > > I have a Windows 7 64 bit machine, glewinfo offers the following summary: > > > > GLEW version 1.13.0 > > Reporting capabilities of pixelformat 3 > > Running on a Intel(R) HD Graphics 2000 from Intel > > OpenGL version 3.1.0 - Build 9.17.10.3347 is supported > > > > In a new Tomviz build I see the following failure: > > > > ERROR: In > C:\bbd\e04ad53c\build\paraview\src\paraview\VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, > > line 590 > > > > vtkWin32OpenGLRenderWindow (00000000029E7990): GL version 2.1 with the > > gpu_shader4 extension is not supported by your graphics driver but is > > required for the new OpenGL rendering backend. Please update your > > OpenGL driver. If you are using Mesa please make sure you have version > > 10.6.5 or later and make sure your driver in Mesa supports OpenGL 3.2. > > > > Is our effective minimum version for OpenGL 3.2 now? It looks like I > > have the latest drivers, and so I am guessing I would need to switch > > back to the old backend or buy a graphics card for the machine. The > > 3.2 section looks like this, > > > GL_VERSION_3_2: MISSING > --------------- > glFramebufferTexture: OK > glGetBufferParameteri64v: MISSING > glGetInteger64i_v: MISSING > > > > From an application development perspective, is there API that I could > > use to present a friendlier message to our users? Is 3.2 effectively > > the minimum, it looks like this card has everything up to 3.1 and then > > lacks several 3,2 features. > > Tomviz ultimately ends up segfaulting, I can add Qt code to detect 3.2 > and fail if not available if that is effectively our minimum. It would > be great to be able to support these cards, but if not possible I > would like to offer a simpler error message without crashing. > > Thanks, > > Marcus > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- 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: From lonni.besancon at gmail.com Thu Feb 11 03:44:36 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 11 Feb 2016 01:44:36 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> <1455142501968-5736521.post@n5.nabble.com> <1455143867910-5736524.post@n5.nabble.com> Message-ID: <1455180276267-5736531.post@n5.nabble.com> Thanks for the tips David. I'll try in a few days when I have some more time available and let you know how it goes. BTW, I'm pretty sure that Paraview can read NetCDF files, but is it possible to convert these files afterwards (to a classical .vtk or .vtp file)? -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736531.html Sent from the VTK - Dev mailing list archive at Nabble.com. From dave.demarle at kitware.com Thu Feb 11 08:11:26 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 11 Feb 2016 08:11:26 -0500 Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: <1455180276267-5736531.post@n5.nabble.com> References: <1455121499769-5736483.post@n5.nabble.com> <1455122042573-5736485.post@n5.nabble.com> <20160210165441.GB28233@megas.kitware.com> <1455142501968-5736521.post@n5.nabble.com> <1455143867910-5736524.post@n5.nabble.com> <1455180276267-5736531.post@n5.nabble.com> Message-ID: "BTW, I'm pretty sure that Paraview can read NetCDF files, but is it possible to convert these files afterwards (to a classical .vtk or .vtp file)?" Depends on the contents of the net cdf file. In the general case no, but if it is a convention we know about (netcdf cf and a couple of others) them yes you can use Paraview to convert. On Feb 11, 2016 3:44 AM, "Lonni Besan?on" wrote: > Thanks for the tips David. I'll try in a few days when I have some more > time > available and let you know how it goes. > > BTW, I'm pretty sure that Paraview can read NetCDF files, but is it > possible > to convert these files afterwards (to a classical .vtk or .vtp file)? > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736531.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Thu Feb 11 08:27:01 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 11 Feb 2016 06:27:01 -0700 (MST) Subject: [vtk-developers] Compilation error hdf5 In-Reply-To: References: <20160210165441.GB28233@megas.kitware.com> <1455142501968-5736521.post@n5.nabble.com> <1455143867910-5736524.post@n5.nabble.com> <1455180276267-5736531.post@n5.nabble.com> Message-ID: <1E6F0DC7-817C-4333-9D76-813E1AB8C4E2@gmail.com> Thanks :) I?ll let you know if I manage to use your tips btw :) Best / Cordialement, Lonni Besan?on PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 Email: lonni.besancon at gmail.com Phone: +33689902815 WebPage: http://lonni.besancon.pagesperso-orange.fr LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > On 11 Feb 2016, at 14:11, David E DeMarle [via VTK] wrote: > > > "BTW, I'm pretty sure that Paraview can read NetCDF files, but is it possible > to convert these files afterwards (to a classical .vtk or .vtp file)?" > > Depends on the contents of the net cdf file. In the general case no, but if it is a convention we know about (netcdf cf and a couple of others) them yes you can use Paraview to convert. > On Feb 11, 2016 3:44 AM, "Lonni Besan?on" <[hidden email] > wrote: > Thanks for the tips David. I'll try in a few days when I have some more time > available and let you know how it goes. > > BTW, I'm pretty sure that Paraview can read NetCDF files, but is it possible > to convert these files afterwards (to a classical .vtk or .vtp file)? > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736531.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > If you reply to this email, your message will be added to the discussion below: > http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736532.html > To unsubscribe from Compilation error hdf5, click here . > NAML -- View this message in context: http://vtk.1045678.n5.nabble.com/Compilation-error-hdf5-tp5736481p5736534.html Sent from the VTK - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmsurti at gmail.com Thu Feb 11 09:06:05 2016 From: dmsurti at gmail.com (Deepak Surti) Date: Thu, 11 Feb 2016 19:36:05 +0530 Subject: [vtk-developers] VTKOpenGLExtensionManager in VTK 7.0? In-Reply-To: References: Message-ID: On Wed, Feb 10, 2016 at 11:56 PM, Ken Martin wrote: > You could try calling renWin.ReportCapabilities() and extract the pieces > you need form it maybe. > That works. Thanks Ken. Regards, Deepak > On Tue, Feb 9, 2016 at 7:23 AM, Deepak Surti wrote: > >> Hi, >> >> vtkOpenGLExtensionManager is missing in VTK 7.0 with the default >> VTK_RENDERING_BACKEND OpenGL2. >> >> With the old OpenGL Backend up to VTK 6.3, I did something like this to >> get hold of the GL Driver, Renderer version etc. >> >> ``` >> ren = vtk.vtkRenderer() >> renWin = vtk.vtkRenderWindow() >> renWin.AddRenderer(ren) >> >> # Now check the OpenGL metadata using the extension manager >> em = vtk.vtkOpenGLExtensionManager() >> em.SetRenderWindow(renWin) >> renWin.Render() >> em.Update() >> >> vtk_ver = vtk.vtkVersion().GetVTKVersion() >> gl_driver = em.GetDriverGLVersion() >> gl_renderer = em.GetDriverGLRenderer() >> ``` >> >> What is the replacement for vtkOpenGLExtensionManager or with OpenGL2 >> backend, how do I get the above information? >> >> Thanks, >> Deepak >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > 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. > -- http://deepaksurti.com To see a miracle, be the miracle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Feb 11 09:09:31 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 11 Feb 2016 09:09:31 -0500 Subject: [vtk-developers] Windows Intel HD 2000 not working with new rendering backend In-Reply-To: References: Message-ID: On Wed, Feb 10, 2016 at 6:36 PM, Ken Martin wrote: > You can use renWin->SupportsOpenGL() to see if the system is supported. It > tries to do this gracefully. > > The minimum requirement right now is OpenGL 2.1 with the shader4 extension. > From what I can see on the web intel HD 2000 should support that but clearly > glew does not think so. Maybe the shader4 extension is not exposed on the > 2.1 context? > I will investigate making the application fail more gracefully. The card seems to be conforming to what Intel stated - OpenGL 3.1. The VTK code is rejecting it, so I guess it is not exposed or not available. This is the on-die GPU with an i7 chip, it was working pretty well in previous tests but I guess we tightened up the feature checking. Marcus From ken.martin at kitware.com Thu Feb 11 09:46:18 2016 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 11 Feb 2016 09:46:18 -0500 Subject: [vtk-developers] Windows Intel HD 2000 not working with new rendering backend In-Reply-To: References: Message-ID: It could be that while the GPU supports gpu_shader4 maybe it doesn't expose that in a 2.1 context for some reason, only in a 3.1 context. Currently we - try for 3.2 context, if we get it we are good - otherwise try for a 2.1 context with the gpu_shader4 extension we could add a middle step where we try for a 3.1 context with gpu_shader4 if we found a system where that made a difference. Ken On Thu, Feb 11, 2016 at 9:09 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Wed, Feb 10, 2016 at 6:36 PM, Ken Martin > wrote: > > You can use renWin->SupportsOpenGL() to see if the system is supported. > It > > tries to do this gracefully. > > > > The minimum requirement right now is OpenGL 2.1 with the shader4 > extension. > > From what I can see on the web intel HD 2000 should support that but > clearly > > glew does not think so. Maybe the shader4 extension is not exposed on the > > 2.1 context? > > > I will investigate making the application fail more gracefully. The > card seems to be conforming to what Intel stated - OpenGL 3.1. The VTK > code is rejecting it, so I guess it is not exposed or not available. > This is the on-die GPU with an i7 chip, it was working pretty well in > previous tests but I guess we tightened up the feature checking. > > Marcus > -- 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: From marcus.hanwell at kitware.com Thu Feb 11 10:48:18 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 11 Feb 2016 10:48:18 -0500 Subject: [vtk-developers] Windows Intel HD 2000 not working with new rendering backend In-Reply-To: References: Message-ID: On Thu, Feb 11, 2016 at 9:46 AM, Ken Martin wrote: > It could be that while the GPU supports gpu_shader4 maybe it doesn't expose > that in a 2.1 context for some reason, only in a 3.1 context. Currently we > > - try for 3.2 context, if we get it we are good > > - otherwise try for a 2.1 context with the gpu_shader4 extension > > we could add a middle step where we try for a 3.1 context with gpu_shader4 > if we found a system where that made a difference. > That sounds like it would be worth trying, I can test a patch if you have one. Marcus From berk.geveci at kitware.com Fri Feb 12 10:18:56 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 12 Feb 2016 10:18:56 -0500 Subject: [vtk-developers] ANN: CFP - Eurographics 2016 Symposium on Parallel, Graphics and, Visualization (EGPGV 2016) Message-ID: [We apologize if you receive multiple copies of this message.] Eurographics 2016 Symposium on Parallel Graphics and Visualization (EGPGV 2016) ========================================================================= June 6-7, 2016, Groningen, the Netherlands Co-located with EuroVis 2016 www.egpgv.org Call for Papers ================ The importance of parallel computing is increasing rapidly with the ubiquitous availability of multi-core CPUs, GPUs, and cluster systems. Computationally demanding and data-intensive applications in graphics and visualization are strongly affected by this trend and require novel efficient parallel solutions. The aim of this symposium is to foster the exchange of experiences and knowledge exploiting and defining new trends in parallel graphics and visualization. The proceedings of the EGPGV Symposium will be published in the Eurographics Proceedings Series and in the Eurographics Digital Library. Best papers from the EGPGV symposium will be invited to submit an extended journal version to IEEE Transactions on Visualization and Computer Graphics. Focusing on parallel computing, the symposium seeks papers on graphics and visualization techniques, data structures, algorithms, and systems for: - large-data - clusters - (multi-)GPU computing, and heterogeneous, hybrid architectures - out-of-core - hybrid distributed and shared memory architectures - grid and cloud environments In particular the symposium topics include: - computationally and data intensive rendering - scientific visualization (volume rendering, flow and tensor visualization) - information visualization and visual analytics - simulations for virtual environments (physics-based animation, collision detection, acoustics) - mesh processing, level-of-detail, and geometric methods - visual computing (image- and video-based rendering, image processing and exploitation, segmentation) - scheduling, memory management and data coherence - large and high resolution displays, virtual environments - scientific, engineering, and industrial applications Important Dates ================= Paper Submission: February 19, 2016 Author Notification: April 1, 2016 Camera-Ready papers: April 15, 2016 Symposium: June 6-7, 2016 Submission instructions ======================== You are invited to submit original and unpublished research works. Full papers are expected to be eight to ten (8-10) pages in length, with the final length appropriate to the contribution of the paper. Submissions are to be formatted along the Eurographics paper publication guidelines. We expect that the submissions will clearly discuss the novel and significant contributions as well as related work in the field. Authors must highlight how their contributions differ and advance the state of the art in parallel graphics and visualization. The full paper and all supplementary material must be submitted via the PCS online system. Additional submission details will be announced shortly on egpgv.org. Symposium Chair ================= Alexandru Telea, University of Groningen, the Netherlands Program Chairs =============== Wes Bethel, Lawrence Berkeley National Laboratory, USA Enrico Gobbetti, CRS4, Italy Program Committee ================== Marco Ament, Karlsruhe Institute of Technology, Germany Ulf Assarsson, Chalmers University, Sweden Janine Bennett, SANDIA Labs, USA Hank Childs, Lawrence Berkeley National Laboratory, USA Kurt Debattista, University of Warwick, UK Stefan Eilemann, ?cole Polytechnique F?d?rale de Lausanne, Switzerland Elmar Eisemann, TU Delft, the Netherlands Kelly Gaither, University Texas/Austin, USA Christoph Garth, University of Kaiserslautern, Germany Berk Geveci, Kitware, USA Michael Guthe, University of Bayreuth, Germany Andrei Jalba, TU Eindhoven, the Netherlands Jens Kr?ger, University Duisburg-Essen, Germany Torsten Kuhlen, RWTH Aachen University, Germany Fabio Marton, CRS4, Italy Patrick McCormick, Los Alamos National Laboratory, USA Kenneth Moreland, Sandia National Laboratories, USA Renato Pajarola, University of Z?rich, Switzerland Bruno Raffin, INRIA Grenoble, France Filip Sadlo, University of Heidelberg, Germany Daniel Weiskopf, University of Stuttgart, Germany Michael Wimmer, Technische Universit?t Wien, Austria -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Feb 15 11:42:15 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 15 Feb 2016 09:42:15 -0700 Subject: [vtk-developers] Do any dashboards build VTK_Group_Tk? Message-ID: Tkinter is still the de-facto python GUI toolkit, but I notice that the official vtkpython binary package does not provide the vtkTkRenderWidget, and I'm not sure if any of the +python dashboard builds include it, either. Is anyone willing to turn on VTK_Group_Tk in their dashboard so that this code can be exercised? Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Feb 16 09:42:21 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 16 Feb 2016 09:42:21 -0500 Subject: [vtk-developers] Do any dashboards build VTK_Group_Tk? In-Reply-To: References: Message-ID: <20160216144221.GB27137@megas.kitware.com> On Mon, Feb 15, 2016 at 09:42:15 -0700, David Gobbi wrote: > Tkinter is still the de-facto python GUI toolkit, but I notice that the > official vtkpython binary package does not provide the vtkTkRenderWidget, > and I'm not sure if any of the +python dashboard builds include it, > either. Is anyone willing to turn on VTK_Group_Tk in their dashboard so > that this code can be exercised? The +tcl dashboards could also have a +tk feature to build. Should probably add some more +tcl dashboards anyways. Added issues to our buildbot repo. --Ben From prakeshofficial at gmail.com Tue Feb 16 11:32:30 2016 From: prakeshofficial at gmail.com (rakesh patil) Date: Tue, 16 Feb 2016 22:02:30 +0530 Subject: [vtk-developers] QVTKWidget + Dock/Undocking + MAC OS In-Reply-To: References: Message-ID: Hi, Since, I got no reply for this, I have prepared a small test case. It is a dock/undock example from Qt and I have just added QVTKWidget to it. Atleast the flickering should be disabled somehow. Can some experts help me? I am using Qt 5.5 and vtk 6.3. This happens only on MAC (tested on OS X Yosemite & OS X El Capitan). On Wed, Feb 10, 2016 at 10:29 PM, rakesh patil wrote: > > Hello, > > This issue is more of Qt related. I posted this question in their forum. > But they redirected me to this forum. I am facing a very strange issue with > Dock/Undocking when one of the docked widget is QVTKWidget, only on MAC. I > have a centralWidget which contains four tabs. Each tab is an inherited > from QWidget. Among these, one widget is QVTKWidget. The issue what I am > facing is when I click on the bar and try to undock, the mouse events are > lost. I release the mouse button and move the mouse, QVTKWidget keeps > moving along with the mouse. I need to click once again on the tab and then > it gets undocked fully. Some times while undocking or docking, I observed > flickering effect on the renderwindow. > > It gives feeling like QDockWidget is passing some information/signal to > its widgets, which QVTKWidget is not able to process, and other QWidgets > are able to process. Has anyone come across this type of scenario? > > Thanks in advance > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dock_qvtkwidget.zip Type: application/zip Size: 13951 bytes Desc: not available URL: From aashish.chaudhary at kitware.com Tue Feb 16 11:34:14 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 16 Feb 2016 11:34:14 -0500 Subject: [vtk-developers] [vtkusers] PROJ4 in VTK In-Reply-To: References: Message-ID: Hi all, As previously mentioned, Dan and I pushed VTK changes to update PROJ4 support in VTK to 4.9.2. Apart from major bug fixes, new API support, now you should be able to use EPSG codes as well. The branch in review is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/1207 Thanks, Aashish On Tue, Dec 8, 2015 at 12:36 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > On Tue, Dec 8, 2015 at 12:35 PM, David E DeMarle > wrote: > >> Branch is tomorrow. >> > > Great.. yes.. certainly we can wait that long (it may take atleast 1-2 > days anyways). > > Thanks, > > >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Tue, Dec 8, 2015 at 12:22 PM, Aashish Chaudhary < >> aashish.chaudhary at kitware.com> wrote: >> >>> >>> On Tue, Dec 8, 2015 at 12:15 PM, David E DeMarle < >>> dave.demarle at kitware.com> wrote: >>> >>>> If after 7.0 branch you've got my +1. >>>> >>> >>> Sure. When is 7.0? >>> >>>> >>>> When we do please do so via Ben's nifty new scripts that standardize >>>> and use best practices for TPL integration into VTK. >>>> >>> >>> I don't remember / know the script whereabouts. Can you send it to me >>> please? >>> >>> Thanks >>> >>> >>> >>>> >>>> >>>> David E DeMarle >>>> Kitware, Inc. >>>> R&D Engineer >>>> 21 Corporate Drive >>>> Clifton Park, NY 12065-8662 >>>> Phone: 518-881-4909 >>>> >>>> On Tue, Dec 8, 2015 at 11:54 AM, Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com> wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> The mangled PROJ4 in VTK is ancient and no longer supported by anyone >>>>> else. Also, it is buggy, since then PROJ4 has moved on fixing bugs and >>>>> changed the API a bit as well (includes the named EPSG codes). >>>>> >>>>> Are there any objections to switching to last release of PROJ4? We >>>>> need this sometime soon so if you have any feedback please send me/mailing >>>>> list an email. >>>>> >>>>> Thanks, >>>>> Aashish >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Feb 17 11:09:44 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 17 Feb 2016 11:09:44 -0500 Subject: [vtk-developers] Gesture events Message-ID: I have been working on adding gesture support to VTK off and on and I have some more changes I wanted to mention. Initially I had added support for multitouch into the RenderWindowInteractor allowing for multiple pointers and tracking multiple pointer locations. That seems to be working fine. The next step was to consider multitouch gestures such as pinch/rotate/pan that iOS and Android can generate. I wanted VTK to be capable of accepting lower level multitouch events and higher level gestures at the discretion of the application developer. I also wanted to have high level gestures (such as pinch) added to VTK because adding support for pinch in a widget is a lot easier than putting in the code to recognize and handle the pinch in the widget itself. So I have created a new topic https://gitlab.kitware.com/vtk/vtk/merge_requests/1221 that adds pinch/rotate/pan/tap/long tap/swipe gestures to VTK. You can invoke those gestures directly from your UI code or pass the low level touch events down to VTK's interactor. When passing the low level touch events the interactor will by default recognize the pinch/pan/rotate gestures for you and convert the touch events into gesture events. This way VTK Widgets and Interactor Styles can be modified to respond to gestures regardless of if the application chooses to send touch events or gestures. To test this out I created a new iOS example app called PlaneView that loads 3D data from your cloud drive and allows you to cut it with a probe filter. Hopefully I can get it on the app store for folks to try out, it is in review currently. (thanks to Steve Jordan for the icons :-) The example also shows how to register file types in iOS, add settings, and is a storyboard based app. One limitation of what I have put into VTK is that it only handles one gesture at a time. A lot of VTK's interaction code tends to be state based, you are rotating or you are zooming. We really do not have a notion of interaction being in multiple states at once. But iOS for example can have multiple gestures being recognized and handled at the same time if you enable that. Currently the code in VTK is designed to handle one gesture at a time. I'm not sure if we want to handle having a rotate gesture start while in the middle of a pinch gesture and try to have all the interactors/widgets handle those cases properly/etc. Thanks Ken -- 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: From ken.martin at kitware.com Wed Feb 17 15:19:28 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 17 Feb 2016 15:19:28 -0500 Subject: [vtk-developers] [EXTERNAL] Re: VTK OpenGL2 Shaders In-Reply-To: References: Message-ID: I took a quick stab at updating the first wiki link. Thanks! Ken On Fri, Feb 5, 2016 at 3:16 PM, Gerrick Bivins < Gerrick.Bivins at halliburton.com> wrote: > So are these not valid anymore? > > http://www.vtk.org/Wiki/Shader_In_VTK > > *http://www.vtk.org/Wiki/images/3/39/Vtk_shaders_tudelft_tut.pdf > * > > > > Or am I misunderstanding the question? > > Gerrick > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Ken Martin > *Sent:* Friday, February 05, 2016 12:21 PM > *To:* Aashish Chaudhary > *Cc:* VTK Developers; Steve Pieper > *Subject:* [EXTERNAL] Re: [vtk-developers] VTK OpenGL2 Shaders > > > > Here is some info from an old email on customizing the polydatamapper > shaders. The PointGaussianMapper also supports custom shaders and there is > an example of that in > Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx > > Thanks > > Ken > > > > 2) *CUSTOM SHADERS* - Added support for customizing the default > PolyDataMapper shaders. You can now modify or completely replace the > default VTK shadersusing methods such as > > > > AddShaderReplacement: replaces a strings in the current shader > SetVertexShaderCode: replaces the default shader template with your own > > AddObserver(vtkCommand::UpdateShaderEvent,...) > > > > These methods (and similar others) give you a great degree on control of > the VTK PolyData shaders. There are examples/tests in > Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. > Through the UpdateShaderEvent you can modify the default VTK uniforms or > your own uniforms as desired. There is currently not a general purpose easy > API for binding your own data arrays to attributes but we may add one at > some point in the future. Currently VTK will send down the default > attributes for you to use in your shader (position, normal, tcoords, > colors, etc) > > > > > > On Fri, Feb 5, 2016 at 12:11 PM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > > Not to my knowledge. Although we talked about it at-least having an API so > that folks can replace the shader or ember new shader code to the existing > one. Also, having some common convention would be nice. > > > > Thanks, > > > > > > > > > > On Fri, Feb 5, 2016 at 11:31 AM, Steve Pieper wrote: > > Hi Bill - > > > > Great question - I'm looking forward to hear what folks have been doing in > this respect. > > > > For me, I have two classes I have been testing with Slicer - one that > manages 3D textures and one that implements shaders [1,2]. We worked on it > at project week [3] and I'm liking how it works. > > > > -Steve > > > > [1] > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLTextureImage.h > > > > > [2] > https://github.com/pieper/CommonGL/blob/master/ShadedActor/Logic/vtkOpenGLShaderComputation.h > > > > > [3] > http://www.na-mic.org/Wiki/index.php/2016_Winter_Project_Week/Projects/CommonGL > > > > > On Fri, Feb 5, 2016 at 11:10 AM, Bill Lorensen > wrote: > > Folks, > > Is there documentation on how to write glsl shaders for VTK? > > Bill > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > _______________________________________________ > Powered by www.kitware.com > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. > * > > *| http://www.kitware.com/company/team/chaudhary.html > * > > > _______________________________________________ > Powered by www.kitware.com > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > -- > > 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: From lonni.besancon at gmail.com Thu Feb 18 08:15:51 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 18 Feb 2016 06:15:51 -0700 (MST) Subject: [vtk-developers] Gesture events In-Reply-To: References: Message-ID: <1455801351739-5736624.post@n5.nabble.com> Hi Ken, Great to read that you've been working on that, I have been modifying classes in android as well in order to kind of include gesture recognition. Wouldn't giving the possibility to recognise multiple gestures at a time better suit the needs of multitouch interaction (the RST technique is based on that principle right?). -- View this message in context: http://vtk.1045678.n5.nabble.com/Gesture-events-tp5736613p5736624.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Thu Feb 18 08:44:07 2016 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 18 Feb 2016 08:44:07 -0500 Subject: [vtk-developers] Gesture events In-Reply-To: <1455801351739-5736624.post@n5.nabble.com> References: <1455801351739-5736624.post@n5.nabble.com> Message-ID: You can send multiple gestures at once down to VTK and I'm pretty sure the multitouch camera style will handle them intermixed (it does not use state with the gestures). But if sending low level events VTK will only recognize one at a time. Most widgets in VTK store a state, that is where I believe multiple concurrent gestures will prove awkward. We could add a combined RST gesture event if we want that, so it would still be one gesture/state but it would support all three interactions at once. Thanks Ken On Thu, Feb 18, 2016 at 8:15 AM, Lonni Besan?on wrote: > Hi Ken, > > Great to read that you've been working on that, I have been modifying > classes in android as well in order to kind of include gesture recognition. > Wouldn't giving the possibility to recognise multiple gestures at a time > better suit the needs of multitouch interaction (the RST technique is based > on that principle right?). > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Gesture-events-tp5736613p5736624.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- 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: From lonni.besancon at gmail.com Thu Feb 18 08:49:27 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 18 Feb 2016 06:49:27 -0700 (MST) Subject: [vtk-developers] Gesture events In-Reply-To: References: <1455801351739-5736624.post@n5.nabble.com> Message-ID: <1455803367912-5736626.post@n5.nabble.com> Thanks for the reply and explanations. -- View this message in context: http://vtk.1045678.n5.nabble.com/Gesture-events-tp5736613p5736626.html Sent from the VTK - Dev mailing list archive at Nabble.com. From sean at rogue-research.com Fri Feb 19 08:36:49 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 19 Feb 2016 08:36:49 -0500 Subject: [vtk-developers] cppcheck of VTK now on dashboard In-Reply-To: <20151125220306.417462295@mail.rogue-research.com> References: <20151125220306.417462295@mail.rogue-research.com> Message-ID: <20160219133649.1163175988@mail.rogue-research.com> On Wed, 25 Nov 2015 17:03:06 -0500, Sean McBride said: >Thanks to my colleague Alex, we now have a nightly cppcheck static >analysis of VTK on the dashboard. ... and now it's green! Thanks to all, especially David Gobbi and Ben Boeckel, for helping me fix and review the various changes. I invite you all to keep an eye on this dashboard (down near the bottom near valgrind) and keep it green. :) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Fri Feb 19 12:08:15 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Feb 2016 12:08:15 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac Message-ID: Folks, I tried to build VTK on my Mac today with i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) My clang build is fine. I get these link errors: Linking C shared library ../../../../lib/libvtkproj4-7.1.dylib Undefined symbols for architecture x86_64: "_vtk_pj_acquire_lock", referenced from: _vtk_pj_get_default_ctx in pj_ctx.c.o _vtk_pj_ctx_alloc in pj_ctx.c.o _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o _vtk_pj_gridinfo_load in pj_gridinfo.c.o _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o ... "_vtk_pj_release_lock", referenced from: _vtk_pj_get_default_ctx in pj_ctx.c.o _vtk_pj_ctx_alloc in pj_ctx.c.o _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o _vtk_pj_gridinfo_load in pj_gridinfo.c.o _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o _vtk_pj_insert_initcache in pj_initcache.c.o _vtk_pj_clear_initcache in pj_initcache.c.o ... ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [lib/libvtkproj4-7.1.1.dylib] Error 1 -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Fri Feb 19 12:11:29 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 19 Feb 2016 12:11:29 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> Message-ID: <20160219171129.1266051426@mail.rogue-research.com> On Tue, 9 Feb 2016 14:55:37 -0500, Berk Geveci said: >A few comments: Just back from vacation, so I missed the latter half of this thread... >* The Simple backend of vtkSMPTools is only there for debugging. Helgrind >produces lots of false positives when using TBB so I developed the Simple >backend for use with Helgrind. It is not a production backend and pretty >much sucks. Now that we haven an OpenMP backend that can be used with >Helgrind, Simple must die. I don't see a reason to deprecate it first since >it is there only for debugging. This is clearly documented in the PDF will >pointed to. Out of curiosity, did you try Thread Sanitizer? Wouldn't keeping the Simple backend remain useful for debugging if these valuable tools (Hellgrind/TSan) don't work with the other backends? >* For compilers that do not support OpenMP 3.1, one can (and should) use >TBB. TBB is the better backend anyway so I recommend it over OpenMP. Although open source clang is getting up to speed with its OpenMP support, Apple's fork of clang (that comes with Xcode) doesn't support OpenMP at all. Of course, no one knows if it will be added or not. Given that Apple is more interested in GCD and Swift, they may decide the burden of supporting OpenMP is not worth it to them. >* We will not include TBB in VTK. It is an external dependency similarly to >OpenGL & MPI. In the future, folks will have to get it or have OpenMP if >they want any thread-level parallelism out of VTK. We need to discuss what >"in the future" means. Why not include it? How is it different from how VTK includes NetCDF, HDF5, zlib, libpng, and a zillion other 3rd party libs? With AppleClang not supporting OpenMP, and TBB not being included, it means VTK won't be buildable 'out of the box' on OS X anymore, if I understand all this correctly. That would be a shame. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Fri Feb 19 12:27:24 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 19 Feb 2016 10:27:24 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: <20160219171129.1266051426@mail.rogue-research.com> References: <20160209152847.2140519877@mail.rogue-research.com> <20160219171129.1266051426@mail.rogue-research.com> Message-ID: On Fri, Feb 19, 2016 at 10:11 AM, Sean McBride wrote: > > With AppleClang not supporting OpenMP, and TBB not being included, it > means VTK won't be buildable 'out of the box' on OS X anymore, if I > understand all this correctly. That would be a shame. VTK will still build out-of-the-box on OS X, because the Sequential backend will be used if neither OpenMP or TBB are available. In fact, this is the current situation in master and the dashboards are working fine. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Feb 19 12:32:18 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 19 Feb 2016 12:32:18 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> <20160219171129.1266051426@mail.rogue-research.com> Message-ID: <20160219173218.378773446@mail.rogue-research.com> On Fri, 19 Feb 2016 10:27:24 -0700, David Gobbi said: >> With AppleClang not supporting OpenMP, and TBB not being included, it >> means VTK won't be buildable 'out of the box' on OS X anymore, if I >> understand all this correctly. That would be a shame. > >VTK will still build out-of-the-box on OS X, because the Sequential backend >will be used if neither OpenMP or TBB are available. In fact, this is the >current situation in master and the dashboards are working fine. It's the single-thread backend, right? So when code that uses vtkMultiThreader is converted to this new scheme, 'out of the box' OS X builds will see massive performance regressions, right? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Fri Feb 19 12:43:39 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 19 Feb 2016 10:43:39 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: <20160219173218.378773446@mail.rogue-research.com> References: <20160209152847.2140519877@mail.rogue-research.com> <20160219171129.1266051426@mail.rogue-research.com> <20160219173218.378773446@mail.rogue-research.com> Message-ID: On Fri, Feb 19, 2016 at 10:32 AM, Sean McBride wrote: > > > It's the single-thread backend, right? > > So when code that uses vtkMultiThreader is converted to this new scheme, > 'out of the box' OS X builds will see massive performance regressions, > right? Yes. That's why, when we converted the vtkThreadedImageAlgorithm, we kept the vtkMultiThreader code path in place. And I'll fight tooth-and-nail to keep that code path maintained for as long as it's needed. But for the new parallel geometry filters, I agree that this will be a concern. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Feb 19 12:50:19 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 19 Feb 2016 10:50:19 -0700 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> <20160219171129.1266051426@mail.rogue-research.com> <20160219173218.378773446@mail.rogue-research.com> Message-ID: Actually, if OS X is focused on GCD, then I wonder how difficult it would be to make a GCD backend? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Feb 19 13:44:42 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 19 Feb 2016 11:44:42 -0700 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: Message-ID: Hi Bill, You can check to see if PROJ_USE_PTHREADS:BOOL=ON in your cache. I did a quick look through lib_proj.cmake and FindThreads.cmake and didn't see anything suspicious. No machines that I access have llvm-gcc anymore. - David On Fri, Feb 19, 2016 at 10:08 AM, Bill Lorensen wrote: > Folks, > > I tried to build VTK on my Mac today with > i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. > build 5658) (LLVM build 2336.1.00) > > My clang build is fine. > > I get these link errors: > Linking C shared library ../../../../lib/libvtkproj4-7.1.dylib > Undefined symbols for architecture x86_64: > "_vtk_pj_acquire_lock", referenced from: > _vtk_pj_get_default_ctx in pj_ctx.c.o > _vtk_pj_ctx_alloc in pj_ctx.c.o > _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o > _vtk_pj_gridinfo_load in pj_gridinfo.c.o > _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o > ... > "_vtk_pj_release_lock", referenced from: > _vtk_pj_get_default_ctx in pj_ctx.c.o > _vtk_pj_ctx_alloc in pj_ctx.c.o > _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o > _vtk_pj_gridinfo_load in pj_gridinfo.c.o > _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o > _vtk_pj_insert_initcache in pj_initcache.c.o > _vtk_pj_clear_initcache in pj_initcache.c.o > ... > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make[2]: *** [lib/libvtkproj4-7.1.1.dylib] Error 1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Feb 19 13:59:59 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Feb 2016 13:59:59 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: Message-ID: It was OFF, but turning it on does not help.I think it is an issue with my old gcc compiler. I'd still like to build VTK with it. On Fri, Feb 19, 2016 at 1:44 PM, David Gobbi wrote: > Hi Bill, > > You can check to see if PROJ_USE_PTHREADS:BOOL=ON in your cache. > I did a quick look through lib_proj.cmake and FindThreads.cmake and didn't > see anything suspicious. No machines that I access have llvm-gcc anymore. > > - David > > > On Fri, Feb 19, 2016 at 10:08 AM, Bill Lorensen > wrote: >> >> Folks, >> >> I tried to build VTK on my Mac today with >> i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. >> build 5658) (LLVM build 2336.1.00) >> >> My clang build is fine. >> >> I get these link errors: >> Linking C shared library ../../../../lib/libvtkproj4-7.1.dylib >> Undefined symbols for architecture x86_64: >> "_vtk_pj_acquire_lock", referenced from: >> _vtk_pj_get_default_ctx in pj_ctx.c.o >> _vtk_pj_ctx_alloc in pj_ctx.c.o >> _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o >> _vtk_pj_gridinfo_load in pj_gridinfo.c.o >> _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o >> ... >> "_vtk_pj_release_lock", referenced from: >> _vtk_pj_get_default_ctx in pj_ctx.c.o >> _vtk_pj_ctx_alloc in pj_ctx.c.o >> _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o >> _vtk_pj_gridinfo_load in pj_gridinfo.c.o >> _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o >> _vtk_pj_insert_initcache in pj_initcache.c.o >> _vtk_pj_clear_initcache in pj_initcache.c.o >> ... >> ld: symbol(s) not found for architecture x86_64 >> collect2: ld returned 1 exit status >> make[2]: *** [lib/libvtkproj4-7.1.1.dylib] Error 1 -- Unpaid intern in BillsBasement at noware dot com From dan.lipsa at kitware.com Fri Feb 19 14:01:25 2016 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 19 Feb 2016 14:01:25 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: Message-ID: Hi Bill, I will take a look at this. On Fri, Feb 19, 2016 at 1:59 PM, Bill Lorensen wrote: > It was OFF, but turning it on does not help.I think it is an issue > with my old gcc compiler. > > I'd still like to build VTK with it. > > > On Fri, Feb 19, 2016 at 1:44 PM, David Gobbi > wrote: > > Hi Bill, > > > > You can check to see if PROJ_USE_PTHREADS:BOOL=ON in your cache. > > I did a quick look through lib_proj.cmake and FindThreads.cmake and > didn't > > see anything suspicious. No machines that I access have llvm-gcc anymore. > > > > - David > > > > > > On Fri, Feb 19, 2016 at 10:08 AM, Bill Lorensen > > > wrote: > >> > >> Folks, > >> > >> I tried to build VTK on my Mac today with > >> i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. > >> build 5658) (LLVM build 2336.1.00) > >> > >> My clang build is fine. > >> > >> I get these link errors: > >> Linking C shared library ../../../../lib/libvtkproj4-7.1.dylib > >> Undefined symbols for architecture x86_64: > >> "_vtk_pj_acquire_lock", referenced from: > >> _vtk_pj_get_default_ctx in pj_ctx.c.o > >> _vtk_pj_ctx_alloc in pj_ctx.c.o > >> _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o > >> _vtk_pj_gridinfo_load in pj_gridinfo.c.o > >> _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o > >> ... > >> "_vtk_pj_release_lock", referenced from: > >> _vtk_pj_get_default_ctx in pj_ctx.c.o > >> _vtk_pj_ctx_alloc in pj_ctx.c.o > >> _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o > >> _vtk_pj_gridinfo_load in pj_gridinfo.c.o > >> _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o > >> _vtk_pj_insert_initcache in pj_initcache.c.o > >> _vtk_pj_clear_initcache in pj_initcache.c.o > >> ... > >> ld: symbol(s) not found for architecture x86_64 > >> collect2: ld returned 1 exit status > >> make[2]: *** [lib/libvtkproj4-7.1.1.dylib] Error 1 > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Fri Feb 19 15:48:41 2016 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 19 Feb 2016 15:48:41 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: Message-ID: Hi Bill, I don't have access to a machine with that configuration. Can you try dsymutil -s ./lib/libvtkproj4-7.1.dylib | grep acquire_lock It seems that this symbol should be defined as an empty function if PROJ_USE_PTHREADS:BOOL is off. Also it seems that mangling should happen correctly. On Fri, Feb 19, 2016 at 2:01 PM, Dan Lipsa wrote: > Hi Bill, > I will take a look at this. > > On Fri, Feb 19, 2016 at 1:59 PM, Bill Lorensen > wrote: > >> It was OFF, but turning it on does not help.I think it is an issue >> with my old gcc compiler. >> >> I'd still like to build VTK with it. >> >> >> On Fri, Feb 19, 2016 at 1:44 PM, David Gobbi >> wrote: >> > Hi Bill, >> > >> > You can check to see if PROJ_USE_PTHREADS:BOOL=ON in your cache. >> > I did a quick look through lib_proj.cmake and FindThreads.cmake and >> didn't >> > see anything suspicious. No machines that I access have llvm-gcc >> anymore. >> > >> > - David >> > >> > >> > On Fri, Feb 19, 2016 at 10:08 AM, Bill Lorensen < >> bill.lorensen at gmail.com> >> > wrote: >> >> >> >> Folks, >> >> >> >> I tried to build VTK on my Mac today with >> >> i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. >> >> build 5658) (LLVM build 2336.1.00) >> >> >> >> My clang build is fine. >> >> >> >> I get these link errors: >> >> Linking C shared library ../../../../lib/libvtkproj4-7.1.dylib >> >> Undefined symbols for architecture x86_64: >> >> "_vtk_pj_acquire_lock", referenced from: >> >> _vtk_pj_get_default_ctx in pj_ctx.c.o >> >> _vtk_pj_ctx_alloc in pj_ctx.c.o >> >> _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o >> >> _vtk_pj_gridinfo_load in pj_gridinfo.c.o >> >> _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o >> >> ... >> >> "_vtk_pj_release_lock", referenced from: >> >> _vtk_pj_get_default_ctx in pj_ctx.c.o >> >> _vtk_pj_ctx_alloc in pj_ctx.c.o >> >> _vtk_pj_gc_findcatalog in pj_gridcatalog.c.o >> >> _vtk_pj_gridinfo_load in pj_gridinfo.c.o >> >> _vtk_pj_gridlist_from_nadgrids in pj_gridlist.c.o >> >> _vtk_pj_insert_initcache in pj_initcache.c.o >> >> _vtk_pj_clear_initcache in pj_initcache.c.o >> >> ... >> >> ld: symbol(s) not found for architecture x86_64 >> >> collect2: ld returned 1 exit status >> >> make[2]: *** [lib/libvtkproj4-7.1.1.dylib] Error 1 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Feb 19 16:43:08 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 19 Feb 2016 16:43:08 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: Message-ID: <20160219214308.521629901@mail.rogue-research.com> On Fri, 19 Feb 2016 13:59:59 -0500, Bill Lorensen said: >It was OFF, but turning it on does not help.I think it is an issue >with my old gcc compiler. Sorry to be a pedant, but it's not gcc, it's llvm-gcc. :) A Frankenstein of the gcc frontend and the LLVM backend, created as a hack before clang supported C++. It was discontinued years ago. >I'd still like to build VTK with it. I'm curious: why? What version of Xcode are you using? It probably has clang also. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.thompson at kitware.com Fri Feb 19 16:44:22 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 19 Feb 2016 16:44:22 -0500 Subject: [vtk-developers] Glyph mapper bug Message-ID: Hi all, I've run into an issue with the Glyph3DMapper when using multiple sources; it looks like the *source-index array* is being normalized using the *scaling array's* range: index = static_cast((value-this->Range[0])*numberOfSources/den); Both Range[0] and den refer to the values used for scaling glyphs, not choosing a glyph source. Both the OpenGL and OpenGL2 mappers appear to do this: https://gitlab.kitware.com/vtk/vtk/blob/master/Rendering/OpenGL/vtkOpenGLGlyph3DMapper.cxx#L492 https://gitlab.kitware.com/vtk/vtk/blob/master/Rendering/OpenGL2/vtkOpenGLGlyph3DMapper.cxx#L483 I assume this is a bug and that the mappers should either 1. not do any normalization... just round and clamp the index array values or 2. normalize using the range of the index array instead of the scaling array. 3. be properly documented if no scaling is allowed in multi-source mode. Any preferences? I think #1 makes the most sense; it's faster and if you really need to preprocess the array, there's always the calculator filter. David From bill.lorensen at gmail.com Fri Feb 19 16:47:09 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Feb 2016 16:47:09 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: <20160219214308.521629901@mail.rogue-research.com> References: <20160219214308.521629901@mail.rogue-research.com> Message-ID: Why not? On Fri, Feb 19, 2016 at 4:43 PM, Sean McBride wrote: > On Fri, 19 Feb 2016 13:59:59 -0500, Bill Lorensen said: > >>It was OFF, but turning it on does not help.I think it is an issue >>with my old gcc compiler. > > Sorry to be a pedant, but it's not gcc, it's llvm-gcc. :) A Frankenstein of the gcc frontend and the LLVM backend, created as a hack before clang supported C++. It was discontinued years ago. > >>I'd still like to build VTK with it. > > I'm curious: why? > > What version of Xcode are you using? It probably has clang also. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Fri Feb 19 16:52:03 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 19 Feb 2016 16:52:03 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: <20160219214308.521629901@mail.rogue-research.com> Message-ID: <20160219215203.1061857302@mail.rogue-research.com> On Fri, 19 Feb 2016 16:47:09 -0500, Bill Lorensen said: >Why not? I wasn't trying to be flippant BTW :), I'm just curious what your use case is that you'd prefer that compiler over others. Over the years Xcode has included gcc, llvm-gcc, and clang; older versions only gcc, middle versions all three, and newer versions only clang. But to answer your question: because it was a big hack, because it's discontinued, because it's old, and because it doesn't support modern C++. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Fri Feb 19 16:58:03 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Feb 2016 16:58:03 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: <20160219215203.1061857302@mail.rogue-research.com> References: <20160219214308.521629901@mail.rogue-research.com> <20160219215203.1061857302@mail.rogue-research.com> Message-ID: My vtk compiled a few days ago. Now it doesn't. I don't look forward to upgrading the os. I'm not sure I have enough disk space. Also I'm not sure what issues I'll have with my other projects. Itk , slicer On Feb 19, 2016 4:52 PM, "Sean McBride" wrote: > On Fri, 19 Feb 2016 16:47:09 -0500, Bill Lorensen said: > > >Why not? > > I wasn't trying to be flippant BTW :), I'm just curious what your use case > is that you'd prefer that compiler over others. Over the years Xcode has > included gcc, llvm-gcc, and clang; older versions only gcc, middle versions > all three, and newer versions only clang. > > But to answer your question: because it was a big hack, because it's > discontinued, because it's old, and because it doesn't support modern C++. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Feb 19 17:00:17 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 19 Feb 2016 17:00:17 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: References: <20160219214308.521629901@mail.rogue-research.com> <20160219215203.1061857302@mail.rogue-research.com> Message-ID: <20160219220017.1559445344@mail.rogue-research.com> On Fri, 19 Feb 2016 16:58:03 -0500, Bill Lorensen said: >My vtk compiled a few days ago. Now it doesn't. And I'm not arguing that finding/fixing your issue shouldn't be done. >I don't look forward to upgrading the os. You might not need to. As I said, your Xcode probably has clang already. What Xcode and OS are you using? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Fri Feb 19 17:29:45 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Feb 2016 17:29:45 -0500 Subject: [vtk-developers] libvtkproj4 problems with gcc on Mac In-Reply-To: <20160219220017.1559445344@mail.rogue-research.com> References: <20160219214308.521629901@mail.rogue-research.com> <20160219215203.1061857302@mail.rogue-research.com> <20160219220017.1559445344@mail.rogue-research.com> Message-ID: Clang works fine. Maybe I should abandon gcc. On Feb 19, 2016 5:00 PM, "Sean McBride" wrote: > On Fri, 19 Feb 2016 16:58:03 -0500, Bill Lorensen said: > > >My vtk compiled a few days ago. Now it doesn't. > > And I'm not arguing that finding/fixing your issue shouldn't be done. > > >I don't look forward to upgrading the os. > > You might not need to. As I said, your Xcode probably has clang already. > What Xcode and OS are you using? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Feb 20 11:15:01 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 20 Feb 2016 11:15:01 -0500 Subject: [vtk-developers] Strange dashboard response Message-ID: Folks, When I try to connect to any if the vtk/tk dashboards my browser reports: Potential DNS rebind attack. The message points me to: https://en.wikipedia.org/wiki/DNS_rebinding Doesn't sound good... -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Sat Feb 20 11:59:39 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 20 Feb 2016 11:59:39 -0500 Subject: [vtk-developers] Strange dashboard response In-Reply-To: References: Message-ID: It's OK now. Not sure what was going on... On Sat, Feb 20, 2016 at 11:15 AM, Bill Lorensen wrote: > Folks, > > When I try to connect to any if the vtk/tk dashboards my browser reports: > > Potential DNS rebind attack. > The message points me to: > https://en.wikipedia.org/wiki/DNS_rebinding > > Doesn't sound good... > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Sat Feb 20 12:32:26 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sat, 20 Feb 2016 12:32:26 -0500 Subject: [vtk-developers] Strange dashboard response In-Reply-To: References: Message-ID: The sysadmins are doing some network updates here. Random network issues are expected throughout the day. Utkarsh On Sat, Feb 20, 2016 at 11:59 AM, Bill Lorensen wrote: > It's OK now. Not sure what was going on... > > > On Sat, Feb 20, 2016 at 11:15 AM, Bill Lorensen wrote: >> Folks, >> >> When I try to connect to any if the vtk/tk dashboards my browser reports: >> >> Potential DNS rebind attack. >> The message points me to: >> https://en.wikipedia.org/wiki/DNS_rebinding >> >> Doesn't sound good... >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From bill.lorensen at gmail.com Sat Feb 20 13:14:50 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 20 Feb 2016 13:14:50 -0500 Subject: [vtk-developers] Strange dashboard response In-Reply-To: References: Message-ID: Thanks On Sat, Feb 20, 2016 at 12:32 PM, Utkarsh Ayachit wrote: > The sysadmins are doing some network updates here. Random network > issues are expected throughout the day. > > Utkarsh > > On Sat, Feb 20, 2016 at 11:59 AM, Bill Lorensen wrote: >> It's OK now. Not sure what was going on... >> >> >> On Sat, Feb 20, 2016 at 11:15 AM, Bill Lorensen wrote: >>> Folks, >>> >>> When I try to connect to any if the vtk/tk dashboards my browser reports: >>> >>> Potential DNS rebind attack. >>> The message points me to: >>> https://en.wikipedia.org/wiki/DNS_rebinding >>> >>> Doesn't sound good... >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Mon Feb 22 08:26:12 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 22 Feb 2016 08:26:12 -0500 Subject: [vtk-developers] dashboards Message-ID: Apologies if these are already fixed but it looks like 1) there are some tests failing due to changes in scalar bar 2) agora system looks to be trashed for some reason (nightly reboot and tmp clear?) 3) Tarvalon looks to have corrupt files or something similar -- 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: From mathieu.westphal at kitware.com Mon Feb 22 09:00:59 2016 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 22 Feb 2016 15:00:59 +0100 Subject: [vtk-developers] dashboards In-Reply-To: References: Message-ID: I'm responsible of the scalar bar changes, i will correct it. Mathieu Westphal On Mon, Feb 22, 2016 at 2:26 PM, Ken Martin wrote: > Apologies if these are already fixed but it looks like > > 1) there are some tests failing due to changes in scalar bar > > 2) agora system looks to be trashed for some reason (nightly reboot and > tmp clear?) > > 3) Tarvalon looks to have corrupt files or something similar > > > > > > > > -- > 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. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Mon Feb 22 11:25:07 2016 From: arankin at robarts.ca (Adam Rankin) Date: Mon, 22 Feb 2016 16:25:07 +0000 Subject: [vtk-developers] "Correct" way to wrap vtk downstream project Message-ID: Hello all, I have modified our lab's library to use the VTK module system (wow, very nice!) and am attempting to determine the "correct" way to wrap the modules in python. I see that VTK uses /Wrapping/Python as its launch point, but I cannot call that from my project because of the python executable and vtk specific file entries (CMakeLists.txt:157-277 except 260-267). Aside from duplicating this folder from VTK and tweaking it to my setup, is there a clean way to perform CMake commands to python wrap my modules? I have included a sample module CMakeLists.txt and module.cmake file so you can hopefully understand what I've done. Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: module.cmake Type: application/octet-stream Size: 165 bytes Desc: module.cmake URL: From berk.geveci at kitware.com Mon Feb 22 11:25:37 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 22 Feb 2016 11:25:37 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> <20160219171129.1266051426@mail.rogue-research.com> <20160219173218.378773446@mail.rogue-research.com> Message-ID: David beat me to the punch :-) I expect that Apple with support OpenMP in the next year or two, at least on the desktop. GCD does not handle SIMD (vector instructions) and AFAIK the only other way Clang supports SIMD is through auto-vectorization, which is limited. I don't see them supporting only SIMD so I would guess that they will pull the whole OpenMP support. However, if they don't, we can write a GCD backend. I have played with it a bit in the past. The issue I ran into was that their abstraction makes developing a thread local storage implementation somewhat tricky. > Why not include it? How is it different from how VTK includes NetCDF, HDF5, zlib, libpng, and a zillion other 3rd party libs? Good question. I don't know how/where we draw the line with these. OpenGL & MPI are external dependencies whereas the ones you listed are included as third party. I have a few reasons why I wouldn't want to include it: * TBB license language may scare off some people as demonstrated by this thread. Although the license is totally fine, I'd rather avoid answering questions about the TBB license from those that do a license check in VTK. * TBB is a fairly complex beast because of platforms/compilers it supports (at fairly low level) and I'd rather avoid writing CMake files & maintaining them I don't have any strong attachment to this view however. > Out of curiosity, did you try Thread Sanitizer? Nope. We should probably try it sometime soon. Best, -berk On Fri, Feb 19, 2016 at 12:50 PM, David Gobbi wrote: > Actually, if OS X is focused on GCD, then I wonder how difficult it would > be to make a GCD backend? > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Feb 22 11:41:23 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 22 Feb 2016 09:41:23 -0700 Subject: [vtk-developers] "Correct" way to wrap vtk downstream project In-Reply-To: References: Message-ID: Hi Adam, At the moment, the only clean way to wrap a module is to build it as a remote module, which builds it within the VTK tree. The wiki page for remote modules is here: http://www.vtk.org/Wiki/VTK/Remote_Modules It is possible to wrap code outside of the VTK tree, but it can be messy. For example, here is the CMakeLists.txt for one of my projects that provides Python, Tcl, and Java wrapping: https://github.com/dgobbi/vtk-dicom/blob/master/Source/CMakeLists.txt - David On Mon, Feb 22, 2016 at 9:25 AM, Adam Rankin wrote: > Hello all, > > > > I have modified our lab?s library to use the VTK module system (wow, very > nice!) and am attempting to determine the ?correct? way to wrap the modules > in python. > > > > I see that VTK uses /Wrapping/Python as its launch point, but I cannot > call that from my project because of the python executable and vtk specific > file entries (CMakeLists.txt:157-277 except 260-267). > > > > Aside from duplicating this folder from VTK and tweaking it to my setup, > is there a clean way to perform CMake commands to python wrap my modules? > > > > I have included a sample module CMakeLists.txt and module.cmake file so > you can hopefully understand what I?ve done. > > > > Cheers, > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arankin at robarts.ca Mon Feb 22 11:48:21 2016 From: arankin at robarts.ca (Adam Rankin) Date: Mon, 22 Feb 2016 16:48:21 +0000 Subject: [vtk-developers] "Correct" way to wrap vtk downstream project In-Reply-To: References: Message-ID: Hi David, Thanks, exactly the info I was looking for. Adam From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Monday, February 22, 2016 11:41 AM To: Adam Rankin Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] "Correct" way to wrap vtk downstream project Hi Adam, At the moment, the only clean way to wrap a module is to build it as a remote module, which builds it within the VTK tree. The wiki page for remote modules is here: http://www.vtk.org/Wiki/VTK/Remote_Modules It is possible to wrap code outside of the VTK tree, but it can be messy. For example, here is the CMakeLists.txt for one of my projects that provides Python, Tcl, and Java wrapping: https://github.com/dgobbi/vtk-dicom/blob/master/Source/CMakeLists.txt - David On Mon, Feb 22, 2016 at 9:25 AM, Adam Rankin > wrote: Hello all, I have modified our lab?s library to use the VTK module system (wow, very nice!) and am attempting to determine the ?correct? way to wrap the modules in python. I see that VTK uses /Wrapping/Python as its launch point, but I cannot call that from my project because of the python executable and vtk specific file entries (CMakeLists.txt:157-277 except 260-267). Aside from duplicating this folder from VTK and tweaking it to my setup, is there a clean way to perform CMake commands to python wrap my modules? I have included a sample module CMakeLists.txt and module.cmake file so you can hopefully understand what I?ve done. Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Feb 22 16:12:33 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 22 Feb 2016 16:12:33 -0500 Subject: [vtk-developers] Wiki Examples Remote Module dashboard submission Message-ID: Folks, I have started submitting nightly dashboards for the Wiki Examples Remote Module. The machine is BillsUbuntu. I would like to see a new VTK category called: Expected Nightly Remote Modules This is what we do for ITK. We try to have at least one build for each remote module that is described in VTK/Remote. The name of the category is negotiable. Bill -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Tue Feb 23 09:29:51 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 23 Feb 2016 07:29:51 -0700 Subject: [vtk-developers] CDash refusing submissions this morning? Message-ID: Submit files (using http) Send to track: merge-requests Using HTTP submit method Drop site:http://open.cdash.org/submit.php?project=VTK Error when uploading file: /Users/kitware/buildbot-slave/vtk-bigmac-osx-shared-debug_clang_opengl1_python/build/Testing/20160223-1419/Notes.xml Error message was: The requested URL returned error: 417 Expectation Failed Problems when submitting via HTTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Feb 23 09:41:35 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 23 Feb 2016 09:41:35 -0500 Subject: [vtk-developers] CDash refusing submissions this morning? In-Reply-To: References: Message-ID: Yes, that's been happening since yesterday and the sysadmins have been notified. We should have a fix soon, hopefully. Utkarsh On Tue, Feb 23, 2016 at 9:29 AM, David Gobbi wrote: > Submit files (using http) > Send to track: merge-requests > Using HTTP submit method > Drop site:http://open.cdash.org/submit.php?project=VTK > Error when uploading file: > /Users/kitware/buildbot-slave/vtk-bigmac-osx-shared-debug_clang_opengl1_python/build/Testing/20160223-1419/Notes.xml > Error message was: The requested URL returned error: 417 Expectation > Failed > Problems when submitting via HTTP > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From aashish.chaudhary at kitware.com Tue Feb 23 11:43:45 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 23 Feb 2016 11:43:45 -0500 Subject: [vtk-developers] Volume rendering update Message-ID: Hi all, We have made some significant improvements to volume rendering since our last update (Ref: https://blog.kitware.com/volume-rendering-enhancements-in-vtk/, https://blog.kitware.com/volume-rendering-on-ios-and-android/). Below is a list of tasks that are either nearly completed and or are in VTK master as of today. - Features/updates - Big volume support - Fixing failing tests. The idea is to split volume into smaller volumes and render them piecewise. - 3x-5x clipping plane performance - For the same parameters, clipping is much faster now, the trick is to skip voxels that are clipped by planes. - Depth and color data capture - User can use RenderToImage to render to a FBO and get depth and color texture which then could be utilized for other operations. - Bugs - Fixed gradient opacity not working for more than one components - Fixed clipping plane location is wrong in certain cases. - Fixed volume rendering invalid or bad for cell data - Fixed edges issue when rendering in multiple pieces (hard edges) - Fixed volume rendering not working in remote rendering mode with image reduction factor > 1 - Fixed volume rendering not working in client-server mode - Fixed volume disappears when changing parameters - Fixed volume rendering not using the correct sampling distance -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Tue Feb 23 16:09:02 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 23 Feb 2016 16:09:02 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Geoff- vtkVoxelGrid (in VTK/Remote/vtkPointCloud) is now interpolating point data attributes. Besides updating Remotes/vtkPointCloud, you'll need to update VTK as I just pushed a bunch of stuff (in VTK/Filters/Points) that implements a kernel interpolation framework. To change the interpolation of attributes on vtkVoxelGrid, you have to specify a new interpolation kernel (vtkLinearKernel is default - averages data). Please test this and report problems. I recommend that you build optimized with VTK_SMP_IMPLEMENTATION_TYPE=TBB you'll run much faster. Best, W On Fri, Jan 29, 2016 at 10:26 AM, Geoff Wright wrote: > Hi Will, > > That sounds good. For my use case I do have a couple of scalar quantities > associated with each point, in PCL terminology I use pcl::PointXYZHSV. > For interpolation of scalar values I think the ideal would be a parameter > on voxel grid that can accept either VTK_NEAREST_INTERPOLATION, > VTK_LINEAR_INTERPOLATION or VTK_CUBIC_INTERPOLATION a la > vtkVolumeProperty.h. However, if this is too much work I think a linear > interpolation implementation would be fine for most use cases. > > Let me know when you push the changes, I'll try it out. Just checked your > gitlab repo and didn't seem them there yet. > > G > > > > > On Fri, Jan 29, 2016 at 10:07 AM Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Geoff- >> >> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >> threaded and seems to be fast. >> >> Question for you before I push the work to the repository: averaging >> points in each bin provides a nice subsampled point position. But what do >> you think we should do for attributes (e.g., scalars, vector, etc.)? These >> could be averaged too. There are however other options like finding the >> closest point to the subsampled point and using those attribute values, or >> if you want to get really fancy, using an interpolation kernel to >> interpolate to the subsampled point. >> >> Thoughts? >> W >> >> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Thanks for the feedback. I have some downsampling filters in the works >>> now, I'll let you know when I have something ready. >>> >>> BTW we are on a similar path. PCL is awesome, but we have some common >>> workflows that would be better served with more compact software >>> environments, and with minimal IO and/or data transfer. So we're trying to >>> knock of a small kernel of capability to achieve this. >>> >>> Best, >>> W >>> >>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>> wrote: >>> >>>> Hi Will, >>>> >>>> This is good to see. I'm currently using VTK to generate surfaces from >>>> some point cloud data. I have some initial pre processing steps that I use >>>> PCL (point cloud library) for, and then a vtk stage that converts PCL point >>>> cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >>>> PCL dependency and use exclusively vtk. My point cloud data grows >>>> very large over time with a lot of redundant points so its very important >>>> to downsample them onto uniform spacing ( >>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>> before processing them in vtk. Would it make sense to add something like >>>> this to your library? >>>> >>>> Geoff >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> FYI- I have committed an initial set of filters for performing point >>>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>>> initial prototype. The work is currently available as a remote module to >>>>> VTK (vtkPointCloud) via this repository: >>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>> >>>>> A couple of notes: >>>>> + Right now I am using vtkPolyData to represent the point cloud via a >>>>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>>>> save on memory. >>>>> + The classes will process as input any vtkPointSet dataset >>>>> + There is a general framework for filtering point clouds via the >>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>> filters also have an optional, second output which contains any points >>>>> removed from the input. >>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>> implicit function). Some of these names are inspired by PCL >>>>> names. >>>>> + All filters are threaded using vtkSMPTools using a threaded locator >>>>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>>>> I have not done much testing. >>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>> wrote that is very fast. >>>>> >>>>> As usual comments and suggestions are requested. In particular any >>>>> suggestions for other filters to write are welcome (to round out some of >>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>> try to educate myself, so be forewarned. >>>>> >>>>> Best, >>>>> W >>>>> >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. - Building the World's Technical Computing Software >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >>> >> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome.velut at gmail.com Wed Feb 24 03:01:33 2016 From: jerome.velut at gmail.com (=?UTF-8?B?SsOpIFZlbHV0?=) Date: Wed, 24 Feb 2016 09:01:33 +0100 Subject: [vtk-developers] RequestUpdateExtent not called after modified Message-ID: Dear all, I am struggling with the pipeline mechanism. I wrote an image reader that wraps the ITK gdcm reader. When I change the directory, the reader does update. However, if the extent of the second volume is larger than the first one, I get the warning message : ERROR: In C:\Users\Jerome\Dev\VTK\vtk-src\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx, line 857 vtkCompositeDataPipeline (000002913075DB70): The update extent specified in the information for output port 0 on algorithm vtkITKGDCMImageReader(000002913074A470) is 0 255 0 255 0 255, which is outside the whole extent 0 255 0 255 0 197. Strangely, I wrote a simple test for this reader and the warning is not thrown. The test set the file path, updates, then changes the file path and updates again. The warning appears in a more complicated pipeline. The odd is that I implemented the RequestUpdateExtent, that simply returns the Superclass::RequestUpdateExtent result. In the simple test, this function is called at each pipeline update. In the full application, it is not called the second time (while requestInformation is correctly called...). I guess the pipeline does not notify correctly the reader to change the update extent. But why? I found this thread which may be close to my issue : http://markmail.org/search/?q=update_extent+not+updated#query:update_extent%20not%20updated+page:1+mid:xmi3dp3xqbnp2hzv+state:results Thanks a lot ! Jerome -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Feb 24 04:04:22 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 24 Feb 2016 02:04:22 -0700 (MST) Subject: [vtk-developers] vtkImageReslice mapping to a texture Message-ID: <1456304662754-5736781.post@n5.nabble.com> Hello, Just wanted to share the weird experience that I had with vtkImageReslice. I actually used it in combination with a plane to create a vtkImageData that is a slice of my dataset. I then wanted to create a texture based on that vtkImageData. Which works just fine until I tried to render in which case, since I am using OpenGLES I had issues with 3D texture rendering. So I thought this problem should not occur as I was trying to render a 2D texture only. Yet, checking the dimensions of my vtkImageReslice gave me dimensions > 1 on all axes. I finally got my piece of code to work thanks to the SetOutputDimensionality(2) function. I don't know if this behaviour is normal or not, but I thought I should share my workaround, and at the very least let you guys know about the behaviour so that you could take a look at it if you believe the behaviour to be incorrect. Lonni -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkImageReslice-mapping-to-a-texture-tp5736781.html Sent from the VTK - Dev mailing list archive at Nabble.com. From will.schroeder at kitware.com Wed Feb 24 06:46:22 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 24 Feb 2016 06:46:22 -0500 Subject: [vtk-developers] Failing tests Message-ID: I added a test yesterday (TestSampleImplicitFunctionFilter.py) that uses vtkPointGaussianMapper. I believe that this class is only available in OpenGL2, so some builds (running the older OpenGL1) are failing. Remind me again, what's the recommended path forward? Since OpenGL2 is now VTK's default (and much faster) I'd prefer to use vtkPointGaussianMapper. I could rewrite the test with the old mapper, or I suppose conditionally eliminate it on OpenGL1 systems, etc. Suggestions? Best, W -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Feb 24 07:51:11 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 24 Feb 2016 07:51:11 -0500 Subject: [vtk-developers] Failing tests In-Reply-To: References: Message-ID: If it is a rendering test I put it into OpenGL2, otherwise I put it in a if statement in the cmakelists file. In this case you could also just make the test use the polydatamapper as long as you don;t need any features of the pointgaussian On Wed, Feb 24, 2016 at 6:46 AM, Will Schroeder wrote: > I added a test yesterday (TestSampleImplicitFunctionFilter.py) that uses > vtkPointGaussianMapper. I believe that this class is only available in > OpenGL2, so some builds (running the older OpenGL1) are failing. > > Remind me again, what's the recommended path forward? Since OpenGL2 is now > VTK's default (and much faster) I'd prefer to use vtkPointGaussianMapper. I > could rewrite the test with the old mapper, or I suppose conditionally > eliminate it on OpenGL1 systems, etc. Suggestions? > > Best, > W > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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: From david.gobbi at gmail.com Wed Feb 24 08:46:16 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 24 Feb 2016 06:46:16 -0700 Subject: [vtk-developers] vtkImageReslice mapping to a texture In-Reply-To: <1456304662754-5736781.post@n5.nabble.com> References: <1456304662754-5736781.post@n5.nabble.com> Message-ID: Hi Lonni, Did you expect that vtkImageReslice would always produce a 2D image? When given a 3D image as input, it will produce another 3D image as output unless it is specifically told to produce a 2D image (which is often done by calling SetOutputExtent() with an extent that is only 1 slice thick). - David On Wed, Feb 24, 2016 at 2:04 AM, Lonni Besan?on wrote: > Hello, > > Just wanted to share the weird experience that I had with vtkImageReslice. > I actually used it in combination with a plane to create a vtkImageData > that > is a slice of my dataset. I then wanted to create a texture based on that > vtkImageData. Which works just fine until I tried to render in which case, > since I am using OpenGLES I had issues with 3D texture rendering. > So I thought this problem should not occur as I was trying to render a 2D > texture only. Yet, checking the dimensions of my vtkImageReslice gave me > dimensions > 1 on all axes. > > I finally got my piece of code to work thanks to the > SetOutputDimensionality(2) function. > I don't know if this behaviour is normal or not, but I thought I should > share my workaround, and at the very least let you guys know about the > behaviour so that you could take a look at it if you believe the behaviour > to be incorrect. > > Lonni > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Feb 24 08:49:11 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 24 Feb 2016 06:49:11 -0700 (MST) Subject: [vtk-developers] vtkImageReslice mapping to a texture In-Reply-To: References: <1456304662754-5736781.post@n5.nabble.com> Message-ID: <1456321751766-5736793.post@n5.nabble.com> That's actually what I expected yes, but I noticed that the SetOutputExtent() was here for a reason and when using it I got exactly what I wanted. I guess my original thinking was wrong, just wanted to confirm with you that point :). (Also point some future question in the direction of this thread :D) -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkImageReslice-mapping-to-a-texture-tp5736781p5736793.html Sent from the VTK - Dev mailing list archive at Nabble.com. From berk.geveci at kitware.com Wed Feb 24 10:30:13 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 24 Feb 2016 10:30:13 -0500 Subject: [vtk-developers] RequestUpdateExtent not called after modified In-Reply-To: References: Message-ID: It is hard to guess whether the problem is the same without seeing code. However, this issue was fixed in VTK master so you may want to update and see for yourself. I am including below the documentation explaining the change (also available in Documentation/Doxygen/ChangesVTK-7-1.md). However, if RequestInformation() executes and RequestData() executes, it is impossible for RequestUpdateExtent() not to execute. There is no code path for this. So something is fishy. Best, -berk Pipeline Update Methods ----------------------- The following methods were deprecated in VTK 7.1: ### vtkAlgorithm: int SetUpdateExtentToWholeExtent(int port); int SetUpdateExtentToWholeExtent(); void SetUpdateExtent(int port, int piece,int numPieces, int ghostLevel); void SetUpdateExtent( int piece,int numPieces, int ghostLevel); void SetUpdateExtent(int port, int extent[6]); void SetUpdateExtent(int extent[6]); ### vtkStreamingDemandDrivenPipeline: int SetUpdateExtentToWholeExtent(int port); static int SetUpdateExtentToWholeExtent(vtkInformation *); int SetUpdateExtent(int port, int extent[6]); int SetUpdateExtent(int port, int x0, int x1, int y0, int y1, int z0, int z1); static int SetUpdateExtent(vtkInformation *, int extent[6]); int SetUpdateExtent(int port, int piece, int numPieces, int ghostLevel); static int SetUpdateExtent(vtkInformation *, int piece, int numPieces, int ghostLevel); static int SetUpdatePiece(vtkInformation *, int piece); static int SetUpdateNumberOfPieces(vtkInformation *, int n); static int SetUpdateGhostLevel(vtkInformation *, int n); int SetUpdateTimeStep(int port, double time); static int SetUpdateTimeStep(vtkInformation *, double time); The following new methods were added: ### vtkAlgorithm: int Update(int port, vtkInformationVector* requests); int Update(vtkInformation* requests); int UpdatePiece(int piece, int numPieces, int ghostLevels, int* extents=0); int UpdateExtent(int piece, int numPieces, int ghostLevels, int* extents=0); int UpdateTimeStep(double time, int piece=-1, int numPieces=1, int ghostLevels=0, int* extents=0); ### vtkStreamingDemandDrivenPipeline: int Update(int port, vtkInformationVector* requests); The main reason behind these changes is to make requesting a particular time step or a particular spatial subset (extent or pieces) during an update easier and more predictable. Prior to these changes, the following is the best way to request a subset during update: vtkNew source; // Set some properties of source here source->UpdateInformation(); source->SetUpdateExtent(0, 5, 0, 5, 2, 2); source->Update(); Note that the following will not work: vtkNew source; // Set some properties of source here // source->UpdateInformation(); <-- this was commented out source->SetUpdateExtent(0, 5, 0, 5, 2, 2); source->Update(); This is because when the output of an algorithm is initialized, all request meta-data stored in its OutputInformation is removed. The initialization of the output happens during the first *RequestInformation*, which is why `UpdateInformation()` needs to be called before setting any request values. To make things more complicated, the following will also not work: vtkNew source; // Set some properties of source here source->UpdateInformation(); source->SetUpdateExtent(0, 5, 0, 5, 2, 2); source->Modified(); source->Update(); This is because during *RequestInformation*, the extent and piece requests are initialized to default values (which is the whole dataset) and *RequestInformation* is called during update if the algorithm has been modified since the last information update. This necessary sequence of calls has been mostly tribal knowledge and is very error prone. To simplify pipeline updates with requests, we introduced a new set of methods. With the new API, our example would be: vtkNew source; int updateExtent[6] = {0, 5, 0, 5, 2, 2}; // Set some properties of source here source->UpdateExtent(updateExtent); To ask for a particular time step from a time source, we would do something like this: vtkNew reader; // Set properties here reader->UpdateTimeStep(0.5); // or reader->UpdateTimeStep(0.5, 1, 2, 1); The last call asks for time value 0.5 and the first of two pieces with one ghost level. The new algorithm also supports directly passing a number of keys to make requests: typedef vtkStreamingDemandDrivenPipeline vtkSDDP; vtkNew source; int updateExtent[6] = {0, 5, 0, 5, 2, 2}; vtkNew requests; requests->Set(vtkSDDP::UPDATE_EXTENT(), updateExtent, 6); reader->Update(requests.GetPointer()); This is equivalent to: typedef vtkStreamingDemandDrivenPipeline vtkSDDP; vtkNew source; int updateExtent[6] = {0, 5, 0, 5, 2, 2}; source->UpdateInformation(); source->GetOutputInformation(0)->Set(vtkSDDP::UPDATE_EXTENT(), updateExtent, 6); reader->Update(); We expect to remove the deprecated methods in VTK 8.0. On Wed, Feb 24, 2016 at 3:01 AM, J? Velut wrote: > Dear all, > > I am struggling with the pipeline mechanism. > I wrote an image reader that wraps the ITK gdcm reader. When I change the > directory, > the reader does update. However, if the extent of the second volume is > larger than the > first one, I get the warning message : > > ERROR: In > C:\Users\Jerome\Dev\VTK\vtk-src\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx, > line 857 > vtkCompositeDataPipeline (000002913075DB70): The update extent specified > in the information for output port 0 on algorithm > vtkITKGDCMImageReader(000002913074A470) is 0 255 0 255 0 255, which is > outside the whole extent 0 255 0 255 0 197. > > Strangely, I wrote a simple test for this reader and the warning is not > thrown. The test set the file path, updates, then changes the file path and > updates again. The warning appears in a more complicated pipeline. > > The odd is that I implemented the RequestUpdateExtent, that simply returns > the Superclass::RequestUpdateExtent result. In the simple test, this > function is called at each pipeline update. In the full application, it is > not called the second time (while requestInformation is correctly > called...). > > I guess the pipeline does not notify correctly the reader to change the > update extent. But why? > I found this thread which may be close to my issue : > > http://markmail.org/search/?q=update_extent+not+updated#query:update_extent%20not%20updated+page:1+mid:xmi3dp3xqbnp2hzv+state:results > > Thanks a lot ! > Jerome > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Wed Feb 24 10:39:42 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Wed, 24 Feb 2016 10:39:42 -0500 Subject: [vtk-developers] Volume rendering update In-Reply-To: References: Message-ID: Hi David On Tue, Feb 23, 2016 at 12:02 PM, David Gobbi wrote: > I was playing with the Medical4 example last week, and > vtkGPURayCastVolumeMapper managed to render shaded volumes at up to > 1024x1024x768! Very fast loading, too, it took around 1 second to load. Great, thanks. > > With the volume size at 1024x1024x1024, however, there was a wrap-around > artifact. I'm guessing that it was due either to memory limitations, or due > to integer overflow. Maybe a hardware issue, maybe the driver, hard to say > when the data set itself is 2GB. This is a Mac (10.9.5) with AMD FirePro > D700 6GB, what datatypes does the mapper use for the buffers? this is interesting hard to say what's happening here but I didn't encounter this issue before. Typically I would expect that you get GL error or a CRASH. Would be it possible to post your example code and data somewhere? Or else, I will see if I can create a example myself. > > On Tue, Feb 23, 2016 at 9:43 AM, Aashish Chaudhary > wrote: >> >> Hi all, >> >> We have made some significant improvements to volume rendering since our >> last update (Ref: >> https://blog.kitware.com/volume-rendering-enhancements-in-vtk/, >> https://blog.kitware.com/volume-rendering-on-ios-and-android/). Below is a >> list of tasks that are either nearly completed and or are in VTK master as >> of today. >> >> Features/updates >> >> Big volume support - Fixing failing tests. The idea is to split volume >> into smaller volumes and render them piecewise. >> >> 3x-5x clipping plane performance - For the same parameters, clipping is >> much faster now, the trick is to skip voxels that are clipped by planes. >> >> Depth and color data capture - User can use RenderToImage to render to a >> FBO and get depth and color texture which then could be utilized for other >> operations. >> >> Bugs >> >> Fixed gradient opacity not working for more than one components >> >> Fixed clipping plane location is wrong in certain cases. >> >> Fixed volume rendering invalid or bad for cell data >> >> Fixed edges issue when rendering in multiple pieces (hard edges) >> >> Fixed volume rendering not working in remote rendering mode with image >> reduction factor > 1 >> >> Fixed volume rendering not working in client-server mode >> >> Fixed volume disappears when changing parameters >> >> Fixed volume rendering not using the correct sampling distance >> >> >> -- >> | Aashish Chaudhary >> | Technical Leader >> | Kitware Inc. >> | http://www.kitware.com/company/team/chaudhary.html > > -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html From david.gobbi at gmail.com Wed Feb 24 11:21:38 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 24 Feb 2016 09:21:38 -0700 Subject: [vtk-developers] Volume rendering update In-Reply-To: References: Message-ID: On Wed, Feb 24, 2016 at 8:39 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > > > With the volume size at 1024x1024x1024, however, there was a wrap-around > > artifact. I'm guessing that it was due either to memory limitations, or > due > > to integer overflow. Maybe a hardware issue, maybe the driver, hard to > say > > when the data set itself is 2GB. This is a Mac (10.9.5) with AMD FirePro > > D700 6GB, what datatypes does the mapper use for the buffers? > > this is interesting hard to say what's happening here but I didn't > encounter this issue before. Typically I would expect that you get GL > error or a CRASH. > Would be it possible to post your example code and data somewhere? Or > else, I will see if I can create a example myself. I have attached the example. It uses the headsq "half" dataset and upsamples it to the desired resolution. If you don't have the "half" dataset, you can use the headsq "quarter" dataset instead. Currently the code resamples the volume to 1024x1024x768 (line 38). Thanks, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Medical4_Resample.py Type: text/x-python-script Size: 5376 bytes Desc: not available URL: From aashish.chaudhary at kitware.com Wed Feb 24 11:25:57 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Wed, 24 Feb 2016 11:25:57 -0500 Subject: [vtk-developers] Volume rendering update In-Reply-To: References: Message-ID: great, thanks. - Aashish On Wed, Feb 24, 2016 at 11:21 AM, David Gobbi wrote: > On Wed, Feb 24, 2016 at 8:39 AM, Aashish Chaudhary > wrote: >> >> >> > With the volume size at 1024x1024x1024, however, there was a wrap-around >> > artifact. I'm guessing that it was due either to memory limitations, or >> > due >> > to integer overflow. Maybe a hardware issue, maybe the driver, hard to >> > say >> > when the data set itself is 2GB. This is a Mac (10.9.5) with AMD >> > FirePro >> > D700 6GB, what datatypes does the mapper use for the buffers? >> >> this is interesting hard to say what's happening here but I didn't >> encounter this issue before. Typically I would expect that you get GL >> error or a CRASH. >> Would be it possible to post your example code and data somewhere? Or >> else, I will see if I can create a example myself. > > > I have attached the example. It uses the headsq "half" dataset and > upsamples > it to the desired resolution. If you don't have the "half" dataset, you can > use the > headsq "quarter" dataset instead. > > Currently the code resamples the volume to 1024x1024x768 (line 38). > > Thanks, > - David -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html From jerome.velut at gmail.com Wed Feb 24 12:17:57 2016 From: jerome.velut at gmail.com (=?UTF-8?B?SsOpIFZlbHV0?=) Date: Wed, 24 Feb 2016 18:17:57 +0100 Subject: [vtk-developers] RequestUpdateExtent not called after modified In-Reply-To: References: Message-ID: Thanks Berk, Thanks a lot ! Indeed checking out the master did solve the issue (and more! Good surprise!) Best regards, Jerome 2016-02-24 16:30 GMT+01:00 Berk Geveci : > It is hard to guess whether the problem is the same without seeing code. > However, this issue was fixed in VTK master so you may want to update and > see for yourself. I am including below the documentation explaining the > change (also available in Documentation/Doxygen/ChangesVTK-7-1.md). > > However, if RequestInformation() executes and RequestData() executes, it > is impossible for RequestUpdateExtent() not to execute. There is no code > path for this. So something is fishy. > > Best, > -berk > > > Pipeline Update Methods > ----------------------- > > The following methods were deprecated in VTK 7.1: > > ### vtkAlgorithm: > > int SetUpdateExtentToWholeExtent(int port); > int SetUpdateExtentToWholeExtent(); > void SetUpdateExtent(int port, > int piece,int numPieces, int ghostLevel); > void SetUpdateExtent( > int piece,int numPieces, int ghostLevel); > void SetUpdateExtent(int port, int extent[6]); > void SetUpdateExtent(int extent[6]); > > ### vtkStreamingDemandDrivenPipeline: > > int SetUpdateExtentToWholeExtent(int port); > static int SetUpdateExtentToWholeExtent(vtkInformation *); > int SetUpdateExtent(int port, int extent[6]); > int SetUpdateExtent(int port, int x0, int x1, int y0, int y1, int z0, > int z1); > static int SetUpdateExtent(vtkInformation *, int extent[6]); > int SetUpdateExtent(int port, > int piece, int numPieces, int ghostLevel); > static int SetUpdateExtent(vtkInformation *, > int piece, int numPieces, int ghostLevel); > static int SetUpdatePiece(vtkInformation *, int piece); > static int SetUpdateNumberOfPieces(vtkInformation *, int n); > static int SetUpdateGhostLevel(vtkInformation *, int n); > int SetUpdateTimeStep(int port, double time); > static int SetUpdateTimeStep(vtkInformation *, double time); > > The following new methods were added: > > ### vtkAlgorithm: > > int Update(int port, vtkInformationVector* requests); > int Update(vtkInformation* requests); > int UpdatePiece(int piece, int numPieces, int ghostLevels, int* > extents=0); > int UpdateExtent(int piece, int numPieces, int ghostLevels, int* > extents=0); > int UpdateTimeStep(double time, > int piece=-1, int numPieces=1, int ghostLevels=0, int* extents=0); > > ### vtkStreamingDemandDrivenPipeline: > > int Update(int port, vtkInformationVector* requests); > > The main reason behind these changes is to make requesting a particular > time step or a particular spatial subset (extent or pieces) during an > update easier and more predictable. Prior to these changes, the following > is the best way to request a subset during update: > > vtkNew source; > // Set some properties of source here > source->UpdateInformation(); > source->SetUpdateExtent(0, 5, 0, 5, 2, 2); > source->Update(); > > Note that the following will not work: > > vtkNew source; > // Set some properties of source here > // source->UpdateInformation(); <-- this was commented out > source->SetUpdateExtent(0, 5, 0, 5, 2, 2); > source->Update(); > > This is because when the output of an algorithm is initialized, all > request meta-data stored in its OutputInformation is removed. The > initialization of the output happens during the first *RequestInformation*, > which is why `UpdateInformation()` needs to be called before setting any > request values. To make things more complicated, the following will also > not work: > > vtkNew source; > // Set some properties of source here > source->UpdateInformation(); > source->SetUpdateExtent(0, 5, 0, 5, 2, 2); > source->Modified(); > source->Update(); > > This is because during *RequestInformation*, the extent and piece requests > are initialized to default values (which is the whole dataset) and > *RequestInformation* is called during update if the algorithm has been > modified since the last information update. > > This necessary sequence of calls has been mostly tribal knowledge and is > very error prone. To simplify pipeline updates with requests, we introduced > a new set of methods. With the new API, our example would be: > > vtkNew source; > int updateExtent[6] = {0, 5, 0, 5, 2, 2}; > // Set some properties of source here > source->UpdateExtent(updateExtent); > > To ask for a particular time step from a time source, we would do > something like this: > > vtkNew reader; > // Set properties here > reader->UpdateTimeStep(0.5); > // or > reader->UpdateTimeStep(0.5, 1, 2, 1); > > The last call asks for time value 0.5 and the first of two pieces with one > ghost level. > > The new algorithm also supports directly passing a number of keys to make > requests: > > typedef vtkStreamingDemandDrivenPipeline vtkSDDP; > vtkNew source; > int updateExtent[6] = {0, 5, 0, 5, 2, 2}; > vtkNew requests; > requests->Set(vtkSDDP::UPDATE_EXTENT(), updateExtent, 6); > reader->Update(requests.GetPointer()); > > This is equivalent to: > > typedef vtkStreamingDemandDrivenPipeline vtkSDDP; > vtkNew source; > int updateExtent[6] = {0, 5, 0, 5, 2, 2}; > source->UpdateInformation(); > source->GetOutputInformation(0)->Set(vtkSDDP::UPDATE_EXTENT(), > updateExtent, 6); > reader->Update(); > > We expect to remove the deprecated methods in VTK 8.0. > > On Wed, Feb 24, 2016 at 3:01 AM, J? Velut wrote: > >> Dear all, >> >> I am struggling with the pipeline mechanism. >> I wrote an image reader that wraps the ITK gdcm reader. When I change the >> directory, >> the reader does update. However, if the extent of the second volume is >> larger than the >> first one, I get the warning message : >> >> ERROR: In >> C:\Users\Jerome\Dev\VTK\vtk-src\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx, >> line 857 >> vtkCompositeDataPipeline (000002913075DB70): The update extent specified >> in the information for output port 0 on algorithm >> vtkITKGDCMImageReader(000002913074A470) is 0 255 0 255 0 255, which is >> outside the whole extent 0 255 0 255 0 197. >> >> Strangely, I wrote a simple test for this reader and the warning is not >> thrown. The test set the file path, updates, then changes the file path and >> updates again. The warning appears in a more complicated pipeline. >> >> The odd is that I implemented the RequestUpdateExtent, that simply >> returns the Superclass::RequestUpdateExtent result. In the simple test, >> this function is called at each pipeline update. In the full application, >> it is not called the second time (while requestInformation is correctly >> called...). >> >> I guess the pipeline does not notify correctly the reader to change the >> update extent. But why? >> I found this thread which may be close to my issue : >> >> http://markmail.org/search/?q=update_extent+not+updated#query:update_extent%20not%20updated+page:1+mid:xmi3dp3xqbnp2hzv+state:results >> >> Thanks a lot ! >> Jerome >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Feb 24 14:31:48 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 24 Feb 2016 14:31:48 -0500 Subject: [vtk-developers] Wiki Examples Remote Module dashboard submission In-Reply-To: References: Message-ID: On Mon, Feb 22, 2016 at 4:12 PM, Bill Lorensen wrote: > Expected Nightly Remote Modules Done. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Feb 25 10:20:05 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 25 Feb 2016 10:20:05 -0500 Subject: [vtk-developers] Checking SMP backend at runtime/compiletime? In-Reply-To: References: <20160209152847.2140519877@mail.rogue-research.com> <20160219171129.1266051426@mail.rogue-research.com> <20160219173218.378773446@mail.rogue-research.com> Message-ID: <20160225152005.1630436472@mail.rogue-research.com> On Mon, 22 Feb 2016 11:25:37 -0500, Berk Geveci said: >David beat me to the punch :-) I expect that Apple with support OpenMP in >the next year or two, at least on the desktop. I encourage everyone that would like to see that file a ticket at: Like anyone, they prioritize (partly) based on number of requests. >(vector instructions) and AFAIK the only other way Clang supports SIMD is >through auto-vectorization, which is limited. I don't see them supporting >only SIMD so I would guess that they will pull the whole OpenMP support. Clang also supports various vector extensions: >> Why not include it? How is it different from how VTK includes NetCDF, >HDF5, zlib, libpng, and a zillion other 3rd party libs? > >Good question. I don't know how/where we draw the line with these. OpenGL & >MPI are external dependencies whereas the ones you listed are included as >third party. I have a few reasons why I wouldn't want to include it: > >* TBB license language may scare off some people as demonstrated by this >thread. Although the license is totally fine, I'd rather avoid answering >questions about the TBB license from those that do a license check in VTK. >* TBB is a fairly complex beast because of platforms/compilers it supports >(at fairly low level) and I'd rather avoid writing CMake files & >maintaining them > >I don't have any strong attachment to this view however. OK thanks. We'll see when we get there I guess... :) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ken.martin at kitware.com Fri Feb 26 08:39:20 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 26 Feb 2016 08:39:20 -0500 Subject: [vtk-developers] ffmpeg compile failure on hythloth Message-ID: It looks like nightly hythloth has been failing to build for the past three days due to issues with FFMPEG. If that rings a bell, and you are not already aware of it, then, I guess you are more aware of it now :-) -- 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: From aashish.chaudhary at kitware.com Fri Feb 26 08:41:43 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 26 Feb 2016 08:41:43 -0500 Subject: [vtk-developers] ffmpeg compile failure on hythloth In-Reply-To: References: Message-ID: Ken, I am looking into it. Hoping to fix it today. - Aashish On Fri, Feb 26, 2016 at 8:39 AM, Ken Martin wrote: > > It looks like nightly hythloth has been failing to build for the past three > days due to issues with FFMPEG. If that rings a bell, and you are not > already aware of it, then, I guess you are more aware of it now :-) > > -- > 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. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html From ken.martin at kitware.com Fri Feb 26 08:41:56 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 26 Feb 2016 08:41:56 -0500 Subject: [vtk-developers] ffmpeg compile failure on hythloth In-Reply-To: References: Message-ID: Awesome! On Fri, Feb 26, 2016 at 8:41 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Ken, > > I am looking into it. Hoping to fix it today. > > - Aashish > > On Fri, Feb 26, 2016 at 8:39 AM, Ken Martin > wrote: > > > > It looks like nightly hythloth has been failing to build for the past > three > > days due to issues with FFMPEG. If that rings a bell, and you are not > > already aware of it, then, I guess you are more aware of it now :-) > > > > -- > > 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. > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > | http://www.kitware.com/company/team/chaudhary.html > -- 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: From mathieu.westphal at kitware.com Fri Feb 26 09:11:05 2016 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 26 Feb 2016 15:11:05 +0100 Subject: [vtk-developers] vtkAxisActor CalculateTitleOffset/CalculateLabelOffset In-Reply-To: References: Message-ID: Hello Is anyone using the the vtkAxisActor::CalculateTitleOffset/CalculateLabelOffset flags ? I'm in the process of rewriting a big part of this class in order to add Features. It is true by default, but all users of this class pass it to false. AFAIU, when this flag is true, the vtkAxisActor *user *is suposed to take care of setting the screenoffset itself, the axis actor only positioning using position and not position + offset as it should. The code i'm working on is way more complicated, and i could implement this flag as well, but it will overcomplicate this class, and if it is not used, i would like to drop it and warning the flag as being ignored now. Of course a code relying of this flag, if there is any, will break. Mathieu Westphal On Fri, Feb 26, 2016 at 4:45 AM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Mathieu, > > The short answer is no one really knows the details of this class too > well. This code had it's birth in VisIt and was moved to VTK a while > ago. > > Utkarsh > > On Thu, Feb 25, 2016 at 12:56 PM, Aashish Chaudhary > wrote: > > Hi Mathieu, > > > > I used this class (did I write it?) long time back and I have to look > > into it to provide you any meaningful answer. What you are trying to > > do? > > > > Also, Seb and Utkarsh may have touched this class recently. > > > > Thanks > > > > > > On Thu, Feb 25, 2016 at 12:43 PM, Berk Geveci > wrote: > >> I have no idea :-) I suggest that you email the Kitware developers list. > >> > >> -berk > >> > >> On Thu, Feb 25, 2016 at 10:41 AM, Mathieu Westphal > >> wrote: > >>> > >>> Hi > >>> > >>> I'm trying to understand the usage of these flags, and I just can't > make > >>> sense of it. > >>> > >>> Both vtkAxisActor user ( CubeAxes and PolarAxe) set this flag to > false, in > >>> order to use the SetScreenOffset in order to have a screen scale > adaptable > >>> offset. > >>> > >>> When set to true, it write the offset directly into the position of the > >>> actor, preventing the axisFollower to ever of the screen offset > correctly. > >>> > >>> Do i miss something ? > >>> > >>> Mathieu Westphal > >> > >> > > > > > > > > -- > > | Aashish Chaudhary > > | Technical Leader > > | Kitware Inc. > > | http://www.kitware.com/company/team/chaudhary.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Sat Feb 27 00:29:47 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Sat, 27 Feb 2016 00:29:47 -0500 Subject: [vtk-developers] ffmpeg compile failure on hythloth In-Reply-To: References: Message-ID: I am having a hard time reproducing this error on my system. the CodecID is now replaced by AVCodecID and it should have been found. I have to login to this machine to figure out the issue. - aashish On Fri, Feb 26, 2016 at 8:41 AM, Ken Martin wrote: > Awesome! > > On Fri, Feb 26, 2016 at 8:41 AM, Aashish Chaudhary > wrote: >> >> Ken, >> >> I am looking into it. Hoping to fix it today. >> >> - Aashish >> >> On Fri, Feb 26, 2016 at 8:39 AM, Ken Martin >> wrote: >> > >> > It looks like nightly hythloth has been failing to build for the past >> > three >> > days due to issues with FFMPEG. If that rings a bell, and you are not >> > already aware of it, then, I guess you are more aware of it now :-) >> > >> > -- >> > 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. >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> > http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> | Aashish Chaudhary >> | Technical Leader >> | Kitware Inc. >> | http://www.kitware.com/company/team/chaudhary.html > > > > > -- > 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. -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html From aashish.chaudhary at kitware.com Sat Feb 27 01:50:34 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Sat, 27 Feb 2016 01:50:34 -0500 Subject: [vtk-developers] ffmpeg compile failure on hythloth In-Reply-To: References: Message-ID: I pushed a fix: https://gitlab.kitware.com/vtk/vtk/merge_requests/1281 and also tested it manually on hythloth. Thanks, Aashish On Sat, Feb 27, 2016 at 12:29 AM, Aashish Chaudhary wrote: > I am having a hard time reproducing this error on my system. the > CodecID is now replaced by AVCodecID and it should have been found. I > have to login to this machine to figure out the issue. > > - aashish > > On Fri, Feb 26, 2016 at 8:41 AM, Ken Martin wrote: >> Awesome! >> >> On Fri, Feb 26, 2016 at 8:41 AM, Aashish Chaudhary >> wrote: >>> >>> Ken, >>> >>> I am looking into it. Hoping to fix it today. >>> >>> - Aashish >>> >>> On Fri, Feb 26, 2016 at 8:39 AM, Ken Martin >>> wrote: >>> > >>> > It looks like nightly hythloth has been failing to build for the past >>> > three >>> > days due to issues with FFMPEG. If that rings a bell, and you are not >>> > already aware of it, then, I guess you are more aware of it now :-) >>> > >>> > -- >>> > 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. >>> > >>> > _______________________________________________ >>> > Powered by www.kitware.com >>> > >>> > Visit other Kitware open-source projects at >>> > http://www.kitware.com/opensource/opensource.html >>> > >>> > Search the list archives at: >>> > http://markmail.org/search/?q=vtk-developers >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >>> > >>> >>> >>> >>> -- >>> | Aashish Chaudhary >>> | Technical Leader >>> | Kitware Inc. >>> | http://www.kitware.com/company/team/chaudhary.html >> >> >> >> >> -- >> 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. > > > > -- > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > | http://www.kitware.com/company/team/chaudhary.html -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html From will.schroeder at kitware.com Sat Feb 27 10:27:52 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Sat, 27 Feb 2016 10:27:52 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Here's a quick update on point cloud processing in VTK. We've got an initial base of decent capability going now, including (and I am absolutely delighted about this) a surface extraction capability based on TSDF (truncated signed distance functions). *Classes now running (in VTK/Remote/vtkPointCloud):* vtkEuclideanClusterExtraction.h vtkExtractHierarchicalBins.h vtkExtractPointCloudPiece.h vtkExtractPoints.h vtkExtractSurface.h vtkFitImplicitFunction.h vtkHierarchicalBinningFilter.h vtkPCACurvatureEstimation.h vtkPCANormalEstimation.h vtkPointCloudFilter.h vtkRadiusOutlierRemoval.h vtkSignedDistance.h vtkStatisticalOutlierRemoval.h vtkVoxelGrid.h *Surface extraction (in VTK/Remote/vtkPointCloud):* We've build a pipeline of objects that perform rudimentary surface extraction from a point cloud. There are three major parts: 1. Generating normals - currently use vtkPCANormalEstimation, including graph traversal to create consistently oriented normals. 2. Compute the TSDF using vtkSignedDistance. 3. Extract zero-crossing isocontour to generate surface (vtkExtractSurface). Note that each of these parts will eventually be expanded by writing new filters, for example I want to use in #1 Brad King's tensor voting (from his PhD thesis ) to compute better normals. For #2, based loosely on the Curless & Levoy paper, we can do better by using different interpolation kernels (see PointInterpolation framework below) rather than the ad hoc probability weights they use (to be added soon). Also for #2 we need to support incremental updating. Finally, #3 is based on a modified Flying Edges algorithm so it is very fast :-) *Point Interpolation (in VTK/Filters/Points)* We just pushed this in, it looks to be a very powerful, quite general framework for performing data interpolation across point samples. It's threaded, uses fast threaded locators, and has an abstraction for a family of interpolation kernels (e.g., linear, gaussian, shepard, voronoi, hopefully SPH) at some point soon, with more on the way. As usual any feedback is appreciated. Make sure you update both VTK and the vtkPointCloud remote module. Please don't be shy, this is happening really fast and I want to catch the inevitable stupid stuff as soon as possible. Best, W On Thu, Jan 28, 2016 at 9:12 AM, Will Schroeder wrote: > FYI- I have committed an initial set of filters for performing point cloud > processing. Any feedback or suggestions are welcome as this is an initial > prototype. The work is currently available as a remote module to VTK > (vtkPointCloud) via this repository: > https://gitlab.kitware.com/vtk/point-cloud.git > > A couple of notes: > + Right now I am using vtkPolyData to represent the point cloud via a > vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to > save on memory. > + The classes will process as input any vtkPointSet dataset > + There is a general framework for filtering point clouds via the class > vtkPointCloudFilter. Besides their filtered cloud output, these filters > also have an optional, second output which contains any points removed from > the input. > + Current filters include vtkRadiusOutlierRemoval, > vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an > implicit function). Some of these names are inspired by PCL > names. > + All filters are threaded using vtkSMPTools using a threaded locator > (vtkStaticPointLocator) so I believe that this is relatively fast, although > I have not done much testing. > + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote > that is very fast. > > As usual comments and suggestions are requested. In particular any > suggestions for other filters to write are welcome (to round out some of > the core functionality). The repository is in flux as I try crazy ideas and > try to educate myself, so be forewarned. > > Best, > W > > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Feb 27 16:37:34 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 27 Feb 2016 16:37:34 -0500 Subject: [vtk-developers] Midas issues with new images Message-ID: I'm seeing Midas problems with newly commited images. I see them with one of my patches as well as Will's remote module. Here is the message I get: -- Fetching "http://www.vtk.org/files/ExternalData/MD5/3f14feae2c853d44b773f8a867766b0e" CMake Error at /home/lorensen/ProjectsGIT/VTKGitlab/CMake/ExternalData.cmake:1005 (message): Object MD5=3f14feae2c853d44b773f8a867766b0e not found at: http://midas3.kitware.com/midas/api/rest?method=midas.bitstream.download&checksum=3f14feae2c853d44b773f8a867766b0e&algorithm=MD5 (wrong hash MD5=a0a85923331d4faa2ba6ff130a19d946) http://www.vtk.org/files/ExternalData/MD5/3f14feae2c853d44b773f8a867766b0e ("HTTP response code said error") Call Stack (most recent call first): /home/lorensen/ProjectsGIT/VTKGitlab/CMake/ExternalData.cmake:1027 (_ExternalData_download_object) The same happens on my merge request: https://open.cdash.org/viewBuildError.php?buildid=4255469 Bill From ken.martin at kitware.com Sun Feb 28 17:01:06 2016 From: ken.martin at kitware.com (Ken Martin) Date: Sun, 28 Feb 2016 17:01:06 -0500 Subject: [vtk-developers] Intel HD 3000 support (sandy bridge) Message-ID: I have been trying to get this GPU working as it is fairly common on older machines without dedicated GPUs. It is a bit of an odd beast and has been driving me a bit nuts. If you happen to have windows with that GPU and can run an experimental dashboard of this topic that would be helpful. https://gitlab.kitware.com/vtk/vtk/merge_requests/1241 Thanks Ken -- 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: From brad.king at kitware.com Mon Feb 29 10:31:56 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Feb 2016 10:31:56 -0500 Subject: [vtk-developers] Midas issues with new images In-Reply-To: References: Message-ID: <56D4646C.5010806@kitware.com> On 02/27/2016 04:37 PM, Bill Lorensen wrote: > I'm seeing Midas problems with newly commited images. I see them with > one of my patches as well as Will's remote module. The external data upload magic is not configured for remote modules AFAIK. The upload infrastructure depends on branches pushed to forks of VTK and so does not work for other repositories. > Here is the message > I get: > > -- Fetching "http://www.vtk.org/files/ExternalData/MD5/3f14feae2c853d44b773f8a867766b0e" > CMake Error at /home/lorensen/ProjectsGIT/VTKGitlab/CMake/ExternalData.cmake:1005 > (message): > Object MD5=3f14feae2c853d44b773f8a867766b0e not found at: > > http://midas3.kitware.com/midas/api/rest?method=midas.bitstream.download&checksum=3f14feae2c853d44b773f8a867766b0e&algorithm=MD5 > (wrong hash MD5=a0a85923331d4faa2ba6ff130a19d946) > http://www.vtk.org/files/ExternalData/MD5/3f14feae2c853d44b773f8a867766b0e > ("HTTP response code said error") > Call Stack (most recent call first): > /home/lorensen/ProjectsGIT/VTKGitlab/CMake/ExternalData.cmake:1027 > (_ExternalData_download_object) > > The same happens on my merge request: > https://open.cdash.org/viewBuildError.php?buildid=4255469 Where is 3f14feae2c853d44b773f8a867766b0e referenced? I don't see it referenced in Will's point-cloud module or in the main VTK. You can grep for it in *.md5 files. Thanks, -Brad From aashish.chaudhary at kitware.com Mon Feb 29 16:21:25 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 29 Feb 2016 16:21:25 -0500 Subject: [vtk-developers] ffmpeg compile failure on hythloth In-Reply-To: References: Message-ID: Thanks to Brad for testing it, the branch is now in master. Thanks, On Sat, Feb 27, 2016 at 1:50 AM, Aashish Chaudhary wrote: > I pushed a fix: https://gitlab.kitware.com/vtk/vtk/merge_requests/1281 > and also tested it manually on hythloth. > > Thanks, > Aashish > > On Sat, Feb 27, 2016 at 12:29 AM, Aashish Chaudhary > wrote: >> I am having a hard time reproducing this error on my system. the >> CodecID is now replaced by AVCodecID and it should have been found. I >> have to login to this machine to figure out the issue. >> >> - aashish >> >> On Fri, Feb 26, 2016 at 8:41 AM, Ken Martin wrote: >>> Awesome! >>> >>> On Fri, Feb 26, 2016 at 8:41 AM, Aashish Chaudhary >>> wrote: >>>> >>>> Ken, >>>> >>>> I am looking into it. Hoping to fix it today. >>>> >>>> - Aashish >>>> >>>> On Fri, Feb 26, 2016 at 8:39 AM, Ken Martin >>>> wrote: >>>> > >>>> > It looks like nightly hythloth has been failing to build for the past >>>> > three >>>> > days due to issues with FFMPEG. If that rings a bell, and you are not >>>> > already aware of it, then, I guess you are more aware of it now :-) >>>> > >>>> > -- >>>> > 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. >>>> > >>>> > _______________________________________________ >>>> > Powered by www.kitware.com >>>> > >>>> > Visit other Kitware open-source projects at >>>> > http://www.kitware.com/opensource/opensource.html >>>> > >>>> > Search the list archives at: >>>> > http://markmail.org/search/?q=vtk-developers >>>> > >>>> > Follow this link to subscribe/unsubscribe: >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> | Aashish Chaudhary >>>> | Technical Leader >>>> | Kitware Inc. >>>> | http://www.kitware.com/company/team/chaudhary.html >>> >>> >>> >>> >>> -- >>> 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. >> >> >> >> -- >> | Aashish Chaudhary >> | Technical Leader >> | Kitware Inc. >> | http://www.kitware.com/company/team/chaudhary.html > > > > -- > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > | http://www.kitware.com/company/team/chaudhary.html -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html From gpwright at gmail.com Mon Feb 29 17:25:42 2016 From: gpwright at gmail.com (Geoff Wright) Date: Mon, 29 Feb 2016 22:25:42 +0000 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Hi Will, I took a look at the new capabilities in vtkPointCloud, it looks very nice, definitely adding some much needed capabilities. I have a PCL pre-processing step that does a bunch of octree-based filtering prior to populating a vtkImageData and evaluating a subsequent vtk pipeline. Unfortunately I wasn't able to eliminate PCL from my hybrid PCL/vtk setup just yet. The problem is not really specific to vtkPointCloud, but I have found that the vtkStaticPointLocator is just very slow compared to pcl::octree::OctreePointCloudSearch. I have some algorithms that do a lot of octree searching and when I switch them over to use vtkStaticPointLocator an algorithm update takes around 200ms compared with 2ms using the octree from pcl. Fyi for my particular use case, I did some profiling and the vtk locator tends to get pretty bogged down in the following call stack: vtkDataArrayTemplate::GetTuple BucketList::FindClosestPointWithinRadius vtkStaticPointLocator::FindClosestPointWithinRadius If I were to guess I would suspect that its just busy doing a lot of memory allocation and deallocation. I think the pcl implementation benefits from a more low level API, avoiding memory allocation inside loops, and probably gets a boost from inline / precompiled headers too. Like I said, it's not specific to your vtkPointCloud module but the performance hit is very significant so I will stick with PCL for the moment. Regards, Geoff On Sat, Feb 27, 2016 at 10:28 AM Will Schroeder wrote: > Here's a quick update on point cloud processing in VTK. We've got an > initial base of decent capability going now, including (and I am absolutely > delighted about this) a surface extraction capability based on TSDF > (truncated signed distance functions). > > *Classes now running (in VTK/Remote/vtkPointCloud):* > vtkEuclideanClusterExtraction.h > vtkExtractHierarchicalBins.h > vtkExtractPointCloudPiece.h > vtkExtractPoints.h > vtkExtractSurface.h > vtkFitImplicitFunction.h > vtkHierarchicalBinningFilter.h > vtkPCACurvatureEstimation.h > vtkPCANormalEstimation.h > vtkPointCloudFilter.h > vtkRadiusOutlierRemoval.h > vtkSignedDistance.h > vtkStatisticalOutlierRemoval.h > vtkVoxelGrid.h > > *Surface extraction (in VTK/Remote/vtkPointCloud):* > We've build a pipeline of objects that perform rudimentary surface > extraction from a point cloud. There are three major parts: > 1. Generating normals - currently use vtkPCANormalEstimation, including > graph traversal to create consistently oriented normals. > 2. Compute the TSDF using vtkSignedDistance. > 3. Extract zero-crossing isocontour to generate surface > (vtkExtractSurface). > > Note that each of these parts will eventually be expanded by writing new > filters, for example I want to use in #1 Brad King's tensor voting (from > his PhD thesis ) to > compute better normals. For #2, based loosely on the Curless & Levoy > paper, we > can do better by using different interpolation kernels (see > PointInterpolation framework below) rather than the ad hoc probability > weights they use (to be added soon). Also for #2 we need to support > incremental updating. Finally, #3 is based on a modified Flying Edges > > algorithm so it is very fast :-) > > *Point Interpolation (in VTK/Filters/Points)* > We just pushed this in, it looks to be a very powerful, quite general > framework for performing data interpolation across point samples. It's > threaded, uses fast threaded locators, and has an abstraction for a family > of interpolation kernels (e.g., linear, gaussian, shepard, voronoi, > hopefully SPH) at some point soon, with more on the way. > > As usual any feedback is appreciated. Make sure you update both VTK and > the vtkPointCloud remote module. Please don't be shy, this is happening > really fast and I want to catch the inevitable stupid stuff as soon as > possible. > > Best, > W > > > On Thu, Jan 28, 2016 at 9:12 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> FYI- I have committed an initial set of filters for performing point >> cloud processing. Any feedback or suggestions are welcome as this is an >> initial prototype. The work is currently available as a remote module to >> VTK (vtkPointCloud) via this repository: >> https://gitlab.kitware.com/vtk/point-cloud.git >> >> A couple of notes: >> + Right now I am using vtkPolyData to represent the point cloud via a >> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >> save on memory. >> + The classes will process as input any vtkPointSet dataset >> + There is a general framework for filtering point clouds via the class >> vtkPointCloudFilter. Besides their filtered cloud output, these filters >> also have an optional, second output which contains any points removed from >> the input. >> + Current filters include vtkRadiusOutlierRemoval, >> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >> implicit function). Some of these names are inspired by PCL >> names. >> + All filters are threaded using vtkSMPTools using a threaded locator >> (vtkStaticPointLocator) so I believe that this is relatively fast, although >> I have not done much testing. >> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >> that is very fast. >> >> As usual comments and suggestions are requested. In particular any >> suggestions for other filters to write are welcome (to round out some of >> the core functionality). The repository is in flux as I try crazy ideas and >> try to educate myself, so be forewarned. >> >> Best, >> W >> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Feb 29 17:50:55 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 29 Feb 2016 17:50:55 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Geoff- This is exactly the feedback I need, thank you for doing this work! Is there any chance I can get my hands on a sample dataset? Also, did you try playing around with the binning dimensions (i.e., Divisions) and number of points per bucket....try setting these to a large number like 500^3 and 1 (there is very little penalty to doing this). Also did you try building this with TBB/threading enabled? There is no doubt that in certain situations a hierarchical locator is going to be faster than uniform binning, but so far the vtkStaticPointLocator is much faster than VTK's octree and kdtree in the tests I've used, so I'd like to see a representative workflow and work through the bottlenecks, and maybe implement other threaded locators. Best, W On Mon, Feb 29, 2016 at 5:25 PM, Geoff Wright wrote: > Hi Will, > > I took a look at the new capabilities in vtkPointCloud, it looks very > nice, definitely adding some much needed capabilities. I have a PCL > pre-processing step that does a bunch of octree-based filtering prior to > populating a vtkImageData and evaluating a subsequent vtk pipeline. > Unfortunately I wasn't able to eliminate PCL from my hybrid PCL/vtk setup > just yet. The problem is not really specific to vtkPointCloud, but I have > found that the vtkStaticPointLocator is just very slow compared to > pcl::octree::OctreePointCloudSearch. I have some algorithms that do a lot > of octree searching and when I switch them over to use > vtkStaticPointLocator an algorithm update takes around 200ms compared with > 2ms using the octree from pcl. > > Fyi for my particular use case, I did some profiling and the vtk locator > tends to get pretty bogged down in the following call stack: > vtkDataArrayTemplate::GetTuple > BucketList::FindClosestPointWithinRadius > vtkStaticPointLocator::FindClosestPointWithinRadius > > If I were to guess I would suspect that its just busy doing a lot of > memory allocation and deallocation. I think the pcl implementation > benefits from a more low level API, avoiding memory allocation inside > loops, and probably gets a boost from inline / precompiled headers too. > > Like I said, it's not specific to your vtkPointCloud module but the > performance hit is very significant so I will stick with PCL for the moment. > > Regards, > Geoff > > > > > On Sat, Feb 27, 2016 at 10:28 AM Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Here's a quick update on point cloud processing in VTK. We've got an >> initial base of decent capability going now, including (and I am absolutely >> delighted about this) a surface extraction capability based on TSDF >> (truncated signed distance functions). >> >> *Classes now running (in VTK/Remote/vtkPointCloud):* >> vtkEuclideanClusterExtraction.h >> vtkExtractHierarchicalBins.h >> vtkExtractPointCloudPiece.h >> vtkExtractPoints.h >> vtkExtractSurface.h >> vtkFitImplicitFunction.h >> vtkHierarchicalBinningFilter.h >> vtkPCACurvatureEstimation.h >> vtkPCANormalEstimation.h >> vtkPointCloudFilter.h >> vtkRadiusOutlierRemoval.h >> vtkSignedDistance.h >> vtkStatisticalOutlierRemoval.h >> vtkVoxelGrid.h >> >> *Surface extraction (in VTK/Remote/vtkPointCloud):* >> We've build a pipeline of objects that perform rudimentary surface >> extraction from a point cloud. There are three major parts: >> 1. Generating normals - currently use vtkPCANormalEstimation, including >> graph traversal to create consistently oriented normals. >> 2. Compute the TSDF using vtkSignedDistance. >> 3. Extract zero-crossing isocontour to generate surface >> (vtkExtractSurface). >> >> Note that each of these parts will eventually be expanded by writing new >> filters, for example I want to use in #1 Brad King's tensor voting (from >> his PhD thesis ) to >> compute better normals. For #2, based loosely on the Curless & Levoy >> paper, we >> can do better by using different interpolation kernels (see >> PointInterpolation framework below) rather than the ad hoc probability >> weights they use (to be added soon). Also for #2 we need to support >> incremental updating. Finally, #3 is based on a modified Flying Edges >> >> algorithm so it is very fast :-) >> >> *Point Interpolation (in VTK/Filters/Points)* >> We just pushed this in, it looks to be a very powerful, quite general >> framework for performing data interpolation across point samples. It's >> threaded, uses fast threaded locators, and has an abstraction for a family >> of interpolation kernels (e.g., linear, gaussian, shepard, voronoi, >> hopefully SPH) at some point soon, with more on the way. >> >> As usual any feedback is appreciated. Make sure you update both VTK and >> the vtkPointCloud remote module. Please don't be shy, this is happening >> really fast and I want to catch the inevitable stupid stuff as soon as >> possible. >> >> Best, >> W >> >> >> On Thu, Jan 28, 2016 at 9:12 AM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> FYI- I have committed an initial set of filters for performing point >>> cloud processing. Any feedback or suggestions are welcome as this is an >>> initial prototype. The work is currently available as a remote module to >>> VTK (vtkPointCloud) via this repository: >>> https://gitlab.kitware.com/vtk/point-cloud.git >>> >>> A couple of notes: >>> + Right now I am using vtkPolyData to represent the point cloud via a >>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>> save on memory. >>> + The classes will process as input any vtkPointSet dataset >>> + There is a general framework for filtering point clouds via the class >>> vtkPointCloudFilter. Besides their filtered cloud output, these filters >>> also have an optional, second output which contains any points removed from >>> the input. >>> + Current filters include vtkRadiusOutlierRemoval, >>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>> implicit function). Some of these names are inspired by PCL >>> names. >>> + All filters are threaded using vtkSMPTools using a threaded locator >>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>> I have not done much testing. >>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >>> that is very fast. >>> >>> As usual comments and suggestions are requested. In particular any >>> suggestions for other filters to write are welcome (to round out some of >>> the core functionality). The repository is in flux as I try crazy ideas and >>> try to educate myself, so be forewarned. >>> >>> Best, >>> W >>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Feb 23 12:02:52 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 23 Feb 2016 17:02:52 -0000 Subject: [vtk-developers] Volume rendering update In-Reply-To: References: Message-ID: I was playing with the Medical4 example last week, and vtkGPURayCastVolumeMapper managed to render shaded volumes at up to 1024x1024x768! Very fast loading, too, it took around 1 second to load. With the volume size at 1024x1024x1024, however, there was a wrap-around artifact. I'm guessing that it was due either to memory limitations, or due to integer overflow. Maybe a hardware issue, maybe the driver, hard to say when the data set itself is 2GB. This is a Mac (10.9.5) with AMD FirePro D700 6GB, what datatypes does the mapper use for the buffers? On Tue, Feb 23, 2016 at 9:43 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Hi all, > > We have made some significant improvements to volume rendering since our > last update (Ref: > https://blog.kitware.com/volume-rendering-enhancements-in-vtk/, > https://blog.kitware.com/volume-rendering-on-ios-and-android/). Below is > a list of tasks that are either nearly completed and or are in VTK master > as of today. > > > - > > Features/updates > - > > Big volume support - Fixing failing tests. The idea is to split > volume into smaller volumes and render them piecewise. > - > > 3x-5x clipping plane performance - For the same parameters, > clipping is much faster now, the trick is to skip voxels that are clipped > by planes. > - > > Depth and color data capture - User can use RenderToImage to render > to a FBO and get depth and color texture which then could be utilized for > other operations. > - > > Bugs > - > > Fixed gradient opacity not working for more than one components > - > > Fixed clipping plane location is wrong in certain cases. > - > > Fixed volume rendering invalid or bad for cell data > - > > Fixed edges issue when rendering in multiple pieces (hard edges) > - > > Fixed volume rendering not working in remote rendering mode with > image reduction factor > 1 > - > > Fixed volume rendering not working in client-server mode > - > > Fixed volume disappears when changing parameters > - > > Fixed volume rendering not using the correct sampling distance > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1024x1024x1024.png Type: image/png Size: 266561 bytes Desc: not available URL: