From victorsv at gmail.com  Tue Mar  1 03:00:16 2016
From: victorsv at gmail.com (victor sv)
Date: Tue, 1 Mar 2016 09:00:16 +0100
Subject: [vtk-developers] PNG problem
In-Reply-To: <CACJ=gTh-B4o+DngPfVs8=9cyTYRe2+sHdv1BBKobZ-H7n3qT3w@mail.gmail.com>
References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local>
 <CACJ=gTi-yE8+vg3iLieK_Xr3im6ZjwUO39HL_H=-D6wS8m16Vw@mail.gmail.com>
 <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local>
 <CACJ=gTj7-1DUTR1vavrure5Y4hKhq4zbQ=78-DB+i_Mw6Wvbeg@mail.gmail.com>
 <9760009C9287EB4EB29C17692C0F5DE52B47F3D1@SBS.CSCA.local>
 <CACJ=gTh-B4o+DngPfVs8=9cyTYRe2+sHdv1BBKobZ-H7n3qT3w@mail.gmail.com>
Message-ID: <CA+Wz_FxoeY+bEEfVip4LYptGyO0Px0iF3bWpLw+QwrbavEw-JA@mail.gmail.com>

Hi all,

I get a black picture when exporting the screen using
vtkwindowtoimagefilter with any supported format (jpg, png, bmp, tiff)

My SO is an Ubuntu 14.04 with VTK v5.8 and I'm using the python bindings
for VTK.

The solution proposed by Joachim works for me:

pRenderWindow.Render()
windowToImageFilter.ReadFrontBufferOff()
windowToImageFilter.Update()

This issue does not appear in all VTK versions and I'm not able to identify
the source of the poblem ... Any suggestion?

I dont understand what ReadFrontBufferOff() does. Anyone can explain why i
need to do that?

Thanks in advance,
V?ctor


2015-07-24 10:24 GMT+02:00 Joachim Pouderoux <joachim.pouderoux at kitware.com>
:

> Could you try to add a pRenderWindow->Render(); before calling
> windowToImageFilter->Update(); ?
> Do that and try with and ReadFrontBufferOff() and then with
> ReadFrontBufferOn().
>
>
> Joachim
>
> *Joachim Pouderoux*
>
> *PhD, Technical Expert*
> *Kitware SAS <http://www.kitware.fr>*
>
>
> 2015-07-24 9:44 GMT+02:00 Manole Buican <manole.buican at terrasigna.com>:
>
>> Hi Joachim,
>>
>>
>>
>> I tried what you suggested, but.. the same results. The system involved
>> is a machine with Genuine Intel (R) CPU, U7300 @ 1.3 GHz, RAM 4 GB, Win 7,
>> 64 bits and Mobile Intel(R) 4 Series Express Chipset Family video card.
>>
>>
>>
>> Thx,
>>
>> Manole
>>
>>
>> ------------------------------
>> *From:* Joachim Pouderoux [joachim.pouderoux at kitware.com]
>> *Sent:* Wednesday, July 22, 2015 6:08 PM
>>
>> *To:* Manole Buican
>> *Cc:* vtk-developers at vtk.org
>> *Subject:* Re: [vtk-developers] PNG problem
>>
>> Can you try to add windowToImageFilter->ReadFrontBufferOff(); before
>> calling Update()?
>>
>> *Joachim Pouderoux*
>>
>> *PhD, Technical Expert*
>> *Kitware SAS <http://www.kitware.fr>*
>>
>>
>> 2015-07-22 17:07 GMT+02:00 Manole Buican <manole.buican at terrasigna.com>:
>>
>>> Hi Joachim
>>>
>>>
>>>
>>> It's a valid white file.
>>>
>>>
>>>
>>> Manole
>>>
>>>
>>> ------------------------------
>>> *From:* Joachim Pouderoux [joachim.pouderoux at kitware.com]
>>> *Sent:* Wednesday, July 22, 2015 6:05 PM
>>> *To:* Manole Buican
>>> *Cc:* vtk-developers at vtk.org
>>> *Subject:* Re: [vtk-developers] PNG problem
>>>
>>> Hi Manole,
>>>
>>> Is the the 2KB PNG file valid and defines an empty/all black image ?
>>>
>>> Joachim
>>>
>>> *Joachim Pouderoux*
>>>
>>> *PhD, Technical Expert*
>>> *Kitware SAS <http://www.kitware.fr>*
>>>
>>>
>>> 2015-07-22 16:47 GMT+02:00 Manole Buican <manole.buican at terrasigna.com>:
>>>
>>>> Hi all,
>>>>
>>>> Code like
>>>>
>>>> void DlgResVis2D::saveTmpPicture(QString &filename)
>>>> {
>>>>         vtkNew<vtkWindowToImageFilter> windowToImageFilter;
>>>>         vtkWindow* pRenderWindow = (vtkWindow *)
>>>> m_pView->GetRenderWindow();
>>>>
>>>>         windowToImageFilter->SetInput(pRenderWindow);
>>>>         windowToImageFilter->SetMagnification(1);
>>>>         windowToImageFilter->SetInputBufferTypeToRGBA();
>>>>         windowToImageFilter->Update();
>>>>
>>>>         vtkSmartPointer <vtkPNGWriter> writer = vtkSmartPointer
>>>> <vtkPNGWriter>::New();
>>>>         writer->SetFileName(filename.toAscii());
>>>>
>>>> writer->SetInputConnection(windowToImageFilter->GetOutputPort());
>>>>         writer->Write();
>>>> }
>>>>
>>>> exports a picture in PNG on 5 computers. On the sixth computer produce
>>>> only a 2KB empty PNG file (no error is prompted), while on each other
>>>> 5 computers produce 35KB PNG file with the same image.
>>>> Does anybody encounter the same behavior?
>>>>
>>>> Thx in advance,
>>>> Manole Buican
>>>>
>>>> _______________________________________________
>>>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/efc315ec/attachment.html>

From will.schroeder at kitware.com  Tue Mar  1 06:12:21 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Tue, 1 Mar 2016 06:12:21 -0500
Subject: [vtk-developers] vtkPointCloud remote module
In-Reply-To: <CAEiDrtXJLjrpH77oL=UitQcofJLV3Gbcb8=GPw7koOffYC+mPA@mail.gmail.com>
References: <CAEiDrtUNBki_2EqLa5xQ+L7DSFS_CQbweoSTc+qQuur1rH-FYw@mail.gmail.com>
 <CAEiDrtVdkJTzkfo4S63VBtNE5S=V3=VKfJPSut+wCOuFJ92BfA@mail.gmail.com>
 <CAG1bWAQOU7neQyp=T49ExfzrY1CM8u6DisagN3bcca9TEwvc+g@mail.gmail.com>
 <CAEiDrtXJLjrpH77oL=UitQcofJLV3Gbcb8=GPw7koOffYC+mPA@mail.gmail.com>
Message-ID: <CAEiDrtXQ4Ctk_wSUe4yqG5iO7485C=Ua8K=fFJO4sfciFKM1uw@mail.gmail.com>

Geoff-

Some additional notes:
- vtkVoxelGrid does not invoke
vtkStaticPointLocator::FindClosestPointWithinRadius so something else is
being tested.
- The methods in vtkStaticPointLocator do not repeatedly
allocate/deallocate memory. Initially yes, but then the memory resource is
reused.
- As a point of reference, depending on the configuration for
vtkStaticPointLocator, on my system I see 250,000 probes/sec
(FindClosestNPoints N=10) about 2x faster than vtkPointLocator (and the
vtkOctreePointLocator). Although faster when probing, the real significant
difference is the time to construct and delete the static point locator
which is orders of magnitude faster than the incremental point locator,
octree, etc
- These rough numbers are for randomized point clouds. With locally dense,
but elsewhere sparse point clouds, there may be some serious performance
hits (which is why any data, or testing scripts, you might have would be
helpful).

Best,
W

On Mon, Feb 29, 2016 at 5:50 PM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> 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 <gpwright at gmail.com> 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<float>::GetTuple
>> BucketList<int>::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 <http://www.kitware.com/publications/item/view/1253>) to
>>> compute better normals. For #2, based loosely on the Curless & Levoy
>>> <https://graphics.stanford.edu/papers/volrange/volrange.pdf> 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
>>> <https://www.researchgate.net/publication/282975362_Flying_Edges_A_High-Performance_Scalable_Isocontouring_Algorithm>
>>> 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
>>>> <http://pointclouds.org/> 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
>



-- 
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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/8b3e53a6/attachment-0001.html>

From dave.demarle at kitware.com  Tue Mar  1 10:18:21 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 1 Mar 2016 10:18:21 -0500
Subject: [vtk-developers] google summer of code 2016 - project ideas and
	mentor volunteers
In-Reply-To: <CANjZAi965G_fvqY3KneENLo2trof2B_OqpMYw9nm=DD07d9A2g@mail.gmail.com>
References: <CANjZAi965G_fvqY3KneENLo2trof2B_OqpMYw9nm=DD07d9A2g@mail.gmail.com>
Message-ID: <CANjZAi8BP4byHOP5xHvxSHDFHr+A=H8hBc+2fk-k2bzjj3YcBg@mail.gmail.com>

Hello,

Unfortunately VTK did not make the cut for GSoC 2016. We will apply again
next year, so if you come up with a great project ideas please do add it to
the idea list wiki page.

thanks


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Feb 9, 2016 at 11:02 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/7e1a651b/attachment.html>

From ken.martin at kitware.com  Tue Mar  1 10:49:23 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Tue, 1 Mar 2016 10:49:23 -0500
Subject: [vtk-developers] New iOS app
Message-ID: <CANXz0SYZ8GaQPt8bSMUrNqFu_Jssbq8uKiLGeJFtma6fR0Bfig@mail.gmail.com>

I have taken the updated gesture code in VTK and created a new example iOS
app named VTK PlaneView (PlainView maybe? ;-) that cleans up a number of
rough edges in previous iOS examples. This example is a simple VTK app that
lets you probe a dataset with a plane. It is based on storyboards. It shows
how to add a settings page and how to load data from the iCloud. It
supports loading data from VTK XML Unstructured Grids, Rectilinear grids,
Structured Grids, and Image Data. Adding dropbox support would be a pretty
easy extension as well. The probe plane uses the probe widget and the probe
widget responds to pinch gestures as well. The code is currently in the
topic:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1221

It is a simple example but a nice starting point for VTK based storyboard
apps. The app has been submitted and approved by the itunes store so you
can find it here (it is free of course)  It runs on ES 3 capable devices
such as iPhone 5s or later and iPad Air or later.

https://itunes.apple.com/us/app/vtk-planeview/id1084391975?mt=8

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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/419f20e9/attachment.html>

From aashish.chaudhary at kitware.com  Tue Mar  1 11:11:28 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Tue, 1 Mar 2016 11:11:28 -0500
Subject: [vtk-developers] New iOS app
In-Reply-To: <CANXz0SYZ8GaQPt8bSMUrNqFu_Jssbq8uKiLGeJFtma6fR0Bfig@mail.gmail.com>
References: <CANXz0SYZ8GaQPt8bSMUrNqFu_Jssbq8uKiLGeJFtma6fR0Bfig@mail.gmail.com>
Message-ID: <CAEw35Z8ga9UU8vUc6kDCmhVSVPxdcPGQSb3F=woYLGHvoxOHPA@mail.gmail.com>

This is awesome Ken!

- aashish

On Tue, Mar 1, 2016 at 10:49 AM, Ken Martin <ken.martin at kitware.com> wrote:
>
> I have taken the updated gesture code in VTK and created a new example iOS
> app named VTK PlaneView (PlainView maybe? ;-) that cleans up a number of
> rough edges in previous iOS examples. This example is a simple VTK app that
> lets you probe a dataset with a plane. It is based on storyboards. It shows
> how to add a settings page and how to load data from the iCloud. It supports
> loading data from VTK XML Unstructured Grids, Rectilinear grids, Structured
> Grids, and Image Data. Adding dropbox support would be a pretty easy
> extension as well. The probe plane uses the probe widget and the probe
> widget responds to pinch gestures as well. The code is currently in the
> topic:
>
> https://gitlab.kitware.com/vtk/vtk/merge_requests/1221
>
> It is a simple example but a nice starting point for VTK based storyboard
> apps. The app has been submitted and approved by the itunes store so you can
> find it here (it is free of course)  It runs on ES 3 capable devices such as
> iPhone 5s or later and iPad Air or later.
>
> https://itunes.apple.com/us/app/vtk-planeview/id1084391975?mt=8
>
> 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.
>
> _______________________________________________
> 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 sean at rogue-research.com  Tue Mar  1 12:39:34 2016
From: sean at rogue-research.com (Sean McBride)
Date: Tue, 1 Mar 2016 12:39:34 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
Message-ID: <20160301173934.364091623@mail.rogue-research.com>

On Fri, 15 Jan 2016 10:57:36 -0500, Berk Geveci said:

>In an effort to address a bug reported on the mailing list, I ended up
>making a change to the way the pipeline is updated. I made a minor change
>to the way update behaves but more importantly, I'd like to make an API
>change that is biggish.

Berk,

After rebuilding my app with VTK master I've run into this.

I just went through the change with git show f020ebb6 and had 2 comments on the code change:

1) Did you mean to commit that commented code in Accelerators/Piston/vtkPistonMapper.cxx ?

2) 

+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);

Couldn't those 'extents' params be const?  I know many VTK API are not very const friendly, but seems a shame to perpetuate that with new API.

>Here is how an algorithm is updated currently.
>
>anAlgorithm->Update();
>
>If you want the algorithm to produce a particular subset in space or time,
>you need to do this:
>
>anAlgorithm->UpdateInformation();
>anAlgorithm->SetUpdateExtent(0, 2, 0);
>anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1);
>anAlgorithm->SetUpdateTimeStep(0.5);
>anAlgorithm->Update();

My app has a few of this pattern:

 slicer->UpdateInformation();
 slicer->SetUpdateExtentToWholeExtent();
 slicer->Update();

do I understand correctly that I can now just do:

 slicer->UpdateWholeExtent();

>Here is the branch that passes all of the tests:
>
>https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change

Shame that link is dead just 6 weeks later.  Makes it harder to research what/when changes broke things... :(

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From burlen.loring at gmail.com  Tue Mar  1 12:50:44 2016
From: burlen.loring at gmail.com (Burlen Loring)
Date: Tue, 1 Mar 2016 09:50:44 -0800
Subject: [vtk-developers] parallel surface lic broken in opengl 2
Message-ID: <56D5D674.2010707@gmail.com>

Hi All,

Writing to report that in latest version of ParaView the surface lic is 
broken with the OpenGL2 back end. I experimented with it using PV5 an 
nvidia gtx 980 with fairly recent driver, and saw a number of issues, 
including completely "trashed" pixels and when rendering in parallel one 
can see "lines" at process boundaries as if the algorithm is serial.

These regression are a shame because it took quite a lot of effort to 
correctly parallelize it, and make it work reliably across a wide 
spectrum of os,gl, and device variations. There is an explanation of the 
parallel algorithm linked below. Hopefully those who are working on 
porting to opengl 2 are aware of and will take a look at these regressions.

Note, that all of the surface LIC classes live VTK but because IceT and 
the compositing classes all live in ParaView, the ctest for parallel 
operation are in ParaView. So another question is, given the importance 
of parallel rendering, should IceT and parallel rendering capability be 
included in VTK?

Burlen

https://github.com/burlen/astronum2014/blob/master/paper/loring-astronum-2014.pdf

From ken.martin at kitware.com  Tue Mar  1 13:38:50 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Tue, 1 Mar 2016 13:38:50 -0500
Subject: [vtk-developers] parallel surface lic broken in opengl 2
In-Reply-To: <56D5D674.2010707@gmail.com>
References: <56D5D674.2010707@gmail.com>
Message-ID: <CANXz0SYF7FAtXXeB2RANP9Hp2zhm6u6xOdez8mWkLFfKzafVzA@mail.gmail.com>

I believe there are 4 main LICs in VTK OpenGL2, serial, parallel, serial +
composite_dataset, parallel + composite_dataset. I believe the first three
work and I think trashed pixels have been fixed recently, the VTK tests all
pass. yay!

The parallel + composite_dataset case is known to be broken, more
specifically the class does not exist. PV needs this class in parallel and
I think it falls back to the serial implementation as that class has been
written which is why you see boundary issues.

My gut feeling is that instead of writing that class, the LIC code should
be reworked as a render pass that gets assigned to mappers. That way adding
lic to a mapper is fairly easy. The way I converted the original code to
OpenGL2 combines the LIC complexity into the middle of the mapper
complexity which is a bad mix especially for the parallel +
composite_dataset case.

Maybe it is easier than I think, but currently I suspect it would take a
few weeks of dedicated effort which is why it is still in the queue.




On Tue, Mar 1, 2016 at 12:50 PM, Burlen Loring <burlen.loring at gmail.com>
wrote:

> Hi All,
>
> Writing to report that in latest version of ParaView the surface lic is
> broken with the OpenGL2 back end. I experimented with it using PV5 an
> nvidia gtx 980 with fairly recent driver, and saw a number of issues,
> including completely "trashed" pixels and when rendering in parallel one
> can see "lines" at process boundaries as if the algorithm is serial.
>
> These regression are a shame because it took quite a lot of effort to
> correctly parallelize it, and make it work reliably across a wide spectrum
> of os,gl, and device variations. There is an explanation of the parallel
> algorithm linked below. Hopefully those who are working on porting to
> opengl 2 are aware of and will take a look at these regressions.
>
> Note, that all of the surface LIC classes live VTK but because IceT and
> the compositing classes all live in ParaView, the ctest for parallel
> operation are in ParaView. So another question is, given the importance of
> parallel rendering, should IceT and parallel rendering capability be
> included in VTK?
>
> Burlen
>
>
> https://github.com/burlen/astronum2014/blob/master/paper/loring-astronum-2014.pdf
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/3e7118b4/attachment.html>

From david.gobbi at gmail.com  Tue Mar  1 13:42:36 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 1 Mar 2016 11:42:36 -0700
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <20160301173934.364091623@mail.rogue-research.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
Message-ID: <CANwS1=HbvZ3aVPft=Q1b9hC-CyO3wZHNdB-YyzWO_yJmzh84UQ@mail.gmail.com>

A couple links that will answer some questions (#2 is the "missing link"):

https://gitlab.kitware.com/vtk/vtk/merge_requests/1155
https://gitlab.kitware.com/vtk/vtk/merge_requests/1090

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/efeeb713/attachment.html>

From berk.geveci at kitware.com  Tue Mar  1 14:01:01 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Tue, 1 Mar 2016 14:01:01 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <20160301173934.364091623@mail.rogue-research.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
Message-ID: <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>

> 1) Did you mean to commit that commented code in
Accelerators/Piston/vtkPistonMapper.cxx ?

Kind of :-) Piston is not moving forward because it was replaced by VTK-m.
So before VTK 8, we will yank the Piston module out. That was quick (and
dirty) way of making it compile with my changes. It is not worth the effort
to make it work at this point.

> do I understand correctly that I can now just do:
>
> slicer->UpdateWholeExtent();

Yes. I didn't add this API btw. It was already there.

>>Here is the branch that passes all of the tests:
>>
>>https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change
>
> Shame that link is dead just 6 weeks later.  Makes it harder to research
what/when changes broke things... :(

That's totally my bad. I pointed to the branch on my fork and then deleted
the branch after the merge. Here is the permanent link:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1090

Best,
-berk

On Tue, Mar 1, 2016 at 12:39 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Fri, 15 Jan 2016 10:57:36 -0500, Berk Geveci said:
>
> >In an effort to address a bug reported on the mailing list, I ended up
> >making a change to the way the pipeline is updated. I made a minor change
> >to the way update behaves but more importantly, I'd like to make an API
> >change that is biggish.
>
> Berk,
>
> After rebuilding my app with VTK master I've run into this.
>
> I just went through the change with git show f020ebb6 and had 2 comments
> on the code change:
>
> 1) Did you mean to commit that commented code in
> Accelerators/Piston/vtkPistonMapper.cxx ?
>
> 2)
>
> +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);
>
> Couldn't those 'extents' params be const?  I know many VTK API are not
> very const friendly, but seems a shame to perpetuate that with new API.
>
> >Here is how an algorithm is updated currently.
> >
> >anAlgorithm->Update();
> >
> >If you want the algorithm to produce a particular subset in space or time,
> >you need to do this:
> >
> >anAlgorithm->UpdateInformation();
> >anAlgorithm->SetUpdateExtent(0, 2, 0);
> >anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1);
> >anAlgorithm->SetUpdateTimeStep(0.5);
> >anAlgorithm->Update();
>
> My app has a few of this pattern:
>
>  slicer->UpdateInformation();
>  slicer->SetUpdateExtentToWholeExtent();
>  slicer->Update();
>
> do I understand correctly that I can now just do:
>
>  slicer->UpdateWholeExtent();
>
> >Here is the branch that passes all of the tests:
> >
> >https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change
>
> Shame that link is dead just 6 weeks later.  Makes it harder to research
> what/when changes broke things... :(
>
> Thanks,
>
> --
> ____________________________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/1427ae33/attachment-0001.html>

From burlen.loring at gmail.com  Tue Mar  1 14:37:52 2016
From: burlen.loring at gmail.com (Burlen Loring)
Date: Tue, 1 Mar 2016 11:37:52 -0800
Subject: [vtk-developers] parallel surface lic broken in opengl 2
In-Reply-To: <CANXz0SYF7FAtXXeB2RANP9Hp2zhm6u6xOdez8mWkLFfKzafVzA@mail.gmail.com>
References: <56D5D674.2010707@gmail.com>
 <CANXz0SYF7FAtXXeB2RANP9Hp2zhm6u6xOdez8mWkLFfKzafVzA@mail.gmail.com>
Message-ID: <56D5EF90.4060602@gmail.com>

Great, sounds like you guys are aware of the issues. Thanks for working 
on it!

On 03/01/2016 10:38 AM, Ken Martin wrote:
> I believe there are 4 main LICs in VTK OpenGL2, serial, parallel, 
> serial + composite_dataset, parallel + composite_dataset. I believe 
> the first three work and I think trashed pixels have been fixed 
> recently, the VTK tests all pass. yay!
>
> The parallel + composite_dataset case is known to be broken, more 
> specifically the class does not exist. PV needs this class in parallel 
> and I think it falls back to the serial implementation as that class 
> has been written which is why you see boundary issues.
>
> My gut feeling is that instead of writing that class, the LIC code 
> should be reworked as a render pass that gets assigned to mappers. 
> That way adding lic to a mapper is fairly easy. The way I converted 
> the original code to OpenGL2 combines the LIC complexity into the 
> middle of the mapper complexity which is a bad mix especially for the 
> parallel + composite_dataset case.
>
> Maybe it is easier than I think, but currently I suspect it would take 
> a few weeks of dedicated effort which is why it is still in the queue.
>
>
>
>
> On Tue, Mar 1, 2016 at 12:50 PM, Burlen Loring 
> <burlen.loring at gmail.com <mailto:burlen.loring at gmail.com>> wrote:
>
>     Hi All,
>
>     Writing to report that in latest version of ParaView the surface
>     lic is broken with the OpenGL2 back end. I experimented with it
>     using PV5 an nvidia gtx 980 with fairly recent driver, and saw a
>     number of issues, including completely "trashed" pixels and when
>     rendering in parallel one can see "lines" at process boundaries as
>     if the algorithm is serial.
>
>     These regression are a shame because it took quite a lot of effort
>     to correctly parallelize it, and make it work reliably across a
>     wide spectrum of os,gl, and device variations. There is an
>     explanation of the parallel algorithm linked below. Hopefully
>     those who are working on porting to opengl 2 are aware of and will
>     take a look at these regressions.
>
>     Note, that all of the surface LIC classes live VTK but because
>     IceT and the compositing classes all live in ParaView, the ctest
>     for parallel operation are in ParaView. So another question is,
>     given the importance of parallel rendering, should IceT and
>     parallel rendering capability be included in VTK?
>
>     Burlen
>
>     https://github.com/burlen/astronum2014/blob/master/paper/loring-astronum-2014.pdf
>     _______________________________________________
>     Powered by www.kitware.com <http://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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/20d3cb83/attachment.html>

From sean at rogue-research.com  Tue Mar  1 15:52:51 2016
From: sean at rogue-research.com (Sean McBride)
Date: Tue, 1 Mar 2016 15:52:51 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
Message-ID: <20160301205251.370840783@mail.rogue-research.com>

On Tue, 1 Mar 2016 14:01:01 -0500, Berk Geveci said:

>> do I understand correctly that I can now just do:
>>
>> slicer->UpdateWholeExtent();
>
>Yes. I didn't add this API btw. It was already there.

Right, which is great, because it'll then work with 6 & 7!

Here's a fix to the docs re const:

<https://gitlab.kitware.com/vtk/vtk/merge_requests/1292>

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 sean at rogue-research.com  Tue Mar  1 15:53:25 2016
From: sean at rogue-research.com (Sean McBride)
Date: Tue, 1 Mar 2016 15:53:25 -0500
Subject: [vtk-developers] vtkPointHandleRepresentation3D dead store warning
	from cppcheck
Message-ID: <20160301205325.405832957@mail.rogue-research.com>

Hi all,

I tried writing to <michael.jeulinl at kitware.com> per git blame, but the address bounces, so...

I'm still toying with enabling cppcheck dead assignment warnings and it found in vtkPointHandleRepresentation3D::StartWidgetInteraction():

  vtkAssemblyPath* path = this->GetAssemblyPath(
    startEventPos[0], startEventPos[1], 0., this->CursorPicker);

  path = this->CursorPicker->GetPath();

from commit ec0732ba83d4f3456737d278e699add0117ec248.

The change made the 1st assignment to 'path' lost... what should this code be doing?

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 gpwright at gmail.com  Tue Mar  1 17:28:36 2016
From: gpwright at gmail.com (Geoff Wright)
Date: Tue, 01 Mar 2016 22:28:36 +0000
Subject: [vtk-developers] vtkPointCloud remote module
In-Reply-To: <CAEiDrtXQ4Ctk_wSUe4yqG5iO7485C=Ua8K=fFJO4sfciFKM1uw@mail.gmail.com>
References: <CAEiDrtUNBki_2EqLa5xQ+L7DSFS_CQbweoSTc+qQuur1rH-FYw@mail.gmail.com>
 <CAEiDrtVdkJTzkfo4S63VBtNE5S=V3=VKfJPSut+wCOuFJ92BfA@mail.gmail.com>
 <CAG1bWAQOU7neQyp=T49ExfzrY1CM8u6DisagN3bcca9TEwvc+g@mail.gmail.com>
 <CAEiDrtXJLjrpH77oL=UitQcofJLV3Gbcb8=GPw7koOffYC+mPA@mail.gmail.com>
 <CAEiDrtXQ4Ctk_wSUe4yqG5iO7485C=Ua8K=fFJO4sfciFKM1uw@mail.gmail.com>
Message-ID: <CAG1bWAT2nuzn31qswi-hjaNvyz4-7H2xXKH1LnAgob__Ho9pdw@mail.gmail.com>

Hi Will,

I was using TBB enabled.  I tried changing the dimensions and number of
points per bucket but it didn't improve much.  I was not using vtkVoxelGrid
yet, just a combination of vtkPolyData and vtkStaticPointLocator to replace
the PCL part.  That's what I meant when I said this performance issue is
not specific to vtkPointCloud.  I could probably use vtkVoxelGrid but it
might need some tweaks to support realtime incoming data without the input
data structure growing indefinitely.  I'm managing that myself at the
moment.

I can't share my exact dataset because it is proprietary but I made an
example for you that I believe replicates a similar scenario.  It uses a
publicly available dataset (one of the PCL demo datasets which is called
bunny).  Take a look:

https://github.com/gpwright/pcl_benchmark

It does 5000 random lookups using PCL and then 5000 using VTK.  When I run
that I get the following output:

PCL did 5000 in 0.082

VTK did 5000 in 4.039


Let me know if you have a chance to try it out, would be curious if there
are any easy fixes.


G







On Tue, Mar 1, 2016 at 6:12 AM Will Schroeder <will.schroeder at kitware.com>
wrote:

> Geoff-
>
> Some additional notes:
> - vtkVoxelGrid does not invoke
> vtkStaticPointLocator::FindClosestPointWithinRadius so something else is
> being tested.
> - The methods in vtkStaticPointLocator do not repeatedly
> allocate/deallocate memory. Initially yes, but then the memory resource is
> reused.
> - As a point of reference, depending on the configuration for
> vtkStaticPointLocator, on my system I see 250,000 probes/sec
> (FindClosestNPoints N=10) about 2x faster than vtkPointLocator (and the
> vtkOctreePointLocator). Although faster when probing, the real significant
> difference is the time to construct and delete the static point locator
> which is orders of magnitude faster than the incremental point locator,
> octree, etc
> - These rough numbers are for randomized point clouds. With locally dense,
> but elsewhere sparse point clouds, there may be some serious performance
> hits (which is why any data, or testing scripts, you might have would be
> helpful).
>
> Best,
> W
>
> On Mon, Feb 29, 2016 at 5:50 PM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> 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 <gpwright at gmail.com> 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<float>::GetTuple
>>> BucketList<int>::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
>>>> <http://www.kitware.com/publications/item/view/1253>) to compute
>>>> better normals. For #2, based loosely on the Curless & Levoy
>>>> <https://graphics.stanford.edu/papers/volrange/volrange.pdf> 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
>>>> <https://www.researchgate.net/publication/282975362_Flying_Edges_A_High-Performance_Scalable_Isocontouring_Algorithm>
>>>> 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
>>>>> <http://pointclouds.org/> 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
>>
>
>
>
> --
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/6eb375fb/attachment-0001.html>

From david.gobbi at gmail.com  Wed Mar  2 14:12:08 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 2 Mar 2016 12:12:08 -0700
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <20160301205251.370840783@mail.rogue-research.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
Message-ID: <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>

Hi Berk,

One of the things that I'm not quite sure about is, why is it permitted to
call algorithm->UpdateExtent() with no arguments?

  int UpdateExtent(const int extents[6]=0)

If I understand the code, UpdateExtent() with no args is the same as
Update().  It seems dangerous to allow this, because a programmer could
easily type UpdateExtent() by accident instead of UpdateWholeExtent(),
especially if they have autocompletion turned on in their code editor (and
especially because Update() and UpdateWholeExtent() give the same result
most of the time).

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160302/4cc070ea/attachment.html>

From berk.geveci at kitware.com  Wed Mar  2 15:08:12 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 2 Mar 2016 15:08:12 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
Message-ID: <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>

Ugh. That's a typo (probably copy & paste error). If you look at the
implementation, it actually doesn't check for NULL pointer. I am swamped
now. Do you have a few cycles to push a fix?

On Wed, Mar 2, 2016 at 2:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Berk,
>
> One of the things that I'm not quite sure about is, why is it permitted to
> call algorithm->UpdateExtent() with no arguments?
>
>   int UpdateExtent(const int extents[6]=0)
>
> If I understand the code, UpdateExtent() with no args is the same as
> Update().  It seems dangerous to allow this, because a programmer could
> easily type UpdateExtent() by accident instead of UpdateWholeExtent(),
> especially if they have autocompletion turned on in their code editor (and
> especially because Update() and UpdateWholeExtent() give the same result
> most of the time).
>
>  - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160302/69c6699d/attachment.html>

From david.gobbi at gmail.com  Wed Mar  2 15:12:44 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 2 Mar 2016 13:12:44 -0700
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
 <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
Message-ID: <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>

Will do.

On Wed, Mar 2, 2016 at 1:08 PM, Berk Geveci <berk.geveci at kitware.com> wrote:

> Ugh. That's a typo (probably copy & paste error). If you look at the
> implementation, it actually doesn't check for NULL pointer. I am swamped
> now. Do you have a few cycles to push a fix?
>
> On Wed, Mar 2, 2016 at 2:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>
>> Hi Berk,
>>
>> One of the things that I'm not quite sure about is, why is it permitted
>> to call algorithm->UpdateExtent() with no arguments?
>>
>>   int UpdateExtent(const int extents[6]=0)
>>
>> If I understand the code, UpdateExtent() with no args is the same as
>> Update().  It seems dangerous to allow this, because a programmer could
>> easily type UpdateExtent() by accident instead of UpdateWholeExtent(),
>> especially if they have autocompletion turned on in their code editor (and
>> especially because Update() and UpdateWholeExtent() give the same result
>> most of the time).
>>
>>  - David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160302/34b725e7/attachment.html>

From sean at rogue-research.com  Wed Mar  2 15:32:34 2016
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 2 Mar 2016 15:32:34 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
 <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
 <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>
Message-ID: <20160302203234.1315769609@mail.rogue-research.com>

I guess that obsoletes this:
<https://gitlab.kitware.com/vtk/vtk/merge_requests/1292>

Maybe you could fix that up at the same time David?

Sean


On Wed, 2 Mar 2016 13:12:44 -0700, David Gobbi said:

>Will do.
>
>On Wed, Mar 2, 2016 at 1:08 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
>
>> Ugh. That's a typo (probably copy & paste error). If you look at the
>> implementation, it actually doesn't check for NULL pointer. I am swamped
>> now. Do you have a few cycles to push a fix?
>>
>> On Wed, Mar 2, 2016 at 2:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>>> Hi Berk,
>>>
>>> One of the things that I'm not quite sure about is, why is it permitted
>>> to call algorithm->UpdateExtent() with no arguments?
>>>
>>>   int UpdateExtent(const int extents[6]=0)
>>>
>>> If I understand the code, UpdateExtent() with no args is the same as
>>> Update().  It seems dangerous to allow this, because a programmer could
>>> easily type UpdateExtent() by accident instead of UpdateWholeExtent(),
>>> especially if they have autocompletion turned on in their code editor (and
>>> especially because Update() and UpdateWholeExtent() give the same result
>>> most of the time).



From david.gobbi at gmail.com  Wed Mar  2 15:34:15 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 2 Mar 2016 13:34:15 -0700
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <20160302203234.1315769609@mail.rogue-research.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
 <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
 <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>
 <20160302203234.1315769609@mail.rogue-research.com>
Message-ID: <CANwS1=H+1S7xHYKOHSJcPGdpwoUP44=2aVW1WqJb78Qic8ceEw@mail.gmail.com>

On Wed, Mar 2, 2016 at 1:32 PM, Sean McBride <sean at rogue-research.com>
wrote:

> I guess that obsoletes this:
> <https://gitlab.kitware.com/vtk/vtk/merge_requests/1292>
>
> Maybe you could fix that up at the same time David?
>

Already have:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1297

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160302/f24118a0/attachment.html>

From aashish.chaudhary at kitware.com  Wed Mar  2 15:39:15 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Wed, 2 Mar 2016 15:39:15 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <20160302203234.1315769609@mail.rogue-research.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
 <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
 <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>
 <20160302203234.1315769609@mail.rogue-research.com>
Message-ID: <CAEw35Z_ufiRA9Vfv+nRzODpsyWXPOFVuv7puEa72qXMVLb0HPA@mail.gmail.com>

Berk,

+100 for the new API. Why not pass time as part of the update? So
instead of this

Update(int piece, int numPieces, int ghostLevel);
Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
UpdateTimeStep(double time);
UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel);
UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel,
int* updateExtent);

You will have:
Update(int piece, int numPieces, int ghostLevel);
Update(int piece, int numPieces, double time, int ghostLevel);
Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
Update(int piece, int numPieces, double time, int ghostLevel, int*
updateExtent);

since for most part their argument is almost identical.

- aashish

On Wed, Mar 2, 2016 at 3:32 PM, Sean McBride <sean at rogue-research.com> wrote:
> I guess that obsoletes this:
> <https://gitlab.kitware.com/vtk/vtk/merge_requests/1292>
>
> Maybe you could fix that up at the same time David?
>
> Sean
>
>
> On Wed, 2 Mar 2016 13:12:44 -0700, David Gobbi said:
>
>>Will do.
>>
>>On Wed, Mar 2, 2016 at 1:08 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
>>
>>> Ugh. That's a typo (probably copy & paste error). If you look at the
>>> implementation, it actually doesn't check for NULL pointer. I am swamped
>>> now. Do you have a few cycles to push a fix?
>>>
>>> On Wed, Mar 2, 2016 at 2:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>
>>>> Hi Berk,
>>>>
>>>> One of the things that I'm not quite sure about is, why is it permitted
>>>> to call algorithm->UpdateExtent() with no arguments?
>>>>
>>>>   int UpdateExtent(const int extents[6]=0)
>>>>
>>>> If I understand the code, UpdateExtent() with no args is the same as
>>>> Update().  It seems dangerous to allow this, because a programmer could
>>>> easily type UpdateExtent() by accident instead of UpdateWholeExtent(),
>>>> especially if they have autocompletion turned on in their code editor (and
>>>> especially because Update() and UpdateWholeExtent() give the same result
>>>> most of the time).
>
>
> _______________________________________________
> 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 berk.geveci at kitware.com  Wed Mar  2 15:41:18 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 2 Mar 2016 15:41:18 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CAEw35Z_ufiRA9Vfv+nRzODpsyWXPOFVuv7puEa72qXMVLb0HPA@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
 <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
 <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>
 <20160302203234.1315769609@mail.rogue-research.com>
 <CAEw35Z_ufiRA9Vfv+nRzODpsyWXPOFVuv7puEa72qXMVLb0HPA@mail.gmail.com>
Message-ID: <CAE32kpW-hkBdsFnLDEBWNOdwAQiacFfy=7o-f_J-j7Dx1hvsJA@mail.gmail.com>

Aashish,

Go find the discussion David and I had about why overloads are not good :-)
Having many different overloads puts a lot of burden on the subclass that
may want to overwrite only one of the signatures.

Best,
-berk

On Wed, Mar 2, 2016 at 3:39 PM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Berk,
>
> +100 for the new API. Why not pass time as part of the update? So
> instead of this
>
> Update(int piece, int numPieces, int ghostLevel);
> Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
> UpdateTimeStep(double time);
> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel);
> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel,
> int* updateExtent);
>
> You will have:
> Update(int piece, int numPieces, int ghostLevel);
> Update(int piece, int numPieces, double time, int ghostLevel);
> Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
> Update(int piece, int numPieces, double time, int ghostLevel, int*
> updateExtent);
>
> since for most part their argument is almost identical.
>
> - aashish
>
> On Wed, Mar 2, 2016 at 3:32 PM, Sean McBride <sean at rogue-research.com>
> wrote:
> > I guess that obsoletes this:
> > <https://gitlab.kitware.com/vtk/vtk/merge_requests/1292>
> >
> > Maybe you could fix that up at the same time David?
> >
> > Sean
> >
> >
> > On Wed, 2 Mar 2016 13:12:44 -0700, David Gobbi said:
> >
> >>Will do.
> >>
> >>On Wed, Mar 2, 2016 at 1:08 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> >>
> >>> Ugh. That's a typo (probably copy & paste error). If you look at the
> >>> implementation, it actually doesn't check for NULL pointer. I am
> swamped
> >>> now. Do you have a few cycles to push a fix?
> >>>
> >>> On Wed, Mar 2, 2016 at 2:12 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>>
> >>>> Hi Berk,
> >>>>
> >>>> One of the things that I'm not quite sure about is, why is it
> permitted
> >>>> to call algorithm->UpdateExtent() with no arguments?
> >>>>
> >>>>   int UpdateExtent(const int extents[6]=0)
> >>>>
> >>>> If I understand the code, UpdateExtent() with no args is the same as
> >>>> Update().  It seems dangerous to allow this, because a programmer
> could
> >>>> easily type UpdateExtent() by accident instead of UpdateWholeExtent(),
> >>>> especially if they have autocompletion turned on in their code editor
> (and
> >>>> especially because Update() and UpdateWholeExtent() give the same
> result
> >>>> most of the time).
> >
> >
> > _______________________________________________
> > 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160302/a69ceca2/attachment.html>

From aashish.chaudhary at kitware.com  Wed Mar  2 15:50:30 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Wed, 2 Mar 2016 15:50:30 -0500
Subject: [vtk-developers] Changes to the way the pipeline is updated
In-Reply-To: <CAE32kpW-hkBdsFnLDEBWNOdwAQiacFfy=7o-f_J-j7Dx1hvsJA@mail.gmail.com>
References: <CAE32kpVkEcszDVdzB53JYQg50Ex-37MyVN_5HH5CPcKg9ZypsQ@mail.gmail.com>
 <20160301173934.364091623@mail.rogue-research.com>
 <CAE32kpUmyyoGBxeEALXi+zH+jvY9iHS7sx4qCmRN-4gQn6asJQ@mail.gmail.com>
 <20160301205251.370840783@mail.rogue-research.com>
 <CANwS1=EdzvoLzbLF8F7YxGQZrm=5J=NoBPmLSkH=zYZ=czvjfQ@mail.gmail.com>
 <CAE32kpVXsw7Yz1mubo466Hhd+dy6T5Pu2sRN_1VCqgQM2sujBg@mail.gmail.com>
 <CANwS1=FJp4kS9ryJgJJQNOMwuqe-M-j7RyVuqagwT_PNcf_hww@mail.gmail.com>
 <20160302203234.1315769609@mail.rogue-research.com>
 <CAEw35Z_ufiRA9Vfv+nRzODpsyWXPOFVuv7puEa72qXMVLb0HPA@mail.gmail.com>
 <CAE32kpW-hkBdsFnLDEBWNOdwAQiacFfy=7o-f_J-j7Dx1hvsJA@mail.gmail.com>
Message-ID: <CAEw35Z_Pc3YMg9SRUpy0SZoAUy5MwuxxdHwXEr9BxdXotC4b9g@mail.gmail.com>

Yeah, I can see that it could cause some issue and if you and David
already discussed this then I am good but i will find the thread as
suggested. Although in this case both of these methods are so similar
in construct that it seems bit odd that I have to call UpdateTimeStamp
again almost with same parameters.

Can you not cache the args pass to Update so the UpdateTimeStamp will
just take the time parameter? I am sure you must have thought about
this too, in that case please ignore my suggestion.

Overall, this will be huge step forward.

- Aashish

On Wed, Mar 2, 2016 at 3:41 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Aashish,
>
> Go find the discussion David and I had about why overloads are not good :-)
> Having many different overloads puts a lot of burden on the subclass that
> may want to overwrite only one of the signatures.
>
> Best,
> -berk
>
> On Wed, Mar 2, 2016 at 3:39 PM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
>>
>> Berk,
>>
>> +100 for the new API. Why not pass time as part of the update? So
>> instead of this
>>
>> Update(int piece, int numPieces, int ghostLevel);
>> Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
>> UpdateTimeStep(double time);
>> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel);
>> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel,
>> int* updateExtent);
>>
>> You will have:
>> Update(int piece, int numPieces, int ghostLevel);
>> Update(int piece, int numPieces, double time, int ghostLevel);
>> Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
>> Update(int piece, int numPieces, double time, int ghostLevel, int*
>> updateExtent);
>>
>> since for most part their argument is almost identical.
>>
>> - aashish
>>
>> On Wed, Mar 2, 2016 at 3:32 PM, Sean McBride <sean at rogue-research.com>
>> wrote:
>> > I guess that obsoletes this:
>> > <https://gitlab.kitware.com/vtk/vtk/merge_requests/1292>
>> >
>> > Maybe you could fix that up at the same time David?
>> >
>> > Sean
>> >
>> >
>> > On Wed, 2 Mar 2016 13:12:44 -0700, David Gobbi said:
>> >
>> >>Will do.
>> >>
>> >>On Wed, Mar 2, 2016 at 1:08 PM, Berk Geveci <berk.geveci at kitware.com>
>> >> wrote:
>> >>
>> >>> Ugh. That's a typo (probably copy & paste error). If you look at the
>> >>> implementation, it actually doesn't check for NULL pointer. I am
>> >>> swamped
>> >>> now. Do you have a few cycles to push a fix?
>> >>>
>> >>> On Wed, Mar 2, 2016 at 2:12 PM, David Gobbi <david.gobbi at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hi Berk,
>> >>>>
>> >>>> One of the things that I'm not quite sure about is, why is it
>> >>>> permitted
>> >>>> to call algorithm->UpdateExtent() with no arguments?
>> >>>>
>> >>>>   int UpdateExtent(const int extents[6]=0)
>> >>>>
>> >>>> If I understand the code, UpdateExtent() with no args is the same as
>> >>>> Update().  It seems dangerous to allow this, because a programmer
>> >>>> could
>> >>>> easily type UpdateExtent() by accident instead of
>> >>>> UpdateWholeExtent(),
>> >>>> especially if they have autocompletion turned on in their code editor
>> >>>> (and
>> >>>> especially because Update() and UpdateWholeExtent() give the same
>> >>>> result
>> >>>> most of the time).
>> >
>> >
>> > _______________________________________________
>> > 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
>
>



-- 
| Aashish Chaudhary
| Technical Leader
| Kitware Inc.
| http://www.kitware.com/company/team/chaudhary.html

From andrew.amaclean at gmail.com  Thu Mar  3 00:35:09 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Thu, 3 Mar 2016 16:35:09 +1100
Subject: [vtk-developers] VTK TBB and Python Wrapping in Windows 10.
Message-ID: <CAHDsG9MKyNCqeOaGRcLgjifUdGdop_-YaHcR85=5P9cfQubV3w@mail.gmail.com>

Hi All

Build:
   Windows 10, compiler VS_12 (2013), 64-bit, Anaconda Python 2.7.
   TBB is found and the paths are correct.

The release version builds without errors.

If I build the Debug version with Python wrapping set to "ON" I get the
error:
   "c:\intel\tbb\tbb44_20160128oss\include\tbb\tbb_config.h(545) : fatal
error C1017: invalid integer constant expression", this particular error
normally relates to an expression in an #if directive that either did not
exist or did not evaluate to a constant.

This occurs when the following are being built:
   "Utilities\PythonInterpreter\vtkPythonInterpreter"
   "Utilities\PythonInterpreter\vtkPythonInteractiveInterpreter"
   "Parallel\MPI4Py\vtkMPI4PyCommunicator"
   "Wrapping\PythonCore\PyVTKObject"
   "Wrapping\PythonCore\vtkPythonCommand"
   "Wrapping\PythonCore\vtkPythonUtil"

I built one of the TBB examples using the FindTBB.cmake in VTK for both
vs_12 (2013) and vs_14 (2015) with no errors or warnings. So
tbb/tbb_config.h does not seem to be causing the problem. Lines 290-296 set
TBB_USE_DEBUG appropriately in tbb/tbb_config.h depending upon whether it
is a Debug or Release build.
So I think the problem relates to something in VTK.

Coming back to VTK, I looked through the CMakeLists.txt files and couldn't
see any definitions that could be causing this error for the python
wrapping.

Any ideas?

Regards
   Andrew


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/db173d62/attachment.html>

From pip010 at gmail.com  Thu Mar  3 04:16:37 2016
From: pip010 at gmail.com (Petar Petrov)
Date: Thu, 3 Mar 2016 10:16:37 +0100
Subject: [vtk-developers] broken vtkAssembly design
Message-ID: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>

Hello community,

quick question about redesign of vtkAssembly:
A while back someone reported that vtkFollowers added to vtkAssembly loose
their main feature, namely facing the camera at all times.
However, this to be solved a major? redesign is needeed:
vtkAssembly to inherit from vtkFollower and not vtkProp, so one can pass
camera information to vtkAssembly via SetCamera method.

Any idea why that is not the case? Is it trivial or there is more to it?

at that point I am faced with 2 options, either fix vtkAssembly or drop its
use and replace it with my own reinvent the wheel when it comes to
composite 3D objects in vtk.

Cheers,
petar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/e06902bc/attachment-0001.html>

From dave.demarle at kitware.com  Thu Mar  3 09:30:49 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 3 Mar 2016 09:30:49 -0500
Subject: [vtk-developers] broken vtkAssembly design
In-Reply-To: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>
References: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>
Message-ID: <CANjZAi8YADTNt91qXRsTi273_LzYZufXG0_XtwNDOwtHw1iHkw@mail.gmail.com>

Why not a "has a" pattern? Ie give the vtkAssembly an optional Camera or
Prop or what not ivar. If present, use it to make it act the way you want.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 3, 2016 at 4:16 AM, Petar Petrov <pip010 at gmail.com> wrote:

> Hello community,
>
> quick question about redesign of vtkAssembly:
> A while back someone reported that vtkFollowers added to vtkAssembly loose
> their main feature, namely facing the camera at all times.
> However, this to be solved a major? redesign is needeed:
> vtkAssembly to inherit from vtkFollower and not vtkProp, so one can pass
> camera information to vtkAssembly via SetCamera method.
>
> Any idea why that is not the case? Is it trivial or there is more to it?
>
> at that point I am faced with 2 options, either fix vtkAssembly or drop
> its use and replace it with my own reinvent the wheel when it comes to
> composite 3D objects in vtk.
>
> Cheers,
> petar
>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/25f9ceec/attachment.html>

From pip010 at gmail.com  Thu Mar  3 09:51:48 2016
From: pip010 at gmail.com (Petar Petrov)
Date: Thu, 3 Mar 2016 15:51:48 +0100
Subject: [vtk-developers] broken vtkAssembly design
In-Reply-To: <CANjZAi8YADTNt91qXRsTi273_LzYZufXG0_XtwNDOwtHw1iHkw@mail.gmail.com>
References: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>
 <CANjZAi8YADTNt91qXRsTi273_LzYZufXG0_XtwNDOwtHw1iHkw@mail.gmail.com>
Message-ID: <CAFr3OanEfsTDYaTybumQ7AResMc11RnoonoE3icmYc5=fe3pKg@mail.gmail.com>

Hi David,

that's even better. However, isn't the camera info passed polymorphic-aly
through some base class pointer?
Or vtkFollower is listening on camera change? Let me dig in more.

However, you do agree it needs some fixing ? :)

Cheers,
Petar

On Thu, Mar 3, 2016 at 3:30 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Why not a "has a" pattern? Ie give the vtkAssembly an optional Camera or
> Prop or what not ivar. If present, use it to make it act the way you want.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Mar 3, 2016 at 4:16 AM, Petar Petrov <pip010 at gmail.com> wrote:
>
>> Hello community,
>>
>> quick question about redesign of vtkAssembly:
>> A while back someone reported that vtkFollowers added to vtkAssembly
>> loose their main feature, namely facing the camera at all times.
>> However, this to be solved a major? redesign is needeed:
>> vtkAssembly to inherit from vtkFollower and not vtkProp, so one can pass
>> camera information to vtkAssembly via SetCamera method.
>>
>> Any idea why that is not the case? Is it trivial or there is more to it?
>>
>> at that point I am faced with 2 options, either fix vtkAssembly or drop
>> its use and replace it with my own reinvent the wheel when it comes to
>> composite 3D objects in vtk.
>>
>> Cheers,
>> petar
>>
>> _______________________________________________
>> 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
>>
>>
>>
>


-- 
All the best,
Petar Petrov
http://ppetrov.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/a8433037/attachment.html>

From dave.demarle at kitware.com  Thu Mar  3 11:00:09 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 3 Mar 2016 11:00:09 -0500
Subject: [vtk-developers] broken vtkAssembly design
In-Reply-To: <CAFr3OanEfsTDYaTybumQ7AResMc11RnoonoE3icmYc5=fe3pKg@mail.gmail.com>
References: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>
 <CANjZAi8YADTNt91qXRsTi273_LzYZufXG0_XtwNDOwtHw1iHkw@mail.gmail.com>
 <CAFr3OanEfsTDYaTybumQ7AResMc11RnoonoE3icmYc5=fe3pKg@mail.gmail.com>
Message-ID: <CANjZAi8qV8o3F5UVT9RiMMMSAeTwG7cGX2wPSRrkksqh679MJA@mail.gmail.com>

> However, you do agree it needs some fixing ? :)

I don't think I've ever used assembly. I trust the list's finding that it
doesn't work with follower though!

Once you make some progress, please do submit a merge request so people can
take a look at both the problem and solution. Ideally the merge will have a
test that demonstrates the feature and will ensure it stays fixed.



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 3, 2016 at 9:51 AM, Petar Petrov <pip010 at gmail.com> wrote:

> Hi David,
>
> that's even better. However, isn't the camera info passed polymorphic-aly
> through some base class pointer?
> Or vtkFollower is listening on camera change? Let me dig in more.
>
> However, you do agree it needs some fixing ? :)
>
> Cheers,
> Petar
>
> On Thu, Mar 3, 2016 at 3:30 PM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>
>> Why not a "has a" pattern? Ie give the vtkAssembly an optional Camera or
>> Prop or what not ivar. If present, use it to make it act the way you want.
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Thu, Mar 3, 2016 at 4:16 AM, Petar Petrov <pip010 at gmail.com> wrote:
>>
>>> Hello community,
>>>
>>> quick question about redesign of vtkAssembly:
>>> A while back someone reported that vtkFollowers added to vtkAssembly
>>> loose their main feature, namely facing the camera at all times.
>>> However, this to be solved a major? redesign is needeed:
>>> vtkAssembly to inherit from vtkFollower and not vtkProp, so one can pass
>>> camera information to vtkAssembly via SetCamera method.
>>>
>>> Any idea why that is not the case? Is it trivial or there is more to it?
>>>
>>> at that point I am faced with 2 options, either fix vtkAssembly or drop
>>> its use and replace it with my own reinvent the wheel when it comes to
>>> composite 3D objects in vtk.
>>>
>>> Cheers,
>>> petar
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>
>
>
> --
> All the best,
> Petar Petrov
> http://ppetrov.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/58af397d/attachment.html>

From pip010 at gmail.com  Thu Mar  3 11:06:51 2016
From: pip010 at gmail.com (Petar Petrov)
Date: Thu, 3 Mar 2016 17:06:51 +0100
Subject: [vtk-developers] broken vtkAssembly design
In-Reply-To: <CANjZAi8qV8o3F5UVT9RiMMMSAeTwG7cGX2wPSRrkksqh679MJA@mail.gmail.com>
References: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>
 <CANjZAi8YADTNt91qXRsTi273_LzYZufXG0_XtwNDOwtHw1iHkw@mail.gmail.com>
 <CAFr3OanEfsTDYaTybumQ7AResMc11RnoonoE3icmYc5=fe3pKg@mail.gmail.com>
 <CANjZAi8qV8o3F5UVT9RiMMMSAeTwG7cGX2wPSRrkksqh679MJA@mail.gmail.com>
Message-ID: <CAFr3Oakf_+oDgd+ie4hFK9Miu1i7eicYG8Ji5iHpS7zedFEP6Q@mail.gmail.com>

On Thu, Mar 3, 2016 at 5:00 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> > However, you do agree it needs some fixing ? :)
>
> I don't think I've ever used assembly. I trust the list's finding that it
> doesn't work with follower though!
>
Just curious. What do you use when you want to assemble a composite objects
made out of a few actors together? vtkAppendPolydata and only one actor
maybe?

>
> Once you make some progress, please do submit a merge request so people
> can take a look at both the problem and solution. Ideally the merge will
> have a test that demonstrates the feature and will ensure it stays fixed.
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Mar 3, 2016 at 9:51 AM, Petar Petrov <pip010 at gmail.com> wrote:
>
>> Hi David,
>>
>> that's even better. However, isn't the camera info passed polymorphic-aly
>> through some base class pointer?
>> Or vtkFollower is listening on camera change? Let me dig in more.
>>
>> However, you do agree it needs some fixing ? :)
>>
>> Cheers,
>> Petar
>>
>> On Thu, Mar 3, 2016 at 3:30 PM, David E DeMarle <dave.demarle at kitware.com
>> > wrote:
>>
>>> Why not a "has a" pattern? Ie give the vtkAssembly an optional Camera or
>>> Prop or what not ivar. If present, use it to make it act the way you want.
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Thu, Mar 3, 2016 at 4:16 AM, Petar Petrov <pip010 at gmail.com> wrote:
>>>
>>>> Hello community,
>>>>
>>>> quick question about redesign of vtkAssembly:
>>>> A while back someone reported that vtkFollowers added to vtkAssembly
>>>> loose their main feature, namely facing the camera at all times.
>>>> However, this to be solved a major? redesign is needeed:
>>>> vtkAssembly to inherit from vtkFollower and not vtkProp, so one can
>>>> pass camera information to vtkAssembly via SetCamera method.
>>>>
>>>> Any idea why that is not the case? Is it trivial or there is more to it?
>>>>
>>>> at that point I am faced with 2 options, either fix vtkAssembly or drop
>>>> its use and replace it with my own reinvent the wheel when it comes to
>>>> composite 3D objects in vtk.
>>>>
>>>> Cheers,
>>>> petar
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> All the best,
>> Petar Petrov
>> http://ppetrov.net
>>
>
>


-- 
All the best,
Petar Petrov
http://ppetrov.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/00525c49/attachment-0001.html>

From dave.demarle at kitware.com  Thu Mar  3 11:10:22 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 3 Mar 2016 11:10:22 -0500
Subject: [vtk-developers] broken vtkAssembly design
In-Reply-To: <CAFr3Oakf_+oDgd+ie4hFK9Miu1i7eicYG8Ji5iHpS7zedFEP6Q@mail.gmail.com>
References: <CAFr3OamSJ5U1n1mSM5D+Q10xAkpy=fJoz_Aa0bL_rP0HHCH4gQ@mail.gmail.com>
 <CANjZAi8YADTNt91qXRsTi273_LzYZufXG0_XtwNDOwtHw1iHkw@mail.gmail.com>
 <CAFr3OanEfsTDYaTybumQ7AResMc11RnoonoE3icmYc5=fe3pKg@mail.gmail.com>
 <CANjZAi8qV8o3F5UVT9RiMMMSAeTwG7cGX2wPSRrkksqh679MJA@mail.gmail.com>
 <CAFr3Oakf_+oDgd+ie4hFK9Miu1i7eicYG8Ji5iHpS7zedFEP6Q@mail.gmail.com>
Message-ID: <CANjZAi9q_PfSU79Pzt49q2+Ow7BhEk2gR2CzPwq4i-34G20TOg@mail.gmail.com>

vtkMultiBlockData and allies.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 3, 2016 at 11:06 AM, Petar Petrov <pip010 at gmail.com> wrote:

>
>
> On Thu, Mar 3, 2016 at 5:00 PM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>
>> > However, you do agree it needs some fixing ? :)
>>
>> I don't think I've ever used assembly. I trust the list's finding that it
>> doesn't work with follower though!
>>
> Just curious. What do you use when you want to assemble a composite
> objects made out of a few actors together? vtkAppendPolydata and only one
> actor maybe?
>
>>
>> Once you make some progress, please do submit a merge request so people
>> can take a look at both the problem and solution. Ideally the merge will
>> have a test that demonstrates the feature and will ensure it stays fixed.
>>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Thu, Mar 3, 2016 at 9:51 AM, Petar Petrov <pip010 at gmail.com> wrote:
>>
>>> Hi David,
>>>
>>> that's even better. However, isn't the camera info passed
>>> polymorphic-aly through some base class pointer?
>>> Or vtkFollower is listening on camera change? Let me dig in more.
>>>
>>> However, you do agree it needs some fixing ? :)
>>>
>>> Cheers,
>>> Petar
>>>
>>> On Thu, Mar 3, 2016 at 3:30 PM, David E DeMarle <
>>> dave.demarle at kitware.com> wrote:
>>>
>>>> Why not a "has a" pattern? Ie give the vtkAssembly an optional Camera
>>>> or Prop or what not ivar. If present, use it to make it act the way you
>>>> want.
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4909
>>>>
>>>> On Thu, Mar 3, 2016 at 4:16 AM, Petar Petrov <pip010 at gmail.com> wrote:
>>>>
>>>>> Hello community,
>>>>>
>>>>> quick question about redesign of vtkAssembly:
>>>>> A while back someone reported that vtkFollowers added to vtkAssembly
>>>>> loose their main feature, namely facing the camera at all times.
>>>>> However, this to be solved a major? redesign is needeed:
>>>>> vtkAssembly to inherit from vtkFollower and not vtkProp, so one can
>>>>> pass camera information to vtkAssembly via SetCamera method.
>>>>>
>>>>> Any idea why that is not the case? Is it trivial or there is more to
>>>>> it?
>>>>>
>>>>> at that point I am faced with 2 options, either fix vtkAssembly or
>>>>> drop its use and replace it with my own reinvent the wheel when it comes to
>>>>> composite 3D objects in vtk.
>>>>>
>>>>> Cheers,
>>>>> petar
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> All the best,
>>> Petar Petrov
>>> http://ppetrov.net
>>>
>>
>>
>
>
> --
> All the best,
> Petar Petrov
> http://ppetrov.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160303/d07fb1cf/attachment.html>

From behollis at sci.utah.edu  Fri Mar  4 19:47:44 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Fri, 04 Mar 2016 17:47:44 -0700
Subject: [vtk-developers] passing vertex attributes to custom shader
Message-ID: <web-12203569@sci.utah.edu>

Hi,

I've been using vtkOpenGLPolyDataMapper() to set custom vertex / 
fragment shaders. I'd also like to provide user-defined vertex 
attributes accessible in the shader code. I assumed from the 
documentation that MapDataArrayToVertexAttributes() is the proper way 
to do this.

However, I get the ERROR: vtkOpenGLPolyDataMapper (0x2872160): Not 
implemented at this level...

There doesn't appear to be a derived class of vtkOpenGLPolyDataMapper 
available for my needs (which is that I'm specifying polygons via a 
vtkPolyData object).

Is it possible to pass vertex attributes and custom uniforms using 
vtkOpenGLPolyDataMapper? Is there a different way from the one I've 
been trying that makes this possible?

Regards,
Brad

From ken.martin at kitware.com  Sat Mar  5 08:05:40 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Sat, 5 Mar 2016 08:05:40 -0500
Subject: [vtk-developers] passing vertex attributes to custom shader
In-Reply-To: <web-12203569@sci.utah.edu>
References: <web-12203569@sci.utah.edu>
Message-ID: <CANXz0SY+P=YuTQFcWg+5=9pd9RiCxPNYQjrrMKERLPhm2ooFsg@mail.gmail.com>

Currently you can pass uniforms (see
https://gitlab.kitware.com/vtk/vtk/blob/v7.0.0.rc2/Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx
for an example). You currently cannot pass your own attributes without
subclassing, only work with the default ones that are passed
(position/scalars/normals/tcoords)

Thanks
Ken

On Fri, Mar 4, 2016 at 7:47 PM, Brad Hollister <behollis at sci.utah.edu>
wrote:

> Hi,
>
> I've been using vtkOpenGLPolyDataMapper() to set custom vertex / fragment
> shaders. I'd also like to provide user-defined vertex attributes accessible
> in the shader code. I assumed from the documentation that
> MapDataArrayToVertexAttributes() is the proper way to do this.
>
> However, I get the ERROR: vtkOpenGLPolyDataMapper (0x2872160): Not
> implemented at this level...
>
> There doesn't appear to be a derived class of vtkOpenGLPolyDataMapper
> available for my needs (which is that I'm specifying polygons via a
> vtkPolyData object).
>
> Is it possible to pass vertex attributes and custom uniforms using
> vtkOpenGLPolyDataMapper? Is there a different way from the one I've been
> trying that makes this possible?
>
> Regards,
> Brad
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160305/d1ca8c63/attachment.html>

From andrew.amaclean at gmail.com  Sun Mar  6 01:25:38 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 6 Mar 2016 17:25:38 +1100
Subject: [vtk-developers] Unable to build Python Interpreter in debug mode
	TBB and VS2013.
Message-ID: <CAHDsG9NfsYSB2Y3KMfgMUCW2Ax58CC-YjBbnSh2wh5ta=o1u5w@mail.gmail.com>

Hi All

Build:
   Windows 10, compiler VS_12 (2013), 64-bit, Anaconda Python 2.7.
   TBB is found and the paths are correct.

The release version builds without errors.

If I build the Debug version with Python wrapping set to "ON" I get the
error:
   "c:\intel\tbb\tbb44_20160128oss\include\tbb\tbb_config.h(545) : fatal
error C1017: invalid integer constant expression", this particular error
normally relates to an expression in an #if directive that either did not
exist or did not evaluate to a constant.

This occurs when the following are being built:
   "Utilities\PythonInterpreter\vtkPythonInterpreter"
   "Utilities\PythonInterpreter\vtkPythonInteractiveInterpreter"
   "Parallel\MPI4Py\vtkMPI4PyCommunicator"
   "Wrapping\PythonCore\PyVTKObject"
   "Wrapping\PythonCore\vtkPythonCommand"
   "Wrapping\PythonCore\vtkPythonUtil"

I built one of the TBB examples using the FindTBB.cmake in VTK for both
vs_12 (2013) and vs_14 (2015) with no errors or warnings. So
tbb/tbb_config.h does not seem to be causing the problem. Lines 290-296 set
TBB_USE_DEBUG appropriately in tbb/tbb_config.h depending upon whether it
is a Debug or Release build.
So I think the problem relates to something in VTK.

Coming back to VTK, I looked through the CMakeLists.txt files and couldn't
see any definitions that could be causing this error for the python
wrapping.

Any ideas?

Regards

Andrew


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160306/46323339/attachment.html>

From david.gobbi at gmail.com  Sun Mar  6 09:18:05 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Sun, 6 Mar 2016 07:18:05 -0700
Subject: [vtk-developers] Unable to build Python Interpreter in debug
 mode TBB and VS2013.
In-Reply-To: <CAHDsG9NfsYSB2Y3KMfgMUCW2Ax58CC-YjBbnSh2wh5ta=o1u5w@mail.gmail.com>
References: <CAHDsG9NfsYSB2Y3KMfgMUCW2Ax58CC-YjBbnSh2wh5ta=o1u5w@mail.gmail.com>
Message-ID: <CANwS1=FMcKfCF=AeZbsmqyzwjgLZy8tpK+ez07+U2HkrR7LjFQ@mail.gmail.com>

Hi Andrew,

Probably the best way to approach this is to find out what preprocessor
symbol is causing the problem, tbb_config.h line 545 is as follows:

#if __GLIBC__==2 && __GLIBC_MINOR__==3 ||  (__APPLE__ && (
__INTEL_COMPILER==1200 && !TBB_USE_DEBUG))

You can print the values of these symbols (to find out which one is defined
as something other than a number) with the same technique used for the
__LINE__ example on the following MSDN web page:

https://msdn.microsoft.com/en-us/library/x7dkzch2.aspx

 - David


On Sat, Mar 5, 2016 at 11:25 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Hi All
>
> Build:
>    Windows 10, compiler VS_12 (2013), 64-bit, Anaconda Python 2.7.
>    TBB is found and the paths are correct.
>
> The release version builds without errors.
>
> If I build the Debug version with Python wrapping set to "ON" I get the
> error:
>    "c:\intel\tbb\tbb44_20160128oss\include\tbb\tbb_config.h(545) : fatal
> error C1017: invalid integer constant expression", this particular error
> normally relates to an expression in an #if directive that either did not
> exist or did not evaluate to a constant.
>
> This occurs when the following are being built:
>    "Utilities\PythonInterpreter\vtkPythonInterpreter"
>    "Utilities\PythonInterpreter\vtkPythonInteractiveInterpreter"
>    "Parallel\MPI4Py\vtkMPI4PyCommunicator"
>    "Wrapping\PythonCore\PyVTKObject"
>    "Wrapping\PythonCore\vtkPythonCommand"
>    "Wrapping\PythonCore\vtkPythonUtil"
>
> I built one of the TBB examples using the FindTBB.cmake in VTK for both
> vs_12 (2013) and vs_14 (2015) with no errors or warnings. So
> tbb/tbb_config.h does not seem to be causing the problem. Lines 290-296 set
> TBB_USE_DEBUG appropriately in tbb/tbb_config.h depending upon whether it
> is a Debug or Release build.
> So I think the problem relates to something in VTK.
>
> Coming back to VTK, I looked through the CMakeLists.txt files and couldn't
> see any definitions that could be causing this error for the python
> wrapping.
>
> Any ideas?
>
> Regards
>
> Andrew
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160306/16823930/attachment.html>

From andrew.amaclean at gmail.com  Sun Mar  6 16:39:09 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Mon, 7 Mar 2016 08:39:09 +1100
Subject: [vtk-developers] Unable to build Python Interpreter in debug
 mode TBB and VS2013.
In-Reply-To: <CANwS1=FMcKfCF=AeZbsmqyzwjgLZy8tpK+ez07+U2HkrR7LjFQ@mail.gmail.com>
References: <CAHDsG9NfsYSB2Y3KMfgMUCW2Ax58CC-YjBbnSh2wh5ta=o1u5w@mail.gmail.com>
 <CANwS1=FMcKfCF=AeZbsmqyzwjgLZy8tpK+ez07+U2HkrR7LjFQ@mail.gmail.com>
Message-ID: <CAHDsG9PGOuvUVYak_q0GdoBM0rkvzmaQ1QObfBPCS4ET3=wZzg@mail.gmail.com>

Thankyou for this David. I couldn't remember how to do this!

Regards
   Andrew


On Mon, Mar 7, 2016 at 1:18 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Andrew,
>
> Probably the best way to approach this is to find out what preprocessor
> symbol is causing the problem, tbb_config.h line 545 is as follows:
>
> #if __GLIBC__==2 && __GLIBC_MINOR__==3 ||  (__APPLE__ && (
> __INTEL_COMPILER==1200 && !TBB_USE_DEBUG))
>
> You can print the values of these symbols (to find out which one is
> defined as something other than a number) with the same technique used for
> the __LINE__ example on the following MSDN web page:
>
> https://msdn.microsoft.com/en-us/library/x7dkzch2.aspx
>
>  - David
>
>
> On Sat, Mar 5, 2016 at 11:25 PM, Andrew Maclean <andrew.amaclean at gmail.com
> > wrote:
>
>> Hi All
>>
>> Build:
>>    Windows 10, compiler VS_12 (2013), 64-bit, Anaconda Python 2.7.
>>    TBB is found and the paths are correct.
>>
>> The release version builds without errors.
>>
>> If I build the Debug version with Python wrapping set to "ON" I get the
>> error:
>>    "c:\intel\tbb\tbb44_20160128oss\include\tbb\tbb_config.h(545) : fatal
>> error C1017: invalid integer constant expression", this particular error
>> normally relates to an expression in an #if directive that either did not
>> exist or did not evaluate to a constant.
>>
>> This occurs when the following are being built:
>>    "Utilities\PythonInterpreter\vtkPythonInterpreter"
>>    "Utilities\PythonInterpreter\vtkPythonInteractiveInterpreter"
>>    "Parallel\MPI4Py\vtkMPI4PyCommunicator"
>>    "Wrapping\PythonCore\PyVTKObject"
>>    "Wrapping\PythonCore\vtkPythonCommand"
>>    "Wrapping\PythonCore\vtkPythonUtil"
>>
>> I built one of the TBB examples using the FindTBB.cmake in VTK for both
>> vs_12 (2013) and vs_14 (2015) with no errors or warnings. So
>> tbb/tbb_config.h does not seem to be causing the problem. Lines 290-296 set
>> TBB_USE_DEBUG appropriately in tbb/tbb_config.h depending upon whether it
>> is a Debug or Release build.
>> So I think the problem relates to something in VTK.
>>
>> Coming back to VTK, I looked through the CMakeLists.txt files and
>> couldn't see any definitions that could be causing this error for the
>> python wrapping.
>>
>> Any ideas?
>>
>> Regards
>>
>> Andrew
>>
>>
>> --
>> ___________________________________________
>> Andrew J. P. Maclean
>>
>>
>


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160307/7a7f4d5f/attachment.html>

From andrew.amaclean at gmail.com  Mon Mar  7 05:16:58 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Mon, 7 Mar 2016 21:16:58 +1100
Subject: [vtk-developers] Unable to build Python Interpreter in debug
 mode TBB and VS2013.
In-Reply-To: <CAHDsG9PGOuvUVYak_q0GdoBM0rkvzmaQ1QObfBPCS4ET3=wZzg@mail.gmail.com>
References: <CAHDsG9NfsYSB2Y3KMfgMUCW2Ax58CC-YjBbnSh2wh5ta=o1u5w@mail.gmail.com>
 <CANwS1=FMcKfCF=AeZbsmqyzwjgLZy8tpK+ez07+U2HkrR7LjFQ@mail.gmail.com>
 <CAHDsG9PGOuvUVYak_q0GdoBM0rkvzmaQ1QObfBPCS4ET3=wZzg@mail.gmail.com>
Message-ID: <CAHDsG9Ne5BrLMmd2--z3dzxF5v2yDHW5jG_GObfuMtS2VS9HHQ@mail.gmail.com>

Ok, thanks to David's comment.

Here is a fix ready for review:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1306

This seems to be caused by the line:
# define _DEBUG
 in
Utilities/Python/vtkPython.h
line 90.

_DEBUG was undefined on line 52 and then redefined on line 90.
Changing line 90 to:
# define _DEBUG 1
 seems to fix this.

Regards
    Andrew


On Mon, Mar 7, 2016 at 8:39 AM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Thankyou for this David. I couldn't remember how to do this!
>
> Regards
>    Andrew
>
>
> On Mon, Mar 7, 2016 at 1:18 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>
>> Hi Andrew,
>>
>> Probably the best way to approach this is to find out what preprocessor
>> symbol is causing the problem, tbb_config.h line 545 is as follows:
>>
>> #if __GLIBC__==2 && __GLIBC_MINOR__==3 ||  (__APPLE__ && (
>> __INTEL_COMPILER==1200 && !TBB_USE_DEBUG))
>>
>> You can print the values of these symbols (to find out which one is
>> defined as something other than a number) with the same technique used for
>> the __LINE__ example on the following MSDN web page:
>>
>> https://msdn.microsoft.com/en-us/library/x7dkzch2.aspx
>>
>>  - David
>>
>>
>> On Sat, Mar 5, 2016 at 11:25 PM, Andrew Maclean <
>> andrew.amaclean at gmail.com> wrote:
>>
>>> Hi All
>>>
>>> Build:
>>>    Windows 10, compiler VS_12 (2013), 64-bit, Anaconda Python 2.7.
>>>    TBB is found and the paths are correct.
>>>
>>> The release version builds without errors.
>>>
>>> If I build the Debug version with Python wrapping set to "ON" I get the
>>> error:
>>>    "c:\intel\tbb\tbb44_20160128oss\include\tbb\tbb_config.h(545) : fatal
>>> error C1017: invalid integer constant expression", this particular error
>>> normally relates to an expression in an #if directive that either did not
>>> exist or did not evaluate to a constant.
>>>
>>> This occurs when the following are being built:
>>>    "Utilities\PythonInterpreter\vtkPythonInterpreter"
>>>    "Utilities\PythonInterpreter\vtkPythonInteractiveInterpreter"
>>>    "Parallel\MPI4Py\vtkMPI4PyCommunicator"
>>>    "Wrapping\PythonCore\PyVTKObject"
>>>    "Wrapping\PythonCore\vtkPythonCommand"
>>>    "Wrapping\PythonCore\vtkPythonUtil"
>>>
>>> I built one of the TBB examples using the FindTBB.cmake in VTK for both
>>> vs_12 (2013) and vs_14 (2015) with no errors or warnings. So
>>> tbb/tbb_config.h does not seem to be causing the problem. Lines 290-296 set
>>> TBB_USE_DEBUG appropriately in tbb/tbb_config.h depending upon whether it
>>> is a Debug or Release build.
>>> So I think the problem relates to something in VTK.
>>>
>>> Coming back to VTK, I looked through the CMakeLists.txt files and
>>> couldn't see any definitions that could be causing this error for the
>>> python wrapping.
>>>
>>> Any ideas?
>>>
>>> Regards
>>>
>>> Andrew
>>>
>>>
>>> --
>>> ___________________________________________
>>> Andrew J. P. Maclean
>>>
>>>
>>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>



-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160307/004995f7/attachment.html>

From david.lonie at kitware.com  Mon Mar  7 11:06:45 2016
From: david.lonie at kitware.com (David Lonie)
Date: Mon, 7 Mar 2016 11:06:45 -0500
Subject: [vtk-developers] New vtkDataArray implementations, tools
Message-ID: <CA+=e1ouo5sM6kF113zneSBYkNe5EfUGmsqFNMBg=Wd7-6nSmZA@mail.gmail.com>

Hi folks,

As part of the ongoing effort to support in-situ toolkits such as Catalyst
in VTK, we have made some changes to how vtkDataArrays are implemented and
used in VTK.

In a nutshell, the array-of-structs (AOS) memory layout should no longer be
assumed when using vtkDataArrays, and there are new SOA (struct-of-arrays)
vtkDataArray implementations included in VTK. This means that methods like
GetVoidPointer, WritePointer, etc should no longer be used, and may enter a
deprecation phase at some point in the future. This also means that
vtkTemplateMacro is no longer the preferred way of interacting with array
data efficiently, since it indirectly relies on GetVoidPointer. Existing
code using vtkTemplateMacro will continue to work, though it will be very
inefficient when used with some of the new array subclasses.

As a replacement for vtkTemplateMacro, there are some new tools that are
used to provide efficient, compile-time optimized access to array data.
These tools and their usage are detailed here:

http://www.vtk.org/Wiki/VTK/Tutorials/DataArrays (wiki version)
https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/Doxygen/ArrayDispatch-VTK-7-1.md
(raw doxygen markdown -- will replace wiki page eventually)

The new vtkArrayDispatch tool allows optimized algorithms to be written
that work on both vtkAOSDataArrayTemplate (the AOS replacement for
vtkDataArrayTemplate) and vtkSOADataArrayTemplate (the new SOA data array
backend). The vtkDataArrayAccessor wrapper will then allow the same
implementation to fallback to using the generic vtkDataArray API in cases
where template-explosion may be an issue.

Also note that there is an API change involved with this patch. The typed
vtkDataArrayTemplate API methods:

void GetTupleValue(vtkIdType tupleIdx, ValueType *tuple)
void SetTupleValue(vtkIdType tupleIdx, const ValueType *tuple)
void InsertTupleValue(vtkIdType tupleIdx, const ValueType *tuple)
vtkIdType InsertNextTupleValue(const ValueType *tuple)


have been renamed to more clearly indicate their purpose. They are now
"GetTypedTuple", etc, and there is a new set of corresponding
"GetTypedComponent"-style methods. The old signatures are still available
on vtkAOSDataArrayTemplate subclasses and have been marked deprecated. VTK
and ParaView have both been updated to use the new APIs.

The last iteration of in-situ data array interfaces, namely
vtkTypedDataArray and vtkMappedDataArray, will be deprecated at some point
due to performance concerns, but continue to be available for the time
being.

If you encounter any issues with the new implementations or have questions
about them, please do not hesitate to email the vtk-developers list and let
us know.

Best,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160307/04d29fea/attachment-0001.html>

From hahnse at ornl.gov  Mon Mar  7 12:25:52 2016
From: hahnse at ornl.gov (Hahn, Steven E.)
Date: Mon, 7 Mar 2016 17:25:52 +0000
Subject: [vtk-developers] VTK_USE_CXX11_FEATURES not setting -std=gnu++11
Message-ID: <760AB7F8-E389-4CE8-AF1F-121B727EBA65@ornl.gov>

I tried setting the option VTK_USE_CXX11_FEATURES and noticed that ?std=gnu++11 is not being set on either OS X or linux. If I try using VTK_OVERRIDE, I get `warning: 'override' keyword is a C++11 extension [-Wc++11-extensions]`

A partial fix appears to be adding `set(CMAKE_CXX_STANDARD 11)` before `set(CMAKE_CXX_STANDARD_REQUIRED 11)` in 
https://gitlab.kitware.com/vtk/vtk/blob/master/Common/Core/CMakeLists.txt#L386. Would it be better to allow C++14 on the compilers which support it? Should these variables be set much earlier (perhaps in https://gitlab.kitware.com/vtk/vtk/blob/master/CMakeLists.txt) so that the same standard is used project-wide?

Would any of these changes make an acceptable merge request?

Best,
Steven Hahn

From arankin at robarts.ca  Mon Mar  7 18:25:30 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Mon, 7 Mar 2016 23:25:30 +0000
Subject: [vtk-developers] Guide to implementing kits
Message-ID: <7afd231bfdd34c0a855c93250b2a9962@dag2.robarts.ca>

Hello all,

Could someone point me towards any documentation regarding details about the kit system in VTK?

Regards,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160307/1b25dedd/attachment.html>

From david.gobbi at gmail.com  Mon Mar  7 19:12:36 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 7 Mar 2016 17:12:36 -0700
Subject: [vtk-developers] Guide to implementing kits
In-Reply-To: <7afd231bfdd34c0a855c93250b2a9962@dag2.robarts.ca>
References: <7afd231bfdd34c0a855c93250b2a9962@dag2.robarts.ca>
Message-ID: <CANwS1=Gj4fs8yXtT+QV4KNBbP8wgzDbgkYuBjE+4WGB8CO2Lag@mail.gmail.com>

You mean the module system?

http://www.vtk.org/Wiki/VTK/Module_Development
http://www.vtk.org/Wiki/VTK/Remote_Modules

And possibly also relevant:

http://www.vtk.org/Wiki/VTK/Build_System_Migration

 - David

On Mon, Mar 7, 2016 at 4:25 PM, Adam Rankin <arankin at robarts.ca> wrote:

> Hello all,
>
>
>
> Could someone point me towards any documentation regarding details about
> the kit system in VTK?
>
>
>
> Regards,
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160307/d06ce57d/attachment.html>

From arankin at robarts.ca  Mon Mar  7 19:15:53 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Tue, 8 Mar 2016 00:15:53 +0000
Subject: [vtk-developers] Guide to implementing kits
In-Reply-To: <CANwS1=Gj4fs8yXtT+QV4KNBbP8wgzDbgkYuBjE+4WGB8CO2Lag@mail.gmail.com>
References: <7afd231bfdd34c0a855c93250b2a9962@dag2.robarts.ca>
 <CANwS1=Gj4fs8yXtT+QV4KNBbP8wgzDbgkYuBjE+4WGB8CO2Lag@mail.gmail.com>
Message-ID: <3abb85e5a29a48618d4a130f0076781b@dag2.robarts.ca>

Not quite. Specifically the kit part of the module system

For example:
vtk_module(vtkCommonCore
  GROUPS
    StandAlone
  PRIVATE_DEPENDS
    vtksys
  TEST_DEPENDS
    vtkTestingCore
    vtkCommonSystem
    vtkCommonTransforms
  KIT
    vtkCommon
  )

Produces projects like:
vtkCommon
vtkCommonKitPython
vtkCommonKitPythonD
vtkCommonCoreObjects

and I?m just trying to understand how those get generated, how they are populated etc? I have started digging into the vtk CMake functions/macros but was hoping someone may have documented the Kit (sub?)system.

Regards,
Adam

From: David Gobbi [mailto:david.gobbi at gmail.com]
Sent: Monday, March 07, 2016 7:13 PM
To: Adam Rankin <arankin at robarts.ca>
Cc: vtk-developers at vtk.org
Subject: Re: [vtk-developers] Guide to implementing kits

You mean the module system?

http://www.vtk.org/Wiki/VTK/Module_Development
http://www.vtk.org/Wiki/VTK/Remote_Modules

And possibly also relevant:

http://www.vtk.org/Wiki/VTK/Build_System_Migration

 - David

On Mon, Mar 7, 2016 at 4:25 PM, Adam Rankin <arankin at robarts.ca<mailto:arankin at robarts.ca>> wrote:
Hello all,

Could someone point me towards any documentation regarding details about the kit system in VTK?

Regards,
Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160308/e0a225fe/attachment.html>

From ben.boeckel at kitware.com  Tue Mar  8 11:17:30 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 8 Mar 2016 11:17:30 -0500
Subject: [vtk-developers] Guide to implementing kits
In-Reply-To: <3abb85e5a29a48618d4a130f0076781b@dag2.robarts.ca>
References: <7afd231bfdd34c0a855c93250b2a9962@dag2.robarts.ca>
 <CANwS1=Gj4fs8yXtT+QV4KNBbP8wgzDbgkYuBjE+4WGB8CO2Lag@mail.gmail.com>
 <3abb85e5a29a48618d4a130f0076781b@dag2.robarts.ca>
Message-ID: <20160308161730.GA25514@megas.kitware.com>

On Tue, Mar 08, 2016 at 00:15:53 +0000, Adam Rankin wrote:
> Not quite. Specifically the kit part of the module system
> 
> For example:
> vtk_module(vtkCommonCore
>   GROUPS
>     StandAlone
>   PRIVATE_DEPENDS
>     vtksys
>   TEST_DEPENDS
>     vtkTestingCore
>     vtkCommonSystem
>     vtkCommonTransforms
>   KIT
>     vtkCommon
>   )
> 
> Produces projects like:
> vtkCommon
> vtkCommonKitPython
> vtkCommonKitPythonD
> vtkCommonCoreObjects
> 
> and I?m just trying to understand how those get generated, how they
> are populated etc? I have started digging into the vtk CMake
> functions/macros but was hoping someone may have documented the Kit
> (sub?)system.

The idea here was to reduce the number of libraries that VTK generates
(to help minimize disk I/O when loading them). Basically, when
vtk_add_library is called, it sees if kits are enabled and what (if any)
kit the module is part of. It then goes and stores this information for
building the main kit libraries (if kits are enabled). It does this
using add_library(OBJECT) to create objects for each module and then the
kit library actually links all of these together into a library.

What are you looking to use kits for?

--Ben

From behollis at sci.utah.edu  Tue Mar  8 13:42:58 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Tue, 08 Mar 2016 11:42:58 -0700
Subject: [vtk-developers] passing vertex attributes to custom shader
	(Ken Martin)
In-Reply-To: <mailman.15.1457197203.5151.vtk-developers@vtk.org>
References: <mailman.15.1457197203.5151.vtk-developers@vtk.org>
Message-ID: <web-12230803@sci.utah.edu>

Thanks, Ken. I'm using the VTK Python bindings. It looks like 
vtkOpenGLHelper isn't wrapped.

Is there another way to set the uniforms besides of the method given 
in the C++ test program?

Regards,
Brad

> Date: Sat, 5 Mar 2016 08:05:40 -0500
>From: Ken Martin <ken.martin at kitware.com>
> To: Brad Hollister <behollis at sci.utah.edu>
> Cc: VTK Developers <vtk-developers at vtk.org>
> Subject: Re: [vtk-developers] passing vertex attributes to custom
> 	shader
> Message-ID:
> 	<CANXz0SY+P=YuTQFcWg+5=9pd9RiCxPNYQjrrMKERLPhm2ooFsg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Currently you can pass uniforms (see
> https://gitlab.kitware.com/vtk/vtk/blob/v7.0.0.rc2/Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx
> for an example). You currently cannot pass your own attributes 
>without
> subclassing, only work with the default ones that are passed
> (position/scalars/normals/tcoords)
> 
> Thanks
> Ken
> 
> On Fri, Mar 4, 2016 at 7:47 PM, Brad Hollister 
><behollis at sci.utah.edu>
> wrote:
> 
>> Hi,
>>
>> I've been using vtkOpenGLPolyDataMapper() to set custom vertex / 
>>fragment
>> shaders. I'd also like to provide user-defined vertex attributes 
>>accessible
>> in the shader code. I assumed from the documentation that
>> MapDataArrayToVertexAttributes() is the proper way to do this.
>>
>> However, I get the ERROR: vtkOpenGLPolyDataMapper (0x2872160): Not
>> implemented at this level...
>>
>> There doesn't appear to be a derived class of 
>>vtkOpenGLPolyDataMapper
>> available for my needs (which is that I'm specifying polygons via a
>> vtkPolyData object).
>>
>> Is it possible to pass vertex attributes and custom uniforms using
>> vtkOpenGLPolyDataMapper? Is there a different way from the one I've 
>>been
>> trying that makes this possible?
>>
>> Regards,
>> Brad
>> _______________________________________________
>> 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 arankin at robarts.ca  Tue Mar  8 14:23:08 2016
From: arankin at robarts.ca (Adam Rankin)
Date: Tue, 8 Mar 2016 19:23:08 +0000
Subject: [vtk-developers] Guide to implementing kits
In-Reply-To: <20160308161730.GA25514@megas.kitware.com>
References: <7afd231bfdd34c0a855c93250b2a9962@dag2.robarts.ca>
 <CANwS1=Gj4fs8yXtT+QV4KNBbP8wgzDbgkYuBjE+4WGB8CO2Lag@mail.gmail.com>
 <3abb85e5a29a48618d4a130f0076781b@dag2.robarts.ca>
 <20160308161730.GA25514@megas.kitware.com>
Message-ID: <0c71e49da5de4636818d9f813f9bea66@dag2.robarts.ca>

After reading your reply, I don't think kits will be necessary for our project. We don't have nearly the number of projects as VTK does.

I have since removed the kit entries from my module.cmake files and it generates and compiles as expected. Thanks!

Adam

-----Original Message-----
From: Ben Boeckel [mailto:ben.boeckel at kitware.com] 
Sent: Tuesday, March 08, 2016 11:18 AM
To: Adam Rankin <arankin at robarts.ca>
Cc: David Gobbi <david.gobbi at gmail.com>; vtk-developers at vtk.org
Subject: Re: [vtk-developers] Guide to implementing kits

On Tue, Mar 08, 2016 at 00:15:53 +0000, Adam Rankin wrote:
> Not quite. Specifically the kit part of the module system
> 
> For example:
> vtk_module(vtkCommonCore
>   GROUPS
>     StandAlone
>   PRIVATE_DEPENDS
>     vtksys
>   TEST_DEPENDS
>     vtkTestingCore
>     vtkCommonSystem
>     vtkCommonTransforms
>   KIT
>     vtkCommon
>   )
> 
> Produces projects like:
> vtkCommon
> vtkCommonKitPython
> vtkCommonKitPythonD
> vtkCommonCoreObjects
> 
> and I?m just trying to understand how those get generated, how they 
> are populated etc? I have started digging into the vtk CMake 
> functions/macros but was hoping someone may have documented the Kit 
> (sub?)system.

The idea here was to reduce the number of libraries that VTK generates (to help minimize disk I/O when loading them). Basically, when vtk_add_library is called, it sees if kits are enabled and what (if any) kit the module is part of. It then goes and stores this information for building the main kit libraries (if kits are enabled). It does this using add_library(OBJECT) to create objects for each module and then the kit library actually links all of these together into a library.

What are you looking to use kits for?

--Ben

From david.gobbi at gmail.com  Thu Mar 10 08:19:22 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 10 Mar 2016 06:19:22 -0700
Subject: [vtk-developers] New SMP implementation for image filters
Message-ID: <CANwS1=FRhvdL7jusbmFFqF4N5QQALYkD-1chSq4PszQvjXjmeA@mail.gmail.com>

Hi All,

As of today, the VTK imaging pipeline has a new implementation based
on vtkSMPTools.  A big chunk of this work is from the "Shared Memory
Parallelism" Google Summer of Code project for 2015.

Many of you will not see much difference, because the the imaging
pipeline has been multithreaded for many, many years.  The advantages
of the new implementation are that it provides more performance tuning,
and it will be easier to maintain as VTK moves forward.  The new SMP
code will only be used if you set VTK_SMP_IMPLEMENTATION_TYPE
to OpenMP or TBB in cmake.  Otherwise, the old threading code will be
used.

The main difference with the new implementation is the load balancing,
Previously, the data was divided evenly (or roughly so) among the threads.
So if there were 10 slices and 8 threads, then 6 of the threads would get
one slice, and 2 of the threads would get 2 slices.  Now, things follow
a different paradigm: the data is divided into a large number of pieces
that are queued for a thread pool.  Pieces are assigned to threads based
on thread availability, and overall CPU utilization is improved because
the load balancing is done dynamically.


So, what performance tuning is available and what gains can you expect
to see?  Let's look at the tuning first.  The following new methods are
available for image filters derived from vtkThreadedImageAlgorithm:

// Enable or disable the new behavior for all filters.
static void SetGlobalDefaultEnableSMP(bool);

// Enable or disable the new behavior for just one filter.
void SetEnableSMP(bool);

// Set the size of the image pieces that will be sent to the
// threads for execution. The ideal size will depend on the
// memory use pattern of the image filter that is being used,
// but the default size of 65536 bytes works well for most.
void SetDesiredBytesPerPiece(vtkIdType bytes);

// Set the minimum size of piece to send to a thread.  Obviously
// giving the threads one voxel at a time would be inefficient.
// A default minimum size of [16,1,1] ensures some contiguity.
void SetMinimumPieceSize(const int size[3]);

// Use pieces that are roughly square in shape (or cubic for 3D
// images).  This provides best results for filters that operate
// on a neighborhood around each output voxel.
void SetSplitModeToBlock();

// Use slab-shaped pieces.  This provides best results for filters
// that perform simple operations on the scalars, such as color mapping.
void SetSplitModeToSlab();

// Use thin rod-shaped pieces.  This also provides good results
// filters like color mapping.  I haven't yet found any algorithms
// for which this splitting method is the best to use.
void SetSplitModeToBeam();


The performance improvements to be gained by tweaking these parameters
are modest, usually less than 20%, but sometimes much higher.  As part
of this patch, I have added a new example to VTK called "ImageBenchmark"
that makes it easy to run a filter under different conditions in order to
optimize
the settings.  I'll create a wiki page in the future, but for now, you can
run "ImageBenchmark --help" to get a comprehensive description of all the
options (assuming that you built VTK with BUILD_EXAMPLES=ON).

Cheers,
  - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/1d6ec668/attachment.html>

From will.schroeder at kitware.com  Thu Mar 10 08:25:08 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Thu, 10 Mar 2016 08:25:08 -0500
Subject: [vtk-developers] New SMP implementation for image filters
In-Reply-To: <CANwS1=FRhvdL7jusbmFFqF4N5QQALYkD-1chSq4PszQvjXjmeA@mail.gmail.com>
References: <CANwS1=FRhvdL7jusbmFFqF4N5QQALYkD-1chSq4PszQvjXjmeA@mail.gmail.com>
Message-ID: <CAEiDrtVB8HZSpw4bFUJZH366BhAPZXbEcthYYSa+wUC9rEkY5g@mail.gmail.com>

Very nice David. Thanks for your contributions. I have found SMPTools to be
extremely easy to use and the fact that it takes care of load balancing
really simplifies the code and yields good results.
Best,
W

On Thu, Mar 10, 2016 at 8:19 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi All,
>
> As of today, the VTK imaging pipeline has a new implementation based
> on vtkSMPTools.  A big chunk of this work is from the "Shared Memory
> Parallelism" Google Summer of Code project for 2015.
>
> Many of you will not see much difference, because the the imaging
> pipeline has been multithreaded for many, many years.  The advantages
> of the new implementation are that it provides more performance tuning,
> and it will be easier to maintain as VTK moves forward.  The new SMP
> code will only be used if you set VTK_SMP_IMPLEMENTATION_TYPE
> to OpenMP or TBB in cmake.  Otherwise, the old threading code will be
> used.
>
> The main difference with the new implementation is the load balancing,
> Previously, the data was divided evenly (or roughly so) among the threads.
> So if there were 10 slices and 8 threads, then 6 of the threads would get
> one slice, and 2 of the threads would get 2 slices.  Now, things follow
> a different paradigm: the data is divided into a large number of pieces
> that are queued for a thread pool.  Pieces are assigned to threads based
> on thread availability, and overall CPU utilization is improved because
> the load balancing is done dynamically.
>
>
> So, what performance tuning is available and what gains can you expect
> to see?  Let's look at the tuning first.  The following new methods are
> available for image filters derived from vtkThreadedImageAlgorithm:
>
> // Enable or disable the new behavior for all filters.
> static void SetGlobalDefaultEnableSMP(bool);
>
> // Enable or disable the new behavior for just one filter.
> void SetEnableSMP(bool);
>
> // Set the size of the image pieces that will be sent to the
> // threads for execution. The ideal size will depend on the
> // memory use pattern of the image filter that is being used,
> // but the default size of 65536 bytes works well for most.
> void SetDesiredBytesPerPiece(vtkIdType bytes);
>
> // Set the minimum size of piece to send to a thread.  Obviously
> // giving the threads one voxel at a time would be inefficient.
> // A default minimum size of [16,1,1] ensures some contiguity.
> void SetMinimumPieceSize(const int size[3]);
>
> // Use pieces that are roughly square in shape (or cubic for 3D
> // images).  This provides best results for filters that operate
> // on a neighborhood around each output voxel.
> void SetSplitModeToBlock();
>
> // Use slab-shaped pieces.  This provides best results for filters
> // that perform simple operations on the scalars, such as color mapping.
> void SetSplitModeToSlab();
>
> // Use thin rod-shaped pieces.  This also provides good results
> // filters like color mapping.  I haven't yet found any algorithms
> // for which this splitting method is the best to use.
> void SetSplitModeToBeam();
>
>
> The performance improvements to be gained by tweaking these parameters
> are modest, usually less than 20%, but sometimes much higher.  As part
> of this patch, I have added a new example to VTK called "ImageBenchmark"
> that makes it easy to run a filter under different conditions in order to
> optimize
> the settings.  I'll create a wiki page in the future, but for now, you can
> run "ImageBenchmark --help" to get a comprehensive description of all the
> options (assuming that you built VTK with BUILD_EXAMPLES=ON).
>
> 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
>
>
>


-- 
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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/7a73493f/attachment.html>

From sujin.philip at kitware.com  Thu Mar 10 09:27:01 2016
From: sujin.philip at kitware.com (Sujin Philip)
Date: Thu, 10 Mar 2016 09:27:01 -0500
Subject: [vtk-developers] vtkAngularPeriodicFilter and vtkTransformFilter
Message-ID: <CAEWo2JN5xOEfYe_yUC1FOyd_0PyAg-sUrh3KX2C-V+yj7NW6Wg@mail.gmail.com>

Hi Developers,

I am working on some changes to vtkAngularPeriodicFilter and I have noticed
that for some cases it uses vtkTransformFilter to generate the result,
instead of using mapped arrays (vtkAngularPeriodicDataArray).

Going through the code, it looks like vtkTransformFilter behaves
differently than vtkAngularPeriodicFilter. Any field that has 3 or 9
components is transformed in vtkAngularPeriodicFilter but
vtkTransformFilter only transforms the normal
(vtkDataSetAttributes::GetNormals()) and vector
(vtkDataSetAttributes::GetVectors()) arrays.

I am thinking of changing vtkTransformFilter to apply transformation on all
3 and 9 components arrays. I wanted to know if there is any reason this
should not be done.

Thanks
Sujin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/081f2d92/attachment.html>

From mathieu.westphal at kitware.com  Thu Mar 10 09:32:19 2016
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Thu, 10 Mar 2016 15:32:19 +0100
Subject: [vtk-developers] vtkAngularPeriodicFilter and vtkTransformFilter
In-Reply-To: <CAEWo2JN5xOEfYe_yUC1FOyd_0PyAg-sUrh3KX2C-V+yj7NW6Wg@mail.gmail.com>
References: <CAEWo2JN5xOEfYe_yUC1FOyd_0PyAg-sUrh3KX2C-V+yj7NW6Wg@mail.gmail.com>
Message-ID: <CAC2t4US+Sf0w1se4is1Y914RbYBU8zM=tLbioP7zQGncmeRaaQ@mail.gmail.com>

Afair, the vtkTransform usage in vtkAngularPeriodicFilter was only a
fallback solution when vtkAngularPeriodicDataArray could not be used for
some reason, it is not efficient and is (or at least should) generating a
warning when used.

No advice concerning the vtkTransform changes.

Mathieu


Mathieu Westphal

On Thu, Mar 10, 2016 at 3:27 PM, Sujin Philip <sujin.philip at kitware.com>
wrote:

> Hi Developers,
>
> I am working on some changes to vtkAngularPeriodicFilter and I have
> noticed that for some cases it uses vtkTransformFilter to generate the
> result, instead of using mapped arrays (vtkAngularPeriodicDataArray).
>
> Going through the code, it looks like vtkTransformFilter behaves
> differently than vtkAngularPeriodicFilter. Any field that has 3 or 9
> components is transformed in vtkAngularPeriodicFilter but
> vtkTransformFilter only transforms the normal
> (vtkDataSetAttributes::GetNormals()) and vector
> (vtkDataSetAttributes::GetVectors()) arrays.
>
> I am thinking of changing vtkTransformFilter to apply transformation on
> all 3 and 9 components arrays. I wanted to know if there is any reason this
> should not be done.
>
> Thanks
> Sujin
>
>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/e02efc2d/attachment-0001.html>

From dave.demarle at kitware.com  Thu Mar 10 10:55:26 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 10 Mar 2016 10:55:26 -0500
Subject: [vtk-developers] vtkAngularPeriodicFilter and vtkTransformFilter
In-Reply-To: <CAC2t4US+Sf0w1se4is1Y914RbYBU8zM=tLbioP7zQGncmeRaaQ@mail.gmail.com>
References: <CAEWo2JN5xOEfYe_yUC1FOyd_0PyAg-sUrh3KX2C-V+yj7NW6Wg@mail.gmail.com>
 <CAC2t4US+Sf0w1se4is1Y914RbYBU8zM=tLbioP7zQGncmeRaaQ@mail.gmail.com>
Message-ID: <CANjZAi8RGdPD_wuqWoUce9W7YQ1nOeLFsLAxkYNOnyd_uVkUGw@mail.gmail.com>

I believe transform filter doesn't transform vector results because it
should not transform normals and similar quantities which would be
invalidated by the transformation.



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 10, 2016 at 9:32 AM, Mathieu Westphal <
mathieu.westphal at kitware.com> wrote:

> Afair, the vtkTransform usage in vtkAngularPeriodicFilter was only a
> fallback solution when vtkAngularPeriodicDataArray could not be used for
> some reason, it is not efficient and is (or at least should) generating a
> warning when used.
>
> No advice concerning the vtkTransform changes.
>
> Mathieu
>
>
> Mathieu Westphal
>
> On Thu, Mar 10, 2016 at 3:27 PM, Sujin Philip <sujin.philip at kitware.com>
> wrote:
>
>> Hi Developers,
>>
>> I am working on some changes to vtkAngularPeriodicFilter and I have
>> noticed that for some cases it uses vtkTransformFilter to generate the
>> result, instead of using mapped arrays (vtkAngularPeriodicDataArray).
>>
>> Going through the code, it looks like vtkTransformFilter behaves
>> differently than vtkAngularPeriodicFilter. Any field that has 3 or 9
>> components is transformed in vtkAngularPeriodicFilter but
>> vtkTransformFilter only transforms the normal
>> (vtkDataSetAttributes::GetNormals()) and vector
>> (vtkDataSetAttributes::GetVectors()) arrays.
>>
>> I am thinking of changing vtkTransformFilter to apply transformation on
>> all 3 and 9 components arrays. I wanted to know if there is any reason this
>> should not be done.
>>
>> Thanks
>> Sujin
>>
>>
>> _______________________________________________
>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/ef096413/attachment.html>

From sujin.philip at kitware.com  Thu Mar 10 11:23:04 2016
From: sujin.philip at kitware.com (Sujin Philip)
Date: Thu, 10 Mar 2016 11:23:04 -0500
Subject: [vtk-developers] vtkAngularPeriodicFilter and vtkTransformFilter
In-Reply-To: <CANjZAi8RGdPD_wuqWoUce9W7YQ1nOeLFsLAxkYNOnyd_uVkUGw@mail.gmail.com>
References: <CAEWo2JN5xOEfYe_yUC1FOyd_0PyAg-sUrh3KX2C-V+yj7NW6Wg@mail.gmail.com>
 <CAC2t4US+Sf0w1se4is1Y914RbYBU8zM=tLbioP7zQGncmeRaaQ@mail.gmail.com>
 <CANjZAi8RGdPD_wuqWoUce9W7YQ1nOeLFsLAxkYNOnyd_uVkUGw@mail.gmail.com>
Message-ID: <CAEWo2JPBJZetJajwusees39eD35FJ9xFohXd5PUV8WNSSA=yNg@mail.gmail.com>

Hi Dave,

The transform filter does transform one normal and one vector array, but
ignores any others. It treats the normals as special (multiplies by the
transposed inverse matrix).

-Sujin


On Thu, Mar 10, 2016 at 10:55 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> I believe transform filter doesn't transform vector results because it
> should not transform normals and similar quantities which would be
> invalidated by the transformation.
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Mar 10, 2016 at 9:32 AM, Mathieu Westphal <
> mathieu.westphal at kitware.com> wrote:
>
>> Afair, the vtkTransform usage in vtkAngularPeriodicFilter was only a
>> fallback solution when vtkAngularPeriodicDataArray could not be used for
>> some reason, it is not efficient and is (or at least should) generating a
>> warning when used.
>>
>> No advice concerning the vtkTransform changes.
>>
>> Mathieu
>>
>>
>> Mathieu Westphal
>>
>> On Thu, Mar 10, 2016 at 3:27 PM, Sujin Philip <sujin.philip at kitware.com>
>> wrote:
>>
>>> Hi Developers,
>>>
>>> I am working on some changes to vtkAngularPeriodicFilter and I have
>>> noticed that for some cases it uses vtkTransformFilter to generate the
>>> result, instead of using mapped arrays (vtkAngularPeriodicDataArray).
>>>
>>> Going through the code, it looks like vtkTransformFilter behaves
>>> differently than vtkAngularPeriodicFilter. Any field that has 3 or 9
>>> components is transformed in vtkAngularPeriodicFilter but
>>> vtkTransformFilter only transforms the normal
>>> (vtkDataSetAttributes::GetNormals()) and vector
>>> (vtkDataSetAttributes::GetVectors()) arrays.
>>>
>>> I am thinking of changing vtkTransformFilter to apply transformation on
>>> all 3 and 9 components arrays. I wanted to know if there is any reason this
>>> should not be done.
>>>
>>> Thanks
>>> Sujin
>>>
>>>
>>> _______________________________________________
>>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/15fb9ddb/attachment.html>

From david.gobbi at gmail.com  Thu Mar 10 11:43:08 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 10 Mar 2016 09:43:08 -0700
Subject: [vtk-developers] vtkAngularPeriodicFilter and vtkTransformFilter
In-Reply-To: <CAEWo2JPBJZetJajwusees39eD35FJ9xFohXd5PUV8WNSSA=yNg@mail.gmail.com>
References: <CAEWo2JN5xOEfYe_yUC1FOyd_0PyAg-sUrh3KX2C-V+yj7NW6Wg@mail.gmail.com>
 <CAC2t4US+Sf0w1se4is1Y914RbYBU8zM=tLbioP7zQGncmeRaaQ@mail.gmail.com>
 <CANjZAi8RGdPD_wuqWoUce9W7YQ1nOeLFsLAxkYNOnyd_uVkUGw@mail.gmail.com>
 <CAEWo2JPBJZetJajwusees39eD35FJ9xFohXd5PUV8WNSSA=yNg@mail.gmail.com>
Message-ID: <CANwS1=FZtMq0ciLo09KEUe7r20_GsjqeUt14+i870fX-2ao_-g@mail.gmail.com>

Fifteen years ago when I wrote the TransformPointsNormalsVectors() method,
VTK was much simpler.  The code should probably be generalized to handle
more attributes.

 - David


On Thu, Mar 10, 2016 at 9:23 AM, Sujin Philip <sujin.philip at kitware.com>
wrote:

> Hi Dave,
>
> The transform filter does transform one normal and one vector array, but
> ignores any others. It treats the normals as special (multiplies by the
> transposed inverse matrix).
>
> -Sujin
>
>
> On Thu, Mar 10, 2016 at 10:55 AM, David E DeMarle <
> dave.demarle at kitware.com> wrote:
>
>> I believe transform filter doesn't transform vector results because it
>> should not transform normals and similar quantities which would be
>> invalidated by the transformation.
>>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Thu, Mar 10, 2016 at 9:32 AM, Mathieu Westphal <
>> mathieu.westphal at kitware.com> wrote:
>>
>>> Afair, the vtkTransform usage in vtkAngularPeriodicFilter was only a
>>> fallback solution when vtkAngularPeriodicDataArray could not be used for
>>> some reason, it is not efficient and is (or at least should) generating a
>>> warning when used.
>>>
>>> No advice concerning the vtkTransform changes.
>>>
>>> Mathieu
>>>
>>>
>>> Mathieu Westphal
>>>
>>> On Thu, Mar 10, 2016 at 3:27 PM, Sujin Philip <sujin.philip at kitware.com>
>>> wrote:
>>>
>>>> Hi Developers,
>>>>
>>>> I am working on some changes to vtkAngularPeriodicFilter and I have
>>>> noticed that for some cases it uses vtkTransformFilter to generate the
>>>> result, instead of using mapped arrays (vtkAngularPeriodicDataArray).
>>>>
>>>> Going through the code, it looks like vtkTransformFilter behaves
>>>> differently than vtkAngularPeriodicFilter. Any field that has 3 or 9
>>>> components is transformed in vtkAngularPeriodicFilter but
>>>> vtkTransformFilter only transforms the normal
>>>> (vtkDataSetAttributes::GetNormals()) and vector
>>>> (vtkDataSetAttributes::GetVectors()) arrays.
>>>>
>>>> I am thinking of changing vtkTransformFilter to apply transformation on
>>>> all 3 and 9 components arrays. I wanted to know if there is any reason this
>>>> should not be done.
>>>>
>>>> Thanks
>>>> Sujin
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>
>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160310/47a076fd/attachment-0001.html>

From andrew.amaclean at gmail.com  Sat Mar 12 23:59:32 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 13 Mar 2016 15:59:32 +1100
Subject: [vtk-developers] New SMP implementation for image filters
Message-ID: <CAHDsG9NG28nANHNiYyrKpTRd4QrYn+C58KRjE9zV0mOEnpnJSQ@mail.gmail.com>

David,
   This is going to be really useful for tuning applications.
   I am trying it out on several different machines all using TBB.

  Thank You for all your efforts in writing this.

Regards
   Andrew


---------- Forwarded message ----------
> From: David Gobbi <david.gobbi at gmail.com>
> To: VTK Developers <vtk-developers at vtk.org>
> Cc:
> Date: Thu, 10 Mar 2016 06:19:22 -0700
> Subject: [vtk-developers] New SMP implementation for image filters
> Hi All,
>
> As of today, the VTK imaging pipeline has a new implementation based
> on vtkSMPTools.  A big chunk of this work is from the "Shared Memory
> Parallelism" Google Summer of Code project for 2015.
>
> Many of you will not see much difference, because the the imaging
> pipeline has been multithreaded for many, many years.  The advantages
> of the new implementation are that it provides more performance tuning,
> and it will be easier to maintain as VTK moves forward.  The new SMP
> code will only be used if you set VTK_SMP_IMPLEMENTATION_TYPE
> to OpenMP or TBB in cmake.  Otherwise, the old threading code will be
> used.
>
> The main difference with the new implementation is the load balancing,
> Previously, the data was divided evenly (or roughly so) among the threads.
> So if there were 10 slices and 8 threads, then 6 of the threads would get
> one slice, and 2 of the threads would get 2 slices.  Now, things follow
> a different paradigm: the data is divided into a large number of pieces
> that are queued for a thread pool.  Pieces are assigned to threads based
> on thread availability, and overall CPU utilization is improved because
> the load balancing is done dynamically.
>
>
> So, what performance tuning is available and what gains can you expect
> to see?  Let's look at the tuning first.  The following new methods are
> available for image filters derived from vtkThreadedImageAlgorithm:
>
> // Enable or disable the new behavior for all filters.
> static void SetGlobalDefaultEnableSMP(bool);
>
> // Enable or disable the new behavior for just one filter.
> void SetEnableSMP(bool);
>
> // Set the size of the image pieces that will be sent to the
> // threads for execution. The ideal size will depend on the
> // memory use pattern of the image filter that is being used,
> // but the default size of 65536 bytes works well for most.
> void SetDesiredBytesPerPiece(vtkIdType bytes);
>
> // Set the minimum size of piece to send to a thread.  Obviously
> // giving the threads one voxel at a time would be inefficient.
> // A default minimum size of [16,1,1] ensures some contiguity.
> void SetMinimumPieceSize(const int size[3]);
>
> // Use pieces that are roughly square in shape (or cubic for 3D
> // images).  This provides best results for filters that operate
> // on a neighborhood around each output voxel.
> void SetSplitModeToBlock();
>
> // Use slab-shaped pieces.  This provides best results for filters
> // that perform simple operations on the scalars, such as color mapping.
> void SetSplitModeToSlab();
>
> // Use thin rod-shaped pieces.  This also provides good results
> // filters like color mapping.  I haven't yet found any algorithms
> // for which this splitting method is the best to use.
> void SetSplitModeToBeam();
>
>
> The performance improvements to be gained by tweaking these parameters
> are modest, usually less than 20%, but sometimes much higher.  As part
> of this patch, I have added a new example to VTK called "ImageBenchmark"
> that makes it easy to run a filter under different conditions in order to
> optimize
> the settings.  I'll create a wiki page in the future, but for now, you can
> run "ImageBenchmark --help" to get a comprehensive description of all the
> options (assuming that you built VTK with BUILD_EXAMPLES=ON).
>
> Cheers,
>   - David
>
>
>
-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160313/15dc09b5/attachment.html>

From david.gobbi at gmail.com  Sun Mar 13 19:09:54 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Sun, 13 Mar 2016 17:09:54 -0600
Subject: [vtk-developers] New SMP implementation for image filters
In-Reply-To: <CAHDsG9NG28nANHNiYyrKpTRd4QrYn+C58KRjE9zV0mOEnpnJSQ@mail.gmail.com>
References: <CAHDsG9NG28nANHNiYyrKpTRd4QrYn+C58KRjE9zV0mOEnpnJSQ@mail.gmail.com>
Message-ID: <CANwS1=G1FuNXLQXs8oF-yBKkK_FM_cyQYHzjTLw9gC7BcDQskw@mail.gmail.com>

Hi Andrew,

Thanks for your kind words.  I have added a brief wiki page that describes
the benchmarking utility:
http://www.vtk.org/Wiki/VTK/ImageBenchmark

Cheers,
 - David

On Sat, Mar 12, 2016 at 9:59 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> David,
>    This is going to be really useful for tuning applications.
>    I am trying it out on several different machines all using TBB.
>
>   Thank You for all your efforts in writing this.
>
> Regards
>    Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160313/09db7291/attachment.html>

From aashish.chaudhary at kitware.com  Mon Mar 14 14:18:22 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Mon, 14 Mar 2016 14:18:22 -0400
Subject: [vtk-developers] Volume rendering tests on megas
Message-ID: <CAEw35Z_4cS8qigjxrnrLjweZ24XaJcij9CZdH8xerm9VTt_mWw@mail.gmail.com>

Hi all,

Just wanted to let you know that volume rendering tests always fail on
megas because of some combination of a non-proprietary driver, vnc, and
desktop setup (tile setup).

Currently Ben who manages that machines disables these tests manually as we
add new tests for rendering.

So if you see new volume rendering tests failing on that machine, please
ignore until we have a resolution in place.

Thanks,


-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
*| http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160314/629ad8c0/attachment.html>

From ken.martin at kitware.com  Mon Mar 14 15:53:38 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Mon, 14 Mar 2016 15:53:38 -0400
Subject: [vtk-developers] passing vertex attributes to custom shader
	(Ken Martin)
In-Reply-To: <web-12230803@sci.utah.edu>
References: <mailman.15.1457197203.5151.vtk-developers@vtk.org>
 <web-12230803@sci.utah.edu>
Message-ID: <CANXz0SY-=KDqdb-p1rZMPhcOux6q_bAD+9SR5mSZKwmem6NwOA@mail.gmail.com>

Hmmm, no, there isn't.  I was just looking at vtkOpenGLHelper, I'm not sure
if that class could be wrapped or if it has to be a subclass of vtkObject.
If it could be wrapped then we can just do that. You can try it by removing
it from the WRAP_EXCLUDE_PYTHON section of Rendering/OpenGL2/CMakeLists.txt

I also noticed the class exposes the vtkVertexArrayObject, with that you
might actually be able to provide your own attributes. I have not tried
that but I it might work.

On Tue, Mar 8, 2016 at 1:42 PM, Brad Hollister <behollis at sci.utah.edu>
wrote:

> Thanks, Ken. I'm using the VTK Python bindings. It looks like
> vtkOpenGLHelper isn't wrapped.
>
> Is there another way to set the uniforms besides of the method given in
> the C++ test program?
>
> Regards,
> Brad
>
> Date: Sat, 5 Mar 2016 08:05:40 -0500
>> From: Ken Martin <ken.martin at kitware.com>
>> To: Brad Hollister <behollis at sci.utah.edu>
>> Cc: VTK Developers <vtk-developers at vtk.org>
>> Subject: Re: [vtk-developers] passing vertex attributes to custom
>>         shader
>> Message-ID:
>>         <CANXz0SY+P=YuTQFcWg+5=
>> 9pd9RiCxPNYQjrrMKERLPhm2ooFsg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Currently you can pass uniforms (see
>>
>> https://gitlab.kitware.com/vtk/vtk/blob/v7.0.0.rc2/Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx
>> for an example). You currently cannot pass your own attributes without
>> subclassing, only work with the default ones that are passed
>> (position/scalars/normals/tcoords)
>>
>> Thanks
>> Ken
>>
>> On Fri, Mar 4, 2016 at 7:47 PM, Brad Hollister <behollis at sci.utah.edu>
>> wrote:
>>
>> Hi,
>>>
>>> I've been using vtkOpenGLPolyDataMapper() to set custom vertex / fragment
>>> shaders. I'd also like to provide user-defined vertex attributes
>>> accessible
>>> in the shader code. I assumed from the documentation that
>>> MapDataArrayToVertexAttributes() is the proper way to do this.
>>>
>>> However, I get the ERROR: vtkOpenGLPolyDataMapper (0x2872160): Not
>>> implemented at this level...
>>>
>>> There doesn't appear to be a derived class of vtkOpenGLPolyDataMapper
>>> available for my needs (which is that I'm specifying polygons via a
>>> vtkPolyData object).
>>>
>>> Is it possible to pass vertex attributes and custom uniforms using
>>> vtkOpenGLPolyDataMapper? Is there a different way from the one I've been
>>> trying that makes this possible?
>>>
>>> Regards,
>>> Brad
>>> _______________________________________________
>>> 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
>
>


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160314/f7617f63/attachment.html>

From dan.lipsa at kitware.com  Mon Mar 14 17:23:42 2016
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Mon, 14 Mar 2016 17:23:42 -0400
Subject: [vtk-developers] vtkDataSetAttributes::COPYTUPLE for GlobalIds
 and appending data
In-Reply-To: <54D8995E.3090000@dsl.pipex.com>
References: <CADwGrVpe=zM=VYcmpqhCnBG=0nCG3HyfRHEBeR6kXojS=CiSRQ@mail.gmail.com>
 <CAKME8fHkpJCTGjfqF3x_Lm=WyyijgS3otagAvN_sNs0hVPi3KA@mail.gmail.com>
 <54D8995E.3090000@dsl.pipex.com>
Message-ID: <CADwGrVrvWotAHLNLs-abUTDyMoeCaCz5CQ3pAjNSru9jec2Rsw@mail.gmail.com>

As it happens, I hit this problem in a different project, more than a year
after I first encountered it. I wanted to share the workaround I have used
then which works in my new project as well.

To prevent append or other VTK filters from removing the GLOBALIDS a
solution is to unset the GLOBALIDS attribute on the dataset:

    attributes.SetActiveAttribute(-1, attributes.GLOBALIDS);

Later on, you can access the global ids array using the name you used for
it.

Regards,
Dan


On Mon, Feb 9, 2015 at 6:26 AM, John Platt <jcplatt at dsl.pipex.com> wrote:

> Hi,
>
> This problem also arises when an unstructured grid must be split into
> parts because the field data is not continuous, for example, stresses
> between two different materials. Appending the parts again for node
> labelling loses the global Ids (node numbers) .
>
> vtkClipPolyData does not copy point global Ids which is reasonable because
> the data would typically need to be interpolated. But if the poly data
> consists solely of vertices, it is safe to copy them. vtkShrinkFilter does
> not copy cell global Ids; vtkUnstructuredGridGeometryFilter does not copy
> point global Ids (VTK 5.10.1).
>
> I would definitely go for an API on the algorithm which allows
> specification of attribute data to be copied.
>
> Thanks.
>
> John.
>
>
>
> On 06/02/2015 20:33, David Cole via vtk-developers wrote:
>
>> When I read "if COPYTUPLE for an attribute is 0, data is still copied"
>> I think to myself, well that doesn't seem to make sense...
>>
>> I think (2) sounds like a better idea.
>>
>>
>> 2 cents,
>> D
>>
>>
>>
>> On Fri, Feb 6, 2015 at 3:12 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>
>>> Hello all,
>>> We would like the feedback of the community for the following problem:
>>>
>>> In an append operation, the GLOBALIDS array is not copied to the output
>>> because, by default, vtkDataSetAttributes::COPYTUPLE is 0 for the
>>> vtkDataSetAttributes::GLOBALIDS attribute.
>>>
>>> This behavior makes sense if appending datasets coming from different
>>> sources, but it does work in a ParaView use case.
>>>
>>> In ParaView running with a remote pvserver configuration, data is
>>> processed
>>> on MPI nodes, sent to node 0 and appended together there (using
>>> vktAppendCompositeDataLeaves) and then sent to the client. In this case,
>>> the
>>> GLOBALIDS arrays is valid, and should be preserved.
>>>
>>> We are thinking of two possible/alternate solutions to this problem:
>>>
>>> 1. Change vtkDataSetAttributes such that if COPYTUPLE for an attribute
>>> is 0,
>>> data is still copied but it does not set that attribute as an active
>>> attribute (using vtkDataSetAttributes::SetActiveAttribute).
>>>
>>>
>>> 2.  Provide API for vktAppendCompositeDataLeaves (and vtkAppendFilter,
>>> vtkAppendPolyData) that
>>> specifies that the GLOBALIDS should be copied.
>>>
>>> Do you have any feedback on this?
>>>
>>> Thank you,
>>> Dan
>>>
>>>
>>> _______________________________________________
>>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160314/1190cb3a/attachment.html>

From berk.geveci at kitware.com  Wed Mar 16 10:05:56 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 16 Mar 2016 10:05:56 -0400
Subject: [vtk-developers] vtkDataSetAttributes::COPYTUPLE for GlobalIds
 and appending data
In-Reply-To: <CADwGrVrvWotAHLNLs-abUTDyMoeCaCz5CQ3pAjNSru9jec2Rsw@mail.gmail.com>
References: <CADwGrVpe=zM=VYcmpqhCnBG=0nCG3HyfRHEBeR6kXojS=CiSRQ@mail.gmail.com>
 <CAKME8fHkpJCTGjfqF3x_Lm=WyyijgS3otagAvN_sNs0hVPi3KA@mail.gmail.com>
 <54D8995E.3090000@dsl.pipex.com>
 <CADwGrVrvWotAHLNLs-abUTDyMoeCaCz5CQ3pAjNSru9jec2Rsw@mail.gmail.com>
Message-ID: <CAE32kpXHswoLa3DbORnq=iG58Ct_SUEzctCVOZFds1qXQcZUYg@mail.gmail.com>

The only correct & general solution for this is to provide an API on the
filter. Sometimes it is correct to copy global ids, sometimes it is not.
The append filter could go either way depending on the data.

PS: vtkShrinkFilter should never copy global ids since it duplicates points.

On Mon, Mar 14, 2016 at 5:23 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:

> As it happens, I hit this problem in a different project, more than a year
> after I first encountered it. I wanted to share the workaround I have used
> then which works in my new project as well.
>
> To prevent append or other VTK filters from removing the GLOBALIDS a
> solution is to unset the GLOBALIDS attribute on the dataset:
>
>     attributes.SetActiveAttribute(-1, attributes.GLOBALIDS);
>
> Later on, you can access the global ids array using the name you used for
> it.
>
> Regards,
> Dan
>
>
> On Mon, Feb 9, 2015 at 6:26 AM, John Platt <jcplatt at dsl.pipex.com> wrote:
>
>> Hi,
>>
>> This problem also arises when an unstructured grid must be split into
>> parts because the field data is not continuous, for example, stresses
>> between two different materials. Appending the parts again for node
>> labelling loses the global Ids (node numbers) .
>>
>> vtkClipPolyData does not copy point global Ids which is reasonable
>> because the data would typically need to be interpolated. But if the poly
>> data consists solely of vertices, it is safe to copy them. vtkShrinkFilter
>> does not copy cell global Ids; vtkUnstructuredGridGeometryFilter does not
>> copy point global Ids (VTK 5.10.1).
>>
>> I would definitely go for an API on the algorithm which allows
>> specification of attribute data to be copied.
>>
>> Thanks.
>>
>> John.
>>
>>
>>
>> On 06/02/2015 20:33, David Cole via vtk-developers wrote:
>>
>>> When I read "if COPYTUPLE for an attribute is 0, data is still copied"
>>> I think to myself, well that doesn't seem to make sense...
>>>
>>> I think (2) sounds like a better idea.
>>>
>>>
>>> 2 cents,
>>> D
>>>
>>>
>>>
>>> On Fri, Feb 6, 2015 at 3:12 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>>
>>>> Hello all,
>>>> We would like the feedback of the community for the following problem:
>>>>
>>>> In an append operation, the GLOBALIDS array is not copied to the output
>>>> because, by default, vtkDataSetAttributes::COPYTUPLE is 0 for the
>>>> vtkDataSetAttributes::GLOBALIDS attribute.
>>>>
>>>> This behavior makes sense if appending datasets coming from different
>>>> sources, but it does work in a ParaView use case.
>>>>
>>>> In ParaView running with a remote pvserver configuration, data is
>>>> processed
>>>> on MPI nodes, sent to node 0 and appended together there (using
>>>> vktAppendCompositeDataLeaves) and then sent to the client. In this
>>>> case, the
>>>> GLOBALIDS arrays is valid, and should be preserved.
>>>>
>>>> We are thinking of two possible/alternate solutions to this problem:
>>>>
>>>> 1. Change vtkDataSetAttributes such that if COPYTUPLE for an attribute
>>>> is 0,
>>>> data is still copied but it does not set that attribute as an active
>>>> attribute (using vtkDataSetAttributes::SetActiveAttribute).
>>>>
>>>>
>>>> 2.  Provide API for vktAppendCompositeDataLeaves (and vtkAppendFilter,
>>>> vtkAppendPolyData) that
>>>> specifies that the GLOBALIDS should be copied.
>>>>
>>>> Do you have any feedback on this?
>>>>
>>>> Thank you,
>>>> Dan
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>
>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160316/a6f29b75/attachment.html>

From dan.lipsa at kitware.com  Wed Mar 16 11:22:03 2016
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Wed, 16 Mar 2016 11:22:03 -0400
Subject: [vtk-developers] vtkDataSetAttributes::COPYTUPLE for GlobalIds
 and appending data
In-Reply-To: <CAE32kpXHswoLa3DbORnq=iG58Ct_SUEzctCVOZFds1qXQcZUYg@mail.gmail.com>
References: <CADwGrVpe=zM=VYcmpqhCnBG=0nCG3HyfRHEBeR6kXojS=CiSRQ@mail.gmail.com>
 <CAKME8fHkpJCTGjfqF3x_Lm=WyyijgS3otagAvN_sNs0hVPi3KA@mail.gmail.com>
 <54D8995E.3090000@dsl.pipex.com>
 <CADwGrVrvWotAHLNLs-abUTDyMoeCaCz5CQ3pAjNSru9jec2Rsw@mail.gmail.com>
 <CAE32kpXHswoLa3DbORnq=iG58Ct_SUEzctCVOZFds1qXQcZUYg@mail.gmail.com>
Message-ID: <CADwGrVrQf_-arN0V21w5pheM56kq+QdZS8gZOjcn8Medqi7U+w@mail.gmail.com>

Indeed, this workaround requires the relevant dataset to be available. It
just happened that this was the case in both projects. For a general
pipeline, where Update() is not called by the user on the relevant filter
this workaround would be trickier to use.
The API Berk suggested would work in both cases and it would be explicit
which is another big advantage.
Dan

On Wed, Mar 16, 2016 at 10:05 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> The only correct & general solution for this is to provide an API on the
> filter. Sometimes it is correct to copy global ids, sometimes it is not.
> The append filter could go either way depending on the data.
>
> PS: vtkShrinkFilter should never copy global ids since it duplicates
> points.
>
> On Mon, Mar 14, 2016 at 5:23 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>
>> As it happens, I hit this problem in a different project, more than a
>> year after I first encountered it. I wanted to share the workaround I have
>> used then which works in my new project as well.
>>
>> To prevent append or other VTK filters from removing the GLOBALIDS a
>> solution is to unset the GLOBALIDS attribute on the dataset:
>>
>>     attributes.SetActiveAttribute(-1, attributes.GLOBALIDS);
>>
>> Later on, you can access the global ids array using the name you used for
>> it.
>>
>> Regards,
>> Dan
>>
>>
>> On Mon, Feb 9, 2015 at 6:26 AM, John Platt <jcplatt at dsl.pipex.com> wrote:
>>
>>> Hi,
>>>
>>> This problem also arises when an unstructured grid must be split into
>>> parts because the field data is not continuous, for example, stresses
>>> between two different materials. Appending the parts again for node
>>> labelling loses the global Ids (node numbers) .
>>>
>>> vtkClipPolyData does not copy point global Ids which is reasonable
>>> because the data would typically need to be interpolated. But if the poly
>>> data consists solely of vertices, it is safe to copy them. vtkShrinkFilter
>>> does not copy cell global Ids; vtkUnstructuredGridGeometryFilter does not
>>> copy point global Ids (VTK 5.10.1).
>>>
>>> I would definitely go for an API on the algorithm which allows
>>> specification of attribute data to be copied.
>>>
>>> Thanks.
>>>
>>> John.
>>>
>>>
>>>
>>> On 06/02/2015 20:33, David Cole via vtk-developers wrote:
>>>
>>>> When I read "if COPYTUPLE for an attribute is 0, data is still copied"
>>>> I think to myself, well that doesn't seem to make sense...
>>>>
>>>> I think (2) sounds like a better idea.
>>>>
>>>>
>>>> 2 cents,
>>>> D
>>>>
>>>>
>>>>
>>>> On Fri, Feb 6, 2015 at 3:12 PM, Dan Lipsa <dan.lipsa at kitware.com>
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>> We would like the feedback of the community for the following problem:
>>>>>
>>>>> In an append operation, the GLOBALIDS array is not copied to the output
>>>>> because, by default, vtkDataSetAttributes::COPYTUPLE is 0 for the
>>>>> vtkDataSetAttributes::GLOBALIDS attribute.
>>>>>
>>>>> This behavior makes sense if appending datasets coming from different
>>>>> sources, but it does work in a ParaView use case.
>>>>>
>>>>> In ParaView running with a remote pvserver configuration, data is
>>>>> processed
>>>>> on MPI nodes, sent to node 0 and appended together there (using
>>>>> vktAppendCompositeDataLeaves) and then sent to the client. In this
>>>>> case, the
>>>>> GLOBALIDS arrays is valid, and should be preserved.
>>>>>
>>>>> We are thinking of two possible/alternate solutions to this problem:
>>>>>
>>>>> 1. Change vtkDataSetAttributes such that if COPYTUPLE for an attribute
>>>>> is 0,
>>>>> data is still copied but it does not set that attribute as an active
>>>>> attribute (using vtkDataSetAttributes::SetActiveAttribute).
>>>>>
>>>>>
>>>>> 2.  Provide API for vktAppendCompositeDataLeaves (and vtkAppendFilter,
>>>>> vtkAppendPolyData) that
>>>>> specifies that the GLOBALIDS should be copied.
>>>>>
>>>>> Do you have any feedback on this?
>>>>>
>>>>> Thank you,
>>>>> Dan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160316/c463ba08/attachment-0001.html>

From behollis at sci.utah.edu  Wed Mar 16 16:27:01 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Wed, 16 Mar 2016 14:27:01 -0600
Subject: [vtk-developers] Using Draw() from vtkOpenGLPolyDataMapper with
	Python Wrapper
Message-ID: <web-12325898@sci.utah.edu>

Hi,

So, I am wanting to specify user-defined vertex attributes since the 
vtkOpenGLPolyDataMapper class doesn't allow this. I've seen mention of 
using the Render() from a mapper:

http://vtk.1045678.n5.nabble.com/OpenGL-with-VTK-td5685633.html

However, I believe the posting may be wrong or out-of-date regarding 
Render(). It looks like the Draw() function:

virtual int vtkOpenGLPolyDataMapper::Draw(vtkRenderer * ren,vtkActor 
*a)
Draw method for OpenGL.
http://www.vtk.org/doc/release/7.0/html/classvtkOpenGLPolyDataMapper.html#a07de87549ffc824200b5e2eca5b4df97

is the way to go here.

Are there any examples of this being used? I am using the Python 
interface, so this should be possible in Python.

Regards,
Brad



From david.gobbi at gmail.com  Wed Mar 16 17:07:41 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 16 Mar 2016 15:07:41 -0600
Subject: [vtk-developers] Nightly Doxygen
Message-ID: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>

Are the nightly doxygen pages not generated anymore?

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160316/f47e640b/attachment.html>

From utkarsh.ayachit at kitware.com  Wed Mar 16 17:26:58 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 16 Mar 2016 17:26:58 -0400
Subject: [vtk-developers] Nightly Doxygen
In-Reply-To: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
References: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
Message-ID: <CADHSJjDQ_HSAc5q3hFx9w+6iNMmPn47xuOjqhqt91aBRWqnhCA@mail.gmail.com>

Yup. It's been on the TODO list to add a new buildbot machine to do
that (similar to how we do for ParaView). Ben, any ETA on that?

On Wed, Mar 16, 2016 at 5:07 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Are the nightly doxygen pages not generated anymore?
>
>  - 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
>
>

From behollis at sci.utah.edu  Wed Mar 16 19:15:21 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Wed, 16 Mar 2016 17:15:21 -0600
Subject: [vtk-developers] Direct OpenGL Calls with derived
	vtkOpenGLPolyDataMapper
Message-ID: <web-12328066@sci.utah.edu>

How would it be possible to call directly to OpenGL with a derived 
mapper object (simple example below) and draw into the VTK window 
using Python? I've tried a similar bit of code, but the overriden 
Render() is never called. A few old forum emails state that it is 
possible to override the Render function (or maybe Draw() with 7.0) 
and issue calls directly to OpenGL for the current VTK render window.

class vtkOpenGLPolyDataMapperCustom(vtkOpenGLPolyDataMapper):
     def __init__(self):
         print "calling init in derived class"
         vtkOpenGLPolyDataMapper.__init__(self)

     def Render( self, ren, act ):
         print 'Render overriden function is being called...'
         ren.GetRenderWindow().MakeCurrent()
         self.drawUsingOpenGL()

     def drawUsingOpenGL(self):
         glLoadIdentity()
         glBegin(GL_QUADS)
         glVertex3f(-1.0, 1.0, 0.0)
         glVertex3f(-1.1, 1.0, 0.0)
         glVertex3f(-1.1, 0.5, 0.0)
         glVertex3f(-1.0, 0.5, 0.0)
         glEnd()
 

From david.gobbi at gmail.com  Wed Mar 16 19:34:17 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 16 Mar 2016 17:34:17 -0600
Subject: [vtk-developers] Direct OpenGL Calls with derived
	vtkOpenGLPolyDataMapper
In-Reply-To: <web-12328066@sci.utah.edu>
References: <web-12328066@sci.utah.edu>
Message-ID: <CANwS1=G0CgiAbTk+9cQmUMzoFpLGYgU4GC8Tn8Xei7Lx8pB3jw@mail.gmail.com>

Hi Brad,

Overriding a virtual C++ method in Python only works if the method is
called from Python.  In this case, the Render method is being called from
C++.

 - David

On Wed, Mar 16, 2016 at 5:15 PM, Brad Hollister <behollis at sci.utah.edu>
wrote:

> How would it be possible to call directly to OpenGL with a derived mapper
> object (simple example below) and draw into the VTK window using Python?
> I've tried a similar bit of code, but the overriden Render() is never
> called. A few old forum emails state that it is possible to override the
> Render function (or maybe Draw() with 7.0) and issue calls directly to
> OpenGL for the current VTK render window.
>
> class vtkOpenGLPolyDataMapperCustom(vtkOpenGLPolyDataMapper):
>     def __init__(self):
>         print "calling init in derived class"
>         vtkOpenGLPolyDataMapper.__init__(self)
>
>     def Render( self, ren, act ):
>         print 'Render overriden function is being called...'
>         ren.GetRenderWindow().MakeCurrent()
>         self.drawUsingOpenGL()
>
>     def drawUsingOpenGL(self):
>         glLoadIdentity()
>         glBegin(GL_QUADS)
>         glVertex3f(-1.0, 1.0, 0.0)
>         glVertex3f(-1.1, 1.0, 0.0)
>         glVertex3f(-1.1, 0.5, 0.0)
>         glVertex3f(-1.0, 0.5, 0.0)
>         glEnd()
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160316/3698499c/attachment.html>

From tharun160190 at gmail.com  Thu Mar 17 03:22:22 2016
From: tharun160190 at gmail.com (Tharun)
Date: Thu, 17 Mar 2016 00:22:22 -0700 (MST)
Subject: [vtk-developers] Improper functioning of vtkStripper
Message-ID: <1458199342025-5737237.post@n5.nabble.com>

vtkStripper is not able to combine lines having same point as starting point
in one line and end point in another line in my case.

Is vtkStripper capable of combining lines in above said case or am I missing
something? 



--
View this message in context: http://vtk.1045678.n5.nabble.com/Improper-functioning-of-vtkStripper-tp5737237.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From pip010 at gmail.com  Thu Mar 17 05:31:05 2016
From: pip010 at gmail.com (Petar Petrov)
Date: Thu, 17 Mar 2016 10:31:05 +0100
Subject: [vtk-developers] vtkActor2D and layer ordering ?
Message-ID: <CAFr3OaniCWK-qbaQYLxZ5fYj9Z0+CKBbn85Q6sr2-dh+2=4vQA@mail.gmail.com>

I found at least 3 ways that might influence z-order of 2D actors:

1) vtkActor2D->SetLayerNumber(int)
2) vtkImageMapper->SetZSlice()
3) vtkProperty2D->SetDsiplayToBackground/Foreground()

None of which seems to do the job. also previous similar question:
http://public.kitware.com/pipermail/vtkusers/2010-February/057204.html

Before vtk7.0, at least point 3 was working, now in vtk7.0 it also stopped
working.

So my question is how can I influence z-ordering of 2Dactors as per latest
vtk?

Cheers,
Petar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/aedcd948/attachment.html>

From lasso at queensu.ca  Thu Mar 17 08:04:07 2016
From: lasso at queensu.ca (Andras Lasso)
Date: Thu, 17 Mar 2016 12:04:07 +0000
Subject: [vtk-developers] vtkActor2D and layer ordering ?
In-Reply-To: <CAFr3OaniCWK-qbaQYLxZ5fYj9Z0+CKBbn85Q6sr2-dh+2=4vQA@mail.gmail.com>
References: <CAFr3OaniCWK-qbaQYLxZ5fYj9Z0+CKBbn85Q6sr2-dh+2=4vQA@mail.gmail.com>
Message-ID: <DM2PR07MB3502875C6497283281571BCD88B0@DM2PR07MB350.namprd07.prod.outlook.com>

I would be interested in this, too.

When building 3D Slicer with OpenGL backend then everything works well. Switching to OpenGL2 bckend improves performance, fixes transparent polydata rendering, and volume rendering (great!), but there are 2D actor ordering issues all over the place.

How 2D actor ordering is changed in OpenGL2 and what should we change in our applications to have the same behavior as with OpenGL?

Andras

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Petar Petrov
Sent: March 17, 2016 5:31 AM
To: vtk-developers at vtk.org; vtkusers at vtk.org
Subject: [vtk-developers] vtkActor2D and layer ordering ?


I found at least 3 ways that might influence z-order of 2D actors:

1) vtkActor2D->SetLayerNumber(int)
2) vtkImageMapper->SetZSlice()
3) vtkProperty2D->SetDsiplayToBackground/Foreground()

None of which seems to do the job. also previous similar question:
http://public.kitware.com/pipermail/vtkusers/2010-February/057204.html

Before vtk7.0, at least point 3 was working, now in vtk7.0 it also stopped working.

So my question is how can I influence z-ordering of 2Dactors as per latest vtk?

Cheers,
Petar





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/f4eb582b/attachment-0001.html>

From dave.demarle at kitware.com  Thu Mar 17 08:45:17 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 17 Mar 2016 08:45:17 -0400
Subject: [vtk-developers] Nightly Doxygen
In-Reply-To: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
References: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
Message-ID: <CANjZAi8cFj0ZuNc172POdPJ0SCFSyY4Umpz1zGC0uzAQHw+T9g@mail.gmail.com>

It hasn't updated in a while because londinium's debug submission has build
errors.

https://open.cdash.org/buildSummary.php?buildid=4256737#


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Wed, Mar 16, 2016 at 5:07 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Are the nightly doxygen pages not generated anymore?
>
>  - 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/a67b6cd7/attachment.html>

From david.gobbi at gmail.com  Thu Mar 17 08:52:13 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 17 Mar 2016 06:52:13 -0600
Subject: [vtk-developers] Nightly Doxygen
In-Reply-To: <CANjZAi8cFj0ZuNc172POdPJ0SCFSyY4Umpz1zGC0uzAQHw+T9g@mail.gmail.com>
References: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
 <CANjZAi8cFj0ZuNc172POdPJ0SCFSyY4Umpz1zGC0uzAQHw+T9g@mail.gmail.com>
Message-ID: <CANwS1=Hx9ptymGT=Q6GdV4VgidVtAQeCBqKUrpGAXtW9fgYOKg@mail.gmail.com>

Aha.  I've seen those errors on londinium, but I didn't know that it was
responsible for building the nightly docs.

On Thu, Mar 17, 2016 at 6:45 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> It hasn't updated in a while because londinium's debug submission has
> build errors.
>
> https://open.cdash.org/buildSummary.php?buildid=4256737#
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Wed, Mar 16, 2016 at 5:07 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Are the nightly doxygen pages not generated anymore?
>>
>>  - David
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/5ecce4de/attachment.html>

From dave.demarle at kitware.com  Thu Mar 17 09:01:22 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 17 Mar 2016 09:01:22 -0400
Subject: [vtk-developers] Nightly Doxygen
In-Reply-To: <CANwS1=Hx9ptymGT=Q6GdV4VgidVtAQeCBqKUrpGAXtW9fgYOKg@mail.gmail.com>
References: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
 <CANjZAi8cFj0ZuNc172POdPJ0SCFSyY4Umpz1zGC0uzAQHw+T9g@mail.gmail.com>
 <CANwS1=Hx9ptymGT=Q6GdV4VgidVtAQeCBqKUrpGAXtW9fgYOKg@mail.gmail.com>
Message-ID: <CANjZAi_44wKk-C29oaFmghUjJ2ysqj4b+u2qGMZjg+Xykk-5fA@mail.gmail.com>

I'll hunt down the responsible parties to make it submit again.

In the near term though we will move the responsibility to a buildbot
machine for greater visibility and reliability.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 17, 2016 at 8:52 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Aha.  I've seen those errors on londinium, but I didn't know that it was
> responsible for building the nightly docs.
>
> On Thu, Mar 17, 2016 at 6:45 AM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> It hasn't updated in a while because londinium's debug submission has
>> build errors.
>>
>> https://open.cdash.org/buildSummary.php?buildid=4256737#
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Wed, Mar 16, 2016 at 5:07 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>
>>> Are the nightly doxygen pages not generated anymore?
>>>
>>>  - David
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/cc0b6c99/attachment.html>

From ken.martin at kitware.com  Thu Mar 17 09:12:42 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Thu, 17 Mar 2016 09:12:42 -0400
Subject: [vtk-developers] vtkActor2D and layer ordering ?
In-Reply-To: <DM2PR07MB3502875C6497283281571BCD88B0@DM2PR07MB350.namprd07.prod.outlook.com>
References: <CAFr3OaniCWK-qbaQYLxZ5fYj9Z0+CKBbn85Q6sr2-dh+2=4vQA@mail.gmail.com>
 <DM2PR07MB3502875C6497283281571BCD88B0@DM2PR07MB350.namprd07.prod.outlook.com>
Message-ID: <CANXz0SbMHMj8degoKMy-vDFzFQFHf0gERtFfkMPQYueryRgAgw@mail.gmail.com>

I believe Bill Lorensen has/had a patch related to 2d actor depth in the
new OpenGL backend that has been merged into master

https://gitlab.kitware.com/vtk/vtk/merge_requests/1284

does that fix the issue?

Thanks
Ken

On Thu, Mar 17, 2016 at 8:04 AM, Andras Lasso <lasso at queensu.ca> wrote:

> I would be interested in this, too.
>
>
>
> When building 3D Slicer with OpenGL backend then everything works well.
> Switching to OpenGL2 bckend improves performance, fixes transparent
> polydata rendering, and volume rendering (great!), but there are 2D actor
> ordering issues all over the place.
>
>
>
> How 2D actor ordering is changed in OpenGL2 and what should we change in
> our applications to have the same behavior as with OpenGL?
>
>
>
> Andras
>
>
>
> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
> Of *Petar Petrov
> *Sent:* March 17, 2016 5:31 AM
> *To:* vtk-developers at vtk.org; vtkusers at vtk.org
> *Subject:* [vtk-developers] vtkActor2D and layer ordering ?
>
>
>
>
>
> I found at least 3 ways that might influence z-order of 2D actors:
>
>
>
> 1) vtkActor2D->SetLayerNumber(int)
>
> 2) vtkImageMapper->SetZSlice()
>
> 3) vtkProperty2D->SetDsiplayToBackground/Foreground()
>
>
>
> None of which seems to do the job. also previous similar question:
>
> http://public.kitware.com/pipermail/vtkusers/2010-February/057204.html
>
>
>
> Before vtk7.0, at least point 3 was working, now in vtk7.0 it also stopped
> working.
>
>
>
> So my question is how can I influence z-ordering of 2Dactors as per latest
> vtk?
>
>
>
> Cheers,
>
> Petar
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/cac2a7d7/attachment-0001.html>

From ken.martin at kitware.com  Thu Mar 17 10:12:19 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Thu, 17 Mar 2016 10:12:19 -0400
Subject: [vtk-developers] What is up with Agora?
Message-ID: <CANXz0SbHPew9LZW8m0anPoEgxNc6mQt1sdSw2BbwhmNu84TQBA@mail.gmail.com>

It seems to be off and on having issues. Anyone know what is up?



-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/53f77934/attachment.html>

From marcus.hanwell at kitware.com  Thu Mar 17 10:49:44 2016
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Thu, 17 Mar 2016 10:49:44 -0400
Subject: [vtk-developers] Nightly Doxygen
In-Reply-To: <CANjZAi_44wKk-C29oaFmghUjJ2ysqj4b+u2qGMZjg+Xykk-5fA@mail.gmail.com>
References: <CANwS1=G39Ukf+r1MCKn3GUhYnGiUurbf3sEkc8jSvsGLGTTtww@mail.gmail.com>
 <CANjZAi8cFj0ZuNc172POdPJ0SCFSyY4Umpz1zGC0uzAQHw+T9g@mail.gmail.com>
 <CANwS1=Hx9ptymGT=Q6GdV4VgidVtAQeCBqKUrpGAXtW9fgYOKg@mail.gmail.com>
 <CANjZAi_44wKk-C29oaFmghUjJ2ysqj4b+u2qGMZjg+Xykk-5fA@mail.gmail.com>
Message-ID: <CAMkPkZUoa79by_wxx80KsPQO+b6Ytk28hBcfohUmCJGEa4Jz-g@mail.gmail.com>

On Thu, Mar 17, 2016 at 9:01 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> I'll hunt down the responsible parties to make it submit again.
>
> In the near term though we will move the responsibility to a buildbot
> machine for greater visibility and reliability.
>
Yeah, that is my machine, I needed to upgrade system libraries, but
don't have the time I used to for dashboard maintenance. It may be
time to retire that machine from service anyway...

Marcus

From cory.quammen at kitware.com  Thu Mar 17 11:12:56 2016
From: cory.quammen at kitware.com (Cory Quammen)
Date: Thu, 17 Mar 2016 11:12:56 -0400
Subject: [vtk-developers] What is up with Agora?
In-Reply-To: <CANXz0SbHPew9LZW8m0anPoEgxNc6mQt1sdSw2BbwhmNu84TQBA@mail.gmail.com>
References: <CANXz0SbHPew9LZW8m0anPoEgxNc6mQt1sdSw2BbwhmNu84TQBA@mail.gmail.com>
Message-ID: <CAB5Fpx4uq3KnLoUT=HC2pH4p2dqDZEyO+H9Hiz4TaYtys+E+Tg@mail.gmail.com>

Dzenan reports that Agora's /tmp disk is full, which is likely causing problems.

Cory

On Thu, Mar 17, 2016 at 10:12 AM, Ken Martin <ken.martin at kitware.com> wrote:
> It seems to be off and on having issues. Anyone know what is up?
>
>
>
> --
> 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
>
>



-- 
Cory Quammen
R&D Engineer
Kitware, Inc.

From david.gobbi at gmail.com  Thu Mar 17 13:54:27 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 17 Mar 2016 11:54:27 -0600
Subject: [vtk-developers] Improper functioning of vtkStripper
In-Reply-To: <1458199342025-5737237.post@n5.nabble.com>
References: <1458199342025-5737237.post@n5.nabble.com>
Message-ID: <CANwS1=FSZmqiCqNCffdPmcLnnkenxONmYUXFH-hrt7cDakoWyg@mail.gmail.com>

On Thu, Mar 17, 2016 at 1:22 AM, Tharun <tharun160190 at gmail.com> wrote:

> vtkStripper is not able to combine lines having same point as starting
> point
> in one line and end point in another line in my case.
>
> Is vtkStripper capable of combining lines in above said case or am I
> missing
> something?
>

I remember that someone fixed this in VTK 7, but you will have to call
  stripper->JoinContiguousSegmentsOn();
before updating the stripper.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/01d38444/attachment.html>

From lasso at queensu.ca  Thu Mar 17 15:01:29 2016
From: lasso at queensu.ca (Andras Lasso)
Date: Thu, 17 Mar 2016 19:01:29 +0000
Subject: [vtk-developers] vtkActor2D and layer ordering ?
In-Reply-To: <CANXz0SbMHMj8degoKMy-vDFzFQFHf0gERtFfkMPQYueryRgAgw@mail.gmail.com>
References: <CAFr3OaniCWK-qbaQYLxZ5fYj9Z0+CKBbn85Q6sr2-dh+2=4vQA@mail.gmail.com>
 <DM2PR07MB3502875C6497283281571BCD88B0@DM2PR07MB350.namprd07.prod.outlook.com>
 <CANXz0SbMHMj8degoKMy-vDFzFQFHf0gERtFfkMPQYueryRgAgw@mail.gmail.com>
Message-ID: <DM2PR07MB3500D3B677952C3607C9283D88B0@DM2PR07MB350.namprd07.prod.outlook.com>

Unfortunately, that doesn?t fix the ordering issues for me. I?ll try to create a simple example to demonstrate the problem.

Andras

From: Ken Martin [mailto:ken.martin at kitware.com]
Sent: Thursday, March 17, 2016 9:13 AM
To: Andras Lasso <lasso at queensu.ca>
Cc: Petar Petrov <pip010 at gmail.com>; vtk-developers at vtk.org; vtkusers at vtk.org
Subject: Re: [vtk-developers] vtkActor2D and layer ordering ?

I believe Bill Lorensen has/had a patch related to 2d actor depth in the new OpenGL backend that has been merged into master

https://gitlab.kitware.com/vtk/vtk/merge_requests/1284

does that fix the issue?

Thanks
Ken

On Thu, Mar 17, 2016 at 8:04 AM, Andras Lasso <lasso at queensu.ca<mailto:lasso at queensu.ca>> wrote:
I would be interested in this, too.

When building 3D Slicer with OpenGL backend then everything works well. Switching to OpenGL2 bckend improves performance, fixes transparent polydata rendering, and volume rendering (great!), but there are 2D actor ordering issues all over the place.

How 2D actor ordering is changed in OpenGL2 and what should we change in our applications to have the same behavior as with OpenGL?

Andras

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org<mailto:vtk-developers-bounces at vtk.org>] On Behalf Of Petar Petrov
Sent: March 17, 2016 5:31 AM
To: vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>; vtkusers at vtk.org<mailto:vtkusers at vtk.org>
Subject: [vtk-developers] vtkActor2D and layer ordering ?


I found at least 3 ways that might influence z-order of 2D actors:

1) vtkActor2D->SetLayerNumber(int)
2) vtkImageMapper->SetZSlice()
3) vtkProperty2D->SetDsiplayToBackground/Foreground()

None of which seems to do the job. also previous similar question:
http://public.kitware.com/pipermail/vtkusers/2010-February/057204.html

Before vtk7.0, at least point 3 was working, now in vtk7.0 it also stopped working.

So my question is how can I influence z-ordering of 2Dactors as per latest vtk?

Cheers,
Petar






_______________________________________________
Powered by www.kitware.com<http://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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/ef8512cc/attachment.html>

From joseph.g.hennessey2.ctr at mail.mil  Thu Mar 17 16:04:08 2016
From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US))
Date: Thu, 17 Mar 2016 20:04:08 +0000
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation and
 near far planes correction (UNCLASSIFIED)
Message-ID: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>

CLASSIFICATION: UNCLASSIFIED

Hello,

I have modified 

Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum

To fix a problem with eyeseparation and near and far planes for use with
immersive paraview

The merge request is called

fix ComputeOffAxisProjectionFrustum eyeseparation and near and far planes.

https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296
d36afb

Commit 4fe4fabb420bba77740ec988d060c5c296d36afb

Authored by Joseph G. Hennessey about an hour ago
1 parent d52198e1

Please add this to VTK and indirectly to ParaView

Thanks,

Joe

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joseph G. Hennessey Ph.D., Lockheed Martin
Army Research Lab
DOD Supercomputing Resource Center


CLASSIFICATION: UNCLASSIFIED
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5615 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/2799e85f/attachment-0001.bin>

From aashish.chaudhary at kitware.com  Thu Mar 17 16:17:02 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 17 Mar 2016 16:17:02 -0400
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation
 and near far planes correction (UNCLASSIFIED)
In-Reply-To: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
Message-ID: <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>

Hi Joe,

Thank for you for the PR. Could you please describe the problem in bit more
detail?

Thanks,


On Thu, Mar 17, 2016 at 4:04 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL
(US) <joseph.g.hennessey2.ctr at mail.mil> wrote:

> CLASSIFICATION: UNCLASSIFIED
>
> Hello,
>
> I have modified
>
> Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum
>
> To fix a problem with eyeseparation and near and far planes for use with
> immersive paraview
>
> The merge request is called
>
> fix ComputeOffAxisProjectionFrustum eyeseparation and near and far planes.
>
>
> https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296
> d36afb
>
> Commit 4fe4fabb420bba77740ec988d060c5c296d36afb
>
> Authored by Joseph G. Hennessey about an hour ago
> 1 parent d52198e1
>
> Please add this to VTK and indirectly to ParaView
>
> Thanks,
>
> Joe
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Joseph G. Hennessey Ph.D., Lockheed Martin
> Army Research Lab
> DOD Supercomputing Resource Center
>
>
> CLASSIFICATION: UNCLASSIFIED
>
> _______________________________________________
> 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
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/d44e6c0e/attachment.html>

From DLRdave at aol.com  Thu Mar 17 16:44:06 2016
From: DLRdave at aol.com (David Cole)
Date: Thu, 17 Mar 2016 16:44:06 -0400
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation
 and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
Message-ID: <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>

OffAxis projection in VTK is woefully underdocumented, and accepting
this pull request will only add to the mystery.

I would suggest documenting that the coordinates used to specify it
are in vtkCamera coordinates (not world), and clarifying with comments
in the code what some of the constants used are for. Also,
EyeSeparation appears to be specified in meters, although it's unclear
how it relates to any of the VTK coordinate systems or to the size of
the actual display being used.


2 cents,
David C.


On Thu, Mar 17, 2016 at 4:17 PM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi Joe,
>
> Thank for you for the PR. Could you please describe the problem in bit more
> detail?
>
> Thanks,
>
>
> On Thu, Mar 17, 2016 at 4:04 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL
> (US) <joseph.g.hennessey2.ctr at mail.mil> wrote:
>>
>> CLASSIFICATION: UNCLASSIFIED
>>
>> Hello,
>>
>> I have modified
>>
>> Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum
>>
>> To fix a problem with eyeseparation and near and far planes for use with
>> immersive paraview
>>
>> The merge request is called
>>
>> fix ComputeOffAxisProjectionFrustum eyeseparation and near and far planes.
>>
>>
>> https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296
>> d36afb
>>
>> Commit 4fe4fabb420bba77740ec988d060c5c296d36afb
>>
>> Authored by Joseph G. Hennessey about an hour ago
>> 1 parent d52198e1
>>
>> Please add this to VTK and indirectly to ParaView
>>
>> Thanks,
>>
>> Joe
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Joseph G. Hennessey Ph.D., Lockheed Martin
>> Army Research Lab
>> DOD Supercomputing Resource Center
>>
>>
>> CLASSIFICATION: UNCLASSIFIED
>>
>> _______________________________________________
>> 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
>
>

From david.gobbi at gmail.com  Thu Mar 17 17:15:09 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 17 Mar 2016 15:15:09 -0600
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation
 and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
 <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
Message-ID: <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>

Considering that vtkCamera doesn't know the physical size of the screen,
I certainly hope that EyeSeparation is not in meters or any other absolute
units!  It should be in units relative to the screen size.  And, since only
the
application itself knows the physical screen size, it is up to the
application
to set it appropriately.   The eye separation is much smaller relative to a
huge wall screen, than to a workstation display.

Just agreeing with the other David here...

 - David

On Thu, Mar 17, 2016 at 2:44 PM, David Cole via vtk-developers <
vtk-developers at vtk.org> wrote:

> OffAxis projection in VTK is woefully underdocumented, and accepting
> this pull request will only add to the mystery.
>
> I would suggest documenting that the coordinates used to specify it
> are in vtkCamera coordinates (not world), and clarifying with comments
> in the code what some of the constants used are for. Also,
> EyeSeparation appears to be specified in meters, although it's unclear
> how it relates to any of the VTK coordinate systems or to the size of
> the actual display being used.
>
>
> 2 cents,
> David C.
>
>
> On Thu, Mar 17, 2016 at 4:17 PM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi Joe,
> >
> > Thank for you for the PR. Could you please describe the problem in bit
> more
> > detail?
> >
> > Thanks,
> >
> >
> > On Thu, Mar 17, 2016 at 4:04 PM, Hennessey, Joseph G CTR USARMY RDECOM
> ARL
> > (US) <joseph.g.hennessey2.ctr at mail.mil> wrote:
> >>
> >> CLASSIFICATION: UNCLASSIFIED
> >>
> >> Hello,
> >>
> >> I have modified
> >>
> >> Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum
> >>
> >> To fix a problem with eyeseparation and near and far planes for use with
> >> immersive paraview
> >>
> >> The merge request is called
> >>
> >> fix ComputeOffAxisProjectionFrustum eyeseparation and near and far
> planes.
> >>
> >>
> >>
> https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296
> >> d36afb
> >>
> >> Commit 4fe4fabb420bba77740ec988d060c5c296d36afb
> >>
> >> Authored by Joseph G. Hennessey about an hour ago
> >> 1 parent d52198e1
> >>
> >> Please add this to VTK and indirectly to ParaView
> >>
> >> Thanks,
> >>
> >> Joe
> >>
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> Joseph G. Hennessey Ph.D., Lockheed Martin
> >> Army Research Lab
> >> DOD Supercomputing Resource Center
> >>
> >>
> >> CLASSIFICATION: UNCLASSIFIED
> >>
> >> _______________________________________________
> >> 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
> >
> >
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/926a3ea2/attachment.html>

From DLRdave at aol.com  Thu Mar 17 19:07:13 2016
From: DLRdave at aol.com (David Cole)
Date: Thu, 17 Mar 2016 19:07:13 -0400
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation
 and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
 <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
 <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>
Message-ID: <CAKME8fFR8Tzc3oe2TSqe+Y+vm8rQEpoae0hd=u5m34NtG0XB9Q@mail.gmail.com>

A ha!

Thank you for the tidbit of information about EyeSeparation. So with a
value of 0.06, is it 6% of the x-axis (width) of the screen then?

I was coincidentally working with a physical system where coordinates
**are** specified in meters, and it, too used a default value of 0.06
for eye separation, so I ended up with a bad assumption in my head
because VTK's is not well documented, and since the numbers were the
same.....


Cheers,
David C.



On Thu, Mar 17, 2016 at 5:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Considering that vtkCamera doesn't know the physical size of the screen,
> I certainly hope that EyeSeparation is not in meters or any other absolute
> units!  It should be in units relative to the screen size.  And, since only
> the
> application itself knows the physical screen size, it is up to the
> application
> to set it appropriately.   The eye separation is much smaller relative to a
> huge wall screen, than to a workstation display.
>
> Just agreeing with the other David here...
>
>  - David
>
> On Thu, Mar 17, 2016 at 2:44 PM, David Cole via vtk-developers
> <vtk-developers at vtk.org> wrote:
>>
>> OffAxis projection in VTK is woefully underdocumented, and accepting
>> this pull request will only add to the mystery.
>>
>> I would suggest documenting that the coordinates used to specify it
>> are in vtkCamera coordinates (not world), and clarifying with comments
>> in the code what some of the constants used are for. Also,
>> EyeSeparation appears to be specified in meters, although it's unclear
>> how it relates to any of the VTK coordinate systems or to the size of
>> the actual display being used.
>>
>>
>> 2 cents,
>> David C.
>>
>>
>> On Thu, Mar 17, 2016 at 4:17 PM, Aashish Chaudhary
>> <aashish.chaudhary at kitware.com> wrote:
>> > Hi Joe,
>> >
>> > Thank for you for the PR. Could you please describe the problem in bit
>> > more
>> > detail?
>> >
>> > Thanks,
>> >
>> >
>> > On Thu, Mar 17, 2016 at 4:04 PM, Hennessey, Joseph G CTR USARMY RDECOM
>> > ARL
>> > (US) <joseph.g.hennessey2.ctr at mail.mil> wrote:
>> >>
>> >> CLASSIFICATION: UNCLASSIFIED
>> >>
>> >> Hello,
>> >>
>> >> I have modified
>> >>
>> >> Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum
>> >>
>> >> To fix a problem with eyeseparation and near and far planes for use
>> >> with
>> >> immersive paraview
>> >>
>> >> The merge request is called
>> >>
>> >> fix ComputeOffAxisProjectionFrustum eyeseparation and near and far
>> >> planes.
>> >>
>> >>
>> >>
>> >> https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296
>> >> d36afb
>> >>
>> >> Commit 4fe4fabb420bba77740ec988d060c5c296d36afb
>> >>
>> >> Authored by Joseph G. Hennessey about an hour ago
>> >> 1 parent d52198e1
>> >>
>> >> Please add this to VTK and indirectly to ParaView
>> >>
>> >> Thanks,
>> >>
>> >> Joe
>> >>
>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> Joseph G. Hennessey Ph.D., Lockheed Martin
>> >> Army Research Lab
>> >> DOD Supercomputing Resource Center
>> >>
>> >>
>> >> CLASSIFICATION: UNCLASSIFIED
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> >
>> _______________________________________________
>> 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 david.gobbi at gmail.com  Thu Mar 17 19:28:03 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 17 Mar 2016 17:28:03 -0600
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation
 and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CAKME8fFR8Tzc3oe2TSqe+Y+vm8rQEpoae0hd=u5m34NtG0XB9Q@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
 <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
 <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>
 <CAKME8fFR8Tzc3oe2TSqe+Y+vm8rQEpoae0hd=u5m34NtG0XB9Q@mail.gmail.com>
Message-ID: <CANwS1=HgydDfaVX3v5TVAM1d7MOysBVGtdL1rei4jtgmSK_ogQ@mail.gmail.com>

On Thu, Mar 17, 2016 at 5:07 PM, David Cole <DLRdave at aol.com> wrote:
>
>
> Thank you for the tidbit of information about EyeSeparation. So with a
> value of 0.06, is it 6% of the x-axis (width) of the screen then?
>

I don't know how it is implemented in VTK.  All I was saying is that it
cannot
be in real-world meters, because vtkCamera doesn't know the size of the
display and therefore cannot convert distances in the observer's world to
distances in the virtual-world.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/72b866bc/attachment.html>

From tluisrs at gmail.com  Thu Mar 17 19:35:54 2016
From: tluisrs at gmail.com (Thales Luis Rodrigues Sabino)
Date: Thu, 17 Mar 2016 20:35:54 -0300
Subject: [vtk-developers] How to use a vtkLODActor to draw a point cloud?
Message-ID: <CAHvrNadi_mBpSbG2wF7PZvC4qbX0hzWAY3ScUbA2QRUAucNB-Q@mail.gmail.com>

I'm trying to use a vtkLODActor to draw a point cloud that has too many
points.

In order to so, after loading the data into the vtkPolyData and creating a
vtkPolyDataMapper, I use the following piece of code

m_CloudMapper->ImmediateModeRenderingOff();

m_CloudActor->SetNumberOfCloudPoints(numberOfPoints / 10);

m_CloudActor->GetProperty()->SetInterpolationToFlat();


Even with a couple million points and settings the desired update rate with
the line

m_QVTKWidget->GetInteractor()->SetDesiredUpdateRate(30.0);


I can't get the effect that Paraview offers. Even when the camera moves,
the vtkLODActor is not acting by random selecting points to draw and keep
the desired rate.

Am I missing something?

-- 
Thales Luis Rodrigues Sabino

PhD Student at PGMC-UFJF <http://www.ufjf.br/pgmc/>
Lattes <http://lattes.cnpq.br/0601030410417146> | LinkedIn
<https://br.linkedin.com/in/tluisrs> | ResearchGate
<https://www.researchgate.net/profile/Thales_Luis_Sabino>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/c85e92cc/attachment.html>

From tluisrs at gmail.com  Thu Mar 17 19:36:36 2016
From: tluisrs at gmail.com (Thales Luis Rodrigues Sabino)
Date: Thu, 17 Mar 2016 20:36:36 -0300
Subject: [vtk-developers] Compiling VTK7 with VS2015 and Qt5.6
Message-ID: <CAHvrNaepMWpSRUAE9JszVPmpSmk=rWBvcRWjevAeG2hmSrNitA@mail.gmail.com>

Today I was able to successfully compile VTK7.0 with VS2015 and Qt5.6.
Since Qt5.6 has binaries available for VS2015 I decided to give it a try.

The first error that appears was the error that 'unistd.h' was not defined
(it is also a unix file). Looking at the source code for the file
'\IO\LSDyna\private\LSDynaFamily.h (45)' one can note that the macro WIN32
is not being defined. The reason is that in VS2015, as can been seen in
this page https://msdn.microsoft.com/en-us/library/b0084kay.aspx, the
correct macro to detect Windows is _WIN32. To fix this, I simply change my
cmake command line with the following

cmake -DCMAKE_CXX_FLAGS="/DWIN32=1 /EHsc"

The EHsc is to solve some warning about the exception handling system.

Hope this can help.

-- 
Thales Luis Rodrigues Sabino

PhD Student at PGMC-UFJF <http://www.ufjf.br/pgmc/>
Lattes <http://lattes.cnpq.br/0601030410417146> | LinkedIn
<https://br.linkedin.com/in/tluisrs> | ResearchGate
<https://www.researchgate.net/profile/Thales_Luis_Sabino>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/6c834979/attachment.html>

From tharun160190 at gmail.com  Thu Mar 17 20:59:45 2016
From: tharun160190 at gmail.com (Tharun)
Date: Thu, 17 Mar 2016 17:59:45 -0700 (MST)
Subject: [vtk-developers] Improper functioning of vtkStripper
In-Reply-To: <CANwS1=FSZmqiCqNCffdPmcLnnkenxONmYUXFH-hrt7cDakoWyg@mail.gmail.com>
References: <1458199342025-5737237.post@n5.nabble.com>
 <CANwS1=FSZmqiCqNCffdPmcLnnkenxONmYUXFH-hrt7cDakoWyg@mail.gmail.com>
Message-ID: <1458262785353-5737267.post@n5.nabble.com>

Thank you David. I am working with VTK 5.10 though.



--
View this message in context: http://vtk.1045678.n5.nabble.com/Improper-functioning-of-vtkStripper-tp5737237p5737267.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From aashish.chaudhary at kitware.com  Thu Mar 17 23:41:39 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 17 Mar 2016 23:41:39 -0400
Subject: [vtk-developers] merge request for vtkCamera.cxx eyeseparation
 and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CANwS1=HgydDfaVX3v5TVAM1d7MOysBVGtdL1rei4jtgmSK_ogQ@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
 <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
 <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>
 <CAKME8fFR8Tzc3oe2TSqe+Y+vm8rQEpoae0hd=u5m34NtG0XB9Q@mail.gmail.com>
 <CANwS1=HgydDfaVX3v5TVAM1d7MOysBVGtdL1rei4jtgmSK_ogQ@mail.gmail.com>
Message-ID: <CAEw35Z84EE-L2sQ9VURKgyy-7dXS5HQG5-JR9T84De19JR_NmQ@mail.gmail.com>

Hi David C.,

We wrote an source article some time back on it:
https://blog.kitware.com/paraview-in-immersive-environments. Also worth
looking at this another article:
https://blog.kitware.com/immersive-paraview-experiences-at-idaho-national-laboratory
for some of the motivation and concepts behind the work.

Since there is no concept of units in VTK, all of the numbers are dependent
on user picking a unit and if they all are in meters or centimeters or
anything else, it should work as expected. Typically a VR system has a
reference point using which distance are measured. Some systems report
inches but most of the modern ones report meters or centimeters. An
separation of 6 cm (or 0.06 m) is chosen for that reason but it is not
mandatory. As far as the documentation goes, there is really one method
which is important in vtkCamera and it has a reference for the paper in
there (please see below). We kept the same variable names so referring the
paper should be straightforward. If you have any particular suggestion on
how to improve the documentation please let us know (A patch is also
welcome).

- Thanks,


//----------------------------------------------------------------------------

void vtkCamera::ComputeOffAxisProjectionFrustum()

{

  this->ComputeWorldToScreenMatrix();


  // \NOTE: Varibles names reflect naming convention used in

  // "High Resolution Virtual Reality", in Proc.

  // SIGGRAPH '92, Computer Graphics, pages 195-202, 1992.


  // OffAxis calculations.




On Thu, Mar 17, 2016 at 7:28 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Thu, Mar 17, 2016 at 5:07 PM, David Cole <DLRdave at aol.com> wrote:
>>
>>
>> Thank you for the tidbit of information about EyeSeparation. So with a
>> value of 0.06, is it 6% of the x-axis (width) of the screen then?
>>
>
> I don't know how it is implemented in VTK.  All I was saying is that it
> cannot
> be in real-world meters, because vtkCamera doesn't know the size of the
> display and therefore cannot convert distances in the observer's world to
> distances in the virtual-world.
>
>  - David
>



-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
*| http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160317/04d17280/attachment-0001.html>

From andrew.amaclean at gmail.com  Fri Mar 18 00:29:36 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 18 Mar 2016 15:29:36 +1100
Subject: [vtk-developers] VTK and Twisted
Message-ID: <CAHDsG9MLGKXN31A6q8ezVLiPPxT074VHqMGek=yoDAYyBiHkJA@mail.gmail.com>

Hi All,
What is the status with ThirdParty/Twisted?
In particular has there been any progress on getting a Python 3 compatible
version of Twisted? I suspect that this is the only thing stopping the
build of VTK_Group_Web.

Regards
    Andrew

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160318/aee1e502/attachment.html>

From joseph.g.hennessey2.ctr at mail.mil  Fri Mar 18 08:42:43 2016
From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US))
Date: Fri, 18 Mar 2016 12:42:43 +0000
Subject: [vtk-developers] [Non-DoD Source] Re: merge request for
 vtkCamera.cxx eyeseparation and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
 <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
 <CANwS1=GtWCE-95sVdrQu9105sTtf+mMc0GDFqZg7VCvHbw1faA@mail.gmail.com>
Message-ID: <10A03274360DCF47A6EE78C9952A31CA41726A99@UMECHPA7C.easf.csd.disa.mil>

CLASSIFICATION: UNCLASSIFIED

The application would still set the eyeseparation with my changes. What I have 
done is correct a mismatch between what is shown on the server side screen 
with what is generated on the same size screen when visualized in the ParaView 
client RenderWindow. The correction I have added for eyeseparation scaling 
with distance to the object is a close approximation of what is already being 
displayed when the ParaView client RenderWindow displays stereo data. There 
were 2 may problems a mismatch of separation across all scales, which I have 
corrected as well as an additional  mismatch for very small data (of sizes 
less than 1) which I have also corrected. The eyeseparation  now produces 
similar results to what is generated for the ParaView client RenderWIndow. The 
near and far planes changes were necessary as they were hard coded constants 
and did not scale with the size of the data. This was particularly noticeable 
for data scaled at 0.001 or smaller, where the data would be clipped out of 
visibility on the server side display but would show up just fine in the 
ParaView client RenderWindow. By changing the near and far plane to be 
relative to the data, I am now more closely approximating what can be seen in 
the ParaView client RenderWindow and can visually data across a wide range of 
scales. I have tested this routing across scales from 1,000,000 X to 
1/1,000,000 X and at every intermediate scale of 10 and the data now clips in 
a way  that closely approximates the way it clips in the ParaView client 
RenderWindow.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joseph G. Hennessey Ph.D., Lockheed Martin Army Research Lab DOD 
Supercomputing Resource Center


-----Original Message-----
From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of 
David Gobbi
Sent: Thursday, March 17, 2016 5:15 PM
To: David Cole <DLRdave at aol.com>
Cc: paraview-developers at paraview.org; vtk-developers at vtk.org
Subject: [Non-DoD Source] Re: [vtk-developers] merge request for vtkCamera.cxx 
eyeseparation and near far planes correction (UNCLASSIFIED)

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.


________________________________



Considering that vtkCamera doesn't know the physical size of the screen, I 
certainly hope that EyeSeparation is not in meters or any other absolute 
units!  It should be in units relative to the screen size.  And, since only 
the application itself knows the physical screen size, it is up to the 
application
to set it appropriately.   The eye separation is much smaller relative to a
huge wall screen, than to a workstation display.

Just agreeing with the other David here...

 - David

On Thu, Mar 17, 2016 at 2:44 PM, David Cole via vtk-developers 
<vtk-developers at vtk.org < Caution-mailto:vtk-developers at vtk.org > > wrote:


	OffAxis projection in VTK is woefully underdocumented, and accepting
	this pull request will only add to the mystery.

	I would suggest documenting that the coordinates used to specify it
	are in vtkCamera coordinates (not world), and clarifying with comments
	in the code what some of the constants used are for. Also,
	EyeSeparation appears to be specified in meters, although it's unclear
	how it relates to any of the VTK coordinate systems or to the size of
	the actual display being used.


	2 cents,
	David C.



	On Thu, Mar 17, 2016 at 4:17 PM, Aashish Chaudhary
	<aashish.chaudhary at kitware.com < Caution-mailto:aashish.chaudhary at kitware.com 
 > > wrote:
	> Hi Joe,
	>
	> Thank for you for the PR. Could you please describe the problem in bit more
	> detail?
	>
	> Thanks,
	>
	>
	> On Thu, Mar 17, 2016 at 4:04 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL
	> (US) <joseph.g.hennessey2.ctr at mail.mil < 
Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > > wrote:
	>>
	>> CLASSIFICATION: UNCLASSIFIED
	>>
	>> Hello,
	>>
	>> I have modified
	>>
	>> Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum
	>>
	>> To fix a problem with eyeseparation and near and far planes for use with
	>> immersive paraview
	>>
	>> The merge request is called
	>>
	>> fix ComputeOffAxisProjectionFrustum eyeseparation and near and far planes.
	>>
	>>
	>> 
Caution-https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296 
< 
Caution-https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740ec988d060c5c296 
 >
	>> d36afb
	>>
	>> Commit 4fe4fabb420bba77740ec988d060c5c296d36afb
	>>
	>> Authored by Joseph G. Hennessey about an hour ago
	>> 1 parent d52198e1
	>>
	>> Please add this to VTK and indirectly to ParaView
	>>
	>> Thanks,
	>>
	>> Joe
	>>
	>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	>> Joseph G. Hennessey Ph.D., Lockheed Martin
	>> Army Research Lab
	>> DOD Supercomputing Resource Center
	>>
	>>
	>> CLASSIFICATION: UNCLASSIFIED
	>>
	>> _______________________________________________
	>> Powered by Caution-www.kitware.com < Caution-http://www.kitware.com >
	>>
	>> Visit other Kitware open-source projects at
	>> Caution-http://www.kitware.com/opensource/opensource.html < 
Caution-http://www.kitware.com/opensource/opensource.html >
	>>
	>> Search the list archives at: 
Caution-http://markmail.org/search/?q=vtk-developers < 
Caution-http://markmail.org/search/?q=vtk-developers >
	>>
	>> Follow this link to subscribe/unsubscribe:
	>> Caution-http://public.kitware.com/mailman/listinfo/vtk-developers < 
Caution-http://public.kitware.com/mailman/listinfo/vtk-developers >
	>>
	>>
	>
	>
	>
	> --
	> | Aashish Chaudhary
	> | Technical Leader
	> | Kitware Inc.
	> | Caution-http://www.kitware.com/company/team/chaudhary.html < 
Caution-http://www.kitware.com/company/team/chaudhary.html >
	>
	> _______________________________________________
	> Powered by Caution-www.kitware.com < Caution-http://www.kitware.com >
	>
	> Visit other Kitware open-source projects at
	> Caution-http://www.kitware.com/opensource/opensource.html < 
Caution-http://www.kitware.com/opensource/opensource.html >
	>
	> Search the list archives at: 
Caution-http://markmail.org/search/?q=vtk-developers < 
Caution-http://markmail.org/search/?q=vtk-developers >
	>
	> Follow this link to subscribe/unsubscribe:
	> Caution-http://public.kitware.com/mailman/listinfo/vtk-developers < 
Caution-http://public.kitware.com/mailman/listinfo/vtk-developers >
	>
	>
	_______________________________________________
	Powered by Caution-www.kitware.com < Caution-http://www.kitware.com >

	Visit other Kitware open-source projects at 
Caution-http://www.kitware.com/opensource/opensource.html < 
Caution-http://www.kitware.com/opensource/opensource.html >

	Search the list archives at: 
Caution-http://markmail.org/search/?q=vtk-developers < 
Caution-http://markmail.org/search/?q=vtk-developers >

	Follow this link to subscribe/unsubscribe:
	Caution-http://public.kitware.com/mailman/listinfo/vtk-developers < 
Caution-http://public.kitware.com/mailman/listinfo/vtk-developers >





CLASSIFICATION: UNCLASSIFIED
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5615 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160318/f1ce6e3c/attachment.bin>

From joseph.g.hennessey2.ctr at mail.mil  Fri Mar 18 08:47:11 2016
From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US))
Date: Fri, 18 Mar 2016 12:47:11 +0000
Subject: [vtk-developers] [Non-DoD Source] Re: merge request for
 vtkCamera.cxx eyeseparation and near far planes correction (UNCLASSIFIED)
In-Reply-To: <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
References: <10A03274360DCF47A6EE78C9952A31CA417254ED@UMECHPA7C.easf.csd.disa.mil>
 <CAEw35Z-VjiTXCcMV8mpCWVSYJo0e--Y8_FhbLr+U-1u2B1E-XQ@mail.gmail.com>
 <CAKME8fHQkCzXfeuGFLhkDoa+yjva2v=yzibv2Mp=onC49uUv4Q@mail.gmail.com>
Message-ID: <10A03274360DCF47A6EE78C9952A31CA41726AC3@UMECHPA7C.easf.csd.disa.mil>

CLASSIFICATION: UNCLASSIFIED

The modifications that I have made are designed to bring the server side
rendering in line with the client rendering in ParaView.
They correct an issue where the server side render used in immersive ParaView
Display does not match what is generated and
Displayed in the ParaView client RenderWindow. The OffAxis projection code is
used on the server side, but is not used to generate
Images for the client display. My goal with these changes is to bring them
closer, but it does not bring them to pixel by pixel perfection,
which is perhaps not even possible given that there are using different
routines to calculate what to display. I do not know why
constants were originally chosen for the near and far planes, for example, but
I do know that they do not work well on different scaled
data clipping the data out of visibility. My changes allow data across a large
range of scales to be visualized and closely approximate
what would be displayed in the ParaView client RenderWindow.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joseph G. Hennessey Ph.D., Lockheed Martin
Army Research Lab
DOD Supercomputing Resource Center

-----Original Message-----
From: David Cole [mailto:DLRdave at aol.com]
Sent: Thursday, March 17, 2016 4:44 PM
To: Aashish Chaudhary <aashish.chaudhary at kitware.com>
Cc: Hennessey, Joseph G CTR USARMY RDECOM ARL (US)
<joseph.g.hennessey2.ctr at mail.mil>; paraview-developers at paraview.org;
vtk-developers at vtk.org
Subject: [Non-DoD Source] Re: [vtk-developers] merge request for vtkCamera.cxx
eyeseparation and near far planes correction (UNCLASSIFIED)

All active links contained in this email were disabled.  Please verify the
identity of the sender, and confirm the authenticity of all links contained
within the message prior to copying and pasting the address to a Web browser.




----

OffAxis projection in VTK is woefully underdocumented, and accepting this pull
request will only add to the mystery.

I would suggest documenting that the coordinates used to specify it are in
vtkCamera coordinates (not world), and clarifying with comments in the code
what some of the constants used are for. Also, EyeSeparation appears to be
specified in meters, although it's unclear how it relates to any of the VTK
coordinate systems or to the size of the actual display being used.


2 cents,
David C.


On Thu, Mar 17, 2016 at 4:17 PM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi Joe,
>
> Thank for you for the PR. Could you please describe the problem in bit
> more detail?
>
> Thanks,
>
>
> On Thu, Mar 17, 2016 at 4:04 PM, Hennessey, Joseph G CTR USARMY RDECOM
> ARL
> (US) <joseph.g.hennessey2.ctr at mail.mil> wrote:
>>
>> CLASSIFICATION: UNCLASSIFIED
>>
>> Hello,
>>
>> I have modified
>>
>> Rendering/Core/vtkCamera.cxx:: ComputeOffAxisProjectionFrustum
>>
>> To fix a problem with eyeseparation and near and far planes for use
>> with immersive paraview
>>
>> The merge request is called
>>
>> fix ComputeOffAxisProjectionFrustum eyeseparation and near and far planes.
>>
>>
>> Caution-https://gitlab.kitware.com/vtk/vtk/commit/4fe4fabb420bba77740
>> ec988d060c5c296
>> d36afb
>>
>> Commit 4fe4fabb420bba77740ec988d060c5c296d36afb
>>
>> Authored by Joseph G. Hennessey about an hour ago
>> 1 parent d52198e1
>>
>> Please add this to VTK and indirectly to ParaView
>>
>> Thanks,
>>
>> Joe
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Joseph G. Hennessey Ph.D., Lockheed Martin Army Research Lab DOD
>> Supercomputing Resource Center
>>
>>
>> CLASSIFICATION: UNCLASSIFIED
>>
>> _______________________________________________
>> Powered by Caution-www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> Caution-http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at:
>> Caution-http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> Caution-http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
>
>
> --
> | Aashish Chaudhary
> | Technical Leader
> | Kitware Inc.
> | Caution-http://www.kitware.com/company/team/chaudhary.html
>
> _______________________________________________
> Powered by Caution-www.kitware.com
>
> Visit other Kitware open-source projects at
> Caution-http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at:
> Caution-http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> Caution-http://public.kitware.com/mailman/listinfo/vtk-developers
>
>


CLASSIFICATION: UNCLASSIFIED
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5615 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160318/ea691f63/attachment-0001.bin>

From sebastien.jourdain at kitware.com  Fri Mar 18 09:25:30 2016
From: sebastien.jourdain at kitware.com (Sebastien Jourdain)
Date: Fri, 18 Mar 2016 07:25:30 -0600
Subject: [vtk-developers] VTK and Twisted
In-Reply-To: <CAHDsG9MLGKXN31A6q8ezVLiPPxT074VHqMGek=yoDAYyBiHkJA@mail.gmail.com>
References: <CAHDsG9MLGKXN31A6q8ezVLiPPxT074VHqMGek=yoDAYyBiHkJA@mail.gmail.com>
Message-ID: <F0B025F9-F500-44EF-8D78-D2A0E022AF9D@kitware.com>

Hi Andrew,

If Python 3 is used then Twisted should not be used. Other solution should be taken for the Web support. I never got a chance to look into that yet. 

Seb

> On Mar 17, 2016, at 22:29, Andrew Maclean <andrew.amaclean at gmail.com> wrote:
> 
> Hi All,
> What is the status with ThirdParty/Twisted?   
> In particular has there been any progress on getting a Python 3 compatible version of Twisted? I suspect that this is the only thing stopping the build of VTK_Group_Web.
> 
> Regards
>     Andrew
> 
> -- 
> ___________________________________________
> Andrew J. P. Maclean
> 
> ___________________________________________
> _______________________________________________
> 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 ken.martin at kitware.com  Fri Mar 18 10:03:20 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 18 Mar 2016 10:03:20 -0400
Subject: [vtk-developers] megas
Message-ID: <CANXz0SZ5m61BFNhAT+2+Deg_yaQn1GPyWKb+e5yQAef9rYG1ng@mail.gmail.com>

Can someone update the megas buildbot to ignore the new volumerendering
test? I believe it is still failing.

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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160318/f76c75bf/attachment.html>

From ken.martin at kitware.com  Fri Mar 18 14:22:56 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 18 Mar 2016 14:22:56 -0400
Subject: [vtk-developers] What is up with Agora?
In-Reply-To: <CAB5Fpx4uq3KnLoUT=HC2pH4p2dqDZEyO+H9Hiz4TaYtys+E+Tg@mail.gmail.com>
References: <CANXz0SbHPew9LZW8m0anPoEgxNc6mQt1sdSw2BbwhmNu84TQBA@mail.gmail.com>
 <CAB5Fpx4uq3KnLoUT=HC2pH4p2dqDZEyO+H9Hiz4TaYtys+E+Tg@mail.gmail.com>
Message-ID: <CANXz0Sb-kVCrNkqQRry0HOcRFU-8O8tE-+Vb3Qp=xzC1bOctJA@mail.gmail.com>

OK I added a

/usr/bin/tmpwatch -am 12 /tmp

to the crontab, maybe that will help some.

Ken


On Thu, Mar 17, 2016 at 11:12 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Dzenan reports that Agora's /tmp disk is full, which is likely causing
> problems.
>
> Cory
>
> On Thu, Mar 17, 2016 at 10:12 AM, Ken Martin <ken.martin at kitware.com>
> wrote:
> > It seems to be off and on having issues. Anyone know what is up?
> >
> >
> >
> > --
> > 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
> >
> >
>
>
>
> --
> Cory Quammen
> R&D Engineer
> Kitware, Inc.
>



-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160318/474c93f9/attachment.html>

From aashish.chaudhary at kitware.com  Mon Mar 21 15:24:39 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Mon, 21 Mar 2016 15:24:39 -0400
Subject: [vtk-developers] ProjectedTetrahedraMapper test failing on few
	machines
Message-ID: <CAEw35Z-ijFx4U5Y01Cwm7pG4h1y7XeENhpx0XfYcR9+sqAJyQQ@mail.gmail.com>

FYI: Seems to be system specific but not sure 100%. I am looking into it.

Thanks,


-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
*| http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160321/1245f63e/attachment.html>

From mantis at public.kitware.com  Mon Mar 21 17:16:30 2016
From: mantis at public.kitware.com (Mantis Bug Tracker)
Date: Mon, 21 Mar 2016 15:16:30 -0600
Subject: [vtk-developers] [VTK 0016034]: OS X conversion of track pad scroll
	to MouseWheel events
In-Reply-To: <ab929b3747dcfa699e41c18a56fd22d8@www.vtk.org>
Message-ID: <2113b4d710011dff71057aca96e894f8@www.vtk.org>


The following issue has been DELETED. 
====================================================================== 
Reported By:                David Gobbi
Assigned To:                David Gobbi
====================================================================== 
Project:                    VTK
Issue ID:                   16034
Category:                   (No Category)
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     backlog
Project:                    TBD 
Type:                       incorrect functionality 
====================================================================== 
Date Submitted:             2016-03-21 08:12 MDT
Last Modified:              2016-03-21 08:16 MDT
====================================================================== 
Summary:                    OS X conversion of track pad scroll to MouseWheel
events
Description: 
The vtkCocoaNSView class does not correctly handle scroll wheel events.

Currently, the code simply emits one VTK MouseWheelEvent for each scrollWheel
event, without regard for the actual size of the deltaY for the scrollEvent. 
The result is very jerky interaction.

To fix the interaction, the deltaY should be accumulated until it reaches a
value of 120 (which corresponds to one "click" of an old-style mouse wheel), at
which point a VTK MouseWheelEvent should be invoked.

Since OS X 10.7, an additional property called scrollingDeltaY is available.  I
don't know if this offers advantages over simply using deltaY, but it should be
investigated.  My feeling is that deltaY is the best property to use.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2016-03-21 08:12 David Gobbi    New Issue                                    
2016-03-21 08:12 David Gobbi    Assigned To               => David Gobbi     
2016-03-21 08:16 David Gobbi    Description Updated                          
2016-03-21 15:16 David Gobbi    Issue Deleted: 0016034                       
======================================================================


From behollis at sci.utah.edu  Wed Mar 23 19:08:58 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Wed, 23 Mar 2016 17:08:58 -0600
Subject: [vtk-developers] transparent foreground polygons occluding
	background geometry
Message-ID: <web-12415216@sci.utah.edu>

Hi,

We have a problem with transparent foreground polys occluding 
geometry.

We're trying to use depth peeling to handle foreground polygons with 
transparency. However, while depth peeling is enabled, 
GetLastRenderingUsedDepthPeeling() returns false.

(The polygons also intersect other similar polygons so that some parts 
of them are in front of others, while other parts of the same poly may 
be behind others. Another reason to use depth peeling as opposed to 
depth sorting, in our opinion.)

We also require custom shaders, using 
vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code @ 
http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx, 
it looks as though custom shaders can't be used with depth peeling in 
VTK.

Thus, is there another way to enable depth peeling or to have 
transparent foreground polys in our usage scenario?

Regards,
Brad

From bill.lorensen at gmail.com  Wed Mar 23 22:55:56 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 23 Mar 2016 19:55:56 -0700
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
Message-ID: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>

Recently the API for vtkAOSDataArrayTemplate was changed.

Set/Get/Insert/InsertNextTupleValue was changed to
Set/Get/Insert/InsertNextTypedTuple.

What was the purpose of the name change?

There are 13 c++ wiki examples that use the old API. I will need to
#if the changed code so that it will still compile with older vtk
versions. I do not turn on legacy options for the examples.

Seems like an arbitrary change to me.

Bill

From david.gobbi at gmail.com  Wed Mar 23 23:51:17 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 23 Mar 2016 21:51:17 -0600
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
Message-ID: <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>

On Wed, Mar 23, 2016 at 8:55 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Recently the API for vtkAOSDataArrayTemplate was changed.
>
> Set/Get/Insert/InsertNextTupleValue was changed to
> Set/Get/Insert/InsertNextTypedTuple.
>
> What was the purpose of the name change?
>
> There are 13 c++ wiki examples that use the old API. I will need to
> #if the changed code so that it will still compile with older vtk
> versions. I do not turn on legacy options for the examples.
>
> Seems like an arbitrary change to me.
>

I was bitten by this as well.  But I can understand the rationale
behind the change.  The old name made little sense.

Actually, I recommend going even further: add new methods
called GetTypedValue() et al. and deprecate GetValue() et al.
Then, for VTK 8, I would love to see these method appear:

  double vtkDataArray::GetValue()
  vtkIdType vtkAbstractArray::GetNumberOfValues()

I would really like GetNumberOfValues() to make a comeback.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160323/8a6ef0c7/attachment.html>

From david.gobbi at gmail.com  Thu Mar 24 00:09:55 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 23 Mar 2016 22:09:55 -0600
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
Message-ID: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>

Also related to data arrays: I'd love to see the deprecation of
InsertValue() and InsertTuple().  The problems with them are:

1) They are redundant.  As far as I'm concerned, their usage can
always be replaced with SetTuple() or InsertNextTuple() and the
resulting code will become easier to read.

2) They don't actually "insert" tuples except at the end of the
array, and we have InsertNextTuple() or that purpose.  Anywhere
else in the array, they perform a replacement operation.

Any thoughts?  Are these methods widely used anywhere except
for VTK's own source tree?

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160323/16ba3faf/attachment.html>

From bill.lorensen at gmail.com  Thu Mar 24 00:48:46 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 23 Mar 2016 21:48:46 -0700
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
 <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
Message-ID: <CADZJ4hPvA5xEjHWcXUEVKVxwzjCLkhAV7Kc=gkxkHMTdsdA88A@mail.gmail.com>

The new names don't make much sense to me.
On Mar 23, 2016 8:51 PM, "David Gobbi" <david.gobbi at gmail.com> wrote:

> On Wed, Mar 23, 2016 at 8:55 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> Recently the API for vtkAOSDataArrayTemplate was changed.
>>
>> Set/Get/Insert/InsertNextTupleValue was changed to
>> Set/Get/Insert/InsertNextTypedTuple.
>>
>> What was the purpose of the name change?
>>
>> There are 13 c++ wiki examples that use the old API. I will need to
>> #if the changed code so that it will still compile with older vtk
>> versions. I do not turn on legacy options for the examples.
>>
>> Seems like an arbitrary change to me.
>>
>
> I was bitten by this as well.  But I can understand the rationale
> behind the change.  The old name made little sense.
>
> Actually, I recommend going even further: add new methods
> called GetTypedValue() et al. and deprecate GetValue() et al.
> Then, for VTK 8, I would love to see these method appear:
>
>   double vtkDataArray::GetValue()
>   vtkIdType vtkAbstractArray::GetNumberOfValues()
>
> I would really like GetNumberOfValues() to make a comeback.
>
>  - David
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160323/28466446/attachment.html>

From ken.martin at kitware.com  Thu Mar 24 08:26:30 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Thu, 24 Mar 2016 08:26:30 -0400
Subject: [vtk-developers] transparent foreground polygons occluding
 background geometry
In-Reply-To: <web-12415216@sci.utah.edu>
References: <web-12415216@sci.utah.edu>
Message-ID: <CANXz0Sb_qKZkgny0eymo6xZJuw-w653VtP0nr843NR7MAQ8V9A@mail.gmail.com>

Your custom shader has to be written to work with depth peeling. When in a
depth peeling pass it needs to do some texture lookups and discard
fragments based on those lookups. I've included the general gist below. I
use string replacements to handle it but you are free to use other
approaches as long as the end result in a depth peeling pass has something
like the following in it.

Thanks
Ken

  // are we using depth peeling?
  vtkInformation *info = actor->GetPropertyKeys();
  if (info && info->Has(vtkDepthPeelingPass::OpaqueZTextureUnit()))
    {
    vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Dec",
      "uniform vec2 screenSize;\n"
      "uniform sampler2D opaqueZTexture;\n"
      "uniform sampler2D translucentZTexture;\n");
    // the .0000001 below is an epsilon.  It turns out that
    // graphics cards can render the same polygon two times
    // in a row with different z values. I suspect it has to
    // do with how rasterization of the polygon is broken up.
    // A different breakup across fragment shaders can result in
    // very slightly different z values for some of the pixels.
    // The end result is that with depth peeling, you can end up
    // counting/accumulating pixels of the same surface twice
    // simply due to this randomness in z values. So we introduce
    // an epsilon into the transparent test to require some
    // minimal z separation between pixels
    vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Impl",
      "float odepth = texture2D(opaqueZTexture,
gl_FragCoord.xy/screenSize).r;\n"
      "  if (gl_FragCoord.z >= odepth) { discard; }\n"
      "  float tdepth = texture2D(translucentZTexture,
gl_FragCoord.xy/screenSize).r;\n"
      "  if (gl_FragCoord.z <= tdepth + .0000001) { discard; }\n"




On Wed, Mar 23, 2016 at 7:08 PM, Brad Hollister <behollis at sci.utah.edu>
wrote:

> Hi,
>
> We have a problem with transparent foreground polys occluding geometry.
>
> We're trying to use depth peeling to handle foreground polygons with
> transparency. However, while depth peeling is enabled,
> GetLastRenderingUsedDepthPeeling() returns false.
>
> (The polygons also intersect other similar polygons so that some parts of
> them are in front of others, while other parts of the same poly may be
> behind others. Another reason to use depth peeling as opposed to depth
> sorting, in our opinion.)
>
> We also require custom shaders, using
> vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code @
> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx,
> it looks as though custom shaders can't be used with depth peeling in VTK.
>
> Thus, is there another way to enable depth peeling or to have transparent
> foreground polys in our usage scenario?
>
> Regards,
> Brad
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/1eecbf6a/attachment-0001.html>

From aashish.chaudhary at kitware.com  Thu Mar 24 10:01:14 2016
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 24 Mar 2016 10:01:14 -0400
Subject: [vtk-developers] ProjectedTetrahedraMapper test failing on few
	machines
In-Reply-To: <CAEw35Z-ijFx4U5Y01Cwm7pG4h1y7XeENhpx0XfYcR9+sqAJyQQ@mail.gmail.com>
References: <CAEw35Z-ijFx4U5Y01Cwm7pG4h1y7XeENhpx0XfYcR9+sqAJyQQ@mail.gmail.com>
Message-ID: <CAEw35Z-OWx+sozdgaxy23nMHS4iH_TJeKRjT8AyG3=CeGBonVQ@mail.gmail.com>

Folks, I pushed the fix 2 days ago and the dashboards were green last
night. I will keep an eye on the dashboards in case something else shows
up.

Thanks,
Aashish

On Mon, Mar 21, 2016 at 3:24 PM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> FYI: Seems to be system specific but not sure 100%. I am looking into it.
>
> Thanks,
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
*| http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/e29776c5/attachment.html>

From sean at rogue-research.com  Thu Mar 24 10:03:02 2016
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 24 Mar 2016 10:03:02 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
Message-ID: <20160324140302.821065445@mail.rogue-research.com>

On Wed, 23 Mar 2016 22:09:55 -0600, David Gobbi said:

>Also related to data arrays: I'd love to see the deprecation of
>InsertValue() and InsertTuple().  The problems with them are:
>
>1) They are redundant.  As far as I'm concerned, their usage can
>always be replaced with SetTuple() or InsertNextTuple() and the
>resulting code will become easier to read.
>
>2) They don't actually "insert" tuples except at the end of the
>array, and we have InsertNextTuple() or that purpose.  Anywhere
>else in the array, they perform a replacement operation.
>
>Any thoughts?  Are these methods widely used anywhere except
>for VTK's own source tree?

No opinion per se, but as to your last question: it's impossible for us to know, and polling this list is too small a sample size.  I just grepped our codebase and found 2 uses of InsertValue().

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  Thu Mar 24 10:11:40 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 24 Mar 2016 08:11:40 -0600
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <20160324140302.821065445@mail.rogue-research.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
Message-ID: <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>

On Thu, Mar 24, 2016 at 8:03 AM, Sean McBride <sean at rogue-research.com>
wrote:

> On Wed, 23 Mar 2016 22:09:55 -0600, David Gobbi said:
>
> >Also related to data arrays: I'd love to see the deprecation of
> >InsertValue() and InsertTuple().  The problems with them are:
> >
> >1) They are redundant.  As far as I'm concerned, their usage can
> >always be replaced with SetTuple() or InsertNextTuple() and the
> >resulting code will become easier to read.
> >
> >2) They don't actually "insert" tuples except at the end of the
> >array, and we have InsertNextTuple() or that purpose.  Anywhere
> >else in the array, they perform a replacement operation.
> >
> >Any thoughts?  Are these methods widely used anywhere except
> >for VTK's own source tree?
>
> No opinion per se, but as to your last question: it's impossible for us to
> know, and polling this list is too small a sample size.  I just grepped our
> codebase and found 2 uses of InsertValue().
>

Yes, I prefer to get the opinions of other developers before opening it up
to everyone :)

But since you took the time to answer: for those two uses you found, was
the usage of InsertValue() easy to understand, and was it a good match for
the intent of the code?

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/6e9ae116/attachment.html>

From david.lonie at kitware.com  Thu Mar 24 11:20:25 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 24 Mar 2016 11:20:25 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
Message-ID: <CA+=e1ou4jcNPNE3_aGg9vYoGWdOYjZ-7XpWXyRMVk5hUiKeHYg@mail.gmail.com>

On Thu, Mar 24, 2016 at 12:09 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Also related to data arrays: I'd love to see the deprecation of
> InsertValue() and InsertTuple().  The problems with them are:
>
> 1) They are redundant.  As far as I'm concerned, their usage can
> always be replaced with SetTuple() or InsertNextTuple() and the
> resulting code will become easier to read.
>
> 2) They don't actually "insert" tuples except at the end of the
> array, and we have InsertNextTuple() or that purpose.  Anywhere
> else in the array, they perform a replacement operation.
>
> Any thoughts?  Are these methods widely used anywhere except
> for VTK's own source tree?
>

I have to agree. Point (2) is the dealbreaker for me -- I know I've gotten
bitten by that, and I know others have been as well. The accepted meaning
of 'insert' simply does not match what these methods actually do.

Ideally, I'd rather keep them and make them function as expected -- insert
the tuple and push the tail of the array down by numComps. However, this
would likely lead to nasty, nasty bugs with legacy code.

TBH, there's a lot of the array API that I'd love to revamp -- get rid of
GetVoidPointer and WritePointer, update Insert*,
GetSize/GetMaxId/GetCapacity, etc. to match modern conventions, etc -- but
there's a lot of legacy code around these array classes at this point so
it's tough to fix the problems.

That said, if the community can get behind such changes, I feel that they
would be worth the pain. I'll go a step further and say that I'm willing to
implement the changes (in VTK/ParaView) if there's enough support/funding
around.

My $0.02,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/3364bcfa/attachment.html>

From sean at rogue-research.com  Thu Mar 24 11:53:19 2016
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 24 Mar 2016 11:53:19 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
Message-ID: <20160324155319.1050506101@mail.rogue-research.com>

On Thu, 24 Mar 2016 08:11:40 -0600, David Gobbi said:

>On Thu, Mar 24, 2016 at 8:03 AM, Sean McBride <sean at rogue-research.com>
>wrote:
>
>> On Wed, 23 Mar 2016 22:09:55 -0600, David Gobbi said:
>>
>> >Also related to data arrays: I'd love to see the deprecation of
>> >InsertValue() and InsertTuple().  The problems with them are:
>> >
>> >1) They are redundant.  As far as I'm concerned, their usage can
>> >always be replaced with SetTuple() or InsertNextTuple() and the
>> >resulting code will become easier to read.
>> >
>> >2) They don't actually "insert" tuples except at the end of the
>> >array, and we have InsertNextTuple() or that purpose.  Anywhere
>> >else in the array, they perform a replacement operation.
>> >
>> >Any thoughts?  Are these methods widely used anywhere except
>> >for VTK's own source tree?
>>
>> No opinion per se, but as to your last question: it's impossible for us to
>> know, and polling this list is too small a sample size.  I just grepped our
>> codebase and found 2 uses of InsertValue().
>>
>
>Yes, I prefer to get the opinions of other developers before opening it up
>to everyone :)
>
>But since you took the time to answer: for those two uses you found, was
>the usage of InsertValue() easy to understand, and was it a good match for
>the intent of the code?

In my 2 cases, it's always appending to the end of the data array.  I guess I could use InsertNextValue() instead, if I understand it correctly.

I think your point #2 is quite valid.  Since it's not *inserting*, but rather *replacing*, then the API name is very confusing.  A deprecate and rename is in order IMHO.

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.lonie at kitware.com  Thu Mar 24 12:00:28 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 24 Mar 2016 12:00:28 -0400
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
 <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
Message-ID: <CA+=e1ouMX_9hm2jE9uikEneH2=NdwZGvMeUpmJeh50xtrhcu0Q@mail.gmail.com>

>
> On Wed, Mar 23, 2016 at 8:55 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> Recently the API for vtkAOSDataArrayTemplate was changed.
>>
>> Set/Get/Insert/InsertNextTupleValue was changed to
>> Set/Get/Insert/InsertNextTypedTuple.
>>
>> What was the purpose of the name change?
>>
>
I believe it was Berk who first proposed this when I was making the data
array changes, so I'll let him correct me if I'm wrong. But as I understand
it this was simply to clarify the difference between the typed and untyped
getters/setters.

Personally, I'm ambivalent about the change. It's a definite improvement to
the API, but any and all API changes are annoying for backwards
compatibility, so it's a win/lose situation.

On Wed, Mar 23, 2016 at 11:51 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Actually, I recommend going even further: add new methods
> called GetTypedValue() et al. and deprecate GetValue() et al.
> Then, for VTK 8, I would love to see these method appear:
>
>   double vtkDataArray::GetValue()
>

GetValue is not defined at the vtkDataArray level, and nor should it be
(IMO).

My reasoning: vtkDataArray no longer assumes AOS ordering. The decision was
that, ideally, vtkDataArray API would operate on tuples and components,
while subclasses (e.g. AOS or SOA) would provide these more
implementation-dependent lookups. In the context of SOA ordering, the value
indices don't make a whole lot of sense and are inefficient to use, while
GetComponentValue is efficient in either case.


>   vtkIdType vtkAbstractArray::GetNumberOfValues()
>
I would really like GetNumberOfValues() to make a comeback.
>

I agree -- so much so that I already added it! ;) It's not gone, it's just
moved out of the implementation class to vtkAbstractArray.

On Thu, Mar 24, 2016 at 12:48 AM, Bill Lorensen <bill.lorensen at gmail.com>
 wrote:

> The new names don't make much sense to me.
>
Can you elaborate? Compare:

GetTuple vs. GetTupleValue
to
GetTuple vs. GetTypedTuple

The meaning of the typed method seems much clearer now IMO. Do you feel the
old method names more clearly communicate the reason for the method's
existence to someone new to VTK?

Cheers,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/a253f82d/attachment.html>

From simon.esneault at gmail.com  Thu Mar 24 12:04:44 2016
From: simon.esneault at gmail.com (Simon ESNEAULT)
Date: Thu, 24 Mar 2016 17:04:44 +0100
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <20160324155319.1050506101@mail.rogue-research.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
Message-ID: <CAC9gB0AquhkroBVWZ_FGNm4D6BB3qffMNo4Cx+LmOH1_KTWzYQ@mail.gmail.com>

Hello,

As a user, I believe that kind of change makes perfect sense, these
functions are just confusing.
Simon

2016-03-24 16:53 GMT+01:00 Sean McBride <sean at rogue-research.com>:

> On Thu, 24 Mar 2016 08:11:40 -0600, David Gobbi said:
>
> >On Thu, Mar 24, 2016 at 8:03 AM, Sean McBride <sean at rogue-research.com>
> >wrote:
> >
> >> On Wed, 23 Mar 2016 22:09:55 -0600, David Gobbi said:
> >>
> >> >Also related to data arrays: I'd love to see the deprecation of
> >> >InsertValue() and InsertTuple().  The problems with them are:
> >> >
> >> >1) They are redundant.  As far as I'm concerned, their usage can
> >> >always be replaced with SetTuple() or InsertNextTuple() and the
> >> >resulting code will become easier to read.
> >> >
> >> >2) They don't actually "insert" tuples except at the end of the
> >> >array, and we have InsertNextTuple() or that purpose.  Anywhere
> >> >else in the array, they perform a replacement operation.
> >> >
> >> >Any thoughts?  Are these methods widely used anywhere except
> >> >for VTK's own source tree?
> >>
> >> No opinion per se, but as to your last question: it's impossible for us
> to
> >> know, and polling this list is too small a sample size.  I just grepped
> our
> >> codebase and found 2 uses of InsertValue().
> >>
> >
> >Yes, I prefer to get the opinions of other developers before opening it up
> >to everyone :)
> >
> >But since you took the time to answer: for those two uses you found, was
> >the usage of InsertValue() easy to understand, and was it a good match for
> >the intent of the code?
>
> In my 2 cases, it's always appending to the end of the data array.  I
> guess I could use InsertNextValue() instead, if I understand it correctly.
>
> I think your point #2 is quite valid.  Since it's not *inserting*, but
> rather *replacing*, then the API name is very confusing.  A deprecate and
> rename is in order IMHO.
>
> 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
>
>


-- 
------------------------------------------------------------------
Simon Esneault
Rennes, France
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/4e3a6dba/attachment.html>

From david.lonie at kitware.com  Thu Mar 24 12:11:31 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 24 Mar 2016 12:11:31 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <20160324155319.1050506101@mail.rogue-research.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
Message-ID: <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>

On Thu, Mar 24, 2016 at 11:53 AM, Sean McBride <sean at rogue-research.com>
wrote:

> In my 2 cases, it's always appending to the end of the data array.  I
> guess I could use InsertNextValue() instead, if I understand it correctly.
>

You're correct, InsertNextValue would work just fine (and should probably
be called "Append" or "PushBack" to keep up with modern conventions).


> I think your point #2 is quite valid.  Since it's not *inserting*, but
> rather *replacing*, then the API name is very confusing.  A deprecate and
> rename is in order IMHO.
>

I 100% agree. Trouble is, as Bill's thread shows, there's always push back
from some developers for these sorts of changes. Whether it improves the
API or not, it creates work for legacy maintainers, and they often feel
that the extra work is unneeded. Trying to address issues like the
vtkDataArray API inconsistencies feels like an impossible balancing act --
there's no solution that satisfies everyone :-(

On Thu, Mar 24, 2016 at 12:04 PM, Simon ESNEAULT <simon.esneault at gmail.com>
 wrote:

> As a user, I believe that kind of change makes perfect sense, these
> functions are just confusing.
>

Thanks for the feedback! I'm genuinely interested in how the majority of
the developer community feels about these sorts of topics. Anyone else want
to share an opinion?

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/af3fd332/attachment.html>

From david.gobbi at gmail.com  Thu Mar 24 12:13:20 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 24 Mar 2016 10:13:20 -0600
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CA+=e1ouMX_9hm2jE9uikEneH2=NdwZGvMeUpmJeh50xtrhcu0Q@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
 <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
 <CA+=e1ouMX_9hm2jE9uikEneH2=NdwZGvMeUpmJeh50xtrhcu0Q@mail.gmail.com>
Message-ID: <CANwS1=GykbfAVeWxoyfDFkKZSjgACeUd6uD4L9gF0vTO9zwg0w@mail.gmail.com>

On Thu, Mar 24, 2016 at 10:00 AM, David Lonie <david.lonie at kitware.com>
wrote:
>
> GetValue is not defined at the vtkDataArray level, and nor should it be
> (IMO).
>
> My reasoning: vtkDataArray no longer assumes AOS ordering. The decision
> was that, ideally, vtkDataArray API would operate on tuples and components,
> while subclasses (e.g. AOS or SOA) would provide these more
> implementation-dependent lookups. In the context of SOA ordering, the value
> indices don't make a whole lot of sense and are inefficient to use, while
> GetComponentValue is efficient in either case.
>

That makes sense, thanks for the explanation.  It's obvious to me now that
you cannot provide a "flat" view of the data until the ordering is known.


I would really like GetNumberOfValues() to make a comeback.
>>
>
> I agree -- so much so that I already added it! ;) It's not gone, it's just
> moved out of the implementation class to vtkAbstractArray.
>

Nice!

 - David

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/23a11281/attachment-0001.html>

From david.lonie at kitware.com  Thu Mar 24 12:19:31 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 24 Mar 2016 12:19:31 -0400
Subject: [vtk-developers] transparent foreground polygons occluding
 background geometry
In-Reply-To: <CANXz0Sb_qKZkgny0eymo6xZJuw-w653VtP0nr843NR7MAQ8V9A@mail.gmail.com>
References: <web-12415216@sci.utah.edu>
 <CANXz0Sb_qKZkgny0eymo6xZJuw-w653VtP0nr843NR7MAQ8V9A@mail.gmail.com>
Message-ID: <CA+=e1osftqcL7XDRpDbsX9UdE_m5qGfu-wxVtMbGf+uK86vxLQ@mail.gmail.com>

Just want to point out that I'm currently rewriting the depth peeling
algorithm to use dual depth peeling. At the moment, my unoptimized
implementation is getting roughly 25% better performance over the standard
depth peeling, though the shader code is a bit more complex and requires
implementing three passes (Initialize dual depth buffer -> multiple peeling
renders -> alpha blend remaining fragments).

This isn't in master yet, but the current polydata shader code is here:
https://gitlab.kitware.com/dlonie/vtk/blob/dual_depth_peels/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx#L990

Current branch is in testing here:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1357

I'm currently planning to make the DDP algorithm optional and leave the
existing depth peeling implementation around while it stabilizes, so
ideally there would be no immediate need to update your shader code when it
lands.

HTH,
Dave

On Thu, Mar 24, 2016 at 8:26 AM, Ken Martin <ken.martin at kitware.com> wrote:

> Your custom shader has to be written to work with depth peeling. When in a
> depth peeling pass it needs to do some texture lookups and discard
> fragments based on those lookups. I've included the general gist below. I
> use string replacements to handle it but you are free to use other
> approaches as long as the end result in a depth peeling pass has something
> like the following in it.
>
> Thanks
> Ken
>
>   // are we using depth peeling?
>   vtkInformation *info = actor->GetPropertyKeys();
>   if (info && info->Has(vtkDepthPeelingPass::OpaqueZTextureUnit()))
>     {
>     vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Dec",
>       "uniform vec2 screenSize;\n"
>       "uniform sampler2D opaqueZTexture;\n"
>       "uniform sampler2D translucentZTexture;\n");
>     // the .0000001 below is an epsilon.  It turns out that
>     // graphics cards can render the same polygon two times
>     // in a row with different z values. I suspect it has to
>     // do with how rasterization of the polygon is broken up.
>     // A different breakup across fragment shaders can result in
>     // very slightly different z values for some of the pixels.
>     // The end result is that with depth peeling, you can end up
>     // counting/accumulating pixels of the same surface twice
>     // simply due to this randomness in z values. So we introduce
>     // an epsilon into the transparent test to require some
>     // minimal z separation between pixels
>     vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Impl",
>       "float odepth = texture2D(opaqueZTexture,
> gl_FragCoord.xy/screenSize).r;\n"
>       "  if (gl_FragCoord.z >= odepth) { discard; }\n"
>       "  float tdepth = texture2D(translucentZTexture,
> gl_FragCoord.xy/screenSize).r;\n"
>       "  if (gl_FragCoord.z <= tdepth + .0000001) { discard; }\n"
>
>
>
>
> On Wed, Mar 23, 2016 at 7:08 PM, Brad Hollister <behollis at sci.utah.edu>
> wrote:
>
>> Hi,
>>
>> We have a problem with transparent foreground polys occluding geometry.
>>
>> We're trying to use depth peeling to handle foreground polygons with
>> transparency. However, while depth peeling is enabled,
>> GetLastRenderingUsedDepthPeeling() returns false.
>>
>> (The polygons also intersect other similar polygons so that some parts of
>> them are in front of others, while other parts of the same poly may be
>> behind others. Another reason to use depth peeling as opposed to depth
>> sorting, in our opinion.)
>>
>> We also require custom shaders, using
>> vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code @
>> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx,
>> it looks as though custom shaders can't be used with depth peeling in VTK.
>>
>> Thus, is there another way to enable depth peeling or to have transparent
>> foreground polys in our usage scenario?
>>
>> Regards,
>> Brad
>> _______________________________________________
>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/e1555207/attachment.html>

From will.schroeder at kitware.com  Thu Mar 24 12:42:40 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Thu, 24 Mar 2016 12:42:40 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
Message-ID: <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>

On Thu, Mar 24, 2016 at 12:11 PM, David Lonie <david.lonie at kitware.com>
wrote:

> Anyone else want to share an opinion?


Polishing the API and code is a good thing, and we've seen a lot of organic
growth and improvement over the 22+ years VTK has been in existence. Done
thoughtfully with minimal disruption I am fine with it.

Having said that, I think there is sometimes a tendency to get caught up in
too much polishing and software process and forget core algorithmic and
performance concerns. There are so many algorithms and emerging computing
technologies that we need to integrate and/or add into VTK. For me APIs are
a secondary concern to capability. For example, I think that STL's API
absolutely sucks but I use it because the implementation is often quite
good, and it provides capabilities that benefit me, so I put up with the
API. Another example is the recent OpenGL2 work: we could have revamped the
API/design since there are arguable deficiencies in the
lights/cameras/actors model, but Ken & Team made the hard to decision to
mostly preserve the API warts and all and rework the inner workings seeing
10-100x performance gains with little impact on current applications except
that they are a lot faster. That makes customers really happy. Changing API
makes them really mad. Before we were constantly getting complaints about
rendering speed, rarely about API, and now those rendering complaints seem
to be mostly gone.

Long term VTK will thrive because it's up to snuff in terms of current
algorithms and computing capabilities. A perfect API will not prevent it's
death. Surely it's a balance, I get that, but IMO I'd like to see more
cycles go into algorithms, computing, and performance.

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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/14d92765/attachment.html>

From bill.lorensen at gmail.com  Thu Mar 24 12:52:52 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 24 Mar 2016 09:52:52 -0700
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
 <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
Message-ID: <CADZJ4hNw-PyTOfv_VSBhzfzLUxKf-k5A__Pme0Sr8hk=jr71FQ@mail.gmail.com>

+1
On Mar 24, 2016 9:43 AM, "Will Schroeder" <will.schroeder at kitware.com>
wrote:

>
> On Thu, Mar 24, 2016 at 12:11 PM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> Anyone else want to share an opinion?
>
>
> Polishing the API and code is a good thing, and we've seen a lot of
> organic growth and improvement over the 22+ years VTK has been in
> existence. Done thoughtfully with minimal disruption I am fine with it.
>
> Having said that, I think there is sometimes a tendency to get caught up
> in too much polishing and software process and forget core algorithmic and
> performance concerns. There are so many algorithms and emerging computing
> technologies that we need to integrate and/or add into VTK. For me APIs are
> a secondary concern to capability. For example, I think that STL's API
> absolutely sucks but I use it because the implementation is often quite
> good, and it provides capabilities that benefit me, so I put up with the
> API. Another example is the recent OpenGL2 work: we could have revamped the
> API/design since there are arguable deficiencies in the
> lights/cameras/actors model, but Ken & Team made the hard to decision to
> mostly preserve the API warts and all and rework the inner workings seeing
> 10-100x performance gains with little impact on current applications except
> that they are a lot faster. That makes customers really happy. Changing API
> makes them really mad. Before we were constantly getting complaints about
> rendering speed, rarely about API, and now those rendering complaints seem
> to be mostly gone.
>
> Long term VTK will thrive because it's up to snuff in terms of current
> algorithms and computing capabilities. A perfect API will not prevent it's
> death. Surely it's a balance, I get that, but IMO I'd like to see more
> cycles go into algorithms, computing, and performance.
>
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/e140d6b6/attachment-0001.html>

From behollis at sci.utah.edu  Thu Mar 24 13:08:04 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Thu, 24 Mar 2016 11:08:04 -0600
Subject: [vtk-developers] vtk-developers Digest, Vol 143, Issue 30
In-Reply-To: <mailman.1521.1458822393.3364.vtk-developers@vtk.org>
References: <mailman.1521.1458822393.3364.vtk-developers@vtk.org>
Message-ID: <web-12422213@sci.utah.edu>

This should help. However, it looks like depth peeling isn't being 
enable regardless of using custom shaders.

I just saw this old email thread:

http://www.vtk.org/pipermail/vtkusers/2010-August/062106.html

We're using QVTK / Python bindings. Is there a problem with depth 
peeling and the Python modules?

Regards,
Brad

> Date: Thu, 24 Mar 2016 08:26:30 -0400
>From: Ken Martin <ken.martin at kitware.com>
> To: Brad Hollister <behollis at sci.utah.edu>
> Cc: VTK Developers <vtk-developers at vtk.org>
> Subject: Re: [vtk-developers] transparent foreground polygons
> 	occluding background geometry
> Message-ID:
> 	<CANXz0Sb_qKZkgny0eymo6xZJuw-w653VtP0nr843NR7MAQ8V9A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Your custom shader has to be written to work with depth peeling. 
>When in a
> depth peeling pass it needs to do some texture lookups and discard
> fragments based on those lookups. I've included the general gist 
>below. I
> use string replacements to handle it but you are free to use other
> approaches as long as the end result in a depth peeling pass has 
>something
> like the following in it.
> 
> Thanks
> Ken
> 
>  // are we using depth peeling?
>  vtkInformation *info = actor->GetPropertyKeys();
>  if (info && info->Has(vtkDepthPeelingPass::OpaqueZTextureUnit()))
>    {
>    vtkShaderProgram::Substitute(FSSource, 
>"//VTK::DepthPeeling::Dec",
>      "uniform vec2 screenSize;\n"
>      "uniform sampler2D opaqueZTexture;\n"
>      "uniform sampler2D translucentZTexture;\n");
>    // the .0000001 below is an epsilon.  It turns out that
>    // graphics cards can render the same polygon two times
>    // in a row with different z values. I suspect it has to
>    // do with how rasterization of the polygon is broken up.
>    // A different breakup across fragment shaders can result in
>    // very slightly different z values for some of the pixels.
>    // The end result is that with depth peeling, you can end up
>    // counting/accumulating pixels of the same surface twice
>    // simply due to this randomness in z values. So we introduce
>    // an epsilon into the transparent test to require some
>    // minimal z separation between pixels
>    vtkShaderProgram::Substitute(FSSource, 
>"//VTK::DepthPeeling::Impl",
>      "float odepth = texture2D(opaqueZTexture,
> gl_FragCoord.xy/screenSize).r;\n"
>      "  if (gl_FragCoord.z >= odepth) { discard; }\n"
>      "  float tdepth = texture2D(translucentZTexture,
> gl_FragCoord.xy/screenSize).r;\n"
>      "  if (gl_FragCoord.z <= tdepth + .0000001) { discard; }\n"
> 
> 
> 
> 
> On Wed, Mar 23, 2016 at 7:08 PM, Brad Hollister 
><behollis at sci.utah.edu>
> wrote:
> 
>> Hi,
>>
>> We have a problem with transparent foreground polys occluding 
>>geometry.
>>
>> We're trying to use depth peeling to handle foreground polygons with
>> transparency. However, while depth peeling is enabled,
>> GetLastRenderingUsedDepthPeeling() returns false.
>>
>> (The polygons also intersect other similar polygons so that some 
>>parts of
>> them are in front of others, while other parts of the same poly may 
>>be
>> behind others. Another reason to use depth peeling as opposed to 
>>depth
>> sorting, in our opinion.)
>>
>> We also require custom shaders, using
>> vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code 
>>@
>> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx,
>> it looks as though custom shaders can't be used with depth peeling 
>>in VTK.
>>
>> Thus, is there another way to enable depth peeling or to have 
>>transparent
>> foreground polys in our usage scenario?
>>
>> Regards,
>> Brad
>> _______________________________________________
>> 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

From sean at rogue-research.com  Thu Mar 24 13:12:55 2016
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 24 Mar 2016 13:12:55 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
 <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
Message-ID: <20160324171255.1067496605@mail.rogue-research.com>

On Thu, 24 Mar 2016 12:42:40 -0400, Will Schroeder said:

>Polishing the API and code is a good thing, and we've seen a lot of organic
>growth and improvement over the 22+ years VTK has been in existence. Done
>thoughtfully with minimal disruption I am fine with it.

I agree with the gist of your post.

But it seems to me, in this concrete case, that renaming an API qualifies as "minimal disruption".  The old name just needs to be tagged deprecated, it's behaviour doesn't need to change.  Old code will still work.

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.lonie at kitware.com  Thu Mar 24 13:19:46 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 24 Mar 2016 13:19:46 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
 <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
Message-ID: <CA+=e1ouaVXj=4Ze0NMKmV2XEZuQ9-n6N_rzLLdNVt9mXAVKyRg@mail.gmail.com>

On Thu, Mar 24, 2016 at 12:42 PM, Will Schroeder <will.schroeder at kitware.com
> wrote:

> I think there is sometimes a tendency to get caught up in too much
> polishing and software process and forget core algorithmic and performance
> concerns.
>
> I'd like to see more cycles go into algorithms, computing, and performance.
>

This rings true and I certainly agree that a stable API is a great thing to
offer to customers. However, IMO this should be balanced with providing a
'correct' API that makes sense and is intuitive and frustration-free as
possible.

I wouldn't consider revamping the Insert behavior (or just removing the
method) to be polish -- I'd consider it a bugfix. Array insertion has a
well-defined meaning to developers, and this break from convention is a
problem for new developers.

They'll expect insert to insert, but instead it just sets. Their code looks
correct, and they'll have a hell of a time trying to figure out why it
isn't working at runtime until they either (a) start digging through
documentation for what should be self-documenting APIs, or (b) step through
the code with a debugger. At this point, they've wasted time tracking down
this unconventional behavior just to find that VTK's methods don't behave
as expected. It's incredibly frustrating to review your own code countless
times trying to figure out what you did wrong, when in reality it's an
external toolkit that's broken -- and it's worse when the brokenness is
known and intentional.

To play devil's advocate to the 'stable APIs keep customers happy"
argument, broken APIs discourage new developers. It doesn't inspire
confidence in the toolkit when you can't expect a common array method to do
what it says it should.

My $0.02,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/a4ed5435/attachment.html>

From josp.jorge at gmail.com  Thu Mar 24 13:36:40 2016
From: josp.jorge at gmail.com (Jorge Perez)
Date: Thu, 24 Mar 2016 18:36:40 +0100
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
 <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
Message-ID: <CAM2LniGFULccp1rFNC+_w5ECDPArgpNg5TiqYtvHuigfHaM3wA@mail.gmail.com>

++1 = 2

2016-03-24 17:42 GMT+01:00 Will Schroeder <will.schroeder at kitware.com>:

>
> On Thu, Mar 24, 2016 at 12:11 PM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> Anyone else want to share an opinion?
>
>
> Polishing the API and code is a good thing, and we've seen a lot of
> organic growth and improvement over the 22+ years VTK has been in
> existence. Done thoughtfully with minimal disruption I am fine with it.
>
> Having said that, I think there is sometimes a tendency to get caught up
> in too much polishing and software process and forget core algorithmic and
> performance concerns. There are so many algorithms and emerging computing
> technologies that we need to integrate and/or add into VTK. For me APIs are
> a secondary concern to capability. For example, I think that STL's API
> absolutely sucks but I use it because the implementation is often quite
> good, and it provides capabilities that benefit me, so I put up with the
> API. Another example is the recent OpenGL2 work: we could have revamped the
> API/design since there are arguable deficiencies in the
> lights/cameras/actors model, but Ken & Team made the hard to decision to
> mostly preserve the API warts and all and rework the inner workings seeing
> 10-100x performance gains with little impact on current applications except
> that they are a lot faster. That makes customers really happy. Changing API
> makes them really mad. Before we were constantly getting complaints about
> rendering speed, rarely about API, and now those rendering complaints seem
> to be mostly gone.
>
> Long term VTK will thrive because it's up to snuff in terms of current
> algorithms and computing capabilities. A perfect API will not prevent it's
> death. Surely it's a balance, I get that, but IMO I'd like to see more
> cycles go into algorithms, computing, and performance.
>
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/36ebea26/attachment.html>

From will.schroeder at kitware.com  Thu Mar 24 13:38:02 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Thu, 24 Mar 2016 13:38:02 -0400
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CA+=e1ouaVXj=4Ze0NMKmV2XEZuQ9-n6N_rzLLdNVt9mXAVKyRg@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
 <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
 <CA+=e1ouaVXj=4Ze0NMKmV2XEZuQ9-n6N_rzLLdNVt9mXAVKyRg@mail.gmail.com>
Message-ID: <CAEiDrtW_iNQkGBvs=KAjgTMc1ieka_Nk8KUjL0zXcqLkZdkK0Q@mail.gmail.com>

A couple of points:

+ there is a drift in the meaning of the API. 22 years ago as C++ was
emerging some of the semantics were less settled. Insert meant "put data
here and perform memory allocation if necessary" as compared to Set which
meant "put data here without range checking." Things have evolved since
then, probably for the better, which is why the behavior sometimes feels
weird given a contemporary understanding.

+ 'that renaming an API qualifies as "minimal disruption"' - well that's
easy for a developer to say :-). And frankly I'm less concerned about
developers than I am about users and paying customers.

+ Since, based on the email response, it seems that several of us have
jumped right back to the attitude of  "....but I want to polish some code!"
how about we strike a deal: before any more polishing each of you speed up
one algorithm by 2x or more (yes you can use vtkSMPTools or other
approach), or add a new class with a new analysis, visualization or
rendering feature. Then I know you are serious about balancing the needs of
capability versus polish :-) Call me when you are done, or if you need some
ideas I can steer you.

Best, and thanks for humoring me,
W

On Thu, Mar 24, 2016 at 1:19 PM, David Lonie <david.lonie at kitware.com>
wrote:

> On Thu, Mar 24, 2016 at 12:42 PM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> I think there is sometimes a tendency to get caught up in too much
>> polishing and software process and forget core algorithmic and performance
>> concerns.
>>
>> I'd like to see more cycles go into algorithms, computing, and
>> performance.
>>
>
> This rings true and I certainly agree that a stable API is a great thing
> to offer to customers. However, IMO this should be balanced with providing
> a 'correct' API that makes sense and is intuitive and frustration-free as
> possible.
>
> I wouldn't consider revamping the Insert behavior (or just removing the
> method) to be polish -- I'd consider it a bugfix. Array insertion has a
> well-defined meaning to developers, and this break from convention is a
> problem for new developers.
>
> They'll expect insert to insert, but instead it just sets. Their code
> looks correct, and they'll have a hell of a time trying to figure out why
> it isn't working at runtime until they either (a) start digging through
> documentation for what should be self-documenting APIs, or (b) step through
> the code with a debugger. At this point, they've wasted time tracking down
> this unconventional behavior just to find that VTK's methods don't behave
> as expected. It's incredibly frustrating to review your own code countless
> times trying to figure out what you did wrong, when in reality it's an
> external toolkit that's broken -- and it's worse when the brokenness is
> known and intentional.
>
> To play devil's advocate to the 'stable APIs keep customers happy"
> argument, broken APIs discourage new developers. It doesn't inspire
> confidence in the toolkit when you can't expect a common array method to do
> what it says it should.
>
> My $0.02,
> Dave
>



-- 
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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/e4563791/attachment-0001.html>

From bill.lorensen at gmail.com  Thu Mar 24 13:41:25 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 24 Mar 2016 10:41:25 -0700
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CADZJ4hPvA5xEjHWcXUEVKVxwzjCLkhAV7Kc=gkxkHMTdsdA88A@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
 <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
 <CADZJ4hPvA5xEjHWcXUEVKVxwzjCLkhAV7Kc=gkxkHMTdsdA88A@mail.gmail.com>
Message-ID: <CADZJ4hNSdeS=ag-BhWx+dk8MOtHMZfgbQjBjtvZu0cG6ma_7-Q@mail.gmail.com>

Why not
Set/Get/Insert/InsertNext/Tuple
SetTuple, GetTuple, InsertTuple and InsertMNextTuple are used in many
other classes.



On Wed, Mar 23, 2016 at 9:48 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> The new names don't make much sense to me.
>
> On Mar 23, 2016 8:51 PM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>
>> On Wed, Mar 23, 2016 at 8:55 PM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>>>
>>> Recently the API for vtkAOSDataArrayTemplate was changed.
>>>
>>> Set/Get/Insert/InsertNextTupleValue was changed to
>>> Set/Get/Insert/InsertNextTypedTuple.
>>>
>>> What was the purpose of the name change?
>>>
>>> There are 13 c++ wiki examples that use the old API. I will need to
>>> #if the changed code so that it will still compile with older vtk
>>> versions. I do not turn on legacy options for the examples.
>>>
>>> Seems like an arbitrary change to me.
>>
>>
>> I was bitten by this as well.  But I can understand the rationale
>> behind the change.  The old name made little sense.
>>
>> Actually, I recommend going even further: add new methods
>> called GetTypedValue() et al. and deprecate GetValue() et al.
>> Then, for VTK 8, I would love to see these method appear:
>>
>>   double vtkDataArray::GetValue()
>>   vtkIdType vtkAbstractArray::GetNumberOfValues()
>>
>> I would really like GetNumberOfValues() to make a comeback.
>>
>>  - David
>>
>>
>>
>



-- 
Unpaid intern in BillsBasement at noware dot com

From david.gobbi at gmail.com  Thu Mar 24 13:41:28 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 24 Mar 2016 11:41:28 -0600
Subject: [vtk-developers] About the vtkDataArray::InsertTuple() method
In-Reply-To: <CA+=e1ouaVXj=4Ze0NMKmV2XEZuQ9-n6N_rzLLdNVt9mXAVKyRg@mail.gmail.com>
References: <CANwS1=EF+Ljt2OtJ-WRF9jBySLShA48hpz6Ang1LQpthfBoYJw@mail.gmail.com>
 <20160324140302.821065445@mail.rogue-research.com>
 <CANwS1=HDZT7_DUESBnRpQh-zskWbVaYDX7Jg+qs5vLL0jQrFBA@mail.gmail.com>
 <20160324155319.1050506101@mail.rogue-research.com>
 <CA+=e1osjpJ_TsWsoB_x6=2RB68F-VegXmZhk7qN-rM5-0gsjXA@mail.gmail.com>
 <CAEiDrtX+o_X_O37H092W_yTsxWAYKr1DYoQ6QHKK6RDyoShoQw@mail.gmail.com>
 <CA+=e1ouaVXj=4Ze0NMKmV2XEZuQ9-n6N_rzLLdNVt9mXAVKyRg@mail.gmail.com>
Message-ID: <CANwS1=FvRFBUx-bQHGEOdytH1pVd7R5M4SDQK0fu6WDCcqwX_w@mail.gmail.com>

On Thu, Mar 24, 2016 at 11:19 AM, David Lonie <david.lonie at kitware.com>
wrote:

>
> I wouldn't consider revamping the Insert behavior (or just removing the
> method) to be polish -- I'd consider it a bugfix. Array insertion has a
> well-defined meaning to developers, and this break from convention is a
> problem for new developers.
>
> They'll expect insert to insert, but instead it just sets. Their code
> looks correct, and they'll have a hell of a time trying to figure out why
> it isn't working at runtime until they either (a) start digging through
> documentation for what should be self-documenting APIs, or (b) step through
> the code with a debugger. At this point, they've wasted time tracking down
> this unconventional behavior just to find that VTK's methods don't behave
> as expected. It's incredibly frustrating to review your own code countless
> times trying to figure out what you did wrong, when in reality it's an
> external toolkit that's broken -- and it's worse when the brokenness is
> known and intentional.
>

This sums up my feelings on this particular API.

I'm all for adding new algorithms to VTK, but over the years I've seen
algorithms go into VTK with buggy, unstable, and even incorrect
implementations.  A poorly-understood API can easily lead to bugs.  The
vtkDataArray::Insert() methods are easily misunderstood (and IMHO
unnecessary) so they should be deprecated.

Personally, I wish that a lot more attention was paid to the bugtracker.
Stability/correctness of algorithms is very important to me (but, yeah,
speed is important too, and everyone knows that I've written crazy code at
times in order to save a few CPU cycles).

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/500e47c0/attachment.html>

From david.lonie at kitware.com  Thu Mar 24 13:58:50 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 24 Mar 2016 13:58:50 -0400
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CADZJ4hNSdeS=ag-BhWx+dk8MOtHMZfgbQjBjtvZu0cG6ma_7-Q@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
 <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
 <CADZJ4hPvA5xEjHWcXUEVKVxwzjCLkhAV7Kc=gkxkHMTdsdA88A@mail.gmail.com>
 <CADZJ4hNSdeS=ag-BhWx+dk8MOtHMZfgbQjBjtvZu0cG6ma_7-Q@mail.gmail.com>
Message-ID: <CA+=e1ovF0v+zAhgvT-wT+9NF74sZmK64DvEFdfrLuPeHSTOoSg@mail.gmail.com>

On Thu, Mar 24, 2016 at 1:41 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Why not
> Set/Get/Insert/InsertNext/Tuple
> SetTuple, GetTuple, InsertTuple and InsertMNextTuple are used in many
> other classes.


I'm afraid I don't follow what you're saying. The methods you list haven't
changed -- they still exist in vtkDataArray and treat all values as doubles.

The only change was s/TupleValue/TypedTuple/ to clarify that these methods
use native types and don't suffer from the type conversion issues that the
vtkDataArray methods do.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/b1bc9df5/attachment.html>

From bill.lorensen at gmail.com  Thu Mar 24 14:02:44 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 24 Mar 2016 11:02:44 -0700
Subject: [vtk-developers] vtkAOSDataArrayTemplate annoying API change
In-Reply-To: <CA+=e1ovF0v+zAhgvT-wT+9NF74sZmK64DvEFdfrLuPeHSTOoSg@mail.gmail.com>
References: <CADZJ4hM7ODENh1wWTkEdEH1V3qap7GFUsfNZPSfyLTnJOZUC8Q@mail.gmail.com>
 <CANwS1=FGD0ZttS3tD_9ZjPRN8SDhFH_ZaML-QQ_v8zuNS9DGMA@mail.gmail.com>
 <CADZJ4hPvA5xEjHWcXUEVKVxwzjCLkhAV7Kc=gkxkHMTdsdA88A@mail.gmail.com>
 <CADZJ4hNSdeS=ag-BhWx+dk8MOtHMZfgbQjBjtvZu0cG6ma_7-Q@mail.gmail.com>
 <CA+=e1ovF0v+zAhgvT-wT+9NF74sZmK64DvEFdfrLuPeHSTOoSg@mail.gmail.com>
Message-ID: <CADZJ4hNzhFTXqw2yNSK0nOu8HOs_fSz+oGoqBHWK62KBWFss1Q@mail.gmail.com>

My bad.


On Thu, Mar 24, 2016 at 10:58 AM, David Lonie <david.lonie at kitware.com> wrote:
> On Thu, Mar 24, 2016 at 1:41 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> Why not
>> Set/Get/Insert/InsertNext/Tuple
>> SetTuple, GetTuple, InsertTuple and InsertMNextTuple are used in many
>> other classes.
>
>
> I'm afraid I don't follow what you're saying. The methods you list haven't
> changed -- they still exist in vtkDataArray and treat all values as doubles.
>
> The only change was s/TupleValue/TypedTuple/ to clarify that these methods
> use native types and don't suffer from the type conversion issues that the
> vtkDataArray methods do.
>
> Dave



-- 
Unpaid intern in BillsBasement at noware dot com

From behollis at sci.utah.edu  Thu Mar 24 14:52:32 2016
From: behollis at sci.utah.edu (Brad Hollister)
Date: Thu, 24 Mar 2016 12:52:32 -0600
Subject: [vtk-developers] vtkOpenGLPolyDataMapper blend mode
Message-ID: <web-12423791@sci.utah.edu>

While vtkSmartVolumeMapper allows the selection of blending mode via:

SetBlendMode (int)
SetBlendModeToComposite ()
SetBlendModeToMaximumIntensity ()
SetBlendModeToMinimumIntensity ()
SetBlendModeToAdditive ()

is there a similar way to enable a particular type of blending with 
vtkOpenGLPolyDataMapper?

Regards,
Brad

From sean at rogue-research.com  Thu Mar 24 18:20:56 2016
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 24 Mar 2016 18:20:56 -0400
Subject: [vtk-developers] strange default-visible build settings (OSGEO?)
Message-ID: <20160324222056.376031101@mail.rogue-research.com>

Hi all,

I don't recall seeing this before, but these days in ccmake I see the following settings even in non-advanced mode:

 BUNDLEDIR                        Applications/OSGEO                                                                                                                                                             
 FRAMEWORKDIR                     Library/Frameworks                                                                                                                                                             
 LIBRARY_OUTPUT_PATH                                                                                                                                                                                             

I suspect they are from something 3rd party... should they be showing by default like that?

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 Mar 25 09:20:41 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 25 Mar 2016 09:20:41 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 143, Issue 30
In-Reply-To: <web-12422213@sci.utah.edu>
References: <mailman.1521.1458822393.3364.vtk-developers@vtk.org>
 <web-12422213@sci.utah.edu>
Message-ID: <CANXz0SanJ91j6BTQR8QVSzHtDVh+DEijMQa28s=P_XomWe_2UA@mail.gmail.com>

There was a bug in VTK 7 where it was not reporting depth peeling as being
used when really it was being used.

To make a long story long :-) I do not like Renderer having an ivar and
maintaining state about depth peeling. I feel like the render passes should
not pollute the core graphics objects with specifics about them (even
though I myself have done it many times) So I started removing/not updating
the LastRenderUsedDepthPeeling code. One of the recent VTK releases went
out with that method not reporting correctly.  It is fixed in master as of
a while ago.  I still think it is a bad method but at least in master it
should report correctly.

Thanks
Ken



On Thu, Mar 24, 2016 at 1:08 PM, Brad Hollister <behollis at sci.utah.edu>
wrote:

> This should help. However, it looks like depth peeling isn't being enable
> regardless of using custom shaders.
>
> I just saw this old email thread:
>
> http://www.vtk.org/pipermail/vtkusers/2010-August/062106.html
>
> We're using QVTK / Python bindings. Is there a problem with depth peeling
> and the Python modules?
>
> Regards,
> Brad
>
> Date: Thu, 24 Mar 2016 08:26:30 -0400
>> From: Ken Martin <ken.martin at kitware.com>
>> To: Brad Hollister <behollis at sci.utah.edu>
>> Cc: VTK Developers <vtk-developers at vtk.org>
>> Subject: Re: [vtk-developers] transparent foreground polygons
>>         occluding background geometry
>> Message-ID:
>>         <
>> CANXz0Sb_qKZkgny0eymo6xZJuw-w653VtP0nr843NR7MAQ8V9A at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Your custom shader has to be written to work with depth peeling. When in a
>> depth peeling pass it needs to do some texture lookups and discard
>> fragments based on those lookups. I've included the general gist below. I
>> use string replacements to handle it but you are free to use other
>> approaches as long as the end result in a depth peeling pass has something
>> like the following in it.
>>
>> Thanks
>> Ken
>>
>>  // are we using depth peeling?
>>  vtkInformation *info = actor->GetPropertyKeys();
>>  if (info && info->Has(vtkDepthPeelingPass::OpaqueZTextureUnit()))
>>    {
>>    vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Dec",
>>      "uniform vec2 screenSize;\n"
>>      "uniform sampler2D opaqueZTexture;\n"
>>      "uniform sampler2D translucentZTexture;\n");
>>    // the .0000001 below is an epsilon.  It turns out that
>>    // graphics cards can render the same polygon two times
>>    // in a row with different z values. I suspect it has to
>>    // do with how rasterization of the polygon is broken up.
>>    // A different breakup across fragment shaders can result in
>>    // very slightly different z values for some of the pixels.
>>    // The end result is that with depth peeling, you can end up
>>    // counting/accumulating pixels of the same surface twice
>>    // simply due to this randomness in z values. So we introduce
>>    // an epsilon into the transparent test to require some
>>    // minimal z separation between pixels
>>    vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Impl",
>>      "float odepth = texture2D(opaqueZTexture,
>> gl_FragCoord.xy/screenSize).r;\n"
>>      "  if (gl_FragCoord.z >= odepth) { discard; }\n"
>>      "  float tdepth = texture2D(translucentZTexture,
>> gl_FragCoord.xy/screenSize).r;\n"
>>      "  if (gl_FragCoord.z <= tdepth + .0000001) { discard; }\n"
>>
>>
>>
>>
>> On Wed, Mar 23, 2016 at 7:08 PM, Brad Hollister <behollis at sci.utah.edu>
>> wrote:
>>
>> Hi,
>>>
>>> We have a problem with transparent foreground polys occluding geometry.
>>>
>>> We're trying to use depth peeling to handle foreground polygons with
>>> transparency. However, while depth peeling is enabled,
>>> GetLastRenderingUsedDepthPeeling() returns false.
>>>
>>> (The polygons also intersect other similar polygons so that some parts of
>>> them are in front of others, while other parts of the same poly may be
>>> behind others. Another reason to use depth peeling as opposed to depth
>>> sorting, in our opinion.)
>>>
>>> We also require custom shaders, using
>>> vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code @
>>>
>>> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx
>>> ,
>>> it looks as though custom shaders can't be used with depth peeling in
>>> VTK.
>>>
>>> Thus, is there another way to enable depth peeling or to have transparent
>>> foreground polys in our usage scenario?
>>>
>>> Regards,
>>> Brad
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160325/a995b500/attachment-0001.html>

From ken.martin at kitware.com  Fri Mar 25 09:24:54 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 25 Mar 2016 09:24:54 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 143, Issue 30
In-Reply-To: <CANXz0SanJ91j6BTQR8QVSzHtDVh+DEijMQa28s=P_XomWe_2UA@mail.gmail.com>
References: <mailman.1521.1458822393.3364.vtk-developers@vtk.org>
 <web-12422213@sci.utah.edu>
 <CANXz0SanJ91j6BTQR8QVSzHtDVh+DEijMQa28s=P_XomWe_2UA@mail.gmail.com>
Message-ID: <CANXz0SYB=EVu5s0QGp=iXseRnSk0VZbuFNSN8qQ7zxdk995GJw@mail.gmail.com>

I should clarify, there may be alpha bitplane issues with the Qt code, I'm
not sure. Just be warned that the renderer reporting it did not use depth
peeling may not be 100% accurate :-)

Ken

On Fri, Mar 25, 2016 at 9:20 AM, Ken Martin <ken.martin at kitware.com> wrote:

> There was a bug in VTK 7 where it was not reporting depth peeling as being
> used when really it was being used.
>
> To make a long story long :-) I do not like Renderer having an ivar and
> maintaining state about depth peeling. I feel like the render passes should
> not pollute the core graphics objects with specifics about them (even
> though I myself have done it many times) So I started removing/not updating
> the LastRenderUsedDepthPeeling code. One of the recent VTK releases went
> out with that method not reporting correctly.  It is fixed in master as of
> a while ago.  I still think it is a bad method but at least in master it
> should report correctly.
>
> Thanks
> Ken
>
>
>
> On Thu, Mar 24, 2016 at 1:08 PM, Brad Hollister <behollis at sci.utah.edu>
> wrote:
>
>> This should help. However, it looks like depth peeling isn't being enable
>> regardless of using custom shaders.
>>
>> I just saw this old email thread:
>>
>> http://www.vtk.org/pipermail/vtkusers/2010-August/062106.html
>>
>> We're using QVTK / Python bindings. Is there a problem with depth peeling
>> and the Python modules?
>>
>> Regards,
>> Brad
>>
>> Date: Thu, 24 Mar 2016 08:26:30 -0400
>>> From: Ken Martin <ken.martin at kitware.com>
>>> To: Brad Hollister <behollis at sci.utah.edu>
>>> Cc: VTK Developers <vtk-developers at vtk.org>
>>> Subject: Re: [vtk-developers] transparent foreground polygons
>>>         occluding background geometry
>>> Message-ID:
>>>         <
>>> CANXz0Sb_qKZkgny0eymo6xZJuw-w653VtP0nr843NR7MAQ8V9A at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Your custom shader has to be written to work with depth peeling. When in
>>> a
>>> depth peeling pass it needs to do some texture lookups and discard
>>> fragments based on those lookups. I've included the general gist below. I
>>> use string replacements to handle it but you are free to use other
>>> approaches as long as the end result in a depth peeling pass has
>>> something
>>> like the following in it.
>>>
>>> Thanks
>>> Ken
>>>
>>>  // are we using depth peeling?
>>>  vtkInformation *info = actor->GetPropertyKeys();
>>>  if (info && info->Has(vtkDepthPeelingPass::OpaqueZTextureUnit()))
>>>    {
>>>    vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Dec",
>>>      "uniform vec2 screenSize;\n"
>>>      "uniform sampler2D opaqueZTexture;\n"
>>>      "uniform sampler2D translucentZTexture;\n");
>>>    // the .0000001 below is an epsilon.  It turns out that
>>>    // graphics cards can render the same polygon two times
>>>    // in a row with different z values. I suspect it has to
>>>    // do with how rasterization of the polygon is broken up.
>>>    // A different breakup across fragment shaders can result in
>>>    // very slightly different z values for some of the pixels.
>>>    // The end result is that with depth peeling, you can end up
>>>    // counting/accumulating pixels of the same surface twice
>>>    // simply due to this randomness in z values. So we introduce
>>>    // an epsilon into the transparent test to require some
>>>    // minimal z separation between pixels
>>>    vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Impl",
>>>      "float odepth = texture2D(opaqueZTexture,
>>> gl_FragCoord.xy/screenSize).r;\n"
>>>      "  if (gl_FragCoord.z >= odepth) { discard; }\n"
>>>      "  float tdepth = texture2D(translucentZTexture,
>>> gl_FragCoord.xy/screenSize).r;\n"
>>>      "  if (gl_FragCoord.z <= tdepth + .0000001) { discard; }\n"
>>>
>>>
>>>
>>>
>>> On Wed, Mar 23, 2016 at 7:08 PM, Brad Hollister <behollis at sci.utah.edu>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> We have a problem with transparent foreground polys occluding geometry.
>>>>
>>>> We're trying to use depth peeling to handle foreground polygons with
>>>> transparency. However, while depth peeling is enabled,
>>>> GetLastRenderingUsedDepthPeeling() returns false.
>>>>
>>>> (The polygons also intersect other similar polygons so that some parts
>>>> of
>>>> them are in front of others, while other parts of the same poly may be
>>>> behind others. Another reason to use depth peeling as opposed to depth
>>>> sorting, in our opinion.)
>>>>
>>>> We also require custom shaders, using
>>>> vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code @
>>>>
>>>> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx
>>>> ,
>>>> it looks as though custom shaders can't be used with depth peeling in
>>>> VTK.
>>>>
>>>> Thus, is there another way to enable depth peeling or to have
>>>> transparent
>>>> foreground polys in our usage scenario?
>>>>
>>>> Regards,
>>>> Brad
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160325/83fdc151/attachment.html>

From ken.martin at kitware.com  Fri Mar 25 09:47:39 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 25 Mar 2016 09:47:39 -0400
Subject: [vtk-developers] vtkdiy warning
Message-ID: <CANXz0SZMoxFMEzh4LVvMFUo=gsEvVJYg85uQKHL9VU3i_erQgA@mail.gmail.com>

There is a recurring warning on vtkdiy, if that module rings a bell for
you, could you please take a look at the issue?

ThirdParty/diy2/vtkdiy2/include/vtkdiy/assigner.hpp:20:31: warning:
declaration of 'nblocks' shadows a member of 'this'


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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160325/26b705b7/attachment.html>

From ken.martin at kitware.com  Fri Mar 25 10:34:05 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 25 Mar 2016 10:34:05 -0400
Subject: [vtk-developers] vtkOpenGLPolyDataMapper blend mode
In-Reply-To: <web-12423791@sci.utah.edu>
References: <web-12423791@sci.utah.edu>
Message-ID: <CANXz0SZj98hQ59bz5+9FsTat-vCb-KnhmC4jn2FOOfWeGvv+4Q@mail.gmail.com>

I thought there might be but I do not see it. From an OpenGL perspective it
is pretty easy. We just change the

  glBlendFuncSeparate() and glBlendEquationSeparate() calls as they can do
what you want.

The risk we run is that some render passes and mappers rely on specific
blend functions to work. They would end up overriding what the user set or
failing which could be confusing. The place to do it would be to add the
ivar/methods into vtkProperty and then in vtkOpenGLActor::Render() use the
property and set the blend functions.

Thanks
Ken



On Thu, Mar 24, 2016 at 2:52 PM, Brad Hollister <behollis at sci.utah.edu>
wrote:

> While vtkSmartVolumeMapper allows the selection of blending mode via:
>
> SetBlendMode (int)
> SetBlendModeToComposite ()
> SetBlendModeToMaximumIntensity ()
> SetBlendModeToMinimumIntensity ()
> SetBlendModeToAdditive ()
>
> is there a similar way to enable a particular type of blending with
> vtkOpenGLPolyDataMapper?
>
> Regards,
> Brad
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160325/ecd64d96/attachment-0001.html>

From sujin.philip at kitware.com  Mon Mar 28 13:29:03 2016
From: sujin.philip at kitware.com (Sujin Philip)
Date: Mon, 28 Mar 2016 13:29:03 -0400
Subject: [vtk-developers] vtkdiy warning
In-Reply-To: <CANXz0SZMoxFMEzh4LVvMFUo=gsEvVJYg85uQKHL9VU3i_erQgA@mail.gmail.com>
References: <CANXz0SZMoxFMEzh4LVvMFUo=gsEvVJYg85uQKHL9VU3i_erQgA@mail.gmail.com>
Message-ID: <CAEWo2JOzA_07HrrY-Ug5UTtdfWeurs0E-KNHG1Y+PhEOz7Q6FQ@mail.gmail.com>

Hi Ken,

I talked with the diy2 developers and they said that they are working on
removing the warnings.

Thanks
Sujin


On Fri, Mar 25, 2016 at 9:47 AM, Ken Martin <ken.martin at kitware.com> wrote:

>
> There is a recurring warning on vtkdiy, if that module rings a bell for
> you, could you please take a look at the issue?
>
> ThirdParty/diy2/vtkdiy2/include/vtkdiy/assigner.hpp:20:31: warning: declaration of 'nblocks' shadows a member of 'this'
>
>
> 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.
>
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160328/3311684a/attachment.html>

From dave.demarle at kitware.com  Mon Mar 28 15:58:12 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Mon, 28 Mar 2016 15:58:12 -0400
Subject: [vtk-developers] vtkdiy warning
In-Reply-To: <CAEWo2JOzA_07HrrY-Ug5UTtdfWeurs0E-KNHG1Y+PhEOz7Q6FQ@mail.gmail.com>
References: <CANXz0SZMoxFMEzh4LVvMFUo=gsEvVJYg85uQKHL9VU3i_erQgA@mail.gmail.com>
 <CAEWo2JOzA_07HrrY-Ug5UTtdfWeurs0E-KNHG1Y+PhEOz7Q6FQ@mail.gmail.com>
Message-ID: <CANjZAi8i14fixUo2zmsOT14-SZkb2KDGBaahHNJ4po_FXtHWzw@mail.gmail.com>

Throw a vtk_third_party_warning_suppress(VTKDIY2 C) in to
ThirdPary/diy2/vtkdiy2/CMakeLists.txt until then?




David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Mon, Mar 28, 2016 at 1:29 PM, Sujin Philip <sujin.philip at kitware.com>
wrote:

> Hi Ken,
>
> I talked with the diy2 developers and they said that they are working on
> removing the warnings.
>
> Thanks
> Sujin
>
>
> On Fri, Mar 25, 2016 at 9:47 AM, Ken Martin <ken.martin at kitware.com>
> wrote:
>
>>
>> There is a recurring warning on vtkdiy, if that module rings a bell for
>> you, could you please take a look at the issue?
>>
>> ThirdParty/diy2/vtkdiy2/include/vtkdiy/assigner.hpp:20:31: warning: declaration of 'nblocks' shadows a member of 'this'
>>
>>
>> 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.
>>
>> _______________________________________________
>> 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: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160328/8b2b07db/attachment.html>

From tharun160190 at gmail.com  Mon Mar 28 22:05:39 2016
From: tharun160190 at gmail.com (Tharun)
Date: Mon, 28 Mar 2016 19:05:39 -0700 (MST)
Subject: [vtk-developers] interactive selection of faces of polydata
Message-ID: <1459217139360-5737436.post@n5.nabble.com>

Hi all, 

I would like to select faces of polydata inside closed polygon drawn on
screen. I would like to know if there are any functions which can do this
readily in VTK.

Thank you



--
View this message in context: http://vtk.1045678.n5.nabble.com/interactive-selection-of-faces-of-polydata-tp5737436.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From schuyler.kylstra at kitware.com  Tue Mar 29 11:23:45 2016
From: schuyler.kylstra at kitware.com (Schuyler Kylstra)
Date: Tue, 29 Mar 2016 11:23:45 -0400
Subject: [vtk-developers] python wrapping with VTK 7
Message-ID: <CAG1ynEy+ku1Hk+wTn8_gaqAGQ5k7qbJx0hpme4r1=4_x9DAYuA@mail.gmail.com>

Hi devs,

I'm working on a VTK 7 based project that I'm trying to wrap in python. I'm
stuck at a point where the project builds but the python library cannot be
included. I'm doing the following in my CMakeLists.txt file:


SET(SRCS
  ....
  )

SET_SOURCE_FILES_PROPERTIES(
  <subset of SRCS>
  PROPERTIES
  WRAP_EXCLUDE 1
  WRAP_EXCLUDE_PYTHON 1
  )

SET(VTK_LIBRARIES

   <vtk libraries>
   )

SET(KIT_PYTHON_LIBRARIES ${VTK_LIBRARIES})

SET(LIBRARY_MODE "SHARED")


INCLUDE(${VTK_CMAKE_DIR}/vtkWrapPython.cmake)
VTK_WRAP_PYTHON3(${LIB_NAME}Python PYTHON_SRCS "${SRCS}")
ADD_LIBRARY(${LIB_NAME}PythonD ${LIBRARY_MODE} ${PYTHON_SRCS})
ADD_LIBRARY(${LIB_NAME}Python MODULE ${LIB_NAME}PythonInit.cxx)

TARGET_LINK_LIBRARIES(${LIB_NAME}PythonD ${LIB_NAME})

FOREACH(c ${KIT_PYTHON_LIBRARIES})
  TARGET_LINK_LIBRARIES(${LIB_NAME}PythonD ${c}PythonD)
ENDFOREACH(c)

TARGET_LINK_LIBRARIES(${LIB_NAME}Python ${LIB_NAME}PythonD)


As I said before, this all builds without error but when I try to run any
python script that includes the library I get the following error:


ImportError: dynamic module does not define init function

Is there something I need to add to ensure that the init function is
created?

-- 
Schuyler Kylstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160329/df22cc21/attachment.html>

From david.gobbi at gmail.com  Tue Mar 29 17:16:46 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 29 Mar 2016 15:16:46 -0600
Subject: [vtk-developers] python wrapping with VTK 7
In-Reply-To: <CAG1ynEy+ku1Hk+wTn8_gaqAGQ5k7qbJx0hpme4r1=4_x9DAYuA@mail.gmail.com>
References: <CAG1ynEy+ku1Hk+wTn8_gaqAGQ5k7qbJx0hpme4r1=4_x9DAYuA@mail.gmail.com>
Message-ID: <CANwS1=H8ONYbUY++gB_EGR0Z64_+uaZBJ=Sv3DNVBHgG7V5v3g@mail.gmail.com>

Hi Schuyler,

The PythonInit.cxx file provides the module's init function, so if the
module fails to load, my guess is that the name of the init function
does not match the name of the module.

Try adding these lines, to change the prefix/suffix of the shared
object:

    set_target_properties(${LIB_NAME}Python PROPERTIES PREFIX "")
    if(WIN32)
      set_target_properties(${LIB_NAME}Python PROPERTIES SUFFIX ".pyd")
    endif()

I've written a set of macros for wrapping external projects, I hope to
release them soon.  For reference, here is the code that I use to create
the python module:

    vtk_wrap_python3(${MODULE_PYTHON_NAME} LIB_PYTHON_SRCS "${_srcs}")
    add_library(${LIB_PYTHON_NAME}
      ${LIB_PYTHON_SRCS} ${LIB_PYTHON_EXTRA_SRCS}
      ${LIB_HIERARCHY_STAMP})
    set_target_properties(${LIB_PYTHON_NAME} PROPERTIES
      POSITION_INDEPENDENT_CODE ON
      OUTPUT_NAME "${LIB_PYTHON_OUTPUT_NAME}")
    target_link_libraries(${LIB_PYTHON_NAME} LINK_PUBLIC ${_name}
${LIB_PYTHON_LIBS})
    add_library(${MODULE_PYTHON_NAME} MODULE ${MODULE_PYTHON_NAME}Init.cxx)
    set_target_properties(${MODULE_PYTHON_NAME} PROPERTIES PREFIX "")
    if(WIN32)
      set_target_properties(${MODULE_PYTHON_NAME} PROPERTIES SUFFIX ".pyd")
    endif()
    set_target_properties(${MODULE_PYTHON_NAME} PROPERTIES NO_SONAME 1)
    target_link_libraries(${MODULE_PYTHON_NAME} ${LIB_PYTHON_NAME})

 - David

On Tue, Mar 29, 2016 at 9:23 AM, Schuyler Kylstra <
schuyler.kylstra at kitware.com> wrote:

> Hi devs,
>
> I'm working on a VTK 7 based project that I'm trying to wrap in python.
> I'm stuck at a point where the project builds but the python library cannot
> be included. I'm doing the following in my CMakeLists.txt file:
>
>
> SET(SRCS
>   ....
>   )
>
> SET_SOURCE_FILES_PROPERTIES(
>   <subset of SRCS>
>   PROPERTIES
>   WRAP_EXCLUDE 1
>   WRAP_EXCLUDE_PYTHON 1
>   )
>
> SET(VTK_LIBRARIES
>
>    <vtk libraries>
>    )
>
> SET(KIT_PYTHON_LIBRARIES ${VTK_LIBRARIES})
>
> SET(LIBRARY_MODE "SHARED")
>
>
> INCLUDE(${VTK_CMAKE_DIR}/vtkWrapPython.cmake)
> VTK_WRAP_PYTHON3(${LIB_NAME}Python PYTHON_SRCS "${SRCS}")
> ADD_LIBRARY(${LIB_NAME}PythonD ${LIBRARY_MODE} ${PYTHON_SRCS})
> ADD_LIBRARY(${LIB_NAME}Python MODULE ${LIB_NAME}PythonInit.cxx)
>
> TARGET_LINK_LIBRARIES(${LIB_NAME}PythonD ${LIB_NAME})
>
> FOREACH(c ${KIT_PYTHON_LIBRARIES})
>   TARGET_LINK_LIBRARIES(${LIB_NAME}PythonD ${c}PythonD)
> ENDFOREACH(c)
>
> TARGET_LINK_LIBRARIES(${LIB_NAME}Python ${LIB_NAME}PythonD)
>
>
> As I said before, this all builds without error but when I try to run any
> python script that includes the library I get the following error:
>
>
> ImportError: dynamic module does not define init function
>
> Is there something I need to add to ensure that the init function is
> created?
>
> --
> Schuyler Kylstra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160329/d2cf265e/attachment.html>

From schuyler.kylstra at kitware.com  Wed Mar 30 15:02:20 2016
From: schuyler.kylstra at kitware.com (Schuyler Kylstra)
Date: Wed, 30 Mar 2016 15:02:20 -0400
Subject: [vtk-developers] python wrapping with VTK 7
In-Reply-To: <CANwS1=H8ONYbUY++gB_EGR0Z64_+uaZBJ=Sv3DNVBHgG7V5v3g@mail.gmail.com>
References: <CAG1ynEy+ku1Hk+wTn8_gaqAGQ5k7qbJx0hpme4r1=4_x9DAYuA@mail.gmail.com>
 <CANwS1=H8ONYbUY++gB_EGR0Z64_+uaZBJ=Sv3DNVBHgG7V5v3g@mail.gmail.com>
Message-ID: <CAG1ynEysh5CojKYPJEm=jq-g-Kn-HbQmjiEDeFzbO4tp4frj+A@mail.gmail.com>

Thanks David! That fixed it.

On Tue, Mar 29, 2016 at 5:16 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Schuyler,
>
> The PythonInit.cxx file provides the module's init function, so if the
> module fails to load, my guess is that the name of the init function
> does not match the name of the module.
>
> Try adding these lines, to change the prefix/suffix of the shared
> object:
>
>     set_target_properties(${LIB_NAME}Python PROPERTIES PREFIX "")
>     if(WIN32)
>       set_target_properties(${LIB_NAME}Python PROPERTIES SUFFIX ".pyd")
>     endif()
>
> I've written a set of macros for wrapping external projects, I hope to
> release them soon.  For reference, here is the code that I use to create
> the python module:
>
>     vtk_wrap_python3(${MODULE_PYTHON_NAME} LIB_PYTHON_SRCS "${_srcs}")
>     add_library(${LIB_PYTHON_NAME}
>       ${LIB_PYTHON_SRCS} ${LIB_PYTHON_EXTRA_SRCS}
>       ${LIB_HIERARCHY_STAMP})
>     set_target_properties(${LIB_PYTHON_NAME} PROPERTIES
>       POSITION_INDEPENDENT_CODE ON
>       OUTPUT_NAME "${LIB_PYTHON_OUTPUT_NAME}")
>     target_link_libraries(${LIB_PYTHON_NAME} LINK_PUBLIC ${_name}
> ${LIB_PYTHON_LIBS})
>     add_library(${MODULE_PYTHON_NAME} MODULE ${MODULE_PYTHON_NAME}Init.cxx)
>     set_target_properties(${MODULE_PYTHON_NAME} PROPERTIES PREFIX "")
>     if(WIN32)
>       set_target_properties(${MODULE_PYTHON_NAME} PROPERTIES SUFFIX ".pyd")
>     endif()
>     set_target_properties(${MODULE_PYTHON_NAME} PROPERTIES NO_SONAME 1)
>     target_link_libraries(${MODULE_PYTHON_NAME} ${LIB_PYTHON_NAME})
>
>  - David
>
> On Tue, Mar 29, 2016 at 9:23 AM, Schuyler Kylstra <
> schuyler.kylstra at kitware.com> wrote:
>
>> Hi devs,
>>
>> I'm working on a VTK 7 based project that I'm trying to wrap in python.
>> I'm stuck at a point where the project builds but the python library cannot
>> be included. I'm doing the following in my CMakeLists.txt file:
>>
>>
>> SET(SRCS
>>   ....
>>   )
>>
>> SET_SOURCE_FILES_PROPERTIES(
>>   <subset of SRCS>
>>   PROPERTIES
>>   WRAP_EXCLUDE 1
>>   WRAP_EXCLUDE_PYTHON 1
>>   )
>>
>> SET(VTK_LIBRARIES
>>
>>    <vtk libraries>
>>    )
>>
>> SET(KIT_PYTHON_LIBRARIES ${VTK_LIBRARIES})
>>
>> SET(LIBRARY_MODE "SHARED")
>>
>>
>> INCLUDE(${VTK_CMAKE_DIR}/vtkWrapPython.cmake)
>> VTK_WRAP_PYTHON3(${LIB_NAME}Python PYTHON_SRCS "${SRCS}")
>> ADD_LIBRARY(${LIB_NAME}PythonD ${LIBRARY_MODE} ${PYTHON_SRCS})
>> ADD_LIBRARY(${LIB_NAME}Python MODULE ${LIB_NAME}PythonInit.cxx)
>>
>> TARGET_LINK_LIBRARIES(${LIB_NAME}PythonD ${LIB_NAME})
>>
>> FOREACH(c ${KIT_PYTHON_LIBRARIES})
>>   TARGET_LINK_LIBRARIES(${LIB_NAME}PythonD ${c}PythonD)
>> ENDFOREACH(c)
>>
>> TARGET_LINK_LIBRARIES(${LIB_NAME}Python ${LIB_NAME}PythonD)
>>
>>
>> As I said before, this all builds without error but when I try to run any
>> python script that includes the library I get the following error:
>>
>>
>> ImportError: dynamic module does not define init function
>>
>> Is there something I need to add to ensure that the init function is
>> created?
>>
>> --
>> Schuyler Kylstra
>>
>
>


-- 
Schuyler Kylstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160330/fea5cea0/attachment.html>

From andrew.amaclean at gmail.com  Thu Mar 31 20:25:01 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 1 Apr 2016 11:25:01 +1100
Subject: [vtk-developers] Removal of a deprecated function.
Message-ID: <CAHDsG9O8bwXFp-dAUXgGHSnGsaDO2B_etqfh2-xBVuBYEJvSMg@mail.gmail.com>

Hi All,

I intend to remove:
 vtkParametricRandomHills::GenerateTheHills (void)

This was deprecated in version 6.2.

AFAIK there is no VTK code using this function anymore.

The removal of this will be consistent with the policy in:
http://www.vtk.org/wp-content/uploads/2015/01/TheVTKSoftwareProcess.pdf

Please let me know in the next few days if anyone really wants this left in
the current master.

Thankyou
   Andrew
-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160401/1fd5efc6/attachment.html>

From dave.demarle at kitware.com  Thu Mar 31 22:51:00 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 31 Mar 2016 22:51:00 -0400
Subject: [vtk-developers] [vtkusers] Removal of a deprecated function.
In-Reply-To: <CAHDsG9O8bwXFp-dAUXgGHSnGsaDO2B_etqfh2-xBVuBYEJvSMg@mail.gmail.com>
References: <CAHDsG9O8bwXFp-dAUXgGHSnGsaDO2B_etqfh2-xBVuBYEJvSMg@mail.gmail.com>
Message-ID: <CANjZAi8_mkFThoFU4xCZNEBZ1ksrrLy7V=mXDOTHALJVrPqkfw@mail.gmail.com>

+1 from me. No code is good code in my opinion.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Mar 31, 2016 at 8:25 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Hi All,
>
> I intend to remove:
>  vtkParametricRandomHills::GenerateTheHills (void)
>
> This was deprecated in version 6.2.
>
> AFAIK there is no VTK code using this function anymore.
>
> The removal of this will be consistent with the policy in:
> http://www.vtk.org/wp-content/uploads/2015/01/TheVTKSoftwareProcess.pdf
>
> Please let me know in the next few days if anyone really wants this left
> in the current master.
>
> Thankyou
>    Andrew
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160331/f2621450/attachment.html>