From sean at rogue-research.com  Wed Oct  1 12:25:55 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 12:25:55 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
Message-ID: <20141001162555.1350523649@mail.rogue-research.com>

On Mon, 29 Sep 2014 16:40:41 -0400, Berk Geveci said:

>For Thursday's hackaton, we need a way of organizing and assigning bugs.

Speaking of which, is there any doc about using Mantis?  I couldn't find anything.  For example, the 'status' options are 'backlog/tabled/expired/closed', what do they mean?  (They are not Mantis' defaults.) What status should be set when a developer has claimed to fix something but the submitter has not yet verified?  Normally, with Mantis' defaults, one would set to 'resolved' then the submitter would set to 'closed'.

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 berk.geveci at kitware.com  Wed Oct  1 12:30:21 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 1 Oct 2014 12:30:21 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <20141001162555.1350523649@mail.rogue-research.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
Message-ID: <CAE32kpX9DSs_bjjNWBEVttcBbTt8i-DVh6+QH5ZH-80r7Tr62w@mail.gmail.com>

There is some sort of state machine in Mantis. Once you put a bug into the
backlog status, other states will appear. The idea was to prevent people
from jumping certain steps, I believe.

My feeling is that we are going to move away from Mantis in the nearish
future so I wouldn't spend a lot of time learning it.

-berk

On Wed, Oct 1, 2014 at 12:25 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Mon, 29 Sep 2014 16:40:41 -0400, Berk Geveci said:
>
> >For Thursday's hackaton, we need a way of organizing and assigning bugs.
>
> Speaking of which, is there any doc about using Mantis?  I couldn't find
> anything.  For example, the 'status' options are
> 'backlog/tabled/expired/closed', what do they mean?  (They are not Mantis'
> defaults.) What status should be set when a developer has claimed to fix
> something but the submitter has not yet verified?  Normally, with Mantis'
> defaults, one would set to 'resolved' then the submitter would set to
> 'closed'.
>
> 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/20141001/acab7608/attachment-0001.html>

From dave.demarle at kitware.com  Wed Oct  1 12:32:19 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 1 Oct 2014 12:32:19 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <20141001162555.1350523649@mail.rogue-research.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
Message-ID: <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>

see "the vtk software process"
https://docs.google.com/a/kitware.com/document/d/1nzinw-dR5JQRNi_gb8qwLL5PnkGMK2FETlQGLr10tZw/edit
section 6

"tabled" is something mantis keeps on putting in there for some reason I
don't understand. Think of it as backlog.



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

On Wed, Oct 1, 2014 at 12:25 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Mon, 29 Sep 2014 16:40:41 -0400, Berk Geveci said:
>
> >For Thursday's hackaton, we need a way of organizing and assigning bugs.
>
> Speaking of which, is there any doc about using Mantis?  I couldn't find
> anything.  For example, the 'status' options are
> 'backlog/tabled/expired/closed', what do they mean?  (They are not Mantis'
> defaults.) What status should be set when a developer has claimed to fix
> something but the submitter has not yet verified?  Normally, with Mantis'
> defaults, one would set to 'resolved' then the submitter would set to
> 'closed'.
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141001/b814f3a8/attachment.html>

From berk.geveci at kitware.com  Wed Oct  1 12:36:56 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 1 Oct 2014 12:36:56 -0400
Subject: [vtk-developers] Gerrit update
Message-ID: <CAE32kpUVHmvRxW0fSXqz9s=iEnM1vv1QVf-o2h4Lh+ksxsgtsA@mail.gmail.com>

Hi folks,

We are working on updating our Gerrit instance (review.source.kitware.com).
When updated, there will no longer be topic support. As many of you know,
the topic support was based on a fork we created and those changes were not
accepted by Gerrit upstream. The decision was that, for security reasons,
we need to update to a newer version of Gerrit. Our changes are too hard to
port forward so we will drop the topic support.

At the same time, we are evaluating Gitlab for potentially migrating code
review, merge management and issue tracking. At this point, it is looking
very likely that we will migrate to Gitlab or Github. So the lack of topic
support will be temporary and we will most likely switch to using pull
requests with Github/Gitlab.

I will send an update once I hear more about when the Gerrit update is
coming. The Gitlab/Github update is a longer term thing. Probably several
months.

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

From sean at rogue-research.com  Wed Oct  1 14:19:28 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 14:19:28 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <CAE32kpX9DSs_bjjNWBEVttcBbTt8i-DVh6+QH5ZH-80r7Tr62w@mail.gmail.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
 <CAE32kpX9DSs_bjjNWBEVttcBbTt8i-DVh6+QH5ZH-80r7Tr62w@mail.gmail.com>
Message-ID: <20141001181928.1777698660@mail.rogue-research.com>

On Wed, 1 Oct 2014 12:30:21 -0400, Berk Geveci said:

>My feeling is that we are going to move away from Mantis in the nearish
>future so I wouldn't spend a lot of time learning it.

We use it here at work, so am actually quite familiar with it.  What are you thinking to switch to?

Cheers,

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



From sean at rogue-research.com  Wed Oct  1 14:19:45 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 14:19:45 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
 <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>
Message-ID: <20141001181945.1795144326@mail.rogue-research.com>

On Wed, 1 Oct 2014 12:32:19 -0400, David E DeMarle said:

>see "the vtk software process"
>https://docs.google.com/a/kitware.com/document/d/1nzinw-
>dR5JQRNi_gb8qwLL5PnkGMK2FETlQGLr10tZw/edit
>section 6
>
>"tabled" is something mantis keeps on putting in there for some reason I
>don't understand. Think of it as backlog.

OK, so it says one should set fixed bugs to 'closed'.  Then the submitter reopens if he disagrees I guess?  Are you sure submitters can reopen?  From what I've seen of Mantis, once set to 'closed' you need higher permission to reopen or even comment...

That doc also says "When a new bug report is made, mantis sends it off to the developer?s mailing list".  That doesn't seem to be true... perhaps it should be...?

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 dave.demarle at kitware.com  Wed Oct  1 15:11:06 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 1 Oct 2014 15:11:06 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <20141001181945.1795144326@mail.rogue-research.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
 <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>
 <20141001181945.1795144326@mail.rogue-research.com>
Message-ID: <CANjZAi-mezQDMN61yQAaRArC46pMMwuxomW26pY+47XKr4HscA@mail.gmail.com>

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

On Wed, Oct 1, 2014 at 2:19 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Wed, 1 Oct 2014 12:32:19 -0400, David E DeMarle said:
>
> >see "the vtk software process"
> >https://docs.google.com/a/kitware.com/document/d/1nzinw-
> >dR5JQRNi_gb8qwLL5PnkGMK2FETlQGLr10tZw/edit
> >section 6
> >
> >"tabled" is something mantis keeps on putting in there for some reason I
> >don't understand. Think of it as backlog.
>
> OK, so it says one should set fixed bugs to 'closed'.  Then the submitter
> reopens if he disagrees I guess?  Are you sure submitters can reopen?  From
> what I've seen of Mantis, once set to 'closed' you need higher permission
> to reopen or even comment...
>
>
That is a configuration setting, just like the workflow states. On VTK,
developers, managers and the administrator can reopen bugs. I'll add
reporter and viewer as well.


> That doc also says "When a new bug report is made, mantis sends it off to
> the developer?s mailing list".  That doesn't seem to be true... perhaps it
> should be...?
>

Still seems to be coming through:

http://markmail.org/search/vtk-developers+list:org%2Evtk%2Evtk-developers+mantis+from:%22Mantis+Bug+Tracker%22+order:date-backward

Now the part about "the release manager reads all newly submitted bugs and
asks developers who are familiar with the area of VTK that the bug relates
to to do a cursory review" hasn't been working so well.



>
> 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/20141001/49067729/attachment.html>

From bill.lorensen at gmail.com  Wed Oct  1 15:44:52 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 1 Oct 2014 15:44:52 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
Message-ID: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>

Folks,

I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my part?

Bill

From sean at rogue-research.com  Wed Oct  1 16:07:24 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 16:07:24 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
Message-ID: <20141001200724.1865052938@mail.rogue-research.com>

On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:

>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my part?

Likewise.  David, maybe you broke something changing the 'reopening' permissions?

Cheers,

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



From bill.lorensen at gmail.com  Wed Oct  1 16:09:20 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 1 Oct 2014 16:09:20 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <20141001200724.1865052938@mail.rogue-research.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
 <20141001200724.1865052938@mail.rogue-research.com>
Message-ID: <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>

bill.lorensen

On Wed, Oct 1, 2014 at 4:07 PM, Sean McBride <sean at rogue-research.com> wrote:
> On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:
>
>>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my part?
>
> Likewise.  David, maybe you broke something changing the 'reopening' permissions?
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>



-- 
Unpaid intern in BillsBasement at noware dot com

From dave.demarle at kitware.com  Wed Oct  1 16:37:15 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 1 Oct 2014 16:37:15 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
 <20141001200724.1865052938@mail.rogue-research.com>
 <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>
Message-ID: <CANjZAi9Gz-YHU3ZsHF-nxUjjdCmYeQk=3REMD5t1bmk0PDk-7A@mail.gmail.com>

Should be fixed now.
Try again please.

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

On Wed, Oct 1, 2014 at 4:09 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> bill.lorensen
>
> On Wed, Oct 1, 2014 at 4:07 PM, Sean McBride <sean at rogue-research.com>
> wrote:
> > On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:
> >
> >>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my
> part?
> >
> > Likewise.  David, maybe you broke something changing the 'reopening'
> permissions?
> >
> > Cheers,
> >
> > --
> > ____________________________________________________________
> > Sean McBride, B. Eng                 sean at rogue-research.com
> > Rogue Research                        www.rogue-research.com
> > Mac Software Developer              Montr?al, Qu?bec, Canada
> >
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> 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/20141001/fe551673/attachment.html>

From bill.lorensen at gmail.com  Wed Oct  1 16:46:14 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 1 Oct 2014 16:46:14 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <CANjZAi9Gz-YHU3ZsHF-nxUjjdCmYeQk=3REMD5t1bmk0PDk-7A@mail.gmail.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
 <20141001200724.1865052938@mail.rogue-research.com>
 <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>
 <CANjZAi9Gz-YHU3ZsHF-nxUjjdCmYeQk=3REMD5t1bmk0PDk-7A@mail.gmail.com>
Message-ID: <CADZJ4hOgQdKC=yuZ6d_hyL9e5A6W3hbLjB6_epGOyEZKOHhMgQ@mail.gmail.com>

It's OK now. Thanks!


On Wed, Oct 1, 2014 at 4:37 PM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> Should be fixed now.
> Try again please.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Wed, Oct 1, 2014 at 4:09 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> bill.lorensen
>>
>> On Wed, Oct 1, 2014 at 4:07 PM, Sean McBride <sean at rogue-research.com>
>> wrote:
>> > On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:
>> >
>> >>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my
>> >> part?
>> >
>> > Likewise.  David, maybe you broke something changing the 'reopening'
>> > permissions?
>> >
>> > Cheers,
>> >
>> > --
>> > ____________________________________________________________
>> > Sean McBride, B. Eng                 sean at rogue-research.com
>> > Rogue Research                        www.rogue-research.com
>> > Mac Software Developer              Montr?al, Qu?bec, Canada
>> >
>> >
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> _______________________________________________
>> 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  Fri Oct  3 08:42:35 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 3 Oct 2014 08:42:35 -0400
Subject: [vtk-developers] post hackathon cleanup
Message-ID: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>

not too bad actually!

Dave C, can you look at the blackbox tests?

thanks,

22  FAILURES
vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
['Mac10.8-clang-rel-x86_64']
vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
['Mac10.8-clang-rel-x86_64']
vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
vtkCommonDataModelCxx-TestHigherOrderCell , 1 , ['Mac10.8-clang-rel-x86_64']
vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
['Win32-vs71-static']
vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
['Mac10.5-gcc-dbg-ppc-shared']
vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
['Mac10.8-clang-rel-x86_64']
vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
vtkFiltersCorePython-multipleComponentContour , 1 ,
['Arch-GCC-4.9-x86_64-debug']
vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator ,
1 , ['Win64-VS10']
vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
['Win64-VS10']
vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
['Mac10.8-clang-rel-x86_64']
JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
'Linux-gcc']
vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
'Arch-GCC-4.9-x86_64-release']
vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141003/9d74e504/attachment.html>

From dave.demarle at kitware.com  Fri Oct  3 08:51:57 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 3 Oct 2014 08:51:57 -0400
Subject: [vtk-developers] post hackathon process suggestions?
Message-ID: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>

We all did a great job Yesterday. Thank you to everyone who participated in
the bug tracker hackathon as well as to those who did us the favor of
reporting the bugs.

Moving forward, and particularly now that we are starting to setup the next
generation suite of software process tools, what can we do to make bug
tracking more relevant to VTK's future development?

See the VTK software process doc section 6 for our collective thoughts on
where we stand right now and are trying to improve upon.

thanks,

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141003/912dbe9c/attachment.html>

From marcus.hanwell at kitware.com  Fri Oct  3 09:32:16 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Fri, 3 Oct 2014 09:32:16 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
Message-ID: <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>

On Fri, Oct 3, 2014 at 8:51 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> We all did a great job Yesterday. Thank you to everyone who participated in
> the bug tracker hackathon as well as to those who did us the favor of
> reporting the bugs.

Yes, great job, and yet another really useful hackathon.
>
> Moving forward, and particularly now that we are starting to setup the next
> generation suite of software process tools, what can we do to make bug
> tracking more relevant to VTK's future development?

I think whatever bug/issue tracker we use ensuring the developer list
is emailed when new tickets are created is crucial. I was talking with
one of our summer of code students and he felt (and I agree) that
weekly developer meetings on IRC would be really useful. We could
likely substitute technology if necessary, but some kind of regular
meeting where real time interaction is possible.
>
> See the VTK software process doc section 6 for our collective thoughts on
> where we stand right now and are trying to improve upon.
>
I would love to go back to a document where we can link to individual
pages and sections, like the wiki or similar. I think real time
editing is great, but I don't think Google Docs works well for this
type of documentation long term. There may be other technologies, but
something where anyone can edit, hyperlinks to pages and sections in
pages would be great so that it is easy to point people directly at
relevant text.

Just my 2 cents, really good hackathon, still have >70% coverage after
our coverage hackathon too!

Marcus

From cory.quammen at kitware.com  Fri Oct  3 10:06:44 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Fri, 3 Oct 2014 10:06:44 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
Message-ID: <CAB5Fpx5J9CmB7_x51q=MaQ5epywOtbNXqxNs-GbhhQo9O-9AFQ@mail.gmail.com>

> I think whatever bug/issue tracker we use ensuring the developer list
> is emailed when new tickets are created is crucial. I was talking with
> one of our summer of code students and he felt (and I agree) that
> weekly developer meetings on IRC would be really useful. We could
> likely substitute technology if necessary, but some kind of regular
> meeting where real time interaction is possible.

+1

From sean at rogue-research.com  Fri Oct  3 10:17:52 2014
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 3 Oct 2014 10:17:52 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
Message-ID: <20141003141752.188535373@mail.rogue-research.com>

On Fri, 3 Oct 2014 09:32:16 -0400, Marcus D. Hanwell said:

>Yes, great job, and yet another really useful hackathon.

Agreed.  We should do them more often!

>I think whatever bug/issue tracker we use ensuring the developer list
>is emailed when new tickets are created is crucial.

+1.

I mentioned this the other day, the docs says it happens and Dave DeMarle agreed pointing this out:

http://markmail.org/search/vtk-developers+list:org%2Evtk%2Evtk-developers+mantis+from:%22Mantis+Bug+Tracker%22+order:date-backward

But it seems to show nothing since 2013.  A google search of "14266 site:vtk.org" shows nothing on the vtk-dev list either.  I would have fixed #14266 ages ago if I knew it existed.

(Next time I hope to be back in person, it was not as fun over the net, and I felt like more of a voyeur without my mic working. :))

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 berk.geveci at kitware.com  Sat Oct  4 13:38:18 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Sat, 4 Oct 2014 13:38:18 -0400
Subject: [vtk-developers] post hackathon cleanup
In-Reply-To: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
References: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
Message-ID: <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>

Hi guys,

I was looking at these tests that started failing after out hackathone:

http://open.cdash.org/viewTest.php?onlyfailed&buildid=3515162

It looks like someone added some leaks:

vtkDebugLeaks has detected LEAKS!
Class "vtkMatrix4x4" has 3 instances still around.
Class "vtkTransform" has 3 instances still around.

If you did anything with transforms during the hackathon, can you please
check this out?

Thanks,
-berk

On Fri, Oct 3, 2014 at 8:42 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> not too bad actually!
>
> Dave C, can you look at the blackbox tests?
>
> thanks,
>
> 22  FAILURES
> vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
> vtkCommonDataModelCxx-TestHigherOrderCell , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
> ['Win32-vs71-static']
> vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
> vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
> ['Mac10.5-gcc-dbg-ppc-shared']
> vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
> vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
> vtkFiltersCorePython-multipleComponentContour , 1 ,
> ['Arch-GCC-4.9-x86_64-debug']
> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator
> , 1 , ['Win64-VS10']
> vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
> vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
> ['Win64-VS10']
> vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
> vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
> 'Linux-gcc']
> vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
> ['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
> 'Arch-GCC-4.9-x86_64-release']
> vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
> vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
> vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141004/7c304a37/attachment.html>

From DLRdave at aol.com  Sat Oct  4 15:58:15 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 4 Oct 2014 15:58:15 -0400
Subject: [vtk-developers] post hackathon cleanup
In-Reply-To: <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>
References: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
 <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>
Message-ID: <CAKME8fF5i9TuyL3WVEXYqsK_RMoHABs+gKm_mW=WWK+LNw2n5Q@mail.gmail.com>

Looks like these are probably related to the vtkVRMLImporter changes I
made... If so, I'll take care of it.



On Sat, Oct 4, 2014 at 1:38 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi guys,
>
> I was looking at these tests that started failing after out hackathone:
>
> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3515162
>
> It looks like someone added some leaks:
>
> vtkDebugLeaks has detected LEAKS!
> Class "vtkMatrix4x4" has 3 instances still around.
> Class "vtkTransform" has 3 instances still around.
>
> If you did anything with transforms during the hackathon, can you please
> check this out?
>
> Thanks,
> -berk
>
> On Fri, Oct 3, 2014 at 8:42 AM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>>
>> not too bad actually!
>>
>> Dave C, can you look at the blackbox tests?
>>
>> thanks,
>>
>> 22  FAILURES
>> vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
>> vtkCommonDataModelCxx-TestHigherOrderCell , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
>> ['Win32-vs71-static']
>> vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
>> vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
>> ['Mac10.5-gcc-dbg-ppc-shared']
>> vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
>> vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
>> vtkFiltersCorePython-multipleComponentContour , 1 ,
>> ['Arch-GCC-4.9-x86_64-debug']
>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator
>> , 1 , ['Win64-VS10']
>> vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
>> vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
>> ['Win64-VS10']
>> vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
>> vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
>> 'Linux-gcc']
>> vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
>> ['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
>> 'Arch-GCC-4.9-x86_64-release']
>> vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>> vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>> vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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 DLRdave at aol.com  Sat Oct  4 17:09:19 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 4 Oct 2014 17:09:19 -0400
Subject: [vtk-developers] post hackathon cleanup
In-Reply-To: <CAKME8fF5i9TuyL3WVEXYqsK_RMoHABs+gKm_mW=WWK+LNw2n5Q@mail.gmail.com>
References: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
 <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>
 <CAKME8fF5i9TuyL3WVEXYqsK_RMoHABs+gKm_mW=WWK+LNw2n5Q@mail.gmail.com>
Message-ID: <CAKME8fEWZqpf4F=uTRWtApfpMhEBxjHpQ2CKjsTMxHcd_+=sTw@mail.gmail.com>

This topic should fix it -- waiting for CDash at home & Experimental
dashboard confirmation before claiming full victory...

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



On Sat, Oct 4, 2014 at 3:58 PM, David Cole <DLRdave at aol.com> wrote:
> Looks like these are probably related to the vtkVRMLImporter changes I
> made... If so, I'll take care of it.
>
>
>
> On Sat, Oct 4, 2014 at 1:38 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
>> Hi guys,
>>
>> I was looking at these tests that started failing after out hackathone:
>>
>> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3515162
>>
>> It looks like someone added some leaks:
>>
>> vtkDebugLeaks has detected LEAKS!
>> Class "vtkMatrix4x4" has 3 instances still around.
>> Class "vtkTransform" has 3 instances still around.
>>
>> If you did anything with transforms during the hackathon, can you please
>> check this out?
>>
>> Thanks,
>> -berk
>>
>> On Fri, Oct 3, 2014 at 8:42 AM, David E DeMarle <dave.demarle at kitware.com>
>> wrote:
>>>
>>> not too bad actually!
>>>
>>> Dave C, can you look at the blackbox tests?
>>>
>>> thanks,
>>>
>>> 22  FAILURES
>>> vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
>>> vtkCommonDataModelCxx-TestHigherOrderCell , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
>>> ['Win32-vs71-static']
>>> vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
>>> vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
>>> ['Mac10.5-gcc-dbg-ppc-shared']
>>> vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
>>> vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
>>> vtkFiltersCorePython-multipleComponentContour , 1 ,
>>> ['Arch-GCC-4.9-x86_64-debug']
>>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator
>>> , 1 , ['Win64-VS10']
>>> vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
>>> vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
>>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
>>> ['Win64-VS10']
>>> vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
>>> vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
>>> 'Linux-gcc']
>>> vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
>>> ['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
>>> 'Arch-GCC-4.9-x86_64-release']
>>> vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
>>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>> vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
>>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>> vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
>>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> 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 dave.demarle at kitware.com  Mon Oct  6 11:54:24 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Mon, 6 Oct 2014 11:54:24 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <20141003141752.188535373@mail.rogue-research.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
 <20141003141752.188535373@mail.rogue-research.com>
Message-ID: <CANjZAi-RC5+2DPTHEQQ6E8eoobAKKioZG-pihfaffxo9fOKeQw@mail.gmail.com>

* I'll look into where the bug tracker emails are getting dropped.

* About the software process doc.

- I like the trivial editing and collaborative commenting on google docs. I
also like the access control model. Approved authors can do whatever they
want to it, everyone else on the web can suggest edits and those are
trivial for approved authors to accept.
- I agree that we need a way to simply reference it and its content. How
about we simply put a note note in it saying where the master/editable
version is, export the doc to pdf every release or so, and make
references/links to the exported read only copy?

* I like the frequent IRC hangouts idea, as long as we can sustain interest
in it.


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

On Fri, Oct 3, 2014 at 10:17 AM, Sean McBride <sean at rogue-research.com>
wrote:

> On Fri, 3 Oct 2014 09:32:16 -0400, Marcus D. Hanwell said:
>
> >Yes, great job, and yet another really useful hackathon.
>
> Agreed.  We should do them more often!
>
> >I think whatever bug/issue tracker we use ensuring the developer list
> >is emailed when new tickets are created is crucial.
>
> +1.
>
> I mentioned this the other day, the docs says it happens and Dave DeMarle
> agreed pointing this out:
>
>
> http://markmail.org/search/vtk-developers+list:org%2Evtk%2Evtk-developers+mantis+from:%22Mantis+Bug+Tracker%22+order:date-backward
>
> But it seems to show nothing since 2013.  A google search of "14266 site:
> vtk.org" shows nothing on the vtk-dev list either.  I would have fixed
> #14266 ages ago if I knew it existed.
>
> (Next time I hope to be back in person, it was not as fun over the net,
> and I felt like more of a voyeur without my mic working. :))
>
> 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/20141006/1684c142/attachment-0001.html>

From marcus.hanwell at kitware.com  Mon Oct  6 12:07:26 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Mon, 6 Oct 2014 12:07:26 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CANjZAi-RC5+2DPTHEQQ6E8eoobAKKioZG-pihfaffxo9fOKeQw@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
 <20141003141752.188535373@mail.rogue-research.com>
 <CANjZAi-RC5+2DPTHEQQ6E8eoobAKKioZG-pihfaffxo9fOKeQw@mail.gmail.com>
Message-ID: <CAMkPkZV-Y0V2QizD8FuKyZTdJqLa+U2woObq_Uu+J2Rhj8TKKA@mail.gmail.com>

On Mon, Oct 6, 2014 at 11:54 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
>
> * About the software process doc.
>
> - I like the trivial editing and collaborative commenting on google docs. I
> also like the access control model. Approved authors can do whatever they
> want to it, everyone else on the web can suggest edits and those are trivial
> for approved authors to accept.
> - I agree that we need a way to simply reference it and its content. How
> about we simply put a note note in it saying where the master/editable
> version is, export the doc to pdf every release or so, and make
> references/links to the exported read only copy?
>
This is just my opinion, but Google doc, PDF, etc all suffer from not
being very accessible on the web. I see the draw of Google docs for
editing, and use it for many things but this doesn't seem like the
best fit to me. I would love to see at least pieces that are relevant
move back to the wiki, and thought this move was temporary (but I
don't remember any of the discussion about moving/keeping these docs
in a Google doc).

Exporting it to the CMS would work too, and restrict editing, if that
was possible. You know what I think now, if others think it works then
I can accept that and work with it. If it is long term a more
memorable link would be great for including in slides, wiki pages,
etc. On the positive side I think the actual content is an enormous
step forward, which is why I would like to make it as accessible as
possible.

Best,

Marcus

From patricksnape at gmail.com  Wed Oct  8 05:49:23 2014
From: patricksnape at gmail.com (patricksnape)
Date: Wed, 8 Oct 2014 02:49:23 -0700 (PDT)
Subject: [vtk-developers] VRML Appearance Nodes
Message-ID: <1412761763937-5729030.post@n5.nabble.com>

Hi,In the vtkVRMLImporter class  documentation
<http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html>   it
mentions that appearance nodes are supported. However, from browsing the
source code on Github, it appears that although they are recognised by the
parser, they are not actually parsed. It would be great if textures could be
parsed as well since the basic appearance nodes essentially just contain a
url to the texture. Is this something that would be valued by the rest of
the community? I'd love to drop the current VRML parser that I'm using but I
can't sacrifice texture support.



--
View this message in context: http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html
Sent from the VTK - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/bf1d623b/attachment.html>

From will.schroeder at kitware.com  Wed Oct  8 06:22:29 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Wed, 8 Oct 2014 06:22:29 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <1412761763937-5729030.post@n5.nabble.com>
References: <1412761763937-5729030.post@n5.nabble.com>
Message-ID: <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>

Patrick-

Can you enter a bug report? If not let me know and I'll do it. I've
contacted the original developer and I am "encouraging" him ;-) to take a
look...we'll see if he has the time.

W

On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com> wrote:

> Hi, In the vtkVRMLImporter class documentation
> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
> mentions that appearance nodes are supported. However, from browsing the
> source code on Github, it appears that although they are recognised by the
> parser, they are not actually parsed. It would be great if textures could
> be parsed as well since the basic appearance nodes essentially just contain
> a url to the texture. Is this something that would be valued by the rest of
> the community? I'd love to drop the current VRML parser that I'm using but
> I can't sacrifice texture support.
> ------------------------------
> View this message in context: VRML Appearance Nodes
> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
> Sent from the VTK - Dev mailing list archive
> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>
> _______________________________________________
> 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/20141008/73dfef7b/attachment.html>

From patricksnape at gmail.com  Wed Oct  8 09:05:16 2014
From: patricksnape at gmail.com (Patrick Snape)
Date: Wed, 8 Oct 2014 14:05:16 +0100
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
Message-ID: <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>

Hi Will,

Bug report submitted:

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

I'm not sure if any of the other importers include this functionality
(loading a texture from a url) but it would be a great addition I think. At
the very least the documentation should be clear that appearance nodes are
not actually supported. I wouldn't mind helping out but must admit that I
am intimidated with the complex process of submitting patches back to VTK.
Particularly the manner in which code reviews seem to be handled... I feel
like I'm trying to submit a patch back to the linux kernel!

Cheers,

Patrick

On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> Patrick-
>
> Can you enter a bug report? If not let me know and I'll do it. I've
> contacted the original developer and I am "encouraging" him ;-) to take a
> look...we'll see if he has the time.
>
> W
>
> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
> wrote:
>
>> Hi, In the vtkVRMLImporter class documentation
>> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
>> mentions that appearance nodes are supported. However, from browsing the
>> source code on Github, it appears that although they are recognised by the
>> parser, they are not actually parsed. It would be great if textures could
>> be parsed as well since the basic appearance nodes essentially just contain
>> a url to the texture. Is this something that would be valued by the rest of
>> the community? I'd love to drop the current VRML parser that I'm using but
>> I can't sacrifice texture support.
>> ------------------------------
>> View this message in context: VRML Appearance Nodes
>> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
>> Sent from the VTK - Dev mailing list archive
>> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>>
>> _______________________________________________
>> 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/20141008/9070a2e4/attachment.html>

From will.schroeder at kitware.com  Wed Oct  8 09:36:40 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Wed, 8 Oct 2014 09:36:40 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
 <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
Message-ID: <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>

I agree the process is tricky, and we are actively rethinking it.

If you want to make an attempt, just focus on the affected class(es) and a
test program. Either I or somebody much better at this than me will work
with you to slip it in.

So let me know if you are going to try, otherwise somebody, someday will
try and resolve this :-)

W

On Wed, Oct 8, 2014 at 9:05 AM, Patrick Snape <patricksnape at gmail.com>
wrote:

> Hi Will,
>
> Bug report submitted:
>
> http://www.vtk.org/Bug/view.php?id=15039
>
> I'm not sure if any of the other importers include this functionality
> (loading a texture from a url) but it would be a great addition I think. At
> the very least the documentation should be clear that appearance nodes are
> not actually supported. I wouldn't mind helping out but must admit that I
> am intimidated with the complex process of submitting patches back to VTK.
> Particularly the manner in which code reviews seem to be handled... I feel
> like I'm trying to submit a patch back to the linux kernel!
>
> Cheers,
>
> Patrick
>
> On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> Patrick-
>>
>> Can you enter a bug report? If not let me know and I'll do it. I've
>> contacted the original developer and I am "encouraging" him ;-) to take a
>> look...we'll see if he has the time.
>>
>> W
>>
>> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
>> wrote:
>>
>>> Hi, In the vtkVRMLImporter class documentation
>>> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
>>> mentions that appearance nodes are supported. However, from browsing the
>>> source code on Github, it appears that although they are recognised by the
>>> parser, they are not actually parsed. It would be great if textures could
>>> be parsed as well since the basic appearance nodes essentially just contain
>>> a url to the texture. Is this something that would be valued by the rest of
>>> the community? I'd love to drop the current VRML parser that I'm using but
>>> I can't sacrifice texture support.
>>> ------------------------------
>>> View this message in context: VRML Appearance Nodes
>>> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
>>> Sent from the VTK - Dev mailing list archive
>>> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>>>
>>> _______________________________________________
>>> 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
>>
>
>


-- 
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/20141008/41183d1a/attachment-0001.html>

From DLRdave at aol.com  Wed Oct  8 10:33:45 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 8 Oct 2014 10:33:45 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
 <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
 <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
Message-ID: <CAKME8fEvg1vc-U-Y7Hyu34cb91baAKU+aNeeYh9=7Bx=hhkR_g@mail.gmail.com>

Patrick,

If you have a patch, that includes testing the new code, and you're
willing to do some follow up work to address any test failures on the
VTK dashboard machines after the fact, I can help you get your patches
through the review process.

(But I can only help you get it through, I don't have the bandwidth to
do the work myself...)


Let me know,
David C.




On Wed, Oct 8, 2014 at 9:36 AM, Will Schroeder
<will.schroeder at kitware.com> wrote:
> I agree the process is tricky, and we are actively rethinking it.
>
> If you want to make an attempt, just focus on the affected class(es) and a
> test program. Either I or somebody much better at this than me will work
> with you to slip it in.
>
> So let me know if you are going to try, otherwise somebody, someday will try
> and resolve this :-)
>
> W
>
> On Wed, Oct 8, 2014 at 9:05 AM, Patrick Snape <patricksnape at gmail.com>
> wrote:
>>
>> Hi Will,
>>
>> Bug report submitted:
>>
>> http://www.vtk.org/Bug/view.php?id=15039
>>
>> I'm not sure if any of the other importers include this functionality
>> (loading a texture from a url) but it would be a great addition I think. At
>> the very least the documentation should be clear that appearance nodes are
>> not actually supported. I wouldn't mind helping out but must admit that I am
>> intimidated with the complex process of submitting patches back to VTK.
>> Particularly the manner in which code reviews seem to be handled... I feel
>> like I'm trying to submit a patch back to the linux kernel!
>>
>> Cheers,
>>
>> Patrick
>>
>> On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder
>> <will.schroeder at kitware.com> wrote:
>>>
>>> Patrick-
>>>
>>> Can you enter a bug report? If not let me know and I'll do it. I've
>>> contacted the original developer and I am "encouraging" him ;-) to take a
>>> look...we'll see if he has the time.
>>>
>>> W
>>>
>>> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
>>> wrote:
>>>>
>>>> Hi, In the vtkVRMLImporter class documentation it mentions that
>>>> appearance nodes are supported. However, from browsing the source code on
>>>> Github, it appears that although they are recognised by the parser, they are
>>>> not actually parsed. It would be great if textures could be parsed as well
>>>> since the basic appearance nodes essentially just contain a url to the
>>>> texture. Is this something that would be valued by the rest of the
>>>> community? I'd love to drop the current VRML parser that I'm using but I
>>>> can't sacrifice texture support.
>>>> ________________________________
>>>> View this message in context: VRML Appearance Nodes
>>>> Sent from the VTK - Dev mailing list archive at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> 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
>>
>>
>
>
>
> --
> 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
>
> _______________________________________________
> 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  Wed Oct  8 14:06:20 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 8 Oct 2014 12:06:20 -0600
Subject: [vtk-developers] A new internal Start method for interactors
Message-ID: <CANwS1=G5zAo1mRHsjxN1hueeHJW2=9uVPVWM4KkwoWzncAerHw@mail.gmail.com>

The interactors are core classes, so I'm bringing this to the list:

The Start() method for every single interactor class had a check for the
"HandleEventLoop" ivar, so I've moved the check into the interactor
base class, and added a new StartEventLoop() method that Start()
calls for the specialized classes to run the OS-specific event loop.

Gerrit patch is here:
http://review.source.kitware.com/#/c/17567/

Comments welcome.

 - David

From jeff.baumes at kitware.com  Wed Oct  8 15:13:26 2014
From: jeff.baumes at kitware.com (Jeff Baumes)
Date: Wed, 8 Oct 2014 15:13:26 -0400
Subject: [vtk-developers] [vtkusers] Creating the dual of a graph -
	planar face traversal - vtkBoostGraphAdapter
In-Reply-To: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
References: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
Message-ID: <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>

In your code, you are retrieving a vtkGraphIndexMap with:

property_map<vtkUndirectedGraph*, edge_index_t>::type e_index =
get(edge_index, in);

vtkGraphIndexMap is intended to be read-only and is already populated with
indices 0 through N-1, which are accessed with get(). It's actually an
identity map by index since indices are always in order, as you can see
here:

https://github.com/Kitware/VTK/blob/master/Infovis/BoostGraphAlgorithms/vtkBoostGraphAdapter.h#L1032-L1049

So I would suggest leaving out your initialization loop on lines 43-45.

Now, the remaining errors seem to require an operator[] on the
EdgeIndexMap, which is not currently implemented in vtkBoostGraphAdapter.h.
The needed code would be to replace the definition of vtkGraphPropertyMap
with something like this (not tested):

struct vtkGraphIndexMap; // forward declaration

template <>
struct property_traits<vtkGraphIndexMap>
{
  typedef vtkIdType value_type;
  typedef vtkIdType reference;
  typedef vtkIdType key_type;
  typedef readable_property_map_tag category;
};

struct vtkGraphIndexMap
{
  property_traits<vtkGraphIndexMap>::reference operator[](const
property_traits<vtkGraphIndexMap>::key_type& b)
    {
    return key;
    }
};


HTH,
Jeff

On Wed, Oct 8, 2014 at 2:12 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com>
wrote:

> Hi All,
>
> I'm trying to write an algorithm which creates the dual of a graph. To
> check whether the graph is planar or not I use the *Boyer-Myrvold
> planarity test* (Boost implementation) through the vtkBoostGraphAdapter.
> That works fine (only on vtkUndirectedGraph-s but that's OK for now).
> (http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/boyer_myrvold.html)
>
> To create the dual I need to traverse the faces of the planar graph for
> which I also have a Boost tool called the planar_face_traversal_visitor.
> (
> http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/planar_face_traversal.html
> )
> There's a guy, Aaron Windsor who implemented the appropriate visitor class
> that is able to create the dual of a graph in Boost.
> (https://github.com/aaw/boost_planar_graph_dual)
> That also works fine using only Boost but I'd like to adapt this feature
> as well using vtkBoostGraphAdapter.
>
> Here's my code: http://pastebin.com/g0Mtw6Ph
>
> These are my errors:
>
>    - *vtkDualGraph.cpp*:44:9: No matching function for call to 'put'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>    'iterator_property_map<typename vertex_vector_t::iterator,
>    boost::vtkGraphIndexMap>')
>
> It seems I cannot provide an appropriate EdgeIndexMap parameter to the
> put function in the 44th line. The vtkBoostGraphAdapter says that we can
> use VTK arrays as property maps, I tried that one as well, with no success.
> I've been dealing with this, reading the source code really deep and trying
> a couple of things in the past few days but I can't really figure out what
> the problem is. Is the vtkBoostGraphAdapter properly prepared for this
> kind of usage?
>
> Any kind of help appreciated!
>
> Thanks in advance!
>
> Szilard
>
> _______________________________________________
> 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/20141008/98e8bc6c/attachment.html>

From david.lonie at kitware.com  Wed Oct  8 15:52:13 2014
From: david.lonie at kitware.com (David Lonie)
Date: Wed, 8 Oct 2014 15:52:13 -0400
Subject: [vtk-developers] vtkTextActor rotation
Message-ID: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>

Hi Folks,

We've noticed some odd behavior while rotating 2D vtkTextActors. There are
two ways to do it:

vtkTextActor::SetOrientation(degrees), or
vtkTextProperty::SetOrientation(degrees)

These behave very differently, especially when alignment flags are used --
see the attached image for an example. The bottom two rows show this most
clearly.

Rotating the text property will rotate the text as it is being rendered
into the texture's buffer. This gives great antialiasing on the rotated
text, but gives bad alignment results, since the vtkTextActor is currently
aligning the entire texture to its position, rather than the text inside
the texture.

Rotating the actor gives the expected alignment behavior, but bad
antialiasing. This is because the text is rendered into the texture without
rotation, and then rotated afterwards.

Combining the two (top row) gives the worst of both cases.

I'd like to fix the text actor to align things "correctly" when the text
property is rotated. So my questions:

1) Is this behavior expected due to backwards compatibility?
2) If not, is this a good time to fix this? (e.g. are there any upcoming
releases I should hold off for?)

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/bad741f6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: textactor-rotation.png
Type: image/png
Size: 79114 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/bad741f6/attachment-0001.png>

From szilardszaloki at gmail.com  Wed Oct  8 17:27:25 2014
From: szilardszaloki at gmail.com (=?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?=)
Date: Wed, 8 Oct 2014 23:27:25 +0200
Subject: [vtk-developers] [vtkusers] Creating the dual of a graph -
	planar face traversal - vtkBoostGraphAdapter
In-Reply-To: <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>
References: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
 <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>
Message-ID: <CAEQ0100JxHyWZ+Wnix_42EJ1HCASbYsrg5Ecqz_R=o+aw-fsqA@mail.gmail.com>

Thank you for replying so fast!

I edited the vtkBoostGraphAdapter.h:

  struct vtkGraphIndexMap;


  template <>

  struct property_traits<vtkGraphIndexMap>

    {

    typedef vtkIdType value_type;

    typedef vtkIdType reference;

    typedef vtkIdType key_type;

    typedef readable_property_map_tag category;

    };



    struct vtkGraphIndexMap

    {

    property_traits<vtkGraphIndexMap>::reference operator[](const
property_traits<vtkGraphIndexMap>::key_type& key)

      {

        return key;

      }

    };


  inline property_traits<vtkGraphIndexMap>::reference

  get(

    vtkGraphIndexMap vtkNotUsed(arr),

    property_traits<vtkGraphIndexMap>::key_type key)

  {

    return key;

  }

I deleted the lines that fill the index map also. Unfortunately I still get
these errors:

   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
   vtkEdgeType, std::__1::less<long long>,
   std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
   boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > > &>'
   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
   vtkEdgeType, std::__1::less<long long>,
   std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
   boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > > &>'
   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > *>,
   boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
   long>, std::__1::allocator<long long> >, std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > &>'
   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > *>,
   boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
   long>, std::__1::allocator<long long> >, std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > &>'
   - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
   overloaded operator[] for type 'edge_to_face_map_t' (aka
   'iterator_property_map<typename vertex_vector_t::iterator,
   boost::vtkGraphIndexMap>')

It seems to me that there's no operator[] for the iterator_property_map. Am
I missing something?

Thanks again!

Szilard

2014-10-08 21:13 GMT+02:00 Jeff Baumes <jeff.baumes at kitware.com>:

> In your code, you are retrieving a vtkGraphIndexMap with:
>
> property_map<vtkUndirectedGraph*, edge_index_t>::type e_index =
> get(edge_index, in);
>
> vtkGraphIndexMap is intended to be read-only and is already populated with
> indices 0 through N-1, which are accessed with get(). It's actually an
> identity map by index since indices are always in order, as you can see
> here:
>
>
> https://github.com/Kitware/VTK/blob/master/Infovis/BoostGraphAlgorithms/vtkBoostGraphAdapter.h#L1032-L1049
>
> So I would suggest leaving out your initialization loop on lines 43-45.
>
> Now, the remaining errors seem to require an operator[] on the
> EdgeIndexMap, which is not currently implemented in vtkBoostGraphAdapter.h.
> The needed code would be to replace the definition of vtkGraphPropertyMap
> with something like this (not tested):
>
> struct vtkGraphIndexMap; // forward declaration
>
> template <>
> struct property_traits<vtkGraphIndexMap>
> {
>   typedef vtkIdType value_type;
>   typedef vtkIdType reference;
>   typedef vtkIdType key_type;
>   typedef readable_property_map_tag category;
> };
>
> struct vtkGraphIndexMap
> {
>   property_traits<vtkGraphIndexMap>::reference operator[](const
> property_traits<vtkGraphIndexMap>::key_type& b)
>     {
>     return key;
>     }
> };
>
>
> HTH,
> Jeff
>
> On Wed, Oct 8, 2014 at 2:12 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com>
> wrote:
>
>> Hi All,
>>
>> I'm trying to write an algorithm which creates the dual of a graph. To
>> check whether the graph is planar or not I use the *Boyer-Myrvold
>> planarity test* (Boost implementation) through the vtkBoostGraphAdapter.
>> That works fine (only on vtkUndirectedGraph-s but that's OK for now).
>> (http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/boyer_myrvold.html)
>>
>> To create the dual I need to traverse the faces of the planar graph for
>> which I also have a Boost tool called the planar_face_traversal_visitor.
>> (
>> http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/planar_face_traversal.html
>> )
>> There's a guy, Aaron Windsor who implemented the appropriate visitor
>> class that is able to create the dual of a graph in Boost.
>> (https://github.com/aaw/boost_planar_graph_dual)
>> That also works fine using only Boost but I'd like to adapt this feature
>> as well using vtkBoostGraphAdapter.
>>
>> Here's my code: http://pastebin.com/g0Mtw6Ph
>>
>> These are my errors:
>>
>>    - *vtkDualGraph.cpp*:44:9: No matching function for call to 'put'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>    vtkEdgeType, std::__1::less<long long>,
>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > > &>'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>    vtkEdgeType, std::__1::less<long long>,
>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > > &>'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>>    'iterator_property_map<typename vertex_vector_t::iterator,
>>    boost::vtkGraphIndexMap>')
>>
>> It seems I cannot provide an appropriate EdgeIndexMap parameter to the
>> put function in the 44th line. The vtkBoostGraphAdapter says that we can
>> use VTK arrays as property maps, I tried that one as well, with no success.
>> I've been dealing with this, reading the source code really deep and trying
>> a couple of things in the past few days but I can't really figure out what
>> the problem is. Is the vtkBoostGraphAdapter properly prepared for this
>> kind of usage?
>>
>> Any kind of help appreciated!
>>
>> Thanks in advance!
>>
>> Szilard
>>
>> _______________________________________________
>> 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/20141008/90e7d5f4/attachment.html>

From berk.geveci at kitware.com  Wed Oct  8 17:38:17 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 8 Oct 2014 17:38:17 -0400
Subject: [vtk-developers] ANNOUNCE: Kitware is hiring
Message-ID: <CAE32kpWTbDpA89vU2U53q=-C0HOro+8c2PU3HexjfraA-aPn7w@mail.gmail.com>

Hi folks,

We are looking to hire visualization developers to our Scientific Computing
team. If you are a talented visualization researcher and developer with
strong C++ skills, please consider applying.  You will join a great team
and work on many interesting and challenging technical problems - always
aiming to deliver robust and widely used software solutions.

For the full posting see:
http://tinyurl.com/l8sgvzw

JOB DESCRIPTION
Kitware is seeking to hire highly skilled Research and Development
Engineers (R&D Engineers) to join our Scientific Computing team and
contribute to our scientific and information visualization efforts.
Candidates will work to develop and improve leading visualization software
solutions.

Kitware collaborates on a multitude of basic and applied research and
development projects. Our collaborators include the top universities from
around the world, national research labs, medical device manufacturers, car
manufacturers, oil and gas companies, financial institutes, and many
others. The projects range from extending our open source C++ libraries and
applications, such as VTK, ParaView, and CMake, to developing proprietary
domain-specific vertical applications for a wide array of platforms
including web and mobile devices.

By joining our team you will participate in a dynamic work environment with
exceptionally talented and friendly coworkers who are committed to
high-quality development practices.  You will collaborate with esteemed
researchers from around the world by:

* Designing and developing scalable data analysis and visualization tools
for use by  researchers and professionals from various domains;

* Solving a wide array of problems ranging from developing distributed
memory parallel algorithms for data analysis, optimizing distributed
parallel codes to compiling and maintaining software on supercomputers.

* Designing and developing tools to improve scientific data analysis
workflows;

* Contributing to and supporting our dynamic open source communities built
around several of our open source tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/3ccf982a/attachment-0001.html>

From berk.geveci at kitware.com  Wed Oct  8 19:19:24 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 8 Oct 2014 19:19:24 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
 <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
 <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
Message-ID: <CAE32kpV9HhBgfhjHLVmx4_n96VCdxynO+uyiBhwcj1VokAzFkw@mail.gmail.com>

We are rethinking our processes. It is very likely that we will go to a
simple fork - pull-request based workflow. Our goal is to streamline the
review process and put more energy into shepherding contributions so we
don't drop them and discourage folks from contributing. It will take us a
few months to get everything in place.

Best,
-berk

On Wed, Oct 8, 2014 at 9:36 AM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> I agree the process is tricky, and we are actively rethinking it.
>
> If you want to make an attempt, just focus on the affected class(es) and a
> test program. Either I or somebody much better at this than me will work
> with you to slip it in.
>
> So let me know if you are going to try, otherwise somebody, someday will
> try and resolve this :-)
>
> W
>
> On Wed, Oct 8, 2014 at 9:05 AM, Patrick Snape <patricksnape at gmail.com>
> wrote:
>
>> Hi Will,
>>
>> Bug report submitted:
>>
>> http://www.vtk.org/Bug/view.php?id=15039
>>
>> I'm not sure if any of the other importers include this functionality
>> (loading a texture from a url) but it would be a great addition I think. At
>> the very least the documentation should be clear that appearance nodes are
>> not actually supported. I wouldn't mind helping out but must admit that I
>> am intimidated with the complex process of submitting patches back to VTK.
>> Particularly the manner in which code reviews seem to be handled... I feel
>> like I'm trying to submit a patch back to the linux kernel!
>>
>> Cheers,
>>
>> Patrick
>>
>> On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder <
>> will.schroeder at kitware.com> wrote:
>>
>>> Patrick-
>>>
>>> Can you enter a bug report? If not let me know and I'll do it. I've
>>> contacted the original developer and I am "encouraging" him ;-) to take a
>>> look...we'll see if he has the time.
>>>
>>> W
>>>
>>> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
>>> wrote:
>>>
>>>> Hi, In the vtkVRMLImporter class documentation
>>>> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
>>>> mentions that appearance nodes are supported. However, from browsing the
>>>> source code on Github, it appears that although they are recognised by the
>>>> parser, they are not actually parsed. It would be great if textures could
>>>> be parsed as well since the basic appearance nodes essentially just contain
>>>> a url to the texture. Is this something that would be valued by the rest of
>>>> the community? I'd love to drop the current VRML parser that I'm using but
>>>> I can't sacrifice texture support.
>>>> ------------------------------
>>>> View this message in context: VRML Appearance Nodes
>>>> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
>>>> Sent from the VTK - Dev mailing list archive
>>>> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>
>
> --
> 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
>
> _______________________________________________
> 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/20141008/38acdbb1/attachment.html>

From bill.lorensen at gmail.com  Thu Oct  9 07:10:35 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 07:10:35 -0400
Subject: [vtk-developers] Recent changes cause cmake failure
Message-ID: <CADZJ4hMpE8ah405TMb0RQSrbQAJuHXUaKvX728KoR_4-JJCRbw@mail.gmail.com>

Folks,

My Fedora build started to have a cmake error in the last couple of
days. I see the same error on the nightly dashboards:

CMake Error: Attempt to add a custom rule to output
"/home/kitware/Dashboards/My
Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
which already has a custom rule.
-- Configuring incomplete, errors occurred!

Bill


-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Thu Oct  9 08:44:15 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 08:44:15 -0400
Subject: [vtk-developers] Recent changes cause cmake failure
In-Reply-To: <CADZJ4hMpE8ah405TMb0RQSrbQAJuHXUaKvX728KoR_4-JJCRbw@mail.gmail.com>
References: <CADZJ4hMpE8ah405TMb0RQSrbQAJuHXUaKvX728KoR_4-JJCRbw@mail.gmail.com>
Message-ID: <CADZJ4hN4w+rKMNnJk-3B8j=SudKADac_-vetQoPAjr6NYP5m-A@mail.gmail.com>

vtkOpenGLGPUVolumeRayCastMapper exists in both VolumeOpenGL and VolumeOpenGLNew.


On Thu, Oct 9, 2014 at 7:10 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Folks,
>
> My Fedora build started to have a cmake error in the last couple of
> days. I see the same error on the nightly dashboards:
>
> CMake Error: Attempt to add a custom rule to output
> "/home/kitware/Dashboards/My
> Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
> which already has a custom rule.
> -- Configuring incomplete, errors occurred!
>
> Bill
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From david.gobbi at gmail.com  Thu Oct  9 09:07:48 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 9 Oct 2014 07:07:48 -0600
Subject: [vtk-developers] New volume rendering
Message-ID: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>

There seems to be some major changes occurring to VTK's volume
rendering.  Can the developers who are involved let the us (the
community) know what is going on?  Either by giving a summary on the
mailing list or by adding to the roadmap on the wiki?  Transparency,
folks!  Thanks in advance.

 - David

From aashish.chaudhary at kitware.com  Thu Oct  9 09:35:22 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 09:35:22 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
Message-ID: <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>

Hi David,

Absolutely! I was going to send an email today about it. In the past, it
was referred in the source article (
http://www.kitware.com/source/home/post/144). Also, for the upcoming issue,
we are working on a
source article targeting volume rendering in this series.

I will send an email out this afternoon.

- Aashish

On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> There seems to be some major changes occurring to VTK's volume
> rendering.  Can the developers who are involved let the us (the
> community) know what is going on?  Either by giving a summary on the
> mailing list or by adding to the roadmap on the wiki?  Transparency,
> folks!  Thanks in advance.
>
>  - 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
>
>


-- 



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

From david.gobbi at gmail.com  Thu Oct  9 09:55:49 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 9 Oct 2014 07:55:49 -0600
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
Message-ID: <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>

Thanks for the heads-up.

 - David

On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi David,
>
> Absolutely! I was going to send an email today about it. In the past, it was
> referred in the source article
> (http://www.kitware.com/source/home/post/144). Also, for the upcoming issue,
> we are working on a
> source article targeting volume rendering in this series.
>
> I will send an email out this afternoon.
>
> - Aashish
>
> On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> There seems to be some major changes occurring to VTK's volume
>> rendering.  Can the developers who are involved let the us (the
>> community) know what is going on?  Either by giving a summary on the
>> mailing list or by adding to the roadmap on the wiki?  Transparency,
>> folks!  Thanks in advance.
>>
>>  - David

From bill.lorensen at gmail.com  Thu Oct  9 10:02:31 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 10:02:31 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
Message-ID: <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>

Aashish,
I hope someone can address the CMake issue I reported. It is related to the
new volume rendering.

Bill
On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:

> Thanks for the heads-up.
>
>  - David
>
> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi David,
> >
> > Absolutely! I was going to send an email today about it. In the past, it
> was
> > referred in the source article
> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
> issue,
> > we are working on a
> > source article targeting volume rendering in this series.
> >
> > I will send an email out this afternoon.
> >
> > - Aashish
> >
> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> There seems to be some major changes occurring to VTK's volume
> >> rendering.  Can the developers who are involved let the us (the
> >> community) know what is going on?  Either by giving a summary on the
> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
> >> folks!  Thanks in advance.
> >>
> >>  - 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/20141009/382fde75/attachment.html>

From aashish.chaudhary at kitware.com  Thu Oct  9 10:04:07 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 10:04:07 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
Message-ID: <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>

Hi Bill,

Somehow I didn't see it (or came to know about it). My apologies. Can you
point me to the
report please?

Thanks,


On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Aashish,
> I hope someone can address the CMake issue I reported. It is related to
> the new volume rendering.
>
> Bill
> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>
>> Thanks for the heads-up.
>>
>>  - David
>>
>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>> <aashish.chaudhary at kitware.com> wrote:
>> > Hi David,
>> >
>> > Absolutely! I was going to send an email today about it. In the past,
>> it was
>> > referred in the source article
>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>> issue,
>> > we are working on a
>> > source article targeting volume rendering in this series.
>> >
>> > I will send an email out this afternoon.
>> >
>> > - Aashish
>> >
>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>> >>
>> >> There seems to be some major changes occurring to VTK's volume
>> >> rendering.  Can the developers who are involved let the us (the
>> >> community) know what is going on?  Either by giving a summary on the
>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>> >> folks!  Thanks in advance.
>> >>
>> >>  - 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
>>
>>


-- 



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

From bill.lorensen at gmail.com  Thu Oct  9 10:22:19 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 10:22:19 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
Message-ID: <CADZJ4hN4Rzv=fG5UgHePACtWbAfekkgooXMMnUbm4mjJ9ws0Yw@mail.gmail.com>

My Fedora build started to have a cmake error in the last couple of
days. I see the same error on some nightly dashboards. Occurs if
python wrapping is on.
http://open.cdash.org/viewConfigure.php?buildid=3522094


CMake Error: Attempt to add a custom rule to output
"/home/kitware/Dashboards/My
Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
which already has a custom rule.
-- Configuring incomplete, errors occurred!

Looks like vtkOpenGLGPUVolumeRayCastMapper exists in both VolumeOpenGL
and VolumeOpenGLNew.

On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi Bill,
>
> Somehow I didn't see it (or came to know about it). My apologies. Can you
> point me to the
> report please?
>
> Thanks,
>
>
> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> Aashish,
>> I hope someone can address the CMake issue I reported. It is related to
>> the new volume rendering.
>>
>> Bill
>>
>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>>
>>> Thanks for the heads-up.
>>>
>>>  - David
>>>
>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>>> <aashish.chaudhary at kitware.com> wrote:
>>> > Hi David,
>>> >
>>> > Absolutely! I was going to send an email today about it. In the past,
>>> > it was
>>> > referred in the source article
>>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>>> > issue,
>>> > we are working on a
>>> > source article targeting volume rendering in this series.
>>> >
>>> > I will send an email out this afternoon.
>>> >
>>> > - Aashish
>>> >
>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>>> > wrote:
>>> >>
>>> >> There seems to be some major changes occurring to VTK's volume
>>> >> rendering.  Can the developers who are involved let the us (the
>>> >> community) know what is going on?  Either by giving a summary on the
>>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>>> >> folks!  Thanks in advance.
>>> >>
>>> >>  - 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
>>>
>
>
>
> --
> | Aashish Chaudhary
> | Technical Leader
> | Kitware Inc.
> | http://www.kitware.com/company/team/chaudhary.html



-- 
Unpaid intern in BillsBasement at noware dot com

From aashish.chaudhary at kitware.com  Thu Oct  9 10:23:10 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 10:23:10 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CADZJ4hN4Rzv=fG5UgHePACtWbAfekkgooXMMnUbm4mjJ9ws0Yw@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CADZJ4hN4Rzv=fG5UgHePACtWbAfekkgooXMMnUbm4mjJ9ws0Yw@mail.gmail.com>
Message-ID: <CAEw35Z9B2c3ucMjTTsp6pOJGWLSfTWnTOp9sekDAhaNcfQXgPQ@mail.gmail.com>

Thanks for the pointers. We will fix it ASAP and report back.

- Aashish

On Thu, Oct 9, 2014 at 10:22 AM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> My Fedora build started to have a cmake error in the last couple of
> days. I see the same error on some nightly dashboards. Occurs if
> python wrapping is on.
> http://open.cdash.org/viewConfigure.php?buildid=3522094
>
>
> CMake Error: Attempt to add a custom rule to output
> "/home/kitware/Dashboards/My
>
> Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
> which already has a custom rule.
> -- Configuring incomplete, errors occurred!
>
> Looks like vtkOpenGLGPUVolumeRayCastMapper exists in both VolumeOpenGL
> and VolumeOpenGLNew.
>
> On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi Bill,
> >
> > Somehow I didn't see it (or came to know about it). My apologies. Can you
> > point me to the
> > report please?
> >
> > Thanks,
> >
> >
> > On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
> > wrote:
> >>
> >> Aashish,
> >> I hope someone can address the CMake issue I reported. It is related to
> >> the new volume rendering.
> >>
> >> Bill
> >>
> >> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
> >>>
> >>> Thanks for the heads-up.
> >>>
> >>>  - David
> >>>
> >>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
> >>> <aashish.chaudhary at kitware.com> wrote:
> >>> > Hi David,
> >>> >
> >>> > Absolutely! I was going to send an email today about it. In the past,
> >>> > it was
> >>> > referred in the source article
> >>> > (http://www.kitware.com/source/home/post/144). Also, for the
> upcoming
> >>> > issue,
> >>> > we are working on a
> >>> > source article targeting volume rendering in this series.
> >>> >
> >>> > I will send an email out this afternoon.
> >>> >
> >>> > - Aashish
> >>> >
> >>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> There seems to be some major changes occurring to VTK's volume
> >>> >> rendering.  Can the developers who are involved let the us (the
> >>> >> community) know what is going on?  Either by giving a summary on the
> >>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
> >>> >> folks!  Thanks in advance.
> >>> >>
> >>> >>  - 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
> >>>
> >
> >
> >
> > --
> > | Aashish Chaudhary
> > | Technical Leader
> > | Kitware Inc.
> > | http://www.kitware.com/company/team/chaudhary.html
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>



-- 



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

From DLRdave at aol.com  Thu Oct  9 10:37:47 2014
From: DLRdave at aol.com (David Cole)
Date: Thu, 9 Oct 2014 10:37:47 -0400
Subject: [vtk-developers] A new internal Start method for interactors
In-Reply-To: <CANwS1=G5zAo1mRHsjxN1hueeHJW2=9uVPVWM4KkwoWzncAerHw@mail.gmail.com>
References: <CANwS1=G5zAo1mRHsjxN1hueeHJW2=9uVPVWM4KkwoWzncAerHw@mail.gmail.com>
Message-ID: <CAKME8fHL42MHKRM3G-5CU2eM83qrpPR1OSDkqWMPfZKoG4mW+g@mail.gmail.com>

Makes perfect sense... let's push it!

On Wed, Oct 8, 2014 at 2:06 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> The interactors are core classes, so I'm bringing this to the list:
>
> The Start() method for every single interactor class had a check for the
> "HandleEventLoop" ivar, so I've moved the check into the interactor
> base class, and added a new StartEventLoop() method that Start()
> calls for the specialized classes to run the OS-specific event loop.
>
> Gerrit patch is here:
> http://review.source.kitware.com/#/c/17567/
>
> Comments welcome.
>
>  - 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 DLRdave at aol.com  Thu Oct  9 10:45:06 2014
From: DLRdave at aol.com (David Cole)
Date: Thu, 9 Oct 2014 10:45:06 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
Message-ID: <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>

I would say the text should look good and be legible when it's rendered...

Would anybody here really prefer perfect backwards compatibility
(including text illegibility) over better visualization...?

On Wed, Oct 8, 2014 at 3:52 PM, David Lonie <david.lonie at kitware.com> wrote:
> Hi Folks,
>
> We've noticed some odd behavior while rotating 2D vtkTextActors. There are
> two ways to do it:
>
> vtkTextActor::SetOrientation(degrees), or
> vtkTextProperty::SetOrientation(degrees)
>
> These behave very differently, especially when alignment flags are used --
> see the attached image for an example. The bottom two rows show this most
> clearly.
>
> Rotating the text property will rotate the text as it is being rendered into
> the texture's buffer. This gives great antialiasing on the rotated text, but
> gives bad alignment results, since the vtkTextActor is currently aligning
> the entire texture to its position, rather than the text inside the texture.
>
> Rotating the actor gives the expected alignment behavior, but bad
> antialiasing. This is because the text is rendered into the texture without
> rotation, and then rotated afterwards.
>
> Combining the two (top row) gives the worst of both cases.
>
> I'd like to fix the text actor to align things "correctly" when the text
> property is rotated. So my questions:
>
> 1) Is this behavior expected due to backwards compatibility?
> 2) If not, is this a good time to fix this? (e.g. are there any upcoming
> releases I should hold off for?)
>
> Thanks,
> Dave
>
> _______________________________________________
> 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 aashish.chaudhary at kitware.com  Thu Oct  9 10:54:10 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 10:54:10 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
Message-ID: <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>

Hi Bill,

We found the issue and will push a fix shortly. It was related to build
module all (and will show on only those dashboards which has it turned
on).  Said, that we will push a fix and monitor the dashboards.

Thanks,
Aashish


On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Hi Bill,
>
> Somehow I didn't see it (or came to know about it). My apologies. Can you
> point me to the
> report please?
>
> Thanks,
>
>
> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> Aashish,
>> I hope someone can address the CMake issue I reported. It is related to
>> the new volume rendering.
>>
>> Bill
>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>
>>> Thanks for the heads-up.
>>>
>>>  - David
>>>
>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>>> <aashish.chaudhary at kitware.com> wrote:
>>> > Hi David,
>>> >
>>> > Absolutely! I was going to send an email today about it. In the past,
>>> it was
>>> > referred in the source article
>>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>>> issue,
>>> > we are working on a
>>> > source article targeting volume rendering in this series.
>>> >
>>> > I will send an email out this afternoon.
>>> >
>>> > - Aashish
>>> >
>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>> >>
>>> >> There seems to be some major changes occurring to VTK's volume
>>> >> rendering.  Can the developers who are involved let the us (the
>>> >> community) know what is going on?  Either by giving a summary on the
>>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>>> >> folks!  Thanks in advance.
>>> >>
>>> >>  - 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
>>>
>>>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



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

From david.lonie at kitware.com  Thu Oct  9 10:54:39 2014
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 9 Oct 2014 10:54:39 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
Message-ID: <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>

On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:

> I would say the text should look good and be legible when it's rendered...
>
> Would anybody here really prefer perfect backwards compatibility
> (including text illegibility) over better visualization...?


I agree, and hope most others would, too! Besides legibility, position is
the issue that could affect developers -- if anyone is using
vtkTextProperty::SetOrientation to rotate their text, my changes will push
the text around into a new location, easily breaking their code...

I've had to add switches to filters that preserve buggy/"legacy" behavior
by default, so I like to check these things before making such changes --
and more importantly, this leaves a breadcrumb in the archive for people
trying to figure out why their code broke! ;-)

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

From dave.demarle at kitware.com  Thu Oct  9 11:04:47 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 9 Oct 2014 11:04:47 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
Message-ID: <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>

My crystal ball says we will start the next release in January and my vote
is quality over compatibility in this case.


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

On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
wrote:

> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>
>> I would say the text should look good and be legible when it's rendered...
>>
>> Would anybody here really prefer perfect backwards compatibility
>> (including text illegibility) over better visualization...?
>
>
> I agree, and hope most others would, too! Besides legibility, position is
> the issue that could affect developers -- if anyone is using
> vtkTextProperty::SetOrientation to rotate their text, my changes will push
> the text around into a new location, easily breaking their code...
>
> I've had to add switches to filters that preserve buggy/"legacy" behavior
> by default, so I like to check these things before making such changes --
> and more importantly, this leaves a breadcrumb in the archive for people
> trying to figure out why their code broke! ;-)
>
> Dave
>
>
> _______________________________________________
> 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/20141009/1e88b6c6/attachment-0001.html>

From aashish.chaudhary at kitware.com  Thu Oct  9 11:07:32 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 11:07:32 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
 <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
Message-ID: <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>

On Thu, Oct 9, 2014 at 11:04 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> My crystal ball says we will start the next release in January and my vote
> is quality over compatibility in this case.
>
+1

>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>>
>>> I would say the text should look good and be legible when it's
>>> rendered...
>>>
>>> Would anybody here really prefer perfect backwards compatibility
>>> (including text illegibility) over better visualization...?
>>
>>
>> I agree, and hope most others would, too! Besides legibility, position is
>> the issue that could affect developers -- if anyone is using
>> vtkTextProperty::SetOrientation to rotate their text, my changes will push
>> the text around into a new location, easily breaking their code...
>>
>> I've had to add switches to filters that preserve buggy/"legacy" behavior
>> by default, so I like to check these things before making such changes --
>> and more importantly, this leaves a breadcrumb in the archive for people
>> trying to figure out why their code broke! ;-)
>>
>> Dave
>>
>>
>> _______________________________________________
>> 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
>
>
>


-- 



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

From david.lonie at kitware.com  Thu Oct  9 11:10:12 2014
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 9 Oct 2014 11:10:12 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
 <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
 <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>
Message-ID: <CA+=e1osD_uXN89hmDG_TizM01sqpxu3=W9Lt8+dZvTtcOg+p+Q@mail.gmail.com>

That's what I wanted to hear :-D I'll start the patch.

On Thu, Oct 9, 2014 at 11:07 AM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> On Thu, Oct 9, 2014 at 11:04 AM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> My crystal ball says we will start the next release in January and my
>> vote is quality over compatibility in this case.
>>
> +1
>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
>> wrote:
>>
>>> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>>>
>>>> I would say the text should look good and be legible when it's
>>>> rendered...
>>>>
>>>> Would anybody here really prefer perfect backwards compatibility
>>>> (including text illegibility) over better visualization...?
>>>
>>>
>>> I agree, and hope most others would, too! Besides legibility, position
>>> is the issue that could affect developers -- if anyone is using
>>> vtkTextProperty::SetOrientation to rotate their text, my changes will push
>>> the text around into a new location, easily breaking their code...
>>>
>>> I've had to add switches to filters that preserve buggy/"legacy"
>>> behavior by default, so I like to check these things before making such
>>> changes -- and more importantly, this leaves a breadcrumb in the archive
>>> for people trying to figure out why their code broke! ;-)
>>>
>>> Dave
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141009/524efcf7/attachment.html>

From david.gobbi at gmail.com  Thu Oct  9 12:07:28 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 9 Oct 2014 10:07:28 -0600
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
Message-ID: <CANwS1=HanE95bcuywZ-EMd6hvDmr0bHu2dzvXv=mPTSMpG6tFA@mail.gmail.com>

This isn't directly related, but it seems to be a good time to plug
the vtkVolumeOutlineSource that can be used to annotate the bounds
of a volume, either with a wireframe or with translucent faces.
I've found it to be quite useful in my own volume interaction apps.
Images are attached (they're named after the corresponding .cxx
test files).

 - David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VolumeOutlineSourceClipped.png
Type: image/png
Size: 39142 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141009/946c8d97/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VolumeOutlineSource.png
Type: image/png
Size: 54651 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141009/946c8d97/attachment-0003.png>

From bill.lorensen at gmail.com  Thu Oct  9 12:40:24 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 12:40:24 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1osD_uXN89hmDG_TizM01sqpxu3=W9Lt8+dZvTtcOg+p+Q@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
 <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
 <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>
 <CA+=e1osD_uXN89hmDG_TizM01sqpxu3=W9Lt8+dZvTtcOg+p+Q@mail.gmail.com>
Message-ID: <CADZJ4hMxDBe7mXb83Th0qshYJaSjPe5L-XB9WN6uSU0PNT_UEg@mail.gmail.com>

+1


On Thu, Oct 9, 2014 at 11:10 AM, David Lonie <david.lonie at kitware.com> wrote:
> That's what I wanted to hear :-D I'll start the patch.
>
> On Thu, Oct 9, 2014 at 11:07 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
>>
>> On Thu, Oct 9, 2014 at 11:04 AM, David E DeMarle
>> <dave.demarle at kitware.com> wrote:
>>>
>>> My crystal ball says we will start the next release in January and my
>>> vote is quality over compatibility in this case.
>>
>> +1
>>>
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
>>> wrote:
>>>>
>>>> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>>>>>
>>>>> I would say the text should look good and be legible when it's
>>>>> rendered...
>>>>>
>>>>> Would anybody here really prefer perfect backwards compatibility
>>>>> (including text illegibility) over better visualization...?
>>>>
>>>>
>>>> I agree, and hope most others would, too! Besides legibility, position
>>>> is the issue that could affect developers -- if anyone is using
>>>> vtkTextProperty::SetOrientation to rotate their text, my changes will push
>>>> the text around into a new location, easily breaking their code...
>>>>
>>>> I've had to add switches to filters that preserve buggy/"legacy"
>>>> behavior by default, so I like to check these things before making such
>>>> changes -- and more importantly, this leaves a breadcrumb in the archive for
>>>> people trying to figure out why their code broke! ;-)
>>>>
>>>> Dave
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>>
>> --
>> | Aashish Chaudhary
>> | Technical Leader
>> | Kitware Inc.
>> | http://www.kitware.com/company/team/chaudhary.html
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>



-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Thu Oct  9 12:42:30 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 12:42:30 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
Message-ID: <CADZJ4hPm8gRyiszqApxjc9QG=WmKP+je2ognZ2oBJQ9iyC1Z4Q@mail.gmail.com>

Aashish,

Configures fine after the patch.

Thanks,

Bill

On Thu, Oct 9, 2014 at 10:54 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi Bill,
>
> We found the issue and will push a fix shortly. It was related to build
> module all (and will show on only those dashboards which has it turned on).
> Said, that we will push a fix and monitor the dashboards.
>
> Thanks,
> Aashish
>
>
> On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
>>
>> Hi Bill,
>>
>> Somehow I didn't see it (or came to know about it). My apologies. Can you
>> point me to the
>> report please?
>>
>> Thanks,
>>
>>
>> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>>>
>>> Aashish,
>>> I hope someone can address the CMake issue I reported. It is related to
>>> the new volume rendering.
>>>
>>> Bill
>>>
>>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>>>
>>>> Thanks for the heads-up.
>>>>
>>>>  - David
>>>>
>>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>>>> <aashish.chaudhary at kitware.com> wrote:
>>>> > Hi David,
>>>> >
>>>> > Absolutely! I was going to send an email today about it. In the past,
>>>> > it was
>>>> > referred in the source article
>>>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>>>> > issue,
>>>> > we are working on a
>>>> > source article targeting volume rendering in this series.
>>>> >
>>>> > I will send an email out this afternoon.
>>>> >
>>>> > - Aashish
>>>> >
>>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> There seems to be some major changes occurring to VTK's volume
>>>> >> rendering.  Can the developers who are involved let the us (the
>>>> >> community) know what is going on?  Either by giving a summary on the
>>>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>>>> >> folks!  Thanks in advance.
>>>> >>
>>>> >>  - 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
>>>>
>>
>>
>>
>> --
>> | Aashish Chaudhary
>> | Technical Leader
>> | Kitware Inc.
>> | http://www.kitware.com/company/team/chaudhary.html
>
>
>
>
> --
> | Aashish Chaudhary
> | Technical Leader
> | Kitware Inc.
> | http://www.kitware.com/company/team/chaudhary.html



-- 
Unpaid intern in BillsBasement at noware dot com

From aashish.chaudhary at kitware.com  Thu Oct  9 15:41:42 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 15:41:42 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CADZJ4hPm8gRyiszqApxjc9QG=WmKP+je2ognZ2oBJQ9iyC1Z4Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
 <CADZJ4hPm8gRyiszqApxjc9QG=WmKP+je2ognZ2oBJQ9iyC1Z4Q@mail.gmail.com>
Message-ID: <CAEw35Z-KmO+BbkzCqw7ioFr6LErkhrYthhgQFRnenLF8pa8m6g@mail.gmail.com>

Thanks for the update Bill. The other dashboard failure should be gone as
well now.

Thanks,
Aashish

On Thu, Oct 9, 2014 at 12:42 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Aashish,
>
> Configures fine after the patch.
>
> Thanks,
>
> Bill
>
> On Thu, Oct 9, 2014 at 10:54 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi Bill,
> >
> > We found the issue and will push a fix shortly. It was related to build
> > module all (and will show on only those dashboards which has it turned
> on).
> > Said, that we will push a fix and monitor the dashboards.
> >
> > Thanks,
> > Aashish
> >
> >
> > On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
> > <aashish.chaudhary at kitware.com> wrote:
> >>
> >> Hi Bill,
> >>
> >> Somehow I didn't see it (or came to know about it). My apologies. Can
> you
> >> point me to the
> >> report please?
> >>
> >> Thanks,
> >>
> >>
> >> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com
> >
> >> wrote:
> >>>
> >>> Aashish,
> >>> I hope someone can address the CMake issue I reported. It is related to
> >>> the new volume rendering.
> >>>
> >>> Bill
> >>>
> >>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
> >>>>
> >>>> Thanks for the heads-up.
> >>>>
> >>>>  - David
> >>>>
> >>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
> >>>> <aashish.chaudhary at kitware.com> wrote:
> >>>> > Hi David,
> >>>> >
> >>>> > Absolutely! I was going to send an email today about it. In the
> past,
> >>>> > it was
> >>>> > referred in the source article
> >>>> > (http://www.kitware.com/source/home/post/144). Also, for the
> upcoming
> >>>> > issue,
> >>>> > we are working on a
> >>>> > source article targeting volume rendering in this series.
> >>>> >
> >>>> > I will send an email out this afternoon.
> >>>> >
> >>>> > - Aashish
> >>>> >
> >>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> There seems to be some major changes occurring to VTK's volume
> >>>> >> rendering.  Can the developers who are involved let the us (the
> >>>> >> community) know what is going on?  Either by giving a summary on
> the
> >>>> >> mailing list or by adding to the roadmap on the wiki?
> Transparency,
> >>>> >> folks!  Thanks in advance.
> >>>> >>
> >>>> >>  - 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
> >>>>
> >>
> >>
> >>
> >> --
> >> | Aashish Chaudhary
> >> | Technical Leader
> >> | Kitware Inc.
> >> | http://www.kitware.com/company/team/chaudhary.html
> >
> >
> >
> >
> > --
> > | Aashish Chaudhary
> > | Technical Leader
> > | Kitware Inc.
> > | http://www.kitware.com/company/team/chaudhary.html
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>



-- 



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

From david.gobbi at gmail.com  Fri Oct 10 08:07:07 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 10 Oct 2014 06:07:07 -0600
Subject: [vtk-developers] Dashboard build failures
Message-ID: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>

The dashboard build failures last night were my fault, I removed a
cmake variable that was marked "deprecated" but which was still being
used in a couple places.  The gerrit builds and continuous builds
yesterday didn't show any errors, it was only the clean builds of the
nightlies that broke.

I've reverted the problem commit.

 - David

From aashish.chaudhary at kitware.com  Fri Oct 10 09:53:33 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Fri, 10 Oct 2014 09:53:33 -0400
Subject: [vtk-developers] Overhaul of the rendering subsystem in VTK: Volume
	Rendering update
Message-ID: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>

Friends,


As reported back in July, we are in the process of a major overhaul of the
rendering subsystem in VTK. The July article (
http://www.kitware.com/source/home/post/144) focused primarily on our
efforts to move to OpenGL 2.1+ to support faster polygonal rendering.  The
October Source will contain an article focused on our rewrite of the
vtkGPURayCastMapper class to provide a faster, more portable and more
easily extensible volume mapper for regular rectilinear grids.



VTK has a long history of volume rendering, and unfortunately that history
is evident in the large selection of classes available to render volumes.
Each of these methods was state-of-the-art at the time, but given VTK?s 20+
year history many of these methods are now quite obsolete. One goal of this
effort is to reduce the number of volume mappers to ideally just two - one
that supports accelerated rendering on graphics hardware and another that
works in parallel on the CPU. In addition, the vtkSmartVolumeMapper would
help application developers by automatically choosing between these
techniques based on system performance.



In this first phase, we have created a replacement for vtkGPURayCastMapper.
Currently, this is available for testing from the VTK git repository (in
master branch, disabled by default). General instructions on how to build
VTK from the source is available at this URL:
http://www.vtk.org/Wiki/VTK/Git*. *In order to build the new mapper, enable
the Module_vtkRenderingVolumeOpenGLNew module in cmake (via -D
*Module_vtkRenderingVolumeOpenGL=ON*), in ccmake or cmake-gui. Once built,
it can be used via vtkSmartVolumeMapper or used directly. Once sufficient
testing by the community has been performed, this class will replace the
old vtkGPURayCastMapper.  In addition, we are adding this new mapper to the
OpenGL2 module.  Availability of the new mapper with OpenGL2 module will
improve the management of textures in the mapper and eventually benefitting
both forms of rendering (geometry and volume) by sharing common code
between them.


Please contact us if you have any questions or encounter any issues.


Thanks,

-- 



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

From jatinparekh93 at gmail.com  Sun Oct 12 05:11:46 2014
From: jatinparekh93 at gmail.com (Jatin Parekh)
Date: Sun, 12 Oct 2014 14:41:46 +0530
Subject: [vtk-developers] vtkMultiThreader Class Error in Output
Message-ID: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>

Hi!
I have a simple code as shown below. I am passing the same parameter to a
function via a normal function call and another via the vtkMultiThreader
SpawnThread. However, I am unable to get the expected output.

*#include <iostream>*

*#include <vtkMultiThreader.h>*

*void *ThreadedFunction(void *data)*

*{*

*    std::cout << data << std::endl;*

*}*

*int main()*

*{*

*    vtkMultiThreader *threaded = vtkMultiThreader::New();*

*    void *x = (void *)1;*


 *    std::cout << "Non Threaded function call:" << std::endl;*

*    ThreadedFunction(x);*


 *    std::cout << "Now in threads:" << std::endl;*

*    threaded->SpawnThread(ThreadedFunction, x);*

*    return 0;*

*}*


If I understand correctly, the output for both, the threaded function
call as well as non threaded function call should be the same.

But it gives me the following output:

*Non Threaded function call:*

*0x1*

*Now in threads:*

*0x10a89d0*


SO, the non-threaded function call displays the correct value whereas
the MultiThreader call displays some different value.

I don't get the reason why the 2 function calls give different
outputs. Are they supposed to be different? If yes, then can someone
please explain why it is supposed to be so?

If no, then any ideas/hints on where I could possibly be making an error?


Thanks!

Jatin Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141012/79afa9d0/attachment.html>

From berk.geveci at kitware.com  Sun Oct 12 09:13:21 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Sun, 12 Oct 2014 09:13:21 -0400
Subject: [vtk-developers] vtkMultiThreader Class Error in Output
In-Reply-To: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>
References: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>
Message-ID: <CAE32kpXiyza+4oFoS8E=Lbg4boWD3etD9VJNiMEn-1jBOjFgjA@mail.gmail.com>

Check out the documentation of SetSingleMethod(), which reads:

> Set the SingleMethod to f() and the UserData field of the ThreadInfo that
is passed to it will be data.
> This method (and all the methods passed to SetMultipleMethod) must be of
type
> vtkThreadFunctionType and must take a single argument of type void *.

The argument passed to SetSingleMethod() is wrapped by the ThreadInfo
struct and passed to the method. Something like:

cout <<  ((vtkMultiThreader::ThreadInfo*)data)->UserData << endl

should do the trick. Also see:

http://www.vtk.org/doc/nightly/html/classvtkMultiThreader_1_1ThreadInfo.html

Best,
-berk

On Sun, Oct 12, 2014 at 5:11 AM, Jatin Parekh <jatinparekh93 at gmail.com>
wrote:

> Hi!
> I have a simple code as shown below. I am passing the same parameter to a
> function via a normal function call and another via the vtkMultiThreader
> SpawnThread. However, I am unable to get the expected output.
>
> *#include <iostream>*
>
> *#include <vtkMultiThreader.h>*
>
> *void *ThreadedFunction(void *data)*
>
> *{*
>
> *    std::cout << data << std::endl;*
>
> *}*
>
> *int main()*
>
> *{*
>
> *    vtkMultiThreader *threaded = vtkMultiThreader::New();*
>
> *    void *x = (void *)1;*
>
>
>  *    std::cout << "Non Threaded function call:" << std::endl;*
>
> *    ThreadedFunction(x);*
>
>
>  *    std::cout << "Now in threads:" << std::endl;*
>
> *    threaded->SpawnThread(ThreadedFunction, x);*
>
> *    return 0;*
>
> *}*
>
>
> If I understand correctly, the output for both, the threaded function call as well as non threaded function call should be the same.
>
> But it gives me the following output:
>
> *Non Threaded function call:*
>
> *0x1*
>
> *Now in threads:*
>
> *0x10a89d0*
>
>
> SO, the non-threaded function call displays the correct value whereas the MultiThreader call displays some different value.
>
> I don't get the reason why the 2 function calls give different outputs. Are they supposed to be different? If yes, then can someone please explain why it is supposed to be so?
>
> If no, then any ideas/hints on where I could possibly be making an error?
>
>
> Thanks!
>
> Jatin Parekh
>
>
> _______________________________________________
> 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/20141012/d67ad0ac/attachment.html>

From jatinparekh93 at gmail.com  Sun Oct 12 12:49:42 2014
From: jatinparekh93 at gmail.com (Jatin Parekh)
Date: Sun, 12 Oct 2014 22:19:42 +0530
Subject: [vtk-developers] vtkMultiThreader Class Error in Output
In-Reply-To: <CAE32kpXiyza+4oFoS8E=Lbg4boWD3etD9VJNiMEn-1jBOjFgjA@mail.gmail.com>
References: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>
 <CAE32kpXiyza+4oFoS8E=Lbg4boWD3etD9VJNiMEn-1jBOjFgjA@mail.gmail.com>
Message-ID: <CAA5y8x7ghq91wOBNnjDqb6vJfy9cExxFXjsDLJRu6Z5+h1iiZw@mail.gmail.com>

Hi Berk,
That worked.
Thanks for your quick reply!

Jatin Parekh

On Sun, Oct 12, 2014 at 6:43 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Check out the documentation of SetSingleMethod(), which reads:
>
> > Set the SingleMethod to f() and the UserData field of the ThreadInfo
> that is passed to it will be data.
> > This method (and all the methods passed to SetMultipleMethod) must be of
> type
> > vtkThreadFunctionType and must take a single argument of type void *.
>
> The argument passed to SetSingleMethod() is wrapped by the ThreadInfo
> struct and passed to the method. Something like:
>
> cout <<  ((vtkMultiThreader::ThreadInfo*)data)->UserData << endl
>
> should do the trick. Also see:
>
>
> http://www.vtk.org/doc/nightly/html/classvtkMultiThreader_1_1ThreadInfo.html
>
> Best,
> -berk
>
> On Sun, Oct 12, 2014 at 5:11 AM, Jatin Parekh <jatinparekh93 at gmail.com>
> wrote:
>
>> Hi!
>> I have a simple code as shown below. I am passing the same parameter to a
>> function via a normal function call and another via the vtkMultiThreader
>> SpawnThread. However, I am unable to get the expected output.
>>
>> *#include <iostream>*
>>
>> *#include <vtkMultiThreader.h>*
>>
>> *void *ThreadedFunction(void *data)*
>>
>> *{*
>>
>> *    std::cout << data << std::endl;*
>>
>> *}*
>>
>> *int main()*
>>
>> *{*
>>
>> *    vtkMultiThreader *threaded = vtkMultiThreader::New();*
>>
>> *    void *x = (void *)1;*
>>
>>
>>  *    std::cout << "Non Threaded function call:" << std::endl;*
>>
>> *    ThreadedFunction(x);*
>>
>>
>>  *    std::cout << "Now in threads:" << std::endl;*
>>
>> *    threaded->SpawnThread(ThreadedFunction, x);*
>>
>> *    return 0;*
>>
>> *}*
>>
>>
>> If I understand correctly, the output for both, the threaded function call as well as non threaded function call should be the same.
>>
>> But it gives me the following output:
>>
>> *Non Threaded function call:*
>>
>> *0x1*
>>
>> *Now in threads:*
>>
>> *0x10a89d0*
>>
>>
>> SO, the non-threaded function call displays the correct value whereas the MultiThreader call displays some different value.
>>
>> I don't get the reason why the 2 function calls give different outputs. Are they supposed to be different? If yes, then can someone please explain why it is supposed to be so?
>>
>> If no, then any ideas/hints on where I could possibly be making an error?
>>
>>
>> Thanks!
>>
>> Jatin Parekh
>>
>>
>> _______________________________________________
>> 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/20141012/858b8c82/attachment-0001.html>

From ben.boeckel at kitware.com  Mon Oct 13 08:33:53 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 13 Oct 2014 08:33:53 -0400
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
Message-ID: <20141013123353.GA26441@megas.kitwarein.com>

On Fri, Oct 10, 2014 at 06:07:07 -0600, David Gobbi wrote:
> The dashboard build failures last night were my fault, I removed a
> cmake variable that was marked "deprecated" but which was still being
> used in a couple places.  The gerrit builds and continuous builds
> yesterday didn't show any errors, it was only the clean builds of the
> nightlies that broke.
> 
> I've reverted the problem commit.

If it's really deprecated, we can use a variable_watch command on it to
warn when it is being used.

--Ben

From berk.geveci at kitware.com  Mon Oct 13 10:16:43 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Mon, 13 Oct 2014 10:16:43 -0400
Subject: [vtk-developers] [vtkusers] Missing update extent request in
	vtkExtractVOI?
In-Reply-To: <543AC335.2040607@student.hpi.uni-potsdam.de>
References: <54391E4E.8050907@student.hpi.uni-potsdam.de>
 <543AC335.2040607@student.hpi.uni-potsdam.de>
Message-ID: <CAE32kpUMhinzw_ZfJ6QpY-nwQ0LW0pq09f+tLVyZ1Rx6VPxJXQ@mail.gmail.com>

We completely rewrote vtkExtractVOI a few months ago and it doesn't look
like we didn't do a great job in fully evaluating it. I will spend some
quality time with it in the next few weeks.

Best,
-berk

On Sun, Oct 12, 2014 at 2:06 PM, Karsten Tausche <
karsten.tausche at student.hpi.uni-potsdam.de> wrote:

>  I just realized that calling SetUpdateExtentToWholeExtent() on a
> downstream algorithm (polyData in the example code) "fixes" this error.
>
>
> On 2014-10-11 14:10, Karsten Tausche wrote:
>
> Hi everyone,
>
> I tried to use vtkExtractVOI to decrease the resolution of a
> vtkImageData/vtkStructuredPoints data set. This works fine when I set the
> sample rate before I connect the filter to the pipeline. But changing the
> sample rate while rendering always results in an error like this:
>
> "ERROR: In
> ..\..\..\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx, line
> 857
> vtkCompositeDataPipeline (0000000005D6E1A0): The update extent specified
> in the information for output port 0 on algorithm
> vtkExtractVOI(0000000005D92710) is 0 10 0 10 0 0, which is outside the
> whole extent 0 9 0 10 0 0."
>
> This behavior also depends on the initial sample rate. With the defaults
> (1, 1, 1), the error message pops up after changing the rate, and the
> filter seems produce the expected result. When I set different initial
> values and increase them while rendering, I get the error message above,
> but the filter result seems correct. When decreasing the sample rate, I
> don't get an error, but the filter decreases the size of the rendered
> image.
>
> I'm using the current VTK master. I appended a small example the produces
> this error; it doesn't render any visible points but I didn't know how to
> enforce the required updates without adding the filter to a rendering
> pipeline.
>
> BTW the error also occurs with vtkStructuredGrid+vtkExtractGrid.
>
> Thanks,
> Karsten
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20141013/41c99200/attachment.html>

From david.gobbi at gmail.com  Mon Oct 13 12:35:14 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 13 Oct 2014 10:35:14 -0600
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <20141013123353.GA26441@megas.kitwarein.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
Message-ID: <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>

The problem is, when I add variable_watch(), it warns the next time
FindPythonLibs is called.  And the message it prints isn't informative.

On Mon, Oct 13, 2014 at 6:33 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Fri, Oct 10, 2014 at 06:07:07 -0600, David Gobbi wrote:
>> The dashboard build failures last night were my fault, I removed a
>> cmake variable that was marked "deprecated" but which was still being
>> used in a couple places.  The gerrit builds and continuous builds
>> yesterday didn't show any errors, it was only the clean builds of the
>> nightlies that broke.
>>
>> I've reverted the problem commit.
>
> If it's really deprecated, we can use a variable_watch command on it to
> warn when it is being used.
>
> --Ben

From ben.boeckel at kitware.com  Mon Oct 13 14:22:37 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 13 Oct 2014 14:22:37 -0400
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
 <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
Message-ID: <20141013182237.GA4640@megas.kitwarein.com>

On Mon, Oct 13, 2014 at 10:35:14 -0600, David Gobbi wrote:
> The problem is, when I add variable_watch(), it warns the next time
> FindPythonLibs is called.  And the message it prints isn't informative.

You could check the type of access being done to the variable. Setting
the watch after the find_package for PythonLibs should be sufficient
(unless we're calling it multiple times).

--Ben

From david.gobbi at gmail.com  Mon Oct 13 14:30:24 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 13 Oct 2014 12:30:24 -0600
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <20141013182237.GA4640@megas.kitwarein.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
 <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
 <20141013182237.GA4640@megas.kitwarein.com>
Message-ID: <CANwS1=GZ1sDU_OKOksXuw_5GFShyBE9nnshZwuEcxnS6REvJ=Q@mail.gmail.com>

On Mon, Oct 13, 2014 at 12:22 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Mon, Oct 13, 2014 at 10:35:14 -0600, David Gobbi wrote:
>> The problem is, when I add variable_watch(), it warns the next time
>> FindPythonLibs is called.  And the message it prints isn't informative.
>
> You could check the type of access being done to the variable. Setting
> the watch after the find_package for PythonLibs should be sufficient
> (unless we're calling it multiple times).

It is called multiple times.  It would be really convenient if cmake had a
variable_unwatch() function.

Or even better, the cmake set() function could have a DEPRECATED
flag so that any use of the variable outside that set() call would trigger
a deprecation warning.

 - David

From ben.boeckel at kitware.com  Mon Oct 13 15:03:18 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 13 Oct 2014 15:03:18 -0400
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <CANwS1=GZ1sDU_OKOksXuw_5GFShyBE9nnshZwuEcxnS6REvJ=Q@mail.gmail.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
 <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
 <20141013182237.GA4640@megas.kitwarein.com>
 <CANwS1=GZ1sDU_OKOksXuw_5GFShyBE9nnshZwuEcxnS6REvJ=Q@mail.gmail.com>
Message-ID: <20141013190318.GA28877@megas.kitwarein.com>

On Mon, Oct 13, 2014 at 12:30:24 -0600, David Gobbi wrote:
> It is called multiple times.  It would be really convenient if cmake had a
> variable_unwatch() function.

CMake can have multiple watches on a variable; how would you tell which
one to remove? I suppose a result variable could hold a token for it,
but then you have the problem of getting that variable passed around
(the cache defeating the purpose here; global properties not really
being the right thing either).

> Or even better, the cmake set() function could have a DEPRECATED
> flag so that any use of the variable outside that set() call would trigger
> a deprecation warning.

A bug report would be nice for this ;) .

--Ben

From david.gobbi at gmail.com  Tue Oct 14 07:41:39 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 14 Oct 2014 05:41:39 -0600
Subject: [vtk-developers] Obsolete PYTHON_INCLUDE_PATH in IBM xlc dashboard
Message-ID: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>

Hi Dave,

The xlC dashboard has cmake warnings since my changes to
FindPythonLibs.cmake yesterday.  Can you modify its build script
(aix_vtk_xlC.cmake according to the notes) by replacing the
deprecated PYTHON_INCLUDE_PATH variable at line 107 with
PYTHON_INCLUDE_DIR?  That will clear the warning.

Cheers,

 - David

From dave.demarle at kitware.com  Tue Oct 14 11:17:47 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 14 Oct 2014 11:17:47 -0400
Subject: [vtk-developers] Obsolete PYTHON_INCLUDE_PATH in IBM xlc
	dashboard
In-Reply-To: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>
References: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>
Message-ID: <CANjZAi--3zSTiVD7MCNd4AWFpimr7+MWDnQa1A_zSSMaCFRB3A@mail.gmail.com>

done
should see it take effect tomorrow



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

On Tue, Oct 14, 2014 at 7:41 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Dave,
>
> The xlC dashboard has cmake warnings since my changes to
> FindPythonLibs.cmake yesterday.  Can you modify its build script
> (aix_vtk_xlC.cmake according to the notes) by replacing the
> deprecated PYTHON_INCLUDE_PATH variable at line 107 with
> PYTHON_INCLUDE_DIR?  That will clear the warning.
>
> Cheers,
>
>  - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141014/75bad3df/attachment-0001.html>

From david.gobbi at gmail.com  Tue Oct 14 11:22:04 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 14 Oct 2014 09:22:04 -0600
Subject: [vtk-developers] Obsolete PYTHON_INCLUDE_PATH in IBM xlc
	dashboard
In-Reply-To: <CANjZAi--3zSTiVD7MCNd4AWFpimr7+MWDnQa1A_zSSMaCFRB3A@mail.gmail.com>
References: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>
 <CANjZAi--3zSTiVD7MCNd4AWFpimr7+MWDnQa1A_zSSMaCFRB3A@mail.gmail.com>
Message-ID: <CANwS1=GAMNPZOC=TXFrPxPEsZQhYaoaNrCPjNFCVrFnePBiK2Q@mail.gmail.com>

Thanks!

On Tue, Oct 14, 2014 at 9:17 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> done
> should see it take effect tomorrow
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Oct 14, 2014 at 7:41 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Hi Dave,
>>
>> The xlC dashboard has cmake warnings since my changes to
>> FindPythonLibs.cmake yesterday.  Can you modify its build script
>> (aix_vtk_xlC.cmake according to the notes) by replacing the
>> deprecated PYTHON_INCLUDE_PATH variable at line 107 with
>> PYTHON_INCLUDE_DIR?  That will clear the warning.
>>
>> Cheers,
>>
>>  - David
>
>

From jeff.baumes at kitware.com  Wed Oct 15 09:09:40 2014
From: jeff.baumes at kitware.com (Jeff Baumes)
Date: Wed, 15 Oct 2014 09:09:40 -0400
Subject: [vtk-developers] [vtkusers] Creating the dual of a graph -
 planar face traversal - vtkBoostGraphAdapter
In-Reply-To: <CAEQ0100JxHyWZ+Wnix_42EJ1HCASbYsrg5Ecqz_R=o+aw-fsqA@mail.gmail.com>
References: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
 <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>
 <CAEQ0100JxHyWZ+Wnix_42EJ1HCASbYsrg5Ecqz_R=o+aw-fsqA@mail.gmail.com>
Message-ID: <CANuLzQEE1svLFcyj32bHvaybH9b8h+52_mU66NnoREpgrbq5xA@mail.gmail.com>

This is starting to get beyond me. Here is what I could find. If you search
for iterator_property_map in

http://www.boost.org/doc/libs/1_55_0/boost/property_map/property_map.hpp

you can see that operator[] is clearly defined. I have a feeling this may
be a const issue, or perhaps the fact that the planar_dual algorithm
assumes you can do this:

edge_to_face[e] = current_face;

while iterator_property_map may produce a map that is read-only:

http://www.boost.org/doc/libs/1_37_0/libs/property_map/iterator_property_map.html
"... converts any random access iterator into a Lvalue Property Map ..."

http://www.boost.org/doc/libs/1_37_0/libs/property_map/LvaluePropertyMap.html
"... may be mutable or non-mutable ..."

Perhaps that points you in the right direction.

Jeff







On Wed, Oct 8, 2014 at 5:27 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com>
wrote:

> Thank you for replying so fast!
>
> I edited the vtkBoostGraphAdapter.h:
>
>   struct vtkGraphIndexMap;
>
>
>   template <>
>
>   struct property_traits<vtkGraphIndexMap>
>
>     {
>
>     typedef vtkIdType value_type;
>
>     typedef vtkIdType reference;
>
>     typedef vtkIdType key_type;
>
>     typedef readable_property_map_tag category;
>
>     };
>
>
>
>     struct vtkGraphIndexMap
>
>     {
>
>     property_traits<vtkGraphIndexMap>::reference operator[](const
> property_traits<vtkGraphIndexMap>::key_type& key)
>
>       {
>
>         return key;
>
>       }
>
>     };
>
>
>   inline property_traits<vtkGraphIndexMap>::reference
>
>   get(
>
>     vtkGraphIndexMap vtkNotUsed(arr),
>
>     property_traits<vtkGraphIndexMap>::key_type key)
>
>   {
>
>     return key;
>
>   }
>
> I deleted the lines that fill the index map also. Unfortunately I still
> get these errors:
>
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>    'iterator_property_map<typename vertex_vector_t::iterator,
>    boost::vtkGraphIndexMap>')
>
> It seems to me that there's no operator[] for the iterator_property_map.
> Am I missing something?
>
> Thanks again!
>
> Szilard
>
> 2014-10-08 21:13 GMT+02:00 Jeff Baumes <jeff.baumes at kitware.com>:
>
>> In your code, you are retrieving a vtkGraphIndexMap with:
>>
>> property_map<vtkUndirectedGraph*, edge_index_t>::type e_index =
>> get(edge_index, in);
>>
>> vtkGraphIndexMap is intended to be read-only and is already populated
>> with indices 0 through N-1, which are accessed with get(). It's actually an
>> identity map by index since indices are always in order, as you can see
>> here:
>>
>>
>> https://github.com/Kitware/VTK/blob/master/Infovis/BoostGraphAlgorithms/vtkBoostGraphAdapter.h#L1032-L1049
>>
>> So I would suggest leaving out your initialization loop on lines 43-45.
>>
>> Now, the remaining errors seem to require an operator[] on the
>> EdgeIndexMap, which is not currently implemented in vtkBoostGraphAdapter.h.
>> The needed code would be to replace the definition of vtkGraphPropertyMap
>> with something like this (not tested):
>>
>> struct vtkGraphIndexMap; // forward declaration
>>
>> template <>
>> struct property_traits<vtkGraphIndexMap>
>> {
>>   typedef vtkIdType value_type;
>>   typedef vtkIdType reference;
>>   typedef vtkIdType key_type;
>>   typedef readable_property_map_tag category;
>> };
>>
>> struct vtkGraphIndexMap
>> {
>>   property_traits<vtkGraphIndexMap>::reference operator[](const
>> property_traits<vtkGraphIndexMap>::key_type& b)
>>     {
>>     return key;
>>     }
>> };
>>
>>
>> HTH,
>> Jeff
>>
>> On Wed, Oct 8, 2014 at 2:12 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to write an algorithm which creates the dual of a graph. To
>>> check whether the graph is planar or not I use the *Boyer-Myrvold
>>> planarity test* (Boost implementation) through the vtkBoostGraphAdapter.
>>> That works fine (only on vtkUndirectedGraph-s but that's OK for now).
>>> (http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/boyer_myrvold.html)
>>>
>>> To create the dual I need to traverse the faces of the planar graph for
>>> which I also have a Boost tool called the planar_face_traversal_visitor.
>>> (
>>> http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/planar_face_traversal.html
>>> )
>>> There's a guy, Aaron Windsor who implemented the appropriate visitor
>>> class that is able to create the dual of a graph in Boost.
>>> (https://github.com/aaw/boost_planar_graph_dual)
>>> That also works fine using only Boost but I'd like to adapt this feature
>>> as well using vtkBoostGraphAdapter.
>>>
>>> Here's my code: http://pastebin.com/g0Mtw6Ph
>>>
>>> These are my errors:
>>>
>>>    - *vtkDualGraph.cpp*:44:9: No matching function for call to 'put'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>>    vtkEdgeType, std::__1::less<long long>,
>>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > > &>'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>>    vtkEdgeType, std::__1::less<long long>,
>>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > > &>'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>>>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>>>    'iterator_property_map<typename vertex_vector_t::iterator,
>>>    boost::vtkGraphIndexMap>')
>>>
>>> It seems I cannot provide an appropriate EdgeIndexMap parameter to the
>>> put function in the 44th line. The vtkBoostGraphAdapter says that we
>>> can use VTK arrays as property maps, I tried that one as well, with no
>>> success. I've been dealing with this, reading the source code really deep
>>> and trying a couple of things in the past few days but I can't really
>>> figure out what the problem is. Is the vtkBoostGraphAdapter properly
>>> prepared for this kind of usage?
>>>
>>> Any kind of help appreciated!
>>>
>>> Thanks in advance!
>>>
>>> Szilard
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20141015/1203dc3f/attachment-0001.html>

From david.lonie at kitware.com  Wed Oct 15 10:19:42 2014
From: david.lonie at kitware.com (David Lonie)
Date: Wed, 15 Oct 2014 10:19:42 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
Message-ID: <CA+=e1ovz5msMsH3gE8HoTbip-aR2xwC91t4U4CO8ahr9UFf08A@mail.gmail.com>

Hi all,

I finished up a patch to better handle rotated and aligned text, and
cleaned up a few other rough spots in the text rendering system.

Looking for reviewers:

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

Dave

On Wed, Oct 8, 2014 at 3:52 PM, David Lonie <david.lonie at kitware.com> wrote:

> Hi Folks,
>
> We've noticed some odd behavior while rotating 2D vtkTextActors. There are
> two ways to do it:
>
> vtkTextActor::SetOrientation(degrees), or
> vtkTextProperty::SetOrientation(degrees)
>
> These behave very differently, especially when alignment flags are used --
> see the attached image for an example. The bottom two rows show this most
> clearly.
>
> Rotating the text property will rotate the text as it is being rendered
> into the texture's buffer. This gives great antialiasing on the rotated
> text, but gives bad alignment results, since the vtkTextActor is currently
> aligning the entire texture to its position, rather than the text inside
> the texture.
>
> Rotating the actor gives the expected alignment behavior, but bad
> antialiasing. This is because the text is rendered into the texture without
> rotation, and then rotated afterwards.
>
> Combining the two (top row) gives the worst of both cases.
>
> I'd like to fix the text actor to align things "correctly" when the text
> property is rotated. So my questions:
>
> 1) Is this behavior expected due to backwards compatibility?
> 2) If not, is this a good time to fix this? (e.g. are there any upcoming
> releases I should hold off for?)
>
> Thanks,
> Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141015/b15172ea/attachment.html>

From tom.valleau at gmail.com  Wed Oct 15 15:15:24 2014
From: tom.valleau at gmail.com (filez41)
Date: Wed, 15 Oct 2014 12:15:24 -0700 (PDT)
Subject: [vtk-developers] VTK 5.6 to 6.1
Message-ID: <1413400524957-5729159.post@n5.nabble.com>

I'm converting some software from VTK 5.6 to 6.1, and the GetProducerPort()
function in vtkDataObject has been deprecated. 

I found details on the deprecated code and what to replace it with here:
http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_GetProducerPort

I want to confirm that I understand the change. 

Old Code:



New Code:


Is this the correct change?  The reason I'm unsure is because previously we
were using a vtkAlgorithmOutput as an intermediate step, and in 6.1 we have
to skip that completely?



--
View this message in context: http://vtk.1045678.n5.nabble.com/VTK-5-6-to-6-1-tp5729159.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From aashish.chaudhary at kitware.com  Thu Oct 16 12:31:37 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 16 Oct 2014 12:31:37 -0400
Subject: [vtk-developers] Overhaul of the rendering subsystem in VTK:
	Volume Rendering update
In-Reply-To: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>
References: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>
Message-ID: <CAEw35Z_tVedsuN_TMVyH8bnB-TdXvmX9k2Ua1FWHy0tZ2XJDwg@mail.gmail.com>

Friends,

As referred earlier, we are continuously working on improving the volume
rendering. As part of next set of delivery,  we are going to bring our
first OpenGL2 volume mapper to the OpenGL2 backend.
We have a branch that will get merged today and* it should only affect the
dashboards and code base switched to OpenGL2 backend*. We will continue to
improve the integration and will use and improve the
existing OpenGL2 backend code as necessary.

If you have any questions of concerns or if you find in any ways its
affecting your regular builds that uses OpenGL(default, and not OpenGL2)
 backend then let us know as soon as possible.

Thanks,


On Fri, Oct 10, 2014 at 9:53 AM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Friends,
>
>
> As reported back in July, we are in the process of a major overhaul of the
> rendering subsystem in VTK. The July article (
> http://www.kitware.com/source/home/post/144) focused primarily on our
> efforts to move to OpenGL 2.1+ to support faster polygonal rendering.  The
> October Source will contain an article focused on our rewrite of the
> vtkGPURayCastMapper class to provide a faster, more portable and more
> easily extensible volume mapper for regular rectilinear grids.
>
>
>
> VTK has a long history of volume rendering, and unfortunately that history
> is evident in the large selection of classes available to render volumes.
> Each of these methods was state-of-the-art at the time, but given VTK?s 20+
> year history many of these methods are now quite obsolete. One goal of this
> effort is to reduce the number of volume mappers to ideally just two - one
> that supports accelerated rendering on graphics hardware and another that
> works in parallel on the CPU. In addition, the vtkSmartVolumeMapper would
> help application developers by automatically choosing between these
> techniques based on system performance.
>
>
>
> In this first phase, we have created a replacement for
> vtkGPURayCastMapper. Currently, this is available for testing from the VTK
> git repository (in master branch, disabled by default). General
> instructions on how to build VTK from the source is available at this URL:
> http://www.vtk.org/Wiki/VTK/Git*. *In order to build the new mapper,
> enable the Module_vtkRenderingVolumeOpenGLNew module in cmake (via -D
> *Module_vtkRenderingVolumeOpenGL=ON*), in ccmake or cmake-gui. Once
> built, it can be used via vtkSmartVolumeMapper or used directly. Once
> sufficient testing by the community has been performed, this class will
> replace the old vtkGPURayCastMapper.  In addition, we are adding this new
> mapper to the OpenGL2 module.  Availability of the new mapper with OpenGL2
> module will improve the management of textures in the mapper and eventually
> benefitting both forms of rendering (geometry and volume) by sharing common
> code between them.
>
>
> Please contact us if you have any questions or encounter any issues.
>
>
> Thanks,
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



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

From david.lonie at kitware.com  Fri Oct 17 10:33:17 2014
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 17 Oct 2014 10:33:17 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1ovz5msMsH3gE8HoTbip-aR2xwC91t4U4CO8ahr9UFf08A@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CA+=e1ovz5msMsH3gE8HoTbip-aR2xwC91t4U4CO8ahr9UFf08A@mail.gmail.com>
Message-ID: <CA+=e1ov5Ro6DLDdOLUpaaBOK42_CONB4gR5wv0hefeOs+XqUsg@mail.gmail.com>

Update: Still looking for reviewers! =) There are a handful of patches, but
most of them are quite small...

On Wed, Oct 15, 2014 at 10:19 AM, David Lonie <david.lonie at kitware.com>
wrote:

> Hi all,
>
> I finished up a patch to better handle rotated and aligned text, and
> cleaned up a few other rough spots in the text rendering system.
>
> Looking for reviewers:
>
> http://review.source.kitware.com/#/t/4851/
>
> Dave
>
> On Wed, Oct 8, 2014 at 3:52 PM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> Hi Folks,
>>
>> We've noticed some odd behavior while rotating 2D vtkTextActors. There
>> are two ways to do it:
>>
>> vtkTextActor::SetOrientation(degrees), or
>> vtkTextProperty::SetOrientation(degrees)
>>
>> These behave very differently, especially when alignment flags are used
>> -- see the attached image for an example. The bottom two rows show this
>> most clearly.
>>
>> Rotating the text property will rotate the text as it is being rendered
>> into the texture's buffer. This gives great antialiasing on the rotated
>> text, but gives bad alignment results, since the vtkTextActor is currently
>> aligning the entire texture to its position, rather than the text inside
>> the texture.
>>
>> Rotating the actor gives the expected alignment behavior, but bad
>> antialiasing. This is because the text is rendered into the texture without
>> rotation, and then rotated afterwards.
>>
>> Combining the two (top row) gives the worst of both cases.
>>
>> I'd like to fix the text actor to align things "correctly" when the text
>> property is rotated. So my questions:
>>
>> 1) Is this behavior expected due to backwards compatibility?
>> 2) If not, is this a good time to fix this? (e.g. are there any upcoming
>> releases I should hold off for?)
>>
>> Thanks,
>> Dave
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141017/7b7df8f5/attachment.html>

From andreas.choi at gmail.com  Mon Oct 20 08:54:19 2014
From: andreas.choi at gmail.com (Jinhyeok Choi)
Date: Mon, 20 Oct 2014 21:54:19 +0900
Subject: [vtk-developers] Update only one renderer,
	(multiple renderers in a render window)
Message-ID: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>

Hi,

I have a question for redrawing a render window.
I only know the method to redraw is
vtkRenderWindow::render();
but it redraw all renderers at once.
I want to redraw only one renderer or only one actor.
Is it possible?
I divide viewport in the render window for each renderer.
One for volume rendering, and the other is something working space.
I want to redraw only working space, because volume rendering is heavy.

I looking forward your helps.

Best regards,
Jinhyeok Choi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141020/22d41ef9/attachment-0001.html>

From david.gobbi at gmail.com  Mon Oct 20 22:50:44 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 20 Oct 2014 20:50:44 -0600
Subject: [vtk-developers] Update only one renderer,
 (multiple renderers in a render window)
In-Reply-To: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>
References: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>
Message-ID: <CANwS1=GMrL0cdkVmm8mQfvJ6eh88jFMYMw0sP04fyPXHoJpuaQ@mail.gmail.com>

Hi Jinhyeok,

It should be possible to do this by calling the methods EraseOff()
and DrawOff() on all the renders that you don't want to re-render.

 - David

On Mon, Oct 20, 2014 at 6:54 AM, Jinhyeok Choi <andreas.choi at gmail.com> wrote:
> Hi,
>
> I have a question for redrawing a render window.
> I only know the method to redraw is
> vtkRenderWindow::render();
> but it redraw all renderers at once.
> I want to redraw only one renderer or only one actor.
> Is it possible?
> I divide viewport in the render window for each renderer.
> One for volume rendering, and the other is something working space.
> I want to redraw only working space, because volume rendering is heavy.
>
> I looking forward your helps.
>
> Best regards,
> Jinhyeok Choi

From andreas.choi at gmail.com  Mon Oct 20 23:56:21 2014
From: andreas.choi at gmail.com (Jinhyeok Choi)
Date: Tue, 21 Oct 2014 12:56:21 +0900
Subject: [vtk-developers] Update only one renderer,
 (multiple renderers in a render window)
In-Reply-To: <CANwS1=GMrL0cdkVmm8mQfvJ6eh88jFMYMw0sP04fyPXHoJpuaQ@mail.gmail.com>
References: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>
 <CANwS1=GMrL0cdkVmm8mQfvJ6eh88jFMYMw0sP04fyPXHoJpuaQ@mail.gmail.com>
Message-ID: <CAAq-dRAydWM+iLAnOmObuxE9PXX4xgE9OkKtVTWdQpzRp+VBUg@mail.gmail.com>

Great! David.

Thank you

It works good

m_pvtkRenderWindow->EraseOff();
m_pvtkRenderer1->DrawOff();
m_pvtkRenderWindow->Render();
m_pvtkRenderer1->DrawOn();
m_pvtkRenderWindow->EraseOn();



2014-10-21 11:50 GMT+09:00 David Gobbi <david.gobbi at gmail.com>:

> Hi Jinhyeok,
>
> It should be possible to do this by calling the methods EraseOff()
> and DrawOff() on all the renders that you don't want to re-render.
>
>  - David
>
> On Mon, Oct 20, 2014 at 6:54 AM, Jinhyeok Choi <andreas.choi at gmail.com>
> wrote:
> > Hi,
> >
> > I have a question for redrawing a render window.
> > I only know the method to redraw is
> > vtkRenderWindow::render();
> > but it redraw all renderers at once.
> > I want to redraw only one renderer or only one actor.
> > Is it possible?
> > I divide viewport in the render window for each renderer.
> > One for volume rendering, and the other is something working space.
> > I want to redraw only working space, because volume rendering is heavy.
> >
> > I looking forward your helps.
> >
> > Best regards,
> > Jinhyeok Choi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141021/159f9a38/attachment.html>

From qinshuo at hust.edu.cn  Tue Oct 21 00:41:18 2014
From: qinshuo at hust.edu.cn (=?GBK?B?x9jLtg==?=)
Date: Tue, 21 Oct 2014 12:41:18 +0800 (GMT+08:00)
Subject: [vtk-developers] Multi input image-to-image filter
Message-ID: <13ef232.469d.14931025a90.Coremail.qinshuo@hust.edu.cn>



I have a question on constructing a multiply input image-to-image filter based on class: vtkSimpleImagetoImgeFilter. In the previous release of vtk, the function AddInput(), GetInput() work well, while in the vtk5.10 there are a lot of problems. One of errors in GetInput() shows that:


"ERROR: In D:\VTK5.10\VTK5.10.1\Filtering\vtkDemandDrivenPipeline.cxx, line 737

vtkStreamingDemandDrivenPipeline (019A3AB0): Input port 0 of algorithm vtkpxAverageImages(019A2AE0) has 4 connections but is not repeatable.

"
The source I refered to is from " http://www.vtk.org/Wiki/VTK/Examples/Developers/MultipleInputConnections " 


There are examples for Multiple Input Connections or ports in "http://www.vtk.org/Wiki/VTK/Examples/Developers". And I get some solutions using function: RequestData().


 But they never use a vtkSimpleImagetoImageFilter. Does this class abandoned?











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

From tom.valleau at gmail.com  Wed Oct 22 12:53:23 2014
From: tom.valleau at gmail.com (filez41)
Date: Wed, 22 Oct 2014 09:53:23 -0700 (PDT)
Subject: [vtk-developers] Deprecated GetProducerPort
Message-ID: <1413996803157-5729205.post@n5.nabble.com>

Hey all, I posted this a week ago but in the email blast the code was left
out.  I'm hoping including the code and rephrasing the question will help. 

I'm upgrading some code from 5.6 to 6.1, and the GetProducerPort has been
deprecated.  We were using it in a few places, and I've been trying to
repeat the results we were getting with 5.6 following this deprecated code
guide:
http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_GetProducerPort
It hasn't been helpful because that's not how it was being used. 

Old Code: 
        vtkImageData * pImageData = aTexture->GetImageDataInput(0);
        vtkAlgorithmOutput * pAlgorithmOutput =
pImageData->GetProducerPort();
        vtkAlgorithm * pAlgorithm = pAlgorithmOutput->GetProducer()

New Code (*not working*): 
        vtkImageData * pImageData = aTexture->GetImageDataInput(0);
        vtkAlgorithm * pAlgorithm = vtkAlgorithm::New();
        pAlgorithm->SetInputDataObject(pImageData);

Reading the code more closely I can understand why the attempted code is not
working, but I can't figure out how to replicate the old results without
that function. 

The goal is to get a vtkAlgorithm out of a vtkDataObject (in this case a
vtkImageData).  Before we were getting the producer port (a
vtkAlgorithmOutput) and passing it's producer off to a vtkAlgorithm.  





--
View this message in context: http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From berk.geveci at kitware.com  Wed Oct 22 13:32:31 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 22 Oct 2014 13:32:31 -0400
Subject: [vtk-developers] Deprecated GetProducerPort
In-Reply-To: <1413996803157-5729205.post@n5.nabble.com>
References: <1413996803157-5729205.post@n5.nabble.com>
Message-ID: <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>

vtkAlgorithm* pAlgorithm = aTexture->GetInputAlgorithm();

-berk


On Wed, Oct 22, 2014 at 12:53 PM, filez41 <tom.valleau at gmail.com> wrote:

> Hey all, I posted this a week ago but in the email blast the code was left
> out.  I'm hoping including the code and rephrasing the question will help.
>
> I'm upgrading some code from 5.6 to 6.1, and the GetProducerPort has been
> deprecated.  We were using it in a few places, and I've been trying to
> repeat the results we were getting with 5.6 following this deprecated code
> guide:
> http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_GetProducerPort
> It hasn't been helpful because that's not how it was being used.
>
> Old Code:
>         vtkImageData * pImageData = aTexture->GetImageDataInput(0);
>         vtkAlgorithmOutput * pAlgorithmOutput =
> pImageData->GetProducerPort();
>         vtkAlgorithm * pAlgorithm = pAlgorithmOutput->GetProducer()
>
> New Code (*not working*):
>         vtkImageData * pImageData = aTexture->GetImageDataInput(0);
>         vtkAlgorithm * pAlgorithm = vtkAlgorithm::New();
>         pAlgorithm->SetInputDataObject(pImageData);
>
> Reading the code more closely I can understand why the attempted code is
> not
> working, but I can't figure out how to replicate the old results without
> that function.
>
> The goal is to get a vtkAlgorithm out of a vtkDataObject (in this case a
> vtkImageData).  Before we were getting the producer port (a
> vtkAlgorithmOutput) and passing it's producer off to a vtkAlgorithm.
>
>
>
>
>
> --
> View this message in context:
> http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141022/26135174/attachment.html>

From sean at rogue-research.com  Wed Oct 22 13:40:21 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 22 Oct 2014 13:40:21 -0400
Subject: [vtk-developers] New OS X 10.10 dashboards
Message-ID: <20141022174021.1657343733@mail.rogue-research.com>

Hi all,

I've had VTK dashboards running on OS X 10.10 for months now, but now that 10.10 is out and the NDA is over I've directed them to the public dashboard.

Can someone please mark these as expected:

 Mac10.10-clang-dbg-x86_64
	Mac10.10-clang-rel-x86_64

The only test failure is vtkChartsCoreCxx-TestChartXYZ:
<http://open.cdash.org/testDetails.php?test=289089209&build=3539483>

This hardware never ran an older OS so I don't know if it's a change between 10.9 or 10.10 or what...

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 dave.demarle at kitware.com  Wed Oct 22 13:46:44 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 22 Oct 2014 13:46:44 -0400
Subject: [vtk-developers] New OS X 10.10 dashboards
In-Reply-To: <20141022174021.1657343733@mail.rogue-research.com>
References: <20141022174021.1657343733@mail.rogue-research.com>
Message-ID: <CANjZAi8ydqETjvk3YJgAnzZcdc_7k_sfVWu7riuCR6CLM_vhNQ@mail.gmail.com>

done, thanks.

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

On Wed, Oct 22, 2014 at 1:40 PM, Sean McBride <sean at rogue-research.com>
wrote:

> Hi all,
>
> I've had VTK dashboards running on OS X 10.10 for months now, but now that
> 10.10 is out and the NDA is over I've directed them to the public dashboard.
>
> Can someone please mark these as expected:
>
>  Mac10.10-clang-dbg-x86_64
>         Mac10.10-clang-rel-x86_64
>
> The only test failure is vtkChartsCoreCxx-TestChartXYZ:
> <http://open.cdash.org/testDetails.php?test=289089209&build=3539483>
>
> This hardware never ran an older OS so I don't know if it's a change
> between 10.9 or 10.10 or what...
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141022/4837ac1c/attachment-0001.html>

From tom.valleau at gmail.com  Wed Oct 22 14:27:18 2014
From: tom.valleau at gmail.com (filez41)
Date: Wed, 22 Oct 2014 11:27:18 -0700 (PDT)
Subject: [vtk-developers] Deprecated GetProducerPort
In-Reply-To: <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>
References: <1413996803157-5729205.post@n5.nabble.com>
 <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>
Message-ID: <1414002438370-5729209.post@n5.nabble.com>

Oh my goodness, how did I not go back that far.  

It works, thank you!



--
View this message in context: http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205p5729209.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From aashish.chaudhary at kitware.com  Wed Oct 22 14:27:24 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Wed, 22 Oct 2014 14:27:24 -0400
Subject: [vtk-developers] Overhaul of the rendering subsystem in VTK:
	Volume Rendering update
In-Reply-To: <CAEw35Z_tVedsuN_TMVyH8bnB-TdXvmX9k2Ua1FWHy0tZ2XJDwg@mail.gmail.com>
References: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>
 <CAEw35Z_tVedsuN_TMVyH8bnB-TdXvmX9k2Ua1FWHy0tZ2XJDwg@mail.gmail.com>
Message-ID: <CAEw35Z_a5J-v7pdvcm8ShiTY=vRXg6fASimTKNNgARmkZxW5GA@mail.gmail.com>

Friends,

Some more good news on the rendering side of things. In the last few days,
we have worked on porting two more volume mappers to OpenGL2 (FixedPoint
and Bunyk) and this noon we merged that code into VTK master. This change
should not affect the code that is using the OpenGL (and not OpenGL2)
backend. We will keep an eye on the dashboards and fix any issue that we
may find. Also, we have updated the vtkSmartVolumeMapper to deal with the
OpenGL and OpenGL2 backend.

Please let us know if you have any questions or if you encounter any issues
in the current master related to this change.

Thanks,

On Thu, Oct 16, 2014 at 12:31 PM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Friends,
>
> As referred earlier, we are continuously working on improving the volume
> rendering. As part of next set of delivery,  we are going to bring our
> first OpenGL2 volume mapper to the OpenGL2 backend.
> We have a branch that will get merged today and* it should only affect
> the dashboards and code base switched to OpenGL2 backend*. We will
> continue to improve the integration and will use and improve the
> existing OpenGL2 backend code as necessary.
>
> If you have any questions of concerns or if you find in any ways its
> affecting your regular builds that uses OpenGL(default, and not OpenGL2)
>  backend then let us know as soon as possible.
>
> Thanks,
>
>
> On Fri, Oct 10, 2014 at 9:53 AM, Aashish Chaudhary <
> aashish.chaudhary at kitware.com> wrote:
>
>> Friends,
>>
>>
>> As reported back in July, we are in the process of a major overhaul of
>> the rendering subsystem in VTK. The July article (
>> http://www.kitware.com/source/home/post/144) focused primarily on our
>> efforts to move to OpenGL 2.1+ to support faster polygonal rendering.  The
>> October Source will contain an article focused on our rewrite of the
>> vtkGPURayCastMapper class to provide a faster, more portable and more
>> easily extensible volume mapper for regular rectilinear grids.
>>
>>
>>
>> VTK has a long history of volume rendering, and unfortunately that
>> history is evident in the large selection of classes available to render
>> volumes. Each of these methods was state-of-the-art at the time, but given
>> VTK?s 20+ year history many of these methods are now quite obsolete. One
>> goal of this effort is to reduce the number of volume mappers to ideally
>> just two - one that supports accelerated rendering on graphics hardware and
>> another that works in parallel on the CPU. In addition, the
>> vtkSmartVolumeMapper would help application developers by automatically
>> choosing between these techniques based on system performance.
>>
>>
>>
>> In this first phase, we have created a replacement for
>> vtkGPURayCastMapper. Currently, this is available for testing from the VTK
>> git repository (in master branch, disabled by default). General
>> instructions on how to build VTK from the source is available at this URL:
>> http://www.vtk.org/Wiki/VTK/Git*. *In order to build the new mapper,
>> enable the Module_vtkRenderingVolumeOpenGLNew module in cmake (via -D
>> *Module_vtkRenderingVolumeOpenGL=ON*), in ccmake or cmake-gui. Once
>> built, it can be used via vtkSmartVolumeMapper or used directly. Once
>> sufficient testing by the community has been performed, this class will
>> replace the old vtkGPURayCastMapper.  In addition, we are adding this new
>> mapper to the OpenGL2 module.  Availability of the new mapper with OpenGL2
>> module will improve the management of textures in the mapper and eventually
>> benefitting both forms of rendering (geometry and volume) by sharing common
>> code between them.
>>
>>
>> Please contact us if you have any questions or encounter any issues.
>>
>>
>> Thanks,
>>
>> --
>>
>>
>>
>> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.
>> *
>> *| http://www.kitware.com/company/team/chaudhary.html
>> <http://www.kitware.com/company/team/chaudhary.html>*
>>
>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



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

From DLRdave at aol.com  Wed Oct 22 14:47:20 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 22 Oct 2014 14:47:20 -0400
Subject: [vtk-developers] New OS X 10.10 dashboards
In-Reply-To: <20141022174021.1657343733@mail.rogue-research.com>
References: <20141022174021.1657343733@mail.rogue-research.com>
Message-ID: <CAKME8fGEK9_XNdVPU1XuiNYbEa53zrv64mZ8X+Vi7Z35G-it1A@mail.gmail.com>

I suspect a real VTK bug behind this test failure. I get *exactly* the
same test image on my Windows / Visual Studio 2012 dashboards:

http://open.cdash.org/testDetails.php?test=266709768&build=3539864

I suspect there is a rounding error or something like that, which is
causing two of the symbols to end up exactly on top of two of the
other symbols.


On Wed, Oct 22, 2014 at 1:40 PM, Sean McBride <sean at rogue-research.com> wrote:
> Hi all,
>
> I've had VTK dashboards running on OS X 10.10 for months now, but now that 10.10 is out and the NDA is over I've directed them to the public dashboard.
>
> Can someone please mark these as expected:
>
>  Mac10.10-clang-dbg-x86_64
>         Mac10.10-clang-rel-x86_64
>
> The only test failure is vtkChartsCoreCxx-TestChartXYZ:
> <http://open.cdash.org/testDetails.php?test=289089209&build=3539483>
>
> This hardware never ran an older OS so I don't know if it's a change between 10.9 or 10.10 or what...
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From berk.geveci at kitware.com  Wed Oct 22 15:44:41 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 22 Oct 2014 15:44:41 -0400
Subject: [vtk-developers] Deprecated GetProducerPort
In-Reply-To: <1414002438370-5729209.post@n5.nabble.com>
References: <1413996803157-5729205.post@n5.nabble.com>
 <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>
 <1414002438370-5729209.post@n5.nabble.com>
Message-ID: <CAE32kpXuFOBbCsx6gsy7bm8nWi3LWYg1uDRH=+fAAS86kjHr4Q@mail.gmail.com>

:-)

On Wed, Oct 22, 2014 at 2:27 PM, filez41 <tom.valleau at gmail.com> wrote:

> Oh my goodness, how did I not go back that far.
>
> It works, thank you!
>
>
>
> --
> View this message in context:
> http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205p5729209.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141022/e3d2eb44/attachment.html>

From cameron.palmer at ntnu.no  Thu Oct 23 16:02:27 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Thu, 23 Oct 2014 20:02:27 +0000
Subject: [vtk-developers] VES-Kiwi
Message-ID: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>

Hi, I?m interested in building VTK-VES-Kiwi stack on just about any platform although I prefer Mac, or Windows. It seems that the instructions provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the state of development on the project?

From aashish.chaudhary at kitware.com  Thu Oct 23 16:19:00 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 23 Oct 2014 16:19:00 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
Message-ID: <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>

Hi Cameron,

The reason we didn't update those documentation because we are working
towards getting VES and some Kiwi functionality in proper VTK in one way or
another. Probably others will provide more information on this matter, but
here is a to follow up on the recent development in that direction:

http://www.kitware.com/source/home/post/144

We will also have an upcoming article on Volume Rendering that should  work
on mobile devices as well (not tested).

*As far as the build goes, there are newer ways to build an Android project
but I personally have not tested that with CMake. There is a project inside
VTK master with OpenGL2 backend that you can try now.*

*Please don't consider this as an official reply on this matter* but I hope
that this provides some useful information.

- Aashish



On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

> Hi, I?m interested in building VTK-VES-Kiwi stack on just about any
> platform although I prefer Mac, or Windows. It seems that the instructions
> provided absolutely don?t work or are not consistently documented.
>
> So is Linux-Eclipse-Android really the only viable option? What is the
> state of development on the project?
> _______________________________________________
> 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
>
>


-- 



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

From cameron.palmer at ntnu.no  Fri Oct 24 02:35:12 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Fri, 24 Oct 2014 06:35:12 +0000
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
Message-ID: <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>

I understand the pain that is documentation, but even the links to the mailing list are broken. For example http://www.vtk.org/Wiki/VES the link at the bottom doesn?t take you where it says it will.

Impressive improvements in the article you shared. Those speed-ups are truly awesome.

Now let?s talk about me. Our university has built up a non-trivial amount of code around VES-Kiwi. What I?m trying to do is get to a place where I can debug and ultimately extend the codebase. Basically the work is increasingly Android-only, but I would prefer a first-class C++ debugging environment something the current Android tools don?t really have yet. That was why I was trying to get plain ol? VES to compile in iOS. Should I take this to mean that the VES codebase has been deprecated in favor of future development within VTK?

Thanks,

Cameron.



On 23. okt. 2014, at 22.19, Aashish Chaudhary <aashish.chaudhary at kitware.com<mailto:aashish.chaudhary at kitware.com>> wrote:

Hi Cameron,

The reason we didn't update those documentation because we are working towards getting VES and some Kiwi functionality in proper VTK in one way or another. Probably others will provide more information on this matter, but here is a to follow up on the recent development in that direction:

http://www.kitware.com/source/home/post/144

We will also have an upcoming article on Volume Rendering that should  work on mobile devices as well (not tested).

As far as the build goes, there are newer ways to build an Android project but I personally have not tested that with CMake. There is a project inside VTK master with OpenGL2 backend that you can try now.

Please don't consider this as an official reply on this matter but I hope that this provides some useful information.

- Aashish



On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <cameron.palmer at ntnu.no<mailto:cameron.palmer at ntnu.no>> wrote:
Hi, I?m interested in building VTK-VES-Kiwi stack on just about any platform although I prefer Mac, or Windows. It seems that the instructions provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the state of development on the project?
_______________________________________________
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




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

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

From aashish.chaudhary at kitware.com  Fri Oct 24 08:43:56 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Fri, 24 Oct 2014 08:43:56 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
Message-ID: <CAEw35Z8O0OjX7GcQ_3Eix7R-65uh3vzVCgsQo9ZDZF6t4QAJww@mail.gmail.com>

On Fri, Oct 24, 2014 at 2:35 AM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

>  I understand the pain that is documentation, but even the links to the
> mailing list are broken. For example http://www.vtk.org/Wiki/VES the link
> at the bottom doesn?t take you where it says it will.
>

I am sorry. Sure, we will fix that.

>
>  Impressive improvements in the article you shared. Those speed-ups are
> truly awesome.
>

Awesome.

>
>  Now let?s talk about me. Our university has built up a non-trivial
> amount of code around VES-Kiwi.
>

Nice. Any chance you can share a link on it?


> What I?m trying to do is get to a place where I can debug and ultimately
> extend the codebase. Basically the work is increasingly Android-only, but I
> would prefer a first-class C++ debugging environment something the current
> Android tools don?t really have yet. That was why I was trying to get plain
> ol? VES to compile in iOS. Should I take this to mean that the VES codebase
> has been deprecated in favor of future development within VTK?
>

Yes, however the application code; not so much. I will see if I can talk to
some of leading developers here and bring it up in our next meeting. It
would be great to catch up with you on a hangout sometime. Let me know and
I can probably give you more information then.

Thanks,
>
>  Cameron.
>
>
>
>  On 23. okt. 2014, at 22.19, Aashish Chaudhary <
> aashish.chaudhary at kitware.com> wrote:
>
>  Hi Cameron,
>
>  The reason we didn't update those documentation because we are working
> towards getting VES and some Kiwi functionality in proper VTK in one way or
> another. Probably others will provide more information on this matter, but
> here is a to follow up on the recent development in that direction:
>
>  http://www.kitware.com/source/home/post/144
>
>  We will also have an upcoming article on Volume Rendering that should
>  work on mobile devices as well (not tested).
>
>  *As far as the build goes, there are newer ways to build an Android
> project but I personally have not tested that with CMake. There is a
> project inside VTK master with OpenGL2 backend that you can try now.*
>
>  *Please don't consider this as an official reply on this matter* but I
> hope that this provides some useful information.
>
>  - Aashish
>
>
>
> On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <
> cameron.palmer at ntnu.no> wrote:
>
>> Hi, I?m interested in building VTK-VES-Kiwi stack on just about any
>> platform although I prefer Mac, or Windows. It seems that the instructions
>> provided absolutely don?t work or are not consistently documented.
>>
>> So is Linux-Eclipse-Android really the only viable option? What is the
>> state of development on the project?
>> _______________________________________________
>> 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
>>
>>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>
>
>


-- 



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

From ken.martin at kitware.com  Fri Oct 24 11:14:18 2014
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 24 Oct 2014 11:14:18 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
Message-ID: <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>

Some history is useful here. Back when VES started VTK rendering was based
on the old fixed pipeline which does not work with OpenGL ES. To render on
Android/iOS they needed to implement a rendering engine built on OpenGL ES.
Due to cost and time constraints they felt they did not have time to put
that codebase into VTK proper. Now we have the time and funding to work on
that. It is a work in progress and still at an early stage but VTK master
includes alpha support for compiling and rendering on Android and iOS. More
specifically:



-          VTK now includes toolchain files and a number of fixes so that
it can build on android and iOS

-          There are now Android and iOS example programs in the Examples
Directory in VTK, for the brave that is the place to start and there are
readme files

-          Very basic multitouch support has been added for android, iOS,
and Windows systems (OpenGL2 backend)

-          A rework of the rendering system to fit with OpenGl 2.1 which
gets us close to OpenGL ES 2.0 along with some nice performance
improvements.

-          An implementation of a shader based volume renderer we think
could work with OpenGL ES 3.0

-          More fixes needed to deal with OpenGL ES 2.0.

-          A testing dashboard to make sure it builds on iOS



There is a ***lot*** still to be done including



-          migrating some of the useful bits of code from VES to somewhere
in VTK

-          setting up android dashboards

-          setting up dashboard tests to verify the built code runs and
renders

-          converting some additional old OpenGL code to 2.1/ES standards

-          Creating more examples for both platforms

-          lots more testing

-          better build support for iOS, it is a bit clunky/limited

-          bunch of stuff I?m forgetting



So right now we are in the awkward time where we are moving to having most
the VES functionality in VTK, but it is not really ready for prime time
yet.  I believe maintenance of VES/Kiwi is limited but happening.



Hope that helps some!



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 *Cameron Lowell Palmer
*Sent:* Friday, October 24, 2014 2:35 AM
*To:* Aashish Chaudhary
*Cc:* vtk-developers at vtk.org
*Subject:* Re: [vtk-developers] VES-Kiwi



I understand the pain that is documentation, but even the links to the
mailing list are broken. For example http://www.vtk.org/Wiki/VES the link
at the bottom doesn?t take you where it says it will.



Impressive improvements in the article you shared. Those speed-ups are
truly awesome.



Now let?s talk about me. Our university has built up a non-trivial amount
of code around VES-Kiwi. What I?m trying to do is get to a place where I
can debug and ultimately extend the codebase. Basically the work is
increasingly Android-only, but I would prefer a first-class C++ debugging
environment something the current Android tools don?t really have yet. That
was why I was trying to get plain ol? VES to compile in iOS. Should I take
this to mean that the VES codebase has been deprecated in favor of future
development within VTK?



Thanks,



Cameron.







On 23. okt. 2014, at 22.19, Aashish Chaudhary <aashish.chaudhary at kitware.com>
wrote:



Hi Cameron,



The reason we didn't update those documentation because we are working
towards getting VES and some Kiwi functionality in proper VTK in one way or
another. Probably others will provide more information on this matter, but
here is a to follow up on the recent development in that direction:



http://www.kitware.com/source/home/post/144



We will also have an upcoming article on Volume Rendering that should  work
on mobile devices as well (not tested).



*As far as the build goes, there are newer ways to build an Android project
but I personally have not tested that with CMake. There is a project inside
VTK master with OpenGL2 backend that you can try now.*



*Please don't consider this as an official reply on this matter* but I hope
that this provides some useful information.



- Aashish







On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

Hi, I?m interested in building VTK-VES-Kiwi stack on just about any
platform although I prefer Mac, or Windows. It seems that the instructions
provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the
state of development on the project?
_______________________________________________
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





-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *

*| **http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141024/1f1e9eab/attachment.html>

From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.0.1414170159.14355.vtk-developers@vtk.org>

through on each platform that VTK runs on, and my gut feeling is that
adding version numbers will entail a fair bit of support-type work before
everyone is happy with the result.  Of course, I also feel that these sort
of 'tidiness' changes are something that VTK really needs.

Note, though, that the general rule for numbered libraries is that
no APIs are changed or deprecated unless the major version number of
the library changes.  Right now, no-one has taken on the role of 'API
watchdog' to ensure that this actually happens with VTK.  Maybe it's
something that could be added to the dashboard in the future, i.e. 
every time a major version of VTK is released a full snapshot of
API could be taken, and the API of the nightlies could be compared
on a daily basis and compatibility issues could be flagged.

> I am sorry if this is a FAQ or something but i couldnt find any
> information on this and need help.

You've been on the vtk-users mailing list for a couple years or so, you
know the FAQs about as well as anyone.  "Why don't VTK libraries have
version numbers" isn't one of them :)

 - David




From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.1.1414170159.14355.vtk-developers@vtk.org>

move a class to a new directory is put an entry in the CVS log of
where you moved the class from.  Then people can check the CVS log
for the deleted file in the old directory.  Not very convenient, but
I don't know of any other way.

 - David




From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.2.1414170161.14355.vtk-developers@vtk.org>

slowdown of VTK when used to render very large numbers (100's to 1000's) 
of actors. Last year, Bob O'Bara created a benchmark program that 
demonstrates this effect quantitatively. This program showed, for 
example, that rendering 1000 actors, each with one geometric primitive 
(we use a cube), runs 15 times slower than rendering a single actor with 
1000 geometric primitives. In both cases, the actual geometry rendered
by 
OpenGL, and the resulting images, are identical, yet the 1000-actor case 
takes 15X more time.

In the past few weeks, by making a number of modifications to VTK 3.2 
(using the May 11 nightly build) we have reduced this difference in 
rendering times from a factor of 15X to 2X. From this work, we have 
identified many issues that influence rendering speed for large numbers 
of actors, and would like to share our major findings with the 
developers. Our goal is to stimulate discussion and suggest possible 
enhancements to VTK that would benefit applications using large numbers 
of actors. Following is a list of the major issues we discovered and the 
code modifications we used to improve rendering speed. We very much
would 
like to see these improvements (or equivalent improvements based on 
suggestions of the "right way" to do some of these things) incorporated 
into VTK.


Issue 1: Numerous OpenGL "state" calls are made by the 
vtkOpenGLProperty::Render() method. At least 12 gl* calls are made for 
each actor every frame. (This was discussed in the vtk-developers list 
beginning May 16.) 

Action: We modified the vtkOpenGLProperty::Render() method to call new 
methods in the vtkOpenGLRenderer class instead of calling OpenGL 
directly. The new methods in vtkOpenGLRenderer store and check the last 
OpenGL settings for things such as material colors, shade model, and 
point size, and only make the gl* call if there's a change. 



Issue 2: glMultMatrixd() is called by vtkOpenGLActor::Render(). In the 
general case, this is needed to render the actor in the right place. In 
our applications, however, the actors nearly always have an identity 
matrix, making the glMultMatrixd() call unnecessary. (Mark Beall posted  
this to the developers list on May 17, but there were no responses.) 

Action: We added an "identity" flag to the vtkMatrix4x4 class to keep 
track of its state. It's not ideal since the matrix elements in this 
class are public (i.e., someone can change the matrix without the class, 
or our identity flag, knowing about it). We also, of course, modified
the 
vtkOpenGLActor::Render() method to check the matrix identity flag before 
calling glMultMatrixd(). 



Issue 3: The vtkFieldData::GetMTime() creates an iterator even when it 
contains no data. 

Action: We added a line to check if vtkFieldData::NumberOfArrays is 
greater than zero before instantiating a vtkFieldData::Iterator. 



Issue 4: The vtkActor::GetBounds() method traverses the VTK pipeline 
checking modified times ad infinitum. With 1000 actors and 120 frames, 
this means 120,000 calls to vtkActor::GetMTime(), 
vtkPolyDataMapper::GetMTime(), vtkDataObject::GetMTime(), and (our
friend 
from Issue 3) vtkFieldData::GetMTime(). 

Action: Since we almost never modify our actors (especially their 
geometry), we added a new protected member called "UpdateMode" to 
vtkProp3D. It is used to encode 1 of 3 possible modes: 

        VTK_UPDATE_DEFAULT 
        VTK_UPDATE_ONCE 
        VTK_UPDATE_DONE 

In VTK_UPDATE_DEFAULT mode, the actor behaves in VTK's normal way. The 
VTK_UPDATE_ONCE mode configures the actor to update one time only, and 
the VTK_UPDATE_DONE mode indicates not to perform the update, but
instead 
use the results from the previous/initial update. 



Issue 5: The vtkPolyDataMapper::RenderPiece() method traverses the VTK 
pipeline checking modification times. 

Action: Using our new vtkProp3D::UpdateMode, we bypassed nearly all of 
the logic in the RenderPiece method for VTK_UPDATE_DONE actors. 



Issue 6: The vtkPolyDataMapper::RenderPiece() method uses the vtkTimer
to 
measure rendering time. 

Action: In VTK_UPDATE_DONE mode, we bypass the timer, using the result 
computed in the previous/initial render. 



Issue 7: The vtkProp3D::GetMatrix() method traverses the VTK pipeline 
checking modification times, and then calls vtkMatrix4x4::DeepCopy(). 
Note that in this case the DeepCopy is just copying the matrix to
itself.

Action: Although we don't know why the DeepCopy call is in there, we
took 
it out and now return a pointer to the vtkProp3D::Matrix data member. 



Issue 8: The vtkOpenGLPolyDataMapper::Draw() method puts 3 OpenGL calls 
-- glDisable(GL_COLOR_MATERIAL), glDisable(GL_LIGHTING), and 
glEnable(GL_LIGHTING) -- in every display list. 

Action: For the GL_COLOR_MATERIAL case, we used the same workaround as
in 
Issue #1 -- adding new logic in the vtkOpenGLRenderer class to check the 
OpenGL setting before making the gl* call. The GL_LIGHTING calls were a 
bit more interesting. The Draw() method disables lighting for the case 
when there are no normals available for either lines or vertices (and 
then re-enables lighting for surfaces). We modified the code to simply 
check for the presence of lines or vertices first, before worrying about 
normals. Since our test case actors don't display lines or vertices,
this 
kept the GL_LIGHTING calls out of our display lists. 

Note: This suggest that, in order to get high throughput with large 
numbers of actors, you cannot mix and match lines and surfaces randomly, 
but will be much better off grouping actors with lines only and surfaces 
only. 



Issue 9: The vtkOpenGLActor::Render() calls glDepthMask(), to either set 
or clear it depending on the actor opacity. 

Action: We added Enable/Disable methods to the vtkRenderer that check
the 
OpenGL state before making the gl* call, in the same way that we
replaced 
the gl* calls in the vtkProperty::Render() method (Issue #1). 



Issue 10: The vtkRenderer::Render() method allocates and destroys 3 
arrays (PropArray, RayCastPropArray, and RenderIntoImagePropArray) each 
frame. 

Action: We took a shortcut and only destroy the arrays if an actor is 
added or removed between frames. In the general case, we'd suggest 
reallocating the arrays only if the number of actors has increased since 
the previous render. 



Issue 11: The vtkOpenGLPolyDataMapper::RenderPiece() method calls 
MakeCurrent(), which in turn calls glXGetCurrentContext(). This was 
discussed in the vtk-developers list beginning May 28. 

Action: Nothing was done for this one. 



Issue 12: The vtkRenderer::RenderOverlay() method ends up calling 
vtkProp::SafeDownCast() for each actor every frame. This is a bit 
frustrating since, as we understand it, none of our actors contribute 
anything to the RenderOverlay method. 

Action: Nothing has been done yet, but one suggestion is to let the 
application software enable/disable the RenderOverlay method. 
Another approach would be to change how the renderer stores the props. 
Right now everything is stored in one big list. It seems it would be 
possible to divide this up into multiple lists based on what the type of 
the prop is. For example, when the prop  is added to the renderer, the 
SafeDownCast call could be made and it could be put in the appropriate 
list. This would also solve Issue 13 below.


Issue 13: The vtkRenderer::Render() ends up calling 
vtkProp::SafeDownCast() for each actor every frame. 

Action: Nothing has been done yet. 



Issue 14: The vtkFrustumCoverageCuller::Cull() processes the same actor 
geometry every frame. Our actors have very simple geometry, and culling 
may not be of any benefit except when zoomed in very close. 

Action: Nothing has been done yet, but perhaps making culling an option, 
either on an actor-by-actor case or for the whole frame, is suggested. 



Issue 15: Using Quantify to measure CPU time, we have observed that the 
glFlush() calls for the 1000-actor case consume twice as many CPU cycles 
as the 1-actor case (82.1 million vs. 42.3 million). At the bottom of
the 
glFlush() call hierarchy is the system writev() function. For the
1-actor 
case, each call to writev takes an average of 338K cycles, whereas for 
the 1000-actor case, each call takes an average of 664K cycles. 

Action: Nothing has been done, other than to verify that the sequence of 
gl* calls and display lists are equivalent for both test cases.



John Tourtellott
-------------------------------------------------------
Simmetrix Inc.
1223 Peoples Avenue
Troy, NY  12180
voice:  518-276-2728
fax:    518-276-2944
mailto: johnt at simmetrix.com
-------------------------------------------------------




From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.3.1414170165.14355.vtk-developers@vtk.org>

data is going to be returned in the array.  So ideally all the Set methods
in VTK should use const arrays and furthermore the vtkSetVectorNMacro
should use const arrays.

I'm guessing that this non-const to const conversion hasn't happened
because 1) it would be a lot of work and 2) it would cause
incompatibilities for people who have their own classes that override
the Set() method with non-const array parameters.

Furthermore, I'm guessing that the Set-method array parameters in VTK
are not going to be converted to const any time in the forseeable
future (for the above to reasons).

So, instead I'm going to modify the wrappers so that all methods
with array parameters are wrapped even if the arrays are not const.
This behaviour doesn't make sense in all cases (it makes no sense
for e.g. GetPosition(float pos[3]) because both python and tcl
will ignore the values returned in the array) but it seems like
the easiest compromise.

Any opinions?

 - David



From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.4.1414170168.14355.vtk-developers@vtk.org>

 "
 About OPN

  Open Projects Net exists to provide an interactive environment for
  free software and open source projects and support groups. Our
  network is currently implemented using Internet Relay Chat
  (IRC). Our aim is to help improve the communication and coordination
  skills of our participants and to maintain a friendly, efficient
  environment for project coordination and technical support.

  ...  "

This is exactly what we wanted.  I also found that the channels on
openprojects.net are very nice and fairly on topic.  From their rules:

    Illegal activities, warez, porn, noticeably heavy mp3 trading,
    hax0r activity and various types of antisocial behavior are all
    off-topic on Open Projects Net and may result in your being barred
    from access. Please respect our rules.

This is the reason why I did not choose another irc server.

Anyway, how does a meeting on Tuesday morning 10AM US EST sound?

cheers,
prabhu


From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.5.1414170168.14355.vtk-developers@vtk.org>

Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.6.1414170169.14355.vtk-developers@vtk.org>

> In most interactor styles, both ways lead to some piece of code that will
> initially try to find the *renderer* in which the event occured,
> by calling
> vtkInteractorStyle::FindPokedRenderer(x, y) (or
> FindPokedCamera(), that I'm
> about to remove also, so stick to the first one :). This will set the
> internal attribute CurrentRenderer. I guess you should check for
> it, and if
> it is not set, then there is probably a problem in the style
> (depending on
> its state).

So, would it be sensible to add a method to the vtkImagePlaneWidget, and
possibly other widgets, called SetRenderer() so that the above pipeline is
easier to implement?  The CurrentRenderer could then be checked to see if it
is the renderer that contains the widget.

Dean






From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.7.1414170169.14355.vtk-developers@vtk.org>

where I can test it on several platforms at the same time and I am
usually more myself here.

So that this does not repeat, I am planning to change GetClassName to be
const, so that it is more consistent with whole OOP philosophy. This
should not break API and it might even make it more compatible. If
anybody has any suggestions, please send me an email.

One more time, I apologize to everybody and I promise I will be more
careful next time.

			Sincerely 

				Andy Cedilnik


On Mon, 2002-05-06 at 07:58, Lorensen, William E (Research) wrote:
> Andy,
> I see that you backed out the const change. I think it would have worked if you also changed the
> GetClassName in vtkObject.h.
> 
> Bill
> 
> -----Original Message-----
> From: Lorensen, William E (Research) 
> Sent: Monday, May 06, 2002 7:45 AM
> To: Lorensen, William E (Research); 'Andy Cedilnik'; vtk-developers
> Subject: RE: [vtk-developers] VTK problems, more clues
> 
> 
> Sure enough, look at the kulu.crd build and you'll see the cause...
> 
> -----Original Message-----
> From: Lorensen, William E (Research) 
> Sent: Monday, May 06, 2002 7:40 AM
> To: 'Andy Cedilnik'; vtk-developers
> Subject: [vtk-developers] VTK problems
> 
> 
> Andy,
> The system is in tough shape today. I suspect your GetClassName change is screwing up the tcl
> runtime. Looks like all the tcl tests failed.
> 
> Bill
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at public.kitware.com
> http://public.kitware.com/mailman/listinfo/vtk-developers
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at public.kitware.com
> http://public.kitware.com/mailman/listinfo/vtk-developers
> 




From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.8.1414170183.14355.vtk-developers@vtk.org>


From bogus@does.not.exist.com  Fri Oct 24 13:02:35 2014
From: bogus@does.not.exist.com ()
Date: Fri, 24 Oct 2014 17:02:35 -0000
Subject: No subject
Message-ID: <mailman.9.1414170183.14355.vtk-developers@vtk.org>

(http://www-linux.gsi.de/Software/gcc-2.95.2.html)

GCC 2.95 Caveats
...
Exception handling may not work with shared libraries, particularly on
alphas, hppas, rs6000/powerpc and mips based platforms. Exception handling
is known to work on x86 GNU/Linux platforms with shared libraries.


Back from to 2004:

I did some more googling and there still appears to be problems along these 
lines -- now with Solaris and later versions of gcc.

I have attached simple source code that reproduces the problem.  Please 
forgive references to my name (example filename: Hank.C) -- I didn't really 
every think I would be handing this out.

Best,
Hank
-- 
________________________________________________________________
 
Hank Childs
VisIt/MeshTV
Lawrence Livermore National Laboratory
 
phone: (925) 422-4035
email: childs3 at llnl.gov
--------------Boundary-00=_VNLZ2QTZILXO1SUUFHO0
Content-Type: application/x-tar;
  name="bug.tar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="bug.tar"

SGFuay5DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEwMDYwMCAAMDE1MDU2
IAAwMTUwNTYgADAwMDAwMDAwNTc1IDA3MzQwNjQyNjUwIDAxMjYzNwAgMAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMGNoaWxkcwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAY2hpbGRzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAgADAwMDAw
MCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj
aW5jbHVkZSA8aW9zdHJlYW0uaD4KI2luY2x1ZGUgPGV4Y2VwdGlvbj4KCnN0YXRpYyB2b2lkClRy
eUV4Y2VwdGlvbihjb25zdCBjaGFyICpzdHIpCnsKICAgIGNlcnIgPDwgIkFib3V0IHRvIGNoZWNr
IGV4Y2VwdGlvbiBoYW5kbGluZzogIiA8PCBzdHIgPDwgZW5kbDsKICAgIHRyeQogICAgewogICAg
ICAgIGNlcnIgPDwgIlRocm93aW5nLi4uIiA8PCBlbmRsOwogICAgICAgIHN0ZDo6ZXhjZXB0aW9u
IGU7CiAgICAgICAgdGhyb3cgZTsKICAgIH0KICAgIGNhdGNoICguLi4pCiAgICB7CiAgICAgICAg
Y2VyciA8PCAiQ2F1Z2h0IGl0LiIgPDwgZW5kbDsKICAgIH0KfQoKCgp2b2lkIFRocm93KHZvaWQp
CnsKICAgIFRyeUV4Y2VwdGlvbigiRnJvbSBUaHJvdyIpOwp9CgoAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhh
bmsuaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxMDA2MDAgADAxNTA1NiAA
MDE1MDU2IAAwMDAwMDAwMDAyNyAwNzM0MDY0MjU3MCAwMTI2NzUAIDAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBjaGlsZHMAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAGNoaWxkcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwIAAwMDAwMDAg
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgp2
b2lkICBUaHJvdyh2b2lkKTsKCgppbmNsdWRlIDxleGNlcHRpb24+CgpzdGF0aWMgdm9pZApUcnlF
eGNlcHRpb24oY29uc3QgY2hhciAqc3RyKQp7CiAgICBjZXJyIDw8ICJBYm91dCB0byBjaGVjayBl
eGNlcHRpb24gaGFuZGxpbmc6ICIgPDwgc3RyIDw8IGVuZGw7CiAgICB0cnkKICAgIHsKICAgICAg
ICBjZXJyIDw8ICJUaHJvd2luZy4uLiIgPDwgZW5kbDsKICAgICAgICBzdGQ6OmV4Y2VwdGlvbiBl
OwogICAgICAgIHRocm93IGU7CiAgICB9CiAgICBjYXRjaCAoLi4uKQogICAgewogICAgICAgIGNl
cnIgPDwgIkNhdWdodCBpdC4iIDw8IGVuZGw7CiAgICB9Cn0KCgoKdm9pZCBUaHJvdyh2b2lkKQp7
CiAgICBUcnlFeGNlcHRpb24oIkZyb20gVGhyb3ciKTsKfQoKAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABtYWlu
LkMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTAwNjAwIAAwMTUwNTYgADAx
NTA1NiAAMDAwMDAwMDAyNTUgMDczNDA2NDMwMzcgMDEyNjc1ACAwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwY2hpbGRzAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABjaGlsZHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMCAAMDAwMDAwIAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNpbmNs
dWRlIDxpb3N0cmVhbS5oPgojaW5jbHVkZSA8ZXhjZXB0aW9uPgoKI2luY2x1ZGUgPEhhbmsuaD4K
CmludCBtYWluKCkKewogICB0cnkKICAgewogICAgICAgVGhyb3coKTsKICAgfQogICBjYXRjaCAo
Li4uKQogICB7CiAgICAgICBjZXJyIDw8ICJDYXVnaHQgaXQhIiA8PCBlbmRsOwogICB9Cn0KICAg
Y2VyciA8PCAiVGhyb3dpbmcuLi4iIDw8IGVuZGw7CiAgICAgICAgc3RkOjpleGNlcHRpb24gZTsK
ICAgICAgICB0aHJvdyBlOwogICAgfQogICAgY2F0Y2ggKC4uLikKICAgIHsKICAgICAgICBjZXJy
IDw8ICJDYXVnaHQgaXQuIiA8PCBlbmRsOwogICAgfQp9CgoKCnZvaWQgVGhyb3codm9pZCkKewog
ICAgVHJ5RXhjZXB0aW9uKCJGcm9tIFRocm93Iik7Cn0KCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATWFrZWZp
bGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEwMDYwMCAAMDE1MDU2IAAwMTUw
NTYgADAwMDAwMDAwNDY0IDA3MzQwNjQyNzU0IDAxMzMxNAAgMAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMGNoaWxkcwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAY2hpbGRzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAgADAwMDAwMCAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQ0M9Zysr
CgpDRkxBR1M9LWcgLUkuCgpIQU5LU1JDPUhhbmsubwoKTUFJTlNSQz1tYWluLm8KCmFsbDogaGFu
a2xpYiBtYWluCgoKaGFua2xpYjogJChIQU5LU1JDKQoJJChDQykgJChDRkxBR1MpIC1zaGFyZWQg
LW8gbGliaGFuay5zbyAkKEhBTktTUkMpCglhciAtcmMgbGliaGFuay5hIGxpYmhhbmsuc287IHJt
IC1mIGxpYmhhbmsuc287IHJhbmxpYiBsaWJoYW5rLmEKCm1haW46ICQoTUFJTlNSQykKCSQoQ0Mp
ICQoQ0ZMQUdTKSAtbyAkQCAkKE1BSU5TUkMpIC1MLiAtbGhhbmsKCi5DLm86ICQ8CgkkKENDKSAk
KENGTEFHUykgLWMgJDwKCjwgZW5kbDsKICAgIH0KfQoKCgp2b2lkIFRocm93KHZvaWQpCnsKICAg
IFRyeUV4Y2VwdGlvbigiRnJvbSBUaHJvdyIpOwp9CgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

--------------Boundary-00=_VNLZ2QTZILXO1SUUFHO0--


From sean at rogue-research.com  Wed Oct  1 12:25:55 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 12:25:55 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
Message-ID: <20141001162555.1350523649@mail.rogue-research.com>

On Mon, 29 Sep 2014 16:40:41 -0400, Berk Geveci said:

>For Thursday's hackaton, we need a way of organizing and assigning bugs.

Speaking of which, is there any doc about using Mantis?  I couldn't find anything.  For example, the 'status' options are 'backlog/tabled/expired/closed', what do they mean?  (They are not Mantis' defaults.) What status should be set when a developer has claimed to fix something but the submitter has not yet verified?  Normally, with Mantis' defaults, one would set to 'resolved' then the submitter would set to 'closed'.

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 berk.geveci at kitware.com  Wed Oct  1 12:30:21 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 1 Oct 2014 12:30:21 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <20141001162555.1350523649@mail.rogue-research.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
Message-ID: <CAE32kpX9DSs_bjjNWBEVttcBbTt8i-DVh6+QH5ZH-80r7Tr62w@mail.gmail.com>

There is some sort of state machine in Mantis. Once you put a bug into the
backlog status, other states will appear. The idea was to prevent people
from jumping certain steps, I believe.

My feeling is that we are going to move away from Mantis in the nearish
future so I wouldn't spend a lot of time learning it.

-berk

On Wed, Oct 1, 2014 at 12:25 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Mon, 29 Sep 2014 16:40:41 -0400, Berk Geveci said:
>
> >For Thursday's hackaton, we need a way of organizing and assigning bugs.
>
> Speaking of which, is there any doc about using Mantis?  I couldn't find
> anything.  For example, the 'status' options are
> 'backlog/tabled/expired/closed', what do they mean?  (They are not Mantis'
> defaults.) What status should be set when a developer has claimed to fix
> something but the submitter has not yet verified?  Normally, with Mantis'
> defaults, one would set to 'resolved' then the submitter would set to
> 'closed'.
>
> 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/20141001/acab7608/attachment-0002.html>

From dave.demarle at kitware.com  Wed Oct  1 12:32:19 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 1 Oct 2014 12:32:19 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <20141001162555.1350523649@mail.rogue-research.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
Message-ID: <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>

see "the vtk software process"
https://docs.google.com/a/kitware.com/document/d/1nzinw-dR5JQRNi_gb8qwLL5PnkGMK2FETlQGLr10tZw/edit
section 6

"tabled" is something mantis keeps on putting in there for some reason I
don't understand. Think of it as backlog.



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

On Wed, Oct 1, 2014 at 12:25 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Mon, 29 Sep 2014 16:40:41 -0400, Berk Geveci said:
>
> >For Thursday's hackaton, we need a way of organizing and assigning bugs.
>
> Speaking of which, is there any doc about using Mantis?  I couldn't find
> anything.  For example, the 'status' options are
> 'backlog/tabled/expired/closed', what do they mean?  (They are not Mantis'
> defaults.) What status should be set when a developer has claimed to fix
> something but the submitter has not yet verified?  Normally, with Mantis'
> defaults, one would set to 'resolved' then the submitter would set to
> 'closed'.
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141001/b814f3a8/attachment-0002.html>

From berk.geveci at kitware.com  Wed Oct  1 12:36:56 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 1 Oct 2014 12:36:56 -0400
Subject: [vtk-developers] Gerrit update
Message-ID: <CAE32kpUVHmvRxW0fSXqz9s=iEnM1vv1QVf-o2h4Lh+ksxsgtsA@mail.gmail.com>

Hi folks,

We are working on updating our Gerrit instance (review.source.kitware.com).
When updated, there will no longer be topic support. As many of you know,
the topic support was based on a fork we created and those changes were not
accepted by Gerrit upstream. The decision was that, for security reasons,
we need to update to a newer version of Gerrit. Our changes are too hard to
port forward so we will drop the topic support.

At the same time, we are evaluating Gitlab for potentially migrating code
review, merge management and issue tracking. At this point, it is looking
very likely that we will migrate to Gitlab or Github. So the lack of topic
support will be temporary and we will most likely switch to using pull
requests with Github/Gitlab.

I will send an update once I hear more about when the Gerrit update is
coming. The Gitlab/Github update is a longer term thing. Probably several
months.

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

From sean at rogue-research.com  Wed Oct  1 14:19:28 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 14:19:28 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <CAE32kpX9DSs_bjjNWBEVttcBbTt8i-DVh6+QH5ZH-80r7Tr62w@mail.gmail.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
 <CAE32kpX9DSs_bjjNWBEVttcBbTt8i-DVh6+QH5ZH-80r7Tr62w@mail.gmail.com>
Message-ID: <20141001181928.1777698660@mail.rogue-research.com>

On Wed, 1 Oct 2014 12:30:21 -0400, Berk Geveci said:

>My feeling is that we are going to move away from Mantis in the nearish
>future so I wouldn't spend a lot of time learning it.

We use it here at work, so am actually quite familiar with it.  What are you thinking to switch to?

Cheers,

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




From sean at rogue-research.com  Wed Oct  1 14:19:45 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 14:19:45 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
 <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>
Message-ID: <20141001181945.1795144326@mail.rogue-research.com>

On Wed, 1 Oct 2014 12:32:19 -0400, David E DeMarle said:

>see "the vtk software process"
>https://docs.google.com/a/kitware.com/document/d/1nzinw-
>dR5JQRNi_gb8qwLL5PnkGMK2FETlQGLr10tZw/edit
>section 6
>
>"tabled" is something mantis keeps on putting in there for some reason I
>don't understand. Think of it as backlog.

OK, so it says one should set fixed bugs to 'closed'.  Then the submitter reopens if he disagrees I guess?  Are you sure submitters can reopen?  From what I've seen of Mantis, once set to 'closed' you need higher permission to reopen or even comment...

That doc also says "When a new bug report is made, mantis sends it off to the developer?s mailing list".  That doesn't seem to be true... perhaps it should be...?

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 dave.demarle at kitware.com  Wed Oct  1 15:11:06 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 1 Oct 2014 15:11:06 -0400
Subject: [vtk-developers] VTK bug tracker hackaton logistics
In-Reply-To: <20141001181945.1795144326@mail.rogue-research.com>
References: <CAE32kpXh2kTZ7Kp7TYqDyp1RXEzQ=iWCAi8j9ivg679bcOog1w@mail.gmail.com>
 <20141001162555.1350523649@mail.rogue-research.com>
 <CANjZAi80NLJZxaEJJgfPivyin2xwvBqer8wbpw6xezvufrpLkQ@mail.gmail.com>
 <20141001181945.1795144326@mail.rogue-research.com>
Message-ID: <CANjZAi-mezQDMN61yQAaRArC46pMMwuxomW26pY+47XKr4HscA@mail.gmail.com>

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

On Wed, Oct 1, 2014 at 2:19 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Wed, 1 Oct 2014 12:32:19 -0400, David E DeMarle said:
>
> >see "the vtk software process"
> >https://docs.google.com/a/kitware.com/document/d/1nzinw-
> >dR5JQRNi_gb8qwLL5PnkGMK2FETlQGLr10tZw/edit
> >section 6
> >
> >"tabled" is something mantis keeps on putting in there for some reason I
> >don't understand. Think of it as backlog.
>
> OK, so it says one should set fixed bugs to 'closed'.  Then the submitter
> reopens if he disagrees I guess?  Are you sure submitters can reopen?  From
> what I've seen of Mantis, once set to 'closed' you need higher permission
> to reopen or even comment...
>
>
That is a configuration setting, just like the workflow states. On VTK,
developers, managers and the administrator can reopen bugs. I'll add
reporter and viewer as well.


> That doc also says "When a new bug report is made, mantis sends it off to
> the developer?s mailing list".  That doesn't seem to be true... perhaps it
> should be...?
>

Still seems to be coming through:

http://markmail.org/search/vtk-developers+list:org%2Evtk%2Evtk-developers+mantis+from:%22Mantis+Bug+Tracker%22+order:date-backward

Now the part about "the release manager reads all newly submitted bugs and
asks developers who are familiar with the area of VTK that the bug relates
to to do a cursory review" hasn't been working so well.



>
> 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/20141001/49067729/attachment-0002.html>

From bill.lorensen at gmail.com  Wed Oct  1 15:44:52 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 1 Oct 2014 15:44:52 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
Message-ID: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>

Folks,

I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my part?

Bill


From sean at rogue-research.com  Wed Oct  1 16:07:24 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 1 Oct 2014 16:07:24 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
Message-ID: <20141001200724.1865052938@mail.rogue-research.com>

On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:

>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my part?

Likewise.  David, maybe you broke something changing the 'reopening' permissions?

Cheers,

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




From bill.lorensen at gmail.com  Wed Oct  1 16:09:20 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 1 Oct 2014 16:09:20 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <20141001200724.1865052938@mail.rogue-research.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
 <20141001200724.1865052938@mail.rogue-research.com>
Message-ID: <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>

bill.lorensen

On Wed, Oct 1, 2014 at 4:07 PM, Sean McBride <sean at rogue-research.com> wrote:
> On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:
>
>>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my part?
>
> Likewise.  David, maybe you broke something changing the 'reopening' permissions?
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>



-- 
Unpaid intern in BillsBasement at noware dot com


From dave.demarle at kitware.com  Wed Oct  1 16:37:15 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 1 Oct 2014 16:37:15 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
 <20141001200724.1865052938@mail.rogue-research.com>
 <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>
Message-ID: <CANjZAi9Gz-YHU3ZsHF-nxUjjdCmYeQk=3REMD5t1bmk0PDk-7A@mail.gmail.com>

Should be fixed now.
Try again please.

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

On Wed, Oct 1, 2014 at 4:09 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> bill.lorensen
>
> On Wed, Oct 1, 2014 at 4:07 PM, Sean McBride <sean at rogue-research.com>
> wrote:
> > On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:
> >
> >>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my
> part?
> >
> > Likewise.  David, maybe you broke something changing the 'reopening'
> permissions?
> >
> > Cheers,
> >
> > --
> > ____________________________________________________________
> > Sean McBride, B. Eng                 sean at rogue-research.com
> > Rogue Research                        www.rogue-research.com
> > Mac Software Developer              Montr?al, Qu?bec, Canada
> >
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> 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/20141001/fe551673/attachment-0002.html>

From bill.lorensen at gmail.com  Wed Oct  1 16:46:14 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 1 Oct 2014 16:46:14 -0400
Subject: [vtk-developers] Has something changed in the bug tracker
In-Reply-To: <CANjZAi9Gz-YHU3ZsHF-nxUjjdCmYeQk=3REMD5t1bmk0PDk-7A@mail.gmail.com>
References: <CADZJ4hPxk1Qh+qfs9or5pSG-zwzJ4DFqzu1NDnbLQZr5AfAHrQ@mail.gmail.com>
 <20141001200724.1865052938@mail.rogue-research.com>
 <CADZJ4hNMRgO1961yH-Dz83JtYO6UJXprLRZO3H6ch5_G=axhVg@mail.gmail.com>
 <CANjZAi9Gz-YHU3ZsHF-nxUjjdCmYeQk=3REMD5t1bmk0PDk-7A@mail.gmail.com>
Message-ID: <CADZJ4hOgQdKC=yuZ6d_hyL9e5A6W3hbLjB6_epGOyEZKOHhMgQ@mail.gmail.com>

It's OK now. Thanks!


On Wed, Oct 1, 2014 at 4:37 PM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> Should be fixed now.
> Try again please.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Wed, Oct 1, 2014 at 4:09 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> bill.lorensen
>>
>> On Wed, Oct 1, 2014 at 4:07 PM, Sean McBride <sean at rogue-research.com>
>> wrote:
>> > On Wed, 1 Oct 2014 15:44:52 -0400, Bill Lorensen said:
>> >
>> >>I can't seem to edit bugs. I could yesterday. Maybe a brainfart on my
>> >> part?
>> >
>> > Likewise.  David, maybe you broke something changing the 'reopening'
>> > permissions?
>> >
>> > Cheers,
>> >
>> > --
>> > ____________________________________________________________
>> > Sean McBride, B. Eng                 sean at rogue-research.com
>> > Rogue Research                        www.rogue-research.com
>> > Mac Software Developer              Montr?al, Qu?bec, Canada
>> >
>> >
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> _______________________________________________
>> 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  Fri Oct  3 08:42:35 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 3 Oct 2014 08:42:35 -0400
Subject: [vtk-developers] post hackathon cleanup
Message-ID: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>

not too bad actually!

Dave C, can you look at the blackbox tests?

thanks,

22  FAILURES
vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
['Mac10.8-clang-rel-x86_64']
vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
['Mac10.8-clang-rel-x86_64']
vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
vtkCommonDataModelCxx-TestHigherOrderCell , 1 , ['Mac10.8-clang-rel-x86_64']
vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
['Win32-vs71-static']
vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
['Mac10.5-gcc-dbg-ppc-shared']
vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
['Mac10.8-clang-rel-x86_64']
vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
vtkFiltersCorePython-multipleComponentContour , 1 ,
['Arch-GCC-4.9-x86_64-debug']
vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator ,
1 , ['Win64-VS10']
vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
['Win64-VS10']
vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
['Mac10.8-clang-rel-x86_64']
JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
'Linux-gcc']
vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
'Arch-GCC-4.9-x86_64-release']
vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141003/9d74e504/attachment-0002.html>

From dave.demarle at kitware.com  Fri Oct  3 08:51:57 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 3 Oct 2014 08:51:57 -0400
Subject: [vtk-developers] post hackathon process suggestions?
Message-ID: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>

We all did a great job Yesterday. Thank you to everyone who participated in
the bug tracker hackathon as well as to those who did us the favor of
reporting the bugs.

Moving forward, and particularly now that we are starting to setup the next
generation suite of software process tools, what can we do to make bug
tracking more relevant to VTK's future development?

See the VTK software process doc section 6 for our collective thoughts on
where we stand right now and are trying to improve upon.

thanks,

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141003/912dbe9c/attachment-0002.html>

From marcus.hanwell at kitware.com  Fri Oct  3 09:32:16 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Fri, 3 Oct 2014 09:32:16 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
Message-ID: <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>

On Fri, Oct 3, 2014 at 8:51 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> We all did a great job Yesterday. Thank you to everyone who participated in
> the bug tracker hackathon as well as to those who did us the favor of
> reporting the bugs.

Yes, great job, and yet another really useful hackathon.
>
> Moving forward, and particularly now that we are starting to setup the next
> generation suite of software process tools, what can we do to make bug
> tracking more relevant to VTK's future development?

I think whatever bug/issue tracker we use ensuring the developer list
is emailed when new tickets are created is crucial. I was talking with
one of our summer of code students and he felt (and I agree) that
weekly developer meetings on IRC would be really useful. We could
likely substitute technology if necessary, but some kind of regular
meeting where real time interaction is possible.
>
> See the VTK software process doc section 6 for our collective thoughts on
> where we stand right now and are trying to improve upon.
>
I would love to go back to a document where we can link to individual
pages and sections, like the wiki or similar. I think real time
editing is great, but I don't think Google Docs works well for this
type of documentation long term. There may be other technologies, but
something where anyone can edit, hyperlinks to pages and sections in
pages would be great so that it is easy to point people directly at
relevant text.

Just my 2 cents, really good hackathon, still have >70% coverage after
our coverage hackathon too!

Marcus


From cory.quammen at kitware.com  Fri Oct  3 10:06:44 2014
From: cory.quammen at kitware.com (Cory Quammen)
Date: Fri, 3 Oct 2014 10:06:44 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
Message-ID: <CAB5Fpx5J9CmB7_x51q=MaQ5epywOtbNXqxNs-GbhhQo9O-9AFQ@mail.gmail.com>

> I think whatever bug/issue tracker we use ensuring the developer list
> is emailed when new tickets are created is crucial. I was talking with
> one of our summer of code students and he felt (and I agree) that
> weekly developer meetings on IRC would be really useful. We could
> likely substitute technology if necessary, but some kind of regular
> meeting where real time interaction is possible.

+1


From sean at rogue-research.com  Fri Oct  3 10:17:52 2014
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 3 Oct 2014 10:17:52 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
Message-ID: <20141003141752.188535373@mail.rogue-research.com>

On Fri, 3 Oct 2014 09:32:16 -0400, Marcus D. Hanwell said:

>Yes, great job, and yet another really useful hackathon.

Agreed.  We should do them more often!

>I think whatever bug/issue tracker we use ensuring the developer list
>is emailed when new tickets are created is crucial.

+1.

I mentioned this the other day, the docs says it happens and Dave DeMarle agreed pointing this out:

http://markmail.org/search/vtk-developers+list:org%2Evtk%2Evtk-developers+mantis+from:%22Mantis+Bug+Tracker%22+order:date-backward

But it seems to show nothing since 2013.  A google search of "14266 site:vtk.org" shows nothing on the vtk-dev list either.  I would have fixed #14266 ages ago if I knew it existed.

(Next time I hope to be back in person, it was not as fun over the net, and I felt like more of a voyeur without my mic working. :))

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 berk.geveci at kitware.com  Sat Oct  4 13:38:18 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Sat, 4 Oct 2014 13:38:18 -0400
Subject: [vtk-developers] post hackathon cleanup
In-Reply-To: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
References: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
Message-ID: <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>

Hi guys,

I was looking at these tests that started failing after out hackathone:

http://open.cdash.org/viewTest.php?onlyfailed&buildid=3515162

It looks like someone added some leaks:

vtkDebugLeaks has detected LEAKS!
Class "vtkMatrix4x4" has 3 instances still around.
Class "vtkTransform" has 3 instances still around.

If you did anything with transforms during the hackathon, can you please
check this out?

Thanks,
-berk

On Fri, Oct 3, 2014 at 8:42 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> not too bad actually!
>
> Dave C, can you look at the blackbox tests?
>
> thanks,
>
> 22  FAILURES
> vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
> vtkCommonDataModelCxx-TestHigherOrderCell , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
> ['Win32-vs71-static']
> vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
> vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
> ['Mac10.5-gcc-dbg-ppc-shared']
> vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
> vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
> vtkFiltersCorePython-multipleComponentContour , 1 ,
> ['Arch-GCC-4.9-x86_64-debug']
> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator
> , 1 , ['Win64-VS10']
> vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
> vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
> ['Win64-VS10']
> vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
> ['Mac10.8-clang-rel-x86_64']
> JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
> vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
> 'Linux-gcc']
> vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
> ['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
> 'Arch-GCC-4.9-x86_64-release']
> vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
> vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
> vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141004/7c304a37/attachment-0002.html>

From DLRdave at aol.com  Sat Oct  4 15:58:15 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 4 Oct 2014 15:58:15 -0400
Subject: [vtk-developers] post hackathon cleanup
In-Reply-To: <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>
References: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
 <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>
Message-ID: <CAKME8fF5i9TuyL3WVEXYqsK_RMoHABs+gKm_mW=WWK+LNw2n5Q@mail.gmail.com>

Looks like these are probably related to the vtkVRMLImporter changes I
made... If so, I'll take care of it.



On Sat, Oct 4, 2014 at 1:38 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi guys,
>
> I was looking at these tests that started failing after out hackathone:
>
> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3515162
>
> It looks like someone added some leaks:
>
> vtkDebugLeaks has detected LEAKS!
> Class "vtkMatrix4x4" has 3 instances still around.
> Class "vtkTransform" has 3 instances still around.
>
> If you did anything with transforms during the hackathon, can you please
> check this out?
>
> Thanks,
> -berk
>
> On Fri, Oct 3, 2014 at 8:42 AM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>>
>> not too bad actually!
>>
>> Dave C, can you look at the blackbox tests?
>>
>> thanks,
>>
>> 22  FAILURES
>> vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
>> vtkCommonDataModelCxx-TestHigherOrderCell , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
>> ['Win32-vs71-static']
>> vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
>> vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
>> ['Mac10.5-gcc-dbg-ppc-shared']
>> vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
>> vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
>> vtkFiltersCorePython-multipleComponentContour , 1 ,
>> ['Arch-GCC-4.9-x86_64-debug']
>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator
>> , 1 , ['Win64-VS10']
>> vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
>> vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
>> ['Win64-VS10']
>> vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
>> ['Mac10.8-clang-rel-x86_64']
>> JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
>> vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
>> 'Linux-gcc']
>> vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
>> ['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
>> 'Arch-GCC-4.9-x86_64-release']
>> vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>> vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>> vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> 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 DLRdave at aol.com  Sat Oct  4 17:09:19 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 4 Oct 2014 17:09:19 -0400
Subject: [vtk-developers] post hackathon cleanup
In-Reply-To: <CAKME8fF5i9TuyL3WVEXYqsK_RMoHABs+gKm_mW=WWK+LNw2n5Q@mail.gmail.com>
References: <CANjZAi9AgtMFqGRGWQSG3xM2PXgBwS=gHyN3zq1_FHVJ7padRA@mail.gmail.com>
 <CAE32kpV4x4109G7_c2SyRn1_V3wDWTw-8cO3Dmj2co8PKbjSzw@mail.gmail.com>
 <CAKME8fF5i9TuyL3WVEXYqsK_RMoHABs+gKm_mW=WWK+LNw2n5Q@mail.gmail.com>
Message-ID: <CAKME8fEWZqpf4F=uTRWtApfpMhEBxjHpQ2CKjsTMxHcd_+=sTw@mail.gmail.com>

This topic should fix it -- waiting for CDash at home & Experimental
dashboard confirmation before claiming full victory...

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



On Sat, Oct 4, 2014 at 3:58 PM, David Cole <DLRdave at aol.com> wrote:
> Looks like these are probably related to the vtkVRMLImporter changes I
> made... If so, I'll take care of it.
>
>
>
> On Sat, Oct 4, 2014 at 1:38 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
>> Hi guys,
>>
>> I was looking at these tests that started failing after out hackathone:
>>
>> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3515162
>>
>> It looks like someone added some leaks:
>>
>> vtkDebugLeaks has detected LEAKS!
>> Class "vtkMatrix4x4" has 3 instances still around.
>> Class "vtkTransform" has 3 instances still around.
>>
>> If you did anything with transforms during the hackathon, can you please
>> check this out?
>>
>> Thanks,
>> -berk
>>
>> On Fri, Oct 3, 2014 at 8:42 AM, David E DeMarle <dave.demarle at kitware.com>
>> wrote:
>>>
>>> not too bad actually!
>>>
>>> Dave C, can you look at the blackbox tests?
>>>
>>> thanks,
>>>
>>> 22  FAILURES
>>> vtkInteractionStyleTcl-TestStyleTrackballActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkInteractionStylePython-TestStyleTrackballActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkInteractionWidgets-TestSetObjectMacro , 1 , ['Win64-VS10']
>>> vtkCommonDataModelCxx-TestHigherOrderCell , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkCommonComputationalGeometryCxx-UnitTestParametricSpline , 1 ,
>>> ['Win32-vs71-static']
>>> vtkCommonCoreCxx-UnitTestMath , 1 , ['AIX00F614-xlC']
>>> vtkCommonComputationalGeometryPython-TestParametricFunctions , 1 ,
>>> ['Mac10.5-gcc-dbg-ppc-shared']
>>> vtkFiltersCoreTcl-capCow , 1 , ['Arch-GCC-4.9-x86_64-debug']
>>> vtkInteractionStyleTcl-TestStyleJoystickActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> vtkCommonCoreCxx-TestUnicodeStringArrayAPI , 1 , ['Mac10.6-gcc-dbg-i386']
>>> vtkFiltersCorePython-multipleComponentContour , 1 ,
>>> ['Arch-GCC-4.9-x86_64-debug']
>>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostDataGenerator
>>> , 1 , ['Win64-VS10']
>>> vtkRenderingVolumePython-TestBunykRayCastFunction , 1 , ['AIX00F614-xlC']
>>> vtkInteractionWidgetsCxx-TestButtonWidget , 1 , ['AIX00F614-xlC']
>>> vtkFiltersParallelGeometryCxx-MPI-TestPUnstructuredGridConnectivity , 1 ,
>>> ['Win64-VS10']
>>> vtkInteractionStylePython-TestStyleJoystickActor , 1 ,
>>> ['Mac10.8-clang-rel-x86_64']
>>> JavaRendering , 2 , ['Mac10.8-clang-dbg-x86_64', 'Mac10.6-gcc-dbg-i386']
>>> vtkRenderingCoreCxx-TestEdgeFlags , 2 , ['TestExternal-Linux-gcc',
>>> 'Linux-gcc']
>>> vtkParallelMPI4PyPython-TestParallelNumpy , 3 ,
>>> ['Arch-GCC-4.9-x86_64-debug', 'Arch-Clang-3.3-x86_64-debug',
>>> 'Arch-GCC-4.9-x86_64-release']
>>> vtkCommonCoreTcl-TestEmptyInput , 7 , ['Mac10.8-clang-dbg-x86_64',
>>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>> vtkCommonCoreTcl-TestSetGet , 7 , ['Mac10.8-clang-dbg-x86_64',
>>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>> vtkCommonCoreTcl-otherPrint , 7 , ['Mac10.8-clang-dbg-x86_64',
>>> 'Mac10.9-clang-dbg-x86_64', 'Arch-GCC-4.9-x86_64-debug',
>>> 'Arch-Clang-3.3-x86_64-debug', 'Mac10.7-clang-dbg-x86_64',
>>> 'Arch-GCC-4.9-x86_64-release', 'Linux-gcc']
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> 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 dave.demarle at kitware.com  Mon Oct  6 11:54:24 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Mon, 6 Oct 2014 11:54:24 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <20141003141752.188535373@mail.rogue-research.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
 <20141003141752.188535373@mail.rogue-research.com>
Message-ID: <CANjZAi-RC5+2DPTHEQQ6E8eoobAKKioZG-pihfaffxo9fOKeQw@mail.gmail.com>

* I'll look into where the bug tracker emails are getting dropped.

* About the software process doc.

- I like the trivial editing and collaborative commenting on google docs. I
also like the access control model. Approved authors can do whatever they
want to it, everyone else on the web can suggest edits and those are
trivial for approved authors to accept.
- I agree that we need a way to simply reference it and its content. How
about we simply put a note note in it saying where the master/editable
version is, export the doc to pdf every release or so, and make
references/links to the exported read only copy?

* I like the frequent IRC hangouts idea, as long as we can sustain interest
in it.


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

On Fri, Oct 3, 2014 at 10:17 AM, Sean McBride <sean at rogue-research.com>
wrote:

> On Fri, 3 Oct 2014 09:32:16 -0400, Marcus D. Hanwell said:
>
> >Yes, great job, and yet another really useful hackathon.
>
> Agreed.  We should do them more often!
>
> >I think whatever bug/issue tracker we use ensuring the developer list
> >is emailed when new tickets are created is crucial.
>
> +1.
>
> I mentioned this the other day, the docs says it happens and Dave DeMarle
> agreed pointing this out:
>
>
> http://markmail.org/search/vtk-developers+list:org%2Evtk%2Evtk-developers+mantis+from:%22Mantis+Bug+Tracker%22+order:date-backward
>
> But it seems to show nothing since 2013.  A google search of "14266 site:
> vtk.org" shows nothing on the vtk-dev list either.  I would have fixed
> #14266 ages ago if I knew it existed.
>
> (Next time I hope to be back in person, it was not as fun over the net,
> and I felt like more of a voyeur without my mic working. :))
>
> 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/20141006/1684c142/attachment-0002.html>

From marcus.hanwell at kitware.com  Mon Oct  6 12:07:26 2014
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Mon, 6 Oct 2014 12:07:26 -0400
Subject: [vtk-developers] post hackathon process suggestions?
In-Reply-To: <CANjZAi-RC5+2DPTHEQQ6E8eoobAKKioZG-pihfaffxo9fOKeQw@mail.gmail.com>
References: <CANjZAi-ksLuSBgfRn6dnsrA+0S-Mp5Xfmg5C6Z1-GXXLo4=nqQ@mail.gmail.com>
 <CAMkPkZV+hB==N8t=bLuN04UeVDR5yV4WVJ-TEnxs5OZs=4MsbQ@mail.gmail.com>
 <20141003141752.188535373@mail.rogue-research.com>
 <CANjZAi-RC5+2DPTHEQQ6E8eoobAKKioZG-pihfaffxo9fOKeQw@mail.gmail.com>
Message-ID: <CAMkPkZV-Y0V2QizD8FuKyZTdJqLa+U2woObq_Uu+J2Rhj8TKKA@mail.gmail.com>

On Mon, Oct 6, 2014 at 11:54 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
>
> * About the software process doc.
>
> - I like the trivial editing and collaborative commenting on google docs. I
> also like the access control model. Approved authors can do whatever they
> want to it, everyone else on the web can suggest edits and those are trivial
> for approved authors to accept.
> - I agree that we need a way to simply reference it and its content. How
> about we simply put a note note in it saying where the master/editable
> version is, export the doc to pdf every release or so, and make
> references/links to the exported read only copy?
>
This is just my opinion, but Google doc, PDF, etc all suffer from not
being very accessible on the web. I see the draw of Google docs for
editing, and use it for many things but this doesn't seem like the
best fit to me. I would love to see at least pieces that are relevant
move back to the wiki, and thought this move was temporary (but I
don't remember any of the discussion about moving/keeping these docs
in a Google doc).

Exporting it to the CMS would work too, and restrict editing, if that
was possible. You know what I think now, if others think it works then
I can accept that and work with it. If it is long term a more
memorable link would be great for including in slides, wiki pages,
etc. On the positive side I think the actual content is an enormous
step forward, which is why I would like to make it as accessible as
possible.

Best,

Marcus


From patricksnape at gmail.com  Wed Oct  8 05:49:23 2014
From: patricksnape at gmail.com (patricksnape)
Date: Wed, 8 Oct 2014 02:49:23 -0700 (PDT)
Subject: [vtk-developers] VRML Appearance Nodes
Message-ID: <1412761763937-5729030.post@n5.nabble.com>

Hi,In the vtkVRMLImporter class  documentation
<http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html>   it
mentions that appearance nodes are supported. However, from browsing the
source code on Github, it appears that although they are recognised by the
parser, they are not actually parsed. It would be great if textures could be
parsed as well since the basic appearance nodes essentially just contain a
url to the texture. Is this something that would be valued by the rest of
the community? I'd love to drop the current VRML parser that I'm using but I
can't sacrifice texture support.



--
View this message in context: http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html
Sent from the VTK - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/bf1d623b/attachment-0002.html>

From will.schroeder at kitware.com  Wed Oct  8 06:22:29 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Wed, 8 Oct 2014 06:22:29 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <1412761763937-5729030.post@n5.nabble.com>
References: <1412761763937-5729030.post@n5.nabble.com>
Message-ID: <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>

Patrick-

Can you enter a bug report? If not let me know and I'll do it. I've
contacted the original developer and I am "encouraging" him ;-) to take a
look...we'll see if he has the time.

W

On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com> wrote:

> Hi, In the vtkVRMLImporter class documentation
> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
> mentions that appearance nodes are supported. However, from browsing the
> source code on Github, it appears that although they are recognised by the
> parser, they are not actually parsed. It would be great if textures could
> be parsed as well since the basic appearance nodes essentially just contain
> a url to the texture. Is this something that would be valued by the rest of
> the community? I'd love to drop the current VRML parser that I'm using but
> I can't sacrifice texture support.
> ------------------------------
> View this message in context: VRML Appearance Nodes
> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
> Sent from the VTK - Dev mailing list archive
> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>
> _______________________________________________
> 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/20141008/73dfef7b/attachment-0002.html>

From patricksnape at gmail.com  Wed Oct  8 09:05:16 2014
From: patricksnape at gmail.com (Patrick Snape)
Date: Wed, 8 Oct 2014 14:05:16 +0100
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
Message-ID: <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>

Hi Will,

Bug report submitted:

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

I'm not sure if any of the other importers include this functionality
(loading a texture from a url) but it would be a great addition I think. At
the very least the documentation should be clear that appearance nodes are
not actually supported. I wouldn't mind helping out but must admit that I
am intimidated with the complex process of submitting patches back to VTK.
Particularly the manner in which code reviews seem to be handled... I feel
like I'm trying to submit a patch back to the linux kernel!

Cheers,

Patrick

On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> Patrick-
>
> Can you enter a bug report? If not let me know and I'll do it. I've
> contacted the original developer and I am "encouraging" him ;-) to take a
> look...we'll see if he has the time.
>
> W
>
> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
> wrote:
>
>> Hi, In the vtkVRMLImporter class documentation
>> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
>> mentions that appearance nodes are supported. However, from browsing the
>> source code on Github, it appears that although they are recognised by the
>> parser, they are not actually parsed. It would be great if textures could
>> be parsed as well since the basic appearance nodes essentially just contain
>> a url to the texture. Is this something that would be valued by the rest of
>> the community? I'd love to drop the current VRML parser that I'm using but
>> I can't sacrifice texture support.
>> ------------------------------
>> View this message in context: VRML Appearance Nodes
>> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
>> Sent from the VTK - Dev mailing list archive
>> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>>
>> _______________________________________________
>> 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/20141008/9070a2e4/attachment-0002.html>

From will.schroeder at kitware.com  Wed Oct  8 09:36:40 2014
From: will.schroeder at kitware.com (Will Schroeder)
Date: Wed, 8 Oct 2014 09:36:40 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
 <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
Message-ID: <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>

I agree the process is tricky, and we are actively rethinking it.

If you want to make an attempt, just focus on the affected class(es) and a
test program. Either I or somebody much better at this than me will work
with you to slip it in.

So let me know if you are going to try, otherwise somebody, someday will
try and resolve this :-)

W

On Wed, Oct 8, 2014 at 9:05 AM, Patrick Snape <patricksnape at gmail.com>
wrote:

> Hi Will,
>
> Bug report submitted:
>
> http://www.vtk.org/Bug/view.php?id=15039
>
> I'm not sure if any of the other importers include this functionality
> (loading a texture from a url) but it would be a great addition I think. At
> the very least the documentation should be clear that appearance nodes are
> not actually supported. I wouldn't mind helping out but must admit that I
> am intimidated with the complex process of submitting patches back to VTK.
> Particularly the manner in which code reviews seem to be handled... I feel
> like I'm trying to submit a patch back to the linux kernel!
>
> Cheers,
>
> Patrick
>
> On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> Patrick-
>>
>> Can you enter a bug report? If not let me know and I'll do it. I've
>> contacted the original developer and I am "encouraging" him ;-) to take a
>> look...we'll see if he has the time.
>>
>> W
>>
>> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
>> wrote:
>>
>>> Hi, In the vtkVRMLImporter class documentation
>>> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
>>> mentions that appearance nodes are supported. However, from browsing the
>>> source code on Github, it appears that although they are recognised by the
>>> parser, they are not actually parsed. It would be great if textures could
>>> be parsed as well since the basic appearance nodes essentially just contain
>>> a url to the texture. Is this something that would be valued by the rest of
>>> the community? I'd love to drop the current VRML parser that I'm using but
>>> I can't sacrifice texture support.
>>> ------------------------------
>>> View this message in context: VRML Appearance Nodes
>>> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
>>> Sent from the VTK - Dev mailing list archive
>>> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>>>
>>> _______________________________________________
>>> 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
>>
>
>


-- 
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/20141008/41183d1a/attachment-0002.html>

From DLRdave at aol.com  Wed Oct  8 10:33:45 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 8 Oct 2014 10:33:45 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
 <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
 <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
Message-ID: <CAKME8fEvg1vc-U-Y7Hyu34cb91baAKU+aNeeYh9=7Bx=hhkR_g@mail.gmail.com>

Patrick,

If you have a patch, that includes testing the new code, and you're
willing to do some follow up work to address any test failures on the
VTK dashboard machines after the fact, I can help you get your patches
through the review process.

(But I can only help you get it through, I don't have the bandwidth to
do the work myself...)


Let me know,
David C.




On Wed, Oct 8, 2014 at 9:36 AM, Will Schroeder
<will.schroeder at kitware.com> wrote:
> I agree the process is tricky, and we are actively rethinking it.
>
> If you want to make an attempt, just focus on the affected class(es) and a
> test program. Either I or somebody much better at this than me will work
> with you to slip it in.
>
> So let me know if you are going to try, otherwise somebody, someday will try
> and resolve this :-)
>
> W
>
> On Wed, Oct 8, 2014 at 9:05 AM, Patrick Snape <patricksnape at gmail.com>
> wrote:
>>
>> Hi Will,
>>
>> Bug report submitted:
>>
>> http://www.vtk.org/Bug/view.php?id=15039
>>
>> I'm not sure if any of the other importers include this functionality
>> (loading a texture from a url) but it would be a great addition I think. At
>> the very least the documentation should be clear that appearance nodes are
>> not actually supported. I wouldn't mind helping out but must admit that I am
>> intimidated with the complex process of submitting patches back to VTK.
>> Particularly the manner in which code reviews seem to be handled... I feel
>> like I'm trying to submit a patch back to the linux kernel!
>>
>> Cheers,
>>
>> Patrick
>>
>> On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder
>> <will.schroeder at kitware.com> wrote:
>>>
>>> Patrick-
>>>
>>> Can you enter a bug report? If not let me know and I'll do it. I've
>>> contacted the original developer and I am "encouraging" him ;-) to take a
>>> look...we'll see if he has the time.
>>>
>>> W
>>>
>>> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
>>> wrote:
>>>>
>>>> Hi, In the vtkVRMLImporter class documentation it mentions that
>>>> appearance nodes are supported. However, from browsing the source code on
>>>> Github, it appears that although they are recognised by the parser, they are
>>>> not actually parsed. It would be great if textures could be parsed as well
>>>> since the basic appearance nodes essentially just contain a url to the
>>>> texture. Is this something that would be valued by the rest of the
>>>> community? I'd love to drop the current VRML parser that I'm using but I
>>>> can't sacrifice texture support.
>>>> ________________________________
>>>> View this message in context: VRML Appearance Nodes
>>>> Sent from the VTK - Dev mailing list archive at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> 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
>>
>>
>
>
>
> --
> 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
>
> _______________________________________________
> 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  Wed Oct  8 14:06:20 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 8 Oct 2014 12:06:20 -0600
Subject: [vtk-developers] A new internal Start method for interactors
Message-ID: <CANwS1=G5zAo1mRHsjxN1hueeHJW2=9uVPVWM4KkwoWzncAerHw@mail.gmail.com>

The interactors are core classes, so I'm bringing this to the list:

The Start() method for every single interactor class had a check for the
"HandleEventLoop" ivar, so I've moved the check into the interactor
base class, and added a new StartEventLoop() method that Start()
calls for the specialized classes to run the OS-specific event loop.

Gerrit patch is here:
http://review.source.kitware.com/#/c/17567/

Comments welcome.

 - David


From jeff.baumes at kitware.com  Wed Oct  8 15:13:26 2014
From: jeff.baumes at kitware.com (Jeff Baumes)
Date: Wed, 8 Oct 2014 15:13:26 -0400
Subject: [vtk-developers] [vtkusers] Creating the dual of a graph -
	planar face traversal - vtkBoostGraphAdapter
In-Reply-To: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
References: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
Message-ID: <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>

In your code, you are retrieving a vtkGraphIndexMap with:

property_map<vtkUndirectedGraph*, edge_index_t>::type e_index =
get(edge_index, in);

vtkGraphIndexMap is intended to be read-only and is already populated with
indices 0 through N-1, which are accessed with get(). It's actually an
identity map by index since indices are always in order, as you can see
here:

https://github.com/Kitware/VTK/blob/master/Infovis/BoostGraphAlgorithms/vtkBoostGraphAdapter.h#L1032-L1049

So I would suggest leaving out your initialization loop on lines 43-45.

Now, the remaining errors seem to require an operator[] on the
EdgeIndexMap, which is not currently implemented in vtkBoostGraphAdapter.h.
The needed code would be to replace the definition of vtkGraphPropertyMap
with something like this (not tested):

struct vtkGraphIndexMap; // forward declaration

template <>
struct property_traits<vtkGraphIndexMap>
{
  typedef vtkIdType value_type;
  typedef vtkIdType reference;
  typedef vtkIdType key_type;
  typedef readable_property_map_tag category;
};

struct vtkGraphIndexMap
{
  property_traits<vtkGraphIndexMap>::reference operator[](const
property_traits<vtkGraphIndexMap>::key_type& b)
    {
    return key;
    }
};


HTH,
Jeff

On Wed, Oct 8, 2014 at 2:12 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com>
wrote:

> Hi All,
>
> I'm trying to write an algorithm which creates the dual of a graph. To
> check whether the graph is planar or not I use the *Boyer-Myrvold
> planarity test* (Boost implementation) through the vtkBoostGraphAdapter.
> That works fine (only on vtkUndirectedGraph-s but that's OK for now).
> (http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/boyer_myrvold.html)
>
> To create the dual I need to traverse the faces of the planar graph for
> which I also have a Boost tool called the planar_face_traversal_visitor.
> (
> http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/planar_face_traversal.html
> )
> There's a guy, Aaron Windsor who implemented the appropriate visitor class
> that is able to create the dual of a graph in Boost.
> (https://github.com/aaw/boost_planar_graph_dual)
> That also works fine using only Boost but I'd like to adapt this feature
> as well using vtkBoostGraphAdapter.
>
> Here's my code: http://pastebin.com/g0Mtw6Ph
>
> These are my errors:
>
>    - *vtkDualGraph.cpp*:44:9: No matching function for call to 'put'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>    'iterator_property_map<typename vertex_vector_t::iterator,
>    boost::vtkGraphIndexMap>')
>
> It seems I cannot provide an appropriate EdgeIndexMap parameter to the
> put function in the 44th line. The vtkBoostGraphAdapter says that we can
> use VTK arrays as property maps, I tried that one as well, with no success.
> I've been dealing with this, reading the source code really deep and trying
> a couple of things in the past few days but I can't really figure out what
> the problem is. Is the vtkBoostGraphAdapter properly prepared for this
> kind of usage?
>
> Any kind of help appreciated!
>
> Thanks in advance!
>
> Szilard
>
> _______________________________________________
> 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/20141008/98e8bc6c/attachment-0002.html>

From david.lonie at kitware.com  Wed Oct  8 15:52:13 2014
From: david.lonie at kitware.com (David Lonie)
Date: Wed, 8 Oct 2014 15:52:13 -0400
Subject: [vtk-developers] vtkTextActor rotation
Message-ID: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>

Hi Folks,

We've noticed some odd behavior while rotating 2D vtkTextActors. There are
two ways to do it:

vtkTextActor::SetOrientation(degrees), or
vtkTextProperty::SetOrientation(degrees)

These behave very differently, especially when alignment flags are used --
see the attached image for an example. The bottom two rows show this most
clearly.

Rotating the text property will rotate the text as it is being rendered
into the texture's buffer. This gives great antialiasing on the rotated
text, but gives bad alignment results, since the vtkTextActor is currently
aligning the entire texture to its position, rather than the text inside
the texture.

Rotating the actor gives the expected alignment behavior, but bad
antialiasing. This is because the text is rendered into the texture without
rotation, and then rotated afterwards.

Combining the two (top row) gives the worst of both cases.

I'd like to fix the text actor to align things "correctly" when the text
property is rotated. So my questions:

1) Is this behavior expected due to backwards compatibility?
2) If not, is this a good time to fix this? (e.g. are there any upcoming
releases I should hold off for?)

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/bad741f6/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: textactor-rotation.png
Type: image/png
Size: 79114 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/bad741f6/attachment-0002.png>

From szilardszaloki at gmail.com  Wed Oct  8 17:27:25 2014
From: szilardszaloki at gmail.com (=?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?=)
Date: Wed, 8 Oct 2014 23:27:25 +0200
Subject: [vtk-developers] [vtkusers] Creating the dual of a graph -
	planar face traversal - vtkBoostGraphAdapter
In-Reply-To: <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>
References: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
 <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>
Message-ID: <CAEQ0100JxHyWZ+Wnix_42EJ1HCASbYsrg5Ecqz_R=o+aw-fsqA@mail.gmail.com>

Thank you for replying so fast!

I edited the vtkBoostGraphAdapter.h:

  struct vtkGraphIndexMap;


  template <>

  struct property_traits<vtkGraphIndexMap>

    {

    typedef vtkIdType value_type;

    typedef vtkIdType reference;

    typedef vtkIdType key_type;

    typedef readable_property_map_tag category;

    };



    struct vtkGraphIndexMap

    {

    property_traits<vtkGraphIndexMap>::reference operator[](const
property_traits<vtkGraphIndexMap>::key_type& key)

      {

        return key;

      }

    };


  inline property_traits<vtkGraphIndexMap>::reference

  get(

    vtkGraphIndexMap vtkNotUsed(arr),

    property_traits<vtkGraphIndexMap>::key_type key)

  {

    return key;

  }

I deleted the lines that fill the index map also. Unfortunately I still get
these errors:

   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
   vtkEdgeType, std::__1::less<long long>,
   std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
   boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > > &>'
   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
   vtkEdgeType, std::__1::less<long long>,
   std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
   boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
   std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
   long, vtkEdgeType> > > &>'
   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > *>,
   boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
   long>, std::__1::allocator<long long> >, std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > &>'
   - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
   No viable overloaded operator[] for type 'const
   boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > *>,
   boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
   long>, std::__1::allocator<long long> >, std::__1::set<long long,
   std::__1::less<long long>, std::__1::allocator<long long> > &>'
   - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
   overloaded operator[] for type 'edge_to_face_map_t' (aka
   'iterator_property_map<typename vertex_vector_t::iterator,
   boost::vtkGraphIndexMap>')

It seems to me that there's no operator[] for the iterator_property_map. Am
I missing something?

Thanks again!

Szilard

2014-10-08 21:13 GMT+02:00 Jeff Baumes <jeff.baumes at kitware.com>:

> In your code, you are retrieving a vtkGraphIndexMap with:
>
> property_map<vtkUndirectedGraph*, edge_index_t>::type e_index =
> get(edge_index, in);
>
> vtkGraphIndexMap is intended to be read-only and is already populated with
> indices 0 through N-1, which are accessed with get(). It's actually an
> identity map by index since indices are always in order, as you can see
> here:
>
>
> https://github.com/Kitware/VTK/blob/master/Infovis/BoostGraphAlgorithms/vtkBoostGraphAdapter.h#L1032-L1049
>
> So I would suggest leaving out your initialization loop on lines 43-45.
>
> Now, the remaining errors seem to require an operator[] on the
> EdgeIndexMap, which is not currently implemented in vtkBoostGraphAdapter.h.
> The needed code would be to replace the definition of vtkGraphPropertyMap
> with something like this (not tested):
>
> struct vtkGraphIndexMap; // forward declaration
>
> template <>
> struct property_traits<vtkGraphIndexMap>
> {
>   typedef vtkIdType value_type;
>   typedef vtkIdType reference;
>   typedef vtkIdType key_type;
>   typedef readable_property_map_tag category;
> };
>
> struct vtkGraphIndexMap
> {
>   property_traits<vtkGraphIndexMap>::reference operator[](const
> property_traits<vtkGraphIndexMap>::key_type& b)
>     {
>     return key;
>     }
> };
>
>
> HTH,
> Jeff
>
> On Wed, Oct 8, 2014 at 2:12 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com>
> wrote:
>
>> Hi All,
>>
>> I'm trying to write an algorithm which creates the dual of a graph. To
>> check whether the graph is planar or not I use the *Boyer-Myrvold
>> planarity test* (Boost implementation) through the vtkBoostGraphAdapter.
>> That works fine (only on vtkUndirectedGraph-s but that's OK for now).
>> (http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/boyer_myrvold.html)
>>
>> To create the dual I need to traverse the faces of the planar graph for
>> which I also have a Boost tool called the planar_face_traversal_visitor.
>> (
>> http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/planar_face_traversal.html
>> )
>> There's a guy, Aaron Windsor who implemented the appropriate visitor
>> class that is able to create the dual of a graph in Boost.
>> (https://github.com/aaw/boost_planar_graph_dual)
>> That also works fine using only Boost but I'd like to adapt this feature
>> as well using vtkBoostGraphAdapter.
>>
>> Here's my code: http://pastebin.com/g0Mtw6Ph
>>
>> These are my errors:
>>
>>    - *vtkDualGraph.cpp*:44:9: No matching function for call to 'put'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>    vtkEdgeType, std::__1::less<long long>,
>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > > &>'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>    vtkEdgeType, std::__1::less<long long>,
>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>    long, vtkEdgeType> > > &>'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>    No viable overloaded operator[] for type 'const
>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>>    'iterator_property_map<typename vertex_vector_t::iterator,
>>    boost::vtkGraphIndexMap>')
>>
>> It seems I cannot provide an appropriate EdgeIndexMap parameter to the
>> put function in the 44th line. The vtkBoostGraphAdapter says that we can
>> use VTK arrays as property maps, I tried that one as well, with no success.
>> I've been dealing with this, reading the source code really deep and trying
>> a couple of things in the past few days but I can't really figure out what
>> the problem is. Is the vtkBoostGraphAdapter properly prepared for this
>> kind of usage?
>>
>> Any kind of help appreciated!
>>
>> Thanks in advance!
>>
>> Szilard
>>
>> _______________________________________________
>> 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/20141008/90e7d5f4/attachment-0002.html>

From berk.geveci at kitware.com  Wed Oct  8 17:38:17 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 8 Oct 2014 17:38:17 -0400
Subject: [vtk-developers] ANNOUNCE: Kitware is hiring
Message-ID: <CAE32kpWTbDpA89vU2U53q=-C0HOro+8c2PU3HexjfraA-aPn7w@mail.gmail.com>

Hi folks,

We are looking to hire visualization developers to our Scientific Computing
team. If you are a talented visualization researcher and developer with
strong C++ skills, please consider applying.  You will join a great team
and work on many interesting and challenging technical problems - always
aiming to deliver robust and widely used software solutions.

For the full posting see:
http://tinyurl.com/l8sgvzw

JOB DESCRIPTION
Kitware is seeking to hire highly skilled Research and Development
Engineers (R&D Engineers) to join our Scientific Computing team and
contribute to our scientific and information visualization efforts.
Candidates will work to develop and improve leading visualization software
solutions.

Kitware collaborates on a multitude of basic and applied research and
development projects. Our collaborators include the top universities from
around the world, national research labs, medical device manufacturers, car
manufacturers, oil and gas companies, financial institutes, and many
others. The projects range from extending our open source C++ libraries and
applications, such as VTK, ParaView, and CMake, to developing proprietary
domain-specific vertical applications for a wide array of platforms
including web and mobile devices.

By joining our team you will participate in a dynamic work environment with
exceptionally talented and friendly coworkers who are committed to
high-quality development practices.  You will collaborate with esteemed
researchers from around the world by:

* Designing and developing scalable data analysis and visualization tools
for use by  researchers and professionals from various domains;

* Solving a wide array of problems ranging from developing distributed
memory parallel algorithms for data analysis, optimizing distributed
parallel codes to compiling and maintaining software on supercomputers.

* Designing and developing tools to improve scientific data analysis
workflows;

* Contributing to and supporting our dynamic open source communities built
around several of our open source tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141008/3ccf982a/attachment-0002.html>

From berk.geveci at kitware.com  Wed Oct  8 19:19:24 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 8 Oct 2014 19:19:24 -0400
Subject: [vtk-developers] VRML Appearance Nodes
In-Reply-To: <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
References: <1412761763937-5729030.post@n5.nabble.com>
 <CAEiDrtWSu+qtbM4j-PJh-nFFa0mSbj2sN06xAdOuXSJXYXNPxA@mail.gmail.com>
 <CAL5VpCC++71yApSsEihu1bEeGnNfLiwLOoze=OteQ1BD4Av0oQ@mail.gmail.com>
 <CAEiDrtVKwwGLA7Hd_UiiJK2e0sPrMqUCUYPd6A3L-8qLUjdiRw@mail.gmail.com>
Message-ID: <CAE32kpV9HhBgfhjHLVmx4_n96VCdxynO+uyiBhwcj1VokAzFkw@mail.gmail.com>

We are rethinking our processes. It is very likely that we will go to a
simple fork - pull-request based workflow. Our goal is to streamline the
review process and put more energy into shepherding contributions so we
don't drop them and discourage folks from contributing. It will take us a
few months to get everything in place.

Best,
-berk

On Wed, Oct 8, 2014 at 9:36 AM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> I agree the process is tricky, and we are actively rethinking it.
>
> If you want to make an attempt, just focus on the affected class(es) and a
> test program. Either I or somebody much better at this than me will work
> with you to slip it in.
>
> So let me know if you are going to try, otherwise somebody, someday will
> try and resolve this :-)
>
> W
>
> On Wed, Oct 8, 2014 at 9:05 AM, Patrick Snape <patricksnape at gmail.com>
> wrote:
>
>> Hi Will,
>>
>> Bug report submitted:
>>
>> http://www.vtk.org/Bug/view.php?id=15039
>>
>> I'm not sure if any of the other importers include this functionality
>> (loading a texture from a url) but it would be a great addition I think. At
>> the very least the documentation should be clear that appearance nodes are
>> not actually supported. I wouldn't mind helping out but must admit that I
>> am intimidated with the complex process of submitting patches back to VTK.
>> Particularly the manner in which code reviews seem to be handled... I feel
>> like I'm trying to submit a patch back to the linux kernel!
>>
>> Cheers,
>>
>> Patrick
>>
>> On Wed, Oct 8, 2014 at 11:22 AM, Will Schroeder <
>> will.schroeder at kitware.com> wrote:
>>
>>> Patrick-
>>>
>>> Can you enter a bug report? If not let me know and I'll do it. I've
>>> contacted the original developer and I am "encouraging" him ;-) to take a
>>> look...we'll see if he has the time.
>>>
>>> W
>>>
>>> On Wed, Oct 8, 2014 at 5:49 AM, patricksnape <patricksnape at gmail.com>
>>> wrote:
>>>
>>>> Hi, In the vtkVRMLImporter class documentation
>>>> <http://www.vtk.org/doc/nightly/html/classvtkVRMLImporter.html> it
>>>> mentions that appearance nodes are supported. However, from browsing the
>>>> source code on Github, it appears that although they are recognised by the
>>>> parser, they are not actually parsed. It would be great if textures could
>>>> be parsed as well since the basic appearance nodes essentially just contain
>>>> a url to the texture. Is this something that would be valued by the rest of
>>>> the community? I'd love to drop the current VRML parser that I'm using but
>>>> I can't sacrifice texture support.
>>>> ------------------------------
>>>> View this message in context: VRML Appearance Nodes
>>>> <http://vtk.1045678.n5.nabble.com/VRML-Appearance-Nodes-tp5729030.html>
>>>> Sent from the VTK - Dev mailing list archive
>>>> <http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html> at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>
>
> --
> 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
>
> _______________________________________________
> 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/20141008/38acdbb1/attachment-0002.html>

From bill.lorensen at gmail.com  Thu Oct  9 07:10:35 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 07:10:35 -0400
Subject: [vtk-developers] Recent changes cause cmake failure
Message-ID: <CADZJ4hMpE8ah405TMb0RQSrbQAJuHXUaKvX728KoR_4-JJCRbw@mail.gmail.com>

Folks,

My Fedora build started to have a cmake error in the last couple of
days. I see the same error on the nightly dashboards:

CMake Error: Attempt to add a custom rule to output
"/home/kitware/Dashboards/My
Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
which already has a custom rule.
-- Configuring incomplete, errors occurred!

Bill


-- 
Unpaid intern in BillsBasement at noware dot com


From bill.lorensen at gmail.com  Thu Oct  9 08:44:15 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 08:44:15 -0400
Subject: [vtk-developers] Recent changes cause cmake failure
In-Reply-To: <CADZJ4hMpE8ah405TMb0RQSrbQAJuHXUaKvX728KoR_4-JJCRbw@mail.gmail.com>
References: <CADZJ4hMpE8ah405TMb0RQSrbQAJuHXUaKvX728KoR_4-JJCRbw@mail.gmail.com>
Message-ID: <CADZJ4hN4w+rKMNnJk-3B8j=SudKADac_-vetQoPAjr6NYP5m-A@mail.gmail.com>

vtkOpenGLGPUVolumeRayCastMapper exists in both VolumeOpenGL and VolumeOpenGLNew.


On Thu, Oct 9, 2014 at 7:10 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Folks,
>
> My Fedora build started to have a cmake error in the last couple of
> days. I see the same error on the nightly dashboards:
>
> CMake Error: Attempt to add a custom rule to output
> "/home/kitware/Dashboards/My
> Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
> which already has a custom rule.
> -- Configuring incomplete, errors occurred!
>
> Bill
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com


From david.gobbi at gmail.com  Thu Oct  9 09:07:48 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 9 Oct 2014 07:07:48 -0600
Subject: [vtk-developers] New volume rendering
Message-ID: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>

There seems to be some major changes occurring to VTK's volume
rendering.  Can the developers who are involved let the us (the
community) know what is going on?  Either by giving a summary on the
mailing list or by adding to the roadmap on the wiki?  Transparency,
folks!  Thanks in advance.

 - David


From aashish.chaudhary at kitware.com  Thu Oct  9 09:35:22 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 09:35:22 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
Message-ID: <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>

Hi David,

Absolutely! I was going to send an email today about it. In the past, it
was referred in the source article (
http://www.kitware.com/source/home/post/144). Also, for the upcoming issue,
we are working on a
source article targeting volume rendering in this series.

I will send an email out this afternoon.

- Aashish

On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> There seems to be some major changes occurring to VTK's volume
> rendering.  Can the developers who are involved let the us (the
> community) know what is going on?  Either by giving a summary on the
> mailing list or by adding to the roadmap on the wiki?  Transparency,
> folks!  Thanks in advance.
>
>  - 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
>
>


-- 



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

From david.gobbi at gmail.com  Thu Oct  9 09:55:49 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 9 Oct 2014 07:55:49 -0600
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
Message-ID: <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>

Thanks for the heads-up.

 - David

On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi David,
>
> Absolutely! I was going to send an email today about it. In the past, it was
> referred in the source article
> (http://www.kitware.com/source/home/post/144). Also, for the upcoming issue,
> we are working on a
> source article targeting volume rendering in this series.
>
> I will send an email out this afternoon.
>
> - Aashish
>
> On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> There seems to be some major changes occurring to VTK's volume
>> rendering.  Can the developers who are involved let the us (the
>> community) know what is going on?  Either by giving a summary on the
>> mailing list or by adding to the roadmap on the wiki?  Transparency,
>> folks!  Thanks in advance.
>>
>>  - David


From bill.lorensen at gmail.com  Thu Oct  9 10:02:31 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 10:02:31 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
Message-ID: <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>

Aashish,
I hope someone can address the CMake issue I reported. It is related to the
new volume rendering.

Bill
On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:

> Thanks for the heads-up.
>
>  - David
>
> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi David,
> >
> > Absolutely! I was going to send an email today about it. In the past, it
> was
> > referred in the source article
> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
> issue,
> > we are working on a
> > source article targeting volume rendering in this series.
> >
> > I will send an email out this afternoon.
> >
> > - Aashish
> >
> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> There seems to be some major changes occurring to VTK's volume
> >> rendering.  Can the developers who are involved let the us (the
> >> community) know what is going on?  Either by giving a summary on the
> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
> >> folks!  Thanks in advance.
> >>
> >>  - 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/20141009/382fde75/attachment-0002.html>

From aashish.chaudhary at kitware.com  Thu Oct  9 10:04:07 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 10:04:07 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
Message-ID: <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>

Hi Bill,

Somehow I didn't see it (or came to know about it). My apologies. Can you
point me to the
report please?

Thanks,


On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Aashish,
> I hope someone can address the CMake issue I reported. It is related to
> the new volume rendering.
>
> Bill
> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>
>> Thanks for the heads-up.
>>
>>  - David
>>
>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>> <aashish.chaudhary at kitware.com> wrote:
>> > Hi David,
>> >
>> > Absolutely! I was going to send an email today about it. In the past,
>> it was
>> > referred in the source article
>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>> issue,
>> > we are working on a
>> > source article targeting volume rendering in this series.
>> >
>> > I will send an email out this afternoon.
>> >
>> > - Aashish
>> >
>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>> >>
>> >> There seems to be some major changes occurring to VTK's volume
>> >> rendering.  Can the developers who are involved let the us (the
>> >> community) know what is going on?  Either by giving a summary on the
>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>> >> folks!  Thanks in advance.
>> >>
>> >>  - 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
>>
>>


-- 



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

From bill.lorensen at gmail.com  Thu Oct  9 10:22:19 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 10:22:19 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
Message-ID: <CADZJ4hN4Rzv=fG5UgHePACtWbAfekkgooXMMnUbm4mjJ9ws0Yw@mail.gmail.com>

My Fedora build started to have a cmake error in the last couple of
days. I see the same error on some nightly dashboards. Occurs if
python wrapping is on.
http://open.cdash.org/viewConfigure.php?buildid=3522094


CMake Error: Attempt to add a custom rule to output
"/home/kitware/Dashboards/My
Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
which already has a custom rule.
-- Configuring incomplete, errors occurred!

Looks like vtkOpenGLGPUVolumeRayCastMapper exists in both VolumeOpenGL
and VolumeOpenGLNew.

On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi Bill,
>
> Somehow I didn't see it (or came to know about it). My apologies. Can you
> point me to the
> report please?
>
> Thanks,
>
>
> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> Aashish,
>> I hope someone can address the CMake issue I reported. It is related to
>> the new volume rendering.
>>
>> Bill
>>
>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>>
>>> Thanks for the heads-up.
>>>
>>>  - David
>>>
>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>>> <aashish.chaudhary at kitware.com> wrote:
>>> > Hi David,
>>> >
>>> > Absolutely! I was going to send an email today about it. In the past,
>>> > it was
>>> > referred in the source article
>>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>>> > issue,
>>> > we are working on a
>>> > source article targeting volume rendering in this series.
>>> >
>>> > I will send an email out this afternoon.
>>> >
>>> > - Aashish
>>> >
>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>>> > wrote:
>>> >>
>>> >> There seems to be some major changes occurring to VTK's volume
>>> >> rendering.  Can the developers who are involved let the us (the
>>> >> community) know what is going on?  Either by giving a summary on the
>>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>>> >> folks!  Thanks in advance.
>>> >>
>>> >>  - 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
>>>
>
>
>
> --
> | Aashish Chaudhary
> | Technical Leader
> | Kitware Inc.
> | http://www.kitware.com/company/team/chaudhary.html



-- 
Unpaid intern in BillsBasement at noware dot com


From aashish.chaudhary at kitware.com  Thu Oct  9 10:23:10 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 10:23:10 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CADZJ4hN4Rzv=fG5UgHePACtWbAfekkgooXMMnUbm4mjJ9ws0Yw@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CADZJ4hN4Rzv=fG5UgHePACtWbAfekkgooXMMnUbm4mjJ9ws0Yw@mail.gmail.com>
Message-ID: <CAEw35Z9B2c3ucMjTTsp6pOJGWLSfTWnTOp9sekDAhaNcfQXgPQ@mail.gmail.com>

Thanks for the pointers. We will fix it ASAP and report back.

- Aashish

On Thu, Oct 9, 2014 at 10:22 AM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> My Fedora build started to have a cmake error in the last couple of
> days. I see the same error on some nightly dashboards. Occurs if
> python wrapping is on.
> http://open.cdash.org/viewConfigure.php?buildid=3522094
>
>
> CMake Error: Attempt to add a custom rule to output
> "/home/kitware/Dashboards/My
>
> Tests/VTK-gnu/Wrapping/Python/vtkOpenGLGPUVolumeRayCastMapperPython.cxx.rule"
> which already has a custom rule.
> -- Configuring incomplete, errors occurred!
>
> Looks like vtkOpenGLGPUVolumeRayCastMapper exists in both VolumeOpenGL
> and VolumeOpenGLNew.
>
> On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi Bill,
> >
> > Somehow I didn't see it (or came to know about it). My apologies. Can you
> > point me to the
> > report please?
> >
> > Thanks,
> >
> >
> > On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
> > wrote:
> >>
> >> Aashish,
> >> I hope someone can address the CMake issue I reported. It is related to
> >> the new volume rendering.
> >>
> >> Bill
> >>
> >> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
> >>>
> >>> Thanks for the heads-up.
> >>>
> >>>  - David
> >>>
> >>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
> >>> <aashish.chaudhary at kitware.com> wrote:
> >>> > Hi David,
> >>> >
> >>> > Absolutely! I was going to send an email today about it. In the past,
> >>> > it was
> >>> > referred in the source article
> >>> > (http://www.kitware.com/source/home/post/144). Also, for the
> upcoming
> >>> > issue,
> >>> > we are working on a
> >>> > source article targeting volume rendering in this series.
> >>> >
> >>> > I will send an email out this afternoon.
> >>> >
> >>> > - Aashish
> >>> >
> >>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> There seems to be some major changes occurring to VTK's volume
> >>> >> rendering.  Can the developers who are involved let the us (the
> >>> >> community) know what is going on?  Either by giving a summary on the
> >>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
> >>> >> folks!  Thanks in advance.
> >>> >>
> >>> >>  - 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
> >>>
> >
> >
> >
> > --
> > | Aashish Chaudhary
> > | Technical Leader
> > | Kitware Inc.
> > | http://www.kitware.com/company/team/chaudhary.html
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>



-- 



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

From DLRdave at aol.com  Thu Oct  9 10:37:47 2014
From: DLRdave at aol.com (David Cole)
Date: Thu, 9 Oct 2014 10:37:47 -0400
Subject: [vtk-developers] A new internal Start method for interactors
In-Reply-To: <CANwS1=G5zAo1mRHsjxN1hueeHJW2=9uVPVWM4KkwoWzncAerHw@mail.gmail.com>
References: <CANwS1=G5zAo1mRHsjxN1hueeHJW2=9uVPVWM4KkwoWzncAerHw@mail.gmail.com>
Message-ID: <CAKME8fHL42MHKRM3G-5CU2eM83qrpPR1OSDkqWMPfZKoG4mW+g@mail.gmail.com>

Makes perfect sense... let's push it!

On Wed, Oct 8, 2014 at 2:06 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> The interactors are core classes, so I'm bringing this to the list:
>
> The Start() method for every single interactor class had a check for the
> "HandleEventLoop" ivar, so I've moved the check into the interactor
> base class, and added a new StartEventLoop() method that Start()
> calls for the specialized classes to run the OS-specific event loop.
>
> Gerrit patch is here:
> http://review.source.kitware.com/#/c/17567/
>
> Comments welcome.
>
>  - 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 DLRdave at aol.com  Thu Oct  9 10:45:06 2014
From: DLRdave at aol.com (David Cole)
Date: Thu, 9 Oct 2014 10:45:06 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
Message-ID: <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>

I would say the text should look good and be legible when it's rendered...

Would anybody here really prefer perfect backwards compatibility
(including text illegibility) over better visualization...?

On Wed, Oct 8, 2014 at 3:52 PM, David Lonie <david.lonie at kitware.com> wrote:
> Hi Folks,
>
> We've noticed some odd behavior while rotating 2D vtkTextActors. There are
> two ways to do it:
>
> vtkTextActor::SetOrientation(degrees), or
> vtkTextProperty::SetOrientation(degrees)
>
> These behave very differently, especially when alignment flags are used --
> see the attached image for an example. The bottom two rows show this most
> clearly.
>
> Rotating the text property will rotate the text as it is being rendered into
> the texture's buffer. This gives great antialiasing on the rotated text, but
> gives bad alignment results, since the vtkTextActor is currently aligning
> the entire texture to its position, rather than the text inside the texture.
>
> Rotating the actor gives the expected alignment behavior, but bad
> antialiasing. This is because the text is rendered into the texture without
> rotation, and then rotated afterwards.
>
> Combining the two (top row) gives the worst of both cases.
>
> I'd like to fix the text actor to align things "correctly" when the text
> property is rotated. So my questions:
>
> 1) Is this behavior expected due to backwards compatibility?
> 2) If not, is this a good time to fix this? (e.g. are there any upcoming
> releases I should hold off for?)
>
> Thanks,
> Dave
>
> _______________________________________________
> 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 aashish.chaudhary at kitware.com  Thu Oct  9 10:54:10 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 10:54:10 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
Message-ID: <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>

Hi Bill,

We found the issue and will push a fix shortly. It was related to build
module all (and will show on only those dashboards which has it turned
on).  Said, that we will push a fix and monitor the dashboards.

Thanks,
Aashish


On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Hi Bill,
>
> Somehow I didn't see it (or came to know about it). My apologies. Can you
> point me to the
> report please?
>
> Thanks,
>
>
> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> Aashish,
>> I hope someone can address the CMake issue I reported. It is related to
>> the new volume rendering.
>>
>> Bill
>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>
>>> Thanks for the heads-up.
>>>
>>>  - David
>>>
>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>>> <aashish.chaudhary at kitware.com> wrote:
>>> > Hi David,
>>> >
>>> > Absolutely! I was going to send an email today about it. In the past,
>>> it was
>>> > referred in the source article
>>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>>> issue,
>>> > we are working on a
>>> > source article targeting volume rendering in this series.
>>> >
>>> > I will send an email out this afternoon.
>>> >
>>> > - Aashish
>>> >
>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>> >>
>>> >> There seems to be some major changes occurring to VTK's volume
>>> >> rendering.  Can the developers who are involved let the us (the
>>> >> community) know what is going on?  Either by giving a summary on the
>>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>>> >> folks!  Thanks in advance.
>>> >>
>>> >>  - 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
>>>
>>>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



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

From david.lonie at kitware.com  Thu Oct  9 10:54:39 2014
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 9 Oct 2014 10:54:39 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
Message-ID: <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>

On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:

> I would say the text should look good and be legible when it's rendered...
>
> Would anybody here really prefer perfect backwards compatibility
> (including text illegibility) over better visualization...?


I agree, and hope most others would, too! Besides legibility, position is
the issue that could affect developers -- if anyone is using
vtkTextProperty::SetOrientation to rotate their text, my changes will push
the text around into a new location, easily breaking their code...

I've had to add switches to filters that preserve buggy/"legacy" behavior
by default, so I like to check these things before making such changes --
and more importantly, this leaves a breadcrumb in the archive for people
trying to figure out why their code broke! ;-)

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

From dave.demarle at kitware.com  Thu Oct  9 11:04:47 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 9 Oct 2014 11:04:47 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
Message-ID: <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>

My crystal ball says we will start the next release in January and my vote
is quality over compatibility in this case.


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

On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
wrote:

> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>
>> I would say the text should look good and be legible when it's rendered...
>>
>> Would anybody here really prefer perfect backwards compatibility
>> (including text illegibility) over better visualization...?
>
>
> I agree, and hope most others would, too! Besides legibility, position is
> the issue that could affect developers -- if anyone is using
> vtkTextProperty::SetOrientation to rotate their text, my changes will push
> the text around into a new location, easily breaking their code...
>
> I've had to add switches to filters that preserve buggy/"legacy" behavior
> by default, so I like to check these things before making such changes --
> and more importantly, this leaves a breadcrumb in the archive for people
> trying to figure out why their code broke! ;-)
>
> Dave
>
>
> _______________________________________________
> 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/20141009/1e88b6c6/attachment-0002.html>

From aashish.chaudhary at kitware.com  Thu Oct  9 11:07:32 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 11:07:32 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
 <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
Message-ID: <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>

On Thu, Oct 9, 2014 at 11:04 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> My crystal ball says we will start the next release in January and my vote
> is quality over compatibility in this case.
>
+1

>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>>
>>> I would say the text should look good and be legible when it's
>>> rendered...
>>>
>>> Would anybody here really prefer perfect backwards compatibility
>>> (including text illegibility) over better visualization...?
>>
>>
>> I agree, and hope most others would, too! Besides legibility, position is
>> the issue that could affect developers -- if anyone is using
>> vtkTextProperty::SetOrientation to rotate their text, my changes will push
>> the text around into a new location, easily breaking their code...
>>
>> I've had to add switches to filters that preserve buggy/"legacy" behavior
>> by default, so I like to check these things before making such changes --
>> and more importantly, this leaves a breadcrumb in the archive for people
>> trying to figure out why their code broke! ;-)
>>
>> Dave
>>
>>
>> _______________________________________________
>> 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
>
>
>


-- 



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

From david.lonie at kitware.com  Thu Oct  9 11:10:12 2014
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 9 Oct 2014 11:10:12 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
 <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
 <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>
Message-ID: <CA+=e1osD_uXN89hmDG_TizM01sqpxu3=W9Lt8+dZvTtcOg+p+Q@mail.gmail.com>

That's what I wanted to hear :-D I'll start the patch.

On Thu, Oct 9, 2014 at 11:07 AM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> On Thu, Oct 9, 2014 at 11:04 AM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> My crystal ball says we will start the next release in January and my
>> vote is quality over compatibility in this case.
>>
> +1
>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
>> wrote:
>>
>>> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>>>
>>>> I would say the text should look good and be legible when it's
>>>> rendered...
>>>>
>>>> Would anybody here really prefer perfect backwards compatibility
>>>> (including text illegibility) over better visualization...?
>>>
>>>
>>> I agree, and hope most others would, too! Besides legibility, position
>>> is the issue that could affect developers -- if anyone is using
>>> vtkTextProperty::SetOrientation to rotate their text, my changes will push
>>> the text around into a new location, easily breaking their code...
>>>
>>> I've had to add switches to filters that preserve buggy/"legacy"
>>> behavior by default, so I like to check these things before making such
>>> changes -- and more importantly, this leaves a breadcrumb in the archive
>>> for people trying to figure out why their code broke! ;-)
>>>
>>> Dave
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141009/524efcf7/attachment-0002.html>

From david.gobbi at gmail.com  Thu Oct  9 12:07:28 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 9 Oct 2014 10:07:28 -0600
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
Message-ID: <CANwS1=HanE95bcuywZ-EMd6hvDmr0bHu2dzvXv=mPTSMpG6tFA@mail.gmail.com>

This isn't directly related, but it seems to be a good time to plug
the vtkVolumeOutlineSource that can be used to annotate the bounds
of a volume, either with a wireframe or with translucent faces.
I've found it to be quite useful in my own volume interaction apps.
Images are attached (they're named after the corresponding .cxx
test files).

 - David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VolumeOutlineSourceClipped.png
Type: image/png
Size: 39142 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141009/946c8d97/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VolumeOutlineSource.png
Type: image/png
Size: 54651 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141009/946c8d97/attachment-0005.png>

From bill.lorensen at gmail.com  Thu Oct  9 12:40:24 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 12:40:24 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1osD_uXN89hmDG_TizM01sqpxu3=W9Lt8+dZvTtcOg+p+Q@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CAKME8fFuzWb5cmmo+aVh8sPRW6FS-rk9xcbAn36Xu2khTg_snQ@mail.gmail.com>
 <CA+=e1otm0o-AD0_pyaGqcXmmqbKBPmge_shnD=OLrJCYHzBM9Q@mail.gmail.com>
 <CANjZAi_0fqLHw0Y__=0+s6AGa6+Vh3DwOE3za5iM44Lixmg0_A@mail.gmail.com>
 <CAEw35Z_MLvD3dm5Uq6BH7W8PrY5MmuV0huD+VB9BhEOONN8bOg@mail.gmail.com>
 <CA+=e1osD_uXN89hmDG_TizM01sqpxu3=W9Lt8+dZvTtcOg+p+Q@mail.gmail.com>
Message-ID: <CADZJ4hMxDBe7mXb83Th0qshYJaSjPe5L-XB9WN6uSU0PNT_UEg@mail.gmail.com>

+1


On Thu, Oct 9, 2014 at 11:10 AM, David Lonie <david.lonie at kitware.com> wrote:
> That's what I wanted to hear :-D I'll start the patch.
>
> On Thu, Oct 9, 2014 at 11:07 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
>>
>> On Thu, Oct 9, 2014 at 11:04 AM, David E DeMarle
>> <dave.demarle at kitware.com> wrote:
>>>
>>> My crystal ball says we will start the next release in January and my
>>> vote is quality over compatibility in this case.
>>
>> +1
>>>
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Thu, Oct 9, 2014 at 10:54 AM, David Lonie <david.lonie at kitware.com>
>>> wrote:
>>>>
>>>> On Thu, Oct 9, 2014 at 10:45 AM, David Cole <DLRdave at aol.com> wrote:
>>>>>
>>>>> I would say the text should look good and be legible when it's
>>>>> rendered...
>>>>>
>>>>> Would anybody here really prefer perfect backwards compatibility
>>>>> (including text illegibility) over better visualization...?
>>>>
>>>>
>>>> I agree, and hope most others would, too! Besides legibility, position
>>>> is the issue that could affect developers -- if anyone is using
>>>> vtkTextProperty::SetOrientation to rotate their text, my changes will push
>>>> the text around into a new location, easily breaking their code...
>>>>
>>>> I've had to add switches to filters that preserve buggy/"legacy"
>>>> behavior by default, so I like to check these things before making such
>>>> changes -- and more importantly, this leaves a breadcrumb in the archive for
>>>> people trying to figure out why their code broke! ;-)
>>>>
>>>> Dave
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>>
>> --
>> | Aashish Chaudhary
>> | Technical Leader
>> | Kitware Inc.
>> | http://www.kitware.com/company/team/chaudhary.html
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>



-- 
Unpaid intern in BillsBasement at noware dot com


From bill.lorensen at gmail.com  Thu Oct  9 12:42:30 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 9 Oct 2014 12:42:30 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
Message-ID: <CADZJ4hPm8gRyiszqApxjc9QG=WmKP+je2ognZ2oBJQ9iyC1Z4Q@mail.gmail.com>

Aashish,

Configures fine after the patch.

Thanks,

Bill

On Thu, Oct 9, 2014 at 10:54 AM, Aashish Chaudhary
<aashish.chaudhary at kitware.com> wrote:
> Hi Bill,
>
> We found the issue and will push a fix shortly. It was related to build
> module all (and will show on only those dashboards which has it turned on).
> Said, that we will push a fix and monitor the dashboards.
>
> Thanks,
> Aashish
>
>
> On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
>>
>> Hi Bill,
>>
>> Somehow I didn't see it (or came to know about it). My apologies. Can you
>> point me to the
>> report please?
>>
>> Thanks,
>>
>>
>> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>>>
>>> Aashish,
>>> I hope someone can address the CMake issue I reported. It is related to
>>> the new volume rendering.
>>>
>>> Bill
>>>
>>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
>>>>
>>>> Thanks for the heads-up.
>>>>
>>>>  - David
>>>>
>>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
>>>> <aashish.chaudhary at kitware.com> wrote:
>>>> > Hi David,
>>>> >
>>>> > Absolutely! I was going to send an email today about it. In the past,
>>>> > it was
>>>> > referred in the source article
>>>> > (http://www.kitware.com/source/home/post/144). Also, for the upcoming
>>>> > issue,
>>>> > we are working on a
>>>> > source article targeting volume rendering in this series.
>>>> >
>>>> > I will send an email out this afternoon.
>>>> >
>>>> > - Aashish
>>>> >
>>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> There seems to be some major changes occurring to VTK's volume
>>>> >> rendering.  Can the developers who are involved let the us (the
>>>> >> community) know what is going on?  Either by giving a summary on the
>>>> >> mailing list or by adding to the roadmap on the wiki?  Transparency,
>>>> >> folks!  Thanks in advance.
>>>> >>
>>>> >>  - 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
>>>>
>>
>>
>>
>> --
>> | Aashish Chaudhary
>> | Technical Leader
>> | Kitware Inc.
>> | http://www.kitware.com/company/team/chaudhary.html
>
>
>
>
> --
> | Aashish Chaudhary
> | Technical Leader
> | Kitware Inc.
> | http://www.kitware.com/company/team/chaudhary.html



-- 
Unpaid intern in BillsBasement at noware dot com


From aashish.chaudhary at kitware.com  Thu Oct  9 15:41:42 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 9 Oct 2014 15:41:42 -0400
Subject: [vtk-developers] New volume rendering
In-Reply-To: <CADZJ4hPm8gRyiszqApxjc9QG=WmKP+je2ognZ2oBJQ9iyC1Z4Q@mail.gmail.com>
References: <CANwS1=FHMibsWZLcDTR2ng6pTC6qj0kPJep0VAXnZxnZ7hG33Q@mail.gmail.com>
 <CAEw35Z9OrnJiwsU-QpAweQ9iBy9_+dTQg2prt32jc-E7LvjRWQ@mail.gmail.com>
 <CANwS1=EmF=CW1t-vWKWXeEMqBNJ9gtzOeN0RBhMpMFvuySBsUA@mail.gmail.com>
 <CADZJ4hNjj8eQhE8JenARJdNqPsXP2f6hGyQpQNLqL-n9ttY8ug@mail.gmail.com>
 <CAEw35Z_=qVjUuRSay6jnXF4mqFa-LdnDeNNNsQPAv_GUPUmH1Q@mail.gmail.com>
 <CAEw35Z8bcnxta-SPTSZy8CO5048pFRtRaenUp3QCPAJgLBV0QQ@mail.gmail.com>
 <CADZJ4hPm8gRyiszqApxjc9QG=WmKP+je2ognZ2oBJQ9iyC1Z4Q@mail.gmail.com>
Message-ID: <CAEw35Z-KmO+BbkzCqw7ioFr6LErkhrYthhgQFRnenLF8pa8m6g@mail.gmail.com>

Thanks for the update Bill. The other dashboard failure should be gone as
well now.

Thanks,
Aashish

On Thu, Oct 9, 2014 at 12:42 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Aashish,
>
> Configures fine after the patch.
>
> Thanks,
>
> Bill
>
> On Thu, Oct 9, 2014 at 10:54 AM, Aashish Chaudhary
> <aashish.chaudhary at kitware.com> wrote:
> > Hi Bill,
> >
> > We found the issue and will push a fix shortly. It was related to build
> > module all (and will show on only those dashboards which has it turned
> on).
> > Said, that we will push a fix and monitor the dashboards.
> >
> > Thanks,
> > Aashish
> >
> >
> > On Thu, Oct 9, 2014 at 10:04 AM, Aashish Chaudhary
> > <aashish.chaudhary at kitware.com> wrote:
> >>
> >> Hi Bill,
> >>
> >> Somehow I didn't see it (or came to know about it). My apologies. Can
> you
> >> point me to the
> >> report please?
> >>
> >> Thanks,
> >>
> >>
> >> On Thu, Oct 9, 2014 at 10:02 AM, Bill Lorensen <bill.lorensen at gmail.com
> >
> >> wrote:
> >>>
> >>> Aashish,
> >>> I hope someone can address the CMake issue I reported. It is related to
> >>> the new volume rendering.
> >>>
> >>> Bill
> >>>
> >>> On Oct 9, 2014 9:56 AM, "David Gobbi" <david.gobbi at gmail.com> wrote:
> >>>>
> >>>> Thanks for the heads-up.
> >>>>
> >>>>  - David
> >>>>
> >>>> On Thu, Oct 9, 2014 at 7:35 AM, Aashish Chaudhary
> >>>> <aashish.chaudhary at kitware.com> wrote:
> >>>> > Hi David,
> >>>> >
> >>>> > Absolutely! I was going to send an email today about it. In the
> past,
> >>>> > it was
> >>>> > referred in the source article
> >>>> > (http://www.kitware.com/source/home/post/144). Also, for the
> upcoming
> >>>> > issue,
> >>>> > we are working on a
> >>>> > source article targeting volume rendering in this series.
> >>>> >
> >>>> > I will send an email out this afternoon.
> >>>> >
> >>>> > - Aashish
> >>>> >
> >>>> > On Thu, Oct 9, 2014 at 9:07 AM, David Gobbi <david.gobbi at gmail.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> There seems to be some major changes occurring to VTK's volume
> >>>> >> rendering.  Can the developers who are involved let the us (the
> >>>> >> community) know what is going on?  Either by giving a summary on
> the
> >>>> >> mailing list or by adding to the roadmap on the wiki?
> Transparency,
> >>>> >> folks!  Thanks in advance.
> >>>> >>
> >>>> >>  - 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
> >>>>
> >>
> >>
> >>
> >> --
> >> | Aashish Chaudhary
> >> | Technical Leader
> >> | Kitware Inc.
> >> | http://www.kitware.com/company/team/chaudhary.html
> >
> >
> >
> >
> > --
> > | Aashish Chaudhary
> > | Technical Leader
> > | Kitware Inc.
> > | http://www.kitware.com/company/team/chaudhary.html
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>



-- 



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

From david.gobbi at gmail.com  Fri Oct 10 08:07:07 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 10 Oct 2014 06:07:07 -0600
Subject: [vtk-developers] Dashboard build failures
Message-ID: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>

The dashboard build failures last night were my fault, I removed a
cmake variable that was marked "deprecated" but which was still being
used in a couple places.  The gerrit builds and continuous builds
yesterday didn't show any errors, it was only the clean builds of the
nightlies that broke.

I've reverted the problem commit.

 - David


From aashish.chaudhary at kitware.com  Fri Oct 10 09:53:33 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Fri, 10 Oct 2014 09:53:33 -0400
Subject: [vtk-developers] Overhaul of the rendering subsystem in VTK: Volume
	Rendering update
Message-ID: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>

Friends,


As reported back in July, we are in the process of a major overhaul of the
rendering subsystem in VTK. The July article (
http://www.kitware.com/source/home/post/144) focused primarily on our
efforts to move to OpenGL 2.1+ to support faster polygonal rendering.  The
October Source will contain an article focused on our rewrite of the
vtkGPURayCastMapper class to provide a faster, more portable and more
easily extensible volume mapper for regular rectilinear grids.



VTK has a long history of volume rendering, and unfortunately that history
is evident in the large selection of classes available to render volumes.
Each of these methods was state-of-the-art at the time, but given VTK?s 20+
year history many of these methods are now quite obsolete. One goal of this
effort is to reduce the number of volume mappers to ideally just two - one
that supports accelerated rendering on graphics hardware and another that
works in parallel on the CPU. In addition, the vtkSmartVolumeMapper would
help application developers by automatically choosing between these
techniques based on system performance.



In this first phase, we have created a replacement for vtkGPURayCastMapper.
Currently, this is available for testing from the VTK git repository (in
master branch, disabled by default). General instructions on how to build
VTK from the source is available at this URL:
http://www.vtk.org/Wiki/VTK/Git*. *In order to build the new mapper, enable
the Module_vtkRenderingVolumeOpenGLNew module in cmake (via -D
*Module_vtkRenderingVolumeOpenGL=ON*), in ccmake or cmake-gui. Once built,
it can be used via vtkSmartVolumeMapper or used directly. Once sufficient
testing by the community has been performed, this class will replace the
old vtkGPURayCastMapper.  In addition, we are adding this new mapper to the
OpenGL2 module.  Availability of the new mapper with OpenGL2 module will
improve the management of textures in the mapper and eventually benefitting
both forms of rendering (geometry and volume) by sharing common code
between them.


Please contact us if you have any questions or encounter any issues.


Thanks,

-- 



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

From jatinparekh93 at gmail.com  Sun Oct 12 05:11:46 2014
From: jatinparekh93 at gmail.com (Jatin Parekh)
Date: Sun, 12 Oct 2014 14:41:46 +0530
Subject: [vtk-developers] vtkMultiThreader Class Error in Output
Message-ID: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>

Hi!
I have a simple code as shown below. I am passing the same parameter to a
function via a normal function call and another via the vtkMultiThreader
SpawnThread. However, I am unable to get the expected output.

*#include <iostream>*

*#include <vtkMultiThreader.h>*

*void *ThreadedFunction(void *data)*

*{*

*    std::cout << data << std::endl;*

*}*

*int main()*

*{*

*    vtkMultiThreader *threaded = vtkMultiThreader::New();*

*    void *x = (void *)1;*


 *    std::cout << "Non Threaded function call:" << std::endl;*

*    ThreadedFunction(x);*


 *    std::cout << "Now in threads:" << std::endl;*

*    threaded->SpawnThread(ThreadedFunction, x);*

*    return 0;*

*}*


If I understand correctly, the output for both, the threaded function
call as well as non threaded function call should be the same.

But it gives me the following output:

*Non Threaded function call:*

*0x1*

*Now in threads:*

*0x10a89d0*


SO, the non-threaded function call displays the correct value whereas
the MultiThreader call displays some different value.

I don't get the reason why the 2 function calls give different
outputs. Are they supposed to be different? If yes, then can someone
please explain why it is supposed to be so?

If no, then any ideas/hints on where I could possibly be making an error?


Thanks!

Jatin Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141012/79afa9d0/attachment-0002.html>

From berk.geveci at kitware.com  Sun Oct 12 09:13:21 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Sun, 12 Oct 2014 09:13:21 -0400
Subject: [vtk-developers] vtkMultiThreader Class Error in Output
In-Reply-To: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>
References: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>
Message-ID: <CAE32kpXiyza+4oFoS8E=Lbg4boWD3etD9VJNiMEn-1jBOjFgjA@mail.gmail.com>

Check out the documentation of SetSingleMethod(), which reads:

> Set the SingleMethod to f() and the UserData field of the ThreadInfo that
is passed to it will be data.
> This method (and all the methods passed to SetMultipleMethod) must be of
type
> vtkThreadFunctionType and must take a single argument of type void *.

The argument passed to SetSingleMethod() is wrapped by the ThreadInfo
struct and passed to the method. Something like:

cout <<  ((vtkMultiThreader::ThreadInfo*)data)->UserData << endl

should do the trick. Also see:

http://www.vtk.org/doc/nightly/html/classvtkMultiThreader_1_1ThreadInfo.html

Best,
-berk

On Sun, Oct 12, 2014 at 5:11 AM, Jatin Parekh <jatinparekh93 at gmail.com>
wrote:

> Hi!
> I have a simple code as shown below. I am passing the same parameter to a
> function via a normal function call and another via the vtkMultiThreader
> SpawnThread. However, I am unable to get the expected output.
>
> *#include <iostream>*
>
> *#include <vtkMultiThreader.h>*
>
> *void *ThreadedFunction(void *data)*
>
> *{*
>
> *    std::cout << data << std::endl;*
>
> *}*
>
> *int main()*
>
> *{*
>
> *    vtkMultiThreader *threaded = vtkMultiThreader::New();*
>
> *    void *x = (void *)1;*
>
>
>  *    std::cout << "Non Threaded function call:" << std::endl;*
>
> *    ThreadedFunction(x);*
>
>
>  *    std::cout << "Now in threads:" << std::endl;*
>
> *    threaded->SpawnThread(ThreadedFunction, x);*
>
> *    return 0;*
>
> *}*
>
>
> If I understand correctly, the output for both, the threaded function call as well as non threaded function call should be the same.
>
> But it gives me the following output:
>
> *Non Threaded function call:*
>
> *0x1*
>
> *Now in threads:*
>
> *0x10a89d0*
>
>
> SO, the non-threaded function call displays the correct value whereas the MultiThreader call displays some different value.
>
> I don't get the reason why the 2 function calls give different outputs. Are they supposed to be different? If yes, then can someone please explain why it is supposed to be so?
>
> If no, then any ideas/hints on where I could possibly be making an error?
>
>
> Thanks!
>
> Jatin Parekh
>
>
> _______________________________________________
> 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/20141012/d67ad0ac/attachment-0002.html>

From jatinparekh93 at gmail.com  Sun Oct 12 12:49:42 2014
From: jatinparekh93 at gmail.com (Jatin Parekh)
Date: Sun, 12 Oct 2014 22:19:42 +0530
Subject: [vtk-developers] vtkMultiThreader Class Error in Output
In-Reply-To: <CAE32kpXiyza+4oFoS8E=Lbg4boWD3etD9VJNiMEn-1jBOjFgjA@mail.gmail.com>
References: <CAA5y8x79i1YhQMHQJT=r=TCqrV8EtwU-cBrxm=6ZNcne5sJ5Og@mail.gmail.com>
 <CAE32kpXiyza+4oFoS8E=Lbg4boWD3etD9VJNiMEn-1jBOjFgjA@mail.gmail.com>
Message-ID: <CAA5y8x7ghq91wOBNnjDqb6vJfy9cExxFXjsDLJRu6Z5+h1iiZw@mail.gmail.com>

Hi Berk,
That worked.
Thanks for your quick reply!

Jatin Parekh

On Sun, Oct 12, 2014 at 6:43 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Check out the documentation of SetSingleMethod(), which reads:
>
> > Set the SingleMethod to f() and the UserData field of the ThreadInfo
> that is passed to it will be data.
> > This method (and all the methods passed to SetMultipleMethod) must be of
> type
> > vtkThreadFunctionType and must take a single argument of type void *.
>
> The argument passed to SetSingleMethod() is wrapped by the ThreadInfo
> struct and passed to the method. Something like:
>
> cout <<  ((vtkMultiThreader::ThreadInfo*)data)->UserData << endl
>
> should do the trick. Also see:
>
>
> http://www.vtk.org/doc/nightly/html/classvtkMultiThreader_1_1ThreadInfo.html
>
> Best,
> -berk
>
> On Sun, Oct 12, 2014 at 5:11 AM, Jatin Parekh <jatinparekh93 at gmail.com>
> wrote:
>
>> Hi!
>> I have a simple code as shown below. I am passing the same parameter to a
>> function via a normal function call and another via the vtkMultiThreader
>> SpawnThread. However, I am unable to get the expected output.
>>
>> *#include <iostream>*
>>
>> *#include <vtkMultiThreader.h>*
>>
>> *void *ThreadedFunction(void *data)*
>>
>> *{*
>>
>> *    std::cout << data << std::endl;*
>>
>> *}*
>>
>> *int main()*
>>
>> *{*
>>
>> *    vtkMultiThreader *threaded = vtkMultiThreader::New();*
>>
>> *    void *x = (void *)1;*
>>
>>
>>  *    std::cout << "Non Threaded function call:" << std::endl;*
>>
>> *    ThreadedFunction(x);*
>>
>>
>>  *    std::cout << "Now in threads:" << std::endl;*
>>
>> *    threaded->SpawnThread(ThreadedFunction, x);*
>>
>> *    return 0;*
>>
>> *}*
>>
>>
>> If I understand correctly, the output for both, the threaded function call as well as non threaded function call should be the same.
>>
>> But it gives me the following output:
>>
>> *Non Threaded function call:*
>>
>> *0x1*
>>
>> *Now in threads:*
>>
>> *0x10a89d0*
>>
>>
>> SO, the non-threaded function call displays the correct value whereas the MultiThreader call displays some different value.
>>
>> I don't get the reason why the 2 function calls give different outputs. Are they supposed to be different? If yes, then can someone please explain why it is supposed to be so?
>>
>> If no, then any ideas/hints on where I could possibly be making an error?
>>
>>
>> Thanks!
>>
>> Jatin Parekh
>>
>>
>> _______________________________________________
>> 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/20141012/858b8c82/attachment-0002.html>

From ben.boeckel at kitware.com  Mon Oct 13 08:33:53 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 13 Oct 2014 08:33:53 -0400
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
Message-ID: <20141013123353.GA26441@megas.kitwarein.com>

On Fri, Oct 10, 2014 at 06:07:07 -0600, David Gobbi wrote:
> The dashboard build failures last night were my fault, I removed a
> cmake variable that was marked "deprecated" but which was still being
> used in a couple places.  The gerrit builds and continuous builds
> yesterday didn't show any errors, it was only the clean builds of the
> nightlies that broke.
> 
> I've reverted the problem commit.

If it's really deprecated, we can use a variable_watch command on it to
warn when it is being used.

--Ben


From berk.geveci at kitware.com  Mon Oct 13 10:16:43 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Mon, 13 Oct 2014 10:16:43 -0400
Subject: [vtk-developers] [vtkusers] Missing update extent request in
	vtkExtractVOI?
In-Reply-To: <543AC335.2040607@student.hpi.uni-potsdam.de>
References: <54391E4E.8050907@student.hpi.uni-potsdam.de>
 <543AC335.2040607@student.hpi.uni-potsdam.de>
Message-ID: <CAE32kpUMhinzw_ZfJ6QpY-nwQ0LW0pq09f+tLVyZ1Rx6VPxJXQ@mail.gmail.com>

We completely rewrote vtkExtractVOI a few months ago and it doesn't look
like we didn't do a great job in fully evaluating it. I will spend some
quality time with it in the next few weeks.

Best,
-berk

On Sun, Oct 12, 2014 at 2:06 PM, Karsten Tausche <
karsten.tausche at student.hpi.uni-potsdam.de> wrote:

>  I just realized that calling SetUpdateExtentToWholeExtent() on a
> downstream algorithm (polyData in the example code) "fixes" this error.
>
>
> On 2014-10-11 14:10, Karsten Tausche wrote:
>
> Hi everyone,
>
> I tried to use vtkExtractVOI to decrease the resolution of a
> vtkImageData/vtkStructuredPoints data set. This works fine when I set the
> sample rate before I connect the filter to the pipeline. But changing the
> sample rate while rendering always results in an error like this:
>
> "ERROR: In
> ..\..\..\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx, line
> 857
> vtkCompositeDataPipeline (0000000005D6E1A0): The update extent specified
> in the information for output port 0 on algorithm
> vtkExtractVOI(0000000005D92710) is 0 10 0 10 0 0, which is outside the
> whole extent 0 9 0 10 0 0."
>
> This behavior also depends on the initial sample rate. With the defaults
> (1, 1, 1), the error message pops up after changing the rate, and the
> filter seems produce the expected result. When I set different initial
> values and increase them while rendering, I get the error message above,
> but the filter result seems correct. When decreasing the sample rate, I
> don't get an error, but the filter decreases the size of the rendered
> image.
>
> I'm using the current VTK master. I appended a small example the produces
> this error; it doesn't render any visible points but I didn't know how to
> enforce the required updates without adding the filter to a rendering
> pipeline.
>
> BTW the error also occurs with vtkStructuredGrid+vtkExtractGrid.
>
> Thanks,
> Karsten
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20141013/41c99200/attachment-0002.html>

From david.gobbi at gmail.com  Mon Oct 13 12:35:14 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 13 Oct 2014 10:35:14 -0600
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <20141013123353.GA26441@megas.kitwarein.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
Message-ID: <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>

The problem is, when I add variable_watch(), it warns the next time
FindPythonLibs is called.  And the message it prints isn't informative.

On Mon, Oct 13, 2014 at 6:33 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Fri, Oct 10, 2014 at 06:07:07 -0600, David Gobbi wrote:
>> The dashboard build failures last night were my fault, I removed a
>> cmake variable that was marked "deprecated" but which was still being
>> used in a couple places.  The gerrit builds and continuous builds
>> yesterday didn't show any errors, it was only the clean builds of the
>> nightlies that broke.
>>
>> I've reverted the problem commit.
>
> If it's really deprecated, we can use a variable_watch command on it to
> warn when it is being used.
>
> --Ben


From ben.boeckel at kitware.com  Mon Oct 13 14:22:37 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 13 Oct 2014 14:22:37 -0400
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
 <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
Message-ID: <20141013182237.GA4640@megas.kitwarein.com>

On Mon, Oct 13, 2014 at 10:35:14 -0600, David Gobbi wrote:
> The problem is, when I add variable_watch(), it warns the next time
> FindPythonLibs is called.  And the message it prints isn't informative.

You could check the type of access being done to the variable. Setting
the watch after the find_package for PythonLibs should be sufficient
(unless we're calling it multiple times).

--Ben


From david.gobbi at gmail.com  Mon Oct 13 14:30:24 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 13 Oct 2014 12:30:24 -0600
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <20141013182237.GA4640@megas.kitwarein.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
 <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
 <20141013182237.GA4640@megas.kitwarein.com>
Message-ID: <CANwS1=GZ1sDU_OKOksXuw_5GFShyBE9nnshZwuEcxnS6REvJ=Q@mail.gmail.com>

On Mon, Oct 13, 2014 at 12:22 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Mon, Oct 13, 2014 at 10:35:14 -0600, David Gobbi wrote:
>> The problem is, when I add variable_watch(), it warns the next time
>> FindPythonLibs is called.  And the message it prints isn't informative.
>
> You could check the type of access being done to the variable. Setting
> the watch after the find_package for PythonLibs should be sufficient
> (unless we're calling it multiple times).

It is called multiple times.  It would be really convenient if cmake had a
variable_unwatch() function.

Or even better, the cmake set() function could have a DEPRECATED
flag so that any use of the variable outside that set() call would trigger
a deprecation warning.

 - David


From ben.boeckel at kitware.com  Mon Oct 13 15:03:18 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 13 Oct 2014 15:03:18 -0400
Subject: [vtk-developers] Dashboard build failures
In-Reply-To: <CANwS1=GZ1sDU_OKOksXuw_5GFShyBE9nnshZwuEcxnS6REvJ=Q@mail.gmail.com>
References: <CANwS1=FY38EE06UENxu64FMMVdooR6SjBc9Tq8QTpnzJhmGO6A@mail.gmail.com>
 <20141013123353.GA26441@megas.kitwarein.com>
 <CANwS1=F+cm-0AQW062RdXf6cx+ydZej0UA4UhQJVoZo3Vu3s1w@mail.gmail.com>
 <20141013182237.GA4640@megas.kitwarein.com>
 <CANwS1=GZ1sDU_OKOksXuw_5GFShyBE9nnshZwuEcxnS6REvJ=Q@mail.gmail.com>
Message-ID: <20141013190318.GA28877@megas.kitwarein.com>

On Mon, Oct 13, 2014 at 12:30:24 -0600, David Gobbi wrote:
> It is called multiple times.  It would be really convenient if cmake had a
> variable_unwatch() function.

CMake can have multiple watches on a variable; how would you tell which
one to remove? I suppose a result variable could hold a token for it,
but then you have the problem of getting that variable passed around
(the cache defeating the purpose here; global properties not really
being the right thing either).

> Or even better, the cmake set() function could have a DEPRECATED
> flag so that any use of the variable outside that set() call would trigger
> a deprecation warning.

A bug report would be nice for this ;) .

--Ben


From david.gobbi at gmail.com  Tue Oct 14 07:41:39 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 14 Oct 2014 05:41:39 -0600
Subject: [vtk-developers] Obsolete PYTHON_INCLUDE_PATH in IBM xlc dashboard
Message-ID: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>

Hi Dave,

The xlC dashboard has cmake warnings since my changes to
FindPythonLibs.cmake yesterday.  Can you modify its build script
(aix_vtk_xlC.cmake according to the notes) by replacing the
deprecated PYTHON_INCLUDE_PATH variable at line 107 with
PYTHON_INCLUDE_DIR?  That will clear the warning.

Cheers,

 - David


From dave.demarle at kitware.com  Tue Oct 14 11:17:47 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 14 Oct 2014 11:17:47 -0400
Subject: [vtk-developers] Obsolete PYTHON_INCLUDE_PATH in IBM xlc
	dashboard
In-Reply-To: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>
References: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>
Message-ID: <CANjZAi--3zSTiVD7MCNd4AWFpimr7+MWDnQa1A_zSSMaCFRB3A@mail.gmail.com>

done
should see it take effect tomorrow



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

On Tue, Oct 14, 2014 at 7:41 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Dave,
>
> The xlC dashboard has cmake warnings since my changes to
> FindPythonLibs.cmake yesterday.  Can you modify its build script
> (aix_vtk_xlC.cmake according to the notes) by replacing the
> deprecated PYTHON_INCLUDE_PATH variable at line 107 with
> PYTHON_INCLUDE_DIR?  That will clear the warning.
>
> Cheers,
>
>  - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141014/75bad3df/attachment-0002.html>

From david.gobbi at gmail.com  Tue Oct 14 11:22:04 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 14 Oct 2014 09:22:04 -0600
Subject: [vtk-developers] Obsolete PYTHON_INCLUDE_PATH in IBM xlc
	dashboard
In-Reply-To: <CANjZAi--3zSTiVD7MCNd4AWFpimr7+MWDnQa1A_zSSMaCFRB3A@mail.gmail.com>
References: <CANwS1=HgwGnwhhm0X3eJN3AC+PXrrhcwDkhZTZ6vgQVDbjUJzQ@mail.gmail.com>
 <CANjZAi--3zSTiVD7MCNd4AWFpimr7+MWDnQa1A_zSSMaCFRB3A@mail.gmail.com>
Message-ID: <CANwS1=GAMNPZOC=TXFrPxPEsZQhYaoaNrCPjNFCVrFnePBiK2Q@mail.gmail.com>

Thanks!

On Tue, Oct 14, 2014 at 9:17 AM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> done
> should see it take effect tomorrow
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Oct 14, 2014 at 7:41 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Hi Dave,
>>
>> The xlC dashboard has cmake warnings since my changes to
>> FindPythonLibs.cmake yesterday.  Can you modify its build script
>> (aix_vtk_xlC.cmake according to the notes) by replacing the
>> deprecated PYTHON_INCLUDE_PATH variable at line 107 with
>> PYTHON_INCLUDE_DIR?  That will clear the warning.
>>
>> Cheers,
>>
>>  - David
>
>


From jeff.baumes at kitware.com  Wed Oct 15 09:09:40 2014
From: jeff.baumes at kitware.com (Jeff Baumes)
Date: Wed, 15 Oct 2014 09:09:40 -0400
Subject: [vtk-developers] [vtkusers] Creating the dual of a graph -
 planar face traversal - vtkBoostGraphAdapter
In-Reply-To: <CAEQ0100JxHyWZ+Wnix_42EJ1HCASbYsrg5Ecqz_R=o+aw-fsqA@mail.gmail.com>
References: <CAEQ0103UjvqR9nA1G3p83DikZGtOn7hYjJmwLH05OuPzh-sTSg@mail.gmail.com>
 <CANuLzQFbX2EBryJjP=Gn7m2xz0ise4dY2so3eC6sDmZnpEzF=g@mail.gmail.com>
 <CAEQ0100JxHyWZ+Wnix_42EJ1HCASbYsrg5Ecqz_R=o+aw-fsqA@mail.gmail.com>
Message-ID: <CANuLzQEE1svLFcyj32bHvaybH9b8h+52_mU66NnoREpgrbq5xA@mail.gmail.com>

This is starting to get beyond me. Here is what I could find. If you search
for iterator_property_map in

http://www.boost.org/doc/libs/1_55_0/boost/property_map/property_map.hpp

you can see that operator[] is clearly defined. I have a feeling this may
be a const issue, or perhaps the fact that the planar_dual algorithm
assumes you can do this:

edge_to_face[e] = current_face;

while iterator_property_map may produce a map that is read-only:

http://www.boost.org/doc/libs/1_37_0/libs/property_map/iterator_property_map.html
"... converts any random access iterator into a Lvalue Property Map ..."

http://www.boost.org/doc/libs/1_37_0/libs/property_map/LvaluePropertyMap.html
"... may be mutable or non-mutable ..."

Perhaps that points you in the right direction.

Jeff







On Wed, Oct 8, 2014 at 5:27 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com>
wrote:

> Thank you for replying so fast!
>
> I edited the vtkBoostGraphAdapter.h:
>
>   struct vtkGraphIndexMap;
>
>
>   template <>
>
>   struct property_traits<vtkGraphIndexMap>
>
>     {
>
>     typedef vtkIdType value_type;
>
>     typedef vtkIdType reference;
>
>     typedef vtkIdType key_type;
>
>     typedef readable_property_map_tag category;
>
>     };
>
>
>
>     struct vtkGraphIndexMap
>
>     {
>
>     property_traits<vtkGraphIndexMap>::reference operator[](const
> property_traits<vtkGraphIndexMap>::key_type& key)
>
>       {
>
>         return key;
>
>       }
>
>     };
>
>
>   inline property_traits<vtkGraphIndexMap>::reference
>
>   get(
>
>     vtkGraphIndexMap vtkNotUsed(arr),
>
>     property_traits<vtkGraphIndexMap>::key_type key)
>
>   {
>
>     return key;
>
>   }
>
> I deleted the lines that fill the index map also. Unfortunately I still
> get these errors:
>
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>    vtkEdgeType, std::__1::less<long long>,
>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>    long, vtkEdgeType> > > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>    No viable overloaded operator[] for type 'const
>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>    'iterator_property_map<typename vertex_vector_t::iterator,
>    boost::vtkGraphIndexMap>')
>
> It seems to me that there's no operator[] for the iterator_property_map.
> Am I missing something?
>
> Thanks again!
>
> Szilard
>
> 2014-10-08 21:13 GMT+02:00 Jeff Baumes <jeff.baumes at kitware.com>:
>
>> In your code, you are retrieving a vtkGraphIndexMap with:
>>
>> property_map<vtkUndirectedGraph*, edge_index_t>::type e_index =
>> get(edge_index, in);
>>
>> vtkGraphIndexMap is intended to be read-only and is already populated
>> with indices 0 through N-1, which are accessed with get(). It's actually an
>> identity map by index since indices are always in order, as you can see
>> here:
>>
>>
>> https://github.com/Kitware/VTK/blob/master/Infovis/BoostGraphAlgorithms/vtkBoostGraphAdapter.h#L1032-L1049
>>
>> So I would suggest leaving out your initialization loop on lines 43-45.
>>
>> Now, the remaining errors seem to require an operator[] on the
>> EdgeIndexMap, which is not currently implemented in vtkBoostGraphAdapter.h.
>> The needed code would be to replace the definition of vtkGraphPropertyMap
>> with something like this (not tested):
>>
>> struct vtkGraphIndexMap; // forward declaration
>>
>> template <>
>> struct property_traits<vtkGraphIndexMap>
>> {
>>   typedef vtkIdType value_type;
>>   typedef vtkIdType reference;
>>   typedef vtkIdType key_type;
>>   typedef readable_property_map_tag category;
>> };
>>
>> struct vtkGraphIndexMap
>> {
>>   property_traits<vtkGraphIndexMap>::reference operator[](const
>> property_traits<vtkGraphIndexMap>::key_type& b)
>>     {
>>     return key;
>>     }
>> };
>>
>>
>> HTH,
>> Jeff
>>
>> On Wed, Oct 8, 2014 at 2:12 PM, Szil?rd Szal?ki <szilardszaloki at gmail.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to write an algorithm which creates the dual of a graph. To
>>> check whether the graph is planar or not I use the *Boyer-Myrvold
>>> planarity test* (Boost implementation) through the vtkBoostGraphAdapter.
>>> That works fine (only on vtkUndirectedGraph-s but that's OK for now).
>>> (http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/boyer_myrvold.html)
>>>
>>> To create the dual I need to traverse the faces of the planar graph for
>>> which I also have a Boost tool called the planar_face_traversal_visitor.
>>> (
>>> http://www.boost.org/doc/libs/1_56_0/libs/graph/doc/planar_face_traversal.html
>>> )
>>> There's a guy, Aaron Windsor who implemented the appropriate visitor
>>> class that is able to create the dual of a graph in Boost.
>>> (https://github.com/aaw/boost_planar_graph_dual)
>>> That also works fine using only Boost but I'd like to adapt this feature
>>> as well using vtkBoostGraphAdapter.
>>>
>>> Here's my code: http://pastebin.com/g0Mtw6Ph
>>>
>>> These are my errors:
>>>
>>>    - *vtkDualGraph.cpp*:44:9: No matching function for call to 'put'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>>    vtkEdgeType, std::__1::less<long long>,
>>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > > &>'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::map<long long,
>>>    vtkEdgeType, std::__1::less<long long>,
>>>    std::__1::allocator<std::__1::pair<const long long, vtkEdgeType> > > *>,
>>>    boost::vtkGraphIndexMap, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > >, std::__1::map<long long, vtkEdgeType,
>>>    std::__1::less<long long>, std::__1::allocator<std::__1::pair<const long
>>>    long, vtkEdgeType> > > &>'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:302:19:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>>    - /usr/local/boost_1_56_0/boost/property_map/*property_map.hpp*:309:5:
>>>    No viable overloaded operator[] for type 'const
>>>    boost::iterator_property_map<std::__1::__wrap_iter<std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > *>,
>>>    boost::vtkGraphIndexMap, std::__1::set<long long, std::__1::less<long
>>>    long>, std::__1::allocator<long long> >, std::__1::set<long long,
>>>    std::__1::less<long long>, std::__1::allocator<long long> > &>'
>>>    - /usr/local/boost_1_56_0/boost/*planar_dual.hpp*:38:38: No viable
>>>    overloaded operator[] for type 'edge_to_face_map_t' (aka
>>>    'iterator_property_map<typename vertex_vector_t::iterator,
>>>    boost::vtkGraphIndexMap>')
>>>
>>> It seems I cannot provide an appropriate EdgeIndexMap parameter to the
>>> put function in the 44th line. The vtkBoostGraphAdapter says that we
>>> can use VTK arrays as property maps, I tried that one as well, with no
>>> success. I've been dealing with this, reading the source code really deep
>>> and trying a couple of things in the past few days but I can't really
>>> figure out what the problem is. Is the vtkBoostGraphAdapter properly
>>> prepared for this kind of usage?
>>>
>>> Any kind of help appreciated!
>>>
>>> Thanks in advance!
>>>
>>> Szilard
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20141015/1203dc3f/attachment-0002.html>

From david.lonie at kitware.com  Wed Oct 15 10:19:42 2014
From: david.lonie at kitware.com (David Lonie)
Date: Wed, 15 Oct 2014 10:19:42 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
Message-ID: <CA+=e1ovz5msMsH3gE8HoTbip-aR2xwC91t4U4CO8ahr9UFf08A@mail.gmail.com>

Hi all,

I finished up a patch to better handle rotated and aligned text, and
cleaned up a few other rough spots in the text rendering system.

Looking for reviewers:

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

Dave

On Wed, Oct 8, 2014 at 3:52 PM, David Lonie <david.lonie at kitware.com> wrote:

> Hi Folks,
>
> We've noticed some odd behavior while rotating 2D vtkTextActors. There are
> two ways to do it:
>
> vtkTextActor::SetOrientation(degrees), or
> vtkTextProperty::SetOrientation(degrees)
>
> These behave very differently, especially when alignment flags are used --
> see the attached image for an example. The bottom two rows show this most
> clearly.
>
> Rotating the text property will rotate the text as it is being rendered
> into the texture's buffer. This gives great antialiasing on the rotated
> text, but gives bad alignment results, since the vtkTextActor is currently
> aligning the entire texture to its position, rather than the text inside
> the texture.
>
> Rotating the actor gives the expected alignment behavior, but bad
> antialiasing. This is because the text is rendered into the texture without
> rotation, and then rotated afterwards.
>
> Combining the two (top row) gives the worst of both cases.
>
> I'd like to fix the text actor to align things "correctly" when the text
> property is rotated. So my questions:
>
> 1) Is this behavior expected due to backwards compatibility?
> 2) If not, is this a good time to fix this? (e.g. are there any upcoming
> releases I should hold off for?)
>
> Thanks,
> Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141015/b15172ea/attachment-0002.html>

From tom.valleau at gmail.com  Wed Oct 15 15:15:24 2014
From: tom.valleau at gmail.com (filez41)
Date: Wed, 15 Oct 2014 12:15:24 -0700 (PDT)
Subject: [vtk-developers] VTK 5.6 to 6.1
Message-ID: <1413400524957-5729159.post@n5.nabble.com>

I'm converting some software from VTK 5.6 to 6.1, and the GetProducerPort()
function in vtkDataObject has been deprecated. 

I found details on the deprecated code and what to replace it with here:
http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_GetProducerPort

I want to confirm that I understand the change. 

Old Code:



New Code:


Is this the correct change?  The reason I'm unsure is because previously we
were using a vtkAlgorithmOutput as an intermediate step, and in 6.1 we have
to skip that completely?



--
View this message in context: http://vtk.1045678.n5.nabble.com/VTK-5-6-to-6-1-tp5729159.html
Sent from the VTK - Dev mailing list archive at Nabble.com.


From aashish.chaudhary at kitware.com  Thu Oct 16 12:31:37 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 16 Oct 2014 12:31:37 -0400
Subject: [vtk-developers] Overhaul of the rendering subsystem in VTK:
	Volume Rendering update
In-Reply-To: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>
References: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>
Message-ID: <CAEw35Z_tVedsuN_TMVyH8bnB-TdXvmX9k2Ua1FWHy0tZ2XJDwg@mail.gmail.com>

Friends,

As referred earlier, we are continuously working on improving the volume
rendering. As part of next set of delivery,  we are going to bring our
first OpenGL2 volume mapper to the OpenGL2 backend.
We have a branch that will get merged today and* it should only affect the
dashboards and code base switched to OpenGL2 backend*. We will continue to
improve the integration and will use and improve the
existing OpenGL2 backend code as necessary.

If you have any questions of concerns or if you find in any ways its
affecting your regular builds that uses OpenGL(default, and not OpenGL2)
 backend then let us know as soon as possible.

Thanks,


On Fri, Oct 10, 2014 at 9:53 AM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Friends,
>
>
> As reported back in July, we are in the process of a major overhaul of the
> rendering subsystem in VTK. The July article (
> http://www.kitware.com/source/home/post/144) focused primarily on our
> efforts to move to OpenGL 2.1+ to support faster polygonal rendering.  The
> October Source will contain an article focused on our rewrite of the
> vtkGPURayCastMapper class to provide a faster, more portable and more
> easily extensible volume mapper for regular rectilinear grids.
>
>
>
> VTK has a long history of volume rendering, and unfortunately that history
> is evident in the large selection of classes available to render volumes.
> Each of these methods was state-of-the-art at the time, but given VTK?s 20+
> year history many of these methods are now quite obsolete. One goal of this
> effort is to reduce the number of volume mappers to ideally just two - one
> that supports accelerated rendering on graphics hardware and another that
> works in parallel on the CPU. In addition, the vtkSmartVolumeMapper would
> help application developers by automatically choosing between these
> techniques based on system performance.
>
>
>
> In this first phase, we have created a replacement for
> vtkGPURayCastMapper. Currently, this is available for testing from the VTK
> git repository (in master branch, disabled by default). General
> instructions on how to build VTK from the source is available at this URL:
> http://www.vtk.org/Wiki/VTK/Git*. *In order to build the new mapper,
> enable the Module_vtkRenderingVolumeOpenGLNew module in cmake (via -D
> *Module_vtkRenderingVolumeOpenGL=ON*), in ccmake or cmake-gui. Once
> built, it can be used via vtkSmartVolumeMapper or used directly. Once
> sufficient testing by the community has been performed, this class will
> replace the old vtkGPURayCastMapper.  In addition, we are adding this new
> mapper to the OpenGL2 module.  Availability of the new mapper with OpenGL2
> module will improve the management of textures in the mapper and eventually
> benefitting both forms of rendering (geometry and volume) by sharing common
> code between them.
>
>
> Please contact us if you have any questions or encounter any issues.
>
>
> Thanks,
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



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

From david.lonie at kitware.com  Fri Oct 17 10:33:17 2014
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 17 Oct 2014 10:33:17 -0400
Subject: [vtk-developers] vtkTextActor rotation
In-Reply-To: <CA+=e1ovz5msMsH3gE8HoTbip-aR2xwC91t4U4CO8ahr9UFf08A@mail.gmail.com>
References: <CA+=e1osv+2mC4KmO7QxGxBb2jnoLTLgu=_YxorgLF8+5fZFTSw@mail.gmail.com>
 <CA+=e1ovz5msMsH3gE8HoTbip-aR2xwC91t4U4CO8ahr9UFf08A@mail.gmail.com>
Message-ID: <CA+=e1ov5Ro6DLDdOLUpaaBOK42_CONB4gR5wv0hefeOs+XqUsg@mail.gmail.com>

Update: Still looking for reviewers! =) There are a handful of patches, but
most of them are quite small...

On Wed, Oct 15, 2014 at 10:19 AM, David Lonie <david.lonie at kitware.com>
wrote:

> Hi all,
>
> I finished up a patch to better handle rotated and aligned text, and
> cleaned up a few other rough spots in the text rendering system.
>
> Looking for reviewers:
>
> http://review.source.kitware.com/#/t/4851/
>
> Dave
>
> On Wed, Oct 8, 2014 at 3:52 PM, David Lonie <david.lonie at kitware.com>
> wrote:
>
>> Hi Folks,
>>
>> We've noticed some odd behavior while rotating 2D vtkTextActors. There
>> are two ways to do it:
>>
>> vtkTextActor::SetOrientation(degrees), or
>> vtkTextProperty::SetOrientation(degrees)
>>
>> These behave very differently, especially when alignment flags are used
>> -- see the attached image for an example. The bottom two rows show this
>> most clearly.
>>
>> Rotating the text property will rotate the text as it is being rendered
>> into the texture's buffer. This gives great antialiasing on the rotated
>> text, but gives bad alignment results, since the vtkTextActor is currently
>> aligning the entire texture to its position, rather than the text inside
>> the texture.
>>
>> Rotating the actor gives the expected alignment behavior, but bad
>> antialiasing. This is because the text is rendered into the texture without
>> rotation, and then rotated afterwards.
>>
>> Combining the two (top row) gives the worst of both cases.
>>
>> I'd like to fix the text actor to align things "correctly" when the text
>> property is rotated. So my questions:
>>
>> 1) Is this behavior expected due to backwards compatibility?
>> 2) If not, is this a good time to fix this? (e.g. are there any upcoming
>> releases I should hold off for?)
>>
>> Thanks,
>> Dave
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141017/7b7df8f5/attachment-0002.html>

From andreas.choi at gmail.com  Mon Oct 20 08:54:19 2014
From: andreas.choi at gmail.com (Jinhyeok Choi)
Date: Mon, 20 Oct 2014 21:54:19 +0900
Subject: [vtk-developers] Update only one renderer,
	(multiple renderers in a render window)
Message-ID: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>

Hi,

I have a question for redrawing a render window.
I only know the method to redraw is
vtkRenderWindow::render();
but it redraw all renderers at once.
I want to redraw only one renderer or only one actor.
Is it possible?
I divide viewport in the render window for each renderer.
One for volume rendering, and the other is something working space.
I want to redraw only working space, because volume rendering is heavy.

I looking forward your helps.

Best regards,
Jinhyeok Choi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141020/22d41ef9/attachment-0002.html>

From david.gobbi at gmail.com  Mon Oct 20 22:50:44 2014
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 20 Oct 2014 20:50:44 -0600
Subject: [vtk-developers] Update only one renderer,
 (multiple renderers in a render window)
In-Reply-To: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>
References: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>
Message-ID: <CANwS1=GMrL0cdkVmm8mQfvJ6eh88jFMYMw0sP04fyPXHoJpuaQ@mail.gmail.com>

Hi Jinhyeok,

It should be possible to do this by calling the methods EraseOff()
and DrawOff() on all the renders that you don't want to re-render.

 - David

On Mon, Oct 20, 2014 at 6:54 AM, Jinhyeok Choi <andreas.choi at gmail.com> wrote:
> Hi,
>
> I have a question for redrawing a render window.
> I only know the method to redraw is
> vtkRenderWindow::render();
> but it redraw all renderers at once.
> I want to redraw only one renderer or only one actor.
> Is it possible?
> I divide viewport in the render window for each renderer.
> One for volume rendering, and the other is something working space.
> I want to redraw only working space, because volume rendering is heavy.
>
> I looking forward your helps.
>
> Best regards,
> Jinhyeok Choi


From andreas.choi at gmail.com  Mon Oct 20 23:56:21 2014
From: andreas.choi at gmail.com (Jinhyeok Choi)
Date: Tue, 21 Oct 2014 12:56:21 +0900
Subject: [vtk-developers] Update only one renderer,
 (multiple renderers in a render window)
In-Reply-To: <CANwS1=GMrL0cdkVmm8mQfvJ6eh88jFMYMw0sP04fyPXHoJpuaQ@mail.gmail.com>
References: <CAAq-dRDEVUKzbuJV2m-H+EmgOchk7kaX6CNXG1u2xAGEJzZqBg@mail.gmail.com>
 <CANwS1=GMrL0cdkVmm8mQfvJ6eh88jFMYMw0sP04fyPXHoJpuaQ@mail.gmail.com>
Message-ID: <CAAq-dRAydWM+iLAnOmObuxE9PXX4xgE9OkKtVTWdQpzRp+VBUg@mail.gmail.com>

Great! David.

Thank you

It works good

m_pvtkRenderWindow->EraseOff();
m_pvtkRenderer1->DrawOff();
m_pvtkRenderWindow->Render();
m_pvtkRenderer1->DrawOn();
m_pvtkRenderWindow->EraseOn();



2014-10-21 11:50 GMT+09:00 David Gobbi <david.gobbi at gmail.com>:

> Hi Jinhyeok,
>
> It should be possible to do this by calling the methods EraseOff()
> and DrawOff() on all the renders that you don't want to re-render.
>
>  - David
>
> On Mon, Oct 20, 2014 at 6:54 AM, Jinhyeok Choi <andreas.choi at gmail.com>
> wrote:
> > Hi,
> >
> > I have a question for redrawing a render window.
> > I only know the method to redraw is
> > vtkRenderWindow::render();
> > but it redraw all renderers at once.
> > I want to redraw only one renderer or only one actor.
> > Is it possible?
> > I divide viewport in the render window for each renderer.
> > One for volume rendering, and the other is something working space.
> > I want to redraw only working space, because volume rendering is heavy.
> >
> > I looking forward your helps.
> >
> > Best regards,
> > Jinhyeok Choi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141021/159f9a38/attachment-0002.html>

From qinshuo at hust.edu.cn  Tue Oct 21 00:41:18 2014
From: qinshuo at hust.edu.cn (=?GBK?B?x9jLtg==?=)
Date: Tue, 21 Oct 2014 12:41:18 +0800 (GMT+08:00)
Subject: [vtk-developers] Multi input image-to-image filter
Message-ID: <13ef232.469d.14931025a90.Coremail.qinshuo@hust.edu.cn>



I have a question on constructing a multiply input image-to-image filter based on class: vtkSimpleImagetoImgeFilter. In the previous release of vtk, the function AddInput(), GetInput() work well, while in the vtk5.10 there are a lot of problems. One of errors in GetInput() shows that:


"ERROR: In D:\VTK5.10\VTK5.10.1\Filtering\vtkDemandDrivenPipeline.cxx, line 737

vtkStreamingDemandDrivenPipeline (019A3AB0): Input port 0 of algorithm vtkpxAverageImages(019A2AE0) has 4 connections but is not repeatable.

"
The source I refered to is from " http://www.vtk.org/Wiki/VTK/Examples/Developers/MultipleInputConnections " 


There are examples for Multiple Input Connections or ports in "http://www.vtk.org/Wiki/VTK/Examples/Developers". And I get some solutions using function: RequestData().


 But they never use a vtkSimpleImagetoImageFilter. Does this class abandoned?











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

From tom.valleau at gmail.com  Wed Oct 22 12:53:23 2014
From: tom.valleau at gmail.com (filez41)
Date: Wed, 22 Oct 2014 09:53:23 -0700 (PDT)
Subject: [vtk-developers] Deprecated GetProducerPort
Message-ID: <1413996803157-5729205.post@n5.nabble.com>

Hey all, I posted this a week ago but in the email blast the code was left
out.  I'm hoping including the code and rephrasing the question will help. 

I'm upgrading some code from 5.6 to 6.1, and the GetProducerPort has been
deprecated.  We were using it in a few places, and I've been trying to
repeat the results we were getting with 5.6 following this deprecated code
guide:
http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_GetProducerPort
It hasn't been helpful because that's not how it was being used. 

Old Code: 
        vtkImageData * pImageData = aTexture->GetImageDataInput(0);
        vtkAlgorithmOutput * pAlgorithmOutput =
pImageData->GetProducerPort();
        vtkAlgorithm * pAlgorithm = pAlgorithmOutput->GetProducer()

New Code (*not working*): 
        vtkImageData * pImageData = aTexture->GetImageDataInput(0);
        vtkAlgorithm * pAlgorithm = vtkAlgorithm::New();
        pAlgorithm->SetInputDataObject(pImageData);

Reading the code more closely I can understand why the attempted code is not
working, but I can't figure out how to replicate the old results without
that function. 

The goal is to get a vtkAlgorithm out of a vtkDataObject (in this case a
vtkImageData).  Before we were getting the producer port (a
vtkAlgorithmOutput) and passing it's producer off to a vtkAlgorithm.  





--
View this message in context: http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205.html
Sent from the VTK - Dev mailing list archive at Nabble.com.


From berk.geveci at kitware.com  Wed Oct 22 13:32:31 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 22 Oct 2014 13:32:31 -0400
Subject: [vtk-developers] Deprecated GetProducerPort
In-Reply-To: <1413996803157-5729205.post@n5.nabble.com>
References: <1413996803157-5729205.post@n5.nabble.com>
Message-ID: <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>

vtkAlgorithm* pAlgorithm = aTexture->GetInputAlgorithm();

-berk


On Wed, Oct 22, 2014 at 12:53 PM, filez41 <tom.valleau at gmail.com> wrote:

> Hey all, I posted this a week ago but in the email blast the code was left
> out.  I'm hoping including the code and rephrasing the question will help.
>
> I'm upgrading some code from 5.6 to 6.1, and the GetProducerPort has been
> deprecated.  We were using it in a few places, and I've been trying to
> repeat the results we were getting with 5.6 following this deprecated code
> guide:
> http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Removal_of_GetProducerPort
> It hasn't been helpful because that's not how it was being used.
>
> Old Code:
>         vtkImageData * pImageData = aTexture->GetImageDataInput(0);
>         vtkAlgorithmOutput * pAlgorithmOutput =
> pImageData->GetProducerPort();
>         vtkAlgorithm * pAlgorithm = pAlgorithmOutput->GetProducer()
>
> New Code (*not working*):
>         vtkImageData * pImageData = aTexture->GetImageDataInput(0);
>         vtkAlgorithm * pAlgorithm = vtkAlgorithm::New();
>         pAlgorithm->SetInputDataObject(pImageData);
>
> Reading the code more closely I can understand why the attempted code is
> not
> working, but I can't figure out how to replicate the old results without
> that function.
>
> The goal is to get a vtkAlgorithm out of a vtkDataObject (in this case a
> vtkImageData).  Before we were getting the producer port (a
> vtkAlgorithmOutput) and passing it's producer off to a vtkAlgorithm.
>
>
>
>
>
> --
> View this message in context:
> http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141022/26135174/attachment-0002.html>

From sean at rogue-research.com  Wed Oct 22 13:40:21 2014
From: sean at rogue-research.com (Sean McBride)
Date: Wed, 22 Oct 2014 13:40:21 -0400
Subject: [vtk-developers] New OS X 10.10 dashboards
Message-ID: <20141022174021.1657343733@mail.rogue-research.com>

Hi all,

I've had VTK dashboards running on OS X 10.10 for months now, but now that 10.10 is out and the NDA is over I've directed them to the public dashboard.

Can someone please mark these as expected:

 Mac10.10-clang-dbg-x86_64
	Mac10.10-clang-rel-x86_64

The only test failure is vtkChartsCoreCxx-TestChartXYZ:
<http://open.cdash.org/testDetails.php?test=289089209&build=3539483>

This hardware never ran an older OS so I don't know if it's a change between 10.9 or 10.10 or what...

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 dave.demarle at kitware.com  Wed Oct 22 13:46:44 2014
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 22 Oct 2014 13:46:44 -0400
Subject: [vtk-developers] New OS X 10.10 dashboards
In-Reply-To: <20141022174021.1657343733@mail.rogue-research.com>
References: <20141022174021.1657343733@mail.rogue-research.com>
Message-ID: <CANjZAi8ydqETjvk3YJgAnzZcdc_7k_sfVWu7riuCR6CLM_vhNQ@mail.gmail.com>

done, thanks.

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

On Wed, Oct 22, 2014 at 1:40 PM, Sean McBride <sean at rogue-research.com>
wrote:

> Hi all,
>
> I've had VTK dashboards running on OS X 10.10 for months now, but now that
> 10.10 is out and the NDA is over I've directed them to the public dashboard.
>
> Can someone please mark these as expected:
>
>  Mac10.10-clang-dbg-x86_64
>         Mac10.10-clang-rel-x86_64
>
> The only test failure is vtkChartsCoreCxx-TestChartXYZ:
> <http://open.cdash.org/testDetails.php?test=289089209&build=3539483>
>
> This hardware never ran an older OS so I don't know if it's a change
> between 10.9 or 10.10 or what...
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141022/4837ac1c/attachment-0002.html>

From tom.valleau at gmail.com  Wed Oct 22 14:27:18 2014
From: tom.valleau at gmail.com (filez41)
Date: Wed, 22 Oct 2014 11:27:18 -0700 (PDT)
Subject: [vtk-developers] Deprecated GetProducerPort
In-Reply-To: <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>
References: <1413996803157-5729205.post@n5.nabble.com>
 <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>
Message-ID: <1414002438370-5729209.post@n5.nabble.com>

Oh my goodness, how did I not go back that far.  

It works, thank you!



--
View this message in context: http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205p5729209.html
Sent from the VTK - Dev mailing list archive at Nabble.com.


From aashish.chaudhary at kitware.com  Wed Oct 22 14:27:24 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Wed, 22 Oct 2014 14:27:24 -0400
Subject: [vtk-developers] Overhaul of the rendering subsystem in VTK:
	Volume Rendering update
In-Reply-To: <CAEw35Z_tVedsuN_TMVyH8bnB-TdXvmX9k2Ua1FWHy0tZ2XJDwg@mail.gmail.com>
References: <CAEw35Z_0PxqjioJ4gD7vQtgP5sf5bUmoj-ppnmUTAwCbnMAshw@mail.gmail.com>
 <CAEw35Z_tVedsuN_TMVyH8bnB-TdXvmX9k2Ua1FWHy0tZ2XJDwg@mail.gmail.com>
Message-ID: <CAEw35Z_a5J-v7pdvcm8ShiTY=vRXg6fASimTKNNgARmkZxW5GA@mail.gmail.com>

Friends,

Some more good news on the rendering side of things. In the last few days,
we have worked on porting two more volume mappers to OpenGL2 (FixedPoint
and Bunyk) and this noon we merged that code into VTK master. This change
should not affect the code that is using the OpenGL (and not OpenGL2)
backend. We will keep an eye on the dashboards and fix any issue that we
may find. Also, we have updated the vtkSmartVolumeMapper to deal with the
OpenGL and OpenGL2 backend.

Please let us know if you have any questions or if you encounter any issues
in the current master related to this change.

Thanks,

On Thu, Oct 16, 2014 at 12:31 PM, Aashish Chaudhary <
aashish.chaudhary at kitware.com> wrote:

> Friends,
>
> As referred earlier, we are continuously working on improving the volume
> rendering. As part of next set of delivery,  we are going to bring our
> first OpenGL2 volume mapper to the OpenGL2 backend.
> We have a branch that will get merged today and* it should only affect
> the dashboards and code base switched to OpenGL2 backend*. We will
> continue to improve the integration and will use and improve the
> existing OpenGL2 backend code as necessary.
>
> If you have any questions of concerns or if you find in any ways its
> affecting your regular builds that uses OpenGL(default, and not OpenGL2)
>  backend then let us know as soon as possible.
>
> Thanks,
>
>
> On Fri, Oct 10, 2014 at 9:53 AM, Aashish Chaudhary <
> aashish.chaudhary at kitware.com> wrote:
>
>> Friends,
>>
>>
>> As reported back in July, we are in the process of a major overhaul of
>> the rendering subsystem in VTK. The July article (
>> http://www.kitware.com/source/home/post/144) focused primarily on our
>> efforts to move to OpenGL 2.1+ to support faster polygonal rendering.  The
>> October Source will contain an article focused on our rewrite of the
>> vtkGPURayCastMapper class to provide a faster, more portable and more
>> easily extensible volume mapper for regular rectilinear grids.
>>
>>
>>
>> VTK has a long history of volume rendering, and unfortunately that
>> history is evident in the large selection of classes available to render
>> volumes. Each of these methods was state-of-the-art at the time, but given
>> VTK?s 20+ year history many of these methods are now quite obsolete. One
>> goal of this effort is to reduce the number of volume mappers to ideally
>> just two - one that supports accelerated rendering on graphics hardware and
>> another that works in parallel on the CPU. In addition, the
>> vtkSmartVolumeMapper would help application developers by automatically
>> choosing between these techniques based on system performance.
>>
>>
>>
>> In this first phase, we have created a replacement for
>> vtkGPURayCastMapper. Currently, this is available for testing from the VTK
>> git repository (in master branch, disabled by default). General
>> instructions on how to build VTK from the source is available at this URL:
>> http://www.vtk.org/Wiki/VTK/Git*. *In order to build the new mapper,
>> enable the Module_vtkRenderingVolumeOpenGLNew module in cmake (via -D
>> *Module_vtkRenderingVolumeOpenGL=ON*), in ccmake or cmake-gui. Once
>> built, it can be used via vtkSmartVolumeMapper or used directly. Once
>> sufficient testing by the community has been performed, this class will
>> replace the old vtkGPURayCastMapper.  In addition, we are adding this new
>> mapper to the OpenGL2 module.  Availability of the new mapper with OpenGL2
>> module will improve the management of textures in the mapper and eventually
>> benefitting both forms of rendering (geometry and volume) by sharing common
>> code between them.
>>
>>
>> Please contact us if you have any questions or encounter any issues.
>>
>>
>> Thanks,
>>
>> --
>>
>>
>>
>> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.
>> *
>> *| http://www.kitware.com/company/team/chaudhary.html
>> <http://www.kitware.com/company/team/chaudhary.html>*
>>
>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>



-- 



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

From DLRdave at aol.com  Wed Oct 22 14:47:20 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 22 Oct 2014 14:47:20 -0400
Subject: [vtk-developers] New OS X 10.10 dashboards
In-Reply-To: <20141022174021.1657343733@mail.rogue-research.com>
References: <20141022174021.1657343733@mail.rogue-research.com>
Message-ID: <CAKME8fGEK9_XNdVPU1XuiNYbEa53zrv64mZ8X+Vi7Z35G-it1A@mail.gmail.com>

I suspect a real VTK bug behind this test failure. I get *exactly* the
same test image on my Windows / Visual Studio 2012 dashboards:

http://open.cdash.org/testDetails.php?test=266709768&build=3539864

I suspect there is a rounding error or something like that, which is
causing two of the symbols to end up exactly on top of two of the
other symbols.


On Wed, Oct 22, 2014 at 1:40 PM, Sean McBride <sean at rogue-research.com> wrote:
> Hi all,
>
> I've had VTK dashboards running on OS X 10.10 for months now, but now that 10.10 is out and the NDA is over I've directed them to the public dashboard.
>
> Can someone please mark these as expected:
>
>  Mac10.10-clang-dbg-x86_64
>         Mac10.10-clang-rel-x86_64
>
> The only test failure is vtkChartsCoreCxx-TestChartXYZ:
> <http://open.cdash.org/testDetails.php?test=289089209&build=3539483>
>
> This hardware never ran an older OS so I don't know if it's a change between 10.9 or 10.10 or what...
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>


From berk.geveci at kitware.com  Wed Oct 22 15:44:41 2014
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 22 Oct 2014 15:44:41 -0400
Subject: [vtk-developers] Deprecated GetProducerPort
In-Reply-To: <1414002438370-5729209.post@n5.nabble.com>
References: <1413996803157-5729205.post@n5.nabble.com>
 <CAE32kpWsCA4r7=-yO18to21QkyNGod9_3w-_tcrBef0g7wq=Lg@mail.gmail.com>
 <1414002438370-5729209.post@n5.nabble.com>
Message-ID: <CAE32kpXuFOBbCsx6gsy7bm8nWi3LWYg1uDRH=+fAAS86kjHr4Q@mail.gmail.com>

:-)

On Wed, Oct 22, 2014 at 2:27 PM, filez41 <tom.valleau at gmail.com> wrote:

> Oh my goodness, how did I not go back that far.
>
> It works, thank you!
>
>
>
> --
> View this message in context:
> http://vtk.1045678.n5.nabble.com/Deprecated-GetProducerPort-tp5729205p5729209.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> 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/20141022/e3d2eb44/attachment-0002.html>

From cameron.palmer at ntnu.no  Thu Oct 23 16:02:27 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Thu, 23 Oct 2014 20:02:27 +0000
Subject: [vtk-developers] VES-Kiwi
Message-ID: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>

Hi, I?m interested in building VTK-VES-Kiwi stack on just about any platform although I prefer Mac, or Windows. It seems that the instructions provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the state of development on the project?

From aashish.chaudhary at kitware.com  Thu Oct 23 16:19:00 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Thu, 23 Oct 2014 16:19:00 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
Message-ID: <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>

Hi Cameron,

The reason we didn't update those documentation because we are working
towards getting VES and some Kiwi functionality in proper VTK in one way or
another. Probably others will provide more information on this matter, but
here is a to follow up on the recent development in that direction:

http://www.kitware.com/source/home/post/144

We will also have an upcoming article on Volume Rendering that should  work
on mobile devices as well (not tested).

*As far as the build goes, there are newer ways to build an Android project
but I personally have not tested that with CMake. There is a project inside
VTK master with OpenGL2 backend that you can try now.*

*Please don't consider this as an official reply on this matter* but I hope
that this provides some useful information.

- Aashish



On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

> Hi, I?m interested in building VTK-VES-Kiwi stack on just about any
> platform although I prefer Mac, or Windows. It seems that the instructions
> provided absolutely don?t work or are not consistently documented.
>
> So is Linux-Eclipse-Android really the only viable option? What is the
> state of development on the project?
> _______________________________________________
> 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
>
>


-- 



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

From cameron.palmer at ntnu.no  Fri Oct 24 02:35:12 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Fri, 24 Oct 2014 06:35:12 +0000
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
Message-ID: <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>

I understand the pain that is documentation, but even the links to the mailing list are broken. For example http://www.vtk.org/Wiki/VES the link at the bottom doesn?t take you where it says it will.

Impressive improvements in the article you shared. Those speed-ups are truly awesome.

Now let?s talk about me. Our university has built up a non-trivial amount of code around VES-Kiwi. What I?m trying to do is get to a place where I can debug and ultimately extend the codebase. Basically the work is increasingly Android-only, but I would prefer a first-class C++ debugging environment something the current Android tools don?t really have yet. That was why I was trying to get plain ol? VES to compile in iOS. Should I take this to mean that the VES codebase has been deprecated in favor of future development within VTK?

Thanks,

Cameron.



On 23. okt. 2014, at 22.19, Aashish Chaudhary <aashish.chaudhary at kitware.com<mailto:aashish.chaudhary at kitware.com>> wrote:

Hi Cameron,

The reason we didn't update those documentation because we are working towards getting VES and some Kiwi functionality in proper VTK in one way or another. Probably others will provide more information on this matter, but here is a to follow up on the recent development in that direction:

http://www.kitware.com/source/home/post/144

We will also have an upcoming article on Volume Rendering that should  work on mobile devices as well (not tested).

As far as the build goes, there are newer ways to build an Android project but I personally have not tested that with CMake. There is a project inside VTK master with OpenGL2 backend that you can try now.

Please don't consider this as an official reply on this matter but I hope that this provides some useful information.

- Aashish



On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <cameron.palmer at ntnu.no<mailto:cameron.palmer at ntnu.no>> wrote:
Hi, I?m interested in building VTK-VES-Kiwi stack on just about any platform although I prefer Mac, or Windows. It seems that the instructions provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the state of development on the project?
_______________________________________________
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




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

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

From aashish.chaudhary at kitware.com  Fri Oct 24 08:43:56 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Fri, 24 Oct 2014 08:43:56 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
Message-ID: <CAEw35Z8O0OjX7GcQ_3Eix7R-65uh3vzVCgsQo9ZDZF6t4QAJww@mail.gmail.com>

On Fri, Oct 24, 2014 at 2:35 AM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

>  I understand the pain that is documentation, but even the links to the
> mailing list are broken. For example http://www.vtk.org/Wiki/VES the link
> at the bottom doesn?t take you where it says it will.
>

I am sorry. Sure, we will fix that.

>
>  Impressive improvements in the article you shared. Those speed-ups are
> truly awesome.
>

Awesome.

>
>  Now let?s talk about me. Our university has built up a non-trivial
> amount of code around VES-Kiwi.
>

Nice. Any chance you can share a link on it?


> What I?m trying to do is get to a place where I can debug and ultimately
> extend the codebase. Basically the work is increasingly Android-only, but I
> would prefer a first-class C++ debugging environment something the current
> Android tools don?t really have yet. That was why I was trying to get plain
> ol? VES to compile in iOS. Should I take this to mean that the VES codebase
> has been deprecated in favor of future development within VTK?
>

Yes, however the application code; not so much. I will see if I can talk to
some of leading developers here and bring it up in our next meeting. It
would be great to catch up with you on a hangout sometime. Let me know and
I can probably give you more information then.

Thanks,
>
>  Cameron.
>
>
>
>  On 23. okt. 2014, at 22.19, Aashish Chaudhary <
> aashish.chaudhary at kitware.com> wrote:
>
>  Hi Cameron,
>
>  The reason we didn't update those documentation because we are working
> towards getting VES and some Kiwi functionality in proper VTK in one way or
> another. Probably others will provide more information on this matter, but
> here is a to follow up on the recent development in that direction:
>
>  http://www.kitware.com/source/home/post/144
>
>  We will also have an upcoming article on Volume Rendering that should
>  work on mobile devices as well (not tested).
>
>  *As far as the build goes, there are newer ways to build an Android
> project but I personally have not tested that with CMake. There is a
> project inside VTK master with OpenGL2 backend that you can try now.*
>
>  *Please don't consider this as an official reply on this matter* but I
> hope that this provides some useful information.
>
>  - Aashish
>
>
>
> On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <
> cameron.palmer at ntnu.no> wrote:
>
>> Hi, I?m interested in building VTK-VES-Kiwi stack on just about any
>> platform although I prefer Mac, or Windows. It seems that the instructions
>> provided absolutely don?t work or are not consistently documented.
>>
>> So is Linux-Eclipse-Android really the only viable option? What is the
>> state of development on the project?
>> _______________________________________________
>> 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
>>
>>
>
>
> --
>
>
>
> *| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
> *| http://www.kitware.com/company/team/chaudhary.html
> <http://www.kitware.com/company/team/chaudhary.html>*
>
>
>


-- 



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

From ken.martin at kitware.com  Fri Oct 24 11:14:18 2014
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 24 Oct 2014 11:14:18 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
Message-ID: <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>

Some history is useful here. Back when VES started VTK rendering was based
on the old fixed pipeline which does not work with OpenGL ES. To render on
Android/iOS they needed to implement a rendering engine built on OpenGL ES.
Due to cost and time constraints they felt they did not have time to put
that codebase into VTK proper. Now we have the time and funding to work on
that. It is a work in progress and still at an early stage but VTK master
includes alpha support for compiling and rendering on Android and iOS. More
specifically:



-          VTK now includes toolchain files and a number of fixes so that
it can build on android and iOS

-          There are now Android and iOS example programs in the Examples
Directory in VTK, for the brave that is the place to start and there are
readme files

-          Very basic multitouch support has been added for android, iOS,
and Windows systems (OpenGL2 backend)

-          A rework of the rendering system to fit with OpenGl 2.1 which
gets us close to OpenGL ES 2.0 along with some nice performance
improvements.

-          An implementation of a shader based volume renderer we think
could work with OpenGL ES 3.0

-          More fixes needed to deal with OpenGL ES 2.0.

-          A testing dashboard to make sure it builds on iOS



There is a ***lot*** still to be done including



-          migrating some of the useful bits of code from VES to somewhere
in VTK

-          setting up android dashboards

-          setting up dashboard tests to verify the built code runs and
renders

-          converting some additional old OpenGL code to 2.1/ES standards

-          Creating more examples for both platforms

-          lots more testing

-          better build support for iOS, it is a bit clunky/limited

-          bunch of stuff I?m forgetting



So right now we are in the awkward time where we are moving to having most
the VES functionality in VTK, but it is not really ready for prime time
yet.  I believe maintenance of VES/Kiwi is limited but happening.



Hope that helps some!



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 *Cameron Lowell Palmer
*Sent:* Friday, October 24, 2014 2:35 AM
*To:* Aashish Chaudhary
*Cc:* vtk-developers at vtk.org
*Subject:* Re: [vtk-developers] VES-Kiwi



I understand the pain that is documentation, but even the links to the
mailing list are broken. For example http://www.vtk.org/Wiki/VES the link
at the bottom doesn?t take you where it says it will.



Impressive improvements in the article you shared. Those speed-ups are
truly awesome.



Now let?s talk about me. Our university has built up a non-trivial amount
of code around VES-Kiwi. What I?m trying to do is get to a place where I
can debug and ultimately extend the codebase. Basically the work is
increasingly Android-only, but I would prefer a first-class C++ debugging
environment something the current Android tools don?t really have yet. That
was why I was trying to get plain ol? VES to compile in iOS. Should I take
this to mean that the VES codebase has been deprecated in favor of future
development within VTK?



Thanks,



Cameron.







On 23. okt. 2014, at 22.19, Aashish Chaudhary <aashish.chaudhary at kitware.com>
wrote:



Hi Cameron,



The reason we didn't update those documentation because we are working
towards getting VES and some Kiwi functionality in proper VTK in one way or
another. Probably others will provide more information on this matter, but
here is a to follow up on the recent development in that direction:



http://www.kitware.com/source/home/post/144



We will also have an upcoming article on Volume Rendering that should  work
on mobile devices as well (not tested).



*As far as the build goes, there are newer ways to build an Android project
but I personally have not tested that with CMake. There is a project inside
VTK master with OpenGL2 backend that you can try now.*



*Please don't consider this as an official reply on this matter* but I hope
that this provides some useful information.



- Aashish







On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

Hi, I?m interested in building VTK-VES-Kiwi stack on just about any
platform although I prefer Mac, or Windows. It seems that the instructions
provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the
state of development on the project?
_______________________________________________
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





-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *

*| **http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20141024/1f1e9eab/attachment-0001.html>

From DLRdave at aol.com  Fri Oct 24 15:53:05 2014
From: DLRdave at aol.com (David Cole)
Date: Fri, 24 Oct 2014 15:53:05 -0400
Subject: [vtk-developers] Never "nothing to do" with a python-wrapped VTK
	build using ninja
Message-ID: <CAKME8fGog_1FBZ_1bFQ4WDx_ccgmDKLw56j02bSuwh19BeF9MQ@mail.gmail.com>

Has anybody else noticed that this rule always runs, even on a
presumably up to date build tree?

    C:\dev\repos\My Tests\VTK Win64-ninja-cl11x64-Debug> ninja
    [1/1] cmd.exe /C "cd /D "C:\dev\repos\My Tests\VTK
Win64-ninja-cl11x64-Debug\Wrapping\Python" && echo ..."
    ...

I expect to see "nothing to do", but it always runs a seemingly silly
little no-op custom command to echo "..."

Does anybody see this with other build systems, or is it just me with
my ninja build?

(Using cmake 3.0.2, by the way)


Thx,
David C.

From ben.boeckel at kitware.com  Fri Oct 24 19:33:10 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 24 Oct 2014 19:33:10 -0400
Subject: [vtk-developers] Never "nothing to do" with a python-wrapped
 VTK build using ninja
In-Reply-To: <CAKME8fGog_1FBZ_1bFQ4WDx_ccgmDKLw56j02bSuwh19BeF9MQ@mail.gmail.com>
References: <CAKME8fGog_1FBZ_1bFQ4WDx_ccgmDKLw56j02bSuwh19BeF9MQ@mail.gmail.com>
Message-ID: <20141024233310.GC999@bronto-burt.dev.benboeckel.net>

On Fri, Oct 24, 2014 at 15:53:05 -0400, David Cole via vtk-developers wrote:
> Has anybody else noticed that this rule always runs, even on a
> presumably up to date build tree?
> 
>     C:\dev\repos\My Tests\VTK Win64-ninja-cl11x64-Debug> ninja
>     [1/1] cmd.exe /C "cd /D "C:\dev\repos\My Tests\VTK
> Win64-ninja-cl11x64-Debug\Wrapping\Python" && echo ..."
>     ...
> 
> I expect to see "nothing to do", but it always runs a seemingly silly
> little no-op custom command to echo "..."
> 
> Does anybody see this with other build systems, or is it just me with
> my ninja build?
> 
> (Using cmake 3.0.2, by the way)

This is fine, but could probably (but I haven't investigated too much)
be modified such that it doesn't need to be always run. Basically the
target is there to trigger that .pyc files are always up-to-date in the
build tree. Since proper dependencies cannot be computed for it (there's
no concept of "depends on all *.py files under inputdir/"), this is
currently used as a hack to chain *that* command into the main build.

When proper git hash detection lands in VTK (doing so during the build
rather than configure time), that will be another target that will
always be out of date preventing a "no work to do" state from ninja.
However, if things need to rebuild or relink every time, *that* would be
a bug.

--Ben

From weifeng0715 at gmail.com  Sat Oct 25 04:14:02 2014
From: weifeng0715 at gmail.com (weifeng0715)
Date: Sat, 25 Oct 2014 01:14:02 -0700 (PDT)
Subject: [vtk-developers] Why does vtkLookupTable not have the following
 functions? How should realize these functions?
Message-ID: <1414224842038-5729223.post@n5.nabble.com>

virtual void 	SetBelowRangeColor (double, double, double, double)
 
virtual void 	SetBelowRangeColor (double[4])
 
virtual double * 	GetBelowRangeColor ()
 
virtual void 	GetBelowRangeColor (double &, double &, double &, double &)
 
virtual void 	GetBelowRangeColor (double[4])
 
virtual void 	SetUseBelowRangeColor (int)
 
virtual int 	GetUseBelowRangeColor ()
 
virtual void 	UseBelowRangeColorOn ()
 
virtual void 	UseBelowRangeColorOff ()
 
virtual void 	SetAboveRangeColor (double, double, double, double)
 
virtual void 	SetAboveRangeColor (double[4])
 
virtual double * 	GetAboveRangeColor ()
 
virtual void 	GetAboveRangeColor (double &, double &, double &, double &)
 
virtual void 	GetAboveRangeColor (double[4])
 
virtual void 	SetUseAboveRangeColor (int)
 
virtual int 	GetUseAboveRangeColor ()
 
virtual void 	UseAboveRangeColorOn ()
 
virtual void 	UseAboveRangeColorOff ()



--
View this message in context: http://vtk.1045678.n5.nabble.com/Why-does-vtkLookupTable-not-have-the-following-functions-How-should-realize-these-functions-tp5729223.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From cameron.palmer at ntnu.no  Sat Oct 25 05:26:21 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Sat, 25 Oct 2014 09:26:21 +0000
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
 <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>
Message-ID: <D07134FC.4842%cameron.palmer@ntnu.no>

I really appreciate the history and roadmap. Sheds some light on the direction of the project.

Thoughts on the roadmap?

As has been brought up before, debugging is the central issue with today's VES codebase. Since getting the code to compile for iOS seems to be broken and in my case not our target platform, I?m left trying to get to a usable development environment for Android. Does the roadmap for the future VTK integration address not just compilation, but the creation of a usable environment for debugging. Cmake seems to create a non-native project for both Android and iOS that while capable of compiling, loses a lot of the power of each environment.

Let me illustrate. https://www.youtube.com/watch?v=kjsC-lKUgM8 is a video from Intel demonstrating debugging the NDK with Eclipse. This is a great resource for getting started with this problem, but it is unworkable because cmake creates a build directory with a project that is effectively just a binary with no source. I think it is important to address in the roadmap leveraging the Best Practices for the supported targets.

At least that is my current thinking.

From: Ken Martin <ken.martin at kitware.com<mailto:ken.martin at kitware.com>>
Date: fredag 24. oktober 2014 17.14
To: Cameron Lowell Palmer <cameron.palmer at ntnu.no<mailto:cameron.palmer at ntnu.no>>, Aashish Chaudhary <aashish.chaudhary at kitware.com<mailto:aashish.chaudhary at kitware.com>>
Cc: "vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>" <vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>>
Subject: RE: [vtk-developers] VES-Kiwi

Some history is useful here. Back when VES started VTK rendering was based on the old fixed pipeline which does not work with OpenGL ES. To render on Android/iOS they needed to implement a rendering engine built on OpenGL ES. Due to cost and time constraints they felt they did not have time to put that codebase into VTK proper. Now we have the time and funding to work on that. It is a work in progress and still at an early stage but VTK master includes alpha support for compiling and rendering on Android and iOS. More specifically:


-          VTK now includes toolchain files and a number of fixes so that it can build on android and iOS

-          There are now Android and iOS example programs in the Examples Directory in VTK, for the brave that is the place to start and there are readme files

-          Very basic multitouch support has been added for android, iOS, and Windows systems (OpenGL2 backend)

-          A rework of the rendering system to fit with OpenGl 2.1 which gets us close to OpenGL ES 2.0 along with some nice performance improvements.

-          An implementation of a shader based volume renderer we think could work with OpenGL ES 3.0

-          More fixes needed to deal with OpenGL ES 2.0.

-          A testing dashboard to make sure it builds on iOS

There is a ***lot*** still to be done including


-          migrating some of the useful bits of code from VES to somewhere in VTK

-          setting up android dashboards

-          setting up dashboard tests to verify the built code runs and renders

-          converting some additional old OpenGL code to 2.1/ES standards

-          Creating more examples for both platforms

-          lots more testing

-          better build support for iOS, it is a bit clunky/limited

-          bunch of stuff I?m forgetting

So right now we are in the awkward time where we are moving to having most the VES functionality in VTK, but it is not really ready for prime time yet.  I believe maintenance of VES/Kiwi is limited but happening.

Hope that helps some!

Thanks
Ken

Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
ken.martin at kitware.com<mailto: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<mailto:vtk-developers-bounces at vtk.org>] On Behalf Of Cameron Lowell Palmer
Sent: Friday, October 24, 2014 2:35 AM
To: Aashish Chaudhary
Cc: vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>
Subject: Re: [vtk-developers] VES-Kiwi

I understand the pain that is documentation, but even the links to the mailing list are broken. For example http://www.vtk.org/Wiki/VES the link at the bottom doesn?t take you where it says it will.

Impressive improvements in the article you shared. Those speed-ups are truly awesome.

Now let?s talk about me. Our university has built up a non-trivial amount of code around VES-Kiwi. What I?m trying to do is get to a place where I can debug and ultimately extend the codebase. Basically the work is increasingly Android-only, but I would prefer a first-class C++ debugging environment something the current Android tools don?t really have yet. That was why I was trying to get plain ol? VES to compile in iOS. Should I take this to mean that the VES codebase has been deprecated in favor of future development within VTK?

Thanks,

Cameron.



On 23. okt. 2014, at 22.19, Aashish Chaudhary <aashish.chaudhary at kitware.com<mailto:aashish.chaudhary at kitware.com>> wrote:

Hi Cameron,

The reason we didn't update those documentation because we are working towards getting VES and some Kiwi functionality in proper VTK in one way or another. Probably others will provide more information on this matter, but here is a to follow up on the recent development in that direction:

http://www.kitware.com/source/home/post/144

We will also have an upcoming article on Volume Rendering that should  work on mobile devices as well (not tested).

As far as the build goes, there are newer ways to build an Android project but I personally have not tested that with CMake. There is a project inside VTK master with OpenGL2 backend that you can try now.

Please don't consider this as an official reply on this matter but I hope that this provides some useful information.

- Aashish



On Thu, Oct 23, 2014 at 4:02 PM, Cameron Lowell Palmer <cameron.palmer at ntnu.no<mailto:cameron.palmer at ntnu.no>> wrote:
Hi, I?m interested in building VTK-VES-Kiwi stack on just about any platform although I prefer Mac, or Windows. It seems that the instructions provided absolutely don?t work or are not consistently documented.

So is Linux-Eclipse-Android really the only viable option? What is the state of development on the project?
_______________________________________________
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



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

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

From DLRdave at aol.com  Sat Oct 25 08:18:14 2014
From: DLRdave at aol.com (David Cole)
Date: Sat, 25 Oct 2014 08:18:14 -0400
Subject: [vtk-developers] Never "nothing to do" with a python-wrapped
 VTK build using ninja
In-Reply-To: <20141024233310.GC999@bronto-burt.dev.benboeckel.net>
References: <CAKME8fGog_1FBZ_1bFQ4WDx_ccgmDKLw56j02bSuwh19BeF9MQ@mail.gmail.com>
 <20141024233310.GC999@bronto-burt.dev.benboeckel.net>
Message-ID: <CAKME8fGOk6gVgRw1MotPe7cut37-2h9NW+bUk2dRX9b5Hh8+CA@mail.gmail.com>

If it's intentional, perhaps "echo Checking if pyc files are up to
date" would be more appropriate than "echo ..."

Just sayin'

:-)


On Fri, Oct 24, 2014 at 7:33 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Fri, Oct 24, 2014 at 15:53:05 -0400, David Cole via vtk-developers wrote:
>> Has anybody else noticed that this rule always runs, even on a
>> presumably up to date build tree?
>>
>>     C:\dev\repos\My Tests\VTK Win64-ninja-cl11x64-Debug> ninja
>>     [1/1] cmd.exe /C "cd /D "C:\dev\repos\My Tests\VTK
>> Win64-ninja-cl11x64-Debug\Wrapping\Python" && echo ..."
>>     ...
>>
>> I expect to see "nothing to do", but it always runs a seemingly silly
>> little no-op custom command to echo "..."
>>
>> Does anybody see this with other build systems, or is it just me with
>> my ninja build?
>>
>> (Using cmake 3.0.2, by the way)
>
> This is fine, but could probably (but I haven't investigated too much)
> be modified such that it doesn't need to be always run. Basically the
> target is there to trigger that .pyc files are always up-to-date in the
> build tree. Since proper dependencies cannot be computed for it (there's
> no concept of "depends on all *.py files under inputdir/"), this is
> currently used as a hack to chain *that* command into the main build.
>
> When proper git hash detection lands in VTK (doing so during the build
> rather than configure time), that will be another target that will
> always be out of date preventing a "no work to do" state from ninja.
> However, if things need to rebuild or relink every time, *that* would be
> a bug.
>
> --Ben

From cameron.palmer at ntnu.no  Sun Oct 26 09:15:22 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Sun, 26 Oct 2014 13:15:22 +0000
Subject: [vtk-developers] Constructing Android.mk files for ndk-build
Message-ID: <D072B27A.487E%cameron.palmer@ntnu.no>

Has anyone ever built Kiwi-VES using ndk-build and Android.mk? If so, can we share?

My current strategy is to statically compile vtk-android and roll up all the output of the vtk superbuild as a single libvtk-android.a. I?ve used GNU ar to roll up all of the .a files. Then I?ll leave our custom Kiwi and VES code as source. This will allow me to build the NDK portion in the standard Android fashion. My current obstacle is the compilation of libarchive which seems to be a requirement of our kiwi code.

If anyone is interested it would be fairly trivial to try this with unmodified VES-Kiwi and put it up on github. Just let me know.

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

From ben.boeckel at kitware.com  Sun Oct 26 22:44:03 2014
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Sun, 26 Oct 2014 22:44:03 -0400
Subject: [vtk-developers] Constructing Android.mk files for ndk-build
In-Reply-To: <D072B27A.487E%cameron.palmer@ntnu.no>
References: <D072B27A.487E%cameron.palmer@ntnu.no>
Message-ID: <20141027024403.GA12785@bronto-burt.dev.benboeckel.net>

On Sun, Oct 26, 2014 at 13:15:22 +0000, Cameron Lowell Palmer wrote:
> Has anyone ever built Kiwi-VES using ndk-build and Android.mk? If so,
> can we share?
> 
> My current strategy is to statically compile vtk-android and roll up
> all the output of the vtk superbuild as a single libvtk-android.a.
> I?ve used GNU ar to roll up all of the .a files. Then I?ll leave our
> custom Kiwi and VES code as source. This will allow me to build the
> NDK portion in the standard Android fashion. My current obstacle is
> the compilation of libarchive which seems to be a requirement of our
> kiwi code.
> 
> If anyone is interested it would be fairly trivial to try this with
> unmodified VES-Kiwi and put it up on github. Just let me know.

Here[1]'s a (non-Kitware related) project which uses ndk-build for the
Android bits, but CMake for the main build. Basically, you cross compile
using the NDK toolchain with CMake, then have the Android bits "install"
the binaries you're interested as an "external" NDK library[2]. Making a
"super" library of all the enabled modules shouldn't be too hard to do
just in the android build (so that umpteen libraries don't need
"installed"). No need to set up the entire Android.mk infrastructure for
all of VTK.

--Ben

[1]https://github.com/mathstuf/abagames-gunroar/blob/master/src/android/CMakeLists.txt
[2]https://github.com/mathstuf/abagames-gunroar/blob/master/src/android/jni/gunroar/Android.mk

From bill.hoffman at kitware.com  Mon Oct 27 09:28:30 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 27 Oct 2014 09:28:30 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <D07134FC.4842%cameron.palmer@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
 <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>
 <D07134FC.4842%cameron.palmer@ntnu.no>
Message-ID: <544E487E.3070204@kitware.com>

On 10/25/2014 5:26 AM, Cameron Lowell Palmer wrote:
>
> Let me illustrate. https://www.youtube.com/watch?v=kjsC-lKUgM8 is a
> video from Intel demonstrating debugging the NDK with Eclipse. This is a
> great resource for getting started with this problem, but it is
> unworkable because cmake creates a build directory with a project that
> is effectively just a binary with no source. I think it is important to
> address in the roadmap leveraging the Best Practices for the supported
> targets.
>
> At least that is my current thinking.
The idea would be to continue to enhance CMake to support the mobile 
IDEs better as time moves forward.  We need something that is seamless 
across windows, mac, and Linux, and works with iOS and Android.  Having 
to maintain N different IDE files in VTK will never work.   NVIDIA has 
been working on adding this type of support to CMake:

http://www.cmake.org/pipermail/cmake-developers/2014-September/011308.html

We worked some to get the build and debugging working with Eclipse here:
http://www.kitware.com/blog/home/post/642

Ditching CMake does not make sense for VTK, it is how VTK is developed. 
  CMake does need some enhancements to make it work better with mobile 
development environments.  Working on enhancing CMake would be a much 
better place to put effort than to have multiple build systems inside 
VTK-VES.

-Bill


-- 
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoffman at kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573

From cameron.palmer at ntnu.no  Mon Oct 27 09:31:00 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Mon, 27 Oct 2014 13:31:00 +0000
Subject: [vtk-developers] Constructing Android.mk files for ndk-build
In-Reply-To: <20141027024403.GA12785@bronto-burt.dev.benboeckel.net>
References: <D072B27A.487E%cameron.palmer@ntnu.no>
 <20141027024403.GA12785@bronto-burt.dev.benboeckel.net>
Message-ID: <D073C69E.4886%cameron.palmer@ntnu.no>

Bill, your email arrived as this was nearly finished.

I?m not sure if you quite understand my issue. Getting VTK setup as a
static library was trivial. You simply allow the existing VES superbuild
to run and then roll up the contents of VTK using GNU ar.

In the stock KiwiViewer app cmake hands you a 9MB libKiwiNative.so and a
small amount of Java wrapping, but mostly the entire app lives in C++
land. This is undesirable since it turns your entire application into a
black box. I have documented the process on a Mac at
https://github.com/palmerc/VES-Kiwi-Build.

In our version of KiwiViewerApp, called SCViewerApp, we don?t touch
vtk-android, but we customize ves-android which is comprised of ves/ and
kiwi/ C++ code. Cmake runs and again builds libSCNative.so. This is still
undesirable because you can?t readily debug it and we?re moving into a
more mobile specific phase of the project that will require it.

So? I?ve let the superbuild run normally and then generated a
libvtk-android.a file from the dozen or so resulting vtk .a files. Then I
copy this into the jni/ folder.

Now, the issue is getting the Android.mk file setup for VES, VTK
(PREBUILT_STATIC_LIBRARY), Kiwi, Eigen using ndk-build. That work is
located at https://github.com/palmerc/VES-Kiwi-NDK.

Now maybe I?m missing something here, but I need to be able to set
breakpoints in the VES and Kiwi C++ code. As I see it this is the only
approach that is going to get me there. However, I?m quite willing to be
wrong. :) 

Cameron.

On 27.10.14, 03.44, "Ben Boeckel" <ben.boeckel at kitware.com> wrote:

>On Sun, Oct 26, 2014 at 13:15:22 +0000, Cameron Lowell Palmer wrote:
>> Has anyone ever built Kiwi-VES using ndk-build and Android.mk? If so,
>> can we share?
>> 
>> My current strategy is to statically compile vtk-android and roll up
>> all the output of the vtk superbuild as a single libvtk-android.a.
>> I?ve used GNU ar to roll up all of the .a files. Then I?ll leave our
>> custom Kiwi and VES code as source. This will allow me to build the
>> NDK portion in the standard Android fashion. My current obstacle is
>> the compilation of libarchive which seems to be a requirement of our
>> kiwi code.
>> 
>> If anyone is interested it would be fairly trivial to try this with
>> unmodified VES-Kiwi and put it up on github. Just let me know.
>
>Here[1]'s a (non-Kitware related) project which uses ndk-build for the
>Android bits, but CMake for the main build. Basically, you cross compile
>using the NDK toolchain with CMake, then have the Android bits "install"
>the binaries you're interested as an "external" NDK library[2]. Making a
>"super" library of all the enabled modules shouldn't be too hard to do
>just in the android build (so that umpteen libraries don't need
>"installed"). No need to set up the entire Android.mk infrastructure for
>all of VTK.
>
>--Ben
>
>[1]https://github.com/mathstuf/abagames-gunroar/blob/master/src/android/CM
>akeLists.txt
>[2]https://github.com/mathstuf/abagames-gunroar/blob/master/src/android/jn
>i/gunroar/Android.mk


From cameron.palmer at ntnu.no  Mon Oct 27 09:55:50 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Mon, 27 Oct 2014 13:55:50 +0000
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <544E487E.3070204@kitware.com>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
 <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>
 <D07134FC.4842%cameron.palmer@ntnu.no> <544E487E.3070204@kitware.com>
Message-ID: <D07407AC.4AC1%cameron.palmer@ntnu.no>

That is what I don?t get, how was the original Kiwi C++ code debugged on
Android? 

I would be happy if cmake could generate a Makefile that just output a
hierarchy of source and Android.mk files.



On 27.10.14, 14.28, "Bill Hoffman" <bill.hoffman at kitware.com> wrote:

>On 10/25/2014 5:26 AM, Cameron Lowell Palmer wrote:
>>
>> Let me illustrate. https://www.youtube.com/watch?v=kjsC-lKUgM8 is a
>> video from Intel demonstrating debugging the NDK with Eclipse. This is a
>> great resource for getting started with this problem, but it is
>> unworkable because cmake creates a build directory with a project that
>> is effectively just a binary with no source. I think it is important to
>> address in the roadmap leveraging the Best Practices for the supported
>> targets.
>>
>> At least that is my current thinking.
>The idea would be to continue to enhance CMake to support the mobile
>IDEs better as time moves forward.  We need something that is seamless
>across windows, mac, and Linux, and works with iOS and Android.  Having
>to maintain N different IDE files in VTK will never work.   NVIDIA has
>been working on adding this type of support to CMake:
>
>http://www.cmake.org/pipermail/cmake-developers/2014-September/011308.html
>
>We worked some to get the build and debugging working with Eclipse here:
>http://www.kitware.com/blog/home/post/642
>
>Ditching CMake does not make sense for VTK, it is how VTK is developed.
>  CMake does need some enhancements to make it work better with mobile
>development environments.  Working on enhancing CMake would be a much
>better place to put effort than to have multiple build systems inside
>VTK-VES.
>
>-Bill
>
>
>-- 
>Bill Hoffman
>Kitware, Inc.
>28 Corporate Drive
>Clifton Park, NY 12065
>bill.hoffman at kitware.com
>http://www.kitware.com
>518 881-4905 (Direct)
>518 371-3971 x105
>Fax (518) 371-4573
>_______________________________________________
>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 bill.hoffman at kitware.com  Mon Oct 27 12:14:24 2014
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 27 Oct 2014 12:14:24 -0400
Subject: [vtk-developers] Constructing Android.mk files for ndk-build
In-Reply-To: <D073C69E.4886%cameron.palmer@ntnu.no>
References: <D072B27A.487E%cameron.palmer@ntnu.no>
 <20141027024403.GA12785@bronto-burt.dev.benboeckel.net>
 <D073C69E.4886%cameron.palmer@ntnu.no>
Message-ID: <544E6F60.5030905@kitware.com>

On 10/27/2014 9:31 AM, Cameron Lowell Palmer wrote:
> Now maybe I?m missing something here, but I need to be able to set
> breakpoints in the VES and Kiwi C++ code. As I see it this is the only
> approach that is going to get me there. However, I?m quite willing to be
> wrong.:)
This is certainly a work in progress.  My email said that the goal would 
be to enhance CMake to support what is needed.  This has not yet been 
done.  Building all of VTK with android.mk files will never be a good 
solution.   I don't think anyone has spent the time yet to figure out 
what needs to be done to make the above work.

Also, I don't think CMake could in a general way create android.mk 
files.  So, we need to figure out the best way to compromise.  Looking 
at the NVIDA tegra IDE work might be a good place to start.

-Bill


From aashish.chaudhary at kitware.com  Mon Oct 27 13:53:31 2014
From: aashish.chaudhary at kitware.com (Aashish Chaudhary)
Date: Mon, 27 Oct 2014 13:53:31 -0400
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <D07407AC.4AC1%cameron.palmer@ntnu.no>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
 <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>
 <D07134FC.4842%cameron.palmer@ntnu.no>
 <544E487E.3070204@kitware.com>
 <D07407AC.4AC1%cameron.palmer@ntnu.no>
Message-ID: <CAEw35Z-O3WtdxV2SX+qREeS9ARr-22gVXPh9rT_Ck8vs7SbrWQ@mail.gmail.com>

FYI: Most (if not all) of the debugging we did was using command line tools
(some of them generates stack trace which can be viewed in the eclipse
plugin (specially the OpenGL ones).

- Aashish

On Mon, Oct 27, 2014 at 9:55 AM, Cameron Lowell Palmer <
cameron.palmer at ntnu.no> wrote:

> That is what I don?t get, how was the original Kiwi C++ code debugged on
> Android?
>
> I would be happy if cmake could generate a Makefile that just output a
> hierarchy of source and Android.mk files.
>
>
>
> On 27.10.14, 14.28, "Bill Hoffman" <bill.hoffman at kitware.com> wrote:
>
> >On 10/25/2014 5:26 AM, Cameron Lowell Palmer wrote:
> >>
> >> Let me illustrate. https://www.youtube.com/watch?v=kjsC-lKUgM8 is a
> >> video from Intel demonstrating debugging the NDK with Eclipse. This is a
> >> great resource for getting started with this problem, but it is
> >> unworkable because cmake creates a build directory with a project that
> >> is effectively just a binary with no source. I think it is important to
> >> address in the roadmap leveraging the Best Practices for the supported
> >> targets.
> >>
> >> At least that is my current thinking.
> >The idea would be to continue to enhance CMake to support the mobile
> >IDEs better as time moves forward.  We need something that is seamless
> >across windows, mac, and Linux, and works with iOS and Android.  Having
> >to maintain N different IDE files in VTK will never work.   NVIDIA has
> >been working on adding this type of support to CMake:
> >
> >
> http://www.cmake.org/pipermail/cmake-developers/2014-September/011308.html
> >
> >We worked some to get the build and debugging working with Eclipse here:
> >http://www.kitware.com/blog/home/post/642
> >
> >Ditching CMake does not make sense for VTK, it is how VTK is developed.
> >  CMake does need some enhancements to make it work better with mobile
> >development environments.  Working on enhancing CMake would be a much
> >better place to put effort than to have multiple build systems inside
> >VTK-VES.
> >
> >-Bill
> >
> >
> >--
> >Bill Hoffman
> >Kitware, Inc.
> >28 Corporate Drive
> >Clifton Park, NY 12065
> >bill.hoffman at kitware.com
> >http://www.kitware.com
> >518 881-4905 (Direct)
> >518 371-3971 x105
> >Fax (518) 371-4573
> >_______________________________________________
> >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
>
>


-- 



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

From cameron.palmer at ntnu.no  Mon Oct 27 14:01:55 2014
From: cameron.palmer at ntnu.no (Cameron Lowell Palmer)
Date: Mon, 27 Oct 2014 18:01:55 +0000
Subject: [vtk-developers] VES-Kiwi
In-Reply-To: <CAEw35Z-O3WtdxV2SX+qREeS9ARr-22gVXPh9rT_Ck8vs7SbrWQ@mail.gmail.com>
References: <36741845-AF1A-4044-AD99-AC51E4BEC0D9@ntnu.no>
 <CAEw35Z_zhSd_gi15OJMUrJEnUbtBiij9BEQJN_wUXssN1KiADA@mail.gmail.com>
 <E3CEBF2C-038F-45B5-AC0C-F140744E32F2@ntnu.no>
 <b2de9bc4bfd274900a85027a23cb496b@mail.gmail.com>
 <D07134FC.4842%cameron.palmer@ntnu.no> <544E487E.3070204@kitware.com>
 <D07407AC.4AC1%cameron.palmer@ntnu.no>
 <CAEw35Z-O3WtdxV2SX+qREeS9ARr-22gVXPh9rT_Ck8vs7SbrWQ@mail.gmail.com>
Message-ID: <D07445C8.4AF8%cameron.palmer@ntnu.no>

Well, I?m quite proud to say, it works, finally.

I can now set breakpoints in Eclipse! The scripting to pull the code into the right places is documented on my GitHub project:
https://github.com/palmerc/VES-Kiwi-NDK

I still need to clean this up further, do some better organization and apply it to our custom version, but I might actually meet my self imposed deadline to finish my first paper next month.

The work done here on VTK is super valuable. It would be a pity if it stays locked behind cmake.

From: Aashish Chaudhary <aashish.chaudhary at kitware.com<mailto:aashish.chaudhary at kitware.com>>
Date: mandag 27. oktober 2014 19.53
To: Cameron Lowell Palmer <cameron.palmer at ntnu.no<mailto:cameron.palmer at ntnu.no>>
Cc: Bill Hoffman <bill.hoffman at kitware.com<mailto:bill.hoffman at kitware.com>>, "vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>" <vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>>
Subject: Re: [vtk-developers] VES-Kiwi

FYI: Most (if not all) of the debugging we did was using command line tools (some of them generates stack trace which can be viewed in the eclipse plugin (specially the OpenGL ones).

- Aashish

On Mon, Oct 27, 2014 at 9:55 AM, Cameron Lowell Palmer <cameron.palmer at ntnu.no<mailto:cameron.palmer at ntnu.no>> wrote:
That is what I don?t get, how was the original Kiwi C++ code debugged on
Android?

I would be happy if cmake could generate a Makefile that just output a
hierarchy of source and Android.mk files.



On 27.10.14, 14.28, "Bill Hoffman" <bill.hoffman at kitware.com<mailto:bill.hoffman at kitware.com>> wrote:

>On 10/25/2014 5:26 AM, Cameron Lowell Palmer wrote:
>>
>> Let me illustrate. https://www.youtube.com/watch?v=kjsC-lKUgM8 is a
>> video from Intel demonstrating debugging the NDK with Eclipse. This is a
>> great resource for getting started with this problem, but it is
>> unworkable because cmake creates a build directory with a project that
>> is effectively just a binary with no source. I think it is important to
>> address in the roadmap leveraging the Best Practices for the supported
>> targets.
>>
>> At least that is my current thinking.
>The idea would be to continue to enhance CMake to support the mobile
>IDEs better as time moves forward.  We need something that is seamless
>across windows, mac, and Linux, and works with iOS and Android.  Having
>to maintain N different IDE files in VTK will never work.   NVIDIA has
>been working on adding this type of support to CMake:
>
>http://www.cmake.org/pipermail/cmake-developers/2014-September/011308.html
>
>We worked some to get the build and debugging working with Eclipse here:
>http://www.kitware.com/blog/home/post/642
>
>Ditching CMake does not make sense for VTK, it is how VTK is developed.
>  CMake does need some enhancements to make it work better with mobile
>development environments.  Working on enhancing CMake would be a much
>better place to put effort than to have multiple build systems inside
>VTK-VES.
>
>-Bill
>
>
>--
>Bill Hoffman
>Kitware, Inc.
>28 Corporate Drive
>Clifton Park, NY 12065
>bill.hoffman at kitware.com<mailto:bill.hoffman at kitware.com>
>http://www.kitware.com
>518 881-4905<tel:518%20881-4905> (Direct)
>518 371-3971 x105<tel:518%20371-3971%20x105>
>Fax (518) 371-4573<tel:%28518%29%20371-4573>
>_______________________________________________
>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
>

_______________________________________________
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




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

From utkarsh.ayachit at kitware.com  Wed Oct 29 12:18:26 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 29 Oct 2014 12:18:26 -0400
Subject: [vtk-developers] Why does vtkLookupTable not have the following
 functions? How should realize these functions?
In-Reply-To: <1414224842038-5729223.post@n5.nabble.com>
References: <1414224842038-5729223.post@n5.nabble.com>
Message-ID: <CADHSJjCmBiKjmCSqvx6snQd17UG=uehTFz_g+W0Z0DhHSrVmkA@mail.gmail.com>

What do you mean? vtkLookupTable indeed has those methods [1]. Are you
using VTK 6.1? These are new changes added to VTK master and will be
available in the next release of VTK.


[1] http://www.vtk.org/doc/nightly/html/classvtkLookupTable.html

On Sat, Oct 25, 2014 at 4:14 AM, weifeng0715 <weifeng0715 at gmail.com> wrote:
> virtual void    SetBelowRangeColor (double, double, double, double)
>
> virtual void    SetBelowRangeColor (double[4])
>
> virtual double *        GetBelowRangeColor ()
>
> virtual void    GetBelowRangeColor (double &, double &, double &, double &)
>
> virtual void    GetBelowRangeColor (double[4])
>
> virtual void    SetUseBelowRangeColor (int)
>
> virtual int     GetUseBelowRangeColor ()
>
> virtual void    UseBelowRangeColorOn ()
>
> virtual void    UseBelowRangeColorOff ()
>
> virtual void    SetAboveRangeColor (double, double, double, double)
>
> virtual void    SetAboveRangeColor (double[4])
>
> virtual double *        GetAboveRangeColor ()
>
> virtual void    GetAboveRangeColor (double &, double &, double &, double &)
>
> virtual void    GetAboveRangeColor (double[4])
>
> virtual void    SetUseAboveRangeColor (int)
>
> virtual int     GetUseAboveRangeColor ()
>
> virtual void    UseAboveRangeColorOn ()
>
> virtual void    UseAboveRangeColorOff ()
>
>
>
> --
> View this message in context: http://vtk.1045678.n5.nabble.com/Why-does-vtkLookupTable-not-have-the-following-functions-How-should-realize-these-functions-tp5729223.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From weifeng0715 at gmail.com  Wed Oct 29 13:15:25 2014
From: weifeng0715 at gmail.com (weifeng0715)
Date: Wed, 29 Oct 2014 10:15:25 -0700 (PDT)
Subject: [vtk-developers] Why does vtkLookupTable not have the following
 functions? How should realize these functions?
In-Reply-To: <CADHSJjCmBiKjmCSqvx6snQd17UG=uehTFz_g+W0Z0DhHSrVmkA@mail.gmail.com>
References: <1414224842038-5729223.post@n5.nabble.com>
 <CADHSJjCmBiKjmCSqvx6snQd17UG=uehTFz_g+W0Z0DhHSrVmkA@mail.gmail.com>
Message-ID: <1414602925985-5729284.post@n5.nabble.com>

I am using VTK6.1 and I could not find those functions.



--
View this message in context: http://vtk.1045678.n5.nabble.com/Why-does-vtkLookupTable-not-have-the-following-functions-How-should-realize-these-functions-tp5729223p5729284.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From utkarsh.ayachit at kitware.com  Wed Oct 29 13:48:09 2014
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 29 Oct 2014 13:48:09 -0400
Subject: [vtk-developers] Why does vtkLookupTable not have the following
 functions? How should realize these functions?
In-Reply-To: <1414602925985-5729284.post@n5.nabble.com>
References: <1414224842038-5729223.post@n5.nabble.com>
 <CADHSJjCmBiKjmCSqvx6snQd17UG=uehTFz_g+W0Z0DhHSrVmkA@mail.gmail.com>
 <1414602925985-5729284.post@n5.nabble.com>
Message-ID: <CADHSJjDH3Z3EsaL7W3q5CWL33a87P+xPyiSR0FMLgDB3nE557w@mail.gmail.com>

This is new functionality and hence not available in VTK 6.1.

Utkarsh

On Wed, Oct 29, 2014 at 1:15 PM, weifeng0715 <weifeng0715 at gmail.com> wrote:
> I am using VTK6.1 and I could not find those functions.
>
>
>
> --
> View this message in context: http://vtk.1045678.n5.nabble.com/Why-does-vtkLookupTable-not-have-the-following-functions-How-should-realize-these-functions-tp5729223p5729284.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From DLRdave at aol.com  Wed Oct 29 13:57:37 2014
From: DLRdave at aol.com (David Cole)
Date: Wed, 29 Oct 2014 13:57:37 -0400
Subject: [vtk-developers] Why does vtkLookupTable not have the following
 functions? How should realize these functions?
In-Reply-To: <CADHSJjDH3Z3EsaL7W3q5CWL33a87P+xPyiSR0FMLgDB3nE557w@mail.gmail.com>
References: <1414224842038-5729223.post@n5.nabble.com>
 <CADHSJjCmBiKjmCSqvx6snQd17UG=uehTFz_g+W0Z0DhHSrVmkA@mail.gmail.com>
 <1414602925985-5729284.post@n5.nabble.com>
 <CADHSJjDH3Z3EsaL7W3q5CWL33a87P+xPyiSR0FMLgDB3nE557w@mail.gmail.com>
Message-ID: <CAKME8fF+HUgY5_Gji2JPEFDijNo-5Fr-Kn4cEiA93jKxrrs4dw@mail.gmail.com>

If you must use VTK 6.1, you can find the corresponding documentation for
VTK 6.1 here:
http://www.vtk.org/doc/release/6.1/html/

If you are using a git checkout of "master," then the nightly documentation
is appropriate. But if you're stuck with the 6.1 release, you should refer
to the 6.1 documentation.

HTH,
David C.


On Wed, Oct 29, 2014 at 1:48 PM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> This is new functionality and hence not available in VTK 6.1.
>
> Utkarsh
>
> On Wed, Oct 29, 2014 at 1:15 PM, weifeng0715 <weifeng0715 at gmail.com>
> wrote:
> > I am using VTK6.1 and I could not find those functions.
> >
> >
> >
> > --
> > View this message in context:
> http://vtk.1045678.n5.nabble.com/Why-does-vtkLookupTable-not-have-the-following-functions-How-should-realize-these-functions-tp5729223p5729284.html
> > Sent from the VTK - Dev mailing list archive at Nabble.com.
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > 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/20141029/f6eadffd/attachment.html>

From weifeng0715 at gmail.com  Wed Oct 29 23:29:20 2014
From: weifeng0715 at gmail.com (weifeng0715)
Date: Wed, 29 Oct 2014 20:29:20 -0700 (PDT)
Subject: [vtk-developers] Why does vtkLookupTable not have the following
 functions? How should realize these functions?
In-Reply-To: <CAKME8fF+HUgY5_Gji2JPEFDijNo-5Fr-Kn4cEiA93jKxrrs4dw@mail.gmail.com>
References: <1414224842038-5729223.post@n5.nabble.com>
 <CADHSJjCmBiKjmCSqvx6snQd17UG=uehTFz_g+W0Z0DhHSrVmkA@mail.gmail.com>
 <1414602925985-5729284.post@n5.nabble.com>
 <CADHSJjDH3Z3EsaL7W3q5CWL33a87P+xPyiSR0FMLgDB3nE557w@mail.gmail.com>
 <CAKME8fF+HUgY5_Gji2JPEFDijNo-5Fr-Kn4cEiA93jKxrrs4dw@mail.gmail.com>
Message-ID: <1414639760294-5729291.post@n5.nabble.com>

Ok. Thanks.



--
View this message in context: http://vtk.1045678.n5.nabble.com/Why-does-vtkLookupTable-not-have-the-following-functions-How-should-realize-these-functions-tp5729223p5729291.html
Sent from the VTK - Dev mailing list archive at Nabble.com.