From jcplatt at dsl.pipex.com  Mon Sep  1 05:55:07 2014
From: jcplatt at dsl.pipex.com (John Platt)
Date: Mon, 1 Sep 2014 10:55:07 +0100
Subject: [vtk-developers] Problem in vtkCleanPolyData copying cell attribute
	data
Message-ID: <2B06DB3238BE47ABB611C60A8889B591@pafec5>

Hi,

I have an access violation in vtkCleanPolyData at the line (version 5.10.1)

    outputCD->CopyData(outPolyData, i, CombinedCellID);

It appears to occur when the input cell data contains both GLOBALIDS & SCALARS. The GLOBALIDS are significant because they are not copied by default.

The output cell data is allocated using the input cell data (2 cell arrays)

    outputCD->CopyAllocate(inputCD);

not the internal vtkCellArray "outPolyData" which will only contain the SCALARS. The crash occurs because the SCALARS are at index = 1 in the input cell data "inputCD" but index = 0 in "outPolyData".

I can't see any easy way to fix this so any help is much appreciated.

Thanks,

John.

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

From brad.king at kitware.com  Tue Sep  2 09:38:21 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 02 Sep 2014 09:38:21 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <20140828150749.1061007759@mail.rogue-research.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
Message-ID: <5405C84D.2010007@kitware.com>

On 08/28/2014 11:07 AM, Sean McBride wrote:
> 1) a 'commits' email list, like other projects.  Where you get an
> email for every merge into master.

We've had one of these since CVS days:

 http://www.vtk.org/mailman/listinfo/vtk-commit

It still works.

-Brad


From dlrdave at aol.com  Tue Sep  2 11:49:52 2014
From: dlrdave at aol.com (David Cole)
Date: Tue, 2 Sep 2014 11:49:52 -0400
Subject: [vtk-developers] InfoVis graph visualization question:
 vtkGraphLayoutView with a "Simple 2D" layout strategy
Message-ID: <8D194DCAB7E4E9B-15CC-2E28@webmail-m269.sysops.aol.com>

Ping...

Anybody know? Just two little itty bitty questions.


-----Original Message-----
From: David Cole <dlrdave at aol.com>
To: vtk-developers <vtk-developers at vtk.org>; jeff.baumes
<jeff.baumes at kitware.com>
Sent: Thu, Jul 31, 2014 2:20 pm
Subject: InfoVis graph visualization question: vtkGraphLayoutView with
a "Simple 2D" layout strategy


This VTK wiki example:
http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/XGMLReader

Yields this "different rendering" test failure on my dashboard machine:
http://open.cdash.org/testDetails.php?test=271695203&build=3430870

The graph structure looks the same, and the visual is roughly
equivalent, but the expected image clearly shows a perfectly square
glyph at each graph node. In my test image, the graph nodes look like
they vary from circle to square to polygons in between...

What determines the shape of the node glyph in a vtkGraphLayoutView
with a "Simple 2D" layout strategy? And would the shape difference
account entirely for the slight offset and angle between expected image
and test image...?


Thanks,
David C.


From berk.geveci at kitware.com  Tue Sep  2 19:56:15 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Tue, 2 Sep 2014 19:56:15 -0400
Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpVyP8htVXVQOubkgknTEi8=HPd8wZiatDsy06XtQ7U2pA@mail.gmail.com>
References: <CAE32kpX_syzWG=BJRzY2=MoB=wy2eBB20j7qEZC_fWQzxj57rw@mail.gmail.com>
 <CAE32kpVyP8htVXVQOubkgknTEi8=HPd8wZiatDsy06XtQ7U2pA@mail.gmail.com>
Message-ID: <CAE32kpX1Wr2Z=72BYU1jDf5szo-qam6e_FjpMMtq8u28RVaeog@mail.gmail.com>

OK folks. October 2nd it is. We'll shoot for 9am-5pm EDT. So far, I
received confirmation from Bill, Dave C.,  Sean and Will. There will be a
few us from Kitware also. If you plan on attending, please let me know off
list - please let me know if you will attend in person or via Google
Hangout.


On Thu, Aug 28, 2014 at 10:21 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Several people indicated a preference for October. How about October 2nd?
>
> Best,
> -berk
>
>
> On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> I propose a hack-a-ton to reduce the number of open issues in the bug
>> tracker. It is like a yard that hasn't been mowed and weeded the whole
>> summer. I propose a full day hack-a-ton. We can host some folks here at
>> Kitware and others can join through a Google Hangout. I propose one in
>> September. What do you think? Interested parties please send me an e-mail
>> off the list with your preferred dates.
>>
>> This will have to be the first in a series. There are a lot of issues to
>> go over.
>>
>> Best,
>> -berk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140902/5d707cb0/attachment-0001.html>

From bill.lorensen at gmail.com  Tue Sep  2 20:44:40 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Tue, 2 Sep 2014 20:44:40 -0400
Subject: [vtk-developers] [vtkusers] Proposal: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpX1Wr2Z=72BYU1jDf5szo-qam6e_FjpMMtq8u28RVaeog@mail.gmail.com>
References: <CAE32kpX_syzWG=BJRzY2=MoB=wy2eBB20j7qEZC_fWQzxj57rw@mail.gmail.com>
 <CAE32kpVyP8htVXVQOubkgknTEi8=HPd8wZiatDsy06XtQ7U2pA@mail.gmail.com>
 <CAE32kpX1Wr2Z=72BYU1jDf5szo-qam6e_FjpMMtq8u28RVaeog@mail.gmail.com>
Message-ID: <CADZJ4hMWpf8sMD0z672gyVyUGbX4nA+DWyxjO7NnptpU6B4qOg@mail.gmail.com>

In person
On Sep 2, 2014 7:56 PM, "Berk Geveci" <berk.geveci at kitware.com> wrote:

> OK folks. October 2nd it is. We'll shoot for 9am-5pm EDT. So far, I
> received confirmation from Bill, Dave C.,  Sean and Will. There will be a
> few us from Kitware also. If you plan on attending, please let me know off
> list - please let me know if you will attend in person or via Google
> Hangout.
>
>
> On Thu, Aug 28, 2014 at 10:21 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Several people indicated a preference for October. How about October 2nd?
>>
>> Best,
>> -berk
>>
>>
>> On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> Hi folks,
>>>
>>> I propose a hack-a-ton to reduce the number of open issues in the bug
>>> tracker. It is like a yard that hasn't been mowed and weeded the whole
>>> summer. I propose a full day hack-a-ton. We can host some folks here at
>>> Kitware and others can join through a Google Hangout. I propose one in
>>> September. What do you think? Interested parties please send me an e-mail
>>> off the list with your preferred dates.
>>>
>>> This will have to be the first in a series. There are a lot of issues to
>>> go over.
>>>
>>> Best,
>>> -berk
>>>
>>
>>
>
> _______________________________________________
> 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
>
> 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/20140902/dda984e6/attachment.html>

From dave.demarle at kitware.com  Wed Sep  3 10:33:19 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 3 Sep 2014 10:33:19 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <5405C84D.2010007@kitware.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
Message-ID: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>

One thing we can hope to do better next time to not alienate the old timers
(including myself).

* The transition from CVS to today's gerrit workflow was necessarily long,
but there were frequent adjustments along the way as we learned and built
up the infrastructure. Every change in the process meant retraining all of
the (self interested and busy) contributors.

Whatever our end goal is with the new infrastructure - we need to work
harder to minimize the number of changes to the commit process, to keep the
contribution process as dead simple as it can be, and to describe the
mechanics clearly and loudly.


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


On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:

> On 08/28/2014 11:07 AM, Sean McBride wrote:
> > 1) a 'commits' email list, like other projects.  Where you get an
> > email for every merge into master.
>
> We've had one of these since CVS days:
>
>  http://www.vtk.org/mailman/listinfo/vtk-commit
>
> It still works.
>
> -Brad
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140903/288610e7/attachment.html>

From dave.demarle at kitware.com  Wed Sep  3 10:35:59 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 3 Sep 2014 10:35:59 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
Message-ID: <CANjZAi9sDC+zr6WWzUmVDhAVThL4gNgh9fUOcecW4uewNhr5AA@mail.gmail.com>

The idea of having gerrit automatically add reviewers is a small tweak that
will improve things greatly.

Can we have a simple gerrit side hook that adds the previous 3 authors of
all touched files?


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


On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> One thing we can hope to do better next time to not alienate the old
> timers (including myself).
>
> * The transition from CVS to today's gerrit workflow was necessarily long,
> but there were frequent adjustments along the way as we learned and built
> up the infrastructure. Every change in the process meant retraining all of
> the (self interested and busy) contributors.
>
> Whatever our end goal is with the new infrastructure - we need to work
> harder to minimize the number of changes to the commit process, to keep the
> contribution process as dead simple as it can be, and to describe the
> mechanics clearly and loudly.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>
>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>> > 1) a 'commits' email list, like other projects.  Where you get an
>> > email for every merge into master.
>>
>> We've had one of these since CVS days:
>>
>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>
>> It still works.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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/20140903/7c2e9eff/attachment.html>

From inglis.dl at gmail.com  Wed Sep  3 10:56:28 2014
From: inglis.dl at gmail.com (Dean Inglis)
Date: Wed, 3 Sep 2014 10:56:28 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
Message-ID: <CABX+von6fGiZn0bfk4W57vmgEK6utNKOT3BuvKfeySgyb=4f7A@mail.gmail.com>

I've been following this thread for a while and would like to add that
I too found the gerritt workflow discouraging enough that I (and fellow
work colleagues) have decided
to maintain a privately forked VTK repo rather than contributing back to
the community.  I would echo
most of the sentiments already expressed by D. DeMarle, D. Gobbi, and J.B.
Although I do miss
the old CVS workflow days, and I have come to embrace github, I'll be
holding back on contributing
to VTK until the commit process is simplified, more responsive, and
expedient.

best to all of you,
Dean


On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> One thing we can hope to do better next time to not alienate the old
> timers (including myself).
>
> * The transition from CVS to today's gerrit workflow was necessarily long,
> but there were frequent adjustments along the way as we learned and built
> up the infrastructure. Every change in the process meant retraining all of
> the (self interested and busy) contributors.
>
> Whatever our end goal is with the new infrastructure - we need to work
> harder to minimize the number of changes to the commit process, to keep the
> contribution process as dead simple as it can be, and to describe the
> mechanics clearly and loudly.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>
>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>> > 1) a 'commits' email list, like other projects.  Where you get an
>> > email for every merge into master.
>>
>> We've had one of these since CVS days:
>>
>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>
>> It still works.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>
> 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/20140903/6d37c079/attachment-0001.html>

From matt.mccormick at kitware.com  Wed Sep  3 12:21:16 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 3 Sep 2014 12:21:16 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi9sDC+zr6WWzUmVDhAVThL4gNgh9fUOcecW4uewNhr5AA@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
 <CANjZAi9sDC+zr6WWzUmVDhAVThL4gNgh9fUOcecW4uewNhr5AA@mail.gmail.com>
Message-ID: <CALzTN-SBq6sJ2p0mnpu_FYxkZHM7KZyi+kmfvDm+uxjCBV6BSw@mail.gmail.com>

Here is a script [1] for reference I wrote a while ago (have not used
recently), that will select potential reviewers and add them to a
Gerrit patch via the command line.  It uses recent changes (within the
last five years) and sorts by the number of lines changed to select
reviewers. It is amazing how many people tweak and improve a file over
its lifetime, especially for a project like VTK.

HTH,
Matt

[1] https://gist.github.com/thewtex/674093


On Wed, Sep 3, 2014 at 10:35 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> The idea of having gerrit automatically add reviewers is a small tweak that
> will improve things greatly.
>
> Can we have a simple gerrit side hook that adds the previous 3 authors of
> all touched files?
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>>
>> One thing we can hope to do better next time to not alienate the old
>> timers (including myself).
>>
>> * The transition from CVS to today's gerrit workflow was necessarily long,
>> but there were frequent adjustments along the way as we learned and built up
>> the infrastructure. Every change in the process meant retraining all of the
>> (self interested and busy) contributors.
>>
>> Whatever our end goal is with the new infrastructure - we need to work
>> harder to minimize the number of changes to the commit process, to keep the
>> contribution process as dead simple as it can be, and to describe the
>> mechanics clearly and loudly.
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>>
>> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>>>
>>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>>> > 1) a 'commits' email list, like other projects.  Where you get an
>>> > email for every merge into master.
>>>
>>> We've had one of these since CVS days:
>>>
>>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>>
>>> It still works.
>>>
>>> -Brad
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> 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
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From david.gobbi at gmail.com  Thu Sep  4 19:33:14 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 4 Sep 2014 17:33:14 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
Message-ID: <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>

I've run into very odd behavior when I use Ambient and Diffuse
coefficients in combination with vtkDataSetMapper.  This is with
VTK master.

My property is set up like this, with AmbientColor="red" and
DiffuseColor="green".

  property->SetAmbient(0.51);
  property->SetDiffuse(0.49);
  property->SetAmbientColor(1.0, 0.0, 0.0);
  property->SetDiffuseColor(0.0, 1.0, 0.0);

My mapper, however, is set to MapScalars, so it should ignore the
AmbientColor and the DiffuseColor, and use the scalars instead:

  mapper->SetColorModeToMapScalars();
  mapper->SetLookupTable(table);
  mapper->UseLookupTableScalarRangeOn();

The lookup table is a simple greyscale lookup table, and my polydata
has scalars.  So I would expect my data to be rendered in greyscale.
But it's not, it's rendered mint green!  See the left side of the
attached image.

I tried a different scalar mapping pathway:

  mapper->InterpolateScalarsBeforeMappingOn();

The result was totally different, now it's greyscale with ambient
lighting, instead of the mix of ambient and diffuse lighting that I
requested (see right of attached image).


If I slightly modify the ambient and diffuse coefficients, the result
is, once again, completely unexpected:

  property->SetAmbient(0.49);  // was 0.51
  property->SetDiffuse(0.51);  // was 0.49

Now everything is red.  In the second attached image, the left shows
InterpolateScalarsBeforeMappingOff() and the right shows On().


Anyone know what is going on here?  Everything behaves just find if I
set either the Ambient or the Diffuse coefficient to zero.  But when I
use them together, VTK goes crazy.

 - David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapscalars1.jpg
Type: image/jpeg
Size: 74282 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140904/eb4cbfaa/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapscalars2.jpg
Type: image/jpeg
Size: 75610 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140904/eb4cbfaa/attachment-0003.jpg>

From dave.demarle at kitware.com  Thu Sep  4 22:31:11 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 4 Sep 2014 22:31:11 -0400
Subject: [vtk-developers] VTK code review / testing / integration
	workflow
In-Reply-To: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com>
References: <CAE32kpXxGwXwdTD4CTUiYZDAHxvB-4q1U7RDpcWWyd0C6f3CYw@mail.gmail.com>
 <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com>
Message-ID: <CANjZAi8xEjBM3ui2nR6Y954uzOJ+pOiCL4VRfeLHv8VAnC9B5A@mail.gmail.com>

On Sat, Aug 23, 2014 at 9:04 PM, David Thompson <david.thompson at kitware.com>
wrote:

> <snip>
> - It would be nice to have tighter integration with the release process
> and issue tracking so that reports of features added and bugs fixed could be


+1

The bugtracker is only loosely integrated into the process. I'ld like it to
be tighter too so that hopefully the number of bugs in the tracker will be
limited and always recent.



> generated. I think what we do of that is mostly by hand now, isn't it?
>
>
Yes mostly by hand.

* before a release we scan the bug tracker and try to address the most
important reports.

* during the release candidate cycle I use the bug tracker and the "found
in" "fixed in" fields to keep track of the bugs that need to be fixed
before the final release

We keep track of what changed in the release entirely outside of the bug
tracker.

* I send an email to all authors and ask them to summarize their changes
 to make up the release notes so we know overall what happened.

* Then I run $VTKSRC//Utilities/Maintenance/sematicDiffVersion.py to make
the API diff report so that we have a list of the added / newly legacy'd /
 and removed items.
See: http://www.vtk.org/Wiki/VTK/API_Changes_6_0_0_to_6_1_0







> Suggested Requirements:-)
>
> - Review system comments should be Markdown or rST or something easily
> presented as HTML which can include links -- at least to the VTK wiki and
> bug tracker, if nothing else. It would be really nice if pull requests
> could effectively become parts of a wiki page or blog so that we could
> curate user-guide-style documentation instead of just doxygen reference
> docs. Not that every topic would have to become part of a user's guide, but
> it should be easy to pull topic info into a user's guide.
>
> - An anti-requirement: Less e-mail spam when (1) a topic includes multiple
> commits and/or (2) automated testing completes. For instance, I can think
> of one topic I'm a reviewer on that has 40-something commits. There are 16
> changesets and reviewers get 1 per commit per
> changeset-the-commit-is-modified.
>
>         2?,
>         David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140904/7a58da55/attachment.html>

From berk.geveci at kitware.com  Fri Sep  5 07:27:52 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Fri, 5 Sep 2014 07:27:52 -0400
Subject: [vtk-developers] VTK code review / testing / integration
	workflow
In-Reply-To: <CANjZAi8xEjBM3ui2nR6Y954uzOJ+pOiCL4VRfeLHv8VAnC9B5A@mail.gmail.com>
References: <CAE32kpXxGwXwdTD4CTUiYZDAHxvB-4q1U7RDpcWWyd0C6f3CYw@mail.gmail.com>
 <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com>
 <CANjZAi8xEjBM3ui2nR6Y954uzOJ+pOiCL4VRfeLHv8VAnC9B5A@mail.gmail.com>
Message-ID: <CAE32kpWAZkmWB22YBQWE+=ciN7FNUaCDQO7PFZ8CAAiPYWK8Gw@mail.gmail.com>

Hi guys,

To close the loop on the tool side of things, we will be evaluating Gitlab
for another project at Kitware. After that, I'll revive the tool
discussion. From what I heard so far, it sounds like we will settle on
Github or Gitlab (or something similar).

Best,
-berk



On Thu, Sep 4, 2014 at 10:31 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

>
> On Sat, Aug 23, 2014 at 9:04 PM, David Thompson <
> david.thompson at kitware.com> wrote:
>
>> <snip>
>> - It would be nice to have tighter integration with the release process
>> and issue tracking so that reports of features added and bugs fixed could be
>
>
> +1
>
> The bugtracker is only loosely integrated into the process. I'ld like it
> to be tighter too so that hopefully the number of bugs in the tracker will
> be limited and always recent.
>
>
>
>> generated. I think what we do of that is mostly by hand now, isn't it?
>>
>>
> Yes mostly by hand.
>
> * before a release we scan the bug tracker and try to address the most
> important reports.
>
> * during the release candidate cycle I use the bug tracker and the "found
> in" "fixed in" fields to keep track of the bugs that need to be fixed
> before the final release
>
> We keep track of what changed in the release entirely outside of the bug
> tracker.
>
> * I send an email to all authors and ask them to summarize their changes
>  to make up the release notes so we know overall what happened.
>
> * Then I run $VTKSRC//Utilities/Maintenance/sematicDiffVersion.py to make
> the API diff report so that we have a list of the added / newly legacy'd /
>  and removed items.
> See: http://www.vtk.org/Wiki/VTK/API_Changes_6_0_0_to_6_1_0
>
>
>
>
>
>
>
>> Suggested Requirements:-)
>>
>> - Review system comments should be Markdown or rST or something easily
>> presented as HTML which can include links -- at least to the VTK wiki and
>> bug tracker, if nothing else. It would be really nice if pull requests
>> could effectively become parts of a wiki page or blog so that we could
>> curate user-guide-style documentation instead of just doxygen reference
>> docs. Not that every topic would have to become part of a user's guide, but
>> it should be easy to pull topic info into a user's guide.
>>
>> - An anti-requirement: Less e-mail spam when (1) a topic includes
>> multiple commits and/or (2) automated testing completes. For instance, I
>> can think of one topic I'm a reviewer on that has 40-something commits.
>> There are 16 changesets and reviewers get 1 per commit per
>> changeset-the-commit-is-modified.
>>
>>         2?,
>>         David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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/20140905/e284596a/attachment.html>

From johnrim20 at gmail.com  Fri Sep  5 07:55:11 2014
From: johnrim20 at gmail.com (JohnR)
Date: Fri, 5 Sep 2014 04:55:11 -0700 (PDT)
Subject: [vtk-developers] How to do Next and Prevous frame in VTK python
Message-ID: <1409918111678-5728585.post@n5.nabble.com>

Hello,

I am doing a program  which should able to do
Next frame and previous frame on button clicks. I have added
a sphere vtk object in render window as an actor. Don't understand
frame functionality and how to do previous and Next frame. I am able to do
set positions but I don't think it can achieve the frame functionality out 
of this
could anyone please help me or share a sample code for this?
Please note my code below

I am using Tkinter python with VTK

[code]

    def sphere_render(cone_Obj,obj_renwin):

        
        obj_renwin.sphereSource = vtk.vtkSphereSource()              
        obj_renwin.sphereSource.SetRadius(.5)    
        obj_renwin.actor = vtk.vtkActor()
        obj_renwin.mapper = vtk.vtkPolyDataMapper()
       
obj_renwin.mapper.SetInputConnection(obj_renwin.sphereSource.GetOutputPort())
        obj_renwin.actor.SetMapper(obj_renwin.mapper)       
        obj_renwin.prop = obj_renwin.actor.GetProperty()        
        global actor_Status
        actor_Status=obj_renwin.add_actors(obj_renwin.actor)        
        obj_renwin.renwin.Render()
        return obj_renwin.actor

   
    def do_Next_Frame(self,obj_renwin):

       obj_renwin.actor.SetPosition(0, 1, 0)


    def do_Prv_Frame(self,obj_renwin):

        obj_renwin.actor.SetPosition(0.0, 0.0, 0.0)


[/code]



--
View this message in context: http://vtk.1045678.n5.nabble.com/How-to-do-Next-and-Prevous-frame-in-VTK-python-tp5728585.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From joachim.pouderoux at kitware.com  Mon Sep  8 08:42:34 2014
From: joachim.pouderoux at kitware.com (Joachim Pouderoux)
Date: Mon, 8 Sep 2014 14:42:34 +0200
Subject: [vtk-developers] ANN: ParaView Training Course in Paris, France,
	October 14-15, 2014
Message-ID: <CACJ=gThe52uEvQF47K0nwhKVO+wqjVmZ3hzcJt77bRFO8Lp0ow@mail.gmail.com>

Hello,

Kitware will be holding a 2-day ParaView course on October 14 and 15th,
2014 at Universit? Pierre et Marie Curie, Paris, France.

The specificity of this training is that it will take place in a virtual
reality room fitted with a powerwall.

Please visit our web site for more information and registration details at
either:

http://training.kitware.fr/browse/71 (in English)
or
http://formations.kitware.fr/browse/71 (in French)

Note that the course might be taught in English. If you have any question,
please contact us at formations at http://www.kitware.fr

Thank you,

*Joachim Pouderoux*

*PhD, Technical Expert*
*Kitware SAS <http://www.kitware.fr>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140908/7393ad59/attachment.html>

From david.gobbi at gmail.com  Mon Sep  8 16:55:44 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 8 Sep 2014 14:55:44 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
Message-ID: <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>

Any comments on the "scalar color mapping" problem that I sent to the
list last week?

 - David


On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> I've run into very odd behavior when I use Ambient and Diffuse
> coefficients in combination with vtkDataSetMapper.  This is with
> VTK master.
[ snip ]

From utkarsh.ayachit at kitware.com  Mon Sep  8 19:17:12 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 8 Sep 2014 19:17:12 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
Message-ID: <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>

This sounds familiar.

Can you try reverting the following commit and see if that makes any difference:

commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
Date:   Fri Jul 18 15:30:37 2014 -0400

    BUG #14828: Keep surface color from interacting with scalar color.

    When using scalar coloring, if vtkScalarsToColorsPainter decided to use
    a texture for mapping the scalars to colors, we ended up with the
    surface color bleeding through the texture. This commit ensures that
    such bleeding is avoided.

    We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
    GL_REPLACE), since that results in the diffuse highlights being lost.
    By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
    the same lighting/coloring path as we would when not using the texture
    for scalar coloring.

    Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988


Utkarsh

On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Any comments on the "scalar color mapping" problem that I sent to the
> list last week?
>
>  - David
>
>
> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> I've run into very odd behavior when I use Ambient and Diffuse
>> coefficients in combination with vtkDataSetMapper.  This is with
>> VTK master.
> [ snip ]
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From david.gobbi at gmail.com  Mon Sep  8 20:15:57 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 8 Sep 2014 18:15:57 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
Message-ID: <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>

Hi Utkarsh,

Thanks for the reply.  If I use this:

  mapper->InterpolateScalarsBeforeMappingOff();

then the result is exactly the same as it was before I reverted that commit.


If I use this:

  mapper->InterpolateScalarsBeforeMappingOn();

then the result looks like the attached image, i.e. like it did in my previous
email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
I reverse these I don't get the greyscale ambient lighting like in the
right side
of the image from my previous email.


Still, I don't get what I expect unless I set one of either the ambient or the
diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
result.

 - David


On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> This sounds familiar.
>
> Can you try reverting the following commit and see if that makes any difference:
>
> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
> Date:   Fri Jul 18 15:30:37 2014 -0400
>
>     BUG #14828: Keep surface color from interacting with scalar color.
>
>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>     a texture for mapping the scalars to colors, we ended up with the
>     surface color bleeding through the texture. This commit ensures that
>     such bleeding is avoided.
>
>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>     GL_REPLACE), since that results in the diffuse highlights being lost.
>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>     the same lighting/coloring path as we would when not using the texture
>     for scalar coloring.
>
>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>
>
> Utkarsh
>
> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Any comments on the "scalar color mapping" problem that I sent to the
>> list last week?
>>
>>  - David
>>
>>
>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> I've run into very odd behavior when I use Ambient and Diffuse
>>> coefficients in combination with vtkDataSetMapper.  This is with
>>> VTK master.
>> [ snip ]
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapscalars3.jpg
Type: image/jpeg
Size: 38858 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140908/1e6df0b1/attachment-0001.jpg>

From utkarsh.ayachit at kitware.com  Tue Sep  9 10:44:26 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 10:44:26 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
Message-ID: <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>

David,

Try the attached patch and then set
SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
ScalarMaterialMode is the thing here. When set to
SetScalarMaterialModeToDefault(), which is the default, it determines
which material component should track the scalar color based on which
coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
The patch fixes an issue where the painter was not respecting the
material mode set on the mapper.

Utkarsh

On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Utkarsh,
>
> Thanks for the reply.  If I use this:
>
>   mapper->InterpolateScalarsBeforeMappingOff();
>
> then the result is exactly the same as it was before I reverted that commit.
>
>
> If I use this:
>
>   mapper->InterpolateScalarsBeforeMappingOn();
>
> then the result looks like the attached image, i.e. like it did in my previous
> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
> I reverse these I don't get the greyscale ambient lighting like in the
> right side
> of the image from my previous email.
>
>
> Still, I don't get what I expect unless I set one of either the ambient or the
> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
> result.
>
>  - David
>
>
> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> This sounds familiar.
>>
>> Can you try reverting the following commit and see if that makes any difference:
>>
>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>
>>     BUG #14828: Keep surface color from interacting with scalar color.
>>
>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>     a texture for mapping the scalars to colors, we ended up with the
>>     surface color bleeding through the texture. This commit ensures that
>>     such bleeding is avoided.
>>
>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>     the same lighting/coloring path as we would when not using the texture
>>     for scalar coloring.
>>
>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>
>>
>> Utkarsh
>>
>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Any comments on the "scalar color mapping" problem that I sent to the
>>> list last week?
>>>
>>>  - David
>>>
>>>
>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>> VTK master.
>>> [ snip ]
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>

From david.gobbi at gmail.com  Tue Sep  9 10:53:32 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 9 Sep 2014 08:53:32 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
Message-ID: <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>

Hi Utkarsh,

The "attached patch" seems to be missing.

 - David

On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> David,
>
> Try the attached patch and then set
> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
> ScalarMaterialMode is the thing here. When set to
> SetScalarMaterialModeToDefault(), which is the default, it determines
> which material component should track the scalar color based on which
> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
> The patch fixes an issue where the painter was not respecting the
> material mode set on the mapper.
>
> Utkarsh
>
> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Utkarsh,
>>
>> Thanks for the reply.  If I use this:
>>
>>   mapper->InterpolateScalarsBeforeMappingOff();
>>
>> then the result is exactly the same as it was before I reverted that commit.
>>
>>
>> If I use this:
>>
>>   mapper->InterpolateScalarsBeforeMappingOn();
>>
>> then the result looks like the attached image, i.e. like it did in my previous
>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>> I reverse these I don't get the greyscale ambient lighting like in the
>> right side
>> of the image from my previous email.
>>
>>
>> Still, I don't get what I expect unless I set one of either the ambient or the
>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>> result.
>>
>>  - David
>>
>>
>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> This sounds familiar.
>>>
>>> Can you try reverting the following commit and see if that makes any difference:
>>>
>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>
>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>
>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>     a texture for mapping the scalars to colors, we ended up with the
>>>     surface color bleeding through the texture. This commit ensures that
>>>     such bleeding is avoided.
>>>
>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>     the same lighting/coloring path as we would when not using the texture
>>>     for scalar coloring.
>>>
>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>
>>>
>>> Utkarsh
>>>
>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>> list last week?
>>>>
>>>>  - David
>>>>
>>>>
>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>> VTK master.
>>>> [ snip ]
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>

From utkarsh.ayachit at kitware.com  Tue Sep  9 10:56:16 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 10:56:16 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
Message-ID: <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>

Doh! Here you go.

On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Utkarsh,
>
> The "attached patch" seems to be missing.
>
>  - David
>
> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> David,
>>
>> Try the attached patch and then set
>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>> ScalarMaterialMode is the thing here. When set to
>> SetScalarMaterialModeToDefault(), which is the default, it determines
>> which material component should track the scalar color based on which
>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>> The patch fixes an issue where the painter was not respecting the
>> material mode set on the mapper.
>>
>> Utkarsh
>>
>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Hi Utkarsh,
>>>
>>> Thanks for the reply.  If I use this:
>>>
>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>
>>> then the result is exactly the same as it was before I reverted that commit.
>>>
>>>
>>> If I use this:
>>>
>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>
>>> then the result looks like the attached image, i.e. like it did in my previous
>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>> I reverse these I don't get the greyscale ambient lighting like in the
>>> right side
>>> of the image from my previous email.
>>>
>>>
>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>> result.
>>>
>>>  - David
>>>
>>>
>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> This sounds familiar.
>>>>
>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>
>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>
>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>
>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>     surface color bleeding through the texture. This commit ensures that
>>>>     such bleeding is avoided.
>>>>
>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>     the same lighting/coloring path as we would when not using the texture
>>>>     for scalar coloring.
>>>>
>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>
>>>>
>>>> Utkarsh
>>>>
>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>> list last week?
>>>>>
>>>>>  - David
>>>>>
>>>>>
>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>> VTK master.
>>>>> [ snip ]
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix.patch
Type: text/x-patch
Size: 723 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/d50411ee/attachment.bin>

From david.gobbi at gmail.com  Tue Sep  9 11:11:39 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 9 Sep 2014 09:11:39 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
Message-ID: <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>

I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
patch, but it had no effect.  The results were exactly the same as in
my first email.

I'll have to look through the code to figure out what the intended behaviour is.

 - David

On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Doh! Here you go.
>
> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Utkarsh,
>>
>> The "attached patch" seems to be missing.
>>
>>  - David
>>
>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> David,
>>>
>>> Try the attached patch and then set
>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>> ScalarMaterialMode is the thing here. When set to
>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>> which material component should track the scalar color based on which
>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>> The patch fixes an issue where the painter was not respecting the
>>> material mode set on the mapper.
>>>
>>> Utkarsh
>>>
>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> Hi Utkarsh,
>>>>
>>>> Thanks for the reply.  If I use this:
>>>>
>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>
>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>
>>>>
>>>> If I use this:
>>>>
>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>
>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>> right side
>>>> of the image from my previous email.
>>>>
>>>>
>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>> result.
>>>>
>>>>  - David
>>>>
>>>>
>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>> This sounds familiar.
>>>>>
>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>
>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>
>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>
>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>     such bleeding is avoided.
>>>>>
>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>     for scalar coloring.
>>>>>
>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>
>>>>>
>>>>> Utkarsh
>>>>>
>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>> list last week?
>>>>>>
>>>>>>  - David
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>> VTK master.
>>>>>> [ snip ]
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>

From utkarsh.ayachit at kitware.com  Tue Sep  9 11:13:48 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 11:13:48 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
Message-ID: <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>

Here's my test script. With the patch applied, I don't see the ambient
and diffuse colors bleed in anymore.

On Tue, Sep 9, 2014 at 11:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
> patch, but it had no effect.  The results were exactly the same as in
> my first email.
>
> I'll have to look through the code to figure out what the intended behaviour is.
>
>  - David
>
> On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Doh! Here you go.
>>
>> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Hi Utkarsh,
>>>
>>> The "attached patch" seems to be missing.
>>>
>>>  - David
>>>
>>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> David,
>>>>
>>>> Try the attached patch and then set
>>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>>> ScalarMaterialMode is the thing here. When set to
>>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>>> which material component should track the scalar color based on which
>>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>>> The patch fixes an issue where the painter was not respecting the
>>>> material mode set on the mapper.
>>>>
>>>> Utkarsh
>>>>
>>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Hi Utkarsh,
>>>>>
>>>>> Thanks for the reply.  If I use this:
>>>>>
>>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>>
>>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>>
>>>>>
>>>>> If I use this:
>>>>>
>>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>>
>>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>>> right side
>>>>> of the image from my previous email.
>>>>>
>>>>>
>>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>>> result.
>>>>>
>>>>>  - David
>>>>>
>>>>>
>>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>> This sounds familiar.
>>>>>>
>>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>>
>>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>>
>>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>>
>>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>>     such bleeding is avoided.
>>>>>>
>>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>>     for scalar coloring.
>>>>>>
>>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>>
>>>>>>
>>>>>> Utkarsh
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>>> list last week?
>>>>>>>
>>>>>>>  - David
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>>> VTK master.
>>>>>>> [ snip ]
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScalarColors.py
Type: text/x-python
Size: 2646 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/ec89321a/attachment-0001.py>

From utkarsh.ayachit at kitware.com  Tue Sep  9 11:14:26 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 11:14:26 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
 <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
Message-ID: <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>

BTW, in my script, you can hit "t" to swap the ambient/diffuse coefficients.

On Tue, Sep 9, 2014 at 11:13 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Here's my test script. With the patch applied, I don't see the ambient
> and diffuse colors bleed in anymore.
>
> On Tue, Sep 9, 2014 at 11:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
>> patch, but it had no effect.  The results were exactly the same as in
>> my first email.
>>
>> I'll have to look through the code to figure out what the intended behaviour is.
>>
>>  - David
>>
>> On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> Doh! Here you go.
>>>
>>> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> Hi Utkarsh,
>>>>
>>>> The "attached patch" seems to be missing.
>>>>
>>>>  - David
>>>>
>>>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>> David,
>>>>>
>>>>> Try the attached patch and then set
>>>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>>>> ScalarMaterialMode is the thing here. When set to
>>>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>>>> which material component should track the scalar color based on which
>>>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>>>> The patch fixes an issue where the painter was not respecting the
>>>>> material mode set on the mapper.
>>>>>
>>>>> Utkarsh
>>>>>
>>>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> Hi Utkarsh,
>>>>>>
>>>>>> Thanks for the reply.  If I use this:
>>>>>>
>>>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>>>
>>>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>>>
>>>>>>
>>>>>> If I use this:
>>>>>>
>>>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>>>
>>>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>>>> right side
>>>>>> of the image from my previous email.
>>>>>>
>>>>>>
>>>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>>>> result.
>>>>>>
>>>>>>  - David
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>>> This sounds familiar.
>>>>>>>
>>>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>>>
>>>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>>>
>>>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>>>
>>>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>>>     such bleeding is avoided.
>>>>>>>
>>>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>>>     for scalar coloring.
>>>>>>>
>>>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>>>
>>>>>>>
>>>>>>> Utkarsh
>>>>>>>
>>>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>>>> list last week?
>>>>>>>>
>>>>>>>>  - David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>>>> VTK master.
>>>>>>>> [ snip ]
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>

From marcus.hanwell at kitware.com  Tue Sep  9 13:23:09 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 13:23:09 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS ...)
Message-ID: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>

Hi,

Moving this discussion from
http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
was saying I do not see precisely what you see, the repeated calls
seem to work for me locally. I would not expect the call without
COMPONENTS to work, and am not sure we should support calling with and
without COMPONENTS.

I have a minimal CMake script,

cmake_minimum_required(VERSION 3.0)

find_package(VTK COMPONENTS vtkChartsCore)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK COMPONENTS vtkCommonCore)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK COMPONENTS vtkCommonMath)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK COMPONENTS vtkChartsCore)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

This results in the output,

$ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
-- LIBS: vtkCommonCore;vtksys
-- LIBS: vtkCommonMath;vtkCommonCore;vtksys
-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
-- Configuring done
-- Generating done
-- Build files have been written to: /home/marcus/build/vtkcomponents

As far as I can see this gives the libraries one would expect, i.e.
vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
final one is incorrect but I am not sure of the value in supporting
mixed COMPONENTS and non-components versions of find_package.

Let me know if there is something I am missing, is this possibly with
an older version of VTK (I am testing with master).

Marcus

From marcus.hanwell at kitware.com  Tue Sep  9 13:53:14 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 13:53:14 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
Message-ID: <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>

Adding you both to CC in case you aren't subscribed, it might also be
worth appending NO_MODULE to the calls to ensure find modules aren't
used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
contains advice I added, but didn't specifically cover multiple calls.
Including the use file, or setting the DIRECTORY property will of
course cause issues if you are not using separate directory scopes for
each target.

On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Hi,
>
> Moving this discussion from
> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
> was saying I do not see precisely what you see, the repeated calls
> seem to work for me locally. I would not expect the call without
> COMPONENTS to work, and am not sure we should support calling with and
> without COMPONENTS.
>
> I have a minimal CMake script,
>
> cmake_minimum_required(VERSION 3.0)
>
> find_package(VTK COMPONENTS vtkChartsCore)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK COMPONENTS vtkCommonCore)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK COMPONENTS vtkCommonMath)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK COMPONENTS vtkChartsCore)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> This results in the output,
>
> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
> -- The C compiler identification is GNU 4.9.1
> -- The CXX compiler identification is GNU 4.9.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
> -- LIBS: vtkCommonCore;vtksys
> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/marcus/build/vtkcomponents
>
> As far as I can see this gives the libraries one would expect, i.e.
> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
> final one is incorrect but I am not sure of the value in supporting
> mixed COMPONENTS and non-components versions of find_package.
>
> Let me know if there is something I am missing, is this possibly with
> an older version of VTK (I am testing with master).
>
> Marcus

From marcus.hanwell at kitware.com  Tue Sep  9 14:18:11 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 14:18:11 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
Message-ID: <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>

Pushing this a little further, to see if we can build executables in
the same directory with multiple calls, the following worked for me
locally,

cmake_minimum_required(VERSION 3.0)

find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
message(STATUS "LIBS: ${VTK_LIBRARIES}")
message(STATUS "DEFS: ${VTK_DEFINITIONS}")
add_executable(testexe test.cxx)
set_property(TARGET testexe APPEND
  PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
set_property(TARGET testexe APPEND
  PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
target_link_libraries(testexe ${VTK_LIBRARIES})

find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
message(STATUS "LIBS: ${VTK_LIBRARIES}")
message(STATUS "DEFS: ${VTK_DEFINITIONS}")
add_executable(testexe2 test2.cxx)
set_property(TARGET testexe2 APPEND
  PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
set_property(TARGET testexe2 APPEND
  PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
target_link_libraries(testexe2 ${VTK_LIBRARIES})

Producing the output,

-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
-- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
-- LIBS: vtkCommonCore;vtksys
-- DEFS:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/marcus/build/vtkcomponents

So the definitions were empty, as you would hope, in the second call,
the mains were very simple instantiating a vtkRenderWindow in the
first which resulted in a vtkXOpenGLRenderWindow class being
instantiated as the overrides kicked in for that target. Most projects
I know of that make multiple calls tend to use directories for each
target, and make the calls in sibling directories, but it looks like
you should be able to call it multiple times in the same scope (on
Linux with VTK master at least).

On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Adding you both to CC in case you aren't subscribed, it might also be
> worth appending NO_MODULE to the calls to ensure find modules aren't
> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
> contains advice I added, but didn't specifically cover multiple calls.
> Including the use file, or setting the DIRECTORY property will of
> course cause issues if you are not using separate directory scopes for
> each target.
>
> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Hi,
>>
>> Moving this discussion from
>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>> was saying I do not see precisely what you see, the repeated calls
>> seem to work for me locally. I would not expect the call without
>> COMPONENTS to work, and am not sure we should support calling with and
>> without COMPONENTS.
>>
>> I have a minimal CMake script,
>>
>> cmake_minimum_required(VERSION 3.0)
>>
>> find_package(VTK COMPONENTS vtkChartsCore)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK COMPONENTS vtkCommonCore)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK COMPONENTS vtkCommonMath)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK COMPONENTS vtkChartsCore)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> This results in the output,
>>
>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>> -- The C compiler identification is GNU 4.9.1
>> -- The CXX compiler identification is GNU 4.9.1
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>> -- LIBS: vtkCommonCore;vtksys
>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>
>> As far as I can see this gives the libraries one would expect, i.e.
>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>> final one is incorrect but I am not sure of the value in supporting
>> mixed COMPONENTS and non-components versions of find_package.
>>
>> Let me know if there is something I am missing, is this possibly with
>> an older version of VTK (I am testing with master).
>>
>> Marcus

From matt.mccormick at kitware.com  Tue Sep  9 14:37:35 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 9 Sep 2014 14:37:35 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
Message-ID: <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>

Hi Marcus,

Thanks for taking a look at this. I reproduced your output with VTK
master for build a build tree and install tree.  However, I get

-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
-- LIBS: vtkCommonCore
-- LIBS: vtkCommonMath
-- LIBS: vtkChartsCore
-- LIBS: vtkChartsCore
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/vtkcomponents/build

for an installed VTK 6.0.


What was the fix and where it was made? We would like to have similar
behavior for ITK and other CMake projects that make use of components.


I hope that multiple calls, sometimes without specifying COMPONENTS,
will still work. If it does not work, CMake should complain
informatively that a non-COMPONENTS call cannot occur after a
COMPONENTS call.

Thanks,
Matt

On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Pushing this a little further, to see if we can build executables in
> the same directory with multiple calls, the following worked for me
> locally,
>
> cmake_minimum_required(VERSION 3.0)
>
> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
> add_executable(testexe test.cxx)
> set_property(TARGET testexe APPEND
>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
> set_property(TARGET testexe APPEND
>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
> target_link_libraries(testexe ${VTK_LIBRARIES})
>
> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
> add_executable(testexe2 test2.cxx)
> set_property(TARGET testexe2 APPEND
>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
> set_property(TARGET testexe2 APPEND
>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>
> Producing the output,
>
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
> -- LIBS: vtkCommonCore;vtksys
> -- DEFS:
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/marcus/build/vtkcomponents
>
> So the definitions were empty, as you would hope, in the second call,
> the mains were very simple instantiating a vtkRenderWindow in the
> first which resulted in a vtkXOpenGLRenderWindow class being
> instantiated as the overrides kicked in for that target. Most projects
> I know of that make multiple calls tend to use directories for each
> target, and make the calls in sibling directories, but it looks like
> you should be able to call it multiple times in the same scope (on
> Linux with VTK master at least).
>
> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Adding you both to CC in case you aren't subscribed, it might also be
>> worth appending NO_MODULE to the calls to ensure find modules aren't
>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>> contains advice I added, but didn't specifically cover multiple calls.
>> Including the use file, or setting the DIRECTORY property will of
>> course cause issues if you are not using separate directory scopes for
>> each target.
>>
>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> Hi,
>>>
>>> Moving this discussion from
>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>> was saying I do not see precisely what you see, the repeated calls
>>> seem to work for me locally. I would not expect the call without
>>> COMPONENTS to work, and am not sure we should support calling with and
>>> without COMPONENTS.
>>>
>>> I have a minimal CMake script,
>>>
>>> cmake_minimum_required(VERSION 3.0)
>>>
>>> find_package(VTK COMPONENTS vtkChartsCore)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK COMPONENTS vtkCommonCore)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK COMPONENTS vtkCommonMath)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK COMPONENTS vtkChartsCore)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> This results in the output,
>>>
>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>> -- The C compiler identification is GNU 4.9.1
>>> -- The CXX compiler identification is GNU 4.9.1
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>> -- LIBS: vtkCommonCore;vtksys
>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>
>>> As far as I can see this gives the libraries one would expect, i.e.
>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>> final one is incorrect but I am not sure of the value in supporting
>>> mixed COMPONENTS and non-components versions of find_package.
>>>
>>> Let me know if there is something I am missing, is this possibly with
>>> an older version of VTK (I am testing with master).
>>>
>>> Marcus

From marcus.hanwell at kitware.com  Tue Sep  9 14:42:23 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 14:42:23 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
 <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
Message-ID: <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>

Matt,

Probably commit f915a54, made after I proposed a different change that
was ultimately rejected. I didn't realize you were on 6.0 - a lot has
changed since then. I am not entirely certain what your use case is
for mixed - reallyt non one should make mixed calls and you should
prefer to always specify COMPONENTS. It would be safer to at least
spit out a warning, I can look at adding something to warn.

Marcus

On Tue, Sep 9, 2014 at 2:37 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> Hi Marcus,
>
> Thanks for taking a look at this. I reproduced your output with VTK
> master for build a build tree and install tree.  However, I get
>
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
> -- LIBS: vtkCommonCore
> -- LIBS: vtkCommonMath
> -- LIBS: vtkChartsCore
> -- LIBS: vtkChartsCore
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /tmp/vtkcomponents/build
>
> for an installed VTK 6.0.
>
>
> What was the fix and where it was made? We would like to have similar
> behavior for ITK and other CMake projects that make use of components.
>
>
> I hope that multiple calls, sometimes without specifying COMPONENTS,
> will still work. If it does not work, CMake should complain
> informatively that a non-COMPONENTS call cannot occur after a
> COMPONENTS call.
>
> Thanks,
> Matt
>
> On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Pushing this a little further, to see if we can build executables in
>> the same directory with multiple calls, the following worked for me
>> locally,
>>
>> cmake_minimum_required(VERSION 3.0)
>>
>> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>> add_executable(testexe test.cxx)
>> set_property(TARGET testexe APPEND
>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>> set_property(TARGET testexe APPEND
>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>> target_link_libraries(testexe ${VTK_LIBRARIES})
>>
>> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>> add_executable(testexe2 test2.cxx)
>> set_property(TARGET testexe2 APPEND
>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>> set_property(TARGET testexe2 APPEND
>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>>
>> Producing the output,
>>
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
>> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
>> -- LIBS: vtkCommonCore;vtksys
>> -- DEFS:
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>
>> So the definitions were empty, as you would hope, in the second call,
>> the mains were very simple instantiating a vtkRenderWindow in the
>> first which resulted in a vtkXOpenGLRenderWindow class being
>> instantiated as the overrides kicked in for that target. Most projects
>> I know of that make multiple calls tend to use directories for each
>> target, and make the calls in sibling directories, but it looks like
>> you should be able to call it multiple times in the same scope (on
>> Linux with VTK master at least).
>>
>> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> Adding you both to CC in case you aren't subscribed, it might also be
>>> worth appending NO_MODULE to the calls to ensure find modules aren't
>>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>>> contains advice I added, but didn't specifically cover multiple calls.
>>> Including the use file, or setting the DIRECTORY property will of
>>> course cause issues if you are not using separate directory scopes for
>>> each target.
>>>
>>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Hi,
>>>>
>>>> Moving this discussion from
>>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>>> was saying I do not see precisely what you see, the repeated calls
>>>> seem to work for me locally. I would not expect the call without
>>>> COMPONENTS to work, and am not sure we should support calling with and
>>>> without COMPONENTS.
>>>>
>>>> I have a minimal CMake script,
>>>>
>>>> cmake_minimum_required(VERSION 3.0)
>>>>
>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK COMPONENTS vtkCommonCore)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK COMPONENTS vtkCommonMath)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> This results in the output,
>>>>
>>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>>> -- The C compiler identification is GNU 4.9.1
>>>> -- The CXX compiler identification is GNU 4.9.1
>>>> -- Check for working C compiler: /usr/bin/cc
>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>> -- Detecting C compiler ABI info
>>>> -- Detecting C compiler ABI info - done
>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>> -- Detecting CXX compiler ABI info
>>>> -- Detecting CXX compiler ABI info - done
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>> -- LIBS: vtkCommonCore;vtksys
>>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>> -- Configuring done
>>>> -- Generating done
>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>
>>>> As far as I can see this gives the libraries one would expect, i.e.
>>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>>> final one is incorrect but I am not sure of the value in supporting
>>>> mixed COMPONENTS and non-components versions of find_package.
>>>>
>>>> Let me know if there is something I am missing, is this possibly with
>>>> an older version of VTK (I am testing with master).
>>>>
>>>> Marcus

From aaron.hickerson at ondiagnostics.com  Tue Sep  9 17:09:01 2014
From: aaron.hickerson at ondiagnostics.com (Aaron Hickerson)
Date: Tue, 9 Sep 2014 14:09:01 -0700
Subject: [vtk-developers] Request info about changes made to
 vtkRuledSurfaceFilter vtkAppendPolyData after 5.2.1
Message-ID: <CADJkAPRMFNrqpH0oiQo2GCOrAts8Ay8aa4B195KefMkt_1S6Dw@mail.gmail.com>

Hello,

I am in the process of upgrading my company OS from ubuntu10 to ubuntu14
and so I am therefore dealing with an upgrade of vtk 5.2.1 to vtk 5.8. Our
legacy software is heavily dependent on vtk and we are noticing some
unexpected differences in outcomes with the newer 5.8 library. These
differences are slight but for our regulated software we need to know why
there are ANY differences in outcomes for this new release, no matter how
small.

There were changes made to the classes vtkRuledSurfaceFilter and
vtkAppendPolyData after 5.2.1 but I cannot find any succinct explanations
as to why these changes were made. These are the two classes that I have
identified that our software is dependent on that behave differently in
this new release, and provide different outcomes. I have scoured the
internet and looked at the source code in detail but I still cannot find
any real explanation as to WHY these two classes were modified to produce
different outcomes than in previous versions.

Can anyone point me to the changelog(s) for these classes that contain
succinct explanations for the algorithmic changes?

Thanks,
Aaron Hickerson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/ca2a0072/attachment.html>

From christopher.mullins at kitware.com  Tue Sep  9 17:16:05 2014
From: christopher.mullins at kitware.com (Christopher Mullins)
Date: Tue, 9 Sep 2014 17:16:05 -0400
Subject: [vtk-developers] Request info about changes made to
 vtkRuledSurfaceFilter vtkAppendPolyData after 5.2.1
In-Reply-To: <CADJkAPRMFNrqpH0oiQo2GCOrAts8Ay8aa4B195KefMkt_1S6Dw@mail.gmail.com>
References: <CADJkAPRMFNrqpH0oiQo2GCOrAts8Ay8aa4B195KefMkt_1S6Dw@mail.gmail.com>
Message-ID: <CABVTP-KfGj2+28Ne__ejxk8tBtg9qTEf2uTnRNUpF3KoUTvDmg@mail.gmail.com>

Hi Aaron.

The old front page of the wiki had a pretty good changelog on it.  I left a
link at the bottom of the current page in case anyone still wanted to see
that - here it is[1].  Maybe one of those links will help, otherwise I hope
someone else on here will be able to offer an explanation.

[1] http://www.vtk.org/Wiki/VTK/Deprecated_frontpage#VTK_5.2

On Tue, Sep 9, 2014 at 5:09 PM, Aaron Hickerson <
aaron.hickerson at ondiagnostics.com> wrote:

> Hello,
>
> I am in the process of upgrading my company OS from ubuntu10 to ubuntu14
> and so I am therefore dealing with an upgrade of vtk 5.2.1 to vtk 5.8. Our
> legacy software is heavily dependent on vtk and we are noticing some
> unexpected differences in outcomes with the newer 5.8 library. These
> differences are slight but for our regulated software we need to know why
> there are ANY differences in outcomes for this new release, no matter how
> small.
>
> There were changes made to the classes vtkRuledSurfaceFilter and
> vtkAppendPolyData after 5.2.1 but I cannot find any succinct explanations
> as to why these changes were made. These are the two classes that I have
> identified that our software is dependent on that behave differently in
> this new release, and provide different outcomes. I have scoured the
> internet and looked at the source code in detail but I still cannot find
> any real explanation as to WHY these two classes were modified to produce
> different outcomes than in previous versions.
>
> Can anyone point me to the changelog(s) for these classes that contain
> succinct explanations for the algorithmic changes?
>
> Thanks,
> Aaron Hickerson
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
Christopher Mullins
R&D Engineer
Kitware Inc.,
919.869.8871
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/3e44d06a/attachment-0001.html>

From david.gobbi at gmail.com  Tue Sep  9 23:01:13 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 9 Sep 2014 21:01:13 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
 <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
 <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>
Message-ID: <CANwS1=GdG3kLinS_DeB-xR8p7FYrwvTZ95mrPzBcz6vzbCH7Kw@mail.gmail.com>

Hi Utkarsh,

I found the difference between my program and your script. I was using
the vtkDataSetMapper, but if I use the vtkPolyDataMapper instead then
I see the correct behavior as ScalarColors.py.  And, of course, if I
use the vtkDataSetMapper in ScalarColors.py then it shows the odd
behavior that I described previously.

So now, the question is why vtkDataSetMapper is giving different
results than vtkPolyDataMapper.

 - David

On Tue, Sep 9, 2014 at 9:14 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> BTW, in my script, you can hit "t" to swap the ambient/diffuse coefficients.
>
> On Tue, Sep 9, 2014 at 11:13 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Here's my test script. With the patch applied, I don't see the ambient
>> and diffuse colors bleed in anymore.
>>
>> On Tue, Sep 9, 2014 at 11:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
>>> patch, but it had no effect.  The results were exactly the same as in
>>> my first email.
>>>
>>> I'll have to look through the code to figure out what the intended behaviour is.
>>>
>>>  - David
>>>
>>> On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> Doh! Here you go.
>>>>
>>>> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Hi Utkarsh,
>>>>>
>>>>> The "attached patch" seems to be missing.
>>>>>
>>>>>  - David
>>>>>
>>>>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>> David,
>>>>>>
>>>>>> Try the attached patch and then set
>>>>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>>>>> ScalarMaterialMode is the thing here. When set to
>>>>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>>>>> which material component should track the scalar color based on which
>>>>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>>>>> The patch fixes an issue where the painter was not respecting the
>>>>>> material mode set on the mapper.
>>>>>>
>>>>>> Utkarsh
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> Hi Utkarsh,
>>>>>>>
>>>>>>> Thanks for the reply.  If I use this:
>>>>>>>
>>>>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>>>>
>>>>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>>>>
>>>>>>>
>>>>>>> If I use this:
>>>>>>>
>>>>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>>>>
>>>>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>>>>> right side
>>>>>>> of the image from my previous email.
>>>>>>>
>>>>>>>
>>>>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>>>>> result.
>>>>>>>
>>>>>>>  - David
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>>>> This sounds familiar.
>>>>>>>>
>>>>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>>>>
>>>>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>>>>
>>>>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>>>>
>>>>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>>>>     such bleeding is avoided.
>>>>>>>>
>>>>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>>>>     for scalar coloring.
>>>>>>>>
>>>>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>>>>
>>>>>>>>
>>>>>>>> Utkarsh
>>>>>>>>
>>>>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>>>>> list last week?
>>>>>>>>>
>>>>>>>>>  - David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>>>>> VTK master.
>>>>>>>>> [ snip ]
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>>

From dlrdave at aol.com  Wed Sep 10 08:30:45 2014
From: dlrdave at aol.com (David Cole)
Date: Wed, 10 Sep 2014 08:30:45 -0400
Subject: [vtk-developers] Wiki example strangeness
Message-ID: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>

This example:
http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/CurvatureBandsWithGlyphs

Clearly contains:
renWin->SetSize(800, 800);

Why, then does the alternate valid image 
"Testing/Baseline/Visualization/TestCurvatureBandsWithGlyphs_1.png" [1] 
in the VTK wiki examples git repository have dimensions 800 x 771? Why 
is an image of a different size considered valid?

And ..... why are the images so different? Shouldn't the randomly 
generated images seen in this example be identical because of random 
seeding? Compare to the primary baseline image at [2].


Thanks for any insight,
David C.


[1] 
https://gitorious.org/vtkwikiexamples/wikiexamples/source/09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/TestCurvatureBandsWithGlyphs_1.png
[2] 
https://gitorious.org/vtkwikiexamples/wikiexamples/source/09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/TestCurvatureBandsWithGlyphs.png


From andrew.amaclean at gmail.com  Wed Sep 10 08:46:32 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 10 Sep 2014 22:46:32 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
Message-ID: <CAHDsG9PsjiFakxciNppWwTOC6e=_wz-dJC_weDSy-w_9OzcjQg@mail.gmail.com>

The first image is generated on a windows machine and the second is done on
a Linux machine. The same random seed is used but the random number
generator is different for windows & Linux hence the different shaped
hills. Both images should be 800 x800.

Andrew
On Sep 10, 2014 10:30 PM, "David Cole" <dlrdave at aol.com> wrote:

> This example:
> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/
> CurvatureBandsWithGlyphs
>
> Clearly contains:
> renWin->SetSize(800, 800);
>
> Why, then does the alternate valid image "Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png" [1] in the VTK wiki examples git
> repository have dimensions 800 x 771? Why is an image of a different size
> considered valid?
>
> And ..... why are the images so different? Shouldn't the randomly
> generated images seen in this example be identical because of random
> seeding? Compare to the primary baseline image at [2].
>
>
> Thanks for any insight,
> David C.
>
>
> [1] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png
> [2] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs.png
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140910/55bc1142/attachment.html>

From utkarsh.ayachit at kitware.com  Wed Sep 10 08:56:38 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 10 Sep 2014 08:56:38 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=GdG3kLinS_DeB-xR8p7FYrwvTZ95mrPzBcz6vzbCH7Kw@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
 <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
 <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>
 <CANwS1=GdG3kLinS_DeB-xR8p7FYrwvTZ95mrPzBcz6vzbCH7Kw@mail.gmail.com>
Message-ID: <CADHSJjAho0HcjSYy3yV+jb_mnkqzh8dZATxpXWQDj_8sfDqOaw@mail.gmail.com>

> So now, the question is why vtkDataSetMapper is giving different
> results than vtkPolyDataMapper.

That's easy. The vtkDataSetMapper doesn't seem to pass all the iVar
values to the internal vtkPolyDataMapper. Hence the ScalarMaterialMode
set on vtkDataSetMapper is lost.

I'll add a test and push the patch I sent to gerrit soon.

Utkarsh

From andrew.amaclean at gmail.com  Wed Sep 10 09:12:37 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 10 Sep 2014 23:12:37 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
Message-ID: <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>

Continuing on ...
With respect to the first image, I suspect that this may be fixed in the
master by your submission: http://review.source.kitware.com/#/c/16872/
and/or http://review.source.kitware.com/#/c/16873/

As for the differences between the hill shapes in Windows and Linux, the
same RNG needs to be used in all machines. I'll look at using one of the
ones in vtkMath.h at some stage. There is an option to turn off random
generation and generate regular shaped hills, but it is pretty boring.

Andrew
 On Sep 10, 2014 10:30 PM, "David Cole" <dlrdave at aol.com> wrote:

> This example:
> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/
> CurvatureBandsWithGlyphs
>
> Clearly contains:
> renWin->SetSize(800, 800);
>
> Why, then does the alternate valid image "Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png" [1] in the VTK wiki examples git
> repository have dimensions 800 x 771? Why is an image of a different size
> considered valid?
>
> And ..... why are the images so different? Shouldn't the randomly
> generated images seen in this example be identical because of random
> seeding? Compare to the primary baseline image at [2].
>
>
> Thanks for any insight,
> David C.
>
>
> [1] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png
> [2] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs.png
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140910/c763c676/attachment.html>

From berk.geveci at kitware.com  Wed Sep 10 20:14:33 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 10 Sep 2014 20:14:33 -0400
Subject: [vtk-developers] The recently introduce vtkPythonAlgorithm
Message-ID: <CAE32kpU7ruvTXa0G1wsS6eu5urwW=KEjRy731jFMS=Cs_JCaAA@mail.gmail.com>

Hi folks,

I wanted to do a little marketing for a class Ben Boeckel recently added to
VTK. I wrote a fairly long article on it recently:

http://www.kitware.com/blog/home/post/737

This class and the supporting Python classes allow one to develop
fully-functional subclasses of vtkAlgorithm purely in Python. Something we
haven't had until now.

I also wrote a who slew of articles on how to leverage the also recently
introduced numpy_support module to do a lot of thing from purely Python
without loosing efficiency. If you are interested, here is the list:

http://www.kitware.com/blog/home/user/53

I will be following these with more articles on developing sophisticated
algorithms in Python and some cool examples.

Best,
-berk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140910/33b88e8c/attachment-0001.html>

From dlrdave at aol.com  Thu Sep 11 07:21:13 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 07:21:13 -0400
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
Message-ID: <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>

Thanks Andrew.

If you are busy, I can investigate making this consistent on Linux and 
Windows. Is the right place to start looking in the wiki example code, 
or is it in VTK itself?

Thanks,
D


From andrew.amaclean at gmail.com  Thu Sep 11 07:37:18 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Thu, 11 Sep 2014 21:37:18 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
Message-ID: <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>

David,
The difference between the Windows and Linux appearance is in the VTK code
itself, due to the fact that I have just used the system RNGs. I just have
to bring in vtkMath.h as there are a couple of RNG's there.  I'll try and
get something up for review before the 20th if that is OK.

Andrew
On Sep 11, 2014 9:21 PM, "David Cole" <dlrdave at aol.com> wrote:

> Thanks Andrew.
>
> If you are busy, I can investigate making this consistent on Linux and
> Windows. Is the right place to start looking in the wiki example code, or
> is it in VTK itself?
>
> Thanks,
> D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140911/1702a142/attachment.html>

From dlrdave at aol.com  Thu Sep 11 07:40:42 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 07:40:42 -0400
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
Message-ID: <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>

Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.

D


From cory.quammen at kitware.com  Thu Sep 11 11:07:24 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Thu, 11 Sep 2014 11:07:24 -0400
Subject: [vtk-developers] Single test file used for more than one test?
Message-ID: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>

Hi all,

I'm writing a VTK test that takes some command-line arguments to
control some options in a filter. What I would like to do is define
several tests in the CMakeLists.txt file that run this same code but
which pass different arguments in through argv[].

I haven't found an example of this kind of test in VTK. Most tests are
defined by passing to vtk_add_test_cxx the name of the source file for
the test.

Can anyone point me to an example similar to what I want to do?

Thanks!
Cory

From bill.lorensen at gmail.com  Thu Sep 11 11:09:02 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 11 Sep 2014 11:09:02 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <CADZJ4hOiBt3bXJFJG97QFBUfXHHAQE7TiYEaBCY+m9M1ARa=JA@mail.gmail.com>

Cory,

I don't think vtk supports that capability. Might need a new testing macro?

Bill

On Thu, Sep 11, 2014 at 11:07 AM, Cory Quammen <cory.quammen at kitware.com> wrote:
> Hi all,
>
> I'm writing a VTK test that takes some command-line arguments to
> control some options in a filter. What I would like to do is define
> several tests in the CMakeLists.txt file that run this same code but
> which pass different arguments in through argv[].
>
> I haven't found an example of this kind of test in VTK. Most tests are
> defined by passing to vtk_add_test_cxx the name of the source file for
> the test.
>
> Can anyone point me to an example similar to what I want to do?
>
> Thanks!
> Cory
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>



-- 
Unpaid intern in BillsBasement at noware dot com

From dave.demarle at kitware.com  Thu Sep 11 11:13:55 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 11 Sep 2014 11:13:55 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <CANjZAi_QuvztpdrJJA5RjK7BU-GRZvC6UKpkL4tob7-PyRR-vw@mail.gmail.com>

In Accelerators/Piston/Testing/Python/CMakeLists.txt we set a different
test name prefix for each variation of the argument.

I agree with Bill, for Cxx you may need to make up a new testing macro.

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

On Thu, Sep 11, 2014 at 11:07 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Hi all,
>
> I'm writing a VTK test that takes some command-line arguments to
> control some options in a filter. What I would like to do is define
> several tests in the CMakeLists.txt file that run this same code but
> which pass different arguments in through argv[].
>
> I haven't found an example of this kind of test in VTK. Most tests are
> defined by passing to vtk_add_test_cxx the name of the source file for
> the test.
>
> Can anyone point me to an example similar to what I want to do?
>
> Thanks!
> Cory
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140911/1cc1869f/attachment.html>

From burlen.loring at gmail.com  Thu Sep 11 11:22:36 2014
From: burlen.loring at gmail.com (Burlen Loring)
Date: Thu, 11 Sep 2014 08:22:36 -0700
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <5411BE3C.7030207@gmail.com>

Hi Cory,

That's how the surface LIC tests are written. Take a look at 
VTK/Rendering/LIC/Testing/Cxx/CMakeLists.txt

Burlen

On 09/11/2014 08:07 AM, Cory Quammen wrote:
> Hi all,
>
> I'm writing a VTK test that takes some command-line arguments to
> control some options in a filter. What I would like to do is define
> several tests in the CMakeLists.txt file that run this same code but
> which pass different arguments in through argv[].
>
> I haven't found an example of this kind of test in VTK. Most tests are
> defined by passing to vtk_add_test_cxx the name of the source file for
> the test.
>
> Can anyone point me to an example similar to what I want to do?
>
> Thanks!
> Cory
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>


From david.gobbi at gmail.com  Thu Sep 11 13:32:16 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 11:32:16 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
Message-ID: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>

Hi All,

The OS X interactors (Cocoa and Carbon) currently interpret the
Command key as "Alt", which I find to be counterintuitive.

OS X generally interprets the "Command" key the same way that
Windows and Linux interpret the "Ctrl" key, so it seems to me that it
would make more sense VTK apps to interpret "Command" as "Ctrl".

The current behavior (Command as "Alt") was added by Sebastien
Barre in 2006, and he included this comment:
// Even though the option key is the one with a small 'alt' label on top
// of it, VNC (as well as some Mac users) uses the command key as 'alt'.

I'm not sure if the part about VNC is correct, but the part about Mac
users using the Command key as "Alt" does not ring true.

Does anyone else think that it is worth changing the behaviour so
that the OS X "Command" key is interpreted by VTK apps the same
way as "Ctrl"?  OS X users will still be able to apply the "Alt" modifier,
because the OS X "Opt" key is equivalent to "Alt".

 - David

From utkarsh.ayachit at kitware.com  Thu Sep 11 13:59:24 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 11 Sep 2014 13:59:24 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
References: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
Message-ID: <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>

> Does anyone else think that it is worth changing the behaviour so
> that the OS X "Command" key is interpreted by VTK apps the same
> way as "Ctrl"?  OS X users will still be able to apply the "Alt" modifier,
> because the OS X "Opt" key is equivalent to "Alt".

+1

From dlrdave at aol.com  Thu Sep 11 14:26:37 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 14:26:37 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>
References: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
 <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>
Message-ID: <8D19C050EB6EE69-37B0-443EF@webmail-m223.sysops.aol.com>

>> Does anyone else think that it is worth changing the behaviour so
>> that the OS X "Command" key is interpreted by VTK apps the same
>> way as "Ctrl"?  OS X users will still be able to apply the "Alt" 
modifier,
>> because the OS X "Opt" key is equivalent to "Alt".
>
> +1

But my Apple keyboard has a "control" key too... Would "control" and 
"command" be two keys on the keyboard that do exactly the same thing 
then?


From david.gobbi at gmail.com  Thu Sep 11 14:35:36 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 12:35:36 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <8D19C050EB6EE69-37B0-443EF@webmail-m223.sysops.aol.com>
References: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
 <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>
 <8D19C050EB6EE69-37B0-443EF@webmail-m223.sysops.aol.com>
Message-ID: <CANwS1=HYOBuZO3A+44Fn79Cqf2tT8M5U2FcuTnv9PgL6w+Wxcw@mail.gmail.com>

On Thu, Sep 11, 2014 at 12:26 PM, David Cole <dlrdave at aol.com> wrote:
> But my Apple keyboard has a "control" key too... Would "control" and
> "command" be two keys on the keyboard that do exactly the same thing then?

Yes.  The VTK interactors only support three modifiers (Control, Shift, Alt), so
aliasing is unavoidable unless we ignore one of the keys altogether.

 - David

From biddisco at cscs.ch  Thu Sep 11 15:00:17 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Thu, 11 Sep 2014 19:00:17 +0000
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <D037BD6C.66DC8%biddisco@cscs.ch>

Does this help


  FOREACH(N 1 2 3 4 8 16 32 64)

    SET(test_name "TestH5PartParallelWriter-P${N}")

      #

      # Serial N==1

      #

      IF (N EQUAL 1)

        ADD_TEST(

          NAME ${test_name}

          COMMAND

            $<TARGET_FILE:TestH5PartParallelWriter>

            -generateParticles 1000000

            -F temp.h5

            -D ${PLUGIN_TEST_DIR}

            -T "${PLUGIN_TEST_DIR}"

            -testName ${test_name}

        )

      ENDIF (N EQUAL 1)

      #

      # Parallel N>1

      #

      IF (N GREATER 1)

        greater_equal(${MPIEXEC_MAX_NUMPROCS} ${N} processors)

        IF (processors)

          ADD_TEST(

          NAME ${test_name}

          COMMAND

            ${MPIEXEC} ${MPIEXEC_PREFLAGS} ${MPIEXEC_NUMPROC_FLAG} ${N}

            $<TARGET_FILE:TestH5PartParallelWriter>

            -generateParticles 1000000

            -F temp.h5

            -D ${PLUGIN_TEST_DIR}

            -T "${PLUGIN_TEST_DIR}"

            -testName ${test_name}

        )

        ENDIF (processors)

    ENDIF (N GREATER 1)

  ENDFOREACH(N)


On 11/09/14 17:07, "Cory Quammen" <cory.quammen at kitware.com<mailto:cory.quammen at kitware.com>> wrote:

Hi all,

I'm writing a VTK test that takes some command-line arguments to
control some options in a filter. What I would like to do is define
several tests in the CMakeLists.txt file that run this same code but
which pass different arguments in through argv[].

I haven't found an example of this kind of test in VTK. Most tests are
defined by passing to vtk_add_test_cxx the name of the source file for
the test.

Can anyone point me to an example similar to what I want to do?

Thanks!
Cory
_______________________________________________
Powered by www.kitware.com

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

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



From dlrdave at aol.com  Thu Sep 11 16:09:59 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 16:09:59 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
Message-ID: <8D19C137F0F1769-37B0-454FA@webmail-m223.sysops.aol.com>

> The VTK interactors only support three modifiers (Control, Shift,
> Alt), so aliasing is unavoidable unless we ignore one of the keys
> altogether.

I'm ok with swapping it to be "same as control" instead of "same as alt"

But I must say, I am used to using the "Alt" key on my Windows keyboard
to do Mac command-key shortcuts when I'm VNC'ed into my Mac. This
change may confuse some people momentarily, and it might make it
difficult to do "Alt" stuff on a Mac from a non-Mac keyboard... but in
my opinion, it's not a big deal any way you slice it.

If you do change the behavior, just document it accordingly, perhaps
mentioning that it changed from one to the other in VTK 6.2 somewhere.


D




From david.gobbi at gmail.com  Thu Sep 11 16:36:50 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 14:36:50 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <8D19C137F0F1769-37B0-454FA@webmail-m223.sysops.aol.com>
References: <8D19C137F0F1769-37B0-454FA@webmail-m223.sysops.aol.com>
Message-ID: <CANwS1=FmfQxV3NgaAv6vwQ=a-=dF9u5-sY5UomGQzdBguKZ5_Q@mail.gmail.com>

On Thu, Sep 11, 2014 at 2:09 PM, David Cole <dlrdave at aol.com> wrote:
>
> If you do change the behavior, just document it accordingly, perhaps
> mentioning that it changed from one to the other in VTK 6.2 somewhere.

Document it where, though?  I can prod Dave DeMarle to mention it in the
VTK 6.2 release notes, but other than that, there isn't really any other way
to document VTK changes like this.

 - David

From cory.quammen at kitware.com  Thu Sep 11 17:38:19 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Thu, 11 Sep 2014 17:38:19 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <5411BE3C.7030207@gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
 <5411BE3C.7030207@gmail.com>
Message-ID: <CAB5Fpx54C2P=oJgRaip=eSK1Cpkta1BasNApAa60mwZyK9C93A@mail.gmail.com>

Burlen,

Thanks for the pointer. I like that your example is explicit in what
is being passed to the tests.

To use the more "magic" vtk_add_test_cxx() function, it turns out you
can do the following:

set(vtk_test_prefix Second)
vtk_add_test_cxx(${vtk-module}CxxTests tests
  SurfacePlusEdges.cxx --arg1 --arg2 --arg3
)
unset(vtk_test_prefix)

And this will define a test named $(vtk-module}Cxx-SecondSurfacePlusEdges.

In it's current form, this test will point to a baseline named
SurfacePlusEdges.png. To point it to a baseline for just this test, I
had to modify vtkTestingMacros.cmake to include vtk_test_prefix in the
baseline path. The modifications are on gerrit:

http://review.source.kitware.com/#/t/4648/

This specifies the baseline file name as SecondSurfacePlusEdges.png.

Reviews for this topic are appreciated :-)

I'm not sure if I'm thrilled with defining the test name this way. It
would be nicer to do something like

vtk_add_test_cxx(${vtk-module}CxxTests tests
  SurfacePlusEdges.cxx --arg0 --arg1 --arg2
  SurfacePlusEdges.cxx,CUSTOM_NAME SurfacePlusEdges2 --arg3 --arg4 --arg5
)

where if CUSTOM_NAME is specified, the first argument is the test name.

Thanks,
Cory

On Thu, Sep 11, 2014 at 11:22 AM, Burlen Loring <burlen.loring at gmail.com> wrote:
> Hi Cory,
>
> That's how the surface LIC tests are written. Take a look at
> VTK/Rendering/LIC/Testing/Cxx/CMakeLists.txt
>
> Burlen
>
>
> On 09/11/2014 08:07 AM, Cory Quammen wrote:
>>
>> Hi all,
>>
>> I'm writing a VTK test that takes some command-line arguments to
>> control some options in a filter. What I would like to do is define
>> several tests in the CMakeLists.txt file that run this same code but
>> which pass different arguments in through argv[].
>>
>> I haven't found an example of this kind of test in VTK. Most tests are
>> defined by passing to vtk_add_test_cxx the name of the source file for
>> the test.
>>
>> Can anyone point me to an example similar to what I want to do?
>>
>> Thanks!
>> Cory
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>

From dlrdave at aol.com  Thu Sep 11 21:11:26 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 21:11:26 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
Message-ID: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>

> Document it where, though?

Perhaps here:
http://www.vtk.org/doc/nightly/html/classvtkCocoaRenderWindowInteractor.html#details

And here:
http://www.vtk.org/doc/nightly/html/classvtkCarbonRenderWindowInteractor.html#details

Prodding Mr. DeMarle to include it in the release notes, or on a wiki
page about the next release, is also a good idea.

I know it's minor, but it is a change in behavior.


D



From david.gobbi at gmail.com  Fri Sep 12 00:10:31 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 22:10:31 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>
References: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>
Message-ID: <CANwS1=HV40H+1Rg4xONWOzRKYZFXg1YUawu=LfZGRD0ZmR5u9Q@mail.gmail.com>

On Thu, Sep 11, 2014 at 7:11 PM, David Cole <dlrdave at aol.com> wrote:
>> Document it where, though?
>
> Perhaps here:
> http://www.vtk.org/doc/nightly/html/classvtkCocoaRenderWindowInteractor.html#details
> http://www.vtk.org/doc/nightly/html/classvtkCarbonRenderWindowInteractor.html#details

Will do.  Sorry for my general grumpiness, winter arrived in my city
two months early :^(

 - David

From andrew.amaclean at gmail.com  Fri Sep 12 04:54:55 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 12 Sep 2014 18:54:55 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
 <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
Message-ID: <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>

All pushed to gerrit, you and Bill have been added as reviewers, see:
http://review.source.kitware.com/16994

After it is reviewed, I'll update the the examples with new pictures, I
will also adjust the banding ranges for the curvature example.

Regards
   Andrew
On Sep 11, 2014 9:40 PM, "David Cole" <dlrdave at aol.com> wrote:

> Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.
>
> D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140912/5aa38626/attachment-0001.html>

From dlrdave at aol.com  Fri Sep 12 06:22:07 2014
From: dlrdave at aol.com (David Cole)
Date: Fri, 12 Sep 2014 06:22:07 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <CANwS1=HV40H+1Rg4xONWOzRKYZFXg1YUawu=LfZGRD0ZmR5u9Q@mail.gmail.com>
References: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>
 <CANwS1=HV40H+1Rg4xONWOzRKYZFXg1YUawu=LfZGRD0ZmR5u9Q@mail.gmail.com>
Message-ID: <8D19C8A8A19E7B4-2B64-44BC2@webmail-m253.sysops.aol.com>

No worries. I am often frustrated when trying to figure out where to 
document conceptual things that aren't really part of a single method 
or class.

Move south! We don't have to shovel down here - I would be grumpy too 
if I had to shovel in September...


D


From andrew.amaclean at gmail.com  Sun Sep 14 18:44:43 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Mon, 15 Sep 2014 08:44:43 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
 <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
 <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>
Message-ID: <CAHDsG9P4QZx+5y1fyGbyTGtC8JSrO=cdXmUxfpUnJ2iW4-Xc7Q@mail.gmail.com>

Hi Bill, David
The wiki examples have been updated with new pictures and the banding range
adjusted for the curvature example.
See:
http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/ElevationBandsWithGlyphs
http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/CurvatureBandsWithGlyphs
and the corresponding C++ versions.

This is a consequence of vtkRandomHills now using
vtkMinimalStandardRandomSequence to generate
a random sequence instead of the native random number generators.

Regards
   Andrew


On Fri, Sep 12, 2014 at 6:54 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> All pushed to gerrit, you and Bill have been added as reviewers, see:
> http://review.source.kitware.com/16994
>
> After it is reviewed, I'll update the the examples with new pictures, I
> will also adjust the banding ranges for the curvature example.
>
> Regards
>    Andrew
> On Sep 11, 2014 9:40 PM, "David Cole" <dlrdave at aol.com> wrote:
>
>> Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.
>>
>> D
>>
>>


-- 
___________________________________________
Andrew J. P. Maclean

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

From will.schroeder at kitware.com  Mon Sep 15 06:17:07 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Mon, 15 Sep 2014 06:17:07 -0400
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9P4QZx+5y1fyGbyTGtC8JSrO=cdXmUxfpUnJ2iW4-Xc7Q@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
 <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
 <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>
 <CAHDsG9P4QZx+5y1fyGbyTGtC8JSrO=cdXmUxfpUnJ2iW4-Xc7Q@mail.gmail.com>
Message-ID: <CAEiDrtXP89+CAz14oECOqxE_NsVRkg46ZTDt7Ao9dUKTLOKCNw@mail.gmail.com>

>From the examples: "Rather beautiful surfaces are generated."

Indeed!

On Sun, Sep 14, 2014 at 6:44 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Hi Bill, David
> The wiki examples have been updated with new pictures and the banding
> range adjusted for the curvature example.
> See:
>
> http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/ElevationBandsWithGlyphs
>
> http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/CurvatureBandsWithGlyphs
> and the corresponding C++ versions.
>
> This is a consequence of vtkRandomHills now using
> vtkMinimalStandardRandomSequence to generate
> a random sequence instead of the native random number generators.
>
> Regards
>    Andrew
>
>
> On Fri, Sep 12, 2014 at 6:54 PM, Andrew Maclean <andrew.amaclean at gmail.com
> > wrote:
>
>> All pushed to gerrit, you and Bill have been added as reviewers, see:
>> http://review.source.kitware.com/16994
>>
>> After it is reviewed, I'll update the the examples with new pictures, I
>> will also adjust the banding ranges for the curvature example.
>>
>> Regards
>>    Andrew
>> On Sep 11, 2014 9:40 PM, "David Cole" <dlrdave at aol.com> wrote:
>>
>>> Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.
>>>
>>> D
>>>
>>>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
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/20140915/37525611/attachment.html>

From Gerrick.Bivins at halliburton.com  Mon Sep 15 10:02:22 2014
From: Gerrick.Bivins at halliburton.com (Gerrick Bivins)
Date: Mon, 15 Sep 2014 14:02:22 +0000
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
Message-ID: <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>

Hi Rostislav,
Did anything happen with this?
I would definitely be interested in this capability/feature/improvement.

Gerrick

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Tuesday, August 12, 2014 11:44 AM
To: Rostislav Khlebnikov
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi Rostislav,

This is great. Can you push the code to Gerrit (http://review.source.kitware.com/)?

Best,
-berk


On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov <rostislav.khlebnikov at kcl.ac.uk<mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
Hi guys,

just thought that the VTK developers might be interested in the test I made recently.

Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata.
Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms.

The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through.

But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code?

All best,
   Rostislav.

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

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

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


----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140915/550fa685/attachment-0001.html>

From rostislav.khlebnikov at kcl.ac.uk  Mon Sep 15 13:07:18 2014
From: rostislav.khlebnikov at kcl.ac.uk (Rostislav Khlebnikov)
Date: Mon, 15 Sep 2014 18:07:18 +0100
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
Message-ID: <54171CC6.9030407@kcl.ac.uk>

Hi,

well, basically, I feel that it is necessary to create a proper change 
to use Gerrit workflow successfully. Unfortunately, I don't quite have 
the time to do this properly for several reasons. One of them is that I 
actually don't need this change - for my project I integrated the 
CGAL-based cutting approach with AABB_tree which outperforms my VTK test 
- for example for the same test with 500k triangles CGAL-based cutting 
takes only 2ms. This will soon be integrated to MITK (in case anyone is 
interested, the pull request can be found here: 
https://github.com/MITK/MITK/pull/73). Making a proper VTK change would 
involve quite a lot of effort. Given that vtkCutter is very general and 
rejecting the octree nodes might be complex for arbitrary implicit 
functions, it seems to require quite a lot of work to avoid incorrect usage.

I can clean up the code a bit and post it to the mailing list if you are 
interested.

All best,
    Rostislav.


On 15/09/2014 15:02, Gerrick Bivins wrote:
>
> Hi Rostislav,
>
> Did anything happen with this?
>
> I would definitely be interested in this capability/feature/improvement.
>
> Gerrick
>
> *From:*vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On 
> Behalf Of *Berk Geveci
> *Sent:* Tuesday, August 12, 2014 11:44 AM
> *To:* Rostislav Khlebnikov
> *Cc:* VTK Developers
> *Subject:* Re: [vtk-developers] vtkCutter modification to use 
> vtkCellLocator
>
> Hi Rostislav,
>
> This is great. Can you push the code to Gerrit 
> (http://review.source.kitware.com/)?
>
> Best,
>
> -berk
>
> On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov 
> <rostislav.khlebnikov at kcl.ac.uk 
> <mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
>
> Hi guys,
>
> just thought that the VTK developers might be interested in the test I 
> made recently.
>
> Bascially what I did is subclass the vtkCellLocator to implement the 
> visitor pattern. It allows to filter the octree nodes (e.g. reject the 
> octree nodes that are of no interest early) and for leafs, to visit 
> the cells of the polydata.
> Then, I subclassed the vtkCutter to use this cell locator instead of 
> straight iteration over cells. Likely for very complex implicit 
> cutting functions this wouldnt be of any benefit. However, for those 
> which can test bboxes as being of interest or not, rejecting whole 
> subtrees, such as vtkPlane, it is very useful. I tested it on a 
> surface with 500k triangles and the cutter performance went from 88ms 
> per cut to 14ms.
>
> The code I made is quite ugly due to limited extensibility of 
> vtkCutter, so I had to copy-paste the RequestData method and make my 
> changes instead of, say, overriding IterateCells method which would 
> just provide the cells to cut through.
>
> But anyway, I was wondering if you guys are intersted in this kind of 
> functionality? Would you like me to send you the code?
>
> All best,
>    Rostislav.
>
> _______________________________________________
> Powered by www.kitware.com <http://www.kitware.com>
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html 
> <http://www.kitware.com/opensource/opensource.html>
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
> ------------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential 
> and privileged information for the sole use of the intended recipient. 
> Any review, use, distribution, or disclosure by others is strictly 
> prohibited. If you are not the intended recipient (or authorized to 
> receive information for the intended recipient), please contact the 
> sender by reply e-mail and delete all copies of this message.

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

From Gerrick.Bivins at halliburton.com  Mon Sep 15 14:28:14 2014
From: Gerrick.Bivins at halliburton.com (Gerrick Bivins)
Date: Mon, 15 Sep 2014 18:28:14 +0000
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <54171CC6.9030407@kcl.ac.uk>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
 <54171CC6.9030407@kcl.ac.uk>
Message-ID: <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>

Yes. I would definitely be interested in seeing the code.
Gerrick

From: Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
Sent: Monday, September 15, 2014 12:07 PM
To: Gerrick Bivins; Berk Geveci
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi,

well, basically, I feel that it is necessary to create a proper change to use Gerrit workflow successfully. Unfortunately, I don't quite have the time to do this properly for several reasons. One of them is that I actually don't need this change - for my project I integrated the CGAL-based cutting approach with AABB_tree which outperforms my VTK test - for example for the same test with 500k triangles CGAL-based cutting takes only 2ms. This will soon be integrated to MITK (in case anyone is interested, the pull request can be found here: https://github.com/MITK/MITK/pull/73). Making a proper VTK change would involve quite a lot of effort. Given that vtkCutter is very general and rejecting the octree nodes might be complex for arbitrary implicit functions, it seems to require quite a lot of work to avoid incorrect usage.

I can clean up the code a bit and post it to the mailing list if you are interested.

All best,
   Rostislav.

On 15/09/2014 15:02, Gerrick Bivins wrote:
Hi Rostislav,
Did anything happen with this?
I would definitely be interested in this capability/feature/improvement.

Gerrick

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Tuesday, August 12, 2014 11:44 AM
To: Rostislav Khlebnikov
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi Rostislav,

This is great. Can you push the code to Gerrit (http://review.source.kitware.com/)?

Best,
-berk


On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov <rostislav.khlebnikov at kcl.ac.uk<mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
Hi guys,

just thought that the VTK developers might be interested in the test I made recently.

Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata.
Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms.

The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through.

But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code?

All best,
   Rostislav.

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

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

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

________________________________
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

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

From andrew.amaclean at gmail.com  Mon Sep 15 19:40:14 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Tue, 16 Sep 2014 09:40:14 +1000
Subject: [vtk-developers] OpenGL2 TestParametricFunctions Failures
Message-ID: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>

I see that TestParametricFunctions.py consistently fails on all the OpenGL2
test machines:
http://open.cdash.org/testSummary.php?project=11&name=vtkCommonComputationalGeometryPython-TestParametricFunctions&date=2014-09-15

vttkParametricRandomHills.cxx was recently changed and the associated test
image for TestParametricFunctions.py updated.

It seems that on these machines, the new valid image has not been
downloaded there are also other OpenGL errors, here is a summary:

Valid Image incorrect, test image - vtkTextMapper not working:
dash1win7.kitware Win32-vs11-OpenGL2
londinium.kitware   Arch-GCC-4.9-x86_64-opengl2

The above machines display this error:
ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58
vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1


Valid Image incorrect, test image - vtkTextMapper not working:
kargad.kitware  MacLion-OpenGL2

Valid Image incorrect, test image - vtkTextMapper not working.
On the test image: Torus, Fig-8 Klein, Mobius, Super Toroid, Dini,
Random Hills and part of Roman all blacked out.
curius.kitware  fedora-x64-gcc-master-debug-ATI-RadeonHD-5870-OpenGL2

For the above two machines the errors seem to be mainly:
ERROR: In
/home/kitware/Dashboards/MyTests/VTK/Nightly/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
line 1458
vtkXOpenGLRenderWindow (0x2cb96a0): Hardware does not support the number of
textures defined.
and
ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58
vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1

Aside from the fact that the valid test images haven't been updated, is
there some issue with my code that I can fix?

Andrew

-- 
___________________________________________
Andrew J. P. Maclean

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

From ken.martin at kitware.com  Tue Sep 16 09:07:38 2014
From: ken.martin at kitware.com (Ken Martin)
Date: Tue, 16 Sep 2014 09:07:38 -0400
Subject: [vtk-developers] OpenGL2 TestParametricFunctions Failures
In-Reply-To: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>
References: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>
Message-ID: <cbe0fa22ef08a3c2cb0689da3692a0ea@mail.gmail.com>

I think you are good Andrew. I?m pretty sure there is a leak in one of the
texture resources in the OpenGL2 backend which may be part of some of the
failures. I?ll take a look at that when I get back to dashboards. Curius
was an old ATI Linux system running a driver that is not from ATI.  The
driver is broken and we decided to not work around it and removed that
dashboard.



Thanks!

Ken



Ken Martin PhD

Chairman & CFO

Kitware Inc.

28 Corporate Drive

Clifton Park NY 12065

ken.martin at kitware.com

518 881-4901 (w)

518 371-4573 (f)



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.



*From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
Of *Andrew Maclean
*Sent:* Monday, September 15, 2014 7:40 PM
*To:* VTK Developers
*Subject:* [vtk-developers] OpenGL2 TestParametricFunctions Failures





I see that TestParametricFunctions.py consistently fails on all the OpenGL2
test machines:

http://open.cdash.org/testSummary.php?project=11&name=vtkCommonComputationalGeometryPython-TestParametricFunctions&date=2014-09-15



vttkParametricRandomHills.cxx was recently changed and the associated test
image for TestParametricFunctions.py updated.



It seems that on these machines, the new valid image has not been
downloaded there are also other OpenGL errors, here is a summary:



Valid Image incorrect, test image - vtkTextMapper not working:

dash1win7.kitware Win32-vs11-OpenGL2

londinium.kitware   Arch-GCC-4.9-x86_64-opengl2



The above machines display this error:

ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58

vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1





Valid Image incorrect, test image - vtkTextMapper not working:

kargad.kitware  MacLion-OpenGL2



Valid Image incorrect, test image - vtkTextMapper not working.

On the test image: Torus, Fig-8 Klein, Mobius, Super Toroid, Dini,

Random Hills and part of Roman all blacked out.

curius.kitware  fedora-x64-gcc-master-debug-ATI-RadeonHD-5870-OpenGL2



For the above two machines the errors seem to be mainly:

ERROR: In
/home/kitware/Dashboards/MyTests/VTK/Nightly/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
line 1458

vtkXOpenGLRenderWindow (0x2cb96a0): Hardware does not support the number of
textures defined.

and

ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58

vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1



Aside from the fact that the valid test images haven't been updated, is
there some issue with my code that I can fix?



Andrew



-- 
___________________________________________
Andrew J. P. Maclean

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

From andrew.amaclean at gmail.com  Tue Sep 16 15:53:48 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 17 Sep 2014 05:53:48 +1000
Subject: [vtk-developers] OpenGL2 TestParametricFunctions Failures
In-Reply-To: <cbe0fa22ef08a3c2cb0689da3692a0ea@mail.gmail.com>
References: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>
 <cbe0fa22ef08a3c2cb0689da3692a0ea@mail.gmail.com>
Message-ID: <CAHDsG9Ou3U1fJqihP=s1PudkAU0ohOWGmzPbuka4YEo3LiwCMg@mail.gmail.com>

Thankyou Ken, that's good to know.
On Sep 16, 2014 11:07 PM, "Ken Martin" <ken.martin at kitware.com> wrote:

> I think you are good Andrew. I?m pretty sure there is a leak in one of the
> texture resources in the OpenGL2 backend which may be part of some of the
> failures. I?ll take a look at that when I get back to dashboards. Curius
> was an old ATI Linux system running a driver that is not from ATI.  The
> driver is broken and we decided to not work around it and removed that
> dashboard.
>
>
>
> Thanks!
>
> Ken
>
>
>
> Ken Martin PhD
>
> Chairman & CFO
>
> Kitware Inc.
>
> 28 Corporate Drive
>
> Clifton Park NY 12065
>
> ken.martin at kitware.com
>
> 518 881-4901 (w)
>
> 518 371-4573 (f)
>
>
>
> 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.
>
>
>
> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
> Of *Andrew Maclean
> *Sent:* Monday, September 15, 2014 7:40 PM
> *To:* VTK Developers
> *Subject:* [vtk-developers] OpenGL2 TestParametricFunctions Failures
>
>
>
>
>
> I see that TestParametricFunctions.py consistently fails on all the
> OpenGL2 test machines:
>
>
> http://open.cdash.org/testSummary.php?project=11&name=vtkCommonComputationalGeometryPython-TestParametricFunctions&date=2014-09-15
>
>
>
> vttkParametricRandomHills.cxx was recently changed and the associated test
> image for TestParametricFunctions.py updated.
>
>
>
> It seems that on these machines, the new valid image has not been
> downloaded there are also other OpenGL errors, here is a summary:
>
>
>
> Valid Image incorrect, test image - vtkTextMapper not working:
>
> dash1win7.kitware Win32-vs11-OpenGL2
>
> londinium.kitware   Arch-GCC-4.9-x86_64-opengl2
>
>
>
> The above machines display this error:
>
> ERROR: In
> /Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
> line 58
>
> vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
> but not some texture unit has not been released: Id=1
>
>
>
>
>
> Valid Image incorrect, test image - vtkTextMapper not working:
>
> kargad.kitware  MacLion-OpenGL2
>
>
>
> Valid Image incorrect, test image - vtkTextMapper not working.
>
> On the test image: Torus, Fig-8 Klein, Mobius, Super Toroid, Dini,
>
> Random Hills and part of Roman all blacked out.
>
> curius.kitware  fedora-x64-gcc-master-debug-ATI-RadeonHD-5870-OpenGL2
>
>
>
> For the above two machines the errors seem to be mainly:
>
> ERROR: In
> /home/kitware/Dashboards/MyTests/VTK/Nightly/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
> line 1458
>
> vtkXOpenGLRenderWindow (0x2cb96a0): Hardware does not support the number
> of textures defined.
>
> and
>
> ERROR: In
> /Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
> line 58
>
> vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
> but not some texture unit has not been released: Id=1
>
>
>
> Aside from the fact that the valid test images haven't been updated, is
> there some issue with my code that I can fix?
>
>
>
> Andrew
>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140917/b845f726/attachment-0001.html>

From berk.geveci at kitware.com  Tue Sep 16 16:03:04 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Tue, 16 Sep 2014 16:03:04 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
Message-ID: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>

Hi folks,

This is a reminder that on October 2nd, we are holding a bug tracker
hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
can. We will be hosting folks at our Clifton Park office as well as holding
a Google Hangout for those attending remotely. Here is the list of
attendees that I know so far:

- Bill Lorensen,
- Dave Cole,
- Sean McBride,
- Will Schroeder,
- me,
- Ben Boeckel,
- Chuck Atkins,
- Shawn Waldon,
- Marcus Hanwell,
- Dave DeMarle,
- Jamie Wright,
- Tim Meehan.

If you are not on this list and you are interested in attending, please let
me know.

Best,
-berk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140916/2143a7c0/attachment.html>

From will.schroeder at kitware.com  Wed Sep 17 13:39:16 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Wed, 17 Sep 2014 13:39:16 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
Message-ID: <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>

There is lots of room at our offices. And especially those in nearby areas
like Cambridge, MA (e.g., Steve P. and Nicole) we'd love to have you come
visit.

W

On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Hi folks,
>
> This is a reminder that on October 2nd, we are holding a bug tracker
> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
> can. We will be hosting folks at our Clifton Park office as well as holding
> a Google Hangout for those attending remotely. Here is the list of
> attendees that I know so far:
>
> - Bill Lorensen,
> - Dave Cole,
> - Sean McBride,
> - Will Schroeder,
> - me,
> - Ben Boeckel,
> - Chuck Atkins,
> - Shawn Waldon,
> - Marcus Hanwell,
> - Dave DeMarle,
> - Jamie Wright,
> - Tim Meehan.
>
> If you are not on this list and you are interested in attending, please
> let me know.
>
> Best,
> -berk
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
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/20140917/cd2acdef/attachment.html>

From david.gobbi at gmail.com  Wed Sep 17 13:59:07 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 17 Sep 2014 11:59:07 -0600
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
 <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>
Message-ID: <CANwS1=GdeFeXuJo+cvDV+pArMxW96fH3-g_n1z=8UAE5aYSJ3g@mail.gmail.com>

I can send some photons and be there as a telepresence.


On Wed, Sep 17, 2014 at 11:39 AM, Will Schroeder
<will.schroeder at kitware.com> wrote:
> There is lots of room at our offices. And especially those in nearby areas
> like Cambridge, MA (e.g., Steve P. and Nicole) we'd love to have you come
> visit.
>
> W
>
> On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>>
>> Hi folks,
>>
>> This is a reminder that on October 2nd, we are holding a bug tracker
>> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
>> can. We will be hosting folks at our Clifton Park office as well as holding
>> a Google Hangout for those attending remotely. Here is the list of attendees
>> that I know so far:
>>
>> - Bill Lorensen,
>> - Dave Cole,
>> - Sean McBride,
>> - Will Schroeder,
>> - me,
>> - Ben Boeckel,
>> - Chuck Atkins,
>> - Shawn Waldon,
>> - Marcus Hanwell,
>> - Dave DeMarle,
>> - Jamie Wright,
>> - Tim Meehan.
>>
>> If you are not on this list and you are interested in attending, please
>> let me know.
>>
>> Best,
>> -berk

From biddisco at cscs.ch  Wed Sep 17 14:07:15 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Wed, 17 Sep 2014 18:07:15 +0000
Subject: [vtk-developers] libc++ problem on OSX
Message-ID: <D03F9A72.6859C%biddisco@cscs.ch>

For compatibility with some other libraries, I tried compiling paraview on OSX using libc++ instead of libstdc++.
Everything is fine except some link errors coing from vtkCocoa? classes. I have never worked with these before, but see all the classes causing me trouble emanate from code which has an mm extension.

Looking at the make rules, I cannot see anything obviously wrong, but does anyone know of a reason why the vtkCocoa classes cause this trouble. Are they using a libstdc++ from the system (via some cocoa related link) which I can?t work around?

Thanks for any hints.

JB

Linking CXX shared library ../../../lib/libvtkRenderingOpenGL-pv4.2.dylib
Undefined symbols for architecture x86_64:
  "vtkObjectBase::PrintHeader(std::ostream&, vtkIndent)", referenced from:
      vtable for vtkCocoaRenderWindowInteractor in vtkCocoaRenderWindowInteractor.mm.o
      vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
  "vtkObjectBase::PrintTrailer(std::ostream&, vtkIndent)", referenced from:
      vtable for vtkCocoaRenderWindowInteractor in vtkCocoaRenderWindowInteractor.mm.o
      vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
  "vtkOpenGLRenderWindow::PrintSelf(std::ostream&, vtkIndent)", referenced from:
      vtkCocoaRenderWindow::PrintSelf(std::ostream&, vtkIndent) in vtkCocoaRenderWindow.mm.o
  "vtkRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)", referenced from:
      vtkCocoaRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent) in vtkCocoaRenderWindowInteractor.mm.o
  "std::string::c_str() const", referenced from:
      vtkCocoaRenderWindow::ReportCapabilities() in vtkCocoaRenderWindow.mm.o
  "std::string::length() const", referenced from:
      vtkCocoaRenderWindow::ReportCapabilities() in vtkCocoaRenderWindow.mm.o

From robert.maynard at kitware.com  Wed Sep 17 14:17:21 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 17 Sep 2014 14:17:21 -0400
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <D03F9A72.6859C%biddisco@cscs.ch>
References: <D03F9A72.6859C%biddisco@cscs.ch>
Message-ID: <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>

If my memory is correct CMake doesn't have explicit global objc or objc++
flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
 property on each mm file to be "-stdlib=libstdc++"

On Wed, Sep 17, 2014 at 2:07 PM, Biddiscombe, John A. <biddisco at cscs.ch>
wrote:

> For compatibility with some other libraries, I tried compiling paraview on
> OSX using libc++ instead of libstdc++.
> Everything is fine except some link errors coing from vtkCocoa? classes. I
> have never worked with these before, but see all the classes causing me
> trouble emanate from code which has an mm extension.
>
> Looking at the make rules, I cannot see anything obviously wrong, but does
> anyone know of a reason why the vtkCocoa classes cause this trouble. Are
> they using a libstdc++ from the system (via some cocoa related link) which
> I can?t work around?
>
> Thanks for any hints.
>
> JB
>
> Linking CXX shared library ../../../lib/libvtkRenderingOpenGL-pv4.2.dylib
> Undefined symbols for architecture x86_64:
>   "vtkObjectBase::PrintHeader(std::ostream&, vtkIndent)", referenced from:
>       vtable for vtkCocoaRenderWindowInteractor in
> vtkCocoaRenderWindowInteractor.mm.o
>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>   "vtkObjectBase::PrintTrailer(std::ostream&, vtkIndent)", referenced from:
>       vtable for vtkCocoaRenderWindowInteractor in
> vtkCocoaRenderWindowInteractor.mm.o
>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>   "vtkOpenGLRenderWindow::PrintSelf(std::ostream&, vtkIndent)", referenced
> from:
>       vtkCocoaRenderWindow::PrintSelf(std::ostream&, vtkIndent) in
> vtkCocoaRenderWindow.mm.o
>   "vtkRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)",
> referenced from:
>       vtkCocoaRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)
> in vtkCocoaRenderWindowInteractor.mm.o
>   "std::string::c_str() const", referenced from:
>       vtkCocoaRenderWindow::ReportCapabilities() in
> vtkCocoaRenderWindow.mm.o
>   "std::string::length() const", referenced from:
>       vtkCocoaRenderWindow::ReportCapabilities() in
> vtkCocoaRenderWindow.mm.o
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140917/b351edbd/attachment.html>

From pieper at isomics.com  Wed Sep 17 14:27:39 2014
From: pieper at isomics.com (Steve Pieper)
Date: Wed, 17 Sep 2014 14:27:39 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CANwS1=GdeFeXuJo+cvDV+pArMxW96fH3-g_n1z=8UAE5aYSJ3g@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
 <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>
 <CANwS1=GdeFeXuJo+cvDV+pArMxW96fH3-g_n1z=8UAE5aYSJ3g@mail.gmail.com>
Message-ID: <CADkb7uNf7+ha6D5eTEt3mKramq0mYU8PmvrW+cVTxxu+7oHw1Q@mail.gmail.com>

I'm on vacation that day but you all have my thanks and best wishes!
On Sep 17, 2014 1:59 PM, "David Gobbi" <david.gobbi at gmail.com> wrote:

> I can send some photons and be there as a telepresence.
>
>
> On Wed, Sep 17, 2014 at 11:39 AM, Will Schroeder
> <will.schroeder at kitware.com> wrote:
> > There is lots of room at our offices. And especially those in nearby
> areas
> > like Cambridge, MA (e.g., Steve P. and Nicole) we'd love to have you come
> > visit.
> >
> > W
> >
> > On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
> > wrote:
> >>
> >> Hi folks,
> >>
> >> This is a reminder that on October 2nd, we are holding a bug tracker
> >> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as
> we
> >> can. We will be hosting folks at our Clifton Park office as well as
> holding
> >> a Google Hangout for those attending remotely. Here is the list of
> attendees
> >> that I know so far:
> >>
> >> - Bill Lorensen,
> >> - Dave Cole,
> >> - Sean McBride,
> >> - Will Schroeder,
> >> - me,
> >> - Ben Boeckel,
> >> - Chuck Atkins,
> >> - Shawn Waldon,
> >> - Marcus Hanwell,
> >> - Dave DeMarle,
> >> - Jamie Wright,
> >> - Tim Meehan.
> >>
> >> If you are not on this list and you are interested in attending, please
> >> let me know.
> >>
> >> Best,
> >> -berk
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140917/e3853105/attachment-0001.html>

From david.gobbi at gmail.com  Wed Sep 17 14:34:56 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 17 Sep 2014 12:34:56 -0600
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
References: <D03F9A72.6859C%biddisco@cscs.ch>
 <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
Message-ID: <CANwS1=E2XmBinosj4N9_dt_hX4hsWDWp1OHB-ZAE_BothYLbCg@mail.gmail.com>

VTK should be compiling just find with libc++ now, in fact I've done so
many times.  AFAIK it is an all-or-nothing thing: compile everything with
libc++, or compile everything with libstdc++.  Mixing the two will result in
link errors just like the ones that John reported.

 - David


On Wed, Sep 17, 2014 at 12:17 PM, Robert Maynard
<robert.maynard at kitware.com> wrote:
> If my memory is correct CMake doesn't have explicit global objc or objc++
> flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> property on each mm file to be "-stdlib=libstdc++"
>
> On Wed, Sep 17, 2014 at 2:07 PM, Biddiscombe, John A. <biddisco at cscs.ch>
> wrote:
>>
>> For compatibility with some other libraries, I tried compiling paraview on
>> OSX using libc++ instead of libstdc++.
>> Everything is fine except some link errors coing from vtkCocoa... classes. I
>> have never worked with these before, but see all the classes causing me
>> trouble emanate from code which has an mm extension.
>>
>> Looking at the make rules, I cannot see anything obviously wrong, but does
>> anyone know of a reason why the vtkCocoa classes cause this trouble. Are
>> they using a libstdc++ from the system (via some cocoa related link) which I
>> can't work around?
>>
>> Thanks for any hints.
>>
>> JB
>>
>> Linking CXX shared library ../../../lib/libvtkRenderingOpenGL-pv4.2.dylib
>> Undefined symbols for architecture x86_64:
>>   "vtkObjectBase::PrintHeader(std::ostream&, vtkIndent)", referenced from:
>>       vtable for vtkCocoaRenderWindowInteractor in
>> vtkCocoaRenderWindowInteractor.mm.o
>>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>>   "vtkObjectBase::PrintTrailer(std::ostream&, vtkIndent)", referenced
>> from:
>>       vtable for vtkCocoaRenderWindowInteractor in
>> vtkCocoaRenderWindowInteractor.mm.o
>>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>>   "vtkOpenGLRenderWindow::PrintSelf(std::ostream&, vtkIndent)", referenced
>> from:
>>       vtkCocoaRenderWindow::PrintSelf(std::ostream&, vtkIndent) in
>> vtkCocoaRenderWindow.mm.o
>>   "vtkRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)",
>> referenced from:
>>       vtkCocoaRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)
>> in vtkCocoaRenderWindowInteractor.mm.o
>>   "std::string::c_str() const", referenced from:
>>       vtkCocoaRenderWindow::ReportCapabilities() in
>> vtkCocoaRenderWindow.mm.o
>>   "std::string::length() const", referenced from:
>>       vtkCocoaRenderWindow::ReportCapabilities() in
>> vtkCocoaRenderWindow.mm.o

From sean at rogue-research.com  Wed Sep 17 14:38:08 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 17 Sep 2014 14:38:08 -0400
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
References: <D03F9A72.6859C%biddisco@cscs.ch>
 <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
Message-ID: <20140917183808.63627212@mail.rogue-research.com>

On Wed, 17 Sep 2014 14:17:21 -0400, Robert Maynard said:

>If my memory is correct CMake doesn't have explicit global objc or objc++
>flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> property on each mm file to be "-stdlib=libstdc++"

CMake doesn't (bug 4756) but VTK does: "VTK_REQUIRED_OBJCXX_FLAGS"

<http://public.kitware.com/Bug/view.php?id=4756>

VTK does work with libc++ and I have several dashboards that use it.  The link error does suggest however that some files are using libstdc++ and some others using libc++.  Maybe try adding -stdlib=libc++ to VTK_REQUIRED_OBJCXX_FLAGS also, though I don't believe I've had to do 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 robert.maynard at kitware.com  Wed Sep 17 14:52:45 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 17 Sep 2014 14:52:45 -0400
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <20140917183808.63627212@mail.rogue-research.com>
References: <D03F9A72.6859C%biddisco@cscs.ch>
 <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
 <20140917183808.63627212@mail.rogue-research.com>
Message-ID: <CAFzjYVq7Kif8FMm2X6zYENa+WFP01YTrsrwcQRhpSKSYhaSpSw@mail.gmail.com>

I completely forgot about VTK_REQUIRED_OBJCXX_FLAGS.

On Wed, Sep 17, 2014 at 2:38 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Wed, 17 Sep 2014 14:17:21 -0400, Robert Maynard said:
>
> >If my memory is correct CMake doesn't have explicit global objc or objc++
> >flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> > property on each mm file to be "-stdlib=libstdc++"
>
> CMake doesn't (bug 4756) but VTK does: "VTK_REQUIRED_OBJCXX_FLAGS"
>
> <http://public.kitware.com/Bug/view.php?id=4756>
>
> VTK does work with libc++ and I have several dashboards that use it.  The
> link error does suggest however that some files are using libstdc++ and
> some others using libc++.  Maybe try adding -stdlib=libc++ to
> VTK_REQUIRED_OBJCXX_FLAGS also, though I don't believe I've had to do
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140917/888a4c57/attachment.html>

From biddisco at cscs.ch  Wed Sep 17 15:15:03 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Wed, 17 Sep 2014 19:15:03 +0000
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <CAFzjYVq7Kif8FMm2X6zYENa+WFP01YTrsrwcQRhpSKSYhaSpSw@mail.gmail.com>
Message-ID: <D03FAA0A.685BD%biddisco@cscs.ch>

Thanks to all of you,

In my cache there was a VTK_REQUIRED_OBJCXX_FLAGS libstdc++ setting. I put that right and now I?m past that problem.

Yours

JB

From: Robert Maynard <robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>>
Date: Wednesday 17 September 2014 20:52
To: Sean McBride <sean at rogue-research.com<mailto:sean at rogue-research.com>>
Cc: cscs <biddisco at cscs.ch<mailto:biddisco at cscs.ch>>, VTK Developers <vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>>
Subject: Re: [vtk-developers] libc++ problem on OSX

I completely forgot about VTK_REQUIRED_OBJCXX_FLAGS.

On Wed, Sep 17, 2014 at 2:38 PM, Sean McBride <sean at rogue-research.com<mailto:sean at rogue-research.com>> wrote:
On Wed, 17 Sep 2014 14:17:21 -0400, Robert Maynard said:

>If my memory is correct CMake doesn't have explicit global objc or objc++
>flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> property on each mm file to be "-stdlib=libstdc++"

CMake doesn't (bug 4756) but VTK does: "VTK_REQUIRED_OBJCXX_FLAGS"

<http://public.kitware.com/Bug/view.php?id=4756>

VTK does work with libc++ and I have several dashboards that use it.  The link error does suggest however that some files are using libstdc++ and some others using libc++.  Maybe try adding -stdlib=libc++ to VTK_REQUIRED_OBJCXX_FLAGS also, though I don't believe I've had to do that...

Cheers,

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




From berk.geveci at kitware.com  Thu Sep 18 11:10:01 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Thu, 18 Sep 2014 11:10:01 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
Message-ID: <CAE32kpWK9KF=7SJv_etzJ+KSAi5wiNk3_Qfy95MzEWtJP50VwQ@mail.gmail.com>

Hi folks,

I just created a public Google event/hangout for our hack-a-ton:

https://plus.google.com/events/cd0s6so0ijo45dsulg8and8p5tg

Looking forward to seeing you there or in person at Kitware.

-berk

On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Hi folks,
>
> This is a reminder that on October 2nd, we are holding a bug tracker
> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
> can. We will be hosting folks at our Clifton Park office as well as holding
> a Google Hangout for those attending remotely. Here is the list of
> attendees that I know so far:
>
> - Bill Lorensen,
> - Dave Cole,
> - Sean McBride,
> - Will Schroeder,
> - me,
> - Ben Boeckel,
> - Chuck Atkins,
> - Shawn Waldon,
> - Marcus Hanwell,
> - Dave DeMarle,
> - Jamie Wright,
> - Tim Meehan.
>
> If you are not on this list and you are interested in attending, please
> let me know.
>
> Best,
> -berk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140918/31754d1d/attachment.html>

From rostislav.khlebnikov at kcl.ac.uk  Thu Sep 18 15:14:29 2014
From: rostislav.khlebnikov at kcl.ac.uk (Rostislav Khlebnikov)
Date: Thu, 18 Sep 2014 20:14:29 +0100
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
 <54171CC6.9030407@kcl.ac.uk>
 <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>
Message-ID: <541B2F15.8030500@kcl.ac.uk>

Hi,

the code is attached. As I said it's quite messy - just ask me if you 
can't figure out something. The functions I added start with small 
letters as opposed to the copy-pasted and modified from VTK which start 
with a capital letter.

Rostislav.


On 15/09/2014 19:28, Gerrick Bivins wrote:
>
> Yes. I would definitely be interested in seeing the code.
>
> Gerrick
>
> *From:*Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
> *Sent:* Monday, September 15, 2014 12:07 PM
> *To:* Gerrick Bivins; Berk Geveci
> *Cc:* VTK Developers
> *Subject:* Re: [vtk-developers] vtkCutter modification to use 
> vtkCellLocator
>
> Hi,
>
> well, basically, I feel that it is necessary to create a proper change 
> to use Gerrit workflow successfully. Unfortunately, I don't quite have 
> the time to do this properly for several reasons. One of them is that 
> I actually don't need this change - for my project I integrated the 
> CGAL-based cutting approach with AABB_tree which outperforms my VTK 
> test - for example for the same test with 500k triangles CGAL-based 
> cutting takes only 2ms. This will soon be integrated to MITK (in case 
> anyone is interested, the pull request can be found here: 
> https://github.com/MITK/MITK/pull/73). Making a proper VTK change 
> would involve quite a lot of effort. Given that vtkCutter is very 
> general and rejecting the octree nodes might be complex for arbitrary 
> implicit functions, it seems to require quite a lot of work to avoid 
> incorrect usage.
>
> I can clean up the code a bit and post it to the mailing list if you 
> are interested.
>
> All best,
>    Rostislav.
>
> On 15/09/2014 15:02, Gerrick Bivins wrote:
>
>     Hi Rostislav,
>
>     Did anything happen with this?
>
>     I would definitely be interested in this
>     capability/feature/improvement.
>
>     Gerrick
>
>     *From:*vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On
>     Behalf Of *Berk Geveci
>     *Sent:* Tuesday, August 12, 2014 11:44 AM
>     *To:* Rostislav Khlebnikov
>     *Cc:* VTK Developers
>     *Subject:* Re: [vtk-developers] vtkCutter modification to use
>     vtkCellLocator
>
>     Hi Rostislav,
>
>     This is great. Can you push the code to Gerrit
>     (http://review.source.kitware.com/)?
>
>     Best,
>
>     -berk
>
>     On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov
>     <rostislav.khlebnikov at kcl.ac.uk
>     <mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
>
>     Hi guys,
>
>     just thought that the VTK developers might be interested in the
>     test I made recently.
>
>     Bascially what I did is subclass the vtkCellLocator to implement
>     the visitor pattern. It allows to filter the octree nodes (e.g.
>     reject the octree nodes that are of no interest early) and for
>     leafs, to visit the cells of the polydata.
>     Then, I subclassed the vtkCutter to use this cell locator instead
>     of straight iteration over cells. Likely for very complex implicit
>     cutting functions this wouldnt be of any benefit. However, for
>     those which can test bboxes as being of interest or not, rejecting
>     whole subtrees, such as vtkPlane, it is very useful. I tested it
>     on a surface with 500k triangles and the cutter performance went
>     from 88ms per cut to 14ms.
>
>     The code I made is quite ugly due to limited extensibility of
>     vtkCutter, so I had to copy-paste the RequestData method and make
>     my changes instead of, say, overriding IterateCells method which
>     would just provide the cells to cut through.
>
>     But anyway, I was wondering if you guys are intersted in this kind
>     of functionality? Would you like me to send you the code?
>
>     All best,
>        Rostislav.
>
>     _______________________________________________
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>     <http://www.kitware.com/opensource/opensource.html>
>
>     Follow this link to subscribe/unsubscribe:
>     http://public.kitware.com/mailman/listinfo/vtk-developers
>
>     ------------------------------------------------------------------------
>
>     This e-mail, including any attached files, may contain
>     confidential and privileged information for the sole use of the
>     intended recipient. Any review, use, distribution, or disclosure
>     by others is strictly prohibited. If you are not the intended
>     recipient (or authorized to receive information for the intended
>     recipient), please contact the sender by reply e-mail and delete
>     all copies of this message.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140918/8075622e/attachment-0001.html>
-------------- next part --------------
#include <functional>
#include <queue>
#include <chrono>

#include <vtkSphereSource.h>

#include <vtkPolyData.h>
#include <vtkPolyDataReader.h>
#include <vtkCutter.h>
#include <vtkPlane.h>
#include <vtkIdList.h>
#include <vtkCell.h>

#include <vtkCellLocator.h>
#include <vtkCutter.h>
#include <vtkBox.h>
#include <vtkInformation.h>
#include <vtkInformationVector.h>
#include <vtkRectilinearGrid.h>
#include <vtkDoubleArray.h>
#include <vtkCellArray.h>
#include <vtkPointData.h>
#include <vtkCellData.h>
#include <vtkIncrementalPointLocator.h>
#include <vtkSmartPointer.h>
#include <vtkPolygonBuilder.h>
#include <vtkXMLPolyDataWriter.h>
#include <vtkCleanPolyData.h>
#include <vtkQuad.h>

class vtkContourHelper
{
public:
    vtkContourHelper(vtkIncrementalPointLocator *locator,
        vtkCellArray *verts,
        vtkCellArray *lines,
        vtkCellArray* polys,
        vtkPointData *inPd,
        vtkCellData *inCd,
        vtkPointData* outPd,
        vtkCellData *outCd,
        int estimatedSize,
        bool outputTriangles);
    ~vtkContourHelper();
    void Contour(vtkCell* cell, double value, vtkDataArray *cellScalars, vtkIdType cellId);

private:
    vtkIncrementalPointLocator* Locator;
    vtkCellArray* Verts;
    vtkCellArray* Lines;
    vtkCellArray* Polys;
    vtkPointData* InPd;
    vtkCellData* InCd;
    vtkPointData* OutPd;
    vtkCellData* OutCd;
    vtkSmartPointer<vtkCellData> TriOutCd;

    vtkCellArray* Tris;
    vtkPolygonBuilder PolyBuilder;
    vtkIdList* Poly;
    bool GenerateTriangles;
};

#include "vtkIncrementalPointLocator.h"
#include "vtkCellArray.h"
#include "vtkPointData.h"
#include "vtkCellData.h"
#include "vtkPolygonBuilder.h"
#include "vtkIdList.h"
#include "vtkCell.h"
#include "vtkDataArray.h"

vtkContourHelper::vtkContourHelper(vtkIncrementalPointLocator *locator,
    vtkCellArray *verts,
    vtkCellArray *lines,
    vtkCellArray* polys,
    vtkPointData *inPd,
    vtkCellData *inCd,
    vtkPointData* outPd,
    vtkCellData *outCd,
    int estimatedSize,
    bool outputTriangles) :
    Locator(locator),
    Verts(verts),
    Lines(lines),
    Polys(polys),
    InPd(inPd),
    InCd(inCd),
    OutPd(outPd),
    OutCd(outCd),
    GenerateTriangles(outputTriangles)
{
    this->Tris = vtkCellArray::New();
    this->TriOutCd = vtkCellData::New();
    if (this->GenerateTriangles)
    {
        this->Tris->Allocate(estimatedSize, estimatedSize / 2);
        this->TriOutCd->Initialize();
    }
    this->Poly = vtkIdList::New();
}

vtkContourHelper::~vtkContourHelper()
{
    this->Tris->Delete();
    this->TriOutCd->Delete();
    this->Poly->FastDelete();
}

void vtkContourHelper::Contour(vtkCell* cell, double value, vtkDataArray *cellScalars, vtkIdType cellId)
{
    bool mergeTriangles = (!this->GenerateTriangles) && cell->GetCellDimension() == 3;
    vtkCellData* outCD;
    vtkCellArray* outPoly;
    if (mergeTriangles)
    {
        outPoly = this->Tris;
        outCD = this->TriOutCd;
    }
    else
    {
        outPoly = this->Polys;
        outCD = this->OutCd;
    }
    cell->Contour(value, cellScalars, this->Locator, this->Verts, this->Lines,
        outPoly, this->InPd, this->OutPd, this->InCd, cellId, outCD);
    if (mergeTriangles)
    {
        this->PolyBuilder.Reset();

        vtkIdType cellSize;
        vtkIdType* cellVerts;
        while (this->Tris->GetNextCell(cellSize, cellVerts))
        {
            if (cellSize == 3)
            {
                this->PolyBuilder.InsertTriangle(cellVerts);
            }
            else //for whatever reason, the cell contouring is already outputing polys
            {
                vtkIdType outCellId = this->Polys->InsertNextCell(cellSize, cellVerts);
                this->OutCd->CopyData(this->InCd, cellId, outCellId);
            }
        }

        this->PolyBuilder.GetPolygon(this->Poly);
        if (this->Poly->GetNumberOfIds() != 0)
        {
            vtkIdType outCellId = this->Polys->InsertNextCell(this->Poly);
            this->OutCd->CopyData(this->InCd, cellId, outCellId);
        }
    }
}

class CellLocatorVisitor : public vtkCellLocator {
public:
    vtkTypeMacro(CellLocatorVisitor, vtkCellLocator);

    static CellLocatorVisitor *New();

    int getBoundsByIndex(int idx, double bounds[6])
    {
        int nSubdiv = 1;
        int level = 0;
        int nNodes = 1;

        while (idx >= nNodes) {
            nSubdiv *= 2;
            nNodes += nSubdiv * nSubdiv * nSubdiv;
            level++;
        }

        int firstInLevel = nNodes - nSubdiv*nSubdiv*nSubdiv;

        double sizeWithinLevel[3];
        for (int i = 0; i < 3; ++i) {
            sizeWithinLevel[i] = (this->Bounds[2 * i + 1] - this->Bounds[2 * i]) / nSubdiv;
        }

        idx -= firstInLevel;

        for (int i = 0; i < 3; ++i) {
            bounds[2 * i] = this->Bounds[2 * i] + sizeWithinLevel[i] * (idx % nSubdiv);
            bounds[2 * i + 1] = bounds[2 * i] + sizeWithinLevel[i];
            idx /= nSubdiv;
        }
        return level;
    }

    void getChildren(int idx, int children[8])
    {
        int nSubdiv = 1;
        int level = 0;
        int nNodes = 1;

        while (idx >= nNodes) {
            nSubdiv *= 2;
            nNodes += nSubdiv * nSubdiv * nSubdiv;
            level++;
        }

        int firstInParentLevel = nNodes - nSubdiv*nSubdiv*nSubdiv;

        idx -= firstInParentLevel;

        int firstChildIndex = nNodes;
        int nNodesInDirection = 2;
        for (int i = 0; i < 3; ++i) {
            firstChildIndex += (idx % (nSubdiv)) * nNodesInDirection;
            nNodesInDirection *= 2 * nSubdiv;
            idx /= (nSubdiv);
        }

        int outit = 0;
        for (int k = 0; k < 2; k++) {
            for (int j = 0; j < 2; j++) {
                for (int i = 0; i < 2; i++) {
                    children[outit++] = firstChildIndex + i + 2 * nSubdiv * j + 4 * nSubdiv * nSubdiv * k;
                }
            }
        }
    }
    void visitCells(std::function<bool(double[6])> cellChecker, std::function<void(vtkCell*, int)> visitor)
    {
        this->BuildLocatorIfNeeded();
        this->ClearCellHasBeenVisited();

        std::queue<int> octantsToVisit;

        octantsToVisit.push(0);

        while (!octantsToVisit.empty()) {
            int currentOctant = octantsToVisit.front();
            octantsToVisit.pop();

            // Get the octant bounds 
            double bounds[6];
            int level = getBoundsByIndex(currentOctant, bounds);

            if (cellChecker(bounds)) {
                vtkIdList* cellsIds = this->Tree[currentOctant];
                if (level == this->Level) {
                    // Leaf
                    if (!cellsIds) {
                        // Empty leaf
                        continue;
                    }

                    for (int i = 0; i < cellsIds->GetNumberOfIds(); ++i) {
                        int cellId = cellsIds->GetId(i);
                        if (!this->CellHasBeenVisited[cellId]) {
                            visitor(this->DataSet->GetCell(cellId), cellId);
                            this->CellHasBeenVisited[cellId] = 1;
                        }
                    }
                }
                else {
                    vtkIdList* cellsIds = this->Tree[currentOctant];
                    if (cellsIds != (void*)1) {
                        continue;
                    }

                    int children[8];

                    // Get children
                    getChildren(currentOctant, children);
                    for (int i = 0; i < 8; ++i) {
                        octantsToVisit.push(children[i]);
                    }
                }
            }
        }
    }
};

CellLocatorVisitor* CellLocatorVisitor::New()
{
    return new CellLocatorVisitor;
}

class CutterWithLocator : public vtkCutter {
public:
    vtkTypeMacro(CutterWithLocator, vtkCutter);

    static CutterWithLocator *New();

    void setLocator(CellLocatorVisitor* locator)
    {
        _locator = locator;
    }

    int RequestData(
        vtkInformation *request,
        vtkInformationVector **inputVector,
        vtkInformationVector *outputVector)
    {
        // get the info objects
        vtkInformation *inInfo = inputVector[0]->GetInformationObject(0);
        vtkInformation *outInfo = outputVector->GetInformationObject(0);

        // get the input and output
        vtkDataSet *input = vtkDataSet::SafeDownCast(
            inInfo->Get(vtkDataObject::DATA_OBJECT()));
        vtkPolyData *output = vtkPolyData::SafeDownCast(
            outInfo->Get(vtkDataObject::DATA_OBJECT()));

        vtkDebugMacro(<< "Executing cutter");
        if (!this->CutFunction)
        {
            vtkErrorMacro("No cut function specified");
            return 0;
        }

        if (!input)
        {
            // this could be a table in a multiblock structure, i.e. no cut!
            return 0;
        }

        if (input->GetNumberOfPoints() < 1 || this->GetNumberOfContours() < 1)
        {
            return 1;
        }

        if ((input->GetDataObjectType() == VTK_STRUCTURED_POINTS ||
            input->GetDataObjectType() == VTK_IMAGE_DATA) &&
            input->GetCell(0) && input->GetCell(0)->GetCellDimension() >= 3)
        {
            this->StructuredPointsCutter(input, output, request, inputVector, outputVector);
        }
        else if (input->GetDataObjectType() == VTK_STRUCTURED_GRID &&
            input->GetCell(0) &&
            input->GetCell(0)->GetCellDimension() >= 3)
        {
            this->StructuredGridCutter(input, output);
        }
        else if (input->GetDataObjectType() == VTK_RECTILINEAR_GRID &&
            static_cast<vtkRectilinearGrid *>(input)->GetDataDimension() == 3)
        {
            this->RectilinearGridCutter(input, output);
        }
        else if (input->GetDataObjectType() == VTK_UNSTRUCTURED_GRID)
        {
            vtkDebugMacro(<< "Executing Unstructured Grid Cutter");
            this->UnstructuredGridCutter(input, output);
        }
        else
        {
            vtkDebugMacro(<< "Executing DataSet Cutter");
            this->DataSetVisitorCutter(input, output);
        }

        return 1;
    }

    //----------------------------------------------------------------------------
    void DataSetVisitorCutter(vtkDataSet *input, vtkPolyData *output)
    {
        vtkIdType i;
        int iter;
        vtkPoints *cellPts;
        vtkDoubleArray *cellScalars;
        vtkCellArray *newVerts, *newLines, *newPolys;
        vtkPoints *newPoints;
        vtkDoubleArray *cutScalars;
        double value, s;
        vtkIdType estimatedSize, numCells = input->GetNumberOfCells();
        vtkIdType numPts = input->GetNumberOfPoints();
        int numCellPts;
        vtkPointData *inPD, *outPD;
        vtkCellData *inCD = input->GetCellData(), *outCD = output->GetCellData();
        vtkIdList *cellIds;
        int numContours = this->ContourValues->GetNumberOfContours();
        int abortExecute = 0;

        cellScalars = vtkDoubleArray::New();

        // Create objects to hold output of contour operation
        //
        estimatedSize = static_cast<vtkIdType>(
            pow(static_cast<double>(numCells), .75)) * numContours;
        estimatedSize = estimatedSize / 1024 * 1024; //multiple of 1024
        if (estimatedSize < 1024)
        {
            estimatedSize = 1024;
        }

        newPoints = vtkPoints::New();
        // set precision for the points in the output
        if (this->OutputPointsPrecision == vtkAlgorithm::DEFAULT_PRECISION)
        {
            vtkPointSet *inputPointSet = vtkPointSet::SafeDownCast(input);
            if (inputPointSet)
            {
                newPoints->SetDataType(inputPointSet->GetPoints()->GetDataType());
            }
            else
            {
                newPoints->SetDataType(VTK_FLOAT);
            }
        }
        else if (this->OutputPointsPrecision == vtkAlgorithm::SINGLE_PRECISION)
        {
            newPoints->SetDataType(VTK_FLOAT);
        }
        else if (this->OutputPointsPrecision == vtkAlgorithm::DOUBLE_PRECISION)
        {
            newPoints->SetDataType(VTK_DOUBLE);
        }
        newPoints->Allocate(estimatedSize, estimatedSize / 2);
        newVerts = vtkCellArray::New();
        newVerts->Allocate(estimatedSize, estimatedSize / 2);
        newLines = vtkCellArray::New();
        newLines->Allocate(estimatedSize, estimatedSize / 2);
        newPolys = vtkCellArray::New();
        newPolys->Allocate(estimatedSize, estimatedSize / 2);
        cutScalars = vtkDoubleArray::New();
        cutScalars->SetNumberOfTuples(numPts);

        // Interpolate data along edge. If generating cut scalars, do necessary setup
        if (this->GenerateCutScalars)
        {
            inPD = vtkPointData::New();
            inPD->ShallowCopy(input->GetPointData());//copies original attributes
            inPD->SetScalars(cutScalars);
        }
        else
        {
            inPD = input->GetPointData();
        }
        outPD = output->GetPointData();
        outPD->InterpolateAllocate(inPD, estimatedSize, estimatedSize / 2);
        outCD->CopyAllocate(inCD, estimatedSize, estimatedSize / 2);

        // locator used to merge potentially duplicate points
        if (this->Locator == NULL)
        {
            this->CreateDefaultLocator();
        }
        this->Locator->InitPointInsertion(newPoints, input->GetBounds());

        // Loop over all points evaluating scalar function at each point
        //
        for (i = 0; i < numPts; i++)
        {
            s = this->CutFunction->FunctionValue(input->GetPoint(i));
            cutScalars->SetComponent(i, 0, s);
        }

        // Compute some information for progress methods
        //
        vtkIdType numCuts = numContours*numCells;
        vtkIdType progressInterval = numCuts / 20 + 1;
        int cut = 0;

        vtkContourHelper helper(this->Locator, newVerts, newLines, newPolys, inPD, inCD, outPD, outCD, estimatedSize, this->GenerateTriangles != 0);
        if (true || this->SortBy == VTK_SORT_BY_CELL)
        {
            // Loop over all contour values.  Then for each contour value,
            // loop over all cells.
            //
            // This is going to have a problem if the input has 2D and 3D cells.
            // I am fixing a bug where cell data is scrambled becauses with
            // vtkPolyData output, verts and lines have lower cell ids than triangles.
            for (iter = 0; iter < numContours && !abortExecute; iter++)
            {
                _locator->visitCells(
                    [&](double bounds[6]) {
                    double sign = this->CutFunction->EvaluateFunction(bounds[0], bounds[2], bounds[4]);

                    bool oneSide = true;
                    for (int i = 0; i < 2 && oneSide; ++i) {
                        for (int j = 2; j < 4 && oneSide; ++j) {
                            for (int k = 4; k < 6; ++k) {
                                double sign2 = this->CutFunction->EvaluateFunction(bounds[i], bounds[j], bounds[k]);
                                if (sign * sign2 <= 0) {
                                    oneSide = false;
                                    break;
                                }
                            }
                        }
                    }

                    return !oneSide;
                },




                    [&](vtkCell* cell, int cellId) {
                    if (!(++cut % progressInterval))
                    {
                        vtkDebugMacro(<< "Cutting #" << cut);
                        this->UpdateProgress(static_cast<double>(cut) / numCuts);
                        abortExecute = this->GetAbortExecute();
                    }

                    cellPts = cell->GetPoints();
                    cellIds = cell->GetPointIds();

                    numCellPts = cellPts->GetNumberOfPoints();
                    cellScalars->SetNumberOfTuples(numCellPts);
                    for (i = 0; i < numCellPts; i++)
                    {
                        s = cutScalars->GetComponent(cellIds->GetId(i), 0);
                        cellScalars->SetTuple(i, &s);
                    }

                    value = this->ContourValues->GetValue(iter);

                    helper.Contour(cell, value, cellScalars, cellId);
                });
            } // for all contour values
        } // sort by cell

        //         else // VTK_SORT_BY_VALUE:
        //         {
        //             // Three passes over the cells to process lower dimensional cells first.
        //             // For poly data output cells need to be added in the order:
        //             // verts, lines and then polys, or cell data gets mixed up.
        //             // A better solution is to have an unstructured grid output.
        //             // I create a table that maps cell type to cell dimensionality,
        //             // because I need a fast way to get cell dimensionality.
        //             // This assumes GetCell is slow and GetCellType is fast.
        //             // I do not like hard coding a list of cell types here,
        //             // but I do not want to add GetCellDimension(vtkIdType cellId)
        //             // to the vtkDataSet API.  Since I anticipate that the output
        //             // will change to vtkUnstructuredGrid.  This temporary solution
        //             // is acceptable.
        //             //
        //             int cellType;
        //             unsigned char cellTypeDimensions[VTK_NUMBER_OF_CELL_TYPES];
        //             vtkCutter::GetCellTypeDimensions(cellTypeDimensions);
        //             int dimensionality;
        //             // We skip 0d cells (points), because they cannot be cut (generate no data).
        //             for (dimensionality = 1; dimensionality <= 3; ++dimensionality)
        //             {
        //                 // Loop over all cells; get scalar values for all cell points
        //                 // and process each cell.
        //                 //
        //                 for (cellId = 0; cellId < numCells && !abortExecute; cellId++)
        //                 {
        //                     // I assume that "GetCellType" is fast.
        //                     cellType = input->GetCellType(cellId);
        //                     if (cellType >= VTK_NUMBER_OF_CELL_TYPES)
        //                     { // Protect against new cell types added.
        //                         vtkErrorMacro("Unknown cell type " << cellType);
        //                         continue;
        //                     }
        //                     if (cellTypeDimensions[cellType] != dimensionality)
        //                     {
        //                         continue;
        //                     }
        //                     input->GetCell(cellId, cell);
        //                     cellPts = cell->GetPoints();
        //                     cellIds = cell->GetPointIds();
        // 
        //                     numCellPts = cellPts->GetNumberOfPoints();
        //                     cellScalars->SetNumberOfTuples(numCellPts);
        //                     for (i = 0; i < numCellPts; i++)
        //                     {
        //                         s = cutScalars->GetComponent(cellIds->GetId(i), 0);
        //                         cellScalars->SetTuple(i, &s);
        //                     }
        // 
        //                     // Loop over all contour values.
        //                     for (iter = 0; iter < numContours && !abortExecute; iter++)
        //                     {
        //                         if (dimensionality == 3 && !(++cut % progressInterval))
        //                         {
        //                             vtkDebugMacro(<< "Cutting #" << cut);
        //                             this->UpdateProgress(static_cast<double>(cut) / numCuts);
        //                             abortExecute = this->GetAbortExecute();
        //                         }
        //                         value = this->ContourValues->GetValue(iter);
        //                         helper.Contour(cell, value, cellScalars, cellId);
        //                     } // for all contour values
        //                 } // for all cells
        //             } // for all dimensions.
        //         } // sort by value

        // Update ourselves.  Because we don't know upfront how many verts, lines,
        // polys we've created, take care to reclaim memory.
        //
        cellScalars->Delete();
        cutScalars->Delete();

        if (this->GenerateCutScalars)
        {
            inPD->Delete();
        }

        output->SetPoints(newPoints);
        newPoints->Delete();

        if (newVerts->GetNumberOfCells())
        {
            output->SetVerts(newVerts);
        }
        newVerts->Delete();

        if (newLines->GetNumberOfCells())
        {
            output->SetLines(newLines);
        }
        newLines->Delete();

        if (newPolys->GetNumberOfCells())
        {
            output->SetPolys(newPolys);
        }
        newPolys->Delete();

        this->Locator->Initialize();//release any extra memory
        output->Squeeze();
    }

    CellLocatorVisitor* _locator;
};

CutterWithLocator* CutterWithLocator::New()
{
    return new CutterWithLocator;
}

int main()
{
    auto sphereSource = vtkSmartPointer<vtkSphereSource>::New();
    sphereSource->SetPhiResolution(300);
    sphereSource->SetThetaResolution(500);
    sphereSource->Update();

    auto plane = vtkSmartPointer<vtkPlane>::New();
    plane->SetOrigin(0.2, 0.1, -0.1);

    vtkCutter* cutter = vtkCutter::New();
    cutter->SetCutFunction(plane);
    cutter->SetInputData(sphereSource->GetOutput());
    cutter->GenerateCutScalarsOff();

    int nIter = 100;

    auto start = std::chrono::high_resolution_clock::now();

    for (int i = 0; i < nIter; ++i) {
        cutter->Modified();
        cutter->Update();
    }

    auto end = std::chrono::high_resolution_clock::now();
    auto dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);

    std::cout << "Normal vtkCutter " << dur.count() / (float)nIter << "ms, " << cutter->GetOutput()->GetNumberOfCells() << " cells\n";

    CellLocatorVisitor* locator = CellLocatorVisitor::New();
    locator->SetDataSet(sphereSource->GetOutput());
    locator->BuildLocator();

    CutterWithLocator* cutter2 = CutterWithLocator::New();
    cutter2->setLocator(locator);
    cutter2->SetCutFunction(plane);
    cutter2->SetInputData(sphereSource->GetOutput());
    cutter2->GenerateCutScalarsOff();

    start = std::chrono::high_resolution_clock::now();

    for (int i = 0; i < nIter; ++i) {
        cutter2->Modified();
        cutter2->Update();
    }

    end = std::chrono::high_resolution_clock::now();
    dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);

    std::cout << "'New' cutter " << dur.count() / (float)nIter << "ms, " << cutter2->GetOutput()->GetNumberOfCells() << " cells\n";

    return EXIT_SUCCESS;
}

From josp.jorge at gmail.com  Fri Sep 19 06:40:57 2014
From: josp.jorge at gmail.com (Jorge Perez)
Date: Fri, 19 Sep 2014 12:40:57 +0200
Subject: [vtk-developers] Wrong/Strange result from
	vtkImplicitPolyDataDistance + vtkSampleFunction
Message-ID: <CAM2LniH0TkH4_5sNGisHxp4z8U28=v2RU+RALD+ad819=qdG4A@mail.gmail.com>

http://vtk.org/Bug/view.php?id=15003

Attached is a test code (Bug_ImplicitPolyDataDistance_01.tcl) to reproduce
a bug with a combination of vtkImplicitPolyDataDistance + vtkSampleFunction.

In this test a triangle mesh of only one connected component is set as
input to vtkImplicitPolyDataDistance then an implicit function is sampled
with vtkSampleFunction. The result is contoured with vtkImageMarchingCubes
and the vtkPolyData resulting from this last step shows more than one
connected component. The original component is reconstructed well but other
wrong components appear.

Attached is also the snapshot of the result.

The input mesh fix_mesh.vtk used in the test can be downloaded from
https://www.dropbox.com/s/x3iwjvyl56sxvs3/fix_mesh.vtk?dl=0

The test has been executed on release 6.1.

Any suggestion about how to fix that? Could it be due to wrong in the test
code?

best regards,

Jorge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bug_ImplicitPolyDataDistance_01.tcl
Type: application/x-tcl
Size: 1076 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0001.tcl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_mesh.png
Type: image/png
Size: 61349 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_mesh_contour.png
Type: image/png
Size: 57224 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0003.png>

From Gerrick.Bivins at halliburton.com  Fri Sep 19 07:30:16 2014
From: Gerrick.Bivins at halliburton.com (Gerrick Bivins)
Date: Fri, 19 Sep 2014 11:30:16 +0000
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <541B2F15.8030500@kcl.ac.uk>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
 <54171CC6.9030407@kcl.ac.uk>
 <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>
 <541B2F15.8030500@kcl.ac.uk>
Message-ID: <B0794D08412B1444B729850159888A9613C2B7CF@NP1EXMB026.corp.halliburton.com>

Thanks!
This is great! Hopefully someone can look at it and make the
modifications to get it checked in.

Gerrick

From: Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
Sent: Thursday, September 18, 2014 2:14 PM
To: Gerrick Bivins; Berk Geveci
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi,

the code is attached. As I said it's quite messy - just ask me if you can't figure out something. The functions I added start with small letters as opposed to the copy-pasted and modified from VTK which start with a capital letter.

Rostislav.

On 15/09/2014 19:28, Gerrick Bivins wrote:
Yes. I would definitely be interested in seeing the code.
Gerrick

From: Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
Sent: Monday, September 15, 2014 12:07 PM
To: Gerrick Bivins; Berk Geveci
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi,

well, basically, I feel that it is necessary to create a proper change to use Gerrit workflow successfully. Unfortunately, I don't quite have the time to do this properly for several reasons. One of them is that I actually don't need this change - for my project I integrated the CGAL-based cutting approach with AABB_tree which outperforms my VTK test - for example for the same test with 500k triangles CGAL-based cutting takes only 2ms. This will soon be integrated to MITK (in case anyone is interested, the pull request can be found here: https://github.com/MITK/MITK/pull/73). Making a proper VTK change would involve quite a lot of effort. Given that vtkCutter is very general and rejecting the octree nodes might be complex for arbitrary implicit functions, it seems to require quite a lot of work to avoid incorrect usage.

I can clean up the code a bit and post it to the mailing list if you are interested.

All best,
   Rostislav.


On 15/09/2014 15:02, Gerrick Bivins wrote:
Hi Rostislav,
Did anything happen with this?
I would definitely be interested in this capability/feature/improvement.

Gerrick

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Tuesday, August 12, 2014 11:44 AM
To: Rostislav Khlebnikov
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi Rostislav,

This is great. Can you push the code to Gerrit (http://review.source.kitware.com/)?

Best,
-berk


On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov <rostislav.khlebnikov at kcl.ac.uk<mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
Hi guys,

just thought that the VTK developers might be interested in the test I made recently.

Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata.
Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms.

The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through.

But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code?

All best,
   Rostislav.

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

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

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

________________________________
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.


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

From david.gobbi at gmail.com  Mon Sep 22 14:22:30 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 22 Sep 2014 12:22:30 -0600
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
Message-ID: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>

Hi All,

This is a question about streaming in an imaging pipeline.  Sometimes
I want to stream just part of whole extent through the pipeline, but
even more often, I want to pull through the whole extent even if a
downstream request is for just a single slice.

Is there a trivial filter in VTK that, regardless of the UpdateExtent
requested, will always request the WholeExtent from upstream?
I say "trivial" because it would indeed be a trivial filter to write.
Has anyone else ever written or used such a filter?

Basically, I'm looking for an easy way to turn streaming off at
any point in my pipeline, either by inserting a "non-streaming filter"
or by telling an existing filter not to stream.

 - David

From david.gobbi at gmail.com  Tue Sep 23 12:12:02 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 23 Sep 2014 10:12:02 -0600
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
In-Reply-To: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
References: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
Message-ID: <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>

Trying again:

Is there a flag that the user can set on a vtkAlgorithm to force it to
always request the whole extent from its input?

I'm guessing the answer is "no" because I don't see any code in
vtkStreamingDemandDrivenPipeline.cxx that would support such a
feature, but I'm wondering if I can get confirmation from other
developers who are familiar with the pipeline.

 - David


On Mon, Sep 22, 2014 at 12:22 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi All,
>
> This is a question about streaming in an imaging pipeline.  Sometimes
> I want to stream just part of whole extent through the pipeline, but
> even more often, I want to pull through the whole extent even if a
> downstream request is for just a single slice.
>
> Is there a trivial filter in VTK that, regardless of the UpdateExtent
> requested, will always request the WholeExtent from upstream?
> I say "trivial" because it would indeed be a trivial filter to write.
> Has anyone else ever written or used such a filter?
>
> Basically, I'm looking for an easy way to turn streaming off at
> any point in my pipeline, either by inserting a "non-streaming filter"
> or by telling an existing filter not to stream.
>
>  - David

From matt.mccormick at kitware.com  Wed Sep 24 17:22:02 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 24 Sep 2014 17:22:02 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
 <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
 <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>
Message-ID: <CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>

Hi Marcus,

Thanks again for your feedback and information here.


Another note for posterity: I am finding that a project that does

find_package( ITK REQUIRED
  COMPONENTS
   [...]
  ITKVtkGlue
)

find_package( VTK NO_MODULE
  REQUIRED
  COMPONENTS
    [...]
)

the "NO_MODULE" option is required to avoid missing includes.


In summary, to avoid issues:


1) Use COMPONENTS for all calls to find_package( VTK

2) Pass NO_MODULE to find_package( VTK


Thanks,
Matt


On Tue, Sep 9, 2014 at 2:42 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Matt,
>
> Probably commit f915a54, made after I proposed a different change that
> was ultimately rejected. I didn't realize you were on 6.0 - a lot has
> changed since then. I am not entirely certain what your use case is
> for mixed - reallyt non one should make mixed calls and you should
> prefer to always specify COMPONENTS. It would be safer to at least
> spit out a warning, I can look at adding something to warn.
>
> Marcus
>
> On Tue, Sep 9, 2014 at 2:37 PM, Matt McCormick
> <matt.mccormick at kitware.com> wrote:
>> Hi Marcus,
>>
>> Thanks for taking a look at this. I reproduced your output with VTK
>> master for build a build tree and install tree.  However, I get
>>
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
>> -- LIBS: vtkCommonCore
>> -- LIBS: vtkCommonMath
>> -- LIBS: vtkChartsCore
>> -- LIBS: vtkChartsCore
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /tmp/vtkcomponents/build
>>
>> for an installed VTK 6.0.
>>
>>
>> What was the fix and where it was made? We would like to have similar
>> behavior for ITK and other CMake projects that make use of components.
>>
>>
>> I hope that multiple calls, sometimes without specifying COMPONENTS,
>> will still work. If it does not work, CMake should complain
>> informatively that a non-COMPONENTS call cannot occur after a
>> COMPONENTS call.
>>
>> Thanks,
>> Matt
>>
>> On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> Pushing this a little further, to see if we can build executables in
>>> the same directory with multiple calls, the following worked for me
>>> locally,
>>>
>>> cmake_minimum_required(VERSION 3.0)
>>>
>>> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>> add_executable(testexe test.cxx)
>>> set_property(TARGET testexe APPEND
>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>> set_property(TARGET testexe APPEND
>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>> target_link_libraries(testexe ${VTK_LIBRARIES})
>>>
>>> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>> add_executable(testexe2 test2.cxx)
>>> set_property(TARGET testexe2 APPEND
>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>> set_property(TARGET testexe2 APPEND
>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>>>
>>> Producing the output,
>>>
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
>>> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
>>> -- LIBS: vtkCommonCore;vtksys
>>> -- DEFS:
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>
>>> So the definitions were empty, as you would hope, in the second call,
>>> the mains were very simple instantiating a vtkRenderWindow in the
>>> first which resulted in a vtkXOpenGLRenderWindow class being
>>> instantiated as the overrides kicked in for that target. Most projects
>>> I know of that make multiple calls tend to use directories for each
>>> target, and make the calls in sibling directories, but it looks like
>>> you should be able to call it multiple times in the same scope (on
>>> Linux with VTK master at least).
>>>
>>> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Adding you both to CC in case you aren't subscribed, it might also be
>>>> worth appending NO_MODULE to the calls to ensure find modules aren't
>>>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>>>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>>>> contains advice I added, but didn't specifically cover multiple calls.
>>>> Including the use file, or setting the DIRECTORY property will of
>>>> course cause issues if you are not using separate directory scopes for
>>>> each target.
>>>>
>>>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>>>> <marcus.hanwell at kitware.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Moving this discussion from
>>>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>>>> was saying I do not see precisely what you see, the repeated calls
>>>>> seem to work for me locally. I would not expect the call without
>>>>> COMPONENTS to work, and am not sure we should support calling with and
>>>>> without COMPONENTS.
>>>>>
>>>>> I have a minimal CMake script,
>>>>>
>>>>> cmake_minimum_required(VERSION 3.0)
>>>>>
>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK COMPONENTS vtkCommonCore)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK COMPONENTS vtkCommonMath)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> This results in the output,
>>>>>
>>>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>>>> -- The C compiler identification is GNU 4.9.1
>>>>> -- The CXX compiler identification is GNU 4.9.1
>>>>> -- Check for working C compiler: /usr/bin/cc
>>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>>> -- Detecting C compiler ABI info
>>>>> -- Detecting C compiler ABI info - done
>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>> -- Detecting CXX compiler ABI info
>>>>> -- Detecting CXX compiler ABI info - done
>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>> -- LIBS: vtkCommonCore;vtksys
>>>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>> -- Configuring done
>>>>> -- Generating done
>>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>>
>>>>> As far as I can see this gives the libraries one would expect, i.e.
>>>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>>>> final one is incorrect but I am not sure of the value in supporting
>>>>> mixed COMPONENTS and non-components versions of find_package.
>>>>>
>>>>> Let me know if there is something I am missing, is this possibly with
>>>>> an older version of VTK (I am testing with master).
>>>>>
>>>>> Marcus

From ken.martin at kitware.com  Thu Sep 25 11:27:43 2014
From: ken.martin at kitware.com (Ken Martin)
Date: Thu, 25 Sep 2014 11:27:43 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
Message-ID: <f8197e9197116fc1acfe8fd1b79548a7@mail.gmail.com>

Depending on various settings, phase of the moon etc, scalar colors
sometimes end up setting the ambient color and sometimes they set the
diffuse color of a vertex and sometimes they set both IIRC.  Sometimes
lighting is applied to the result and sometimes it isn?t.

The following snippet of code is what I am using for the OpenGL backend,
which is very close to that VTK currently does. Textured scalars coloring
is another beast. Hope that helps

  if ( we have scalar colors)
    {
    if (this->ScalarMaterialMode == VTK_MATERIALMODE_AMBIENT ||
          (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
actor->GetProperty()->GetAmbient() > actor->GetProperty()->GetDiffuse()))
      {
      FSSource = replace(FSSource,"//VTK::Color::Impl",
                                  "vec3 ambientColor = vertexColor.rgb;\n"
                                  "vec3 diffuseColor =
diffuseColorUniform.rgb;\n"
                                  "float opacity = vertexColor.a;");
      }
    else if (this->ScalarMaterialMode == VTK_MATERIALMODE_DIFFUSE ||
          (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
actor->GetProperty()->GetAmbient() <= actor->GetProperty()->GetDiffuse()))
      {
      FSSource = replace(FSSource,"//VTK::Color::Impl",
                                  "vec3 diffuseColor = vertexColor.rgb;\n"
                                  "vec3 ambientColor =
ambientColorUniform;\n"
                                  "float opacity = vertexColor.a;");
      }
    Else // I believe this case is something like
VTK_MATERIALMODE_AMBIENT_AND_DIFFUSE
      {
      FSSource = replace(FSSource,"//VTK::Color::Impl",
                                  "vec3 diffuseColor = vertexColor.rgb;\n"
                                  "vec3 ambientColor = vertexColor.rgb;\n"
                                  "float opacity = vertexColor.a;");
      }
    }
  Else // no scalars, just use material property colors
    {
    FSSource = replace(FSSource,"//VTK::Color::Impl",
                                "vec3 ambientColor =
ambientColorUniform;\n"
                                "vec3 diffuseColor =
diffuseColorUniform;\n"
                                "float opacity = opacityUniform;");
    }

Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
ken.martin at kitware.com
518 881-4901 (w)
518 371-4573 (f)

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.


-----Original Message-----
From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
David Gobbi
Sent: Thursday, September 4, 2014 7:33 PM
To: VTK Developers
Subject: [vtk-developers] Bug in scalar color mapping?

I've run into very odd behavior when I use Ambient and Diffuse
coefficients in combination with vtkDataSetMapper.  This is with VTK
master.

My property is set up like this, with AmbientColor="red" and
DiffuseColor="green".

  property->SetAmbient(0.51);
  property->SetDiffuse(0.49);
  property->SetAmbientColor(1.0, 0.0, 0.0);
  property->SetDiffuseColor(0.0, 1.0, 0.0);

My mapper, however, is set to MapScalars, so it should ignore the
AmbientColor and the DiffuseColor, and use the scalars instead:

  mapper->SetColorModeToMapScalars();
  mapper->SetLookupTable(table);
  mapper->UseLookupTableScalarRangeOn();

The lookup table is a simple greyscale lookup table, and my polydata has
scalars.  So I would expect my data to be rendered in greyscale.
But it's not, it's rendered mint green!  See the left side of the attached
image.

I tried a different scalar mapping pathway:

  mapper->InterpolateScalarsBeforeMappingOn();

The result was totally different, now it's greyscale with ambient
lighting, instead of the mix of ambient and diffuse lighting that I
requested (see right of attached image).


If I slightly modify the ambient and diffuse coefficients, the result is,
once again, completely unexpected:

  property->SetAmbient(0.49);  // was 0.51
  property->SetDiffuse(0.51);  // was 0.49

Now everything is red.  In the second attached image, the left shows
InterpolateScalarsBeforeMappingOff() and the right shows On().


Anyone know what is going on here?  Everything behaves just find if I set
either the Ambient or the Diffuse coefficient to zero.  But when I use
them together, VTK goes crazy.

 - David

From david.gobbi at gmail.com  Thu Sep 25 12:09:08 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 25 Sep 2014 10:09:08 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <f8197e9197116fc1acfe8fd1b79548a7@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <f8197e9197116fc1acfe8fd1b79548a7@mail.gmail.com>
Message-ID: <CANwS1=FrNK1FhTEdJ0b+yjNtB3EDhpMLQ_2uMeuQT1FSoQfeCA@mail.gmail.com>

Thanks, Ken.  That makes it very clear.

Now I know we need backwards compatibility, so maybe I should bite
my tongue, but it would be nice if the code would _combine_ the property's
color with the scalar color, e.g.

     if (this->ScalarMaterialMode == VTK_MATERIALMODE_AMBIENT)
       {
       FSSource = replace(FSSource,"//VTK::Color::Impl",
         "vec3 ambientColor = vertexColor.rgb*ambientColorUniform.rbg;\n"
         "vec3 diffuseColor = diffuseColorUniform.rgb;\n"
         "float opacity = vertexColor.a*opacityUniform;");
       }

etcetera.  If the mode is VTK_MATERIALMODE_AMBIENT the scalars would
combine with the property's ambient color, if VTK_MATERIALMODE_DIFFUSE
the scalars would combine with the property's diffuse color, and if the mode is
AMBIENT_AND_DIFFUSE the scalar color would combine with both.  As for
DEFAULT, my preference would be for it to be same as AMBIENT_AND_DIFFUSE.

 - David


On Thu, Sep 25, 2014 at 9:27 AM, Ken Martin <ken.martin at kitware.com> wrote:
> Depending on various settings, phase of the moon etc, scalar colors
> sometimes end up setting the ambient color and sometimes they set the
> diffuse color of a vertex and sometimes they set both IIRC.  Sometimes
> lighting is applied to the result and sometimes it isn't.
>
> The following snippet of code is what I am using for the OpenGL backend,
> which is very close to that VTK currently does. Textured scalars coloring
> is another beast. Hope that helps
>
>   if ( we have scalar colors)
>     {
>     if (this->ScalarMaterialMode == VTK_MATERIALMODE_AMBIENT ||
>           (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
> actor->GetProperty()->GetAmbient() > actor->GetProperty()->GetDiffuse()))
>       {
>       FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                   "vec3 ambientColor = vertexColor.rgb;\n"
>                                   "vec3 diffuseColor =
> diffuseColorUniform.rgb;\n"
>                                   "float opacity = vertexColor.a;");
>       }
>     else if (this->ScalarMaterialMode == VTK_MATERIALMODE_DIFFUSE ||
>           (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
> actor->GetProperty()->GetAmbient() <= actor->GetProperty()->GetDiffuse()))
>       {
>       FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                   "vec3 diffuseColor = vertexColor.rgb;\n"
>                                   "vec3 ambientColor =
> ambientColorUniform;\n"
>                                   "float opacity = vertexColor.a;");
>       }
>     Else // I believe this case is something like
> VTK_MATERIALMODE_AMBIENT_AND_DIFFUSE
>       {
>       FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                   "vec3 diffuseColor = vertexColor.rgb;\n"
>                                   "vec3 ambientColor = vertexColor.rgb;\n"
>                                   "float opacity = vertexColor.a;");
>       }
>     }
>   Else // no scalars, just use material property colors
>     {
>     FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                 "vec3 ambientColor =
> ambientColorUniform;\n"
>                                 "vec3 diffuseColor =
> diffuseColorUniform;\n"
>                                 "float opacity = opacityUniform;");
>     }
>
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> ken.martin at kitware.com
> 518 881-4901 (w)
> 518 371-4573 (f)
>
> 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.
>
>
> -----Original Message-----
> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
> David Gobbi
> Sent: Thursday, September 4, 2014 7:33 PM
> To: VTK Developers
> Subject: [vtk-developers] Bug in scalar color mapping?
>
> I've run into very odd behavior when I use Ambient and Diffuse
> coefficients in combination with vtkDataSetMapper.  This is with VTK
> master.
>
> My property is set up like this, with AmbientColor="red" and
> DiffuseColor="green".
>
>   property->SetAmbient(0.51);
>   property->SetDiffuse(0.49);
>   property->SetAmbientColor(1.0, 0.0, 0.0);
>   property->SetDiffuseColor(0.0, 1.0, 0.0);
>
> My mapper, however, is set to MapScalars, so it should ignore the
> AmbientColor and the DiffuseColor, and use the scalars instead:
>
>   mapper->SetColorModeToMapScalars();
>   mapper->SetLookupTable(table);
>   mapper->UseLookupTableScalarRangeOn();
>
> The lookup table is a simple greyscale lookup table, and my polydata has
> scalars.  So I would expect my data to be rendered in greyscale.
> But it's not, it's rendered mint green!  See the left side of the attached
> image.
>
> I tried a different scalar mapping pathway:
>
>   mapper->InterpolateScalarsBeforeMappingOn();
>
> The result was totally different, now it's greyscale with ambient
> lighting, instead of the mix of ambient and diffuse lighting that I
> requested (see right of attached image).
>
>
> If I slightly modify the ambient and diffuse coefficients, the result is,
> once again, completely unexpected:
>
>   property->SetAmbient(0.49);  // was 0.51
>   property->SetDiffuse(0.51);  // was 0.49
>
> Now everything is red.  In the second attached image, the left shows
> InterpolateScalarsBeforeMappingOff() and the right shows On().
>
>
> Anyone know what is going on here?  Everything behaves just find if I set
> either the Ambient or the Diffuse coefficient to zero.  But when I use
> them together, VTK goes crazy.
>
>  - David

From matt.mccormick at kitware.com  Thu Sep 25 12:48:11 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 25 Sep 2014 12:48:11 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
 <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
 <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>
 <CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>
Message-ID: <CALzTN-SB1_iA9Q-4i75WfH=KR5L-4hvV5fs15ZiTJ4LQH7Udzg@mail.gmail.com>

Looking at FindITK.cmake and FindVTK.cmake, they appear to not
propagate COMPONENTS [1] [2].  I think we should consider removing
these altogether.  Any version of ITK or VTK from moderately recent
history will have a Config.cmake file.

Matt

[1] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindITK.cmake;h=c9d39eb981f6933d61fc6cb4e0e41f26baabdeab;hb=HEAD
[2] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindVTK.cmake;h=60f48dd4063f3e0eed0f733b923ae7a83b7c76fc;hb=HEAD

On Wed, Sep 24, 2014 at 5:22 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> Hi Marcus,
>
> Thanks again for your feedback and information here.
>
>
> Another note for posterity: I am finding that a project that does
>
> find_package( ITK REQUIRED
>   COMPONENTS
>    [...]
>   ITKVtkGlue
> )
>
> find_package( VTK NO_MODULE
>   REQUIRED
>   COMPONENTS
>     [...]
> )
>
> the "NO_MODULE" option is required to avoid missing includes.
>
>
> In summary, to avoid issues:
>
>
> 1) Use COMPONENTS for all calls to find_package( VTK
>
> 2) Pass NO_MODULE to find_package( VTK
>
>
> Thanks,
> Matt
>
>
> On Tue, Sep 9, 2014 at 2:42 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Matt,
>>
>> Probably commit f915a54, made after I proposed a different change that
>> was ultimately rejected. I didn't realize you were on 6.0 - a lot has
>> changed since then. I am not entirely certain what your use case is
>> for mixed - reallyt non one should make mixed calls and you should
>> prefer to always specify COMPONENTS. It would be safer to at least
>> spit out a warning, I can look at adding something to warn.
>>
>> Marcus
>>
>> On Tue, Sep 9, 2014 at 2:37 PM, Matt McCormick
>> <matt.mccormick at kitware.com> wrote:
>>> Hi Marcus,
>>>
>>> Thanks for taking a look at this. I reproduced your output with VTK
>>> master for build a build tree and install tree.  However, I get
>>>
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
>>> -- LIBS: vtkCommonCore
>>> -- LIBS: vtkCommonMath
>>> -- LIBS: vtkChartsCore
>>> -- LIBS: vtkChartsCore
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /tmp/vtkcomponents/build
>>>
>>> for an installed VTK 6.0.
>>>
>>>
>>> What was the fix and where it was made? We would like to have similar
>>> behavior for ITK and other CMake projects that make use of components.
>>>
>>>
>>> I hope that multiple calls, sometimes without specifying COMPONENTS,
>>> will still work. If it does not work, CMake should complain
>>> informatively that a non-COMPONENTS call cannot occur after a
>>> COMPONENTS call.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Pushing this a little further, to see if we can build executables in
>>>> the same directory with multiple calls, the following worked for me
>>>> locally,
>>>>
>>>> cmake_minimum_required(VERSION 3.0)
>>>>
>>>> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>>> add_executable(testexe test.cxx)
>>>> set_property(TARGET testexe APPEND
>>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>>> set_property(TARGET testexe APPEND
>>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>>> target_link_libraries(testexe ${VTK_LIBRARIES})
>>>>
>>>> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>>> add_executable(testexe2 test2.cxx)
>>>> set_property(TARGET testexe2 APPEND
>>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>>> set_property(TARGET testexe2 APPEND
>>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>>> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>>>>
>>>> Producing the output,
>>>>
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
>>>> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
>>>> -- LIBS: vtkCommonCore;vtksys
>>>> -- DEFS:
>>>> -- Configuring done
>>>> -- Generating done
>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>
>>>> So the definitions were empty, as you would hope, in the second call,
>>>> the mains were very simple instantiating a vtkRenderWindow in the
>>>> first which resulted in a vtkXOpenGLRenderWindow class being
>>>> instantiated as the overrides kicked in for that target. Most projects
>>>> I know of that make multiple calls tend to use directories for each
>>>> target, and make the calls in sibling directories, but it looks like
>>>> you should be able to call it multiple times in the same scope (on
>>>> Linux with VTK master at least).
>>>>
>>>> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
>>>> <marcus.hanwell at kitware.com> wrote:
>>>>> Adding you both to CC in case you aren't subscribed, it might also be
>>>>> worth appending NO_MODULE to the calls to ensure find modules aren't
>>>>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>>>>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>>>>> contains advice I added, but didn't specifically cover multiple calls.
>>>>> Including the use file, or setting the DIRECTORY property will of
>>>>> course cause issues if you are not using separate directory scopes for
>>>>> each target.
>>>>>
>>>>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>>>>> <marcus.hanwell at kitware.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Moving this discussion from
>>>>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>>>>> was saying I do not see precisely what you see, the repeated calls
>>>>>> seem to work for me locally. I would not expect the call without
>>>>>> COMPONENTS to work, and am not sure we should support calling with and
>>>>>> without COMPONENTS.
>>>>>>
>>>>>> I have a minimal CMake script,
>>>>>>
>>>>>> cmake_minimum_required(VERSION 3.0)
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkCommonCore)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkCommonMath)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> This results in the output,
>>>>>>
>>>>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>>>>> -- The C compiler identification is GNU 4.9.1
>>>>>> -- The CXX compiler identification is GNU 4.9.1
>>>>>> -- Check for working C compiler: /usr/bin/cc
>>>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>>>> -- Detecting C compiler ABI info
>>>>>> -- Detecting C compiler ABI info - done
>>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>>> -- Detecting CXX compiler ABI info
>>>>>> -- Detecting CXX compiler ABI info - done
>>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>>> -- LIBS: vtkCommonCore;vtksys
>>>>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>>> -- Configuring done
>>>>>> -- Generating done
>>>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>>>
>>>>>> As far as I can see this gives the libraries one would expect, i.e.
>>>>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>>>>> final one is incorrect but I am not sure of the value in supporting
>>>>>> mixed COMPONENTS and non-components versions of find_package.
>>>>>>
>>>>>> Let me know if there is something I am missing, is this possibly with
>>>>>> an older version of VTK (I am testing with master).
>>>>>>
>>>>>> Marcus

From brad.king at kitware.com  Thu Sep 25 12:56:26 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 25 Sep 2014 12:56:26 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CALzTN-SB1_iA9Q-4i75WfH=KR5L-4hvV5fs15ZiTJ4LQH7Udzg@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>	<CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>	<CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>	<CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>	<CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>	<CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>
 <CALzTN-SB1_iA9Q-4i75WfH=KR5L-4hvV5fs15ZiTJ4LQH7Udzg@mail.gmail.com>
Message-ID: <5424493A.1070406@kitware.com>

On 09/25/2014 12:48 PM, Matt McCormick wrote:
> Looking at FindITK.cmake and FindVTK.cmake, they appear to not
> propagate COMPONENTS [1] [2].

Those are forwarded by find_package automatically:

 http://www.cmake.org/cmake/help/v3.0/command/find_package.html
 "If no [version] and/or component list is given to a recursive
  invocation inside a find-module, the corresponding arguments
  are forwarded automatically from the outer call"

> I think we should consider removing these altogether.
> Any version of ITK or VTK from moderately recent history will
> have a Config.cmake file.

They provide compatibility for applications that expect
USE_ITK_FILE or USE_VTK_FILE to be set instead of the modern
ITK_USE_FILE or VTK_USE_FILE.  The ITK one also provides
compatibility with versions of ITK that installed the
package files under lib/InsightToolkit instead of lib/ITK.

However, I would be okay with removing them.

-Brad


From sean at rogue-research.com  Fri Sep 26 12:01:09 2014
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 26 Sep 2014 12:01:09 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <5405C84D.2010007@kitware.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
Message-ID: <20140926160109.603512592@mail.rogue-research.com>

On Tue, 2 Sep 2014 09:38:21 -0400, Brad King said:

>On 08/28/2014 11:07 AM, Sean McBride wrote:
>> 1) a 'commits' email list, like other projects.  Where you get an
>> email for every merge into master.
>
>We've had one of these since CVS days:
>
> http://www.vtk.org/mailman/listinfo/vtk-commit

Brad,

Thanks for pointing this out.  I subscribed immediately, but wanted to experience it a bit before replying.

It's decent, but I find the subject line really not useful.  They are always of the form:

[Vtk-commit] Visualization Toolkit branch, master, updated. v6.1.0-1718-g5ad494c

Only the last bit ever changes, meaning you really need to look at the body of the email.

Much more useful would be something like on the clang commits list, ex:

r218482 - Fix PR20886 - enforce CUDA target match in method calls

There you can lurk on the list and have an idea of what's changing just from scanning the subjects.  For me anyway, that'd be perfect.

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 brad.king at kitware.com  Fri Sep 26 14:02:56 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 26 Sep 2014 14:02:56 -0400
Subject: [vtk-developers] VTK commits mailing list
In-Reply-To: <20140926160109.603512592@mail.rogue-research.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <20140926160109.603512592@mail.rogue-research.com>
Message-ID: <5425AA50.3020904@kitware.com>

On 09/26/2014 12:01 PM, Sean McBride wrote:
> It's decent, but I find the subject line really not useful.
> They are always of the form:
> 
> [Vtk-commit] Visualization Toolkit branch, master, updated. v6.1.0-1718-g5ad494c
> 
> Much more useful would be something like on the clang commits list, ex:
> 
> r218482 - Fix PR20886 - enforce CUDA target match in method calls

We're just using the contrib/hooks/post-receive-email script from
the upstream git.git repository.  The difference is that our Git
repository notifications are per-push, not per-commit.  One push
can contain many commits, and for us almost always contains at
least 2.  There is no good way to generate a subject line that
summarizes more than one commit.

It is possible to generate one message per commit, but that will
take further investigation someday.

-Brad


From will.schroeder at kitware.com  Sat Sep 27 07:27:49 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Sat, 27 Sep 2014 07:27:49 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
Message-ID: <CAEiDrtW2LzqBTpWRnfNrXcqE=+CHDk5t42uHPbHEMtarjw8r9g@mail.gmail.com>

+100

On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> One thing we can hope to do better next time to not alienate the old
> timers (including myself).
>
> * The transition from CVS to today's gerrit workflow was necessarily long,
> but there were frequent adjustments along the way as we learned and built
> up the infrastructure. Every change in the process meant retraining all of
> the (self interested and busy) contributors.
>
> Whatever our end goal is with the new infrastructure - we need to work
> harder to minimize the number of changes to the commit process, to keep the
> contribution process as dead simple as it can be, and to describe the
> mechanics clearly and loudly.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>
>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>> > 1) a 'commits' email list, like other projects.  Where you get an
>> > email for every merge into master.
>>
>> We've had one of these since CVS days:
>>
>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>
>> It still works.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
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/20140927/e6d0af7d/attachment.html>

From kevnull at phutureshock.com  Sat Sep 27 18:14:59 2014
From: kevnull at phutureshock.com (kevnull at phutureshock.com)
Date: Sat, 27 Sep 2014 15:14:59 -0700
Subject: [vtk-developers] "dot fe" writer class for writing meshes to
	Surface Evolver format?
Message-ID: <eac2839a69be7942404216412eaa963b.squirrel@webmail.phutureshock.com>

I am about to write a small class to write dot fe files that the "Surface
Evolver" software takes as input. If anyone on the list has already done
so would you mind sharing your code. If not, if anyone is interested,
please email me and I will send you the code when it is finished.

While I am emailing the list, I might as well ask a question about point
clouds that I have been struggling with lately, that is, extracting
topologically clean 2-surfaces from a CT scan that has some "thickness" to
it. I would like to use only the points on the "exterior of the surface"
to eventually run marching cubes on, is there a filter that I can use to
thin my data set to those points on the "outside surface" of the point
cloud?

Details here:

http://www.phutureshock.com/mememap/poor-quality-meshes-and-vertex-normals-from-a-point-cloud-with-densitythickness/

Thanks in advance!

Best,
Kevin


From cory.quammen at kitware.com  Mon Sep 29 11:19:01 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Mon, 29 Sep 2014 11:19:01 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx54C2P=oJgRaip=eSK1Cpkta1BasNApAa60mwZyK9C93A@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
 <5411BE3C.7030207@gmail.com>
 <CAB5Fpx54C2P=oJgRaip=eSK1Cpkta1BasNApAa60mwZyK9C93A@mail.gmail.com>
Message-ID: <CAB5Fpx7_mP_cmQVTXEj_T7Cs50TsVxTz6zpirmJ2AraedMa5qQ@mail.gmail.com>

Just to follow up, I put in some changes in VTK that enable you to
specify a test name in front of the test source file in
vtk_add_test_*.

Author: Cory Quammen <cory.quammen at kitware.com>  2014-09-12 09:00:52
Committer: Cory Quammen <cory.quammen at kitware.com>  2014-09-15 09:50:11

    Enabled easier specification of custom test name

    A custom test name can be specified by giving a name followed by a
    comma before the test file name, .e.g.,

    CustomTestName,TestSource.cxx

    CustomTclTestName,TestSource.tcl

    CustomPyTestName,TestSource.py

    Support for custom test names is available in:

    vtk_add_test_cxx
    vtk_add_test_mpi
    vtk_add_test_python
    vtk_add_test_python_mpi
    vtk_add_test_tcl

    This way to specify a custom name is more straightforward and less
    verbose than the vtk_test_prefix mechanism or custom calls to
    ExternalData_add_test.

    Example:

    vtk_add_test_cxx(${vtk-module}CxxTests tests
      TestClass,TestClass.cxx --arg0 --arg1 --arg2
    )

    vtk_add_test_cxx(${vtk-module}CxxTests tests
      TestClass2,TestClass.cxx --arg3 --arg4 --arg5
    )

    The baseline for a test with custom name 'TestClass2' is expected to
    be 'TestClass2.png'.

    Note that currently, every test defined from the same source file
    must be defined in a separate call to vtk_add_test_*. For example,

    vtk_add_test_cxx(${vtk-module}CxxTests tests
      TestClass,TestClass.cxx --arg0 --arg1 --arg2
      TestClass2,TestClass.cxx --arg3 --arg4 --arg5
    )

    does not work correctly - it passes --arg0 through --arg5 to both the
    TestClass and TestClass2 test instances. Instead, tests with arguments
    must be specified with different calls to vtk_add_test_*.

    Change-Id: I88fabc4c5eca5898e257887f3e161fd9c4ee0864

On Thu, Sep 11, 2014 at 5:38 PM, Cory Quammen <cory.quammen at kitware.com> wrote:
> Burlen,
>
> Thanks for the pointer. I like that your example is explicit in what
> is being passed to the tests.
>
> To use the more "magic" vtk_add_test_cxx() function, it turns out you
> can do the following:
>
> set(vtk_test_prefix Second)
> vtk_add_test_cxx(${vtk-module}CxxTests tests
>   SurfacePlusEdges.cxx --arg1 --arg2 --arg3
> )
> unset(vtk_test_prefix)
>
> And this will define a test named $(vtk-module}Cxx-SecondSurfacePlusEdges.
>
> In it's current form, this test will point to a baseline named
> SurfacePlusEdges.png. To point it to a baseline for just this test, I
> had to modify vtkTestingMacros.cmake to include vtk_test_prefix in the
> baseline path. The modifications are on gerrit:
>
> http://review.source.kitware.com/#/t/4648/
>
> This specifies the baseline file name as SecondSurfacePlusEdges.png.
>
> Reviews for this topic are appreciated :-)
>
> I'm not sure if I'm thrilled with defining the test name this way. It
> would be nicer to do something like
>
> vtk_add_test_cxx(${vtk-module}CxxTests tests
>   SurfacePlusEdges.cxx --arg0 --arg1 --arg2
>   SurfacePlusEdges.cxx,CUSTOM_NAME SurfacePlusEdges2 --arg3 --arg4 --arg5
> )
>
> where if CUSTOM_NAME is specified, the first argument is the test name.
>
> Thanks,
> Cory
>
> On Thu, Sep 11, 2014 at 11:22 AM, Burlen Loring <burlen.loring at gmail.com> wrote:
>> Hi Cory,
>>
>> That's how the surface LIC tests are written. Take a look at
>> VTK/Rendering/LIC/Testing/Cxx/CMakeLists.txt
>>
>> Burlen
>>
>>
>> On 09/11/2014 08:07 AM, Cory Quammen wrote:
>>>
>>> Hi all,
>>>
>>> I'm writing a VTK test that takes some command-line arguments to
>>> control some options in a filter. What I would like to do is define
>>> several tests in the CMakeLists.txt file that run this same code but
>>> which pass different arguments in through argv[].
>>>
>>> I haven't found an example of this kind of test in VTK. Most tests are
>>> defined by passing to vtk_add_test_cxx the name of the source file for
>>> the test.
>>>
>>> Can anyone point me to an example similar to what I want to do?
>>>
>>> Thanks!
>>> Cory
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>

From berk.geveci at kitware.com  Mon Sep 29 16:40:41 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Mon, 29 Sep 2014 16:40:41 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
Message-ID: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>

Hi folks,

For Thursday's hackaton, we need a way of organizing and assigning bugs. I
suggest that we use our bug tracker for this. We can assign tags to bugs as
well as assign them to people in there. I already created a "hackaton" tag
that you can use.

So if you are planning on attending, please quickly go over the bug tracker
and tag any bug that look interesting to you with the "hackaton" tag. Also,
assign it to yourself if you'd like to work on it, as long as it is not
already tagged and assigned to someone else.

You can use the "View Issues" view and the tags filter there to list all
bugs already tagged as "hackaton". (1 as of this writing).

For those attending by Google Hangout, here the link:

https://plus.google.com/events/cd0s6so0ijo45dsulg8and8p5tg

For those attending in person, if you didn't already let me know please do
so soon.

Looking forward to it.
-berk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140929/c38384a4/attachment.html>

From berk.geveci at kitware.com  Mon Sep 29 20:15:16 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Mon, 29 Sep 2014 20:15:16 -0400
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
In-Reply-To: <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>
References: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
 <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>
Message-ID: <CAE32kpX_H2fJmmd+G5ScRsnM13C5NQTe3c5FtDhSZdGj-eakYw@mail.gmail.com>

Hi David,

Many apologies for taking so long to answer.  It was a tough week. The
short answer is no. If you are doing this in Python with VTK master, I'd
suggest using vtkPythonAlgorithm. This should take no more than 10 lines of
Python code to achieve.

Best,
-berk

On Tue, Sep 23, 2014 at 12:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Trying again:
>
> Is there a flag that the user can set on a vtkAlgorithm to force it to
> always request the whole extent from its input?
>
> I'm guessing the answer is "no" because I don't see any code in
> vtkStreamingDemandDrivenPipeline.cxx that would support such a
> feature, but I'm wondering if I can get confirmation from other
> developers who are familiar with the pipeline.
>
>  - David
>
>
> On Mon, Sep 22, 2014 at 12:22 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > Hi All,
> >
> > This is a question about streaming in an imaging pipeline.  Sometimes
> > I want to stream just part of whole extent through the pipeline, but
> > even more often, I want to pull through the whole extent even if a
> > downstream request is for just a single slice.
> >
> > Is there a trivial filter in VTK that, regardless of the UpdateExtent
> > requested, will always request the WholeExtent from upstream?
> > I say "trivial" because it would indeed be a trivial filter to write.
> > Has anyone else ever written or used such a filter?
> >
> > Basically, I'm looking for an easy way to turn streaming off at
> > any point in my pipeline, either by inserting a "non-streaming filter"
> > or by telling an existing filter not to stream.
> >
> >  - David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140929/416c5227/attachment.html>

From david.gobbi at gmail.com  Tue Sep 30 08:35:57 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 30 Sep 2014 06:35:57 -0600
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
In-Reply-To: <CAE32kpX_H2fJmmd+G5ScRsnM13C5NQTe3c5FtDhSZdGj-eakYw@mail.gmail.com>
References: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
 <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>
 <CAE32kpX_H2fJmmd+G5ScRsnM13C5NQTe3c5FtDhSZdGj-eakYw@mail.gmail.com>
Message-ID: <CANwS1=GvhgzsxOapr-aciNurrBFySPXVxRjZEYoef5Wu2_UTgQ@mail.gmail.com>

Thanks, pretty much what I figured.  I'm not using python for this
project, but I'll throw together a C++ "anti-streaming filter" and
test it in my pipeline.

 - David



On Mon, Sep 29, 2014 at 6:15 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi David,
>
> Many apologies for taking so long to answer.  It was a tough week. The short
> answer is no. If you are doing this in Python with VTK master, I'd suggest
> using vtkPythonAlgorithm. This should take no more than 10 lines of Python
> code to achieve.
>
> Best,
> -berk
>
> On Tue, Sep 23, 2014 at 12:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Trying again:
>>
>> Is there a flag that the user can set on a vtkAlgorithm to force it to
>> always request the whole extent from its input?
>>
>> I'm guessing the answer is "no" because I don't see any code in
>> vtkStreamingDemandDrivenPipeline.cxx that would support such a
>> feature, but I'm wondering if I can get confirmation from other
>> developers who are familiar with the pipeline.
>>
>>  - David
>>
>>
>> On Mon, Sep 22, 2014 at 12:22 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>> > Hi All,
>> >
>> > This is a question about streaming in an imaging pipeline.  Sometimes
>> > I want to stream just part of whole extent through the pipeline, but
>> > even more often, I want to pull through the whole extent even if a
>> > downstream request is for just a single slice.
>> >
>> > Is there a trivial filter in VTK that, regardless of the UpdateExtent
>> > requested, will always request the WholeExtent from upstream?
>> > I say "trivial" because it would indeed be a trivial filter to write.
>> > Has anyone else ever written or used such a filter?
>> >
>> > Basically, I'm looking for an easy way to turn streaming off at
>> > any point in my pipeline, either by inserting a "non-streaming filter"
>> > or by telling an existing filter not to stream.
>> >
>> >  - David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>

From ben.boeckel at kitware.com  Tue Sep 30 10:46:07 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 30 Sep 2014 10:46:07 -0400
Subject: [vtk-developers] VTK commits mailing list
In-Reply-To: <5425AA50.3020904@kitware.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <20140926160109.603512592@mail.rogue-research.com>
 <5425AA50.3020904@kitware.com>
Message-ID: <20140930144607.GB12969@megas.kitwarein.com>

On Fri, Sep 26, 2014 at 14:02:56 -0400, Brad King wrote:
>           There is no good way to generate a subject line that
> summarizes more than one commit.

Maybe include the branch name that was merged?

--Ben

From brad.king at kitware.com  Tue Sep 30 10:50:24 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 30 Sep 2014 10:50:24 -0400
Subject: [vtk-developers] VTK commits mailing list
In-Reply-To: <20140930144607.GB12969@megas.kitwarein.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <20140926160109.603512592@mail.rogue-research.com>
 <5425AA50.3020904@kitware.com> <20140930144607.GB12969@megas.kitwarein.com>
Message-ID: <542AC330.6090405@kitware.com>

On 09/30/2014 10:46 AM, Ben Boeckel wrote:
> On Fri, Sep 26, 2014 at 14:02:56 -0400, Brad King wrote:
>>           There is no good way to generate a subject line that
>> summarizes more than one commit.
> 
> Maybe include the branch name that was merged?

We don't have that explicitly.  We have only the name of the
integration branch and its old and new sha1 values.  Yes, more
info could be inferred given knowledge of our merge workflow,
but that is also new infrastructure development.

-Brad


From jcplatt at dsl.pipex.com  Mon Sep  1 05:55:07 2014
From: jcplatt at dsl.pipex.com (John Platt)
Date: Mon, 1 Sep 2014 10:55:07 +0100
Subject: [vtk-developers] Problem in vtkCleanPolyData copying cell attribute
	data
Message-ID: <2B06DB3238BE47ABB611C60A8889B591@pafec5>

Hi,

I have an access violation in vtkCleanPolyData at the line (version 5.10.1)

    outputCD->CopyData(outPolyData, i, CombinedCellID);

It appears to occur when the input cell data contains both GLOBALIDS & SCALARS. The GLOBALIDS are significant because they are not copied by default.

The output cell data is allocated using the input cell data (2 cell arrays)

    outputCD->CopyAllocate(inputCD);

not the internal vtkCellArray "outPolyData" which will only contain the SCALARS. The crash occurs because the SCALARS are at index = 1 in the input cell data "inputCD" but index = 0 in "outPolyData".

I can't see any easy way to fix this so any help is much appreciated.

Thanks,

John.

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

From brad.king at kitware.com  Tue Sep  2 09:38:21 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 02 Sep 2014 09:38:21 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <20140828150749.1061007759@mail.rogue-research.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
Message-ID: <5405C84D.2010007@kitware.com>

On 08/28/2014 11:07 AM, Sean McBride wrote:
> 1) a 'commits' email list, like other projects.  Where you get an
> email for every merge into master.

We've had one of these since CVS days:

 http://www.vtk.org/mailman/listinfo/vtk-commit

It still works.

-Brad



From dlrdave at aol.com  Tue Sep  2 11:49:52 2014
From: dlrdave at aol.com (David Cole)
Date: Tue, 2 Sep 2014 11:49:52 -0400
Subject: [vtk-developers] InfoVis graph visualization question:
 vtkGraphLayoutView with a "Simple 2D" layout strategy
Message-ID: <8D194DCAB7E4E9B-15CC-2E28@webmail-m269.sysops.aol.com>

Ping...

Anybody know? Just two little itty bitty questions.


-----Original Message-----
From: David Cole <dlrdave at aol.com>
To: vtk-developers <vtk-developers at vtk.org>; jeff.baumes
<jeff.baumes at kitware.com>
Sent: Thu, Jul 31, 2014 2:20 pm
Subject: InfoVis graph visualization question: vtkGraphLayoutView with
a "Simple 2D" layout strategy


This VTK wiki example:
http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/XGMLReader

Yields this "different rendering" test failure on my dashboard machine:
http://open.cdash.org/testDetails.php?test=271695203&build=3430870

The graph structure looks the same, and the visual is roughly
equivalent, but the expected image clearly shows a perfectly square
glyph at each graph node. In my test image, the graph nodes look like
they vary from circle to square to polygons in between...

What determines the shape of the node glyph in a vtkGraphLayoutView
with a "Simple 2D" layout strategy? And would the shape difference
account entirely for the slight offset and angle between expected image
and test image...?


Thanks,
David C.



From berk.geveci at kitware.com  Tue Sep  2 19:56:15 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Tue, 2 Sep 2014 19:56:15 -0400
Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpVyP8htVXVQOubkgknTEi8=HPd8wZiatDsy06XtQ7U2pA@mail.gmail.com>
References: <CAE32kpX_syzWG=BJRzY2=MoB=wy2eBB20j7qEZC_fWQzxj57rw@mail.gmail.com>
 <CAE32kpVyP8htVXVQOubkgknTEi8=HPd8wZiatDsy06XtQ7U2pA@mail.gmail.com>
Message-ID: <CAE32kpX1Wr2Z=72BYU1jDf5szo-qam6e_FjpMMtq8u28RVaeog@mail.gmail.com>

OK folks. October 2nd it is. We'll shoot for 9am-5pm EDT. So far, I
received confirmation from Bill, Dave C.,  Sean and Will. There will be a
few us from Kitware also. If you plan on attending, please let me know off
list - please let me know if you will attend in person or via Google
Hangout.


On Thu, Aug 28, 2014 at 10:21 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Several people indicated a preference for October. How about October 2nd?
>
> Best,
> -berk
>
>
> On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> I propose a hack-a-ton to reduce the number of open issues in the bug
>> tracker. It is like a yard that hasn't been mowed and weeded the whole
>> summer. I propose a full day hack-a-ton. We can host some folks here at
>> Kitware and others can join through a Google Hangout. I propose one in
>> September. What do you think? Interested parties please send me an e-mail
>> off the list with your preferred dates.
>>
>> This will have to be the first in a series. There are a lot of issues to
>> go over.
>>
>> Best,
>> -berk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140902/5d707cb0/attachment-0002.html>

From bill.lorensen at gmail.com  Tue Sep  2 20:44:40 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Tue, 2 Sep 2014 20:44:40 -0400
Subject: [vtk-developers] [vtkusers] Proposal: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpX1Wr2Z=72BYU1jDf5szo-qam6e_FjpMMtq8u28RVaeog@mail.gmail.com>
References: <CAE32kpX_syzWG=BJRzY2=MoB=wy2eBB20j7qEZC_fWQzxj57rw@mail.gmail.com>
 <CAE32kpVyP8htVXVQOubkgknTEi8=HPd8wZiatDsy06XtQ7U2pA@mail.gmail.com>
 <CAE32kpX1Wr2Z=72BYU1jDf5szo-qam6e_FjpMMtq8u28RVaeog@mail.gmail.com>
Message-ID: <CADZJ4hMWpf8sMD0z672gyVyUGbX4nA+DWyxjO7NnptpU6B4qOg@mail.gmail.com>

In person
On Sep 2, 2014 7:56 PM, "Berk Geveci" <berk.geveci at kitware.com> wrote:

> OK folks. October 2nd it is. We'll shoot for 9am-5pm EDT. So far, I
> received confirmation from Bill, Dave C.,  Sean and Will. There will be a
> few us from Kitware also. If you plan on attending, please let me know off
> list - please let me know if you will attend in person or via Google
> Hangout.
>
>
> On Thu, Aug 28, 2014 at 10:21 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Several people indicated a preference for October. How about October 2nd?
>>
>> Best,
>> -berk
>>
>>
>> On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> Hi folks,
>>>
>>> I propose a hack-a-ton to reduce the number of open issues in the bug
>>> tracker. It is like a yard that hasn't been mowed and weeded the whole
>>> summer. I propose a full day hack-a-ton. We can host some folks here at
>>> Kitware and others can join through a Google Hangout. I propose one in
>>> September. What do you think? Interested parties please send me an e-mail
>>> off the list with your preferred dates.
>>>
>>> This will have to be the first in a series. There are a lot of issues to
>>> go over.
>>>
>>> Best,
>>> -berk
>>>
>>
>>
>
> _______________________________________________
> 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
>
> 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/20140902/dda984e6/attachment-0002.html>

From dave.demarle at kitware.com  Wed Sep  3 10:33:19 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 3 Sep 2014 10:33:19 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <5405C84D.2010007@kitware.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
Message-ID: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>

One thing we can hope to do better next time to not alienate the old timers
(including myself).

* The transition from CVS to today's gerrit workflow was necessarily long,
but there were frequent adjustments along the way as we learned and built
up the infrastructure. Every change in the process meant retraining all of
the (self interested and busy) contributors.

Whatever our end goal is with the new infrastructure - we need to work
harder to minimize the number of changes to the commit process, to keep the
contribution process as dead simple as it can be, and to describe the
mechanics clearly and loudly.


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


On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:

> On 08/28/2014 11:07 AM, Sean McBride wrote:
> > 1) a 'commits' email list, like other projects.  Where you get an
> > email for every merge into master.
>
> We've had one of these since CVS days:
>
>  http://www.vtk.org/mailman/listinfo/vtk-commit
>
> It still works.
>
> -Brad
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140903/288610e7/attachment-0002.html>

From dave.demarle at kitware.com  Wed Sep  3 10:35:59 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 3 Sep 2014 10:35:59 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
Message-ID: <CANjZAi9sDC+zr6WWzUmVDhAVThL4gNgh9fUOcecW4uewNhr5AA@mail.gmail.com>

The idea of having gerrit automatically add reviewers is a small tweak that
will improve things greatly.

Can we have a simple gerrit side hook that adds the previous 3 authors of
all touched files?


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


On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> One thing we can hope to do better next time to not alienate the old
> timers (including myself).
>
> * The transition from CVS to today's gerrit workflow was necessarily long,
> but there were frequent adjustments along the way as we learned and built
> up the infrastructure. Every change in the process meant retraining all of
> the (self interested and busy) contributors.
>
> Whatever our end goal is with the new infrastructure - we need to work
> harder to minimize the number of changes to the commit process, to keep the
> contribution process as dead simple as it can be, and to describe the
> mechanics clearly and loudly.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>
>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>> > 1) a 'commits' email list, like other projects.  Where you get an
>> > email for every merge into master.
>>
>> We've had one of these since CVS days:
>>
>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>
>> It still works.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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/20140903/7c2e9eff/attachment-0002.html>

From inglis.dl at gmail.com  Wed Sep  3 10:56:28 2014
From: inglis.dl at gmail.com (Dean Inglis)
Date: Wed, 3 Sep 2014 10:56:28 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
Message-ID: <CABX+von6fGiZn0bfk4W57vmgEK6utNKOT3BuvKfeySgyb=4f7A@mail.gmail.com>

I've been following this thread for a while and would like to add that
I too found the gerritt workflow discouraging enough that I (and fellow
work colleagues) have decided
to maintain a privately forked VTK repo rather than contributing back to
the community.  I would echo
most of the sentiments already expressed by D. DeMarle, D. Gobbi, and J.B.
Although I do miss
the old CVS workflow days, and I have come to embrace github, I'll be
holding back on contributing
to VTK until the commit process is simplified, more responsive, and
expedient.

best to all of you,
Dean


On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> One thing we can hope to do better next time to not alienate the old
> timers (including myself).
>
> * The transition from CVS to today's gerrit workflow was necessarily long,
> but there were frequent adjustments along the way as we learned and built
> up the infrastructure. Every change in the process meant retraining all of
> the (self interested and busy) contributors.
>
> Whatever our end goal is with the new infrastructure - we need to work
> harder to minimize the number of changes to the commit process, to keep the
> contribution process as dead simple as it can be, and to describe the
> mechanics clearly and loudly.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>
>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>> > 1) a 'commits' email list, like other projects.  Where you get an
>> > email for every merge into master.
>>
>> We've had one of these since CVS days:
>>
>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>
>> It still works.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>
> 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/20140903/6d37c079/attachment-0002.html>

From matt.mccormick at kitware.com  Wed Sep  3 12:21:16 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 3 Sep 2014 12:21:16 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi9sDC+zr6WWzUmVDhAVThL4gNgh9fUOcecW4uewNhr5AA@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
 <CANjZAi9sDC+zr6WWzUmVDhAVThL4gNgh9fUOcecW4uewNhr5AA@mail.gmail.com>
Message-ID: <CALzTN-SBq6sJ2p0mnpu_FYxkZHM7KZyi+kmfvDm+uxjCBV6BSw@mail.gmail.com>

Here is a script [1] for reference I wrote a while ago (have not used
recently), that will select potential reviewers and add them to a
Gerrit patch via the command line.  It uses recent changes (within the
last five years) and sorts by the number of lines changed to select
reviewers. It is amazing how many people tweak and improve a file over
its lifetime, especially for a project like VTK.

HTH,
Matt

[1] https://gist.github.com/thewtex/674093


On Wed, Sep 3, 2014 at 10:35 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> The idea of having gerrit automatically add reviewers is a small tweak that
> will improve things greatly.
>
> Can we have a simple gerrit side hook that adds the previous 3 authors of
> all touched files?
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>>
>> One thing we can hope to do better next time to not alienate the old
>> timers (including myself).
>>
>> * The transition from CVS to today's gerrit workflow was necessarily long,
>> but there were frequent adjustments along the way as we learned and built up
>> the infrastructure. Every change in the process meant retraining all of the
>> (self interested and busy) contributors.
>>
>> Whatever our end goal is with the new infrastructure - we need to work
>> harder to minimize the number of changes to the commit process, to keep the
>> contribution process as dead simple as it can be, and to describe the
>> mechanics clearly and loudly.
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>>
>> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>>>
>>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>>> > 1) a 'commits' email list, like other projects.  Where you get an
>>> > email for every merge into master.
>>>
>>> We've had one of these since CVS days:
>>>
>>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>>
>>> It still works.
>>>
>>> -Brad
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> 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
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>


From david.gobbi at gmail.com  Thu Sep  4 19:33:14 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 4 Sep 2014 17:33:14 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
Message-ID: <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>

I've run into very odd behavior when I use Ambient and Diffuse
coefficients in combination with vtkDataSetMapper.  This is with
VTK master.

My property is set up like this, with AmbientColor="red" and
DiffuseColor="green".

  property->SetAmbient(0.51);
  property->SetDiffuse(0.49);
  property->SetAmbientColor(1.0, 0.0, 0.0);
  property->SetDiffuseColor(0.0, 1.0, 0.0);

My mapper, however, is set to MapScalars, so it should ignore the
AmbientColor and the DiffuseColor, and use the scalars instead:

  mapper->SetColorModeToMapScalars();
  mapper->SetLookupTable(table);
  mapper->UseLookupTableScalarRangeOn();

The lookup table is a simple greyscale lookup table, and my polydata
has scalars.  So I would expect my data to be rendered in greyscale.
But it's not, it's rendered mint green!  See the left side of the
attached image.

I tried a different scalar mapping pathway:

  mapper->InterpolateScalarsBeforeMappingOn();

The result was totally different, now it's greyscale with ambient
lighting, instead of the mix of ambient and diffuse lighting that I
requested (see right of attached image).


If I slightly modify the ambient and diffuse coefficients, the result
is, once again, completely unexpected:

  property->SetAmbient(0.49);  // was 0.51
  property->SetDiffuse(0.51);  // was 0.49

Now everything is red.  In the second attached image, the left shows
InterpolateScalarsBeforeMappingOff() and the right shows On().


Anyone know what is going on here?  Everything behaves just find if I
set either the Ambient or the Diffuse coefficient to zero.  But when I
use them together, VTK goes crazy.

 - David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapscalars1.jpg
Type: image/jpeg
Size: 74282 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140904/eb4cbfaa/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapscalars2.jpg
Type: image/jpeg
Size: 75610 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140904/eb4cbfaa/attachment-0005.jpg>

From dave.demarle at kitware.com  Thu Sep  4 22:31:11 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 4 Sep 2014 22:31:11 -0400
Subject: [vtk-developers] VTK code review / testing / integration
	workflow
In-Reply-To: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com>
References: <CAE32kpXxGwXwdTD4CTUiYZDAHxvB-4q1U7RDpcWWyd0C6f3CYw@mail.gmail.com>
 <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com>
Message-ID: <CANjZAi8xEjBM3ui2nR6Y954uzOJ+pOiCL4VRfeLHv8VAnC9B5A@mail.gmail.com>

On Sat, Aug 23, 2014 at 9:04 PM, David Thompson <david.thompson at kitware.com>
wrote:

> <snip>
> - It would be nice to have tighter integration with the release process
> and issue tracking so that reports of features added and bugs fixed could be


+1

The bugtracker is only loosely integrated into the process. I'ld like it to
be tighter too so that hopefully the number of bugs in the tracker will be
limited and always recent.



> generated. I think what we do of that is mostly by hand now, isn't it?
>
>
Yes mostly by hand.

* before a release we scan the bug tracker and try to address the most
important reports.

* during the release candidate cycle I use the bug tracker and the "found
in" "fixed in" fields to keep track of the bugs that need to be fixed
before the final release

We keep track of what changed in the release entirely outside of the bug
tracker.

* I send an email to all authors and ask them to summarize their changes
 to make up the release notes so we know overall what happened.

* Then I run $VTKSRC//Utilities/Maintenance/sematicDiffVersion.py to make
the API diff report so that we have a list of the added / newly legacy'd /
 and removed items.
See: http://www.vtk.org/Wiki/VTK/API_Changes_6_0_0_to_6_1_0







> Suggested Requirements:-)
>
> - Review system comments should be Markdown or rST or something easily
> presented as HTML which can include links -- at least to the VTK wiki and
> bug tracker, if nothing else. It would be really nice if pull requests
> could effectively become parts of a wiki page or blog so that we could
> curate user-guide-style documentation instead of just doxygen reference
> docs. Not that every topic would have to become part of a user's guide, but
> it should be easy to pull topic info into a user's guide.
>
> - An anti-requirement: Less e-mail spam when (1) a topic includes multiple
> commits and/or (2) automated testing completes. For instance, I can think
> of one topic I'm a reviewer on that has 40-something commits. There are 16
> changesets and reviewers get 1 per commit per
> changeset-the-commit-is-modified.
>
>         2?,
>         David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140904/7a58da55/attachment-0002.html>

From berk.geveci at kitware.com  Fri Sep  5 07:27:52 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Fri, 5 Sep 2014 07:27:52 -0400
Subject: [vtk-developers] VTK code review / testing / integration
	workflow
In-Reply-To: <CANjZAi8xEjBM3ui2nR6Y954uzOJ+pOiCL4VRfeLHv8VAnC9B5A@mail.gmail.com>
References: <CAE32kpXxGwXwdTD4CTUiYZDAHxvB-4q1U7RDpcWWyd0C6f3CYw@mail.gmail.com>
 <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com>
 <CANjZAi8xEjBM3ui2nR6Y954uzOJ+pOiCL4VRfeLHv8VAnC9B5A@mail.gmail.com>
Message-ID: <CAE32kpWAZkmWB22YBQWE+=ciN7FNUaCDQO7PFZ8CAAiPYWK8Gw@mail.gmail.com>

Hi guys,

To close the loop on the tool side of things, we will be evaluating Gitlab
for another project at Kitware. After that, I'll revive the tool
discussion. From what I heard so far, it sounds like we will settle on
Github or Gitlab (or something similar).

Best,
-berk



On Thu, Sep 4, 2014 at 10:31 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

>
> On Sat, Aug 23, 2014 at 9:04 PM, David Thompson <
> david.thompson at kitware.com> wrote:
>
>> <snip>
>> - It would be nice to have tighter integration with the release process
>> and issue tracking so that reports of features added and bugs fixed could be
>
>
> +1
>
> The bugtracker is only loosely integrated into the process. I'ld like it
> to be tighter too so that hopefully the number of bugs in the tracker will
> be limited and always recent.
>
>
>
>> generated. I think what we do of that is mostly by hand now, isn't it?
>>
>>
> Yes mostly by hand.
>
> * before a release we scan the bug tracker and try to address the most
> important reports.
>
> * during the release candidate cycle I use the bug tracker and the "found
> in" "fixed in" fields to keep track of the bugs that need to be fixed
> before the final release
>
> We keep track of what changed in the release entirely outside of the bug
> tracker.
>
> * I send an email to all authors and ask them to summarize their changes
>  to make up the release notes so we know overall what happened.
>
> * Then I run $VTKSRC//Utilities/Maintenance/sematicDiffVersion.py to make
> the API diff report so that we have a list of the added / newly legacy'd /
>  and removed items.
> See: http://www.vtk.org/Wiki/VTK/API_Changes_6_0_0_to_6_1_0
>
>
>
>
>
>
>
>> Suggested Requirements:-)
>>
>> - Review system comments should be Markdown or rST or something easily
>> presented as HTML which can include links -- at least to the VTK wiki and
>> bug tracker, if nothing else. It would be really nice if pull requests
>> could effectively become parts of a wiki page or blog so that we could
>> curate user-guide-style documentation instead of just doxygen reference
>> docs. Not that every topic would have to become part of a user's guide, but
>> it should be easy to pull topic info into a user's guide.
>>
>> - An anti-requirement: Less e-mail spam when (1) a topic includes
>> multiple commits and/or (2) automated testing completes. For instance, I
>> can think of one topic I'm a reviewer on that has 40-something commits.
>> There are 16 changesets and reviewers get 1 per commit per
>> changeset-the-commit-is-modified.
>>
>>         2?,
>>         David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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/20140905/e284596a/attachment-0002.html>

From johnrim20 at gmail.com  Fri Sep  5 07:55:11 2014
From: johnrim20 at gmail.com (JohnR)
Date: Fri, 5 Sep 2014 04:55:11 -0700 (PDT)
Subject: [vtk-developers] How to do Next and Prevous frame in VTK python
Message-ID: <1409918111678-5728585.post@n5.nabble.com>

Hello,

I am doing a program  which should able to do
Next frame and previous frame on button clicks. I have added
a sphere vtk object in render window as an actor. Don't understand
frame functionality and how to do previous and Next frame. I am able to do
set positions but I don't think it can achieve the frame functionality out 
of this
could anyone please help me or share a sample code for this?
Please note my code below

I am using Tkinter python with VTK

[code]

    def sphere_render(cone_Obj,obj_renwin):

        
        obj_renwin.sphereSource = vtk.vtkSphereSource()              
        obj_renwin.sphereSource.SetRadius(.5)    
        obj_renwin.actor = vtk.vtkActor()
        obj_renwin.mapper = vtk.vtkPolyDataMapper()
       
obj_renwin.mapper.SetInputConnection(obj_renwin.sphereSource.GetOutputPort())
        obj_renwin.actor.SetMapper(obj_renwin.mapper)       
        obj_renwin.prop = obj_renwin.actor.GetProperty()        
        global actor_Status
        actor_Status=obj_renwin.add_actors(obj_renwin.actor)        
        obj_renwin.renwin.Render()
        return obj_renwin.actor

   
    def do_Next_Frame(self,obj_renwin):

       obj_renwin.actor.SetPosition(0, 1, 0)


    def do_Prv_Frame(self,obj_renwin):

        obj_renwin.actor.SetPosition(0.0, 0.0, 0.0)


[/code]



--
View this message in context: http://vtk.1045678.n5.nabble.com/How-to-do-Next-and-Prevous-frame-in-VTK-python-tp5728585.html
Sent from the VTK - Dev mailing list archive at Nabble.com.


From joachim.pouderoux at kitware.com  Mon Sep  8 08:42:34 2014
From: joachim.pouderoux at kitware.com (Joachim Pouderoux)
Date: Mon, 8 Sep 2014 14:42:34 +0200
Subject: [vtk-developers] ANN: ParaView Training Course in Paris, France,
	October 14-15, 2014
Message-ID: <CACJ=gThe52uEvQF47K0nwhKVO+wqjVmZ3hzcJt77bRFO8Lp0ow@mail.gmail.com>

Hello,

Kitware will be holding a 2-day ParaView course on October 14 and 15th,
2014 at Universit? Pierre et Marie Curie, Paris, France.

The specificity of this training is that it will take place in a virtual
reality room fitted with a powerwall.

Please visit our web site for more information and registration details at
either:

http://training.kitware.fr/browse/71 (in English)
or
http://formations.kitware.fr/browse/71 (in French)

Note that the course might be taught in English. If you have any question,
please contact us at formations at http://www.kitware.fr

Thank you,

*Joachim Pouderoux*

*PhD, Technical Expert*
*Kitware SAS <http://www.kitware.fr>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140908/7393ad59/attachment-0002.html>

From david.gobbi at gmail.com  Mon Sep  8 16:55:44 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 8 Sep 2014 14:55:44 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
Message-ID: <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>

Any comments on the "scalar color mapping" problem that I sent to the
list last week?

 - David


On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> I've run into very odd behavior when I use Ambient and Diffuse
> coefficients in combination with vtkDataSetMapper.  This is with
> VTK master.
[ snip ]


From utkarsh.ayachit at kitware.com  Mon Sep  8 19:17:12 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 8 Sep 2014 19:17:12 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
Message-ID: <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>

This sounds familiar.

Can you try reverting the following commit and see if that makes any difference:

commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
Date:   Fri Jul 18 15:30:37 2014 -0400

    BUG #14828: Keep surface color from interacting with scalar color.

    When using scalar coloring, if vtkScalarsToColorsPainter decided to use
    a texture for mapping the scalars to colors, we ended up with the
    surface color bleeding through the texture. This commit ensures that
    such bleeding is avoided.

    We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
    GL_REPLACE), since that results in the diffuse highlights being lost.
    By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
    the same lighting/coloring path as we would when not using the texture
    for scalar coloring.

    Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988


Utkarsh

On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Any comments on the "scalar color mapping" problem that I sent to the
> list last week?
>
>  - David
>
>
> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> I've run into very odd behavior when I use Ambient and Diffuse
>> coefficients in combination with vtkDataSetMapper.  This is with
>> VTK master.
> [ snip ]
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>


From david.gobbi at gmail.com  Mon Sep  8 20:15:57 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 8 Sep 2014 18:15:57 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
Message-ID: <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>

Hi Utkarsh,

Thanks for the reply.  If I use this:

  mapper->InterpolateScalarsBeforeMappingOff();

then the result is exactly the same as it was before I reverted that commit.


If I use this:

  mapper->InterpolateScalarsBeforeMappingOn();

then the result looks like the attached image, i.e. like it did in my previous
email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
I reverse these I don't get the greyscale ambient lighting like in the
right side
of the image from my previous email.


Still, I don't get what I expect unless I set one of either the ambient or the
diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
result.

 - David


On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> This sounds familiar.
>
> Can you try reverting the following commit and see if that makes any difference:
>
> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
> Date:   Fri Jul 18 15:30:37 2014 -0400
>
>     BUG #14828: Keep surface color from interacting with scalar color.
>
>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>     a texture for mapping the scalars to colors, we ended up with the
>     surface color bleeding through the texture. This commit ensures that
>     such bleeding is avoided.
>
>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>     GL_REPLACE), since that results in the diffuse highlights being lost.
>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>     the same lighting/coloring path as we would when not using the texture
>     for scalar coloring.
>
>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>
>
> Utkarsh
>
> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Any comments on the "scalar color mapping" problem that I sent to the
>> list last week?
>>
>>  - David
>>
>>
>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> I've run into very odd behavior when I use Ambient and Diffuse
>>> coefficients in combination with vtkDataSetMapper.  This is with
>>> VTK master.
>> [ snip ]
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapscalars3.jpg
Type: image/jpeg
Size: 38858 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140908/1e6df0b1/attachment-0002.jpg>

From utkarsh.ayachit at kitware.com  Tue Sep  9 10:44:26 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 10:44:26 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
Message-ID: <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>

David,

Try the attached patch and then set
SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
ScalarMaterialMode is the thing here. When set to
SetScalarMaterialModeToDefault(), which is the default, it determines
which material component should track the scalar color based on which
coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
The patch fixes an issue where the painter was not respecting the
material mode set on the mapper.

Utkarsh

On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Utkarsh,
>
> Thanks for the reply.  If I use this:
>
>   mapper->InterpolateScalarsBeforeMappingOff();
>
> then the result is exactly the same as it was before I reverted that commit.
>
>
> If I use this:
>
>   mapper->InterpolateScalarsBeforeMappingOn();
>
> then the result looks like the attached image, i.e. like it did in my previous
> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
> I reverse these I don't get the greyscale ambient lighting like in the
> right side
> of the image from my previous email.
>
>
> Still, I don't get what I expect unless I set one of either the ambient or the
> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
> result.
>
>  - David
>
>
> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> This sounds familiar.
>>
>> Can you try reverting the following commit and see if that makes any difference:
>>
>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>
>>     BUG #14828: Keep surface color from interacting with scalar color.
>>
>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>     a texture for mapping the scalars to colors, we ended up with the
>>     surface color bleeding through the texture. This commit ensures that
>>     such bleeding is avoided.
>>
>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>     the same lighting/coloring path as we would when not using the texture
>>     for scalar coloring.
>>
>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>
>>
>> Utkarsh
>>
>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Any comments on the "scalar color mapping" problem that I sent to the
>>> list last week?
>>>
>>>  - David
>>>
>>>
>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>> VTK master.
>>> [ snip ]
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>


From david.gobbi at gmail.com  Tue Sep  9 10:53:32 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 9 Sep 2014 08:53:32 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
Message-ID: <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>

Hi Utkarsh,

The "attached patch" seems to be missing.

 - David

On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> David,
>
> Try the attached patch and then set
> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
> ScalarMaterialMode is the thing here. When set to
> SetScalarMaterialModeToDefault(), which is the default, it determines
> which material component should track the scalar color based on which
> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
> The patch fixes an issue where the painter was not respecting the
> material mode set on the mapper.
>
> Utkarsh
>
> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Utkarsh,
>>
>> Thanks for the reply.  If I use this:
>>
>>   mapper->InterpolateScalarsBeforeMappingOff();
>>
>> then the result is exactly the same as it was before I reverted that commit.
>>
>>
>> If I use this:
>>
>>   mapper->InterpolateScalarsBeforeMappingOn();
>>
>> then the result looks like the attached image, i.e. like it did in my previous
>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>> I reverse these I don't get the greyscale ambient lighting like in the
>> right side
>> of the image from my previous email.
>>
>>
>> Still, I don't get what I expect unless I set one of either the ambient or the
>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>> result.
>>
>>  - David
>>
>>
>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> This sounds familiar.
>>>
>>> Can you try reverting the following commit and see if that makes any difference:
>>>
>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>
>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>
>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>     a texture for mapping the scalars to colors, we ended up with the
>>>     surface color bleeding through the texture. This commit ensures that
>>>     such bleeding is avoided.
>>>
>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>     the same lighting/coloring path as we would when not using the texture
>>>     for scalar coloring.
>>>
>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>
>>>
>>> Utkarsh
>>>
>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>> list last week?
>>>>
>>>>  - David
>>>>
>>>>
>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>> VTK master.
>>>> [ snip ]
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>


From utkarsh.ayachit at kitware.com  Tue Sep  9 10:56:16 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 10:56:16 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
Message-ID: <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>

Doh! Here you go.

On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Utkarsh,
>
> The "attached patch" seems to be missing.
>
>  - David
>
> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> David,
>>
>> Try the attached patch and then set
>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>> ScalarMaterialMode is the thing here. When set to
>> SetScalarMaterialModeToDefault(), which is the default, it determines
>> which material component should track the scalar color based on which
>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>> The patch fixes an issue where the painter was not respecting the
>> material mode set on the mapper.
>>
>> Utkarsh
>>
>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Hi Utkarsh,
>>>
>>> Thanks for the reply.  If I use this:
>>>
>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>
>>> then the result is exactly the same as it was before I reverted that commit.
>>>
>>>
>>> If I use this:
>>>
>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>
>>> then the result looks like the attached image, i.e. like it did in my previous
>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>> I reverse these I don't get the greyscale ambient lighting like in the
>>> right side
>>> of the image from my previous email.
>>>
>>>
>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>> result.
>>>
>>>  - David
>>>
>>>
>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> This sounds familiar.
>>>>
>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>
>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>
>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>
>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>     surface color bleeding through the texture. This commit ensures that
>>>>     such bleeding is avoided.
>>>>
>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>     the same lighting/coloring path as we would when not using the texture
>>>>     for scalar coloring.
>>>>
>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>
>>>>
>>>> Utkarsh
>>>>
>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>> list last week?
>>>>>
>>>>>  - David
>>>>>
>>>>>
>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>> VTK master.
>>>>> [ snip ]
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix.patch
Type: text/x-patch
Size: 723 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/d50411ee/attachment-0002.bin>

From david.gobbi at gmail.com  Tue Sep  9 11:11:39 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 9 Sep 2014 09:11:39 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
Message-ID: <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>

I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
patch, but it had no effect.  The results were exactly the same as in
my first email.

I'll have to look through the code to figure out what the intended behaviour is.

 - David

On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Doh! Here you go.
>
> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Utkarsh,
>>
>> The "attached patch" seems to be missing.
>>
>>  - David
>>
>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> David,
>>>
>>> Try the attached patch and then set
>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>> ScalarMaterialMode is the thing here. When set to
>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>> which material component should track the scalar color based on which
>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>> The patch fixes an issue where the painter was not respecting the
>>> material mode set on the mapper.
>>>
>>> Utkarsh
>>>
>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> Hi Utkarsh,
>>>>
>>>> Thanks for the reply.  If I use this:
>>>>
>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>
>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>
>>>>
>>>> If I use this:
>>>>
>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>
>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>> right side
>>>> of the image from my previous email.
>>>>
>>>>
>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>> result.
>>>>
>>>>  - David
>>>>
>>>>
>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>> This sounds familiar.
>>>>>
>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>
>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>
>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>
>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>     such bleeding is avoided.
>>>>>
>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>     for scalar coloring.
>>>>>
>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>
>>>>>
>>>>> Utkarsh
>>>>>
>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>> list last week?
>>>>>>
>>>>>>  - David
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>> VTK master.
>>>>>> [ snip ]
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>


From utkarsh.ayachit at kitware.com  Tue Sep  9 11:13:48 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 11:13:48 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
Message-ID: <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>

Here's my test script. With the patch applied, I don't see the ambient
and diffuse colors bleed in anymore.

On Tue, Sep 9, 2014 at 11:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
> patch, but it had no effect.  The results were exactly the same as in
> my first email.
>
> I'll have to look through the code to figure out what the intended behaviour is.
>
>  - David
>
> On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Doh! Here you go.
>>
>> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Hi Utkarsh,
>>>
>>> The "attached patch" seems to be missing.
>>>
>>>  - David
>>>
>>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> David,
>>>>
>>>> Try the attached patch and then set
>>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>>> ScalarMaterialMode is the thing here. When set to
>>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>>> which material component should track the scalar color based on which
>>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>>> The patch fixes an issue where the painter was not respecting the
>>>> material mode set on the mapper.
>>>>
>>>> Utkarsh
>>>>
>>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Hi Utkarsh,
>>>>>
>>>>> Thanks for the reply.  If I use this:
>>>>>
>>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>>
>>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>>
>>>>>
>>>>> If I use this:
>>>>>
>>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>>
>>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>>> right side
>>>>> of the image from my previous email.
>>>>>
>>>>>
>>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>>> result.
>>>>>
>>>>>  - David
>>>>>
>>>>>
>>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>> This sounds familiar.
>>>>>>
>>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>>
>>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>>
>>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>>
>>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>>     such bleeding is avoided.
>>>>>>
>>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>>     for scalar coloring.
>>>>>>
>>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>>
>>>>>>
>>>>>> Utkarsh
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>>> list last week?
>>>>>>>
>>>>>>>  - David
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>>> VTK master.
>>>>>>> [ snip ]
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScalarColors.py
Type: text/x-python
Size: 2646 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/ec89321a/attachment-0002.py>

From utkarsh.ayachit at kitware.com  Tue Sep  9 11:14:26 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 9 Sep 2014 11:14:26 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
 <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
Message-ID: <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>

BTW, in my script, you can hit "t" to swap the ambient/diffuse coefficients.

On Tue, Sep 9, 2014 at 11:13 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Here's my test script. With the patch applied, I don't see the ambient
> and diffuse colors bleed in anymore.
>
> On Tue, Sep 9, 2014 at 11:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
>> patch, but it had no effect.  The results were exactly the same as in
>> my first email.
>>
>> I'll have to look through the code to figure out what the intended behaviour is.
>>
>>  - David
>>
>> On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>> Doh! Here you go.
>>>
>>> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>> Hi Utkarsh,
>>>>
>>>> The "attached patch" seems to be missing.
>>>>
>>>>  - David
>>>>
>>>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>> David,
>>>>>
>>>>> Try the attached patch and then set
>>>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>>>> ScalarMaterialMode is the thing here. When set to
>>>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>>>> which material component should track the scalar color based on which
>>>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>>>> The patch fixes an issue where the painter was not respecting the
>>>>> material mode set on the mapper.
>>>>>
>>>>> Utkarsh
>>>>>
>>>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>> Hi Utkarsh,
>>>>>>
>>>>>> Thanks for the reply.  If I use this:
>>>>>>
>>>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>>>
>>>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>>>
>>>>>>
>>>>>> If I use this:
>>>>>>
>>>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>>>
>>>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>>>> right side
>>>>>> of the image from my previous email.
>>>>>>
>>>>>>
>>>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>>>> result.
>>>>>>
>>>>>>  - David
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>>> This sounds familiar.
>>>>>>>
>>>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>>>
>>>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>>>
>>>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>>>
>>>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>>>     such bleeding is avoided.
>>>>>>>
>>>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>>>     for scalar coloring.
>>>>>>>
>>>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>>>
>>>>>>>
>>>>>>> Utkarsh
>>>>>>>
>>>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>>>> list last week?
>>>>>>>>
>>>>>>>>  - David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>>>> VTK master.
>>>>>>>> [ snip ]
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>


From marcus.hanwell at kitware.com  Tue Sep  9 13:23:09 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 13:23:09 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS ...)
Message-ID: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>

Hi,

Moving this discussion from
http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
was saying I do not see precisely what you see, the repeated calls
seem to work for me locally. I would not expect the call without
COMPONENTS to work, and am not sure we should support calling with and
without COMPONENTS.

I have a minimal CMake script,

cmake_minimum_required(VERSION 3.0)

find_package(VTK COMPONENTS vtkChartsCore)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK COMPONENTS vtkCommonCore)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK COMPONENTS vtkCommonMath)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK COMPONENTS vtkChartsCore)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

find_package(VTK)
message(STATUS "LIBS: ${VTK_LIBRARIES}")

This results in the output,

$ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
-- LIBS: vtkCommonCore;vtksys
-- LIBS: vtkCommonMath;vtkCommonCore;vtksys
-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
-- Configuring done
-- Generating done
-- Build files have been written to: /home/marcus/build/vtkcomponents

As far as I can see this gives the libraries one would expect, i.e.
vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
final one is incorrect but I am not sure of the value in supporting
mixed COMPONENTS and non-components versions of find_package.

Let me know if there is something I am missing, is this possibly with
an older version of VTK (I am testing with master).

Marcus


From marcus.hanwell at kitware.com  Tue Sep  9 13:53:14 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 13:53:14 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
Message-ID: <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>

Adding you both to CC in case you aren't subscribed, it might also be
worth appending NO_MODULE to the calls to ensure find modules aren't
used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
contains advice I added, but didn't specifically cover multiple calls.
Including the use file, or setting the DIRECTORY property will of
course cause issues if you are not using separate directory scopes for
each target.

On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Hi,
>
> Moving this discussion from
> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
> was saying I do not see precisely what you see, the repeated calls
> seem to work for me locally. I would not expect the call without
> COMPONENTS to work, and am not sure we should support calling with and
> without COMPONENTS.
>
> I have a minimal CMake script,
>
> cmake_minimum_required(VERSION 3.0)
>
> find_package(VTK COMPONENTS vtkChartsCore)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK COMPONENTS vtkCommonCore)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK COMPONENTS vtkCommonMath)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK COMPONENTS vtkChartsCore)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> find_package(VTK)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>
> This results in the output,
>
> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
> -- The C compiler identification is GNU 4.9.1
> -- The CXX compiler identification is GNU 4.9.1
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
> -- LIBS: vtkCommonCore;vtksys
> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/marcus/build/vtkcomponents
>
> As far as I can see this gives the libraries one would expect, i.e.
> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
> final one is incorrect but I am not sure of the value in supporting
> mixed COMPONENTS and non-components versions of find_package.
>
> Let me know if there is something I am missing, is this possibly with
> an older version of VTK (I am testing with master).
>
> Marcus


From marcus.hanwell at kitware.com  Tue Sep  9 14:18:11 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 14:18:11 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
Message-ID: <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>

Pushing this a little further, to see if we can build executables in
the same directory with multiple calls, the following worked for me
locally,

cmake_minimum_required(VERSION 3.0)

find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
message(STATUS "LIBS: ${VTK_LIBRARIES}")
message(STATUS "DEFS: ${VTK_DEFINITIONS}")
add_executable(testexe test.cxx)
set_property(TARGET testexe APPEND
  PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
set_property(TARGET testexe APPEND
  PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
target_link_libraries(testexe ${VTK_LIBRARIES})

find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
message(STATUS "LIBS: ${VTK_LIBRARIES}")
message(STATUS "DEFS: ${VTK_DEFINITIONS}")
add_executable(testexe2 test2.cxx)
set_property(TARGET testexe2 APPEND
  PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
set_property(TARGET testexe2 APPEND
  PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
target_link_libraries(testexe2 ${VTK_LIBRARIES})

Producing the output,

-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
-- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
-- LIBS: vtkCommonCore;vtksys
-- DEFS:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/marcus/build/vtkcomponents

So the definitions were empty, as you would hope, in the second call,
the mains were very simple instantiating a vtkRenderWindow in the
first which resulted in a vtkXOpenGLRenderWindow class being
instantiated as the overrides kicked in for that target. Most projects
I know of that make multiple calls tend to use directories for each
target, and make the calls in sibling directories, but it looks like
you should be able to call it multiple times in the same scope (on
Linux with VTK master at least).

On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Adding you both to CC in case you aren't subscribed, it might also be
> worth appending NO_MODULE to the calls to ensure find modules aren't
> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
> contains advice I added, but didn't specifically cover multiple calls.
> Including the use file, or setting the DIRECTORY property will of
> course cause issues if you are not using separate directory scopes for
> each target.
>
> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Hi,
>>
>> Moving this discussion from
>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>> was saying I do not see precisely what you see, the repeated calls
>> seem to work for me locally. I would not expect the call without
>> COMPONENTS to work, and am not sure we should support calling with and
>> without COMPONENTS.
>>
>> I have a minimal CMake script,
>>
>> cmake_minimum_required(VERSION 3.0)
>>
>> find_package(VTK COMPONENTS vtkChartsCore)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK COMPONENTS vtkCommonCore)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK COMPONENTS vtkCommonMath)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK COMPONENTS vtkChartsCore)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> find_package(VTK)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>
>> This results in the output,
>>
>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>> -- The C compiler identification is GNU 4.9.1
>> -- The CXX compiler identification is GNU 4.9.1
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>> -- LIBS: vtkCommonCore;vtksys
>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>
>> As far as I can see this gives the libraries one would expect, i.e.
>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>> final one is incorrect but I am not sure of the value in supporting
>> mixed COMPONENTS and non-components versions of find_package.
>>
>> Let me know if there is something I am missing, is this possibly with
>> an older version of VTK (I am testing with master).
>>
>> Marcus


From matt.mccormick at kitware.com  Tue Sep  9 14:37:35 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 9 Sep 2014 14:37:35 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
Message-ID: <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>

Hi Marcus,

Thanks for taking a look at this. I reproduced your output with VTK
master for build a build tree and install tree.  However, I get

-- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
-- LIBS: vtkCommonCore
-- LIBS: vtkCommonMath
-- LIBS: vtkChartsCore
-- LIBS: vtkChartsCore
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/vtkcomponents/build

for an installed VTK 6.0.


What was the fix and where it was made? We would like to have similar
behavior for ITK and other CMake projects that make use of components.


I hope that multiple calls, sometimes without specifying COMPONENTS,
will still work. If it does not work, CMake should complain
informatively that a non-COMPONENTS call cannot occur after a
COMPONENTS call.

Thanks,
Matt

On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Pushing this a little further, to see if we can build executables in
> the same directory with multiple calls, the following worked for me
> locally,
>
> cmake_minimum_required(VERSION 3.0)
>
> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
> add_executable(testexe test.cxx)
> set_property(TARGET testexe APPEND
>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
> set_property(TARGET testexe APPEND
>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
> target_link_libraries(testexe ${VTK_LIBRARIES})
>
> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
> message(STATUS "LIBS: ${VTK_LIBRARIES}")
> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
> add_executable(testexe2 test2.cxx)
> set_property(TARGET testexe2 APPEND
>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
> set_property(TARGET testexe2 APPEND
>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>
> Producing the output,
>
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
> -- LIBS: vtkCommonCore;vtksys
> -- DEFS:
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/marcus/build/vtkcomponents
>
> So the definitions were empty, as you would hope, in the second call,
> the mains were very simple instantiating a vtkRenderWindow in the
> first which resulted in a vtkXOpenGLRenderWindow class being
> instantiated as the overrides kicked in for that target. Most projects
> I know of that make multiple calls tend to use directories for each
> target, and make the calls in sibling directories, but it looks like
> you should be able to call it multiple times in the same scope (on
> Linux with VTK master at least).
>
> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Adding you both to CC in case you aren't subscribed, it might also be
>> worth appending NO_MODULE to the calls to ensure find modules aren't
>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>> contains advice I added, but didn't specifically cover multiple calls.
>> Including the use file, or setting the DIRECTORY property will of
>> course cause issues if you are not using separate directory scopes for
>> each target.
>>
>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> Hi,
>>>
>>> Moving this discussion from
>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>> was saying I do not see precisely what you see, the repeated calls
>>> seem to work for me locally. I would not expect the call without
>>> COMPONENTS to work, and am not sure we should support calling with and
>>> without COMPONENTS.
>>>
>>> I have a minimal CMake script,
>>>
>>> cmake_minimum_required(VERSION 3.0)
>>>
>>> find_package(VTK COMPONENTS vtkChartsCore)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK COMPONENTS vtkCommonCore)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK COMPONENTS vtkCommonMath)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK COMPONENTS vtkChartsCore)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> find_package(VTK)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>
>>> This results in the output,
>>>
>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>> -- The C compiler identification is GNU 4.9.1
>>> -- The CXX compiler identification is GNU 4.9.1
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>> -- LIBS: vtkCommonCore;vtksys
>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>
>>> As far as I can see this gives the libraries one would expect, i.e.
>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>> final one is incorrect but I am not sure of the value in supporting
>>> mixed COMPONENTS and non-components versions of find_package.
>>>
>>> Let me know if there is something I am missing, is this possibly with
>>> an older version of VTK (I am testing with master).
>>>
>>> Marcus


From marcus.hanwell at kitware.com  Tue Sep  9 14:42:23 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Tue, 9 Sep 2014 14:42:23 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
 <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
Message-ID: <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>

Matt,

Probably commit f915a54, made after I proposed a different change that
was ultimately rejected. I didn't realize you were on 6.0 - a lot has
changed since then. I am not entirely certain what your use case is
for mixed - reallyt non one should make mixed calls and you should
prefer to always specify COMPONENTS. It would be safer to at least
spit out a warning, I can look at adding something to warn.

Marcus

On Tue, Sep 9, 2014 at 2:37 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> Hi Marcus,
>
> Thanks for taking a look at this. I reproduced your output with VTK
> master for build a build tree and install tree.  However, I get
>
> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
> -- LIBS: vtkCommonCore
> -- LIBS: vtkCommonMath
> -- LIBS: vtkChartsCore
> -- LIBS: vtkChartsCore
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /tmp/vtkcomponents/build
>
> for an installed VTK 6.0.
>
>
> What was the fix and where it was made? We would like to have similar
> behavior for ITK and other CMake projects that make use of components.
>
>
> I hope that multiple calls, sometimes without specifying COMPONENTS,
> will still work. If it does not work, CMake should complain
> informatively that a non-COMPONENTS call cannot occur after a
> COMPONENTS call.
>
> Thanks,
> Matt
>
> On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Pushing this a little further, to see if we can build executables in
>> the same directory with multiple calls, the following worked for me
>> locally,
>>
>> cmake_minimum_required(VERSION 3.0)
>>
>> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>> add_executable(testexe test.cxx)
>> set_property(TARGET testexe APPEND
>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>> set_property(TARGET testexe APPEND
>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>> target_link_libraries(testexe ${VTK_LIBRARIES})
>>
>> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>> add_executable(testexe2 test2.cxx)
>> set_property(TARGET testexe2 APPEND
>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>> set_property(TARGET testexe2 APPEND
>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>>
>> Producing the output,
>>
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
>> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
>> -- LIBS: vtkCommonCore;vtksys
>> -- DEFS:
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>
>> So the definitions were empty, as you would hope, in the second call,
>> the mains were very simple instantiating a vtkRenderWindow in the
>> first which resulted in a vtkXOpenGLRenderWindow class being
>> instantiated as the overrides kicked in for that target. Most projects
>> I know of that make multiple calls tend to use directories for each
>> target, and make the calls in sibling directories, but it looks like
>> you should be able to call it multiple times in the same scope (on
>> Linux with VTK master at least).
>>
>> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> Adding you both to CC in case you aren't subscribed, it might also be
>>> worth appending NO_MODULE to the calls to ensure find modules aren't
>>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>>> contains advice I added, but didn't specifically cover multiple calls.
>>> Including the use file, or setting the DIRECTORY property will of
>>> course cause issues if you are not using separate directory scopes for
>>> each target.
>>>
>>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Hi,
>>>>
>>>> Moving this discussion from
>>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>>> was saying I do not see precisely what you see, the repeated calls
>>>> seem to work for me locally. I would not expect the call without
>>>> COMPONENTS to work, and am not sure we should support calling with and
>>>> without COMPONENTS.
>>>>
>>>> I have a minimal CMake script,
>>>>
>>>> cmake_minimum_required(VERSION 3.0)
>>>>
>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK COMPONENTS vtkCommonCore)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK COMPONENTS vtkCommonMath)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> find_package(VTK)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>
>>>> This results in the output,
>>>>
>>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>>> -- The C compiler identification is GNU 4.9.1
>>>> -- The CXX compiler identification is GNU 4.9.1
>>>> -- Check for working C compiler: /usr/bin/cc
>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>> -- Detecting C compiler ABI info
>>>> -- Detecting C compiler ABI info - done
>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>> -- Detecting CXX compiler ABI info
>>>> -- Detecting CXX compiler ABI info - done
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>> -- LIBS: vtkCommonCore;vtksys
>>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>> -- Configuring done
>>>> -- Generating done
>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>
>>>> As far as I can see this gives the libraries one would expect, i.e.
>>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>>> final one is incorrect but I am not sure of the value in supporting
>>>> mixed COMPONENTS and non-components versions of find_package.
>>>>
>>>> Let me know if there is something I am missing, is this possibly with
>>>> an older version of VTK (I am testing with master).
>>>>
>>>> Marcus


From aaron.hickerson at ondiagnostics.com  Tue Sep  9 17:09:01 2014
From: aaron.hickerson at ondiagnostics.com (Aaron Hickerson)
Date: Tue, 9 Sep 2014 14:09:01 -0700
Subject: [vtk-developers] Request info about changes made to
 vtkRuledSurfaceFilter vtkAppendPolyData after 5.2.1
Message-ID: <CADJkAPRMFNrqpH0oiQo2GCOrAts8Ay8aa4B195KefMkt_1S6Dw@mail.gmail.com>

Hello,

I am in the process of upgrading my company OS from ubuntu10 to ubuntu14
and so I am therefore dealing with an upgrade of vtk 5.2.1 to vtk 5.8. Our
legacy software is heavily dependent on vtk and we are noticing some
unexpected differences in outcomes with the newer 5.8 library. These
differences are slight but for our regulated software we need to know why
there are ANY differences in outcomes for this new release, no matter how
small.

There were changes made to the classes vtkRuledSurfaceFilter and
vtkAppendPolyData after 5.2.1 but I cannot find any succinct explanations
as to why these changes were made. These are the two classes that I have
identified that our software is dependent on that behave differently in
this new release, and provide different outcomes. I have scoured the
internet and looked at the source code in detail but I still cannot find
any real explanation as to WHY these two classes were modified to produce
different outcomes than in previous versions.

Can anyone point me to the changelog(s) for these classes that contain
succinct explanations for the algorithmic changes?

Thanks,
Aaron Hickerson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/ca2a0072/attachment-0002.html>

From christopher.mullins at kitware.com  Tue Sep  9 17:16:05 2014
From: christopher.mullins at kitware.com (Christopher Mullins)
Date: Tue, 9 Sep 2014 17:16:05 -0400
Subject: [vtk-developers] Request info about changes made to
 vtkRuledSurfaceFilter vtkAppendPolyData after 5.2.1
In-Reply-To: <CADJkAPRMFNrqpH0oiQo2GCOrAts8Ay8aa4B195KefMkt_1S6Dw@mail.gmail.com>
References: <CADJkAPRMFNrqpH0oiQo2GCOrAts8Ay8aa4B195KefMkt_1S6Dw@mail.gmail.com>
Message-ID: <CABVTP-KfGj2+28Ne__ejxk8tBtg9qTEf2uTnRNUpF3KoUTvDmg@mail.gmail.com>

Hi Aaron.

The old front page of the wiki had a pretty good changelog on it.  I left a
link at the bottom of the current page in case anyone still wanted to see
that - here it is[1].  Maybe one of those links will help, otherwise I hope
someone else on here will be able to offer an explanation.

[1] http://www.vtk.org/Wiki/VTK/Deprecated_frontpage#VTK_5.2

On Tue, Sep 9, 2014 at 5:09 PM, Aaron Hickerson <
aaron.hickerson at ondiagnostics.com> wrote:

> Hello,
>
> I am in the process of upgrading my company OS from ubuntu10 to ubuntu14
> and so I am therefore dealing with an upgrade of vtk 5.2.1 to vtk 5.8. Our
> legacy software is heavily dependent on vtk and we are noticing some
> unexpected differences in outcomes with the newer 5.8 library. These
> differences are slight but for our regulated software we need to know why
> there are ANY differences in outcomes for this new release, no matter how
> small.
>
> There were changes made to the classes vtkRuledSurfaceFilter and
> vtkAppendPolyData after 5.2.1 but I cannot find any succinct explanations
> as to why these changes were made. These are the two classes that I have
> identified that our software is dependent on that behave differently in
> this new release, and provide different outcomes. I have scoured the
> internet and looked at the source code in detail but I still cannot find
> any real explanation as to WHY these two classes were modified to produce
> different outcomes than in previous versions.
>
> Can anyone point me to the changelog(s) for these classes that contain
> succinct explanations for the algorithmic changes?
>
> Thanks,
> Aaron Hickerson
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
Christopher Mullins
R&D Engineer
Kitware Inc.,
919.869.8871
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140909/3e44d06a/attachment-0002.html>

From david.gobbi at gmail.com  Tue Sep  9 23:01:13 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 9 Sep 2014 21:01:13 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
 <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
 <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>
Message-ID: <CANwS1=GdG3kLinS_DeB-xR8p7FYrwvTZ95mrPzBcz6vzbCH7Kw@mail.gmail.com>

Hi Utkarsh,

I found the difference between my program and your script. I was using
the vtkDataSetMapper, but if I use the vtkPolyDataMapper instead then
I see the correct behavior as ScalarColors.py.  And, of course, if I
use the vtkDataSetMapper in ScalarColors.py then it shows the odd
behavior that I described previously.

So now, the question is why vtkDataSetMapper is giving different
results than vtkPolyDataMapper.

 - David

On Tue, Sep 9, 2014 at 9:14 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> BTW, in my script, you can hit "t" to swap the ambient/diffuse coefficients.
>
> On Tue, Sep 9, 2014 at 11:13 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Here's my test script. With the patch applied, I don't see the ambient
>> and diffuse colors bleed in anymore.
>>
>> On Tue, Sep 9, 2014 at 11:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> I added SetScalarMaterialModeToAmbientAndDiffuse() and applied the
>>> patch, but it had no effect.  The results were exactly the same as in
>>> my first email.
>>>
>>> I'll have to look through the code to figure out what the intended behaviour is.
>>>
>>>  - David
>>>
>>> On Tue, Sep 9, 2014 at 8:56 AM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> Doh! Here you go.
>>>>
>>>> On Tue, Sep 9, 2014 at 10:53 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> Hi Utkarsh,
>>>>>
>>>>> The "attached patch" seems to be missing.
>>>>>
>>>>>  - David
>>>>>
>>>>> On Tue, Sep 9, 2014 at 8:44 AM, Utkarsh Ayachit
>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>> David,
>>>>>>
>>>>>> Try the attached patch and then set
>>>>>> SetScalarMaterialModeToAmbientAndDiffuse() on the mapper.
>>>>>> ScalarMaterialMode is the thing here. When set to
>>>>>> SetScalarMaterialModeToDefault(), which is the default, it determines
>>>>>> which material component should track the scalar color based on which
>>>>>> coefficient is greater (see vtkOpenGLScalarsToColorsPainter.cxx:175).
>>>>>> The patch fixes an issue where the painter was not respecting the
>>>>>> material mode set on the mapper.
>>>>>>
>>>>>> Utkarsh
>>>>>>
>>>>>> On Mon, Sep 8, 2014 at 8:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>> Hi Utkarsh,
>>>>>>>
>>>>>>> Thanks for the reply.  If I use this:
>>>>>>>
>>>>>>>   mapper->InterpolateScalarsBeforeMappingOff();
>>>>>>>
>>>>>>> then the result is exactly the same as it was before I reverted that commit.
>>>>>>>
>>>>>>>
>>>>>>> If I use this:
>>>>>>>
>>>>>>>   mapper->InterpolateScalarsBeforeMappingOn();
>>>>>>>
>>>>>>> then the result looks like the attached image, i.e. like it did in my previous
>>>>>>> email with property->SetAmbient(0.49), property->SetDiffuse(0.51), but when
>>>>>>> I reverse these I don't get the greyscale ambient lighting like in the
>>>>>>> right side
>>>>>>> of the image from my previous email.
>>>>>>>
>>>>>>>
>>>>>>> Still, I don't get what I expect unless I set one of either the ambient or the
>>>>>>> diffuse coefficient to zero.  Whenever they are both nonzero, I get the wrong
>>>>>>> result.
>>>>>>>
>>>>>>>  - David
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 8, 2014 at 5:17 PM, Utkarsh Ayachit
>>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>>>> This sounds familiar.
>>>>>>>>
>>>>>>>> Can you try reverting the following commit and see if that makes any difference:
>>>>>>>>
>>>>>>>> commit daf8c6e76ec7bb02f56dda17ce260141b7e960a5
>>>>>>>> Author: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
>>>>>>>> Date:   Fri Jul 18 15:30:37 2014 -0400
>>>>>>>>
>>>>>>>>     BUG #14828: Keep surface color from interacting with scalar color.
>>>>>>>>
>>>>>>>>     When using scalar coloring, if vtkScalarsToColorsPainter decided to use
>>>>>>>>     a texture for mapping the scalars to colors, we ended up with the
>>>>>>>>     surface color bleeding through the texture. This commit ensures that
>>>>>>>>     such bleeding is avoided.
>>>>>>>>
>>>>>>>>     We don't simply use glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE,
>>>>>>>>     GL_REPLACE), since that results in the diffuse highlights being lost.
>>>>>>>>     By enabling GL_COLOR_MATERIAL and calling glColor3f(1,1,1), we follow
>>>>>>>>     the same lighting/coloring path as we would when not using the texture
>>>>>>>>     for scalar coloring.
>>>>>>>>
>>>>>>>>     Change-Id: I9c4db15dd0db699d5d045fa7ae27696d18828988
>>>>>>>>
>>>>>>>>
>>>>>>>> Utkarsh
>>>>>>>>
>>>>>>>> On Mon, Sep 8, 2014 at 4:55 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>> Any comments on the "scalar color mapping" problem that I sent to the
>>>>>>>>> list last week?
>>>>>>>>>
>>>>>>>>>  - David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Sep 4, 2014 at 5:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>>> I've run into very odd behavior when I use Ambient and Diffuse
>>>>>>>>>> coefficients in combination with vtkDataSetMapper.  This is with
>>>>>>>>>> VTK master.
>>>>>>>>> [ snip ]
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>>


From dlrdave at aol.com  Wed Sep 10 08:30:45 2014
From: dlrdave at aol.com (David Cole)
Date: Wed, 10 Sep 2014 08:30:45 -0400
Subject: [vtk-developers] Wiki example strangeness
Message-ID: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>

This example:
http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/CurvatureBandsWithGlyphs

Clearly contains:
renWin->SetSize(800, 800);

Why, then does the alternate valid image 
"Testing/Baseline/Visualization/TestCurvatureBandsWithGlyphs_1.png" [1] 
in the VTK wiki examples git repository have dimensions 800 x 771? Why 
is an image of a different size considered valid?

And ..... why are the images so different? Shouldn't the randomly 
generated images seen in this example be identical because of random 
seeding? Compare to the primary baseline image at [2].


Thanks for any insight,
David C.


[1] 
https://gitorious.org/vtkwikiexamples/wikiexamples/source/09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/TestCurvatureBandsWithGlyphs_1.png
[2] 
https://gitorious.org/vtkwikiexamples/wikiexamples/source/09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/TestCurvatureBandsWithGlyphs.png



From andrew.amaclean at gmail.com  Wed Sep 10 08:46:32 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 10 Sep 2014 22:46:32 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
Message-ID: <CAHDsG9PsjiFakxciNppWwTOC6e=_wz-dJC_weDSy-w_9OzcjQg@mail.gmail.com>

The first image is generated on a windows machine and the second is done on
a Linux machine. The same random seed is used but the random number
generator is different for windows & Linux hence the different shaped
hills. Both images should be 800 x800.

Andrew
On Sep 10, 2014 10:30 PM, "David Cole" <dlrdave at aol.com> wrote:

> This example:
> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/
> CurvatureBandsWithGlyphs
>
> Clearly contains:
> renWin->SetSize(800, 800);
>
> Why, then does the alternate valid image "Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png" [1] in the VTK wiki examples git
> repository have dimensions 800 x 771? Why is an image of a different size
> considered valid?
>
> And ..... why are the images so different? Shouldn't the randomly
> generated images seen in this example be identical because of random
> seeding? Compare to the primary baseline image at [2].
>
>
> Thanks for any insight,
> David C.
>
>
> [1] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png
> [2] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs.png
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140910/55bc1142/attachment-0002.html>

From utkarsh.ayachit at kitware.com  Wed Sep 10 08:56:38 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 10 Sep 2014 08:56:38 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=GdG3kLinS_DeB-xR8p7FYrwvTZ95mrPzBcz6vzbCH7Kw@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <CANwS1=Fa2u1uvQS+E3-iPdsycg0ca+DVXCaMHQDsSS1tuN2dGA@mail.gmail.com>
 <CADHSJjCKCb3jxUAotXkMOTZ7xbSug2AoLUHpWvDS67EdAeCJcQ@mail.gmail.com>
 <CANwS1=F_Xj1C0Gh3Nc4c8_ZNQ4beKMs=TaUP+Sxi_ByHox_ZKA@mail.gmail.com>
 <CADHSJjBPNvwhFhuRqKNS0a5nRCQdqCV8pM8Uzk4fG+_VKy+Upw@mail.gmail.com>
 <CANwS1=EHDDHob=8Z66y8ocbZDzaP6ChwR8EdCecFDQhHBoCw6Q@mail.gmail.com>
 <CADHSJjAHY7ccc0gBbTA910H2MtuhP9xmxP2UQMKbeoyHg7uq0Q@mail.gmail.com>
 <CANwS1=EUVgWAQNYgGaofpqa0Gnr9CRmgpQPW4DoDQa+LkL8jTg@mail.gmail.com>
 <CADHSJjBcxt1rfQ6e_xQ+xCmxBpBhSn6xZ2AoqF-DX6jg09TuTA@mail.gmail.com>
 <CADHSJjAbYQEUdOGg47VXZ4eC37g0KrjoTwvSNozikOoHFFRQMQ@mail.gmail.com>
 <CANwS1=GdG3kLinS_DeB-xR8p7FYrwvTZ95mrPzBcz6vzbCH7Kw@mail.gmail.com>
Message-ID: <CADHSJjAho0HcjSYy3yV+jb_mnkqzh8dZATxpXWQDj_8sfDqOaw@mail.gmail.com>

> So now, the question is why vtkDataSetMapper is giving different
> results than vtkPolyDataMapper.

That's easy. The vtkDataSetMapper doesn't seem to pass all the iVar
values to the internal vtkPolyDataMapper. Hence the ScalarMaterialMode
set on vtkDataSetMapper is lost.

I'll add a test and push the patch I sent to gerrit soon.

Utkarsh


From andrew.amaclean at gmail.com  Wed Sep 10 09:12:37 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 10 Sep 2014 23:12:37 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
Message-ID: <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>

Continuing on ...
With respect to the first image, I suspect that this may be fixed in the
master by your submission: http://review.source.kitware.com/#/c/16872/
and/or http://review.source.kitware.com/#/c/16873/

As for the differences between the hill shapes in Windows and Linux, the
same RNG needs to be used in all machines. I'll look at using one of the
ones in vtkMath.h at some stage. There is an option to turn off random
generation and generate regular shaped hills, but it is pretty boring.

Andrew
 On Sep 10, 2014 10:30 PM, "David Cole" <dlrdave at aol.com> wrote:

> This example:
> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/
> CurvatureBandsWithGlyphs
>
> Clearly contains:
> renWin->SetSize(800, 800);
>
> Why, then does the alternate valid image "Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png" [1] in the VTK wiki examples git
> repository have dimensions 800 x 771? Why is an image of a different size
> considered valid?
>
> And ..... why are the images so different? Shouldn't the randomly
> generated images seen in this example be identical because of random
> seeding? Compare to the primary baseline image at [2].
>
>
> Thanks for any insight,
> David C.
>
>
> [1] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs_1.png
> [2] https://gitorious.org/vtkwikiexamples/wikiexamples/source/
> 09a4920a453052c36ad08d2994565dbec73a2107:Testing/Baseline/Visualization/
> TestCurvatureBandsWithGlyphs.png
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140910/c763c676/attachment-0002.html>

From berk.geveci at kitware.com  Wed Sep 10 20:14:33 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 10 Sep 2014 20:14:33 -0400
Subject: [vtk-developers] The recently introduce vtkPythonAlgorithm
Message-ID: <CAE32kpU7ruvTXa0G1wsS6eu5urwW=KEjRy731jFMS=Cs_JCaAA@mail.gmail.com>

Hi folks,

I wanted to do a little marketing for a class Ben Boeckel recently added to
VTK. I wrote a fairly long article on it recently:

http://www.kitware.com/blog/home/post/737

This class and the supporting Python classes allow one to develop
fully-functional subclasses of vtkAlgorithm purely in Python. Something we
haven't had until now.

I also wrote a who slew of articles on how to leverage the also recently
introduced numpy_support module to do a lot of thing from purely Python
without loosing efficiency. If you are interested, here is the list:

http://www.kitware.com/blog/home/user/53

I will be following these with more articles on developing sophisticated
algorithms in Python and some cool examples.

Best,
-berk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140910/33b88e8c/attachment-0002.html>

From dlrdave at aol.com  Thu Sep 11 07:21:13 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 07:21:13 -0400
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
Message-ID: <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>

Thanks Andrew.

If you are busy, I can investigate making this consistent on Linux and 
Windows. Is the right place to start looking in the wiki example code, 
or is it in VTK itself?

Thanks,
D



From andrew.amaclean at gmail.com  Thu Sep 11 07:37:18 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Thu, 11 Sep 2014 21:37:18 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
Message-ID: <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>

David,
The difference between the Windows and Linux appearance is in the VTK code
itself, due to the fact that I have just used the system RNGs. I just have
to bring in vtkMath.h as there are a couple of RNG's there.  I'll try and
get something up for review before the 20th if that is OK.

Andrew
On Sep 11, 2014 9:21 PM, "David Cole" <dlrdave at aol.com> wrote:

> Thanks Andrew.
>
> If you are busy, I can investigate making this consistent on Linux and
> Windows. Is the right place to start looking in the wiki example code, or
> is it in VTK itself?
>
> Thanks,
> D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140911/1702a142/attachment-0002.html>

From dlrdave at aol.com  Thu Sep 11 07:40:42 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 07:40:42 -0400
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
Message-ID: <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>

Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.

D



From cory.quammen at kitware.com  Thu Sep 11 11:07:24 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Thu, 11 Sep 2014 11:07:24 -0400
Subject: [vtk-developers] Single test file used for more than one test?
Message-ID: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>

Hi all,

I'm writing a VTK test that takes some command-line arguments to
control some options in a filter. What I would like to do is define
several tests in the CMakeLists.txt file that run this same code but
which pass different arguments in through argv[].

I haven't found an example of this kind of test in VTK. Most tests are
defined by passing to vtk_add_test_cxx the name of the source file for
the test.

Can anyone point me to an example similar to what I want to do?

Thanks!
Cory


From bill.lorensen at gmail.com  Thu Sep 11 11:09:02 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 11 Sep 2014 11:09:02 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <CADZJ4hOiBt3bXJFJG97QFBUfXHHAQE7TiYEaBCY+m9M1ARa=JA@mail.gmail.com>

Cory,

I don't think vtk supports that capability. Might need a new testing macro?

Bill

On Thu, Sep 11, 2014 at 11:07 AM, Cory Quammen <cory.quammen at kitware.com> wrote:
> Hi all,
>
> I'm writing a VTK test that takes some command-line arguments to
> control some options in a filter. What I would like to do is define
> several tests in the CMakeLists.txt file that run this same code but
> which pass different arguments in through argv[].
>
> I haven't found an example of this kind of test in VTK. Most tests are
> defined by passing to vtk_add_test_cxx the name of the source file for
> the test.
>
> Can anyone point me to an example similar to what I want to do?
>
> Thanks!
> Cory
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>



-- 
Unpaid intern in BillsBasement at noware dot com


From dave.demarle at kitware.com  Thu Sep 11 11:13:55 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 11 Sep 2014 11:13:55 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <CANjZAi_QuvztpdrJJA5RjK7BU-GRZvC6UKpkL4tob7-PyRR-vw@mail.gmail.com>

In Accelerators/Piston/Testing/Python/CMakeLists.txt we set a different
test name prefix for each variation of the argument.

I agree with Bill, for Cxx you may need to make up a new testing macro.

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

On Thu, Sep 11, 2014 at 11:07 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Hi all,
>
> I'm writing a VTK test that takes some command-line arguments to
> control some options in a filter. What I would like to do is define
> several tests in the CMakeLists.txt file that run this same code but
> which pass different arguments in through argv[].
>
> I haven't found an example of this kind of test in VTK. Most tests are
> defined by passing to vtk_add_test_cxx the name of the source file for
> the test.
>
> Can anyone point me to an example similar to what I want to do?
>
> Thanks!
> Cory
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140911/1cc1869f/attachment-0002.html>

From burlen.loring at gmail.com  Thu Sep 11 11:22:36 2014
From: burlen.loring at gmail.com (Burlen Loring)
Date: Thu, 11 Sep 2014 08:22:36 -0700
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <5411BE3C.7030207@gmail.com>

Hi Cory,

That's how the surface LIC tests are written. Take a look at 
VTK/Rendering/LIC/Testing/Cxx/CMakeLists.txt

Burlen

On 09/11/2014 08:07 AM, Cory Quammen wrote:
> Hi all,
>
> I'm writing a VTK test that takes some command-line arguments to
> control some options in a filter. What I would like to do is define
> several tests in the CMakeLists.txt file that run this same code but
> which pass different arguments in through argv[].
>
> I haven't found an example of this kind of test in VTK. Most tests are
> defined by passing to vtk_add_test_cxx the name of the source file for
> the test.
>
> Can anyone point me to an example similar to what I want to do?
>
> Thanks!
> Cory
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>



From david.gobbi at gmail.com  Thu Sep 11 13:32:16 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 11:32:16 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
Message-ID: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>

Hi All,

The OS X interactors (Cocoa and Carbon) currently interpret the
Command key as "Alt", which I find to be counterintuitive.

OS X generally interprets the "Command" key the same way that
Windows and Linux interpret the "Ctrl" key, so it seems to me that it
would make more sense VTK apps to interpret "Command" as "Ctrl".

The current behavior (Command as "Alt") was added by Sebastien
Barre in 2006, and he included this comment:
// Even though the option key is the one with a small 'alt' label on top
// of it, VNC (as well as some Mac users) uses the command key as 'alt'.

I'm not sure if the part about VNC is correct, but the part about Mac
users using the Command key as "Alt" does not ring true.

Does anyone else think that it is worth changing the behaviour so
that the OS X "Command" key is interpreted by VTK apps the same
way as "Ctrl"?  OS X users will still be able to apply the "Alt" modifier,
because the OS X "Opt" key is equivalent to "Alt".

 - David


From utkarsh.ayachit at kitware.com  Thu Sep 11 13:59:24 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 11 Sep 2014 13:59:24 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
References: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
Message-ID: <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>

> Does anyone else think that it is worth changing the behaviour so
> that the OS X "Command" key is interpreted by VTK apps the same
> way as "Ctrl"?  OS X users will still be able to apply the "Alt" modifier,
> because the OS X "Opt" key is equivalent to "Alt".

+1


From dlrdave at aol.com  Thu Sep 11 14:26:37 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 14:26:37 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>
References: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
 <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>
Message-ID: <8D19C050EB6EE69-37B0-443EF@webmail-m223.sysops.aol.com>

>> Does anyone else think that it is worth changing the behaviour so
>> that the OS X "Command" key is interpreted by VTK apps the same
>> way as "Ctrl"?  OS X users will still be able to apply the "Alt" 
modifier,
>> because the OS X "Opt" key is equivalent to "Alt".
>
> +1

But my Apple keyboard has a "control" key too... Would "control" and 
"command" be two keys on the keyboard that do exactly the same thing 
then?



From david.gobbi at gmail.com  Thu Sep 11 14:35:36 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 12:35:36 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <8D19C050EB6EE69-37B0-443EF@webmail-m223.sysops.aol.com>
References: <CANwS1=Fk5v8i+VyXnt_qtQBt4ODbG8oQ5ZCTuFufG9mEKoF+XA@mail.gmail.com>
 <CADHSJjBTSgLG6UZ7YhhYMtauDKV0fVgeVMXN3BVbPQT-ZkAd6g@mail.gmail.com>
 <8D19C050EB6EE69-37B0-443EF@webmail-m223.sysops.aol.com>
Message-ID: <CANwS1=HYOBuZO3A+44Fn79Cqf2tT8M5U2FcuTnv9PgL6w+Wxcw@mail.gmail.com>

On Thu, Sep 11, 2014 at 12:26 PM, David Cole <dlrdave at aol.com> wrote:
> But my Apple keyboard has a "control" key too... Would "control" and
> "command" be two keys on the keyboard that do exactly the same thing then?

Yes.  The VTK interactors only support three modifiers (Control, Shift, Alt), so
aliasing is unavoidable unless we ignore one of the keys altogether.

 - David


From biddisco at cscs.ch  Thu Sep 11 15:00:17 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Thu, 11 Sep 2014 19:00:17 +0000
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
Message-ID: <D037BD6C.66DC8%biddisco@cscs.ch>

Does this help


  FOREACH(N 1 2 3 4 8 16 32 64)

    SET(test_name "TestH5PartParallelWriter-P${N}")

      #

      # Serial N==1

      #

      IF (N EQUAL 1)

        ADD_TEST(

          NAME ${test_name}

          COMMAND

            $<TARGET_FILE:TestH5PartParallelWriter>

            -generateParticles 1000000

            -F temp.h5

            -D ${PLUGIN_TEST_DIR}

            -T "${PLUGIN_TEST_DIR}"

            -testName ${test_name}

        )

      ENDIF (N EQUAL 1)

      #

      # Parallel N>1

      #

      IF (N GREATER 1)

        greater_equal(${MPIEXEC_MAX_NUMPROCS} ${N} processors)

        IF (processors)

          ADD_TEST(

          NAME ${test_name}

          COMMAND

            ${MPIEXEC} ${MPIEXEC_PREFLAGS} ${MPIEXEC_NUMPROC_FLAG} ${N}

            $<TARGET_FILE:TestH5PartParallelWriter>

            -generateParticles 1000000

            -F temp.h5

            -D ${PLUGIN_TEST_DIR}

            -T "${PLUGIN_TEST_DIR}"

            -testName ${test_name}

        )

        ENDIF (processors)

    ENDIF (N GREATER 1)

  ENDFOREACH(N)


On 11/09/14 17:07, "Cory Quammen" <cory.quammen at kitware.com<mailto:cory.quammen at kitware.com>> wrote:

Hi all,

I'm writing a VTK test that takes some command-line arguments to
control some options in a filter. What I would like to do is define
several tests in the CMakeLists.txt file that run this same code but
which pass different arguments in through argv[].

I haven't found an example of this kind of test in VTK. Most tests are
defined by passing to vtk_add_test_cxx the name of the source file for
the test.

Can anyone point me to an example similar to what I want to do?

Thanks!
Cory
_______________________________________________
Powered by www.kitware.com

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

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



From dlrdave at aol.com  Thu Sep 11 16:09:59 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 16:09:59 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
Message-ID: <8D19C137F0F1769-37B0-454FA@webmail-m223.sysops.aol.com>

> The VTK interactors only support three modifiers (Control, Shift,
> Alt), so aliasing is unavoidable unless we ignore one of the keys
> altogether.

I'm ok with swapping it to be "same as control" instead of "same as alt"

But I must say, I am used to using the "Alt" key on my Windows keyboard
to do Mac command-key shortcuts when I'm VNC'ed into my Mac. This
change may confuse some people momentarily, and it might make it
difficult to do "Alt" stuff on a Mac from a non-Mac keyboard... but in
my opinion, it's not a big deal any way you slice it.

If you do change the behavior, just document it accordingly, perhaps
mentioning that it changed from one to the other in VTK 6.2 somewhere.


D





From david.gobbi at gmail.com  Thu Sep 11 16:36:50 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 14:36:50 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <8D19C137F0F1769-37B0-454FA@webmail-m223.sysops.aol.com>
References: <8D19C137F0F1769-37B0-454FA@webmail-m223.sysops.aol.com>
Message-ID: <CANwS1=FmfQxV3NgaAv6vwQ=a-=dF9u5-sY5UomGQzdBguKZ5_Q@mail.gmail.com>

On Thu, Sep 11, 2014 at 2:09 PM, David Cole <dlrdave at aol.com> wrote:
>
> If you do change the behavior, just document it accordingly, perhaps
> mentioning that it changed from one to the other in VTK 6.2 somewhere.

Document it where, though?  I can prod Dave DeMarle to mention it in the
VTK 6.2 release notes, but other than that, there isn't really any other way
to document VTK changes like this.

 - David


From cory.quammen at kitware.com  Thu Sep 11 17:38:19 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Thu, 11 Sep 2014 17:38:19 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <5411BE3C.7030207@gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
 <5411BE3C.7030207@gmail.com>
Message-ID: <CAB5Fpx54C2P=oJgRaip=eSK1Cpkta1BasNApAa60mwZyK9C93A@mail.gmail.com>

Burlen,

Thanks for the pointer. I like that your example is explicit in what
is being passed to the tests.

To use the more "magic" vtk_add_test_cxx() function, it turns out you
can do the following:

set(vtk_test_prefix Second)
vtk_add_test_cxx(${vtk-module}CxxTests tests
  SurfacePlusEdges.cxx --arg1 --arg2 --arg3
)
unset(vtk_test_prefix)

And this will define a test named $(vtk-module}Cxx-SecondSurfacePlusEdges.

In it's current form, this test will point to a baseline named
SurfacePlusEdges.png. To point it to a baseline for just this test, I
had to modify vtkTestingMacros.cmake to include vtk_test_prefix in the
baseline path. The modifications are on gerrit:

http://review.source.kitware.com/#/t/4648/

This specifies the baseline file name as SecondSurfacePlusEdges.png.

Reviews for this topic are appreciated :-)

I'm not sure if I'm thrilled with defining the test name this way. It
would be nicer to do something like

vtk_add_test_cxx(${vtk-module}CxxTests tests
  SurfacePlusEdges.cxx --arg0 --arg1 --arg2
  SurfacePlusEdges.cxx,CUSTOM_NAME SurfacePlusEdges2 --arg3 --arg4 --arg5
)

where if CUSTOM_NAME is specified, the first argument is the test name.

Thanks,
Cory

On Thu, Sep 11, 2014 at 11:22 AM, Burlen Loring <burlen.loring at gmail.com> wrote:
> Hi Cory,
>
> That's how the surface LIC tests are written. Take a look at
> VTK/Rendering/LIC/Testing/Cxx/CMakeLists.txt
>
> Burlen
>
>
> On 09/11/2014 08:07 AM, Cory Quammen wrote:
>>
>> Hi all,
>>
>> I'm writing a VTK test that takes some command-line arguments to
>> control some options in a filter. What I would like to do is define
>> several tests in the CMakeLists.txt file that run this same code but
>> which pass different arguments in through argv[].
>>
>> I haven't found an example of this kind of test in VTK. Most tests are
>> defined by passing to vtk_add_test_cxx the name of the source file for
>> the test.
>>
>> Can anyone point me to an example similar to what I want to do?
>>
>> Thanks!
>> Cory
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>


From dlrdave at aol.com  Thu Sep 11 21:11:26 2014
From: dlrdave at aol.com (David Cole)
Date: Thu, 11 Sep 2014 21:11:26 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
Message-ID: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>

> Document it where, though?

Perhaps here:
http://www.vtk.org/doc/nightly/html/classvtkCocoaRenderWindowInteractor.html#details

And here:
http://www.vtk.org/doc/nightly/html/classvtkCarbonRenderWindowInteractor.html#details

Prodding Mr. DeMarle to include it in the release notes, or on a wiki
page about the next release, is also a good idea.

I know it's minor, but it is a change in behavior.


D




From david.gobbi at gmail.com  Fri Sep 12 00:10:31 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 11 Sep 2014 22:10:31 -0600
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>
References: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>
Message-ID: <CANwS1=HV40H+1Rg4xONWOzRKYZFXg1YUawu=LfZGRD0ZmR5u9Q@mail.gmail.com>

On Thu, Sep 11, 2014 at 7:11 PM, David Cole <dlrdave at aol.com> wrote:
>> Document it where, though?
>
> Perhaps here:
> http://www.vtk.org/doc/nightly/html/classvtkCocoaRenderWindowInteractor.html#details
> http://www.vtk.org/doc/nightly/html/classvtkCarbonRenderWindowInteractor.html#details

Will do.  Sorry for my general grumpiness, winter arrived in my city
two months early :^(

 - David


From andrew.amaclean at gmail.com  Fri Sep 12 04:54:55 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 12 Sep 2014 18:54:55 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
 <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
Message-ID: <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>

All pushed to gerrit, you and Bill have been added as reviewers, see:
http://review.source.kitware.com/16994

After it is reviewed, I'll update the the examples with new pictures, I
will also adjust the banding ranges for the curvature example.

Regards
   Andrew
On Sep 11, 2014 9:40 PM, "David Cole" <dlrdave at aol.com> wrote:

> Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.
>
> D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140912/5aa38626/attachment-0002.html>

From dlrdave at aol.com  Fri Sep 12 06:22:07 2014
From: dlrdave at aol.com (David Cole)
Date: Fri, 12 Sep 2014 06:22:07 -0400
Subject: [vtk-developers] Command key on OS X: Ctrl or Alt?
In-Reply-To: <CANwS1=HV40H+1Rg4xONWOzRKYZFXg1YUawu=LfZGRD0ZmR5u9Q@mail.gmail.com>
References: <8D19C3D9C7E6616-2B64-43274@webmail-m253.sysops.aol.com>
 <CANwS1=HV40H+1Rg4xONWOzRKYZFXg1YUawu=LfZGRD0ZmR5u9Q@mail.gmail.com>
Message-ID: <8D19C8A8A19E7B4-2B64-44BC2@webmail-m253.sysops.aol.com>

No worries. I am often frustrated when trying to figure out where to 
document conceptual things that aren't really part of a single method 
or class.

Move south! We don't have to shovel down here - I would be grumpy too 
if I had to shovel in September...


D



From andrew.amaclean at gmail.com  Sun Sep 14 18:44:43 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Mon, 15 Sep 2014 08:44:43 +1000
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
 <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
 <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>
Message-ID: <CAHDsG9P4QZx+5y1fyGbyTGtC8JSrO=cdXmUxfpUnJ2iW4-Xc7Q@mail.gmail.com>

Hi Bill, David
The wiki examples have been updated with new pictures and the banding range
adjusted for the curvature example.
See:
http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/ElevationBandsWithGlyphs
http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/CurvatureBandsWithGlyphs
and the corresponding C++ versions.

This is a consequence of vtkRandomHills now using
vtkMinimalStandardRandomSequence to generate
a random sequence instead of the native random number generators.

Regards
   Andrew


On Fri, Sep 12, 2014 at 6:54 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> All pushed to gerrit, you and Bill have been added as reviewers, see:
> http://review.source.kitware.com/16994
>
> After it is reviewed, I'll update the the examples with new pictures, I
> will also adjust the banding ranges for the curvature example.
>
> Regards
>    Andrew
> On Sep 11, 2014 9:40 PM, "David Cole" <dlrdave at aol.com> wrote:
>
>> Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.
>>
>> D
>>
>>


-- 
___________________________________________
Andrew J. P. Maclean

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

From will.schroeder at kitware.com  Mon Sep 15 06:17:07 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Mon, 15 Sep 2014 06:17:07 -0400
Subject: [vtk-developers] Wiki example strangeness
In-Reply-To: <CAHDsG9P4QZx+5y1fyGbyTGtC8JSrO=cdXmUxfpUnJ2iW4-Xc7Q@mail.gmail.com>
References: <8D19B0A2D2726F6-1768-394C8@webmail-m244.sysops.aol.com>
 <CAHDsG9M+xzxz+k_dfL0C3LcwaVEtp2e+ANNMuvFqqfgMLWcq1Q@mail.gmail.com>
 <8D19BC9A10B19FA-CB4-46662@webmail-m172.sysops.aol.com>
 <CAHDsG9O5j7qGLE47ZvqdeYZFJ-6DOZn53s_sdnkmeReom3Lrkw@mail.gmail.com>
 <8D19BCC5A5FC9FD-37B0-40878@webmail-m223.sysops.aol.com>
 <CAHDsG9OjthphcH17zRsx33AnNrQshH_-LVb=Wwh9wOtBN=15ow@mail.gmail.com>
 <CAHDsG9P4QZx+5y1fyGbyTGtC8JSrO=cdXmUxfpUnJ2iW4-Xc7Q@mail.gmail.com>
Message-ID: <CAEiDrtXP89+CAz14oECOqxE_NsVRkg46ZTDt7Ao9dUKTLOKCNw@mail.gmail.com>

>From the examples: "Rather beautiful surfaces are generated."

Indeed!

On Sun, Sep 14, 2014 at 6:44 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Hi Bill, David
> The wiki examples have been updated with new pictures and the banding
> range adjusted for the curvature example.
> See:
>
> http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/ElevationBandsWithGlyphs
>
> http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/CurvatureBandsWithGlyphs
> and the corresponding C++ versions.
>
> This is a consequence of vtkRandomHills now using
> vtkMinimalStandardRandomSequence to generate
> a random sequence instead of the native random number generators.
>
> Regards
>    Andrew
>
>
> On Fri, Sep 12, 2014 at 6:54 PM, Andrew Maclean <andrew.amaclean at gmail.com
> > wrote:
>
>> All pushed to gerrit, you and Bill have been added as reviewers, see:
>> http://review.source.kitware.com/16994
>>
>> After it is reviewed, I'll update the the examples with new pictures, I
>> will also adjust the banding ranges for the curvature example.
>>
>> Regards
>>    Andrew
>> On Sep 11, 2014 9:40 PM, "David Cole" <dlrdave at aol.com> wrote:
>>
>>> Totally OK -- thanks. Add me as a reviewer when you push it to gerrit.
>>>
>>> D
>>>
>>>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
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/20140915/37525611/attachment-0002.html>

From Gerrick.Bivins at halliburton.com  Mon Sep 15 10:02:22 2014
From: Gerrick.Bivins at halliburton.com (Gerrick Bivins)
Date: Mon, 15 Sep 2014 14:02:22 +0000
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
Message-ID: <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>

Hi Rostislav,
Did anything happen with this?
I would definitely be interested in this capability/feature/improvement.

Gerrick

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Tuesday, August 12, 2014 11:44 AM
To: Rostislav Khlebnikov
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi Rostislav,

This is great. Can you push the code to Gerrit (http://review.source.kitware.com/)?

Best,
-berk


On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov <rostislav.khlebnikov at kcl.ac.uk<mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
Hi guys,

just thought that the VTK developers might be interested in the test I made recently.

Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata.
Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms.

The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through.

But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code?

All best,
   Rostislav.

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

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

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


----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140915/550fa685/attachment-0002.html>

From rostislav.khlebnikov at kcl.ac.uk  Mon Sep 15 13:07:18 2014
From: rostislav.khlebnikov at kcl.ac.uk (Rostislav Khlebnikov)
Date: Mon, 15 Sep 2014 18:07:18 +0100
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
Message-ID: <54171CC6.9030407@kcl.ac.uk>

Hi,

well, basically, I feel that it is necessary to create a proper change 
to use Gerrit workflow successfully. Unfortunately, I don't quite have 
the time to do this properly for several reasons. One of them is that I 
actually don't need this change - for my project I integrated the 
CGAL-based cutting approach with AABB_tree which outperforms my VTK test 
- for example for the same test with 500k triangles CGAL-based cutting 
takes only 2ms. This will soon be integrated to MITK (in case anyone is 
interested, the pull request can be found here: 
https://github.com/MITK/MITK/pull/73). Making a proper VTK change would 
involve quite a lot of effort. Given that vtkCutter is very general and 
rejecting the octree nodes might be complex for arbitrary implicit 
functions, it seems to require quite a lot of work to avoid incorrect usage.

I can clean up the code a bit and post it to the mailing list if you are 
interested.

All best,
    Rostislav.


On 15/09/2014 15:02, Gerrick Bivins wrote:
>
> Hi Rostislav,
>
> Did anything happen with this?
>
> I would definitely be interested in this capability/feature/improvement.
>
> Gerrick
>
> *From:*vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On 
> Behalf Of *Berk Geveci
> *Sent:* Tuesday, August 12, 2014 11:44 AM
> *To:* Rostislav Khlebnikov
> *Cc:* VTK Developers
> *Subject:* Re: [vtk-developers] vtkCutter modification to use 
> vtkCellLocator
>
> Hi Rostislav,
>
> This is great. Can you push the code to Gerrit 
> (http://review.source.kitware.com/)?
>
> Best,
>
> -berk
>
> On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov 
> <rostislav.khlebnikov at kcl.ac.uk 
> <mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
>
> Hi guys,
>
> just thought that the VTK developers might be interested in the test I 
> made recently.
>
> Bascially what I did is subclass the vtkCellLocator to implement the 
> visitor pattern. It allows to filter the octree nodes (e.g. reject the 
> octree nodes that are of no interest early) and for leafs, to visit 
> the cells of the polydata.
> Then, I subclassed the vtkCutter to use this cell locator instead of 
> straight iteration over cells. Likely for very complex implicit 
> cutting functions this wouldnt be of any benefit. However, for those 
> which can test bboxes as being of interest or not, rejecting whole 
> subtrees, such as vtkPlane, it is very useful. I tested it on a 
> surface with 500k triangles and the cutter performance went from 88ms 
> per cut to 14ms.
>
> The code I made is quite ugly due to limited extensibility of 
> vtkCutter, so I had to copy-paste the RequestData method and make my 
> changes instead of, say, overriding IterateCells method which would 
> just provide the cells to cut through.
>
> But anyway, I was wondering if you guys are intersted in this kind of 
> functionality? Would you like me to send you the code?
>
> All best,
>    Rostislav.
>
> _______________________________________________
> Powered by www.kitware.com <http://www.kitware.com>
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html 
> <http://www.kitware.com/opensource/opensource.html>
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
> ------------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential 
> and privileged information for the sole use of the intended recipient. 
> Any review, use, distribution, or disclosure by others is strictly 
> prohibited. If you are not the intended recipient (or authorized to 
> receive information for the intended recipient), please contact the 
> sender by reply e-mail and delete all copies of this message.

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

From Gerrick.Bivins at halliburton.com  Mon Sep 15 14:28:14 2014
From: Gerrick.Bivins at halliburton.com (Gerrick Bivins)
Date: Mon, 15 Sep 2014 18:28:14 +0000
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <54171CC6.9030407@kcl.ac.uk>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
 <54171CC6.9030407@kcl.ac.uk>
Message-ID: <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>

Yes. I would definitely be interested in seeing the code.
Gerrick

From: Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
Sent: Monday, September 15, 2014 12:07 PM
To: Gerrick Bivins; Berk Geveci
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi,

well, basically, I feel that it is necessary to create a proper change to use Gerrit workflow successfully. Unfortunately, I don't quite have the time to do this properly for several reasons. One of them is that I actually don't need this change - for my project I integrated the CGAL-based cutting approach with AABB_tree which outperforms my VTK test - for example for the same test with 500k triangles CGAL-based cutting takes only 2ms. This will soon be integrated to MITK (in case anyone is interested, the pull request can be found here: https://github.com/MITK/MITK/pull/73). Making a proper VTK change would involve quite a lot of effort. Given that vtkCutter is very general and rejecting the octree nodes might be complex for arbitrary implicit functions, it seems to require quite a lot of work to avoid incorrect usage.

I can clean up the code a bit and post it to the mailing list if you are interested.

All best,
   Rostislav.

On 15/09/2014 15:02, Gerrick Bivins wrote:
Hi Rostislav,
Did anything happen with this?
I would definitely be interested in this capability/feature/improvement.

Gerrick

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Tuesday, August 12, 2014 11:44 AM
To: Rostislav Khlebnikov
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi Rostislav,

This is great. Can you push the code to Gerrit (http://review.source.kitware.com/)?

Best,
-berk


On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov <rostislav.khlebnikov at kcl.ac.uk<mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
Hi guys,

just thought that the VTK developers might be interested in the test I made recently.

Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata.
Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms.

The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through.

But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code?

All best,
   Rostislav.

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

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

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

________________________________
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

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

From andrew.amaclean at gmail.com  Mon Sep 15 19:40:14 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Tue, 16 Sep 2014 09:40:14 +1000
Subject: [vtk-developers] OpenGL2 TestParametricFunctions Failures
Message-ID: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>

I see that TestParametricFunctions.py consistently fails on all the OpenGL2
test machines:
http://open.cdash.org/testSummary.php?project=11&name=vtkCommonComputationalGeometryPython-TestParametricFunctions&date=2014-09-15

vttkParametricRandomHills.cxx was recently changed and the associated test
image for TestParametricFunctions.py updated.

It seems that on these machines, the new valid image has not been
downloaded there are also other OpenGL errors, here is a summary:

Valid Image incorrect, test image - vtkTextMapper not working:
dash1win7.kitware Win32-vs11-OpenGL2
londinium.kitware   Arch-GCC-4.9-x86_64-opengl2

The above machines display this error:
ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58
vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1


Valid Image incorrect, test image - vtkTextMapper not working:
kargad.kitware  MacLion-OpenGL2

Valid Image incorrect, test image - vtkTextMapper not working.
On the test image: Torus, Fig-8 Klein, Mobius, Super Toroid, Dini,
Random Hills and part of Roman all blacked out.
curius.kitware  fedora-x64-gcc-master-debug-ATI-RadeonHD-5870-OpenGL2

For the above two machines the errors seem to be mainly:
ERROR: In
/home/kitware/Dashboards/MyTests/VTK/Nightly/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
line 1458
vtkXOpenGLRenderWindow (0x2cb96a0): Hardware does not support the number of
textures defined.
and
ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58
vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1

Aside from the fact that the valid test images haven't been updated, is
there some issue with my code that I can fix?

Andrew

-- 
___________________________________________
Andrew J. P. Maclean

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

From ken.martin at kitware.com  Tue Sep 16 09:07:38 2014
From: ken.martin at kitware.com (Ken Martin)
Date: Tue, 16 Sep 2014 09:07:38 -0400
Subject: [vtk-developers] OpenGL2 TestParametricFunctions Failures
In-Reply-To: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>
References: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>
Message-ID: <cbe0fa22ef08a3c2cb0689da3692a0ea@mail.gmail.com>

I think you are good Andrew. I?m pretty sure there is a leak in one of the
texture resources in the OpenGL2 backend which may be part of some of the
failures. I?ll take a look at that when I get back to dashboards. Curius
was an old ATI Linux system running a driver that is not from ATI.  The
driver is broken and we decided to not work around it and removed that
dashboard.



Thanks!

Ken



Ken Martin PhD

Chairman & CFO

Kitware Inc.

28 Corporate Drive

Clifton Park NY 12065

ken.martin at kitware.com

518 881-4901 (w)

518 371-4573 (f)



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.



*From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
Of *Andrew Maclean
*Sent:* Monday, September 15, 2014 7:40 PM
*To:* VTK Developers
*Subject:* [vtk-developers] OpenGL2 TestParametricFunctions Failures





I see that TestParametricFunctions.py consistently fails on all the OpenGL2
test machines:

http://open.cdash.org/testSummary.php?project=11&name=vtkCommonComputationalGeometryPython-TestParametricFunctions&date=2014-09-15



vttkParametricRandomHills.cxx was recently changed and the associated test
image for TestParametricFunctions.py updated.



It seems that on these machines, the new valid image has not been
downloaded there are also other OpenGL errors, here is a summary:



Valid Image incorrect, test image - vtkTextMapper not working:

dash1win7.kitware Win32-vs11-OpenGL2

londinium.kitware   Arch-GCC-4.9-x86_64-opengl2



The above machines display this error:

ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58

vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1





Valid Image incorrect, test image - vtkTextMapper not working:

kargad.kitware  MacLion-OpenGL2



Valid Image incorrect, test image - vtkTextMapper not working.

On the test image: Torus, Fig-8 Klein, Mobius, Super Toroid, Dini,

Random Hills and part of Roman all blacked out.

curius.kitware  fedora-x64-gcc-master-debug-ATI-RadeonHD-5870-OpenGL2



For the above two machines the errors seem to be mainly:

ERROR: In
/home/kitware/Dashboards/MyTests/VTK/Nightly/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
line 1458

vtkXOpenGLRenderWindow (0x2cb96a0): Hardware does not support the number of
textures defined.

and

ERROR: In
/Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
line 58

vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
but not some texture unit has not been released: Id=1



Aside from the fact that the valid test images haven't been updated, is
there some issue with my code that I can fix?



Andrew



-- 
___________________________________________
Andrew J. P. Maclean

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

From andrew.amaclean at gmail.com  Tue Sep 16 15:53:48 2014
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Wed, 17 Sep 2014 05:53:48 +1000
Subject: [vtk-developers] OpenGL2 TestParametricFunctions Failures
In-Reply-To: <cbe0fa22ef08a3c2cb0689da3692a0ea@mail.gmail.com>
References: <CAHDsG9OYW-PbvRRfGq8OmJK=StWuMhef7W8+u-v-tK3=jJmSpQ@mail.gmail.com>
 <cbe0fa22ef08a3c2cb0689da3692a0ea@mail.gmail.com>
Message-ID: <CAHDsG9Ou3U1fJqihP=s1PudkAU0ohOWGmzPbuka4YEo3LiwCMg@mail.gmail.com>

Thankyou Ken, that's good to know.
On Sep 16, 2014 11:07 PM, "Ken Martin" <ken.martin at kitware.com> wrote:

> I think you are good Andrew. I?m pretty sure there is a leak in one of the
> texture resources in the OpenGL2 backend which may be part of some of the
> failures. I?ll take a look at that when I get back to dashboards. Curius
> was an old ATI Linux system running a driver that is not from ATI.  The
> driver is broken and we decided to not work around it and removed that
> dashboard.
>
>
>
> Thanks!
>
> Ken
>
>
>
> Ken Martin PhD
>
> Chairman & CFO
>
> Kitware Inc.
>
> 28 Corporate Drive
>
> Clifton Park NY 12065
>
> ken.martin at kitware.com
>
> 518 881-4901 (w)
>
> 518 371-4573 (f)
>
>
>
> 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.
>
>
>
> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
> Of *Andrew Maclean
> *Sent:* Monday, September 15, 2014 7:40 PM
> *To:* VTK Developers
> *Subject:* [vtk-developers] OpenGL2 TestParametricFunctions Failures
>
>
>
>
>
> I see that TestParametricFunctions.py consistently fails on all the
> OpenGL2 test machines:
>
>
> http://open.cdash.org/testSummary.php?project=11&name=vtkCommonComputationalGeometryPython-TestParametricFunctions&date=2014-09-15
>
>
>
> vttkParametricRandomHills.cxx was recently changed and the associated test
> image for TestParametricFunctions.py updated.
>
>
>
> It seems that on these machines, the new valid image has not been
> downloaded there are also other OpenGL errors, here is a summary:
>
>
>
> Valid Image incorrect, test image - vtkTextMapper not working:
>
> dash1win7.kitware Win32-vs11-OpenGL2
>
> londinium.kitware   Arch-GCC-4.9-x86_64-opengl2
>
>
>
> The above machines display this error:
>
> ERROR: In
> /Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
> line 58
>
> vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
> but not some texture unit has not been released: Id=1
>
>
>
>
>
> Valid Image incorrect, test image - vtkTextMapper not working:
>
> kargad.kitware  MacLion-OpenGL2
>
>
>
> Valid Image incorrect, test image - vtkTextMapper not working.
>
> On the test image: Torus, Fig-8 Klein, Mobius, Super Toroid, Dini,
>
> Random Hills and part of Roman all blacked out.
>
> curius.kitware  fedora-x64-gcc-master-debug-ATI-RadeonHD-5870-OpenGL2
>
>
>
> For the above two machines the errors seem to be mainly:
>
> ERROR: In
> /home/kitware/Dashboards/MyTests/VTK/Nightly/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
> line 1458
>
> vtkXOpenGLRenderWindow (0x2cb96a0): Hardware does not support the number
> of textures defined.
>
> and
>
> ERROR: In
> /Users/kitware/Dashboards/MyTests/VTK_SRC_OpenGL2/Rendering/OpenGL2/vtkOpenGLTextureUnitManager.cxx,
> line 58
>
> vtkOpenGLTextureUnitManager (0x7fe0791010d0): the texture unit is deleted
> but not some texture unit has not been released: Id=1
>
>
>
> Aside from the fact that the valid test images haven't been updated, is
> there some issue with my code that I can fix?
>
>
>
> Andrew
>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140917/b845f726/attachment-0002.html>

From berk.geveci at kitware.com  Tue Sep 16 16:03:04 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Tue, 16 Sep 2014 16:03:04 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
Message-ID: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>

Hi folks,

This is a reminder that on October 2nd, we are holding a bug tracker
hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
can. We will be hosting folks at our Clifton Park office as well as holding
a Google Hangout for those attending remotely. Here is the list of
attendees that I know so far:

- Bill Lorensen,
- Dave Cole,
- Sean McBride,
- Will Schroeder,
- me,
- Ben Boeckel,
- Chuck Atkins,
- Shawn Waldon,
- Marcus Hanwell,
- Dave DeMarle,
- Jamie Wright,
- Tim Meehan.

If you are not on this list and you are interested in attending, please let
me know.

Best,
-berk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140916/2143a7c0/attachment-0002.html>

From will.schroeder at kitware.com  Wed Sep 17 13:39:16 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Wed, 17 Sep 2014 13:39:16 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
Message-ID: <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>

There is lots of room at our offices. And especially those in nearby areas
like Cambridge, MA (e.g., Steve P. and Nicole) we'd love to have you come
visit.

W

On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Hi folks,
>
> This is a reminder that on October 2nd, we are holding a bug tracker
> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
> can. We will be hosting folks at our Clifton Park office as well as holding
> a Google Hangout for those attending remotely. Here is the list of
> attendees that I know so far:
>
> - Bill Lorensen,
> - Dave Cole,
> - Sean McBride,
> - Will Schroeder,
> - me,
> - Ben Boeckel,
> - Chuck Atkins,
> - Shawn Waldon,
> - Marcus Hanwell,
> - Dave DeMarle,
> - Jamie Wright,
> - Tim Meehan.
>
> If you are not on this list and you are interested in attending, please
> let me know.
>
> Best,
> -berk
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
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/20140917/cd2acdef/attachment-0002.html>

From david.gobbi at gmail.com  Wed Sep 17 13:59:07 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 17 Sep 2014 11:59:07 -0600
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
 <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>
Message-ID: <CANwS1=GdeFeXuJo+cvDV+pArMxW96fH3-g_n1z=8UAE5aYSJ3g@mail.gmail.com>

I can send some photons and be there as a telepresence.


On Wed, Sep 17, 2014 at 11:39 AM, Will Schroeder
<will.schroeder at kitware.com> wrote:
> There is lots of room at our offices. And especially those in nearby areas
> like Cambridge, MA (e.g., Steve P. and Nicole) we'd love to have you come
> visit.
>
> W
>
> On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>>
>> Hi folks,
>>
>> This is a reminder that on October 2nd, we are holding a bug tracker
>> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
>> can. We will be hosting folks at our Clifton Park office as well as holding
>> a Google Hangout for those attending remotely. Here is the list of attendees
>> that I know so far:
>>
>> - Bill Lorensen,
>> - Dave Cole,
>> - Sean McBride,
>> - Will Schroeder,
>> - me,
>> - Ben Boeckel,
>> - Chuck Atkins,
>> - Shawn Waldon,
>> - Marcus Hanwell,
>> - Dave DeMarle,
>> - Jamie Wright,
>> - Tim Meehan.
>>
>> If you are not on this list and you are interested in attending, please
>> let me know.
>>
>> Best,
>> -berk


From biddisco at cscs.ch  Wed Sep 17 14:07:15 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Wed, 17 Sep 2014 18:07:15 +0000
Subject: [vtk-developers] libc++ problem on OSX
Message-ID: <D03F9A72.6859C%biddisco@cscs.ch>

For compatibility with some other libraries, I tried compiling paraview on OSX using libc++ instead of libstdc++.
Everything is fine except some link errors coing from vtkCocoa? classes. I have never worked with these before, but see all the classes causing me trouble emanate from code which has an mm extension.

Looking at the make rules, I cannot see anything obviously wrong, but does anyone know of a reason why the vtkCocoa classes cause this trouble. Are they using a libstdc++ from the system (via some cocoa related link) which I can?t work around?

Thanks for any hints.

JB

Linking CXX shared library ../../../lib/libvtkRenderingOpenGL-pv4.2.dylib
Undefined symbols for architecture x86_64:
  "vtkObjectBase::PrintHeader(std::ostream&, vtkIndent)", referenced from:
      vtable for vtkCocoaRenderWindowInteractor in vtkCocoaRenderWindowInteractor.mm.o
      vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
  "vtkObjectBase::PrintTrailer(std::ostream&, vtkIndent)", referenced from:
      vtable for vtkCocoaRenderWindowInteractor in vtkCocoaRenderWindowInteractor.mm.o
      vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
  "vtkOpenGLRenderWindow::PrintSelf(std::ostream&, vtkIndent)", referenced from:
      vtkCocoaRenderWindow::PrintSelf(std::ostream&, vtkIndent) in vtkCocoaRenderWindow.mm.o
  "vtkRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)", referenced from:
      vtkCocoaRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent) in vtkCocoaRenderWindowInteractor.mm.o
  "std::string::c_str() const", referenced from:
      vtkCocoaRenderWindow::ReportCapabilities() in vtkCocoaRenderWindow.mm.o
  "std::string::length() const", referenced from:
      vtkCocoaRenderWindow::ReportCapabilities() in vtkCocoaRenderWindow.mm.o

From robert.maynard at kitware.com  Wed Sep 17 14:17:21 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 17 Sep 2014 14:17:21 -0400
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <D03F9A72.6859C%biddisco@cscs.ch>
References: <D03F9A72.6859C%biddisco@cscs.ch>
Message-ID: <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>

If my memory is correct CMake doesn't have explicit global objc or objc++
flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
 property on each mm file to be "-stdlib=libstdc++"

On Wed, Sep 17, 2014 at 2:07 PM, Biddiscombe, John A. <biddisco at cscs.ch>
wrote:

> For compatibility with some other libraries, I tried compiling paraview on
> OSX using libc++ instead of libstdc++.
> Everything is fine except some link errors coing from vtkCocoa? classes. I
> have never worked with these before, but see all the classes causing me
> trouble emanate from code which has an mm extension.
>
> Looking at the make rules, I cannot see anything obviously wrong, but does
> anyone know of a reason why the vtkCocoa classes cause this trouble. Are
> they using a libstdc++ from the system (via some cocoa related link) which
> I can?t work around?
>
> Thanks for any hints.
>
> JB
>
> Linking CXX shared library ../../../lib/libvtkRenderingOpenGL-pv4.2.dylib
> Undefined symbols for architecture x86_64:
>   "vtkObjectBase::PrintHeader(std::ostream&, vtkIndent)", referenced from:
>       vtable for vtkCocoaRenderWindowInteractor in
> vtkCocoaRenderWindowInteractor.mm.o
>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>   "vtkObjectBase::PrintTrailer(std::ostream&, vtkIndent)", referenced from:
>       vtable for vtkCocoaRenderWindowInteractor in
> vtkCocoaRenderWindowInteractor.mm.o
>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>   "vtkOpenGLRenderWindow::PrintSelf(std::ostream&, vtkIndent)", referenced
> from:
>       vtkCocoaRenderWindow::PrintSelf(std::ostream&, vtkIndent) in
> vtkCocoaRenderWindow.mm.o
>   "vtkRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)",
> referenced from:
>       vtkCocoaRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)
> in vtkCocoaRenderWindowInteractor.mm.o
>   "std::string::c_str() const", referenced from:
>       vtkCocoaRenderWindow::ReportCapabilities() in
> vtkCocoaRenderWindow.mm.o
>   "std::string::length() const", referenced from:
>       vtkCocoaRenderWindow::ReportCapabilities() in
> vtkCocoaRenderWindow.mm.o
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140917/b351edbd/attachment-0002.html>

From pieper at isomics.com  Wed Sep 17 14:27:39 2014
From: pieper at isomics.com (Steve Pieper)
Date: Wed, 17 Sep 2014 14:27:39 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CANwS1=GdeFeXuJo+cvDV+pArMxW96fH3-g_n1z=8UAE5aYSJ3g@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
 <CAEiDrtUTq-G=143tcdh1deg6S7oFenD0ahdToz+pZE9f4PkgyA@mail.gmail.com>
 <CANwS1=GdeFeXuJo+cvDV+pArMxW96fH3-g_n1z=8UAE5aYSJ3g@mail.gmail.com>
Message-ID: <CADkb7uNf7+ha6D5eTEt3mKramq0mYU8PmvrW+cVTxxu+7oHw1Q@mail.gmail.com>

I'm on vacation that day but you all have my thanks and best wishes!
On Sep 17, 2014 1:59 PM, "David Gobbi" <david.gobbi at gmail.com> wrote:

> I can send some photons and be there as a telepresence.
>
>
> On Wed, Sep 17, 2014 at 11:39 AM, Will Schroeder
> <will.schroeder at kitware.com> wrote:
> > There is lots of room at our offices. And especially those in nearby
> areas
> > like Cambridge, MA (e.g., Steve P. and Nicole) we'd love to have you come
> > visit.
> >
> > W
> >
> > On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
> > wrote:
> >>
> >> Hi folks,
> >>
> >> This is a reminder that on October 2nd, we are holding a bug tracker
> >> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as
> we
> >> can. We will be hosting folks at our Clifton Park office as well as
> holding
> >> a Google Hangout for those attending remotely. Here is the list of
> attendees
> >> that I know so far:
> >>
> >> - Bill Lorensen,
> >> - Dave Cole,
> >> - Sean McBride,
> >> - Will Schroeder,
> >> - me,
> >> - Ben Boeckel,
> >> - Chuck Atkins,
> >> - Shawn Waldon,
> >> - Marcus Hanwell,
> >> - Dave DeMarle,
> >> - Jamie Wright,
> >> - Tim Meehan.
> >>
> >> If you are not on this list and you are interested in attending, please
> >> let me know.
> >>
> >> Best,
> >> -berk
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140917/e3853105/attachment-0002.html>

From david.gobbi at gmail.com  Wed Sep 17 14:34:56 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 17 Sep 2014 12:34:56 -0600
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
References: <D03F9A72.6859C%biddisco@cscs.ch>
 <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
Message-ID: <CANwS1=E2XmBinosj4N9_dt_hX4hsWDWp1OHB-ZAE_BothYLbCg@mail.gmail.com>

VTK should be compiling just find with libc++ now, in fact I've done so
many times.  AFAIK it is an all-or-nothing thing: compile everything with
libc++, or compile everything with libstdc++.  Mixing the two will result in
link errors just like the ones that John reported.

 - David


On Wed, Sep 17, 2014 at 12:17 PM, Robert Maynard
<robert.maynard at kitware.com> wrote:
> If my memory is correct CMake doesn't have explicit global objc or objc++
> flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> property on each mm file to be "-stdlib=libstdc++"
>
> On Wed, Sep 17, 2014 at 2:07 PM, Biddiscombe, John A. <biddisco at cscs.ch>
> wrote:
>>
>> For compatibility with some other libraries, I tried compiling paraview on
>> OSX using libc++ instead of libstdc++.
>> Everything is fine except some link errors coing from vtkCocoa... classes. I
>> have never worked with these before, but see all the classes causing me
>> trouble emanate from code which has an mm extension.
>>
>> Looking at the make rules, I cannot see anything obviously wrong, but does
>> anyone know of a reason why the vtkCocoa classes cause this trouble. Are
>> they using a libstdc++ from the system (via some cocoa related link) which I
>> can't work around?
>>
>> Thanks for any hints.
>>
>> JB
>>
>> Linking CXX shared library ../../../lib/libvtkRenderingOpenGL-pv4.2.dylib
>> Undefined symbols for architecture x86_64:
>>   "vtkObjectBase::PrintHeader(std::ostream&, vtkIndent)", referenced from:
>>       vtable for vtkCocoaRenderWindowInteractor in
>> vtkCocoaRenderWindowInteractor.mm.o
>>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>>   "vtkObjectBase::PrintTrailer(std::ostream&, vtkIndent)", referenced
>> from:
>>       vtable for vtkCocoaRenderWindowInteractor in
>> vtkCocoaRenderWindowInteractor.mm.o
>>       vtable for vtkCocoaRenderWindow in vtkCocoaRenderWindow.mm.o
>>   "vtkOpenGLRenderWindow::PrintSelf(std::ostream&, vtkIndent)", referenced
>> from:
>>       vtkCocoaRenderWindow::PrintSelf(std::ostream&, vtkIndent) in
>> vtkCocoaRenderWindow.mm.o
>>   "vtkRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)",
>> referenced from:
>>       vtkCocoaRenderWindowInteractor::PrintSelf(std::ostream&, vtkIndent)
>> in vtkCocoaRenderWindowInteractor.mm.o
>>   "std::string::c_str() const", referenced from:
>>       vtkCocoaRenderWindow::ReportCapabilities() in
>> vtkCocoaRenderWindow.mm.o
>>   "std::string::length() const", referenced from:
>>       vtkCocoaRenderWindow::ReportCapabilities() in
>> vtkCocoaRenderWindow.mm.o


From sean at rogue-research.com  Wed Sep 17 14:38:08 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 17 Sep 2014 14:38:08 -0400
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
References: <D03F9A72.6859C%biddisco@cscs.ch>
 <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
Message-ID: <20140917183808.63627212@mail.rogue-research.com>

On Wed, 17 Sep 2014 14:17:21 -0400, Robert Maynard said:

>If my memory is correct CMake doesn't have explicit global objc or objc++
>flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> property on each mm file to be "-stdlib=libstdc++"

CMake doesn't (bug 4756) but VTK does: "VTK_REQUIRED_OBJCXX_FLAGS"

<http://public.kitware.com/Bug/view.php?id=4756>

VTK does work with libc++ and I have several dashboards that use it.  The link error does suggest however that some files are using libstdc++ and some others using libc++.  Maybe try adding -stdlib=libc++ to VTK_REQUIRED_OBJCXX_FLAGS also, though I don't believe I've had to do 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 robert.maynard at kitware.com  Wed Sep 17 14:52:45 2014
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 17 Sep 2014 14:52:45 -0400
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <20140917183808.63627212@mail.rogue-research.com>
References: <D03F9A72.6859C%biddisco@cscs.ch>
 <CAFzjYVoj=mAbz5R-B2mN73osSWTSr0t1dCTa+Ff6L2-bcf95xA@mail.gmail.com>
 <20140917183808.63627212@mail.rogue-research.com>
Message-ID: <CAFzjYVq7Kif8FMm2X6zYENa+WFP01YTrsrwcQRhpSKSYhaSpSw@mail.gmail.com>

I completely forgot about VTK_REQUIRED_OBJCXX_FLAGS.

On Wed, Sep 17, 2014 at 2:38 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Wed, 17 Sep 2014 14:17:21 -0400, Robert Maynard said:
>
> >If my memory is correct CMake doesn't have explicit global objc or objc++
> >flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> > property on each mm file to be "-stdlib=libstdc++"
>
> CMake doesn't (bug 4756) but VTK does: "VTK_REQUIRED_OBJCXX_FLAGS"
>
> <http://public.kitware.com/Bug/view.php?id=4756>
>
> VTK does work with libc++ and I have several dashboards that use it.  The
> link error does suggest however that some files are using libstdc++ and
> some others using libc++.  Maybe try adding -stdlib=libc++ to
> VTK_REQUIRED_OBJCXX_FLAGS also, though I don't believe I've had to do
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140917/888a4c57/attachment-0002.html>

From biddisco at cscs.ch  Wed Sep 17 15:15:03 2014
From: biddisco at cscs.ch (Biddiscombe, John A.)
Date: Wed, 17 Sep 2014 19:15:03 +0000
Subject: [vtk-developers] libc++ problem on OSX
In-Reply-To: <CAFzjYVq7Kif8FMm2X6zYENa+WFP01YTrsrwcQRhpSKSYhaSpSw@mail.gmail.com>
Message-ID: <D03FAA0A.685BD%biddisco@cscs.ch>

Thanks to all of you,

In my cache there was a VTK_REQUIRED_OBJCXX_FLAGS libstdc++ setting. I put that right and now I?m past that problem.

Yours

JB

From: Robert Maynard <robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>>
Date: Wednesday 17 September 2014 20:52
To: Sean McBride <sean at rogue-research.com<mailto:sean at rogue-research.com>>
Cc: cscs <biddisco at cscs.ch<mailto:biddisco at cscs.ch>>, VTK Developers <vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>>
Subject: Re: [vtk-developers] libc++ problem on OSX

I completely forgot about VTK_REQUIRED_OBJCXX_FLAGS.

On Wed, Sep 17, 2014 at 2:38 PM, Sean McBride <sean at rogue-research.com<mailto:sean at rogue-research.com>> wrote:
On Wed, 17 Sep 2014 14:17:21 -0400, Robert Maynard said:

>If my memory is correct CMake doesn't have explicit global objc or objc++
>flag variables. Instead what you can try todo is to set the  COMPILE_FLAGS
> property on each mm file to be "-stdlib=libstdc++"

CMake doesn't (bug 4756) but VTK does: "VTK_REQUIRED_OBJCXX_FLAGS"

<http://public.kitware.com/Bug/view.php?id=4756>

VTK does work with libc++ and I have several dashboards that use it.  The link error does suggest however that some files are using libstdc++ and some others using libc++.  Maybe try adding -stdlib=libc++ to VTK_REQUIRED_OBJCXX_FLAGS also, though I don't believe I've had to do that...

Cheers,

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




From berk.geveci at kitware.com  Thu Sep 18 11:10:01 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Thu, 18 Sep 2014 11:10:01 -0400
Subject: [vtk-developers] REMINDER: Bug tracker hack-a-ton
In-Reply-To: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
References: <CAE32kpWsYd_MTEko_L9=Rzap30CR=QdUKsZfvQH53L8SU9bMMg@mail.gmail.com>
Message-ID: <CAE32kpWK9KF=7SJv_etzJ+KSAi5wiNk3_Qfy95MzEWtJP50VwQ@mail.gmail.com>

Hi folks,

I just created a public Google event/hangout for our hack-a-ton:

https://plus.google.com/events/cd0s6so0ijo45dsulg8and8p5tg

Looking forward to seeing you there or in person at Kitware.

-berk

On Tue, Sep 16, 2014 at 4:03 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Hi folks,
>
> This is a reminder that on October 2nd, we are holding a bug tracker
> hack-a-ton, 9am-5pm. The goal is to clean up our bug tracker as best as we
> can. We will be hosting folks at our Clifton Park office as well as holding
> a Google Hangout for those attending remotely. Here is the list of
> attendees that I know so far:
>
> - Bill Lorensen,
> - Dave Cole,
> - Sean McBride,
> - Will Schroeder,
> - me,
> - Ben Boeckel,
> - Chuck Atkins,
> - Shawn Waldon,
> - Marcus Hanwell,
> - Dave DeMarle,
> - Jamie Wright,
> - Tim Meehan.
>
> If you are not on this list and you are interested in attending, please
> let me know.
>
> Best,
> -berk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140918/31754d1d/attachment-0002.html>

From rostislav.khlebnikov at kcl.ac.uk  Thu Sep 18 15:14:29 2014
From: rostislav.khlebnikov at kcl.ac.uk (Rostislav Khlebnikov)
Date: Thu, 18 Sep 2014 20:14:29 +0100
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
 <54171CC6.9030407@kcl.ac.uk>
 <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>
Message-ID: <541B2F15.8030500@kcl.ac.uk>

Hi,

the code is attached. As I said it's quite messy - just ask me if you 
can't figure out something. The functions I added start with small 
letters as opposed to the copy-pasted and modified from VTK which start 
with a capital letter.

Rostislav.


On 15/09/2014 19:28, Gerrick Bivins wrote:
>
> Yes. I would definitely be interested in seeing the code.
>
> Gerrick
>
> *From:*Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
> *Sent:* Monday, September 15, 2014 12:07 PM
> *To:* Gerrick Bivins; Berk Geveci
> *Cc:* VTK Developers
> *Subject:* Re: [vtk-developers] vtkCutter modification to use 
> vtkCellLocator
>
> Hi,
>
> well, basically, I feel that it is necessary to create a proper change 
> to use Gerrit workflow successfully. Unfortunately, I don't quite have 
> the time to do this properly for several reasons. One of them is that 
> I actually don't need this change - for my project I integrated the 
> CGAL-based cutting approach with AABB_tree which outperforms my VTK 
> test - for example for the same test with 500k triangles CGAL-based 
> cutting takes only 2ms. This will soon be integrated to MITK (in case 
> anyone is interested, the pull request can be found here: 
> https://github.com/MITK/MITK/pull/73). Making a proper VTK change 
> would involve quite a lot of effort. Given that vtkCutter is very 
> general and rejecting the octree nodes might be complex for arbitrary 
> implicit functions, it seems to require quite a lot of work to avoid 
> incorrect usage.
>
> I can clean up the code a bit and post it to the mailing list if you 
> are interested.
>
> All best,
>    Rostislav.
>
> On 15/09/2014 15:02, Gerrick Bivins wrote:
>
>     Hi Rostislav,
>
>     Did anything happen with this?
>
>     I would definitely be interested in this
>     capability/feature/improvement.
>
>     Gerrick
>
>     *From:*vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On
>     Behalf Of *Berk Geveci
>     *Sent:* Tuesday, August 12, 2014 11:44 AM
>     *To:* Rostislav Khlebnikov
>     *Cc:* VTK Developers
>     *Subject:* Re: [vtk-developers] vtkCutter modification to use
>     vtkCellLocator
>
>     Hi Rostislav,
>
>     This is great. Can you push the code to Gerrit
>     (http://review.source.kitware.com/)?
>
>     Best,
>
>     -berk
>
>     On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov
>     <rostislav.khlebnikov at kcl.ac.uk
>     <mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
>
>     Hi guys,
>
>     just thought that the VTK developers might be interested in the
>     test I made recently.
>
>     Bascially what I did is subclass the vtkCellLocator to implement
>     the visitor pattern. It allows to filter the octree nodes (e.g.
>     reject the octree nodes that are of no interest early) and for
>     leafs, to visit the cells of the polydata.
>     Then, I subclassed the vtkCutter to use this cell locator instead
>     of straight iteration over cells. Likely for very complex implicit
>     cutting functions this wouldnt be of any benefit. However, for
>     those which can test bboxes as being of interest or not, rejecting
>     whole subtrees, such as vtkPlane, it is very useful. I tested it
>     on a surface with 500k triangles and the cutter performance went
>     from 88ms per cut to 14ms.
>
>     The code I made is quite ugly due to limited extensibility of
>     vtkCutter, so I had to copy-paste the RequestData method and make
>     my changes instead of, say, overriding IterateCells method which
>     would just provide the cells to cut through.
>
>     But anyway, I was wondering if you guys are intersted in this kind
>     of functionality? Would you like me to send you the code?
>
>     All best,
>        Rostislav.
>
>     _______________________________________________
>     Powered by www.kitware.com <http://www.kitware.com>
>
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>     <http://www.kitware.com/opensource/opensource.html>
>
>     Follow this link to subscribe/unsubscribe:
>     http://public.kitware.com/mailman/listinfo/vtk-developers
>
>     ------------------------------------------------------------------------
>
>     This e-mail, including any attached files, may contain
>     confidential and privileged information for the sole use of the
>     intended recipient. Any review, use, distribution, or disclosure
>     by others is strictly prohibited. If you are not the intended
>     recipient (or authorized to receive information for the intended
>     recipient), please contact the sender by reply e-mail and delete
>     all copies of this message.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140918/8075622e/attachment-0002.html>
-------------- next part --------------
#include <functional>
#include <queue>
#include <chrono>

#include <vtkSphereSource.h>

#include <vtkPolyData.h>
#include <vtkPolyDataReader.h>
#include <vtkCutter.h>
#include <vtkPlane.h>
#include <vtkIdList.h>
#include <vtkCell.h>

#include <vtkCellLocator.h>
#include <vtkCutter.h>
#include <vtkBox.h>
#include <vtkInformation.h>
#include <vtkInformationVector.h>
#include <vtkRectilinearGrid.h>
#include <vtkDoubleArray.h>
#include <vtkCellArray.h>
#include <vtkPointData.h>
#include <vtkCellData.h>
#include <vtkIncrementalPointLocator.h>
#include <vtkSmartPointer.h>
#include <vtkPolygonBuilder.h>
#include <vtkXMLPolyDataWriter.h>
#include <vtkCleanPolyData.h>
#include <vtkQuad.h>

class vtkContourHelper
{
public:
    vtkContourHelper(vtkIncrementalPointLocator *locator,
        vtkCellArray *verts,
        vtkCellArray *lines,
        vtkCellArray* polys,
        vtkPointData *inPd,
        vtkCellData *inCd,
        vtkPointData* outPd,
        vtkCellData *outCd,
        int estimatedSize,
        bool outputTriangles);
    ~vtkContourHelper();
    void Contour(vtkCell* cell, double value, vtkDataArray *cellScalars, vtkIdType cellId);

private:
    vtkIncrementalPointLocator* Locator;
    vtkCellArray* Verts;
    vtkCellArray* Lines;
    vtkCellArray* Polys;
    vtkPointData* InPd;
    vtkCellData* InCd;
    vtkPointData* OutPd;
    vtkCellData* OutCd;
    vtkSmartPointer<vtkCellData> TriOutCd;

    vtkCellArray* Tris;
    vtkPolygonBuilder PolyBuilder;
    vtkIdList* Poly;
    bool GenerateTriangles;
};

#include "vtkIncrementalPointLocator.h"
#include "vtkCellArray.h"
#include "vtkPointData.h"
#include "vtkCellData.h"
#include "vtkPolygonBuilder.h"
#include "vtkIdList.h"
#include "vtkCell.h"
#include "vtkDataArray.h"

vtkContourHelper::vtkContourHelper(vtkIncrementalPointLocator *locator,
    vtkCellArray *verts,
    vtkCellArray *lines,
    vtkCellArray* polys,
    vtkPointData *inPd,
    vtkCellData *inCd,
    vtkPointData* outPd,
    vtkCellData *outCd,
    int estimatedSize,
    bool outputTriangles) :
    Locator(locator),
    Verts(verts),
    Lines(lines),
    Polys(polys),
    InPd(inPd),
    InCd(inCd),
    OutPd(outPd),
    OutCd(outCd),
    GenerateTriangles(outputTriangles)
{
    this->Tris = vtkCellArray::New();
    this->TriOutCd = vtkCellData::New();
    if (this->GenerateTriangles)
    {
        this->Tris->Allocate(estimatedSize, estimatedSize / 2);
        this->TriOutCd->Initialize();
    }
    this->Poly = vtkIdList::New();
}

vtkContourHelper::~vtkContourHelper()
{
    this->Tris->Delete();
    this->TriOutCd->Delete();
    this->Poly->FastDelete();
}

void vtkContourHelper::Contour(vtkCell* cell, double value, vtkDataArray *cellScalars, vtkIdType cellId)
{
    bool mergeTriangles = (!this->GenerateTriangles) && cell->GetCellDimension() == 3;
    vtkCellData* outCD;
    vtkCellArray* outPoly;
    if (mergeTriangles)
    {
        outPoly = this->Tris;
        outCD = this->TriOutCd;
    }
    else
    {
        outPoly = this->Polys;
        outCD = this->OutCd;
    }
    cell->Contour(value, cellScalars, this->Locator, this->Verts, this->Lines,
        outPoly, this->InPd, this->OutPd, this->InCd, cellId, outCD);
    if (mergeTriangles)
    {
        this->PolyBuilder.Reset();

        vtkIdType cellSize;
        vtkIdType* cellVerts;
        while (this->Tris->GetNextCell(cellSize, cellVerts))
        {
            if (cellSize == 3)
            {
                this->PolyBuilder.InsertTriangle(cellVerts);
            }
            else //for whatever reason, the cell contouring is already outputing polys
            {
                vtkIdType outCellId = this->Polys->InsertNextCell(cellSize, cellVerts);
                this->OutCd->CopyData(this->InCd, cellId, outCellId);
            }
        }

        this->PolyBuilder.GetPolygon(this->Poly);
        if (this->Poly->GetNumberOfIds() != 0)
        {
            vtkIdType outCellId = this->Polys->InsertNextCell(this->Poly);
            this->OutCd->CopyData(this->InCd, cellId, outCellId);
        }
    }
}

class CellLocatorVisitor : public vtkCellLocator {
public:
    vtkTypeMacro(CellLocatorVisitor, vtkCellLocator);

    static CellLocatorVisitor *New();

    int getBoundsByIndex(int idx, double bounds[6])
    {
        int nSubdiv = 1;
        int level = 0;
        int nNodes = 1;

        while (idx >= nNodes) {
            nSubdiv *= 2;
            nNodes += nSubdiv * nSubdiv * nSubdiv;
            level++;
        }

        int firstInLevel = nNodes - nSubdiv*nSubdiv*nSubdiv;

        double sizeWithinLevel[3];
        for (int i = 0; i < 3; ++i) {
            sizeWithinLevel[i] = (this->Bounds[2 * i + 1] - this->Bounds[2 * i]) / nSubdiv;
        }

        idx -= firstInLevel;

        for (int i = 0; i < 3; ++i) {
            bounds[2 * i] = this->Bounds[2 * i] + sizeWithinLevel[i] * (idx % nSubdiv);
            bounds[2 * i + 1] = bounds[2 * i] + sizeWithinLevel[i];
            idx /= nSubdiv;
        }
        return level;
    }

    void getChildren(int idx, int children[8])
    {
        int nSubdiv = 1;
        int level = 0;
        int nNodes = 1;

        while (idx >= nNodes) {
            nSubdiv *= 2;
            nNodes += nSubdiv * nSubdiv * nSubdiv;
            level++;
        }

        int firstInParentLevel = nNodes - nSubdiv*nSubdiv*nSubdiv;

        idx -= firstInParentLevel;

        int firstChildIndex = nNodes;
        int nNodesInDirection = 2;
        for (int i = 0; i < 3; ++i) {
            firstChildIndex += (idx % (nSubdiv)) * nNodesInDirection;
            nNodesInDirection *= 2 * nSubdiv;
            idx /= (nSubdiv);
        }

        int outit = 0;
        for (int k = 0; k < 2; k++) {
            for (int j = 0; j < 2; j++) {
                for (int i = 0; i < 2; i++) {
                    children[outit++] = firstChildIndex + i + 2 * nSubdiv * j + 4 * nSubdiv * nSubdiv * k;
                }
            }
        }
    }
    void visitCells(std::function<bool(double[6])> cellChecker, std::function<void(vtkCell*, int)> visitor)
    {
        this->BuildLocatorIfNeeded();
        this->ClearCellHasBeenVisited();

        std::queue<int> octantsToVisit;

        octantsToVisit.push(0);

        while (!octantsToVisit.empty()) {
            int currentOctant = octantsToVisit.front();
            octantsToVisit.pop();

            // Get the octant bounds 
            double bounds[6];
            int level = getBoundsByIndex(currentOctant, bounds);

            if (cellChecker(bounds)) {
                vtkIdList* cellsIds = this->Tree[currentOctant];
                if (level == this->Level) {
                    // Leaf
                    if (!cellsIds) {
                        // Empty leaf
                        continue;
                    }

                    for (int i = 0; i < cellsIds->GetNumberOfIds(); ++i) {
                        int cellId = cellsIds->GetId(i);
                        if (!this->CellHasBeenVisited[cellId]) {
                            visitor(this->DataSet->GetCell(cellId), cellId);
                            this->CellHasBeenVisited[cellId] = 1;
                        }
                    }
                }
                else {
                    vtkIdList* cellsIds = this->Tree[currentOctant];
                    if (cellsIds != (void*)1) {
                        continue;
                    }

                    int children[8];

                    // Get children
                    getChildren(currentOctant, children);
                    for (int i = 0; i < 8; ++i) {
                        octantsToVisit.push(children[i]);
                    }
                }
            }
        }
    }
};

CellLocatorVisitor* CellLocatorVisitor::New()
{
    return new CellLocatorVisitor;
}

class CutterWithLocator : public vtkCutter {
public:
    vtkTypeMacro(CutterWithLocator, vtkCutter);

    static CutterWithLocator *New();

    void setLocator(CellLocatorVisitor* locator)
    {
        _locator = locator;
    }

    int RequestData(
        vtkInformation *request,
        vtkInformationVector **inputVector,
        vtkInformationVector *outputVector)
    {
        // get the info objects
        vtkInformation *inInfo = inputVector[0]->GetInformationObject(0);
        vtkInformation *outInfo = outputVector->GetInformationObject(0);

        // get the input and output
        vtkDataSet *input = vtkDataSet::SafeDownCast(
            inInfo->Get(vtkDataObject::DATA_OBJECT()));
        vtkPolyData *output = vtkPolyData::SafeDownCast(
            outInfo->Get(vtkDataObject::DATA_OBJECT()));

        vtkDebugMacro(<< "Executing cutter");
        if (!this->CutFunction)
        {
            vtkErrorMacro("No cut function specified");
            return 0;
        }

        if (!input)
        {
            // this could be a table in a multiblock structure, i.e. no cut!
            return 0;
        }

        if (input->GetNumberOfPoints() < 1 || this->GetNumberOfContours() < 1)
        {
            return 1;
        }

        if ((input->GetDataObjectType() == VTK_STRUCTURED_POINTS ||
            input->GetDataObjectType() == VTK_IMAGE_DATA) &&
            input->GetCell(0) && input->GetCell(0)->GetCellDimension() >= 3)
        {
            this->StructuredPointsCutter(input, output, request, inputVector, outputVector);
        }
        else if (input->GetDataObjectType() == VTK_STRUCTURED_GRID &&
            input->GetCell(0) &&
            input->GetCell(0)->GetCellDimension() >= 3)
        {
            this->StructuredGridCutter(input, output);
        }
        else if (input->GetDataObjectType() == VTK_RECTILINEAR_GRID &&
            static_cast<vtkRectilinearGrid *>(input)->GetDataDimension() == 3)
        {
            this->RectilinearGridCutter(input, output);
        }
        else if (input->GetDataObjectType() == VTK_UNSTRUCTURED_GRID)
        {
            vtkDebugMacro(<< "Executing Unstructured Grid Cutter");
            this->UnstructuredGridCutter(input, output);
        }
        else
        {
            vtkDebugMacro(<< "Executing DataSet Cutter");
            this->DataSetVisitorCutter(input, output);
        }

        return 1;
    }

    //----------------------------------------------------------------------------
    void DataSetVisitorCutter(vtkDataSet *input, vtkPolyData *output)
    {
        vtkIdType i;
        int iter;
        vtkPoints *cellPts;
        vtkDoubleArray *cellScalars;
        vtkCellArray *newVerts, *newLines, *newPolys;
        vtkPoints *newPoints;
        vtkDoubleArray *cutScalars;
        double value, s;
        vtkIdType estimatedSize, numCells = input->GetNumberOfCells();
        vtkIdType numPts = input->GetNumberOfPoints();
        int numCellPts;
        vtkPointData *inPD, *outPD;
        vtkCellData *inCD = input->GetCellData(), *outCD = output->GetCellData();
        vtkIdList *cellIds;
        int numContours = this->ContourValues->GetNumberOfContours();
        int abortExecute = 0;

        cellScalars = vtkDoubleArray::New();

        // Create objects to hold output of contour operation
        //
        estimatedSize = static_cast<vtkIdType>(
            pow(static_cast<double>(numCells), .75)) * numContours;
        estimatedSize = estimatedSize / 1024 * 1024; //multiple of 1024
        if (estimatedSize < 1024)
        {
            estimatedSize = 1024;
        }

        newPoints = vtkPoints::New();
        // set precision for the points in the output
        if (this->OutputPointsPrecision == vtkAlgorithm::DEFAULT_PRECISION)
        {
            vtkPointSet *inputPointSet = vtkPointSet::SafeDownCast(input);
            if (inputPointSet)
            {
                newPoints->SetDataType(inputPointSet->GetPoints()->GetDataType());
            }
            else
            {
                newPoints->SetDataType(VTK_FLOAT);
            }
        }
        else if (this->OutputPointsPrecision == vtkAlgorithm::SINGLE_PRECISION)
        {
            newPoints->SetDataType(VTK_FLOAT);
        }
        else if (this->OutputPointsPrecision == vtkAlgorithm::DOUBLE_PRECISION)
        {
            newPoints->SetDataType(VTK_DOUBLE);
        }
        newPoints->Allocate(estimatedSize, estimatedSize / 2);
        newVerts = vtkCellArray::New();
        newVerts->Allocate(estimatedSize, estimatedSize / 2);
        newLines = vtkCellArray::New();
        newLines->Allocate(estimatedSize, estimatedSize / 2);
        newPolys = vtkCellArray::New();
        newPolys->Allocate(estimatedSize, estimatedSize / 2);
        cutScalars = vtkDoubleArray::New();
        cutScalars->SetNumberOfTuples(numPts);

        // Interpolate data along edge. If generating cut scalars, do necessary setup
        if (this->GenerateCutScalars)
        {
            inPD = vtkPointData::New();
            inPD->ShallowCopy(input->GetPointData());//copies original attributes
            inPD->SetScalars(cutScalars);
        }
        else
        {
            inPD = input->GetPointData();
        }
        outPD = output->GetPointData();
        outPD->InterpolateAllocate(inPD, estimatedSize, estimatedSize / 2);
        outCD->CopyAllocate(inCD, estimatedSize, estimatedSize / 2);

        // locator used to merge potentially duplicate points
        if (this->Locator == NULL)
        {
            this->CreateDefaultLocator();
        }
        this->Locator->InitPointInsertion(newPoints, input->GetBounds());

        // Loop over all points evaluating scalar function at each point
        //
        for (i = 0; i < numPts; i++)
        {
            s = this->CutFunction->FunctionValue(input->GetPoint(i));
            cutScalars->SetComponent(i, 0, s);
        }

        // Compute some information for progress methods
        //
        vtkIdType numCuts = numContours*numCells;
        vtkIdType progressInterval = numCuts / 20 + 1;
        int cut = 0;

        vtkContourHelper helper(this->Locator, newVerts, newLines, newPolys, inPD, inCD, outPD, outCD, estimatedSize, this->GenerateTriangles != 0);
        if (true || this->SortBy == VTK_SORT_BY_CELL)
        {
            // Loop over all contour values.  Then for each contour value,
            // loop over all cells.
            //
            // This is going to have a problem if the input has 2D and 3D cells.
            // I am fixing a bug where cell data is scrambled becauses with
            // vtkPolyData output, verts and lines have lower cell ids than triangles.
            for (iter = 0; iter < numContours && !abortExecute; iter++)
            {
                _locator->visitCells(
                    [&](double bounds[6]) {
                    double sign = this->CutFunction->EvaluateFunction(bounds[0], bounds[2], bounds[4]);

                    bool oneSide = true;
                    for (int i = 0; i < 2 && oneSide; ++i) {
                        for (int j = 2; j < 4 && oneSide; ++j) {
                            for (int k = 4; k < 6; ++k) {
                                double sign2 = this->CutFunction->EvaluateFunction(bounds[i], bounds[j], bounds[k]);
                                if (sign * sign2 <= 0) {
                                    oneSide = false;
                                    break;
                                }
                            }
                        }
                    }

                    return !oneSide;
                },




                    [&](vtkCell* cell, int cellId) {
                    if (!(++cut % progressInterval))
                    {
                        vtkDebugMacro(<< "Cutting #" << cut);
                        this->UpdateProgress(static_cast<double>(cut) / numCuts);
                        abortExecute = this->GetAbortExecute();
                    }

                    cellPts = cell->GetPoints();
                    cellIds = cell->GetPointIds();

                    numCellPts = cellPts->GetNumberOfPoints();
                    cellScalars->SetNumberOfTuples(numCellPts);
                    for (i = 0; i < numCellPts; i++)
                    {
                        s = cutScalars->GetComponent(cellIds->GetId(i), 0);
                        cellScalars->SetTuple(i, &s);
                    }

                    value = this->ContourValues->GetValue(iter);

                    helper.Contour(cell, value, cellScalars, cellId);
                });
            } // for all contour values
        } // sort by cell

        //         else // VTK_SORT_BY_VALUE:
        //         {
        //             // Three passes over the cells to process lower dimensional cells first.
        //             // For poly data output cells need to be added in the order:
        //             // verts, lines and then polys, or cell data gets mixed up.
        //             // A better solution is to have an unstructured grid output.
        //             // I create a table that maps cell type to cell dimensionality,
        //             // because I need a fast way to get cell dimensionality.
        //             // This assumes GetCell is slow and GetCellType is fast.
        //             // I do not like hard coding a list of cell types here,
        //             // but I do not want to add GetCellDimension(vtkIdType cellId)
        //             // to the vtkDataSet API.  Since I anticipate that the output
        //             // will change to vtkUnstructuredGrid.  This temporary solution
        //             // is acceptable.
        //             //
        //             int cellType;
        //             unsigned char cellTypeDimensions[VTK_NUMBER_OF_CELL_TYPES];
        //             vtkCutter::GetCellTypeDimensions(cellTypeDimensions);
        //             int dimensionality;
        //             // We skip 0d cells (points), because they cannot be cut (generate no data).
        //             for (dimensionality = 1; dimensionality <= 3; ++dimensionality)
        //             {
        //                 // Loop over all cells; get scalar values for all cell points
        //                 // and process each cell.
        //                 //
        //                 for (cellId = 0; cellId < numCells && !abortExecute; cellId++)
        //                 {
        //                     // I assume that "GetCellType" is fast.
        //                     cellType = input->GetCellType(cellId);
        //                     if (cellType >= VTK_NUMBER_OF_CELL_TYPES)
        //                     { // Protect against new cell types added.
        //                         vtkErrorMacro("Unknown cell type " << cellType);
        //                         continue;
        //                     }
        //                     if (cellTypeDimensions[cellType] != dimensionality)
        //                     {
        //                         continue;
        //                     }
        //                     input->GetCell(cellId, cell);
        //                     cellPts = cell->GetPoints();
        //                     cellIds = cell->GetPointIds();
        // 
        //                     numCellPts = cellPts->GetNumberOfPoints();
        //                     cellScalars->SetNumberOfTuples(numCellPts);
        //                     for (i = 0; i < numCellPts; i++)
        //                     {
        //                         s = cutScalars->GetComponent(cellIds->GetId(i), 0);
        //                         cellScalars->SetTuple(i, &s);
        //                     }
        // 
        //                     // Loop over all contour values.
        //                     for (iter = 0; iter < numContours && !abortExecute; iter++)
        //                     {
        //                         if (dimensionality == 3 && !(++cut % progressInterval))
        //                         {
        //                             vtkDebugMacro(<< "Cutting #" << cut);
        //                             this->UpdateProgress(static_cast<double>(cut) / numCuts);
        //                             abortExecute = this->GetAbortExecute();
        //                         }
        //                         value = this->ContourValues->GetValue(iter);
        //                         helper.Contour(cell, value, cellScalars, cellId);
        //                     } // for all contour values
        //                 } // for all cells
        //             } // for all dimensions.
        //         } // sort by value

        // Update ourselves.  Because we don't know upfront how many verts, lines,
        // polys we've created, take care to reclaim memory.
        //
        cellScalars->Delete();
        cutScalars->Delete();

        if (this->GenerateCutScalars)
        {
            inPD->Delete();
        }

        output->SetPoints(newPoints);
        newPoints->Delete();

        if (newVerts->GetNumberOfCells())
        {
            output->SetVerts(newVerts);
        }
        newVerts->Delete();

        if (newLines->GetNumberOfCells())
        {
            output->SetLines(newLines);
        }
        newLines->Delete();

        if (newPolys->GetNumberOfCells())
        {
            output->SetPolys(newPolys);
        }
        newPolys->Delete();

        this->Locator->Initialize();//release any extra memory
        output->Squeeze();
    }

    CellLocatorVisitor* _locator;
};

CutterWithLocator* CutterWithLocator::New()
{
    return new CutterWithLocator;
}

int main()
{
    auto sphereSource = vtkSmartPointer<vtkSphereSource>::New();
    sphereSource->SetPhiResolution(300);
    sphereSource->SetThetaResolution(500);
    sphereSource->Update();

    auto plane = vtkSmartPointer<vtkPlane>::New();
    plane->SetOrigin(0.2, 0.1, -0.1);

    vtkCutter* cutter = vtkCutter::New();
    cutter->SetCutFunction(plane);
    cutter->SetInputData(sphereSource->GetOutput());
    cutter->GenerateCutScalarsOff();

    int nIter = 100;

    auto start = std::chrono::high_resolution_clock::now();

    for (int i = 0; i < nIter; ++i) {
        cutter->Modified();
        cutter->Update();
    }

    auto end = std::chrono::high_resolution_clock::now();
    auto dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);

    std::cout << "Normal vtkCutter " << dur.count() / (float)nIter << "ms, " << cutter->GetOutput()->GetNumberOfCells() << " cells\n";

    CellLocatorVisitor* locator = CellLocatorVisitor::New();
    locator->SetDataSet(sphereSource->GetOutput());
    locator->BuildLocator();

    CutterWithLocator* cutter2 = CutterWithLocator::New();
    cutter2->setLocator(locator);
    cutter2->SetCutFunction(plane);
    cutter2->SetInputData(sphereSource->GetOutput());
    cutter2->GenerateCutScalarsOff();

    start = std::chrono::high_resolution_clock::now();

    for (int i = 0; i < nIter; ++i) {
        cutter2->Modified();
        cutter2->Update();
    }

    end = std::chrono::high_resolution_clock::now();
    dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);

    std::cout << "'New' cutter " << dur.count() / (float)nIter << "ms, " << cutter2->GetOutput()->GetNumberOfCells() << " cells\n";

    return EXIT_SUCCESS;
}

From josp.jorge at gmail.com  Fri Sep 19 06:40:57 2014
From: josp.jorge at gmail.com (Jorge Perez)
Date: Fri, 19 Sep 2014 12:40:57 +0200
Subject: [vtk-developers] Wrong/Strange result from
	vtkImplicitPolyDataDistance + vtkSampleFunction
Message-ID: <CAM2LniH0TkH4_5sNGisHxp4z8U28=v2RU+RALD+ad819=qdG4A@mail.gmail.com>

http://vtk.org/Bug/view.php?id=15003

Attached is a test code (Bug_ImplicitPolyDataDistance_01.tcl) to reproduce
a bug with a combination of vtkImplicitPolyDataDistance + vtkSampleFunction.

In this test a triangle mesh of only one connected component is set as
input to vtkImplicitPolyDataDistance then an implicit function is sampled
with vtkSampleFunction. The result is contoured with vtkImageMarchingCubes
and the vtkPolyData resulting from this last step shows more than one
connected component. The original component is reconstructed well but other
wrong components appear.

Attached is also the snapshot of the result.

The input mesh fix_mesh.vtk used in the test can be downloaded from
https://www.dropbox.com/s/x3iwjvyl56sxvs3/fix_mesh.vtk?dl=0

The test has been executed on release 6.1.

Any suggestion about how to fix that? Could it be due to wrong in the test
code?

best regards,

Jorge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bug_ImplicitPolyDataDistance_01.tcl
Type: application/x-tcl
Size: 1076 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0002.tcl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_mesh.png
Type: image/png
Size: 61349 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_mesh_contour.png
Type: image/png
Size: 57224 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140919/ddab61aa/attachment-0005.png>

From Gerrick.Bivins at halliburton.com  Fri Sep 19 07:30:16 2014
From: Gerrick.Bivins at halliburton.com (Gerrick Bivins)
Date: Fri, 19 Sep 2014 11:30:16 +0000
Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator
In-Reply-To: <541B2F15.8030500@kcl.ac.uk>
References: <53E66DFC.201@kcl.ac.uk>
 <CAE32kpV1wWzduUJF==_RtAYqtJFhagDzMN+R0JcGGBQ989b5Sw@mail.gmail.com>
 <B0794D08412B1444B729850159888A9613C2897B@NP1EXMB026.corp.halliburton.com>
 <54171CC6.9030407@kcl.ac.uk>
 <B0794D08412B1444B729850159888A9613C28BDB@NP1EXMB026.corp.halliburton.com>
 <541B2F15.8030500@kcl.ac.uk>
Message-ID: <B0794D08412B1444B729850159888A9613C2B7CF@NP1EXMB026.corp.halliburton.com>

Thanks!
This is great! Hopefully someone can look at it and make the
modifications to get it checked in.

Gerrick

From: Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
Sent: Thursday, September 18, 2014 2:14 PM
To: Gerrick Bivins; Berk Geveci
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi,

the code is attached. As I said it's quite messy - just ask me if you can't figure out something. The functions I added start with small letters as opposed to the copy-pasted and modified from VTK which start with a capital letter.

Rostislav.

On 15/09/2014 19:28, Gerrick Bivins wrote:
Yes. I would definitely be interested in seeing the code.
Gerrick

From: Rostislav Khlebnikov [mailto:rostislav.khlebnikov at kcl.ac.uk]
Sent: Monday, September 15, 2014 12:07 PM
To: Gerrick Bivins; Berk Geveci
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi,

well, basically, I feel that it is necessary to create a proper change to use Gerrit workflow successfully. Unfortunately, I don't quite have the time to do this properly for several reasons. One of them is that I actually don't need this change - for my project I integrated the CGAL-based cutting approach with AABB_tree which outperforms my VTK test - for example for the same test with 500k triangles CGAL-based cutting takes only 2ms. This will soon be integrated to MITK (in case anyone is interested, the pull request can be found here: https://github.com/MITK/MITK/pull/73). Making a proper VTK change would involve quite a lot of effort. Given that vtkCutter is very general and rejecting the octree nodes might be complex for arbitrary implicit functions, it seems to require quite a lot of work to avoid incorrect usage.

I can clean up the code a bit and post it to the mailing list if you are interested.

All best,
   Rostislav.


On 15/09/2014 15:02, Gerrick Bivins wrote:
Hi Rostislav,
Did anything happen with this?
I would definitely be interested in this capability/feature/improvement.

Gerrick

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Tuesday, August 12, 2014 11:44 AM
To: Rostislav Khlebnikov
Cc: VTK Developers
Subject: Re: [vtk-developers] vtkCutter modification to use vtkCellLocator

Hi Rostislav,

This is great. Can you push the code to Gerrit (http://review.source.kitware.com/)?

Best,
-berk


On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov <rostislav.khlebnikov at kcl.ac.uk<mailto:rostislav.khlebnikov at kcl.ac.uk>> wrote:
Hi guys,

just thought that the VTK developers might be interested in the test I made recently.

Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata.
Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms.

The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through.

But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code?

All best,
   Rostislav.

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

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

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

________________________________
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.


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

From david.gobbi at gmail.com  Mon Sep 22 14:22:30 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 22 Sep 2014 12:22:30 -0600
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
Message-ID: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>

Hi All,

This is a question about streaming in an imaging pipeline.  Sometimes
I want to stream just part of whole extent through the pipeline, but
even more often, I want to pull through the whole extent even if a
downstream request is for just a single slice.

Is there a trivial filter in VTK that, regardless of the UpdateExtent
requested, will always request the WholeExtent from upstream?
I say "trivial" because it would indeed be a trivial filter to write.
Has anyone else ever written or used such a filter?

Basically, I'm looking for an easy way to turn streaming off at
any point in my pipeline, either by inserting a "non-streaming filter"
or by telling an existing filter not to stream.

 - David


From david.gobbi at gmail.com  Tue Sep 23 12:12:02 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 23 Sep 2014 10:12:02 -0600
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
In-Reply-To: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
References: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
Message-ID: <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>

Trying again:

Is there a flag that the user can set on a vtkAlgorithm to force it to
always request the whole extent from its input?

I'm guessing the answer is "no" because I don't see any code in
vtkStreamingDemandDrivenPipeline.cxx that would support such a
feature, but I'm wondering if I can get confirmation from other
developers who are familiar with the pipeline.

 - David


On Mon, Sep 22, 2014 at 12:22 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi All,
>
> This is a question about streaming in an imaging pipeline.  Sometimes
> I want to stream just part of whole extent through the pipeline, but
> even more often, I want to pull through the whole extent even if a
> downstream request is for just a single slice.
>
> Is there a trivial filter in VTK that, regardless of the UpdateExtent
> requested, will always request the WholeExtent from upstream?
> I say "trivial" because it would indeed be a trivial filter to write.
> Has anyone else ever written or used such a filter?
>
> Basically, I'm looking for an easy way to turn streaming off at
> any point in my pipeline, either by inserting a "non-streaming filter"
> or by telling an existing filter not to stream.
>
>  - David


From matt.mccormick at kitware.com  Wed Sep 24 17:22:02 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 24 Sep 2014 17:22:02 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
 <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
 <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>
Message-ID: <CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>

Hi Marcus,

Thanks again for your feedback and information here.


Another note for posterity: I am finding that a project that does

find_package( ITK REQUIRED
  COMPONENTS
   [...]
  ITKVtkGlue
)

find_package( VTK NO_MODULE
  REQUIRED
  COMPONENTS
    [...]
)

the "NO_MODULE" option is required to avoid missing includes.


In summary, to avoid issues:


1) Use COMPONENTS for all calls to find_package( VTK

2) Pass NO_MODULE to find_package( VTK


Thanks,
Matt


On Tue, Sep 9, 2014 at 2:42 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Matt,
>
> Probably commit f915a54, made after I proposed a different change that
> was ultimately rejected. I didn't realize you were on 6.0 - a lot has
> changed since then. I am not entirely certain what your use case is
> for mixed - reallyt non one should make mixed calls and you should
> prefer to always specify COMPONENTS. It would be safer to at least
> spit out a warning, I can look at adding something to warn.
>
> Marcus
>
> On Tue, Sep 9, 2014 at 2:37 PM, Matt McCormick
> <matt.mccormick at kitware.com> wrote:
>> Hi Marcus,
>>
>> Thanks for taking a look at this. I reproduced your output with VTK
>> master for build a build tree and install tree.  However, I get
>>
>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
>> -- LIBS: vtkCommonCore
>> -- LIBS: vtkCommonMath
>> -- LIBS: vtkChartsCore
>> -- LIBS: vtkChartsCore
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: /tmp/vtkcomponents/build
>>
>> for an installed VTK 6.0.
>>
>>
>> What was the fix and where it was made? We would like to have similar
>> behavior for ITK and other CMake projects that make use of components.
>>
>>
>> I hope that multiple calls, sometimes without specifying COMPONENTS,
>> will still work. If it does not work, CMake should complain
>> informatively that a non-COMPONENTS call cannot occur after a
>> COMPONENTS call.
>>
>> Thanks,
>> Matt
>>
>> On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> Pushing this a little further, to see if we can build executables in
>>> the same directory with multiple calls, the following worked for me
>>> locally,
>>>
>>> cmake_minimum_required(VERSION 3.0)
>>>
>>> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>> add_executable(testexe test.cxx)
>>> set_property(TARGET testexe APPEND
>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>> set_property(TARGET testexe APPEND
>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>> target_link_libraries(testexe ${VTK_LIBRARIES})
>>>
>>> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>> add_executable(testexe2 test2.cxx)
>>> set_property(TARGET testexe2 APPEND
>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>> set_property(TARGET testexe2 APPEND
>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>>>
>>> Producing the output,
>>>
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
>>> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
>>> -- LIBS: vtkCommonCore;vtksys
>>> -- DEFS:
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>
>>> So the definitions were empty, as you would hope, in the second call,
>>> the mains were very simple instantiating a vtkRenderWindow in the
>>> first which resulted in a vtkXOpenGLRenderWindow class being
>>> instantiated as the overrides kicked in for that target. Most projects
>>> I know of that make multiple calls tend to use directories for each
>>> target, and make the calls in sibling directories, but it looks like
>>> you should be able to call it multiple times in the same scope (on
>>> Linux with VTK master at least).
>>>
>>> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Adding you both to CC in case you aren't subscribed, it might also be
>>>> worth appending NO_MODULE to the calls to ensure find modules aren't
>>>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>>>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>>>> contains advice I added, but didn't specifically cover multiple calls.
>>>> Including the use file, or setting the DIRECTORY property will of
>>>> course cause issues if you are not using separate directory scopes for
>>>> each target.
>>>>
>>>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>>>> <marcus.hanwell at kitware.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Moving this discussion from
>>>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>>>> was saying I do not see precisely what you see, the repeated calls
>>>>> seem to work for me locally. I would not expect the call without
>>>>> COMPONENTS to work, and am not sure we should support calling with and
>>>>> without COMPONENTS.
>>>>>
>>>>> I have a minimal CMake script,
>>>>>
>>>>> cmake_minimum_required(VERSION 3.0)
>>>>>
>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK COMPONENTS vtkCommonCore)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK COMPONENTS vtkCommonMath)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> find_package(VTK)
>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>
>>>>> This results in the output,
>>>>>
>>>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>>>> -- The C compiler identification is GNU 4.9.1
>>>>> -- The CXX compiler identification is GNU 4.9.1
>>>>> -- Check for working C compiler: /usr/bin/cc
>>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>>> -- Detecting C compiler ABI info
>>>>> -- Detecting C compiler ABI info - done
>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>> -- Detecting CXX compiler ABI info
>>>>> -- Detecting CXX compiler ABI info - done
>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>> -- LIBS: vtkCommonCore;vtksys
>>>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>> -- Configuring done
>>>>> -- Generating done
>>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>>
>>>>> As far as I can see this gives the libraries one would expect, i.e.
>>>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>>>> final one is incorrect but I am not sure of the value in supporting
>>>>> mixed COMPONENTS and non-components versions of find_package.
>>>>>
>>>>> Let me know if there is something I am missing, is this possibly with
>>>>> an older version of VTK (I am testing with master).
>>>>>
>>>>> Marcus


From ken.martin at kitware.com  Thu Sep 25 11:27:43 2014
From: ken.martin at kitware.com (Ken Martin)
Date: Thu, 25 Sep 2014 11:27:43 -0400
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
Message-ID: <f8197e9197116fc1acfe8fd1b79548a7@mail.gmail.com>

Depending on various settings, phase of the moon etc, scalar colors
sometimes end up setting the ambient color and sometimes they set the
diffuse color of a vertex and sometimes they set both IIRC.  Sometimes
lighting is applied to the result and sometimes it isn?t.

The following snippet of code is what I am using for the OpenGL backend,
which is very close to that VTK currently does. Textured scalars coloring
is another beast. Hope that helps

  if ( we have scalar colors)
    {
    if (this->ScalarMaterialMode == VTK_MATERIALMODE_AMBIENT ||
          (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
actor->GetProperty()->GetAmbient() > actor->GetProperty()->GetDiffuse()))
      {
      FSSource = replace(FSSource,"//VTK::Color::Impl",
                                  "vec3 ambientColor = vertexColor.rgb;\n"
                                  "vec3 diffuseColor =
diffuseColorUniform.rgb;\n"
                                  "float opacity = vertexColor.a;");
      }
    else if (this->ScalarMaterialMode == VTK_MATERIALMODE_DIFFUSE ||
          (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
actor->GetProperty()->GetAmbient() <= actor->GetProperty()->GetDiffuse()))
      {
      FSSource = replace(FSSource,"//VTK::Color::Impl",
                                  "vec3 diffuseColor = vertexColor.rgb;\n"
                                  "vec3 ambientColor =
ambientColorUniform;\n"
                                  "float opacity = vertexColor.a;");
      }
    Else // I believe this case is something like
VTK_MATERIALMODE_AMBIENT_AND_DIFFUSE
      {
      FSSource = replace(FSSource,"//VTK::Color::Impl",
                                  "vec3 diffuseColor = vertexColor.rgb;\n"
                                  "vec3 ambientColor = vertexColor.rgb;\n"
                                  "float opacity = vertexColor.a;");
      }
    }
  Else // no scalars, just use material property colors
    {
    FSSource = replace(FSSource,"//VTK::Color::Impl",
                                "vec3 ambientColor =
ambientColorUniform;\n"
                                "vec3 diffuseColor =
diffuseColorUniform;\n"
                                "float opacity = opacityUniform;");
    }

Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
ken.martin at kitware.com
518 881-4901 (w)
518 371-4573 (f)

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.


-----Original Message-----
From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
David Gobbi
Sent: Thursday, September 4, 2014 7:33 PM
To: VTK Developers
Subject: [vtk-developers] Bug in scalar color mapping?

I've run into very odd behavior when I use Ambient and Diffuse
coefficients in combination with vtkDataSetMapper.  This is with VTK
master.

My property is set up like this, with AmbientColor="red" and
DiffuseColor="green".

  property->SetAmbient(0.51);
  property->SetDiffuse(0.49);
  property->SetAmbientColor(1.0, 0.0, 0.0);
  property->SetDiffuseColor(0.0, 1.0, 0.0);

My mapper, however, is set to MapScalars, so it should ignore the
AmbientColor and the DiffuseColor, and use the scalars instead:

  mapper->SetColorModeToMapScalars();
  mapper->SetLookupTable(table);
  mapper->UseLookupTableScalarRangeOn();

The lookup table is a simple greyscale lookup table, and my polydata has
scalars.  So I would expect my data to be rendered in greyscale.
But it's not, it's rendered mint green!  See the left side of the attached
image.

I tried a different scalar mapping pathway:

  mapper->InterpolateScalarsBeforeMappingOn();

The result was totally different, now it's greyscale with ambient
lighting, instead of the mix of ambient and diffuse lighting that I
requested (see right of attached image).


If I slightly modify the ambient and diffuse coefficients, the result is,
once again, completely unexpected:

  property->SetAmbient(0.49);  // was 0.51
  property->SetDiffuse(0.51);  // was 0.49

Now everything is red.  In the second attached image, the left shows
InterpolateScalarsBeforeMappingOff() and the right shows On().


Anyone know what is going on here?  Everything behaves just find if I set
either the Ambient or the Diffuse coefficient to zero.  But when I use
them together, VTK goes crazy.

 - David


From david.gobbi at gmail.com  Thu Sep 25 12:09:08 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 25 Sep 2014 10:09:08 -0600
Subject: [vtk-developers] Bug in scalar color mapping?
In-Reply-To: <f8197e9197116fc1acfe8fd1b79548a7@mail.gmail.com>
References: <CANwS1=E0a=LypndLhpm7Vbai8UsgnD9JfgMtr9xZ4yfDUk-WUQ@mail.gmail.com>
 <CANwS1=E54dLtSojSNKwCmWaPAFQrQUGGXJ76oV-SveLfmifTpg@mail.gmail.com>
 <f8197e9197116fc1acfe8fd1b79548a7@mail.gmail.com>
Message-ID: <CANwS1=FrNK1FhTEdJ0b+yjNtB3EDhpMLQ_2uMeuQT1FSoQfeCA@mail.gmail.com>

Thanks, Ken.  That makes it very clear.

Now I know we need backwards compatibility, so maybe I should bite
my tongue, but it would be nice if the code would _combine_ the property's
color with the scalar color, e.g.

     if (this->ScalarMaterialMode == VTK_MATERIALMODE_AMBIENT)
       {
       FSSource = replace(FSSource,"//VTK::Color::Impl",
         "vec3 ambientColor = vertexColor.rgb*ambientColorUniform.rbg;\n"
         "vec3 diffuseColor = diffuseColorUniform.rgb;\n"
         "float opacity = vertexColor.a*opacityUniform;");
       }

etcetera.  If the mode is VTK_MATERIALMODE_AMBIENT the scalars would
combine with the property's ambient color, if VTK_MATERIALMODE_DIFFUSE
the scalars would combine with the property's diffuse color, and if the mode is
AMBIENT_AND_DIFFUSE the scalar color would combine with both.  As for
DEFAULT, my preference would be for it to be same as AMBIENT_AND_DIFFUSE.

 - David


On Thu, Sep 25, 2014 at 9:27 AM, Ken Martin <ken.martin at kitware.com> wrote:
> Depending on various settings, phase of the moon etc, scalar colors
> sometimes end up setting the ambient color and sometimes they set the
> diffuse color of a vertex and sometimes they set both IIRC.  Sometimes
> lighting is applied to the result and sometimes it isn't.
>
> The following snippet of code is what I am using for the OpenGL backend,
> which is very close to that VTK currently does. Textured scalars coloring
> is another beast. Hope that helps
>
>   if ( we have scalar colors)
>     {
>     if (this->ScalarMaterialMode == VTK_MATERIALMODE_AMBIENT ||
>           (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
> actor->GetProperty()->GetAmbient() > actor->GetProperty()->GetDiffuse()))
>       {
>       FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                   "vec3 ambientColor = vertexColor.rgb;\n"
>                                   "vec3 diffuseColor =
> diffuseColorUniform.rgb;\n"
>                                   "float opacity = vertexColor.a;");
>       }
>     else if (this->ScalarMaterialMode == VTK_MATERIALMODE_DIFFUSE ||
>           (this->ScalarMaterialMode == VTK_MATERIALMODE_DEFAULT &&
> actor->GetProperty()->GetAmbient() <= actor->GetProperty()->GetDiffuse()))
>       {
>       FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                   "vec3 diffuseColor = vertexColor.rgb;\n"
>                                   "vec3 ambientColor =
> ambientColorUniform;\n"
>                                   "float opacity = vertexColor.a;");
>       }
>     Else // I believe this case is something like
> VTK_MATERIALMODE_AMBIENT_AND_DIFFUSE
>       {
>       FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                   "vec3 diffuseColor = vertexColor.rgb;\n"
>                                   "vec3 ambientColor = vertexColor.rgb;\n"
>                                   "float opacity = vertexColor.a;");
>       }
>     }
>   Else // no scalars, just use material property colors
>     {
>     FSSource = replace(FSSource,"//VTK::Color::Impl",
>                                 "vec3 ambientColor =
> ambientColorUniform;\n"
>                                 "vec3 diffuseColor =
> diffuseColorUniform;\n"
>                                 "float opacity = opacityUniform;");
>     }
>
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> ken.martin at kitware.com
> 518 881-4901 (w)
> 518 371-4573 (f)
>
> 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.
>
>
> -----Original Message-----
> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
> David Gobbi
> Sent: Thursday, September 4, 2014 7:33 PM
> To: VTK Developers
> Subject: [vtk-developers] Bug in scalar color mapping?
>
> I've run into very odd behavior when I use Ambient and Diffuse
> coefficients in combination with vtkDataSetMapper.  This is with VTK
> master.
>
> My property is set up like this, with AmbientColor="red" and
> DiffuseColor="green".
>
>   property->SetAmbient(0.51);
>   property->SetDiffuse(0.49);
>   property->SetAmbientColor(1.0, 0.0, 0.0);
>   property->SetDiffuseColor(0.0, 1.0, 0.0);
>
> My mapper, however, is set to MapScalars, so it should ignore the
> AmbientColor and the DiffuseColor, and use the scalars instead:
>
>   mapper->SetColorModeToMapScalars();
>   mapper->SetLookupTable(table);
>   mapper->UseLookupTableScalarRangeOn();
>
> The lookup table is a simple greyscale lookup table, and my polydata has
> scalars.  So I would expect my data to be rendered in greyscale.
> But it's not, it's rendered mint green!  See the left side of the attached
> image.
>
> I tried a different scalar mapping pathway:
>
>   mapper->InterpolateScalarsBeforeMappingOn();
>
> The result was totally different, now it's greyscale with ambient
> lighting, instead of the mix of ambient and diffuse lighting that I
> requested (see right of attached image).
>
>
> If I slightly modify the ambient and diffuse coefficients, the result is,
> once again, completely unexpected:
>
>   property->SetAmbient(0.49);  // was 0.51
>   property->SetDiffuse(0.51);  // was 0.49
>
> Now everything is red.  In the second attached image, the left shows
> InterpolateScalarsBeforeMappingOff() and the right shows On().
>
>
> Anyone know what is going on here?  Everything behaves just find if I set
> either the Ambient or the Diffuse coefficient to zero.  But when I use
> them together, VTK goes crazy.
>
>  - David


From matt.mccormick at kitware.com  Thu Sep 25 12:48:11 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 25 Sep 2014 12:48:11 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>
 <CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>
 <CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>
 <CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>
 <CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>
 <CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>
Message-ID: <CALzTN-SB1_iA9Q-4i75WfH=KR5L-4hvV5fs15ZiTJ4LQH7Udzg@mail.gmail.com>

Looking at FindITK.cmake and FindVTK.cmake, they appear to not
propagate COMPONENTS [1] [2].  I think we should consider removing
these altogether.  Any version of ITK or VTK from moderately recent
history will have a Config.cmake file.

Matt

[1] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindITK.cmake;h=c9d39eb981f6933d61fc6cb4e0e41f26baabdeab;hb=HEAD
[2] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindVTK.cmake;h=60f48dd4063f3e0eed0f733b923ae7a83b7c76fc;hb=HEAD

On Wed, Sep 24, 2014 at 5:22 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> Hi Marcus,
>
> Thanks again for your feedback and information here.
>
>
> Another note for posterity: I am finding that a project that does
>
> find_package( ITK REQUIRED
>   COMPONENTS
>    [...]
>   ITKVtkGlue
> )
>
> find_package( VTK NO_MODULE
>   REQUIRED
>   COMPONENTS
>     [...]
> )
>
> the "NO_MODULE" option is required to avoid missing includes.
>
>
> In summary, to avoid issues:
>
>
> 1) Use COMPONENTS for all calls to find_package( VTK
>
> 2) Pass NO_MODULE to find_package( VTK
>
>
> Thanks,
> Matt
>
>
> On Tue, Sep 9, 2014 at 2:42 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Matt,
>>
>> Probably commit f915a54, made after I proposed a different change that
>> was ultimately rejected. I didn't realize you were on 6.0 - a lot has
>> changed since then. I am not entirely certain what your use case is
>> for mixed - reallyt non one should make mixed calls and you should
>> prefer to always specify COMPONENTS. It would be safer to at least
>> spit out a warning, I can look at adding something to warn.
>>
>> Marcus
>>
>> On Tue, Sep 9, 2014 at 2:37 PM, Matt McCormick
>> <matt.mccormick at kitware.com> wrote:
>>> Hi Marcus,
>>>
>>> Thanks for taking a look at this. I reproduced your output with VTK
>>> master for build a build tree and install tree.  However, I get
>>>
>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkIOImage;vtkDICOMParser;vtkIOCore;/usr/lib64/libz.so;vtkmetaio;/usr/lib64/libjpeg.so;/usr/lib64/libpng.so;/usr/lib64/libtiff.so;vtkIOXMLParser;/usr/lib64/libexpat.so;vtkRenderingFreeType;/usr/lib64/libfreetype.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid
>>> -- LIBS: vtkCommonCore
>>> -- LIBS: vtkCommonMath
>>> -- LIBS: vtkChartsCore
>>> -- LIBS: vtkChartsCore
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: /tmp/vtkcomponents/build
>>>
>>> for an installed VTK 6.0.
>>>
>>>
>>> What was the fix and where it was made? We would like to have similar
>>> behavior for ITK and other CMake projects that make use of components.
>>>
>>>
>>> I hope that multiple calls, sometimes without specifying COMPONENTS,
>>> will still work. If it does not work, CMake should complain
>>> informatively that a non-COMPONENTS call cannot occur after a
>>> COMPONENTS call.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Tue, Sep 9, 2014 at 2:18 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> Pushing this a little further, to see if we can build executables in
>>>> the same directory with multiple calls, the following worked for me
>>>> locally,
>>>>
>>>> cmake_minimum_required(VERSION 3.0)
>>>>
>>>> find_package(VTK COMPONENTS vtkChartsCore vtkRenderingContextOpenGL NO_MODULE)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>>> add_executable(testexe test.cxx)
>>>> set_property(TARGET testexe APPEND
>>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>>> set_property(TARGET testexe APPEND
>>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>>> target_link_libraries(testexe ${VTK_LIBRARIES})
>>>>
>>>> find_package(VTK COMPONENTS vtkCommonCore NO_MODULE)
>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>> message(STATUS "DEFS: ${VTK_DEFINITIONS}")
>>>> add_executable(testexe2 test2.cxx)
>>>> set_property(TARGET testexe2 APPEND
>>>>   PROPERTY COMPILE_DEFINITIONS "${VTK_DEFINITIONS}")
>>>> set_property(TARGET testexe2 APPEND
>>>>   PROPERTY INCLUDE_DIRECTORIES ${VTK_INCLUDE_DIRS})
>>>> target_link_libraries(testexe2 ${VTK_LIBRARIES})
>>>>
>>>> Producing the output,
>>>>
>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl;vtkRenderingContextOpenGL;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;vtkjpeg;vtkpng;vtktiff
>>>> -- DEFS: vtkRenderingContext2D_AUTOINIT=1(vtkRenderingContextOpenGL);vtkRenderingCore_AUTOINIT=2(vtkRenderingFreeType,vtkRenderingOpenGL)
>>>> -- LIBS: vtkCommonCore;vtksys
>>>> -- DEFS:
>>>> -- Configuring done
>>>> -- Generating done
>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>
>>>> So the definitions were empty, as you would hope, in the second call,
>>>> the mains were very simple instantiating a vtkRenderWindow in the
>>>> first which resulted in a vtkXOpenGLRenderWindow class being
>>>> instantiated as the overrides kicked in for that target. Most projects
>>>> I know of that make multiple calls tend to use directories for each
>>>> target, and make the calls in sibling directories, but it looks like
>>>> you should be able to call it multiple times in the same scope (on
>>>> Linux with VTK master at least).
>>>>
>>>> On Tue, Sep 9, 2014 at 1:53 PM, Marcus D. Hanwell
>>>> <marcus.hanwell at kitware.com> wrote:
>>>>> Adding you both to CC in case you aren't subscribed, it might also be
>>>>> worth appending NO_MODULE to the calls to ensure find modules aren't
>>>>> used, i.e. find_package(VTK COMPONENTS vtkChartsCore NO_MODULE). The
>>>>> wiki page at http://www.vtk.org/Wiki/VTK/Build_System_Migration#Finding_and_Linking_to_VTK
>>>>> contains advice I added, but didn't specifically cover multiple calls.
>>>>> Including the use file, or setting the DIRECTORY property will of
>>>>> course cause issues if you are not using separate directory scopes for
>>>>> each target.
>>>>>
>>>>> On Tue, Sep 9, 2014 at 1:23 PM, Marcus D. Hanwell
>>>>> <marcus.hanwell at kitware.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Moving this discussion from
>>>>>> http://review.source.kitware.com/#/c/16703/ to the mailing list. As I
>>>>>> was saying I do not see precisely what you see, the repeated calls
>>>>>> seem to work for me locally. I would not expect the call without
>>>>>> COMPONENTS to work, and am not sure we should support calling with and
>>>>>> without COMPONENTS.
>>>>>>
>>>>>> I have a minimal CMake script,
>>>>>>
>>>>>> cmake_minimum_required(VERSION 3.0)
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkCommonCore)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkCommonMath)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK COMPONENTS vtkChartsCore)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> find_package(VTK)
>>>>>> message(STATUS "LIBS: ${VTK_LIBRARIES}")
>>>>>>
>>>>>> This results in the output,
>>>>>>
>>>>>> $ cmake -DVTK_DIR:PATH=/home/marcus/build/VTK .
>>>>>> -- The C compiler identification is GNU 4.9.1
>>>>>> -- The CXX compiler identification is GNU 4.9.1
>>>>>> -- Check for working C compiler: /usr/bin/cc
>>>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>>>> -- Detecting C compiler ABI info
>>>>>> -- Detecting C compiler ABI info - done
>>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>>> -- Detecting CXX compiler ABI info
>>>>>> -- Detecting CXX compiler ABI info - done
>>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>>> -- LIBS: vtkCommonCore;vtksys
>>>>>> -- LIBS: vtkCommonMath;vtkCommonCore;vtksys
>>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>>> -- LIBS: vtkChartsCore;vtkCommonColor;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkInfovisCore;vtkFiltersExtraction;vtkCommonExecutionModel;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkImagingFourier;vtkImagingCore;vtkalglib;vtkRenderingContext2D;vtkRenderingCore;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;vtkfreetype;vtkzlib;vtkftgl
>>>>>> -- Configuring done
>>>>>> -- Generating done
>>>>>> -- Build files have been written to: /home/marcus/build/vtkcomponents
>>>>>>
>>>>>> As far as I can see this gives the libraries one would expect, i.e.
>>>>>> vtkChartsCore, vtkCommonCore, vtkCommonMath, vtkChartsCore, and the
>>>>>> final one is incorrect but I am not sure of the value in supporting
>>>>>> mixed COMPONENTS and non-components versions of find_package.
>>>>>>
>>>>>> Let me know if there is something I am missing, is this possibly with
>>>>>> an older version of VTK (I am testing with master).
>>>>>>
>>>>>> Marcus


From brad.king at kitware.com  Thu Sep 25 12:56:26 2014
From: brad.king at kitware.com (Brad King)
Date: Thu, 25 Sep 2014 12:56:26 -0400
Subject: [vtk-developers] Repeated calls to find_package(VTK COMPONENTS
	...)
In-Reply-To: <CALzTN-SB1_iA9Q-4i75WfH=KR5L-4hvV5fs15ZiTJ4LQH7Udzg@mail.gmail.com>
References: <CAMkPkZU+j_QDUS9Kamv-_skp8TaZofDgcvncZU7onUgLvU4Szg@mail.gmail.com>	<CAMkPkZWL08DqYdK5P=UCRjGhsnCkaUroEYzDH1xZ2P_WLMBcBQ@mail.gmail.com>	<CAMkPkZX9Yujk+qtakrvT3od5Q6Lfy3=aaF5f2k48zF=WFc4c8w@mail.gmail.com>	<CALzTN-QRD=JOk-i9Ab3dbyTq2_rd6VB9PpH1Ou3G93+4J5v_4g@mail.gmail.com>	<CAMkPkZUBupso2wn9n6zRzWnPKKYReReCbkkezqKSamNO=pUawg@mail.gmail.com>	<CALzTN-TQwV5t0wf-TSoLBFmD17JBWNY=BB0dED2OkdazTMYyGQ@mail.gmail.com>
 <CALzTN-SB1_iA9Q-4i75WfH=KR5L-4hvV5fs15ZiTJ4LQH7Udzg@mail.gmail.com>
Message-ID: <5424493A.1070406@kitware.com>

On 09/25/2014 12:48 PM, Matt McCormick wrote:
> Looking at FindITK.cmake and FindVTK.cmake, they appear to not
> propagate COMPONENTS [1] [2].

Those are forwarded by find_package automatically:

 http://www.cmake.org/cmake/help/v3.0/command/find_package.html
 "If no [version] and/or component list is given to a recursive
  invocation inside a find-module, the corresponding arguments
  are forwarded automatically from the outer call"

> I think we should consider removing these altogether.
> Any version of ITK or VTK from moderately recent history will
> have a Config.cmake file.

They provide compatibility for applications that expect
USE_ITK_FILE or USE_VTK_FILE to be set instead of the modern
ITK_USE_FILE or VTK_USE_FILE.  The ITK one also provides
compatibility with versions of ITK that installed the
package files under lib/InsightToolkit instead of lib/ITK.

However, I would be okay with removing them.

-Brad



From sean at rogue-research.com  Fri Sep 26 12:01:09 2014
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 26 Sep 2014 12:01:09 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <5405C84D.2010007@kitware.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
Message-ID: <20140926160109.603512592@mail.rogue-research.com>

On Tue, 2 Sep 2014 09:38:21 -0400, Brad King said:

>On 08/28/2014 11:07 AM, Sean McBride wrote:
>> 1) a 'commits' email list, like other projects.  Where you get an
>> email for every merge into master.
>
>We've had one of these since CVS days:
>
> http://www.vtk.org/mailman/listinfo/vtk-commit

Brad,

Thanks for pointing this out.  I subscribed immediately, but wanted to experience it a bit before replying.

It's decent, but I find the subject line really not useful.  They are always of the form:

[Vtk-commit] Visualization Toolkit branch, master, updated. v6.1.0-1718-g5ad494c

Only the last bit ever changes, meaning you really need to look at the body of the email.

Much more useful would be something like on the clang commits list, ex:

r218482 - Fix PR20886 - enforce CUDA target match in method calls

There you can lurk on the list and have an idea of what's changing just from scanning the subjects.  For me anyway, that'd be perfect.

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 brad.king at kitware.com  Fri Sep 26 14:02:56 2014
From: brad.king at kitware.com (Brad King)
Date: Fri, 26 Sep 2014 14:02:56 -0400
Subject: [vtk-developers] VTK commits mailing list
In-Reply-To: <20140926160109.603512592@mail.rogue-research.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <20140926160109.603512592@mail.rogue-research.com>
Message-ID: <5425AA50.3020904@kitware.com>

On 09/26/2014 12:01 PM, Sean McBride wrote:
> It's decent, but I find the subject line really not useful.
> They are always of the form:
> 
> [Vtk-commit] Visualization Toolkit branch, master, updated. v6.1.0-1718-g5ad494c
> 
> Much more useful would be something like on the clang commits list, ex:
> 
> r218482 - Fix PR20886 - enforce CUDA target match in method calls

We're just using the contrib/hooks/post-receive-email script from
the upstream git.git repository.  The difference is that our Git
repository notifications are per-push, not per-commit.  One push
can contain many commits, and for us almost always contains at
least 2.  There is no good way to generate a subject line that
summarizes more than one commit.

It is possible to generate one message per commit, but that will
take further investigation someday.

-Brad



From will.schroeder at kitware.com  Sat Sep 27 07:27:49 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Sat, 27 Sep 2014 07:27:49 -0400
Subject: [vtk-developers] Driving away your existing developers
In-Reply-To: <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <CANjZAi_3U-3xThprzNGKEvKZsWH=2xFnWvh5qdLobPWZ=iMp4A@mail.gmail.com>
Message-ID: <CAEiDrtW2LzqBTpWRnfNrXcqE=+CHDk5t42uHPbHEMtarjw8r9g@mail.gmail.com>

+100

On Wed, Sep 3, 2014 at 10:33 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> One thing we can hope to do better next time to not alienate the old
> timers (including myself).
>
> * The transition from CVS to today's gerrit workflow was necessarily long,
> but there were frequent adjustments along the way as we learned and built
> up the infrastructure. Every change in the process meant retraining all of
> the (self interested and busy) contributors.
>
> Whatever our end goal is with the new infrastructure - we need to work
> harder to minimize the number of changes to the commit process, to keep the
> contribution process as dead simple as it can be, and to describe the
> mechanics clearly and loudly.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Tue, Sep 2, 2014 at 9:38 AM, Brad King <brad.king at kitware.com> wrote:
>
>> On 08/28/2014 11:07 AM, Sean McBride wrote:
>> > 1) a 'commits' email list, like other projects.  Where you get an
>> > email for every merge into master.
>>
>> We've had one of these since CVS days:
>>
>>  http://www.vtk.org/mailman/listinfo/vtk-commit
>>
>> It still works.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
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/20140927/e6d0af7d/attachment-0002.html>

From kevnull at phutureshock.com  Sat Sep 27 18:14:59 2014
From: kevnull at phutureshock.com (kevnull at phutureshock.com)
Date: Sat, 27 Sep 2014 15:14:59 -0700
Subject: [vtk-developers] "dot fe" writer class for writing meshes to
	Surface Evolver format?
Message-ID: <eac2839a69be7942404216412eaa963b.squirrel@webmail.phutureshock.com>

I am about to write a small class to write dot fe files that the "Surface
Evolver" software takes as input. If anyone on the list has already done
so would you mind sharing your code. If not, if anyone is interested,
please email me and I will send you the code when it is finished.

While I am emailing the list, I might as well ask a question about point
clouds that I have been struggling with lately, that is, extracting
topologically clean 2-surfaces from a CT scan that has some "thickness" to
it. I would like to use only the points on the "exterior of the surface"
to eventually run marching cubes on, is there a filter that I can use to
thin my data set to those points on the "outside surface" of the point
cloud?

Details here:

http://www.phutureshock.com/mememap/poor-quality-meshes-and-vertex-normals-from-a-point-cloud-with-densitythickness/

Thanks in advance!

Best,
Kevin



From cory.quammen at kitware.com  Mon Sep 29 11:19:01 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Mon, 29 Sep 2014 11:19:01 -0400
Subject: [vtk-developers] Single test file used for more than one test?
In-Reply-To: <CAB5Fpx54C2P=oJgRaip=eSK1Cpkta1BasNApAa60mwZyK9C93A@mail.gmail.com>
References: <CAB5Fpx644+XJ-mjFwytOeD3wVHNLYeXW49P39MSbdJjoOMVwFw@mail.gmail.com>
 <5411BE3C.7030207@gmail.com>
 <CAB5Fpx54C2P=oJgRaip=eSK1Cpkta1BasNApAa60mwZyK9C93A@mail.gmail.com>
Message-ID: <CAB5Fpx7_mP_cmQVTXEj_T7Cs50TsVxTz6zpirmJ2AraedMa5qQ@mail.gmail.com>

Just to follow up, I put in some changes in VTK that enable you to
specify a test name in front of the test source file in
vtk_add_test_*.

Author: Cory Quammen <cory.quammen at kitware.com>  2014-09-12 09:00:52
Committer: Cory Quammen <cory.quammen at kitware.com>  2014-09-15 09:50:11

    Enabled easier specification of custom test name

    A custom test name can be specified by giving a name followed by a
    comma before the test file name, .e.g.,

    CustomTestName,TestSource.cxx

    CustomTclTestName,TestSource.tcl

    CustomPyTestName,TestSource.py

    Support for custom test names is available in:

    vtk_add_test_cxx
    vtk_add_test_mpi
    vtk_add_test_python
    vtk_add_test_python_mpi
    vtk_add_test_tcl

    This way to specify a custom name is more straightforward and less
    verbose than the vtk_test_prefix mechanism or custom calls to
    ExternalData_add_test.

    Example:

    vtk_add_test_cxx(${vtk-module}CxxTests tests
      TestClass,TestClass.cxx --arg0 --arg1 --arg2
    )

    vtk_add_test_cxx(${vtk-module}CxxTests tests
      TestClass2,TestClass.cxx --arg3 --arg4 --arg5
    )

    The baseline for a test with custom name 'TestClass2' is expected to
    be 'TestClass2.png'.

    Note that currently, every test defined from the same source file
    must be defined in a separate call to vtk_add_test_*. For example,

    vtk_add_test_cxx(${vtk-module}CxxTests tests
      TestClass,TestClass.cxx --arg0 --arg1 --arg2
      TestClass2,TestClass.cxx --arg3 --arg4 --arg5
    )

    does not work correctly - it passes --arg0 through --arg5 to both the
    TestClass and TestClass2 test instances. Instead, tests with arguments
    must be specified with different calls to vtk_add_test_*.

    Change-Id: I88fabc4c5eca5898e257887f3e161fd9c4ee0864

On Thu, Sep 11, 2014 at 5:38 PM, Cory Quammen <cory.quammen at kitware.com> wrote:
> Burlen,
>
> Thanks for the pointer. I like that your example is explicit in what
> is being passed to the tests.
>
> To use the more "magic" vtk_add_test_cxx() function, it turns out you
> can do the following:
>
> set(vtk_test_prefix Second)
> vtk_add_test_cxx(${vtk-module}CxxTests tests
>   SurfacePlusEdges.cxx --arg1 --arg2 --arg3
> )
> unset(vtk_test_prefix)
>
> And this will define a test named $(vtk-module}Cxx-SecondSurfacePlusEdges.
>
> In it's current form, this test will point to a baseline named
> SurfacePlusEdges.png. To point it to a baseline for just this test, I
> had to modify vtkTestingMacros.cmake to include vtk_test_prefix in the
> baseline path. The modifications are on gerrit:
>
> http://review.source.kitware.com/#/t/4648/
>
> This specifies the baseline file name as SecondSurfacePlusEdges.png.
>
> Reviews for this topic are appreciated :-)
>
> I'm not sure if I'm thrilled with defining the test name this way. It
> would be nicer to do something like
>
> vtk_add_test_cxx(${vtk-module}CxxTests tests
>   SurfacePlusEdges.cxx --arg0 --arg1 --arg2
>   SurfacePlusEdges.cxx,CUSTOM_NAME SurfacePlusEdges2 --arg3 --arg4 --arg5
> )
>
> where if CUSTOM_NAME is specified, the first argument is the test name.
>
> Thanks,
> Cory
>
> On Thu, Sep 11, 2014 at 11:22 AM, Burlen Loring <burlen.loring at gmail.com> wrote:
>> Hi Cory,
>>
>> That's how the surface LIC tests are written. Take a look at
>> VTK/Rendering/LIC/Testing/Cxx/CMakeLists.txt
>>
>> Burlen
>>
>>
>> On 09/11/2014 08:07 AM, Cory Quammen wrote:
>>>
>>> Hi all,
>>>
>>> I'm writing a VTK test that takes some command-line arguments to
>>> control some options in a filter. What I would like to do is define
>>> several tests in the CMakeLists.txt file that run this same code but
>>> which pass different arguments in through argv[].
>>>
>>> I haven't found an example of this kind of test in VTK. Most tests are
>>> defined by passing to vtk_add_test_cxx the name of the source file for
>>> the test.
>>>
>>> Can anyone point me to an example similar to what I want to do?
>>>
>>> Thanks!
>>> Cory
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>


From berk.geveci at kitware.com  Mon Sep 29 16:40:41 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Mon, 29 Sep 2014 16:40:41 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
Message-ID: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>

Hi folks,

For Thursday's hackaton, we need a way of organizing and assigning bugs. I
suggest that we use our bug tracker for this. We can assign tags to bugs as
well as assign them to people in there. I already created a "hackaton" tag
that you can use.

So if you are planning on attending, please quickly go over the bug tracker
and tag any bug that look interesting to you with the "hackaton" tag. Also,
assign it to yourself if you'd like to work on it, as long as it is not
already tagged and assigned to someone else.

You can use the "View Issues" view and the tags filter there to list all
bugs already tagged as "hackaton". (1 as of this writing).

For those attending by Google Hangout, here the link:

https://plus.google.com/events/cd0s6so0ijo45dsulg8and8p5tg

For those attending in person, if you didn't already let me know please do
so soon.

Looking forward to it.
-berk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140929/c38384a4/attachment-0002.html>

From berk.geveci at kitware.com  Mon Sep 29 20:15:16 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Mon, 29 Sep 2014 20:15:16 -0400
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
In-Reply-To: <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>
References: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
 <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>
Message-ID: <CAE32kpX_H2fJmmd+G5ScRsnM13C5NQTe3c5FtDhSZdGj-eakYw@mail.gmail.com>

Hi David,

Many apologies for taking so long to answer.  It was a tough week. The
short answer is no. If you are doing this in Python with VTK master, I'd
suggest using vtkPythonAlgorithm. This should take no more than 10 lines of
Python code to achieve.

Best,
-berk

On Tue, Sep 23, 2014 at 12:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Trying again:
>
> Is there a flag that the user can set on a vtkAlgorithm to force it to
> always request the whole extent from its input?
>
> I'm guessing the answer is "no" because I don't see any code in
> vtkStreamingDemandDrivenPipeline.cxx that would support such a
> feature, but I'm wondering if I can get confirmation from other
> developers who are familiar with the pipeline.
>
>  - David
>
>
> On Mon, Sep 22, 2014 at 12:22 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > Hi All,
> >
> > This is a question about streaming in an imaging pipeline.  Sometimes
> > I want to stream just part of whole extent through the pipeline, but
> > even more often, I want to pull through the whole extent even if a
> > downstream request is for just a single slice.
> >
> > Is there a trivial filter in VTK that, regardless of the UpdateExtent
> > requested, will always request the WholeExtent from upstream?
> > I say "trivial" because it would indeed be a trivial filter to write.
> > Has anyone else ever written or used such a filter?
> >
> > Basically, I'm looking for an easy way to turn streaming off at
> > any point in my pipeline, either by inserting a "non-streaming filter"
> > or by telling an existing filter not to stream.
> >
> >  - David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20140929/416c5227/attachment-0002.html>

From david.gobbi at gmail.com  Tue Sep 30 08:35:57 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 30 Sep 2014 06:35:57 -0600
Subject: [vtk-developers] A filter that does the opposite of
	vtkImageDataStreamer?
In-Reply-To: <CAE32kpX_H2fJmmd+G5ScRsnM13C5NQTe3c5FtDhSZdGj-eakYw@mail.gmail.com>
References: <CANwS1=GDyjLyti64m0mthebz-2cQk337QT9K=3R8yDSeP5r67Q@mail.gmail.com>
 <CANwS1=EQUB4+QfwjnYfA7ezjGsQfjWFL323eX-__-oyeWiJigA@mail.gmail.com>
 <CAE32kpX_H2fJmmd+G5ScRsnM13C5NQTe3c5FtDhSZdGj-eakYw@mail.gmail.com>
Message-ID: <CANwS1=GvhgzsxOapr-aciNurrBFySPXVxRjZEYoef5Wu2_UTgQ@mail.gmail.com>

Thanks, pretty much what I figured.  I'm not using python for this
project, but I'll throw together a C++ "anti-streaming filter" and
test it in my pipeline.

 - David



On Mon, Sep 29, 2014 at 6:15 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi David,
>
> Many apologies for taking so long to answer.  It was a tough week. The short
> answer is no. If you are doing this in Python with VTK master, I'd suggest
> using vtkPythonAlgorithm. This should take no more than 10 lines of Python
> code to achieve.
>
> Best,
> -berk
>
> On Tue, Sep 23, 2014 at 12:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Trying again:
>>
>> Is there a flag that the user can set on a vtkAlgorithm to force it to
>> always request the whole extent from its input?
>>
>> I'm guessing the answer is "no" because I don't see any code in
>> vtkStreamingDemandDrivenPipeline.cxx that would support such a
>> feature, but I'm wondering if I can get confirmation from other
>> developers who are familiar with the pipeline.
>>
>>  - David
>>
>>
>> On Mon, Sep 22, 2014 at 12:22 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>> > Hi All,
>> >
>> > This is a question about streaming in an imaging pipeline.  Sometimes
>> > I want to stream just part of whole extent through the pipeline, but
>> > even more often, I want to pull through the whole extent even if a
>> > downstream request is for just a single slice.
>> >
>> > Is there a trivial filter in VTK that, regardless of the UpdateExtent
>> > requested, will always request the WholeExtent from upstream?
>> > I say "trivial" because it would indeed be a trivial filter to write.
>> > Has anyone else ever written or used such a filter?
>> >
>> > Basically, I'm looking for an easy way to turn streaming off at
>> > any point in my pipeline, either by inserting a "non-streaming filter"
>> > or by telling an existing filter not to stream.
>> >
>> >  - David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>


From ben.boeckel at kitware.com  Tue Sep 30 10:46:07 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 30 Sep 2014 10:46:07 -0400
Subject: [vtk-developers] VTK commits mailing list
In-Reply-To: <5425AA50.3020904@kitware.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <20140926160109.603512592@mail.rogue-research.com>
 <5425AA50.3020904@kitware.com>
Message-ID: <20140930144607.GB12969@megas.kitwarein.com>

On Fri, Sep 26, 2014 at 14:02:56 -0400, Brad King wrote:
>           There is no good way to generate a subject line that
> summarizes more than one commit.

Maybe include the branch name that was merged?

--Ben


From brad.king at kitware.com  Tue Sep 30 10:50:24 2014
From: brad.king at kitware.com (Brad King)
Date: Tue, 30 Sep 2014 10:50:24 -0400
Subject: [vtk-developers] VTK commits mailing list
In-Reply-To: <20140930144607.GB12969@megas.kitwarein.com>
References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch>
 <CAPK9r6_+f1eCjKYyDP9iBPA8zypCmuSC0EpUF4JHjwB-AY3cSQ@mail.gmail.com>
 <CAE32kpVPbAysDNYS06Yo_153Yjr3mGfzJxh183mr3qnr_CkSkg@mail.gmail.com>
 <20140828150749.1061007759@mail.rogue-research.com>
 <5405C84D.2010007@kitware.com>
 <20140926160109.603512592@mail.rogue-research.com>
 <5425AA50.3020904@kitware.com> <20140930144607.GB12969@megas.kitwarein.com>
Message-ID: <542AC330.6090405@kitware.com>

On 09/30/2014 10:46 AM, Ben Boeckel wrote:
> On Fri, Sep 26, 2014 at 14:02:56 -0400, Brad King wrote:
>>           There is no good way to generate a subject line that
>> summarizes more than one commit.
> 
> Maybe include the branch name that was merged?

We don't have that explicitly.  We have only the name of the
integration branch and its old and new sha1 values.  Yes, more
info could be inferred given knowledge of our merge workflow,
but that is also new infrastructure development.

-Brad