From bill.lorensen at gmail.com Thu Sep 2 08:06:18 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Sep 2010 08:06:18 -0400 Subject: [vtk-developers] Patch to modernize Widgets/Testing/Cxx In-Reply-To: References: Message-ID: Karthik, If we add the addition Start method to vtkTestingInteractor, then we should add the same method (perhaps a dummy method) to vtkRenderWindowInteractor. The idea is that the test/example should look the same whether run as a test or as an example. Bill On Tue, Aug 31, 2010 at 2:09 AM, Karthik Krishnan wrote: > On Tue, Aug 24, 2010 at 2:24 AM, Bill Lorensen > wrote: >> >> Karthik, >> >> I'm trying to complete a project I started last year to modernize the >> vtk cxx tests. I have gone through all of the Widgets cxx tests and >> changed them to use smart pointers and the vtkTestingInteractor. ?This >> reduces the number of lines in each test and makes them more readable. >> >> Can you apply the attached patch and give me some feedback? Marcus is >> also working to modernize the Charts testing. >> > > Thanks Bill. > > I'll submit this after my experimental build ends? up nice and green. > > In addition to your attached patch, I'll also try and trim it a bit more but > I was hoping to get some feedback. > > (a) I'd also like to replace lines of the form > > ? vtkSmartPointer recorder = > ??? vtkSmartPointer::New(); > ? recorder->SetInteractor(iren); > ? recorder->ReadFromInputStringOn(); > ? recorder->SetInputString(BoxWidgetEventLog2); > ? recorder->Play(); > ? recorder->Off(); > ? iren->Start(); > ? return EXIT_SUCCESS; > > with just > > ? return vtkTesting::InteractorEventLoop( argc, argv, iren, > BoxWidgetEventLog2 ); > > Perhaps we should move that recorder stuff into vtkTestingInteractor > instead; something like > ? iren->Start(BoxWidgetEventLog2) > > It would also be great to pass the event log as a command line; I'll try and > submit a patch ? > > Thanks > -- > karthik > From bill.lorensen at gmail.com Thu Sep 2 08:09:55 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Sep 2010 08:09:55 -0400 Subject: [vtk-developers] Chart Regression Failures on WikiExamples In-Reply-To: References: Message-ID: Marcus, But if I look at this example, http://www.cdash.org/CDash/testDetails.php?test=64471785&build=710283 the old (Valid Image) looks "better" than the new (Test Image). Same holds for http://www.cdash.org/CDash/testDetails.php?test=64471786&build=710283 Bill On Tue, Aug 31, 2010 at 2:45 AM, Marcus D. Hanwell wrote: > On Mon, Aug 30, 2010 at 12:16 PM, Bill Lorensen > wrote: >> >> Marcus, >> >> On August 25, several Wiki Examples that use charts started to fail >> regression tests. >> >> For example, >> http://www.cdash.org/CDash/testDetails.php?test=64174959&build=707531 >> and >> http://www.cdash.org/CDash/testDetails.php?test=64174962&build=707531 >> >> Have you noticed similar problems? >> > Hi Bill, > I had intended to email you about that. I was working on the code to do the > layout in the charts, it now uses font metrics and lays the chart out > automatically based on the font metrics returned for the axes. This means > that virtually every image with an axis had to be updated (which I did in > the regression tests). > Thanks, > Marcus (from sunny Chester, UK) From karthik.krishnan at kitware.com Thu Sep 2 08:17:59 2010 From: karthik.krishnan at kitware.com (Karthik Krishnan) Date: Thu, 2 Sep 2010 17:47:59 +0530 Subject: [vtk-developers] Patch to modernize Widgets/Testing/Cxx In-Reply-To: References: Message-ID: My mistake, did not think it through. The existing iren->Start() could take care of the event recording and playback as well... depending on whether -I, --DisableReplay, --Record flags are set. The parsing of the command line arguments would be done in the CMAKE_TEST_DRIVER_BEFORE_MAIN thing.. and appropriate the switches set on vtkTestingInteractor so it can do the playback -or- record -or- interactive_mode_w/wo_playback. That would get necessitate moving all those long eventlog strings into VTKData first. Would that be better ? thanks -- karthik On Thu, Sep 2, 2010 at 5:36 PM, Bill Lorensen wrote: > Karthik, > > If we add the addition Start method to vtkTestingInteractor, then we > should add the same method (perhaps a dummy method) to > vtkRenderWindowInteractor. The idea is that the test/example should > look the same whether run as a test or as an example. > > Bill > > On Tue, Aug 31, 2010 at 2:09 AM, Karthik Krishnan > wrote: > > On Tue, Aug 24, 2010 at 2:24 AM, Bill Lorensen > > wrote: > >> > >> Karthik, > >> > >> I'm trying to complete a project I started last year to modernize the > >> vtk cxx tests. I have gone through all of the Widgets cxx tests and > >> changed them to use smart pointers and the vtkTestingInteractor. This > >> reduces the number of lines in each test and makes them more readable. > >> > >> Can you apply the attached patch and give me some feedback? Marcus is > >> also working to modernize the Charts testing. > >> > > > > Thanks Bill. > > > > I'll submit this after my experimental build ends up nice and green. > > > > In addition to your attached patch, I'll also try and trim it a bit more > but > > I was hoping to get some feedback. > > > > (a) I'd also like to replace lines of the form > > > > vtkSmartPointer recorder = > > vtkSmartPointer::New(); > > recorder->SetInteractor(iren); > > recorder->ReadFromInputStringOn(); > > recorder->SetInputString(BoxWidgetEventLog2); > > recorder->Play(); > > recorder->Off(); > > iren->Start(); > > return EXIT_SUCCESS; > > > > with just > > > > return vtkTesting::InteractorEventLoop( argc, argv, iren, > > BoxWidgetEventLog2 ); > > > > Perhaps we should move that recorder stuff into vtkTestingInteractor > > instead; something like > > iren->Start(BoxWidgetEventLog2) > > > > It would also be great to pass the event log as a command line; I'll try > and > > submit a patch ? > > > > Thanks > > -- > > karthik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Sep 2 09:09:44 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Sep 2010 09:09:44 -0400 Subject: [vtk-developers] Patch to modernize Widgets/Testing/Cxx In-Reply-To: References: Message-ID: That sounds much better. Let's chew on it a bit more. Bill On Thu, Sep 2, 2010 at 8:17 AM, Karthik Krishnan wrote: > My mistake, did not think it through. The existing iren->Start() could take > care of the event recording and playback as well... depending on whether -I, > --DisableReplay, --Record flags are set. > > The parsing of the command line arguments would be done in the > CMAKE_TEST_DRIVER_BEFORE_MAIN thing.. and appropriate the switches set on > vtkTestingInteractor so it can do the playback -or- record -or- > interactive_mode_w/wo_playback. That would get necessitate moving all those > long eventlog strings into VTKData first. > > Would that be better ? > > thanks > -- > karthik > > On Thu, Sep 2, 2010 at 5:36 PM, Bill Lorensen > wrote: >> >> Karthik, >> >> If we add the addition Start method to vtkTestingInteractor, then we >> should add the same method (perhaps a dummy method) to >> vtkRenderWindowInteractor. The idea is that the test/example should >> look the same whether run as a test or as an example. >> >> Bill >> >> On Tue, Aug 31, 2010 at 2:09 AM, Karthik Krishnan >> wrote: >> > On Tue, Aug 24, 2010 at 2:24 AM, Bill Lorensen >> > wrote: >> >> >> >> Karthik, >> >> >> >> I'm trying to complete a project I started last year to modernize the >> >> vtk cxx tests. I have gone through all of the Widgets cxx tests and >> >> changed them to use smart pointers and the vtkTestingInteractor. ?This >> >> reduces the number of lines in each test and makes them more readable. >> >> >> >> Can you apply the attached patch and give me some feedback? Marcus is >> >> also working to modernize the Charts testing. >> >> >> > >> > Thanks Bill. >> > >> > I'll submit this after my experimental build ends? up nice and green. >> > >> > In addition to your attached patch, I'll also try and trim it a bit more >> > but >> > I was hoping to get some feedback. >> > >> > (a) I'd also like to replace lines of the form >> > >> > ? vtkSmartPointer recorder = >> > ??? vtkSmartPointer::New(); >> > ? recorder->SetInteractor(iren); >> > ? recorder->ReadFromInputStringOn(); >> > ? recorder->SetInputString(BoxWidgetEventLog2); >> > ? recorder->Play(); >> > ? recorder->Off(); >> > ? iren->Start(); >> > ? return EXIT_SUCCESS; >> > >> > with just >> > >> > ? return vtkTesting::InteractorEventLoop( argc, argv, iren, >> > BoxWidgetEventLog2 ); >> > >> > Perhaps we should move that recorder stuff into vtkTestingInteractor >> > instead; something like >> > ? iren->Start(BoxWidgetEventLog2) >> > >> > It would also be great to pass the event log as a command line; I'll try >> > and >> > submit a patch ? >> > >> > Thanks >> > -- >> > karthik >> > > > From daviddoria+vtk at gmail.com Thu Sep 2 12:55:57 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Thu, 2 Sep 2010 12:55:57 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: On Thu, Aug 26, 2010 at 8:14 AM, David Doria > wrote: > vtkKdTreePointLocator is a leaf class that implements the >> vtkAbstractPointLocator interface. It would be best if new interface >> methods were be added at the abstract layer and then implemented in each >> leaf class. >> >> > Good point. Even better than that, the abstract class can provide the > implementation because all it does is setup the parameters to call a pure > virtual function. This means that the logic of changing parameters is done > at the abstract level, then the appropriate "inner function" is called > depending on the subclass. > > I have added this type of convenience function > for FindClosestPoint, FindClosestNPoints, and FindPointsWithinRadius. > > The code is here: > repo: git at github.com:daviddoria/daviddoria-vtk.git > branch: VTK-KdTree > > I added tests for all of the subclasses to exercise the new (and old) > functions: > Filter/Testing/Cxx/TestKdTreePointLocator.cxx > Filter/Testing/Cxx/TestOctreePointLocator.cxx > Filter/Testing/Cxx/TestIncrementalOctreePointLocator.cxx > Filter/Testing/Cxx/TestPointLocator.cxx > > A potential problem with your proposed implementation is that it assumes >> the vtkDataSet is a vtkPointSet, which may not be true. >> >> It looks like vtkDataSet also implements a GetPoint(vtkIdType, double*) > function, so I changed it to cast to a vtkDataSet instead of a vtkPointSet. > > >> I definitely agree that the proposed api is convenient, but it doesn't add >> new power to the class. >> >> > Yes, they are indeed convenience functions! I'm all for making things more > convenient :) > > Please let me know what you think. > > Thanks, > > David > Did anyone get a chance to look at this? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Thu Sep 2 15:01:33 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Thu, 2 Sep 2010 15:01:33 -0400 Subject: [vtk-developers] Unused arguments warnings Message-ID: I've seen a handful of unused args warnings when compiling lately (argc and argv in some tests). Should I change them to int TestName(int, char*[]) or int TestName(int vtkNotUsed(argc), char*vtkNotUsed(argv)[]) ? Is the idea of the vtkNotUsed macro just that the code explicitly says "we are not using this" rather than making the reader wonder if they forgot to name the variable? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Sep 2 15:37:30 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Sep 2010 15:37:30 -0400 Subject: [vtk-developers] Unused arguments warnings In-Reply-To: References: Message-ID: int TestName(int, char*[]) the int TestName(int vtkNotUsed(argc), char*vtkNotUsed(argv)[]) is really for internal vtk developers. On Thu, Sep 2, 2010 at 3:01 PM, David Doria wrote: > I've seen a handful of unused args warnings when compiling lately (argc and > argv in some tests). > Should I change them to > int TestName(int, char*[]) > or > int TestName(int?vtkNotUsed(argc), char*vtkNotUsed(argv)[]) > ? > Is the idea of the vtkNotUsed macro just that the code explicitly says "we > are not using this" rather than making the reader wonder if they forgot to > name the variable? > Thanks, > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From sean at rogue-research.com Thu Sep 2 16:08:40 2010 From: sean at rogue-research.com (Sean McBride) Date: Thu, 2 Sep 2010 16:08:40 -0400 Subject: [vtk-developers] Unused arguments warnings In-Reply-To: References: Message-ID: <20100902200840.477705361@mail.rogue-research.com> On Thu, 2 Sep 2010 15:01:33 -0400, David Doria said: >I've seen a handful of unused args warnings when compiling lately (argc and >argv in some tests). > >Should I change them to > >int TestName(int, char*[]) > >or > >int TestName(int vtkNotUsed(argc), char*vtkNotUsed(argv)[]) > >? > >Is the idea of the vtkNotUsed macro just that the code explicitly says "we >are not using this" rather than making the reader wonder if they forgot to >name the variable? Another option is: int TestName(int argc, char* argv[]) { (void)argc; (void)argv; } which is done is some VTK files... Dunno if there is a preferred convention. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From daviddoria+vtk at gmail.com Fri Sep 3 11:54:51 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Fri, 3 Sep 2010 11:54:51 -0400 Subject: [vtk-developers] Unused arguments warnings In-Reply-To: <20100902200840.477705361@mail.rogue-research.com> References: <20100902200840.477705361@mail.rogue-research.com> Message-ID: > Another option is: > > int TestName(int argc, char* argv[]) > { > ?(void)argc; > ?(void)argv; > > } > > which is done is some VTK files... Dunno if there is a preferred convention. If we can come to a consensus on a convention and write it down here: http://www.vtk.org/Wiki/VTK_Coding_Standards , I volunteer to make everything consistent. Bill - when you said "is really for internal vtk developers" do you mean VTK class functions only as opposed to Tests? David From bill.lorensen at gmail.com Fri Sep 3 12:22:34 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 3 Sep 2010 12:22:34 -0400 Subject: [vtk-developers] Unused arguments warnings In-Reply-To: References: <20100902200840.477705361@mail.rogue-research.com> Message-ID: As opposed to wiki examples. On Fri, Sep 3, 2010 at 11:54 AM, David Doria wrote: >> Another option is: >> >> int TestName(int argc, char* argv[]) >> { >> ?(void)argc; >> ?(void)argv; >> >> } >> >> which is done is some VTK files... Dunno if there is a preferred convention. > > If we can come to a consensus on a convention and write it down here: > http://www.vtk.org/Wiki/VTK_Coding_Standards , I volunteer to make > everything consistent. > > Bill - when you said "is really for internal vtk developers" do you > mean VTK class functions only as opposed to Tests? > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > From daviddoria+vtk at gmail.com Fri Sep 3 12:26:13 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Fri, 3 Sep 2010 12:26:13 -0400 Subject: [vtk-developers] Unused arguments warnings In-Reply-To: References: <20100902200840.477705361@mail.rogue-research.com> Message-ID: On Fri, Sep 3, 2010 at 12:22 PM, Bill Lorensen wrote: > As opposed to wiki examples. What I am talking about here are the tests inside the VTK distribution (src/VTK/IO/Testing/Cxx/TestSomething.cxx). David From bill.lorensen at gmail.com Fri Sep 3 12:49:46 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 3 Sep 2010 12:49:46 -0400 Subject: [vtk-developers] Unused arguments warnings In-Reply-To: References: <20100902200840.477705361@mail.rogue-research.com> Message-ID: There, vtkNotUsed seems appropriate. On Fri, Sep 3, 2010 at 12:26 PM, David Doria wrote: > On Fri, Sep 3, 2010 at 12:22 PM, Bill Lorensen wrote: >> As opposed to wiki examples. > > What I am talking about here are the tests inside the VTK distribution > (src/VTK/IO/Testing/Cxx/TestSomething.cxx). > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > From daviddoria+vtk at gmail.com Sat Sep 4 08:15:00 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Sat, 4 Sep 2010 08:15:00 -0400 Subject: [vtk-developers] TestBSPTree.cxx compile error Message-ID: In Cygwin there is an error compiling TestBSPTree.cxx. This conditional passes (it thinks it is WIN32) but then conio.h cannot be found. #ifdef WIN32 #include #endif 1) Shouldn't cygwin report that it is NOT win32? 2) Later in the file there is this code: #ifdef WIN32 if (kbhit()) { char c = getch(); if (c=='A') break; } #endif but there is no equivalent statement for not win32 - what is the point of that code? Can it simply be removed? 3) I don't see any cygwin dashboards - can Kitware (or someone) setup a nightly cygwin build? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.partyka at kitware.com Sat Sep 4 09:29:24 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Sat, 4 Sep 2010 09:29:24 -0400 Subject: [vtk-developers] TestBSPTree.cxx compile error In-Reply-To: References: Message-ID: Dash14 was running a cygwin dashboard. Let me see if I can find out what happened to it. If anything, change TestBDSPTree to use the following instead. #if defined( _WIN32 ) && !defined( __CYGWIN__ ) On Sat, Sep 4, 2010 at 8:15 AM, David Doria > wrote: > In Cygwin there is an error compiling TestBSPTree.cxx. This conditional > passes (it thinks it is WIN32) but then conio.h cannot be found. > > #ifdef WIN32 > #include > #endif > > 1) Shouldn't cygwin report that it is NOT win32? > > 2) Later in the file there is this code: > > #ifdef WIN32 > if (kbhit()) { > char c = getch(); > if (c=='A') break; > } > #endif > > but there is no equivalent statement for not win32 - what is the point of > that code? Can it simply be removed? > > 3) I don't see any cygwin dashboards - can Kitware (or someone) setup a > nightly cygwin build? > > Thanks, > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Mon Sep 6 12:24:02 2010 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Mon, 6 Sep 2010 18:24:02 +0200 Subject: [vtk-developers] TestBSPTree.cxx compile error In-Reply-To: References: Message-ID: 2) Later in the file there is this code: #ifdef WIN32 if (kbhit()) { char c = getch(); if (c=='A') break; } #endif That was for me to do debugging and you can remove it, or just add some #if 0 around it to comment it out JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Mon Sep 6 14:24:51 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Mon, 6 Sep 2010 14:24:51 -0400 Subject: [vtk-developers] Missing typedef in vtkSocket.cxx Message-ID: When compiling on Windows Vista with Visual Studio 2008 I got a "socklen_t is undefined" compiler error. I added typedef int socklen_t; at the top of the file and then it worked. Anyone involved with vtkSocket know if that seems like a reasonable fix? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Sep 6 14:32:26 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 6 Sep 2010 14:32:26 -0400 Subject: [vtk-developers] Missing typedef in vtkSocket.cxx In-Reply-To: References: Message-ID: Seems like that should be in some system include file. It's dangerous to assume a particular atomic type. The correct fix is to find where it is defined on that system and #include the proper file, maybe with #if system guards. Bill On Mon, Sep 6, 2010 at 2:24 PM, David Doria wrote: > When compiling on Windows Vista with Visual Studio 2008 I got a "socklen_t > is undefined" compiler error. > I added > typedef int socklen_t; > at the top of the file and then it worked. Anyone involved with vtkSocket > know if that seems like a reasonable fix? > Thanks, > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From dave.partyka at kitware.com Mon Sep 6 14:46:24 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Mon, 6 Sep 2010 14:46:24 -0400 Subject: [vtk-developers] Missing typedef in vtkSocket.cxx In-Reply-To: References: Message-ID: I think socklen_t is posix. The line of code you speak of is guarded with an ifdef set by a trycompile. It shouldn't be defined if you're using Visual Studio as far as I can tell. #if defined(VTK_HAVE_GETSOCKNAME_WITH_SOCKLEN_T) socklen_t sizebuf = sizeof(sockinfo); #else On Mon, Sep 6, 2010 at 2:32 PM, Bill Lorensen wrote: > Seems like that should be in some system include file. It's dangerous > to assume a particular atomic type. The correct fix is to find where > it is defined on that system and #include the proper file, maybe with > #if system guards. > > Bill > > On Mon, Sep 6, 2010 at 2:24 PM, David Doria > > wrote: > > When compiling on Windows Vista with Visual Studio 2008 I got a > "socklen_t > > is undefined" compiler error. > > I added > > typedef int socklen_t; > > at the top of the file and then it worked. Anyone involved with vtkSocket > > know if that seems like a reasonable fix? > > Thanks, > > > > 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emonson at cs.duke.edu Mon Sep 6 20:18:22 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Mon, 6 Sep 2010 20:18:22 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping Message-ID: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> Hello, I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? Thanks a lot, -Eric ------------------------------------------------------ Eric E Monson Duke Visualization Technology Group From david.gobbi at gmail.com Mon Sep 6 20:48:18 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 6 Sep 2010 18:48:18 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> Message-ID: Hi Eric, The python wrapping of the vtkArray class was broken by this commit, which happened while I was on vacation: http://vtk.org/gitweb?p=VTK.git;a=commit;h=ba442dcd57fe6bf52ef7fb9c21cb842e78e489cd This commit added the typedefs CoordinateT, DimensionT, and SizeT to vtkArray and its support classes. The wrappers do not support typedefs yet, except for a few like vtkIdType that have been hard-coded. You can try doing a checkout before the commit mentioned above and see how things work. I didn't have much time to experiment with these classes. David On Mon, Sep 6, 2010 at 6:18 PM, Eric E. Monson wrote: > Hello, > > I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. > > I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? > > Thanks a lot, > -Eric > > ------------------------------------------------------ > Eric E Monson > Duke Visualization Technology Group > > From jimcp at cox.net Mon Sep 6 23:21:30 2010 From: jimcp at cox.net (Jim Peterson) Date: Mon, 06 Sep 2010 23:21:30 -0400 Subject: [vtk-developers] Java Examples/Tutorial/step6 code on the wiki page Message-ID: <4C85AFBA.2020008@cox.net> All, I updated the wiki page with a Java example code6.java which I believe could be the missing java box widget example under the tutorial. I am hoping to learn vtk using Java, so as I encounter missing java examples I have been transforming the corresponding python examples. I intend to post them to the wiki as I make progress with this effort. Do I need to do any more than update the wiki pages to contribute the example code for distribution? Hope this helps, Jim From emonson at cs.duke.edu Tue Sep 7 08:43:27 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 7 Sep 2010 08:43:27 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> Message-ID: <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> Hey David, Thanks for the explanation. I'll try to get back to before that commit with all of Titan and see how it works. I hope this can be worked out eventually, though. It seems like the wrappers are a tough thing because the C++ code is such a moving target! I'm just curious -- I know there are strong motivations in place for people to fix things when their commits break other parts of VTK, but is there anything formal in place regarding breaking the python wrapping? (I would assume it only shows up on the dashboards if there happens to be a Python test that covers a given class.) Thanks again, -Eric On Sep 6, 2010, at 8:48 PM, David Gobbi wrote: > Hi Eric, > > The python wrapping of the vtkArray class was broken by this commit, > which happened while I was on vacation: > > http://vtk.org/gitweb?p=VTK.git;a=commit;h=ba442dcd57fe6bf52ef7fb9c21cb842e78e489cd > > This commit added the typedefs CoordinateT, DimensionT, and SizeT to > vtkArray and its support classes. The wrappers do not support > typedefs yet, except for a few like vtkIdType that have been > hard-coded. You can try doing a checkout before the commit mentioned > above and see how things work. I didn't have much time to experiment > with these classes. > > David > > > On Mon, Sep 6, 2010 at 6:18 PM, Eric E. Monson wrote: >> Hello, >> >> I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. >> >> I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? >> >> Thanks a lot, >> -Eric >> >> ------------------------------------------------------ >> Eric E Monson >> Duke Visualization Technology Group >> >> From david.gobbi at gmail.com Tue Sep 7 09:14:56 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 07:14:56 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> Message-ID: Hi Eric, Code maintenance for the wrappers is no different from any other part of VTK, i.e. anything that isn't tested will eventually break, if it isn't broken already. On the dashboard, TestStringsPython and TestVariantPython used vtkArray methods and both are failing because of the recent vtkArray changes, so you can bet that this issue will eventually be resolved but it might take time. If I'd written a vtkArray-specific python test (like I did for vtkVariant), it would have helped. The moving target issue is usually not a problem. The wrappers are generated automatically and they will adapt to most changes in the C++ code; cases like this one with vtkArray are the exception rather than the rule. I'm looking into how easy/difficult it will be to add basic typedef support to the wrappers. David On Tue, Sep 7, 2010 at 6:43 AM, Eric E. Monson wrote: > Hey David, > > Thanks for the explanation. I'll try to get back to before that commit with all of Titan and see how it works. I hope this can be worked out eventually, though. > > It seems like the wrappers are a tough thing because the C++ code is such a moving target! I'm just curious -- I know there are strong motivations in place for people to fix things when their commits break other parts of VTK, but is there anything formal in place regarding breaking the python wrapping? (I would assume it only shows up on the dashboards if there happens to be a Python test that covers a given class.) > > Thanks again, > -Eric > > > On Sep 6, 2010, at 8:48 PM, David Gobbi wrote: > >> Hi Eric, >> >> The python wrapping of the vtkArray class was broken by this commit, >> which happened while I was on vacation: >> >> http://vtk.org/gitweb?p=VTK.git;a=commit;h=ba442dcd57fe6bf52ef7fb9c21cb842e78e489cd >> >> This commit added the typedefs CoordinateT, DimensionT, and SizeT to >> vtkArray and its support classes. ?The wrappers do not support >> typedefs yet, except for a few like vtkIdType that have been >> hard-coded. ?You can try doing a checkout before the commit mentioned >> above and see how things work. ?I didn't have much time to experiment >> with these classes. >> >> ?David >> >> >> On Mon, Sep 6, 2010 at 6:18 PM, Eric E. Monson wrote: >>> Hello, >>> >>> I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. >>> >>> I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? >>> >>> Thanks a lot, >>> -Eric >>> >>> ------------------------------------------------------ >>> Eric E Monson >>> Duke Visualization Technology Group >>> >>> > > From david.gobbi at gmail.com Tue Sep 7 09:30:13 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 07:30:13 -0600 Subject: [vtk-developers] ReadOpenGLExtensions() should not call Render() Message-ID: Hi All, I have a little complaint about this code in vtkOpenGLExtensionManager::ReadOpenGLExtensions() this->RenderWindow->MakeCurrent(); if (!this->RenderWindow->IsCurrent()) { // Really should create a method in the render window to create // the graphics context instead of forcing a full render. this->RenderWindow->Render(); } Calling Render() inside ReadOpenGLExtensions() is a bad thing. It can cause the first render to occur as a side effect, and it might result in the window being rendered before it has been properly sized and positioned. From what I've seen, this Render always gets called on Windows but never on X. This render was also the cause of bug 11208 (http://www.vtk.org/Bug/view.php?id=11208) which took me the better part of a day to track down. David From emonson at cs.duke.edu Tue Sep 7 11:17:08 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 7 Sep 2010 11:17:08 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> Message-ID: <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> Hey David, I was able to check out the older versions and change some other typedef spots and the extra methods are now available, but it looks like there's still no way to access the data. In C++ it looks like the only way to get a vtkArrayRange object out of the vtkArrayExtents is to use the bracket [] operator, and that doesn't translate into Python correctly, as far as I can tell. We may just need to add some sort of GetRange(DimensionT i) method for the wrapping... (I'm cc-ing Tim on this since I know you didn't come up with these classes.) Thanks, -Eric On Sep 7, 2010, at 9:14 AM, David Gobbi wrote: > Hi Eric, > > Code maintenance for the wrappers is no different from any other part > of VTK, i.e. anything that isn't tested will eventually break, if it > isn't broken already. > > On the dashboard, TestStringsPython and TestVariantPython used > vtkArray methods and both are failing because of the recent vtkArray > changes, so you can bet that this issue will eventually be resolved > but it might take time. If I'd written a vtkArray-specific python > test (like I did for vtkVariant), it would have helped. > > The moving target issue is usually not a problem. The wrappers are > generated automatically and they will adapt to most changes in the C++ > code; cases like this one with vtkArray are the exception rather than > the rule. I'm looking into how easy/difficult it will be to add basic > typedef support to the wrappers. > > David > > > On Tue, Sep 7, 2010 at 6:43 AM, Eric E. Monson wrote: >> Hey David, >> >> Thanks for the explanation. I'll try to get back to before that commit with all of Titan and see how it works. I hope this can be worked out eventually, though. >> >> It seems like the wrappers are a tough thing because the C++ code is such a moving target! I'm just curious -- I know there are strong motivations in place for people to fix things when their commits break other parts of VTK, but is there anything formal in place regarding breaking the python wrapping? (I would assume it only shows up on the dashboards if there happens to be a Python test that covers a given class.) >> >> Thanks again, >> -Eric >> >> >> On Sep 6, 2010, at 8:48 PM, David Gobbi wrote: >> >>> Hi Eric, >>> >>> The python wrapping of the vtkArray class was broken by this commit, >>> which happened while I was on vacation: >>> >>> http://vtk.org/gitweb?p=VTK.git;a=commit;h=ba442dcd57fe6bf52ef7fb9c21cb842e78e489cd >>> >>> This commit added the typedefs CoordinateT, DimensionT, and SizeT to >>> vtkArray and its support classes. The wrappers do not support >>> typedefs yet, except for a few like vtkIdType that have been >>> hard-coded. You can try doing a checkout before the commit mentioned >>> above and see how things work. I didn't have much time to experiment >>> with these classes. >>> >>> David >>> >>> >>> On Mon, Sep 6, 2010 at 6:18 PM, Eric E. Monson wrote: >>>> Hello, >>>> >>>> I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. >>>> >>>> I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? >>>> >>>> Thanks a lot, >>>> -Eric >>>> >>>> ------------------------------------------------------ >>>> Eric E Monson >>>> Duke Visualization Technology Group >>>> >>>> >> >> From david.gobbi at gmail.com Tue Sep 7 12:07:54 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 10:07:54 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> Message-ID: Maybe we can all work together to get these classes fully wrapped. Can you post your changes somewhere? David On Tue, Sep 7, 2010 at 9:17 AM, Eric E. Monson wrote: > Hey David, > > I was able to check out the older versions and change some other typedef spots and the extra methods are now available, but it looks like there's still no way to access the data. > > In C++ it looks like the only way to get a vtkArrayRange object out of the vtkArrayExtents is to use the bracket [] operator, and that doesn't translate into Python correctly, as far as I can tell. We may just need to add some sort of GetRange(DimensionT i) method for the wrapping... (I'm cc-ing Tim on this since I know you didn't come up with these classes.) > > Thanks, > -Eric > > > On Sep 7, 2010, at 9:14 AM, David Gobbi wrote: > >> Hi Eric, >> >> Code maintenance for the wrappers is no different from any other part >> of VTK, i.e. anything that isn't tested will eventually break, if it >> isn't broken already. >> >> On the dashboard, TestStringsPython and TestVariantPython used >> vtkArray methods and both are failing because of the recent vtkArray >> changes, so you can bet that this issue will eventually be resolved >> but it might take time. ?If I'd written a vtkArray-specific python >> test (like I did for vtkVariant), it would have helped. >> >> The moving target issue is usually not a problem. ?The wrappers are >> generated automatically and they will adapt to most changes in the C++ >> code; cases like this one with vtkArray are the exception rather than >> the rule. ?I'm looking into how easy/difficult it will be to add basic >> typedef support to the wrappers. >> >> ?David >> >> >> On Tue, Sep 7, 2010 at 6:43 AM, Eric E. Monson wrote: >>> Hey David, >>> >>> Thanks for the explanation. I'll try to get back to before that commit with all of Titan and see how it works. I hope this can be worked out eventually, though. >>> >>> It seems like the wrappers are a tough thing because the C++ code is such a moving target! I'm just curious -- I know there are strong motivations in place for people to fix things when their commits break other parts of VTK, but is there anything formal in place regarding breaking the python wrapping? (I would assume it only shows up on the dashboards if there happens to be a Python test that covers a given class.) >>> >>> Thanks again, >>> -Eric >>> >>> >>> On Sep 6, 2010, at 8:48 PM, David Gobbi wrote: >>> >>>> Hi Eric, >>>> >>>> The python wrapping of the vtkArray class was broken by this commit, >>>> which happened while I was on vacation: >>>> >>>> http://vtk.org/gitweb?p=VTK.git;a=commit;h=ba442dcd57fe6bf52ef7fb9c21cb842e78e489cd >>>> >>>> This commit added the typedefs CoordinateT, DimensionT, and SizeT to >>>> vtkArray and its support classes. ?The wrappers do not support >>>> typedefs yet, except for a few like vtkIdType that have been >>>> hard-coded. ?You can try doing a checkout before the commit mentioned >>>> above and see how things work. ?I didn't have much time to experiment >>>> with these classes. >>>> >>>> ?David >>>> >>>> >>>> On Mon, Sep 6, 2010 at 6:18 PM, Eric E. Monson wrote: >>>>> Hello, >>>>> >>>>> I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. >>>>> >>>>> I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? >>>>> >>>>> Thanks a lot, >>>>> -Eric >>>>> >>>>> ------------------------------------------------------ >>>>> Eric E Monson >>>>> Duke Visualization Technology Group >>>>> >>>>> >>> >>> > > From emonson at cs.duke.edu Tue Sep 7 12:38:26 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 7 Sep 2010 12:38:26 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> Message-ID: <0D3F58C3-30FF-4AD8-9EC8-97B1C56C519A@cs.duke.edu> I was just thinking of something simple like this (note that I've gotten rid of all of Tim's typedef stuff in this version. At first I thought of GetRange(), but I changed it since that means something else in other VTK classes...): diff --git a/Common/vtkArrayExtents.cxx b/Common/vtkArrayExtents.cxx index 833fe5d..59e7c64 100644 --- a/Common/vtkArrayExtents.cxx +++ b/Common/vtkArrayExtents.cxx @@ -114,6 +114,11 @@ void vtkArrayExtents::SetDimensions(vtkIdType dimensions) this->Storage.assign(dimensions, vtkArrayRange()); } +vtkArrayRange& vtkArrayExtents::GetDimensionRange(vtkIdType i) +{ + return this->Storage[i]; +} + vtkArrayRange& vtkArrayExtents::operator[](vtkIdType i) { return this->Storage[i]; diff --git a/Common/vtkArrayExtents.h b/Common/vtkArrayExtents.h index 7d45861..ed4095a 100644 --- a/Common/vtkArrayExtents.h +++ b/Common/vtkArrayExtents.h @@ -124,6 +124,10 @@ public: // Description: // Accesses the extent of the i-th dimension. + vtkArrayRange& GetDimensionRange(vtkIdType i); + + // Description: + // Accesses the extent of the i-th dimension. vtkArrayRange& operator[](vtkIdType i); // Description: On Sep 7, 2010, at 12:07 PM, David Gobbi wrote: > Maybe we can all work together to get these classes fully wrapped. > Can you post your changes somewhere? > > David > > > On Tue, Sep 7, 2010 at 9:17 AM, Eric E. Monson wrote: >> Hey David, >> >> I was able to check out the older versions and change some other typedef spots and the extra methods are now available, but it looks like there's still no way to access the data. >> >> In C++ it looks like the only way to get a vtkArrayRange object out of the vtkArrayExtents is to use the bracket [] operator, and that doesn't translate into Python correctly, as far as I can tell. We may just need to add some sort of GetRange(DimensionT i) method for the wrapping... (I'm cc-ing Tim on this since I know you didn't come up with these classes.) >> >> Thanks, >> -Eric >> >> >> On Sep 7, 2010, at 9:14 AM, David Gobbi wrote: >> >>> Hi Eric, >>> >>> Code maintenance for the wrappers is no different from any other part >>> of VTK, i.e. anything that isn't tested will eventually break, if it >>> isn't broken already. >>> >>> On the dashboard, TestStringsPython and TestVariantPython used >>> vtkArray methods and both are failing because of the recent vtkArray >>> changes, so you can bet that this issue will eventually be resolved >>> but it might take time. If I'd written a vtkArray-specific python >>> test (like I did for vtkVariant), it would have helped. >>> >>> The moving target issue is usually not a problem. The wrappers are >>> generated automatically and they will adapt to most changes in the C++ >>> code; cases like this one with vtkArray are the exception rather than >>> the rule. I'm looking into how easy/difficult it will be to add basic >>> typedef support to the wrappers. >>> >>> David >>> >>> >>> On Tue, Sep 7, 2010 at 6:43 AM, Eric E. Monson wrote: >>>> Hey David, >>>> >>>> Thanks for the explanation. I'll try to get back to before that commit with all of Titan and see how it works. I hope this can be worked out eventually, though. >>>> >>>> It seems like the wrappers are a tough thing because the C++ code is such a moving target! I'm just curious -- I know there are strong motivations in place for people to fix things when their commits break other parts of VTK, but is there anything formal in place regarding breaking the python wrapping? (I would assume it only shows up on the dashboards if there happens to be a Python test that covers a given class.) >>>> >>>> Thanks again, >>>> -Eric >>>> >>>> >>>> On Sep 6, 2010, at 8:48 PM, David Gobbi wrote: >>>> >>>>> Hi Eric, >>>>> >>>>> The python wrapping of the vtkArray class was broken by this commit, >>>>> which happened while I was on vacation: >>>>> >>>>> http://vtk.org/gitweb?p=VTK.git;a=commit;h=ba442dcd57fe6bf52ef7fb9c21cb842e78e489cd >>>>> >>>>> This commit added the typedefs CoordinateT, DimensionT, and SizeT to >>>>> vtkArray and its support classes. The wrappers do not support >>>>> typedefs yet, except for a few like vtkIdType that have been >>>>> hard-coded. You can try doing a checkout before the commit mentioned >>>>> above and see how things work. I didn't have much time to experiment >>>>> with these classes. >>>>> >>>>> David >>>>> >>>>> >>>>> On Mon, Sep 6, 2010 at 6:18 PM, Eric E. Monson wrote: >>>>>> Hello, >>>>>> >>>>>> I've been trying to see how much of the Titan text analysis functionality can be done from Python, but I ran into a problem accessing the contents of a vtkArrayExtents. The object is obtained by calling GetExtents() on a vtkArray, and if I print the array object I can see that the proper extents are there, but I can't figure out how to access them: the only methods on the vtkArrayExtents that seem to be wrapped are Append, Contains, SameShape and ZeroBased, and the object isn't iterable or scriptable. As I started trying out other things like vtkArrayRange and vtkArrayCoordinates, I also had trouble figuring out how to use them from Python. >>>>>> >>>>>> I know David Gobbi has made a lot of great progress on the Python wrapping over the summer, and I saw his wiki example for vtkVariant, but does anyone know if these supporting classes around vtkArray work from Python right now? >>>>>> >>>>>> Thanks a lot, >>>>>> -Eric >>>>>> >>>>>> ------------------------------------------------------ >>>>>> Eric E Monson >>>>>> Duke Visualization Technology Group >>>>>> >>>>>> >>>> >>>> >> >> From kmorel at sandia.gov Tue Sep 7 13:23:44 2010 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Tue, 7 Sep 2010 11:23:44 -0600 Subject: [vtk-developers] ReadOpenGLExtensions() should not call Render() In-Reply-To: Message-ID: I think we can all agree that having vtkOpenGLExtensionManager call Render is not a great idea. The problem is that there is a chicken-and-egg problem where vtkOpenGLExtensionManager needs the OpenGL context already created to accurately report the extensions supported, but you often want query available extensions early in initialization before rendering occurs. So, how should ReadOpenGLExtensions behave if the context has not yet been created? Perhaps vtkRenderWindow could expose a method that forces the context to be created. But does that actually solve the problem? Could this still cause problems if the user has not set up size, position, offscreen rendering, alpha channel, etc? What if the render window is later used with a QVTKWidget? Perhaps ReadOpenGLExtensions should just error out if the OpenGL context is not yet created. This might "break" a lot of existing code, but should we consider that code already broken? If this is the right solution, then vtkRenderWindow should probably still get a method that forces the context to created. That would allow users to initialize the parameters of the render window, create the OpenGL context, and then use vtkOpenGLExtensionManager to initialize the rest of the rendering. -Ken On 9/7/10 7:30 AM, "David Gobbi" wrote: Hi All, I have a little complaint about this code in vtkOpenGLExtensionManager::ReadOpenGLExtensions() this->RenderWindow->MakeCurrent(); if (!this->RenderWindow->IsCurrent()) { // Really should create a method in the render window to create // the graphics context instead of forcing a full render. this->RenderWindow->Render(); } Calling Render() inside ReadOpenGLExtensions() is a bad thing. It can cause the first render to occur as a side effect, and it might result in the window being rendered before it has been properly sized and positioned. From what I've seen, this Render always gets called on Windows but never on X. This render was also the cause of bug 11208 (http://www.vtk.org/Bug/view.php?id=11208) which took me the better part of a day to track down. 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://www.vtk.org/mailman/listinfo/vtk-developers **** Kenneth Moreland *** Sandia National Laboratories *********** *** *** *** email: kmorel at sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://www.cs.unm.edu/~kmorel -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Tue Sep 7 13:40:56 2010 From: clinton at elemtech.com (Clinton Stimpson) Date: Tue, 7 Sep 2010 11:40:56 -0600 Subject: [vtk-developers] ReadOpenGLExtensions() should not call Render() In-Reply-To: References: Message-ID: <201009071140.56500.clinton@elemtech.com> There is already a vtkRenderWindow::Start() which creates a context before rendering, so after that, one can query extensions. Clint On Tuesday, September 07, 2010 11:23:44 am Moreland, Kenneth wrote: > I think we can all agree that having vtkOpenGLExtensionManager call Render > is not a great idea. The problem is that there is a chicken-and-egg > problem where vtkOpenGLExtensionManager needs the OpenGL context already > created to accurately report the extensions supported, but you often want > query available extensions early in initialization before rendering > occurs. > > So, how should ReadOpenGLExtensions behave if the context has not yet been > created? Perhaps vtkRenderWindow could expose a method that forces the > context to be created. But does that actually solve the problem? Could > this still cause problems if the user has not set up size, position, > offscreen rendering, alpha channel, etc? What if the render window is > later used with a QVTKWidget? > > Perhaps ReadOpenGLExtensions should just error out if the OpenGL context is > not yet created. This might "break" a lot of existing code, but should we > consider that code already broken? If this is the right solution, then > vtkRenderWindow should probably still get a method that forces the context > to created. That would allow users to initialize the parameters of the > render window, create the OpenGL context, and then use > vtkOpenGLExtensionManager to initialize the rest of the rendering. > > -Ken > > > On 9/7/10 7:30 AM, "David Gobbi" wrote: > > Hi All, > > I have a little complaint about this code in > vtkOpenGLExtensionManager::ReadOpenGLExtensions() > > this->RenderWindow->MakeCurrent(); > if (!this->RenderWindow->IsCurrent()) > { > // Really should create a method in the render window to create > // the graphics context instead of forcing a full render. > this->RenderWindow->Render(); > } > > Calling Render() inside ReadOpenGLExtensions() is a bad thing. It can > cause the first render to occur as a side effect, and it might result > in the window being rendered before it has been properly sized and > positioned. From what I've seen, this Render always gets called on > Windows but never on X. This render was also the cause of bug 11208 > (http://www.vtk.org/Bug/view.php?id=11208) which took me the better > part of a day to track down. > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > > > > **** Kenneth Moreland > *** Sandia National Laboratories > *********** > *** *** *** email: kmorel at sandia.gov > ** *** ** phone: (505) 844-8919 > *** web: http://www.cs.unm.edu/~kmorel From david.gobbi at gmail.com Tue Sep 7 14:02:55 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 12:02:55 -0600 Subject: [vtk-developers] ReadOpenGLExtensions() should not call Render() In-Reply-To: <201009071140.56500.clinton@elemtech.com> References: <201009071140.56500.clinton@elemtech.com> Message-ID: Hi Clinton, On Windows, calling Start() will indirectly call CreateAWindow() so it doesn't avoid the window creation issue. Requiring that people call Start() before ReadOpenGLExtensions() introduces backwards incompatibility. I think that having ReadOpenGLExtensions() generate an error if the context hasn't been created is the correct solution, and like Kenneth says this means that the user will have to call a context-creation method like Start() before querying the extensions. I'm not fond of backwards incompatibility, but considering the wide range of circumstances under which windows can be created (different operating systems, different GUIs) I don't think there is any other option that could be considered to be a stable solution. David On Tue, Sep 7, 2010 at 11:40 AM, Clinton Stimpson wrote: > > There is already a vtkRenderWindow::Start() which creates a context before > rendering, so after that, one can query extensions. > > Clint > > On Tuesday, September 07, 2010 11:23:44 am Moreland, Kenneth wrote: >> I think we can all agree that having vtkOpenGLExtensionManager call Render >> is not a great idea. ?The problem is that there is a chicken-and-egg >> problem where vtkOpenGLExtensionManager needs the OpenGL context already >> created to accurately report the extensions supported, but you often want >> query available extensions early in initialization before rendering >> occurs. >> >> So, how should ReadOpenGLExtensions behave if the context has not yet been >> created? ?Perhaps vtkRenderWindow could expose a method that forces the >> context to be created. ?But does that actually solve the problem? ?Could >> this still cause problems if the user has not set up size, position, >> offscreen rendering, alpha channel, etc? ?What if the render window is >> later used with a QVTKWidget? >> >> Perhaps ReadOpenGLExtensions should just error out if the OpenGL context is >> not yet created. ?This might "break" a lot of existing code, but should we >> consider that code already broken? ?If this is the right solution, then >> vtkRenderWindow should probably still get a method that forces the context >> to created. ?That would allow users to initialize the parameters of the >> render window, create the OpenGL context, and then use >> vtkOpenGLExtensionManager to initialize the rest of the rendering. >> >> -Ken >> >> >> On 9/7/10 7:30 AM, "David Gobbi" wrote: >> >> Hi All, >> >> I have a little complaint about this code in >> vtkOpenGLExtensionManager::ReadOpenGLExtensions() >> >> ? ? this->RenderWindow->MakeCurrent(); >> ? ? if (!this->RenderWindow->IsCurrent()) >> ? ? ? { >> ? ? ? // Really should create a method in the render window to create >> ? ? ? // the graphics context instead of forcing a full render. >> ? ? ? this->RenderWindow->Render(); >> ? ? ? } >> >> Calling Render() inside ReadOpenGLExtensions() is a bad thing. ?It can >> cause the first render to occur as a side effect, and it might result >> in the window being rendered before it has been properly sized and >> positioned. ?From what I've seen, this Render always gets called on >> Windows but never on X. ?This render was also the cause of bug 11208 >> (http://www.vtk.org/Bug/view.php?id=11208) which took me the better >> part of a day to track down. >> >> ? 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://www.vtk.org/mailman/listinfo/vtk-developers >> >> >> >> >> >> ? ?**** ? ? ?Kenneth Moreland >> ? ? *** ? ? ?Sandia National Laboratories >> *********** >> *** *** *** ?email: kmorel at sandia.gov >> ** ?*** ?** ?phone: (505) 844-8919 >> ? ? *** ? ? ?web: ? http://www.cs.unm.edu/~kmorel > From david.gobbi at gmail.com Tue Sep 7 14:38:06 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 12:38:06 -0600 Subject: [vtk-developers] DASH1 and DASH11 dashboards Message-ID: Does anyone know anything about DASH1 and DASH11? These machines have been complaining that "vtkWrapTcl.exe is not found" for several days now. I have a vague feeling that they might be failing because of something that I've done. Is there someone who can check to see if vtkWrapTcl.exe is being built on these machines? Thanks in advance, David From dave.partyka at kitware.com Tue Sep 7 14:47:51 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Tue, 7 Sep 2010 14:47:51 -0400 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: Sure thing. On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi wrote: > Does anyone know anything about DASH1 and DASH11? These machines have > been complaining that "vtkWrapTcl.exe is not found" for several days > now. I have a vague feeling that they might be failing because of > something that I've done. Is there someone who can check to see if > vtkWrapTcl.exe is being built on these machines? > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.partyka at kitware.com Tue Sep 7 15:06:37 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Tue, 7 Sep 2010 15:06:37 -0400 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: That executable is in the bin tree. Actually I looked into this a little bit a week ago or so when I noticed it but was side tracked. In the top level CMakeLists.txt file of VTK I don't think GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes (.\). IF(CMAKE_CROSSCOMPILING) SET(VTK_WRAP_TCL_EXE vtkWrapTcl) SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) ELSE(CMAKE_CROSSCOMPILING) GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION) GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) ENDIF(CMAKE_CROSSCOMPILING) That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and vtkWrapPython.cmake could probably just use the target name (vtkWrapTcl, vtkWrapPython) and let CMake figure out the path on it's own instead of using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. # add custom command to output ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} ${KIT_HIERARCHY_FILE} MAIN_DEPENDENCY "${TMP_INPUT}" COMMAND ${VTK_WRAP_TCL_EXE} ARGS ${TMP_CONCRETE} ${TMP_HINTS} ${TMP_HIERARCHY} ${TMP_DEFINITIONS} ${TMP_INCLUDE} "${quote}${TMP_INPUT}${quote}" "${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" ${verbatim} ) I'll let you take it from there :-P On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka wrote: > Sure thing. > > > On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi wrote: > >> Does anyone know anything about DASH1 and DASH11? These machines have >> been complaining that "vtkWrapTcl.exe is not found" for several days >> now. I have a vague feeling that they might be failing because of >> something that I've done. Is there someone who can check to see if >> vtkWrapTcl.exe is being built on these machines? >> >> 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://www.vtk.org/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 7 15:16:37 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 13:16:37 -0600 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: Thanks. That confirms my suspicion that it is a CMake issue. I was hoping that those machines were just broken somehow. Sigh. David On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka wrote: > That executable is in the bin tree. Actually I looked into this a little bit > a week ago or so when I noticed it but was side tracked. > In the top level CMakeLists.txt file of VTK I don't think > GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes > (.\). > IF(CMAKE_CROSSCOMPILING) > ?? ?SET(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl) > ?? ?SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) > ??ELSE(CMAKE_CROSSCOMPILING) > ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl ? ? LOCATION) > ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) > ??ENDIF(CMAKE_CROSSCOMPILING) > That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and > vtkWrapPython.cmake could probably just use the target name (vtkWrapTcl, > vtkWrapPython) and let CMake figure out the path on it's own instead of > using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. > # add custom command to output > ?? ? ?ADD_CUSTOM_COMMAND( > ?? ? ? ?OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx > ?? ? ? ?DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} > ?? ? ? ?${KIT_HIERARCHY_FILE} > ?? ? ? ?MAIN_DEPENDENCY "${TMP_INPUT}" > ?? ? ? ?COMMAND ${VTK_WRAP_TCL_EXE} > ?? ? ? ?ARGS > ?? ? ? ?${TMP_CONCRETE} > ?? ? ? ?${TMP_HINTS} > ?? ? ? ?${TMP_HIERARCHY} > ?? ? ? ?${TMP_DEFINITIONS} > ?? ? ? ?${TMP_INCLUDE} > ?? ? ? ?"${quote}${TMP_INPUT}${quote}" > ?? ? ? ?"${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" > ?? ? ? ?COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" > ?? ? ? ?${verbatim} > ?? ? ? ?) > > I'll let you take it from there :-P > > On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka > wrote: >> >> Sure thing. >> >> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi wrote: >>> >>> Does anyone know anything about DASH1 and DASH11? ?These machines have >>> been complaining that "vtkWrapTcl.exe is not found" for several days >>> now. ?I have a vague feeling that they might be failing because of >>> something that I've done. ?Is there someone who can check to see if >>> vtkWrapTcl.exe is being built on these machines? >>> >>> 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://www.vtk.org/mailman/listinfo/vtk-developers >>> >> > > From tshead at sandia.gov Tue Sep 7 15:28:50 2010 From: tshead at sandia.gov (Timothy Shead) Date: Tue, 7 Sep 2010 13:28:50 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> Message-ID: <4C869272.5020201@sandia.gov> We've been running into limitations with integer sizes and vtkArray recently, and exploring alternatives. Those typedefs are there to keep things manageable, since trying to track-down and replace integer types across multiple vtkArray-related classes is extremely error prone. My preference would be: * Adding typedef support to the array wrappers, or * Waiting for the dust to settle before removing typedefs. Cheers, Tim -- Timothy M. Shead Sandia National Laboratories 1424, Data Analysis and Visualization From david.gobbi at gmail.com Tue Sep 7 15:38:15 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 7 Sep 2010 13:38:15 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <4C869272.5020201@sandia.gov> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> Message-ID: I'm fine with that. Wrapper typedef support is something that I had planned from the start, I just didn't expect that it would be needed so soon. What do you think of Eric's GetDimensionRange() method suggestion? I'd prefer that there are always named-method alternatives to [ ] operator methods. David On Tue, Sep 7, 2010 at 1:28 PM, Timothy Shead wrote: > We've been running into limitations with integer sizes and vtkArray > recently, and exploring alternatives. ?Those typedefs are there to keep > things manageable, since trying to track-down and replace integer types > across multiple vtkArray-related classes is extremely error prone. ?My > preference would be: > > * Adding typedef support to the array wrappers, or > * Waiting for the dust to settle before removing typedefs. > > Cheers, > Tim > > -- > Timothy M. Shead > Sandia National Laboratories > 1424, Data Analysis and Visualization > > From tshead at sandia.gov Tue Sep 7 19:02:55 2010 From: tshead at sandia.gov (Timothy Shead) Date: Tue, 7 Sep 2010 17:02:55 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> Message-ID: <4C86C49F.9020502@sandia.gov> On 9/7/10 1:38 PM, David Gobbi wrote: > I'm fine with that. Wrapper typedef support is something that I had > planned from the start, I just didn't expect that it would be needed > so soon. What do you think of Eric's GetDimensionRange() method > suggestion? I'd prefer that there are always named-method > alternatives to [ ] operator methods. Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. Cheers, Tim -- Timothy M. Shead Sandia National Laboratories 1424, Data Analysis and Visualization From emonson at cs.duke.edu Tue Sep 7 21:47:06 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 7 Sep 2010 21:47:06 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <4C86C49F.9020502@sandia.gov> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> <4C86C49F.9020502@sandia.gov> Message-ID: <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> On Sep 7, 2010, at 7:02 PM, Timothy Shead wrote: > On 9/7/10 1:38 PM, David Gobbi wrote: >> I'm fine with that. Wrapper typedef support is something that I had >> planned from the start, I just didn't expect that it would be needed >> so soon. What do you think of Eric's GetDimensionRange() method >> suggestion? I'd prefer that there are always named-method >> alternatives to [ ] operator methods. > > Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. Ah, thank you -- I hadn't seen the vtkArray::GetExtent() option. I can get the values from that for now. -Eric From david.gobbi at gmail.com Wed Sep 8 08:40:42 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 8 Sep 2010 06:40:42 -0600 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: Hi Dave, I tried your suggestion of using the executable target name in ADD_CUSTOM_COMMAND instead of using the full path to the executable. It worked nicely, so I added the following code to CMakeLists.txt to get DASH1 and DASH11 running again: # The LOCATION doesn't seem to work on Visual Studio 7 IF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") SET(VTK_WRAP_TCL_EXE vtkWrapTcl) SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION) GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") This works as a quick fix. The proper fix would be to use just "vtkWrapTcl" when vtkWrapTcl.cmake is called from VTK, but to use the full path when vtkWrapTcl.cmake is called from external packages. This "proper fix" would be easy except for this nasty piece of code in CMakeLists.txt: # Save these in cache as other projects including VTK (such as ParaView) may # want to use these. SET(VTK_WRAP_PYTHON_EXE "${VTK_WRAP_PYTHON_EXE}" CACHE INTERNAL "Location of program to do Python wrapping") SET(VTK_WRAP_PYTHON_INIT_EXE "${VTK_WRAP_PYTHON_INIT_EXE}" CACHE INTERNAL "Location of program to do Python wrapping") Hopefully this is legacy code. David On Tue, Sep 7, 2010 at 1:16 PM, David Gobbi wrote: > Thanks. ?That confirms my suspicion that it is a CMake issue. ?I was > hoping that those machines were just broken somehow. ?Sigh. > > ?David > > > On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka wrote: >> That executable is in the bin tree. Actually I looked into this a little bit >> a week ago or so when I noticed it but was side tracked. >> In the top level CMakeLists.txt file of VTK I don't think >> GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes >> (.\). >> IF(CMAKE_CROSSCOMPILING) >> ?? ?SET(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl) >> ?? ?SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) >> ??ELSE(CMAKE_CROSSCOMPILING) >> ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl ? ? LOCATION) >> ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) >> ??ENDIF(CMAKE_CROSSCOMPILING) >> That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and >> vtkWrapPython.cmake could probably just use the target name (vtkWrapTcl, >> vtkWrapPython) and let CMake figure out the path on it's own instead of >> using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. >> # add custom command to output >> ?? ? ?ADD_CUSTOM_COMMAND( >> ?? ? ? ?OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx >> ?? ? ? ?DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} >> ?? ? ? ?${KIT_HIERARCHY_FILE} >> ?? ? ? ?MAIN_DEPENDENCY "${TMP_INPUT}" >> ?? ? ? ?COMMAND ${VTK_WRAP_TCL_EXE} >> ?? ? ? ?ARGS >> ?? ? ? ?${TMP_CONCRETE} >> ?? ? ? ?${TMP_HINTS} >> ?? ? ? ?${TMP_HIERARCHY} >> ?? ? ? ?${TMP_DEFINITIONS} >> ?? ? ? ?${TMP_INCLUDE} >> ?? ? ? ?"${quote}${TMP_INPUT}${quote}" >> ?? ? ? ?"${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" >> ?? ? ? ?COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" >> ?? ? ? ?${verbatim} >> ?? ? ? ?) >> >> I'll let you take it from there :-P >> >> On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka >> wrote: >>> >>> Sure thing. >>> >>> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi wrote: >>>> >>>> Does anyone know anything about DASH1 and DASH11? ?These machines have >>>> been complaining that "vtkWrapTcl.exe is not found" for several days >>>> now. ?I have a vague feeling that they might be failing because of >>>> something that I've done. ?Is there someone who can check to see if >>>> vtkWrapTcl.exe is being built on these machines? >>>> >>>> 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://www.vtk.org/mailman/listinfo/vtk-developers >>>> >>> >> >> > From david.cole at kitware.com Wed Sep 8 09:46:24 2010 From: david.cole at kitware.com (David Cole) Date: Wed, 8 Sep 2010 09:46:24 -0400 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: get_target_property(... LOCATION) has never worked 100% reliably across all platforms... Its use should be eliminated. For add_custom_command use within a VTK CMakeLists.txt file, please use simply the name of the cmake target, not a reference to the executable file. Thanks, David Cole On Wed, Sep 8, 2010 at 8:40 AM, David Gobbi wrote: > Hi Dave, > > I tried your suggestion of using the executable target name in > ADD_CUSTOM_COMMAND instead of using the full path to the executable. > It worked nicely, so I added the following code to CMakeLists.txt to > get DASH1 and DASH11 running again: > > # The LOCATION doesn't seem to work on Visual Studio 7 > IF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") > SET(VTK_WRAP_TCL_EXE vtkWrapTcl) > SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) > ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") > GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION) > GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) > ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") > > This works as a quick fix. The proper fix would be to use just > "vtkWrapTcl" when vtkWrapTcl.cmake is called from VTK, but to use the > full path when vtkWrapTcl.cmake is called from external packages. > This "proper fix" would be easy except for this nasty piece of code in > CMakeLists.txt: > > # Save these in cache as other projects including VTK (such as ParaView) > may > # want to use these. > SET(VTK_WRAP_PYTHON_EXE > "${VTK_WRAP_PYTHON_EXE}" > CACHE INTERNAL "Location of program to do Python wrapping") > SET(VTK_WRAP_PYTHON_INIT_EXE > "${VTK_WRAP_PYTHON_INIT_EXE}" > CACHE INTERNAL "Location of program to do Python wrapping") > > Hopefully this is legacy code. > > David > > > > > On Tue, Sep 7, 2010 at 1:16 PM, David Gobbi wrote: > > Thanks. That confirms my suspicion that it is a CMake issue. I was > > hoping that those machines were just broken somehow. Sigh. > > > > David > > > > > > On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka > wrote: > >> That executable is in the bin tree. Actually I looked into this a little > bit > >> a week ago or so when I noticed it but was side tracked. > >> In the top level CMakeLists.txt file of VTK I don't think > >> GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes > >> (.\). > >> IF(CMAKE_CROSSCOMPILING) > >> SET(VTK_WRAP_TCL_EXE vtkWrapTcl) > >> SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) > >> ELSE(CMAKE_CROSSCOMPILING) > >> GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION) > >> GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) > >> ENDIF(CMAKE_CROSSCOMPILING) > >> That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and > >> vtkWrapPython.cmake could probably just use the target name (vtkWrapTcl, > >> vtkWrapPython) and let CMake figure out the path on it's own instead of > >> using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. > >> # add custom command to output > >> ADD_CUSTOM_COMMAND( > >> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx > >> DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} > >> ${KIT_HIERARCHY_FILE} > >> MAIN_DEPENDENCY "${TMP_INPUT}" > >> COMMAND ${VTK_WRAP_TCL_EXE} > >> ARGS > >> ${TMP_CONCRETE} > >> ${TMP_HINTS} > >> ${TMP_HIERARCHY} > >> ${TMP_DEFINITIONS} > >> ${TMP_INCLUDE} > >> "${quote}${TMP_INPUT}${quote}" > >> > "${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" > >> COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" > >> ${verbatim} > >> ) > >> > >> I'll let you take it from there :-P > >> > >> On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka > >> wrote: > >>> > >>> Sure thing. > >>> > >>> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi > wrote: > >>>> > >>>> Does anyone know anything about DASH1 and DASH11? These machines have > >>>> been complaining that "vtkWrapTcl.exe is not found" for several days > >>>> now. I have a vague feeling that they might be failing because of > >>>> something that I've done. Is there someone who can check to see if > >>>> vtkWrapTcl.exe is being built on these machines? > >>>> > >>>> 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 8 10:34:06 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 8 Sep 2010 08:34:06 -0600 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: Hi David (Cole): I'll make sure the wrappers do this. But is there a reliable way for me to get the full path so that I can store it in VTKConfig.cmake? David On Wed, Sep 8, 2010 at 7:46 AM, David Cole wrote: > get_target_property(... LOCATION) has never worked 100% reliably across all > platforms... Its use should be eliminated. > For add_custom_command use within a VTK CMakeLists.txt file, please use > simply the name of the cmake target, not a reference to the executable file. > Thanks, > David Cole > > On Wed, Sep 8, 2010 at 8:40 AM, David Gobbi wrote: >> >> Hi Dave, >> >> I tried your suggestion of using the executable target name in >> ADD_CUSTOM_COMMAND instead of using the full path to the executable. >> It worked nicely, so I added the following code to CMakeLists.txt to >> get DASH1 and DASH11 running again: >> >> ? ?# The LOCATION doesn't seem to work on Visual Studio 7 >> ? ?IF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") >> ? ? ?SET(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl) >> ? ? ?SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) >> ? ?ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") >> ? ? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl ? ? LOCATION) >> ? ? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) >> ? ?ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") >> >> This works as a quick fix. ?The proper fix would be to use just >> "vtkWrapTcl" when vtkWrapTcl.cmake is called from VTK, but to use the >> full path when vtkWrapTcl.cmake is called from external packages. >> This "proper fix" would be easy except for this nasty piece of code in >> CMakeLists.txt: >> >> ?# Save these in cache as other projects including VTK (such as ParaView) >> may >> ?# want to use these. >> ?SET(VTK_WRAP_PYTHON_EXE >> ? ?"${VTK_WRAP_PYTHON_EXE}" >> ? ?CACHE INTERNAL "Location of program to do Python wrapping") >> ?SET(VTK_WRAP_PYTHON_INIT_EXE >> ? ?"${VTK_WRAP_PYTHON_INIT_EXE}" >> ? ?CACHE INTERNAL "Location of program to do Python wrapping") >> >> Hopefully this is legacy code. >> >> ? David >> >> >> >> >> On Tue, Sep 7, 2010 at 1:16 PM, David Gobbi wrote: >> > Thanks. ?That confirms my suspicion that it is a CMake issue. ?I was >> > hoping that those machines were just broken somehow. ?Sigh. >> > >> > ?David >> > >> > >> > On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka >> > wrote: >> >> That executable is in the bin tree. Actually I looked into this a >> >> little bit >> >> a week ago or so when I noticed it but was side tracked. >> >> In the top level CMakeLists.txt file of VTK I don't think >> >> GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes >> >> (.\). >> >> IF(CMAKE_CROSSCOMPILING) >> >> ?? ?SET(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl) >> >> ?? ?SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) >> >> ??ELSE(CMAKE_CROSSCOMPILING) >> >> ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl ? ? LOCATION) >> >> ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) >> >> ??ENDIF(CMAKE_CROSSCOMPILING) >> >> That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and >> >> vtkWrapPython.cmake could probably just use the target name >> >> (vtkWrapTcl, >> >> vtkWrapPython) and let CMake figure out the path on it's own instead of >> >> using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. >> >> # add custom command to output >> >> ?? ? ?ADD_CUSTOM_COMMAND( >> >> ?? ? ? ?OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx >> >> ?? ? ? ?DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} >> >> ?? ? ? ?${KIT_HIERARCHY_FILE} >> >> ?? ? ? ?MAIN_DEPENDENCY "${TMP_INPUT}" >> >> ?? ? ? ?COMMAND ${VTK_WRAP_TCL_EXE} >> >> ?? ? ? ?ARGS >> >> ?? ? ? ?${TMP_CONCRETE} >> >> ?? ? ? ?${TMP_HINTS} >> >> ?? ? ? ?${TMP_HIERARCHY} >> >> ?? ? ? ?${TMP_DEFINITIONS} >> >> ?? ? ? ?${TMP_INCLUDE} >> >> ?? ? ? ?"${quote}${TMP_INPUT}${quote}" >> >> >> >> ?"${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" >> >> ?? ? ? ?COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" >> >> ?? ? ? ?${verbatim} >> >> ?? ? ? ?) >> >> >> >> I'll let you take it from there :-P >> >> >> >> On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka >> >> wrote: >> >>> >> >>> Sure thing. >> >>> >> >>> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi >> >>> wrote: >> >>>> >> >>>> Does anyone know anything about DASH1 and DASH11? ?These machines >> >>>> have >> >>>> been complaining that "vtkWrapTcl.exe is not found" for several days >> >>>> now. ?I have a vague feeling that they might be failing because of >> >>>> something that I've done. ?Is there someone who can check to see if >> >>>> vtkWrapTcl.exe is being built on these machines? >> >>>> >> >>>> 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers >> > > From haehn at bwh.harvard.edu Wed Sep 8 13:42:16 2010 From: haehn at bwh.harvard.edu (Daniel Haehn) Date: Wed, 8 Sep 2010 13:42:16 -0400 Subject: [vtk-developers] Coordinate conversions (World-Display) Message-ID: <564BD474-1FC0-427D-A0F9-1A757C9973AD@bwh.harvard.edu> Hi VTK experts, I use the following functions to convert between World and Display coordinates and vice versa. I found the method on the mailing list or in some other code. Isn't there an easier way to do that? Is it correct at all and is it robust? this->GetRenderer is a vtkRenderer. //--------------------------------------------------------------------------- /// Convert display to world coordinates double* vtkMRMLAnnotationThreeDViewDisplayableManager::GetDisplayToWorldCoordinates(double x, double y) { double coordinates[3]; coordinates[0]=(double)x; coordinates[1]=(double)y; coordinates[2]=0; this->GetRenderer()->SetDisplayPoint(coordinates); this->GetRenderer()->DisplayToView(); this->GetRenderer()->GetViewPoint(coordinates); this->GetRenderer()->ViewToWorld(); return this->GetRenderer()->GetWorldPoint(); } //--------------------------------------------------------------------------- /// Convert world to display coordinates double* vtkMRMLAnnotationThreeDViewDisplayableManager::GetWorldToDisplayCoordinates(double * worldPoints) { vtkDebugMacro("GetWorldToDisplayCoordinates: RAS " << worldPoints[0] << ", " << worldPoints[1] << ", " << worldPoints[2]) double * displayCoordinates; this->GetRenderer()->SetWorldPoint(worldPoints); this->GetRenderer()->WorldToView(); displayCoordinates = this->GetRenderer()->GetViewPoint(); this->GetRenderer()->ViewToDisplay(); double * output = this->GetRenderer()->GetDisplayPoint(); vtkDebugMacro("GetWorldToDisplayCoordinates: Display " << output[0] << ", " << output[1]) return output; } Thank you, Daniel From pppebay at sandia.gov Wed Sep 8 16:38:03 2010 From: pppebay at sandia.gov (Pebay, Philippe P) Date: Wed, 8 Sep 2010 14:38:03 -0600 Subject: [vtk-developers] MSC VER <= 1200 Message-ID: <687C3C69C44FBD4893CCAC45A593E2B819B33B099A@ES02SNLNT.srn.sandia.gov> Hello, I still have the #if defined(_MSC_VER) && (_MSC_VER <= 1200) compiler directives in some parallel statistics classes (because of older STL syntax). Are we still supporting this compiler version, or can I get rid of this? Thanks P -- Philippe P?bay Sandia National Laboratories From dave.partyka at kitware.com Wed Sep 8 16:44:11 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Wed, 8 Sep 2010 16:44:11 -0400 Subject: [vtk-developers] MSC VER <= 1200 In-Reply-To: <687C3C69C44FBD4893CCAC45A593E2B819B33B099A@ES02SNLNT.srn.sandia.gov> References: <687C3C69C44FBD4893CCAC45A593E2B819B33B099A@ES02SNLNT.srn.sandia.gov> Message-ID: Officially we no longer support VS6. On Wed, Sep 8, 2010 at 4:38 PM, Pebay, Philippe P wrote: > Hello, > > I still have the > #if defined(_MSC_VER) && (_MSC_VER <= 1200) > compiler directives in some parallel statistics classes (because of older > STL syntax). > > Are we still supporting this compiler version, or can I get rid of this? > > Thanks > P > > > -- > Philippe P?bay > Sandia National Laboratories > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pppebay at sandia.gov Wed Sep 8 16:46:38 2010 From: pppebay at sandia.gov (Pebay, Philippe P) Date: Wed, 8 Sep 2010 14:46:38 -0600 Subject: [vtk-developers] MSC VER <= 1200 In-Reply-To: References: <687C3C69C44FBD4893CCAC45A593E2B819B33B099A@ES02SNLNT.srn.sandia.gov>, Message-ID: <687C3C69C44FBD4893CCAC45A593E2B819B33B099B@ES02SNLNT.srn.sandia.gov> Thank you. I am therefore going to remove all of these #if defined ... #else... #endif which clutter the parallel stats code. P -- Philippe P?bay Sandia National Laboratories ________________________________________ From: Dave Partyka [dave.partyka at kitware.com] Sent: Wednesday, September 08, 2010 1:44 PM To: Pebay, Philippe P Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] MSC VER <= 1200 Officially we no longer support VS6. On Wed, Sep 8, 2010 at 4:38 PM, Pebay, Philippe P > wrote: Hello, I still have the #if defined(_MSC_VER) && (_MSC_VER <= 1200) compiler directives in some parallel statistics classes (because of older STL syntax). Are we still supporting this compiler version, or can I get rid of this? Thanks P -- Philippe P?bay Sandia National Laboratories _______________________________________________ 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://www.vtk.org/mailman/listinfo/vtk-developers From sean at rogue-research.com Wed Sep 8 16:56:00 2010 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Sep 2010 16:56:00 -0400 Subject: [vtk-developers] vtkNetCDF upgraded to 4.1.1 In-Reply-To: References: Message-ID: <20100908205600.1946984227@mail.rogue-research.com> On Tue, 17 Aug 2010 15:11:12 -0400, Dave Partyka said: >I just upaded VTK's netcdf from 3.6.2 to 4.1.1. In addition to the >traditional C library I have also brought in the C++ version of the library >(vtkNetCDF_cpp). I spent time creating the proper DLL exports, allowing even >Windows developers to use the library! This provides a nicer API that >developers can use when writing new netcdf readers/writers. Also with netcdf >4.x we can now potentially use HDF5 based NetCDF files. See here for the >release notes for NetCDF 4. As always we value feedback from the community, >feel free to report any issues. In the mean time I will be monitoring the >dashboards. Dave, I believe there is some mangling missing after your change. I just pulled VTK from git and my app, which links to both NetCDF and VTK, no longer links. Error is: ld: duplicate symbol _nc_inq_type in /path1/libnetcdf.a(nc.o) and /path2/ libvtkNetCDF.a(nc.c.o) If I do the following: nm libvtkNetCDF.a | grep " [TRD] " It lists several symbols that aren't prefixed by vtk_netcdf, namely: 0000000000003083 T _nc_inq_type 0000000000000043 T _nextUTF8 00000000000008ae T _nulldup 00000000000018ae T _utf8proc_NFC 0000000000001860 T _utf8proc_NFD 000000000000194a T _utf8proc_NFKC 00000000000018fc T _utf8proc_NFKD 0000000000001998 T _utf8proc_check 0000000000000343 T _utf8proc_codepoint_valid 0000000000000fd1 T _utf8proc_decompose 00000000000005d9 T _utf8proc_decompose_char 00000000000003c6 T _utf8proc_encode_char 0000000000000000 T _utf8proc_errmsg 000000000000054b T _utf8proc_get_property 00000000000000cf T _utf8proc_iterate 000000000000172b T _utf8proc_map 000000000000126a T _utf8proc_reencode nc_inq_type certainly should be in vtk_netcdf_mangle.h, not sure why/how you missed it. My experience with updating VTK's freetype is that one must regenerate the symbol list on all the major platforms and merge the results. Some symbols seem to only be exported on some OSes, see my comments in vtk_freetype_mangle.h. Not sure about the other symbols. "utf8proc" looks like 3rd party code used by NetCDF itself. I wonder if these symbols should not be exported at all, I'm guessing they are not part of NetCDF's public API. 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.partyka at kitware.com Wed Sep 8 17:00:51 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Wed, 8 Sep 2010 17:00:51 -0400 Subject: [vtk-developers] vtkNetCDF upgraded to 4.1.1 In-Reply-To: <20100908205600.1946984227@mail.rogue-research.com> References: <20100908205600.1946984227@mail.rogue-research.com> Message-ID: Thanks Sean, I'll take a look. On Wed, Sep 8, 2010 at 4:56 PM, Sean McBride wrote: > On Tue, 17 Aug 2010 15:11:12 -0400, Dave Partyka said: > > >I just upaded VTK's netcdf from 3.6.2 to 4.1.1. In addition to the > >traditional C library I have also brought in the C++ version of the > library > >(vtkNetCDF_cpp). I spent time creating the proper DLL exports, allowing > even > >Windows developers to use the library! This provides a nicer API that > >developers can use when writing new netcdf readers/writers. Also with > netcdf > >4.x we can now potentially use HDF5 based NetCDF files. See here for the > >release notes for NetCDF 4. As always we value feedback from the > community, > >feel free to report any issues. In the mean time I will be monitoring the > >dashboards. > > Dave, > > I believe there is some mangling missing after your change. I just > pulled VTK from git and my app, which links to both NetCDF and VTK, no > longer links. Error is: > > ld: duplicate symbol _nc_inq_type in /path1/libnetcdf.a(nc.o) and /path2/ > libvtkNetCDF.a(nc.c.o) > > If I do the following: > > nm libvtkNetCDF.a | grep " [TRD] " > > It lists several symbols that aren't prefixed by vtk_netcdf, namely: > > 0000000000003083 T _nc_inq_type > 0000000000000043 T _nextUTF8 > 00000000000008ae T _nulldup > 00000000000018ae T _utf8proc_NFC > 0000000000001860 T _utf8proc_NFD > 000000000000194a T _utf8proc_NFKC > 00000000000018fc T _utf8proc_NFKD > 0000000000001998 T _utf8proc_check > 0000000000000343 T _utf8proc_codepoint_valid > 0000000000000fd1 T _utf8proc_decompose > 00000000000005d9 T _utf8proc_decompose_char > 00000000000003c6 T _utf8proc_encode_char > 0000000000000000 T _utf8proc_errmsg > 000000000000054b T _utf8proc_get_property > 00000000000000cf T _utf8proc_iterate > 000000000000172b T _utf8proc_map > 000000000000126a T _utf8proc_reencode > > nc_inq_type certainly should be in vtk_netcdf_mangle.h, not sure why/how > you missed it. My experience with updating VTK's freetype is that one > must regenerate the symbol list on all the major platforms and merge the > results. Some symbols seem to only be exported on some OSes, see my > comments in vtk_freetype_mangle.h. > > Not sure about the other symbols. "utf8proc" looks like 3rd party code > used by NetCDF itself. I wonder if these symbols should not be exported > at all, I'm guessing they are not part of NetCDF's public API. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Sep 8 17:30:09 2010 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Sep 2010 17:30:09 -0400 Subject: [vtk-developers] vtkNetCDF upgraded to 4.1.1 In-Reply-To: References: <20100908205600.1946984227@mail.rogue-research.com> Message-ID: <20100908213009.1865467441@mail.rogue-research.com> Dave, FYI, if I add: #define nc_inq_type vtk_netcdf_nc_inq_type #define nextUTF8 vtk_netcdf_nextUTF8 #define nulldup vtk_netcdf_nulldup my app then links. If I further add the utf8proc ones, VTK itself fails to link when rebuilt. On Wed, 8 Sep 2010 17:00:51 -0400, Dave Partyka said: >Thanks Sean, I'll take a look. > >On Wed, Sep 8, 2010 at 4:56 PM, Sean McBride wrote: > >> On Tue, 17 Aug 2010 15:11:12 -0400, Dave Partyka said: >> >> >I just upaded VTK's netcdf from 3.6.2 to 4.1.1. In addition to the >> >traditional C library I have also brought in the C++ version of the >> library >> >(vtkNetCDF_cpp). I spent time creating the proper DLL exports, allowing >> even >> >Windows developers to use the library! This provides a nicer API that >> >developers can use when writing new netcdf readers/writers. Also with >> netcdf >> >4.x we can now potentially use HDF5 based NetCDF files. See here for the >> >release notes for NetCDF 4. As always we value feedback from the >> community, >> >feel free to report any issues. In the mean time I will be monitoring the >> >dashboards. >> >> Dave, >> >> I believe there is some mangling missing after your change. I just >> pulled VTK from git and my app, which links to both NetCDF and VTK, no >> longer links. Error is: >> >> ld: duplicate symbol _nc_inq_type in /path1/libnetcdf.a(nc.o) and /path2/ >> libvtkNetCDF.a(nc.c.o) >> >> If I do the following: >> >> nm libvtkNetCDF.a | grep " [TRD] " >> >> It lists several symbols that aren't prefixed by vtk_netcdf, namely: >> >> 0000000000003083 T _nc_inq_type >> 0000000000000043 T _nextUTF8 >> 00000000000008ae T _nulldup >> 00000000000018ae T _utf8proc_NFC >> 0000000000001860 T _utf8proc_NFD >> 000000000000194a T _utf8proc_NFKC >> 00000000000018fc T _utf8proc_NFKD >> 0000000000001998 T _utf8proc_check >> 0000000000000343 T _utf8proc_codepoint_valid >> 0000000000000fd1 T _utf8proc_decompose >> 00000000000005d9 T _utf8proc_decompose_char >> 00000000000003c6 T _utf8proc_encode_char >> 0000000000000000 T _utf8proc_errmsg >> 000000000000054b T _utf8proc_get_property >> 00000000000000cf T _utf8proc_iterate >> 000000000000172b T _utf8proc_map >> 000000000000126a T _utf8proc_reencode >> >> nc_inq_type certainly should be in vtk_netcdf_mangle.h, not sure why/how >> you missed it. My experience with updating VTK's freetype is that one >> must regenerate the symbol list on all the major platforms and merge the >> results. Some symbols seem to only be exported on some OSes, see my >> comments in vtk_freetype_mangle.h. >> >> Not sure about the other symbols. "utf8proc" looks like 3rd party code >> used by NetCDF itself. I wonder if these symbols should not be exported >> at all, I'm guessing they are not part of NetCDF's public API. From dave.partyka at kitware.com Wed Sep 8 18:50:13 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Wed, 8 Sep 2010 18:50:13 -0400 Subject: [vtk-developers] vtkNetCDF upgraded to 4.1.1 In-Reply-To: <20100908213009.1865467441@mail.rogue-research.com> References: <20100908205600.1946984227@mail.rogue-research.com> <20100908213009.1865467441@mail.rogue-research.com> Message-ID: I have added them. Thanks On Wed, Sep 8, 2010 at 5:30 PM, Sean McBride wrote: > Dave, > > FYI, if I add: > > #define nc_inq_type vtk_netcdf_nc_inq_type > #define nextUTF8 vtk_netcdf_nextUTF8 > #define nulldup vtk_netcdf_nulldup > > my app then links. If I further add the utf8proc ones, VTK itself fails > to link when rebuilt. > > > > On Wed, 8 Sep 2010 17:00:51 -0400, Dave Partyka said: > > >Thanks Sean, I'll take a look. > > > >On Wed, Sep 8, 2010 at 4:56 PM, Sean McBride >wrote: > > > >> On Tue, 17 Aug 2010 15:11:12 -0400, Dave Partyka said: > >> > >> >I just upaded VTK's netcdf from 3.6.2 to 4.1.1. In addition to the > >> >traditional C library I have also brought in the C++ version of the > >> library > >> >(vtkNetCDF_cpp). I spent time creating the proper DLL exports, allowing > >> even > >> >Windows developers to use the library! This provides a nicer API that > >> >developers can use when writing new netcdf readers/writers. Also with > >> netcdf > >> >4.x we can now potentially use HDF5 based NetCDF files. See here for > the > >> >release notes for NetCDF 4. As always we value feedback from the > >> community, > >> >feel free to report any issues. In the mean time I will be monitoring > the > >> >dashboards. > >> > >> Dave, > >> > >> I believe there is some mangling missing after your change. I just > >> pulled VTK from git and my app, which links to both NetCDF and VTK, no > >> longer links. Error is: > >> > >> ld: duplicate symbol _nc_inq_type in /path1/libnetcdf.a(nc.o) and > /path2/ > >> libvtkNetCDF.a(nc.c.o) > >> > >> If I do the following: > >> > >> nm libvtkNetCDF.a | grep " [TRD] " > >> > >> It lists several symbols that aren't prefixed by vtk_netcdf, namely: > >> > >> 0000000000003083 T _nc_inq_type > >> 0000000000000043 T _nextUTF8 > >> 00000000000008ae T _nulldup > >> 00000000000018ae T _utf8proc_NFC > >> 0000000000001860 T _utf8proc_NFD > >> 000000000000194a T _utf8proc_NFKC > >> 00000000000018fc T _utf8proc_NFKD > >> 0000000000001998 T _utf8proc_check > >> 0000000000000343 T _utf8proc_codepoint_valid > >> 0000000000000fd1 T _utf8proc_decompose > >> 00000000000005d9 T _utf8proc_decompose_char > >> 00000000000003c6 T _utf8proc_encode_char > >> 0000000000000000 T _utf8proc_errmsg > >> 000000000000054b T _utf8proc_get_property > >> 00000000000000cf T _utf8proc_iterate > >> 000000000000172b T _utf8proc_map > >> 000000000000126a T _utf8proc_reencode > >> > >> nc_inq_type certainly should be in vtk_netcdf_mangle.h, not sure why/how > >> you missed it. My experience with updating VTK's freetype is that one > >> must regenerate the symbol list on all the major platforms and merge the > >> results. Some symbols seem to only be exported on some OSes, see my > >> comments in vtk_freetype_mangle.h. > >> > >> Not sure about the other symbols. "utf8proc" looks like 3rd party code > >> used by NetCDF itself. I wonder if these symbols should not be exported > >> at all, I'm guessing they are not part of NetCDF's public API. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.marion at kitware.com Wed Sep 8 18:44:31 2010 From: pat.marion at kitware.com (pat marion) Date: Wed, 8 Sep 2010 18:44:31 -0400 Subject: [vtk-developers] [vtkusers] Coordinate conversions (World-Display) In-Reply-To: <564BD474-1FC0-427D-A0F9-1A757C9973AD@bwh.harvard.edu> References: <564BD474-1FC0-427D-A0F9-1A757C9973AD@bwh.harvard.edu> Message-ID: Sadly, yes, this is the way to do it. If you want, there is a class that offers static convenience methods: static void vtkInteractorObserver::ComputeDisplayToWorld (vtkRenderer *ren, double x, double y, double z, double worldPt[4]) static void vtkInteractorObserver::ComputeWorldToDisplay (vtkRenderer *ren, double x, double y, double z, double displayPt[3]) But if you look at the implementation... void vtkInteractorObserver::ComputeWorldToDisplay(vtkRenderer *ren, double x, double y, double z, double displayPt[3]) { ren->SetWorldPoint(x, y, z, 1.0); ren->WorldToDisplay(); ren->GetDisplayPoint(displayPt); } One comment about your code... I'd be careful returning a double* like that. You don't own that memory, it could change at any time. Pat On Wed, Sep 8, 2010 at 1:42 PM, Daniel Haehn wrote: > Hi VTK experts, > > I use the following functions to convert between World and Display > coordinates and vice versa. I found the method on the mailing list or in > some other code. > > Isn't there an easier way to do that? Is it correct at all and is it > robust? > > this->GetRenderer is a vtkRenderer. > > > //--------------------------------------------------------------------------- > /// Convert display to world coordinates > double* > vtkMRMLAnnotationThreeDViewDisplayableManager::GetDisplayToWorldCoordinates(double > x, double y) > { > double coordinates[3]; > coordinates[0]=(double)x; > coordinates[1]=(double)y; > coordinates[2]=0; > > this->GetRenderer()->SetDisplayPoint(coordinates); > this->GetRenderer()->DisplayToView(); > this->GetRenderer()->GetViewPoint(coordinates); > this->GetRenderer()->ViewToWorld(); > return this->GetRenderer()->GetWorldPoint(); > > } > > > //--------------------------------------------------------------------------- > /// Convert world to display coordinates > double* > vtkMRMLAnnotationThreeDViewDisplayableManager::GetWorldToDisplayCoordinates(double > * worldPoints) > { > > vtkDebugMacro("GetWorldToDisplayCoordinates: RAS " << worldPoints[0] << ", > " << worldPoints[1] << ", " << worldPoints[2]) > > double * displayCoordinates; > > this->GetRenderer()->SetWorldPoint(worldPoints); > this->GetRenderer()->WorldToView(); > displayCoordinates = this->GetRenderer()->GetViewPoint(); > this->GetRenderer()->ViewToDisplay(); > > double * output = this->GetRenderer()->GetDisplayPoint(); > > vtkDebugMacro("GetWorldToDisplayCoordinates: Display " << output[0] << ", > " << output[1]) > > return output; > > } > > Thank you, > Daniel > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtkusers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thuluyang at gmail.com Thu Sep 9 02:52:42 2010 From: thuluyang at gmail.com (=?GB2312?B?wr3R9A==?=) Date: Thu, 9 Sep 2010 14:52:42 +0800 Subject: [vtk-developers] help Message-ID: hello,sorry to interupt you . but i have a really important question.i am asking you for help. i am a new learner of vtk. recently,i am using vtk to do 3d reconstruction. i am using mip(maximum intenstity projection ) to do this. first reading some silces of ct dicom image,then do the projection. as you know vtk is using pipeline ,we can only get 3d volume. but what i want is the 2d image by MIP. i dont know if i make myself understood by you? my english is poor. here is the main code: //read the dicoms vtkDICOMImageReader *volumeReader = vtkDICOMImageReader::New(); volumeReader->SetDirectoryName("C:/mrdata"); vtkImageShiftScale *scale=vtkImageShiftScale::New(); scale->SetInput(volumeReader->GetOutput()); scale->SetOutputScalarTypeToUnsignedChar(); scale->Update(); vtkVolumeRayCastMIPFunction *MIP = vtkVolumeRayCastMIPFunction::New(); vtkVolumeRayCastMapper *RaycastMapper = vtkVolumeRayCastMapper::New(); RaycastMapper->SetVolumeRayCastFunction(MIP); RaycastMapper->SetInput(scale->GetOutput()); here is the case, where i can get the 2d image i want? i couldnot find any interface.but i think the image should be the output of RaycastMapper? the pity is i cant find any output of RaycastMapper. could you give me some suggestions? -- ?? ?????????????? Yang Lu Department of Biomedical Engineering, School of Medicine, Tsinghua University ??/Tel?+86-010-51532315 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Thu Sep 9 05:42:59 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Thu, 9 Sep 2010 05:42:59 -0400 Subject: [vtk-developers] help In-Reply-To: References: Message-ID: 2010/9/9 ?? : > hello,sorry to interupt you . > but i have a really important question.i am asking you for help. > i am a new learner of vtk. > recently,i am using vtk to do 3d reconstruction. > i am using mip(maximum intenstity projection ) to do this. > first reading some silces of ct dicom image,then do the projection. > as you know vtk is using pipeline ,we can only get 3d volume. > but what i want is the 2d image by MIP. > i dont know if i make myself understood by you? my english is poor. > here is the main code: > //read the dicoms > vtkDICOMImageReader *volumeReader = vtkDICOMImageReader::New(); > volumeReader->SetDirectoryName("C:/mrdata"); > vtkImageShiftScale *scale=vtkImageShiftScale::New(); > scale->SetInput(volumeReader->GetOutput()); > scale->SetOutputScalarTypeToUnsignedChar(); > scale->Update(); > vtkVolumeRayCastMIPFunction *MIP = vtkVolumeRayCastMIPFunction::New(); > vtkVolumeRayCastMapper *RaycastMapper = vtkVolumeRayCastMapper::New(); > RaycastMapper->SetVolumeRayCastFunction(MIP); > RaycastMapper->SetInput(scale->GetOutput()); > here is the case, where i can get the 2d image i want? > i couldnot find any interface.but i think the image should be the output of > RaycastMapper? > the pity is i cant find any output of RaycastMapper. > could you give me some suggestions? > -- > ?? > ?????????????? > Yang Lu Hi Yang, Unfortunately I don't have an answer for you, but I'd suggest you post this question to the VTK users list: http://www.vtk.org/mailman/listinfo/vtkusers The developers list is for questions about writing new code for VTK while the users list is about using existing code in VTK. Good luck! David From sean at rogue-research.com Thu Sep 9 10:04:47 2010 From: sean at rogue-research.com (Sean McBride) Date: Thu, 9 Sep 2010 10:04:47 -0400 Subject: [vtk-developers] UTF8 text rendering In-Reply-To: <4C2B553A.6090409@dkfz.de> References: <4C2B553A.6090409@dkfz.de> Message-ID: <20100909140447.198860006@mail.rogue-research.com> On Wed, 30 Jun 2010 16:31:22 +0200, Marco Nolden said: >I wrote a little fix to enable the rendering of utf8 characters. I think >the restriction to ascii actually was a bug caused by the incorrect >conversion of signed and unsigned values which did not work for >character codes >127: > >http://github.com/nolden/VTK/commit/9ba958806256e38ae4ae4fc424c37f8a7eea2ae9 > >See also: >http://www.vtk.org/Bug/view.php?id=4501 > >Maybe you could include that till the unicode support is fully implemented. Marco, Marcus, I've updated to git head to try this and it does not work for me. After a quick look at the code in vtkFreeTypeUtilities.cxx, I'm not surprised UTF8 does not work. The code does things like: for (; *str; str++) which presupposes that each character is one byte, which is not the case with UTF8. The patch did nothing to correct this. Indeed, if I use UTF8 characters that are represented as 2 bytes, they are rendered as two characters. So the first question is: which character encoding does vtkTextActor::SetInput() expect? The documentation was regressed in this regard: Through experimentation, I believe the answer is: ISO-8859-1. Though I'm not sure if that depends on the platform or the font, or anything else. Anyone know? Marco, might you have misused the term 'UTF8' to mean 'better than ASCII'? Character encodings are a complicated thing, I've always found this a good article if you want to learn more: Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From haehn at bwh.harvard.edu Thu Sep 9 11:39:34 2010 From: haehn at bwh.harvard.edu (Daniel Haehn) Date: Thu, 9 Sep 2010 11:39:34 -0400 Subject: [vtk-developers] [vtkusers] Coordinate conversions (World-Display) In-Reply-To: References: <564BD474-1FC0-427D-A0F9-1A757C9973AD@bwh.harvard.edu> Message-ID: Pat, looks good - I will use the static methods. Thank you, Daniel On Sep 8, 2010, at 6:44 PM, pat marion wrote: > Sadly, yes, this is the way to do it. If you want, there is a class that offers static convenience methods: > > static void vtkInteractorObserver::ComputeDisplayToWorld (vtkRenderer *ren, double x, double y, double z, double worldPt[4]) > static void vtkInteractorObserver::ComputeWorldToDisplay (vtkRenderer *ren, double x, double y, double z, double displayPt[3]) > > But if you look at the implementation... > > void vtkInteractorObserver::ComputeWorldToDisplay(vtkRenderer *ren, > double x, > double y, > double z, > double displayPt[3]) > { > ren->SetWorldPoint(x, y, z, 1.0); > ren->WorldToDisplay(); > ren->GetDisplayPoint(displayPt); > } > > One comment about your code... I'd be careful returning a double* like that. You don't own that memory, it could change at any time. > > Pat > > On Wed, Sep 8, 2010 at 1:42 PM, Daniel Haehn wrote: > Hi VTK experts, > > I use the following functions to convert between World and Display coordinates and vice versa. I found the method on the mailing list or in some other code. > > Isn't there an easier way to do that? Is it correct at all and is it robust? > > this->GetRenderer is a vtkRenderer. > > //--------------------------------------------------------------------------- > /// Convert display to world coordinates > double* vtkMRMLAnnotationThreeDViewDisplayableManager::GetDisplayToWorldCoordinates(double x, double y) > { > double coordinates[3]; > coordinates[0]=(double)x; > coordinates[1]=(double)y; > coordinates[2]=0; > > this->GetRenderer()->SetDisplayPoint(coordinates); > this->GetRenderer()->DisplayToView(); > this->GetRenderer()->GetViewPoint(coordinates); > this->GetRenderer()->ViewToWorld(); > return this->GetRenderer()->GetWorldPoint(); > > } > > //--------------------------------------------------------------------------- > /// Convert world to display coordinates > double* vtkMRMLAnnotationThreeDViewDisplayableManager::GetWorldToDisplayCoordinates(double * worldPoints) > { > > vtkDebugMacro("GetWorldToDisplayCoordinates: RAS " << worldPoints[0] << ", " << worldPoints[1] << ", " << worldPoints[2]) > > double * displayCoordinates; > > this->GetRenderer()->SetWorldPoint(worldPoints); > this->GetRenderer()->WorldToView(); > displayCoordinates = this->GetRenderer()->GetViewPoint(); > this->GetRenderer()->ViewToDisplay(); > > double * output = this->GetRenderer()->GetDisplayPoint(); > > vtkDebugMacro("GetWorldToDisplayCoordinates: Display " << output[0] << ", " << output[1]) > > return output; > > } > > Thank you, > Daniel > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtkusers > From david.gobbi at gmail.com Thu Sep 9 15:31:27 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 9 Sep 2010 13:31:27 -0600 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: I've removed GET_TARGET_PROPERTY(... LOCATION) throughout VTK. I did the wrapper executables yesterday, and since the dashboards didn't complain, I did the rest today. David On Wed, Sep 8, 2010 at 8:34 AM, David Gobbi wrote: > Hi David (Cole): > > I'll make sure the wrappers do this. ?But is there a reliable way for > me to get the full path so that I can store it in VTKConfig.cmake? > > ?David > > > On Wed, Sep 8, 2010 at 7:46 AM, David Cole wrote: >> get_target_property(... LOCATION) has never worked 100% reliably across all >> platforms... Its use should be eliminated. >> For add_custom_command use within a VTK CMakeLists.txt file, please use >> simply the name of the cmake target, not a reference to the executable file. >> Thanks, >> David Cole >> >> On Wed, Sep 8, 2010 at 8:40 AM, David Gobbi wrote: >>> >>> Hi Dave, >>> >>> I tried your suggestion of using the executable target name in >>> ADD_CUSTOM_COMMAND instead of using the full path to the executable. >>> It worked nicely, so I added the following code to CMakeLists.txt to >>> get DASH1 and DASH11 running again: >>> >>> ? ?# The LOCATION doesn't seem to work on Visual Studio 7 >>> ? ?IF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") >>> ? ? ?SET(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl) >>> ? ? ?SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) >>> ? ?ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") >>> ? ? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl ? ? LOCATION) >>> ? ? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) >>> ? ?ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") >>> >>> This works as a quick fix. ?The proper fix would be to use just >>> "vtkWrapTcl" when vtkWrapTcl.cmake is called from VTK, but to use the >>> full path when vtkWrapTcl.cmake is called from external packages. >>> This "proper fix" would be easy except for this nasty piece of code in >>> CMakeLists.txt: >>> >>> ?# Save these in cache as other projects including VTK (such as ParaView) >>> may >>> ?# want to use these. >>> ?SET(VTK_WRAP_PYTHON_EXE >>> ? ?"${VTK_WRAP_PYTHON_EXE}" >>> ? ?CACHE INTERNAL "Location of program to do Python wrapping") >>> ?SET(VTK_WRAP_PYTHON_INIT_EXE >>> ? ?"${VTK_WRAP_PYTHON_INIT_EXE}" >>> ? ?CACHE INTERNAL "Location of program to do Python wrapping") >>> >>> Hopefully this is legacy code. >>> >>> ? David >>> >>> >>> >>> >>> On Tue, Sep 7, 2010 at 1:16 PM, David Gobbi wrote: >>> > Thanks. ?That confirms my suspicion that it is a CMake issue. ?I was >>> > hoping that those machines were just broken somehow. ?Sigh. >>> > >>> > ?David >>> > >>> > >>> > On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka >>> > wrote: >>> >> That executable is in the bin tree. Actually I looked into this a >>> >> little bit >>> >> a week ago or so when I noticed it but was side tracked. >>> >> In the top level CMakeLists.txt file of VTK I don't think >>> >> GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes >>> >> (.\). >>> >> IF(CMAKE_CROSSCOMPILING) >>> >> ?? ?SET(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl) >>> >> ?? ?SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) >>> >> ??ELSE(CMAKE_CROSSCOMPILING) >>> >> ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE ? ? ?vtkWrapTcl ? ? LOCATION) >>> >> ?? ?GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) >>> >> ??ENDIF(CMAKE_CROSSCOMPILING) >>> >> That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and >>> >> vtkWrapPython.cmake could probably just use the target name >>> >> (vtkWrapTcl, >>> >> vtkWrapPython) and let CMake figure out the path on it's own instead of >>> >> using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. >>> >> # add custom command to output >>> >> ?? ? ?ADD_CUSTOM_COMMAND( >>> >> ?? ? ? ?OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx >>> >> ?? ? ? ?DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} >>> >> ?? ? ? ?${KIT_HIERARCHY_FILE} >>> >> ?? ? ? ?MAIN_DEPENDENCY "${TMP_INPUT}" >>> >> ?? ? ? ?COMMAND ${VTK_WRAP_TCL_EXE} >>> >> ?? ? ? ?ARGS >>> >> ?? ? ? ?${TMP_CONCRETE} >>> >> ?? ? ? ?${TMP_HINTS} >>> >> ?? ? ? ?${TMP_HIERARCHY} >>> >> ?? ? ? ?${TMP_DEFINITIONS} >>> >> ?? ? ? ?${TMP_INCLUDE} >>> >> ?? ? ? ?"${quote}${TMP_INPUT}${quote}" >>> >> >>> >> ?"${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" >>> >> ?? ? ? ?COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" >>> >> ?? ? ? ?${verbatim} >>> >> ?? ? ? ?) >>> >> >>> >> I'll let you take it from there :-P >>> >> >>> >> On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka >>> >> wrote: >>> >>> >>> >>> Sure thing. >>> >>> >>> >>> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi >>> >>> wrote: >>> >>>> >>> >>>> Does anyone know anything about DASH1 and DASH11? ?These machines >>> >>>> have >>> >>>> been complaining that "vtkWrapTcl.exe is not found" for several days >>> >>>> now. ?I have a vague feeling that they might be failing because of >>> >>>> something that I've done. ?Is there someone who can check to see if >>> >>>> vtkWrapTcl.exe is being built on these machines? >>> >>>> >>> >>>> 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers >>> >> >> > From dave.partyka at kitware.com Thu Sep 9 15:32:25 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Thu, 9 Sep 2010 15:32:25 -0400 Subject: [vtk-developers] DASH1 and DASH11 dashboards In-Reply-To: References: Message-ID: Excellent! Thanks David! On Thu, Sep 9, 2010 at 3:31 PM, David Gobbi wrote: > I've removed GET_TARGET_PROPERTY(... LOCATION) throughout VTK. I did > the wrapper executables yesterday, and since the dashboards didn't > complain, I did the rest today. > > David > > > On Wed, Sep 8, 2010 at 8:34 AM, David Gobbi wrote: > > Hi David (Cole): > > > > I'll make sure the wrappers do this. But is there a reliable way for > > me to get the full path so that I can store it in VTKConfig.cmake? > > > > David > > > > > > On Wed, Sep 8, 2010 at 7:46 AM, David Cole > wrote: > >> get_target_property(... LOCATION) has never worked 100% reliably across > all > >> platforms... Its use should be eliminated. > >> For add_custom_command use within a VTK CMakeLists.txt file, please use > >> simply the name of the cmake target, not a reference to the executable > file. > >> Thanks, > >> David Cole > >> > >> On Wed, Sep 8, 2010 at 8:40 AM, David Gobbi > wrote: > >>> > >>> Hi Dave, > >>> > >>> I tried your suggestion of using the executable target name in > >>> ADD_CUSTOM_COMMAND instead of using the full path to the executable. > >>> It worked nicely, so I added the following code to CMakeLists.txt to > >>> get DASH1 and DASH11 running again: > >>> > >>> # The LOCATION doesn't seem to work on Visual Studio 7 > >>> IF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") > >>> SET(VTK_WRAP_TCL_EXE vtkWrapTcl) > >>> SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) > >>> ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") > >>> GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION) > >>> GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION) > >>> ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*") > >>> > >>> This works as a quick fix. The proper fix would be to use just > >>> "vtkWrapTcl" when vtkWrapTcl.cmake is called from VTK, but to use the > >>> full path when vtkWrapTcl.cmake is called from external packages. > >>> This "proper fix" would be easy except for this nasty piece of code in > >>> CMakeLists.txt: > >>> > >>> # Save these in cache as other projects including VTK (such as > ParaView) > >>> may > >>> # want to use these. > >>> SET(VTK_WRAP_PYTHON_EXE > >>> "${VTK_WRAP_PYTHON_EXE}" > >>> CACHE INTERNAL "Location of program to do Python wrapping") > >>> SET(VTK_WRAP_PYTHON_INIT_EXE > >>> "${VTK_WRAP_PYTHON_INIT_EXE}" > >>> CACHE INTERNAL "Location of program to do Python wrapping") > >>> > >>> Hopefully this is legacy code. > >>> > >>> David > >>> > >>> > >>> > >>> > >>> On Tue, Sep 7, 2010 at 1:16 PM, David Gobbi > wrote: > >>> > Thanks. That confirms my suspicion that it is a CMake issue. I was > >>> > hoping that those machines were just broken somehow. Sigh. > >>> > > >>> > David > >>> > > >>> > > >>> > On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka < > dave.partyka at kitware.com> > >>> > wrote: > >>> >> That executable is in the bin tree. Actually I looked into this a > >>> >> little bit > >>> >> a week ago or so when I noticed it but was side tracked. > >>> >> In the top level CMakeLists.txt file of VTK I don't think > >>> >> GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes > >>> >> (.\). > >>> >> IF(CMAKE_CROSSCOMPILING) > >>> >> SET(VTK_WRAP_TCL_EXE vtkWrapTcl) > >>> >> SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit) > >>> >> ELSE(CMAKE_CROSSCOMPILING) > >>> >> GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl > LOCATION) > >>> >> GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit > LOCATION) > >>> >> ENDIF(CMAKE_CROSSCOMPILING) > >>> >> That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and > >>> >> vtkWrapPython.cmake could probably just use the target name > >>> >> (vtkWrapTcl, > >>> >> vtkWrapPython) and let CMake figure out the path on it's own instead > of > >>> >> using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to. > >>> >> # add custom command to output > >>> >> ADD_CUSTOM_COMMAND( > >>> >> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx > >>> >> DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS} > >>> >> ${KIT_HIERARCHY_FILE} > >>> >> MAIN_DEPENDENCY "${TMP_INPUT}" > >>> >> COMMAND ${VTK_WRAP_TCL_EXE} > >>> >> ARGS > >>> >> ${TMP_CONCRETE} > >>> >> ${TMP_HINTS} > >>> >> ${TMP_HIERARCHY} > >>> >> ${TMP_DEFINITIONS} > >>> >> ${TMP_INCLUDE} > >>> >> "${quote}${TMP_INPUT}${quote}" > >>> >> > >>> >> > "${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}" > >>> >> COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx" > >>> >> ${verbatim} > >>> >> ) > >>> >> > >>> >> I'll let you take it from there :-P > >>> >> > >>> >> On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka < > dave.partyka at kitware.com> > >>> >> wrote: > >>> >>> > >>> >>> Sure thing. > >>> >>> > >>> >>> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi > > >>> >>> wrote: > >>> >>>> > >>> >>>> Does anyone know anything about DASH1 and DASH11? These machines > >>> >>>> have > >>> >>>> been complaining that "vtkWrapTcl.exe is not found" for several > days > >>> >>>> now. I have a vague feeling that they might be failing because of > >>> >>>> something that I've done. Is there someone who can check to see > if > >>> >>>> vtkWrapTcl.exe is being built on these machines? > >>> >>>> > >>> >>>> 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > >>> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbsk at ohiou.edu Fri Sep 10 14:56:22 2010 From: hobbsk at ohiou.edu (Kevin H. Hobbs) Date: Fri, 10 Sep 2010 14:56:22 -0400 Subject: [vtk-developers] Mangled Mesa Unsupported? Message-ID: <4C8A7F56.9000703@ohiou.edu> While trying to sort out some problems with Mesa from git I found out that mangled mesa is no longer supported by VTK. Should the VTK_USE_MANGLED_MESA CMake variable be removed? Should the Rendering/vtkMesa* classes be removed? It seems like each vtkMesaXXX.cxx file does : #include "vtkOpenGLXXX.h" #include "vtkMesaXXX.h" #define vtkOpenGLXXX vtkMesaXXX #include "vtkOpenGLXXX.cxx" #undef vtkOpenGLXXX but vtkOpenGLXXX.h and vtkMesaXXX.h differ so much that vtkOpenGLXXX.cxx cannot be compiled. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: From daviddoria+vtk at gmail.com Sun Sep 12 09:18:44 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Sun, 12 Sep 2010 09:18:44 -0400 Subject: [vtk-developers] New function: vtkMath::ProjectVector Message-ID: I added a function called ProjectVector to vtkMath along with a test for it in TestMath.cxx. repo: git at github.com:daviddoria/daviddoria-vtk.git branch: VTK-VectorProjection Any comments/objections? David From david.cole at kitware.com Sun Sep 12 10:40:13 2010 From: david.cole at kitware.com (David Cole) Date: Sun, 12 Sep 2010 10:40:13 -0400 Subject: [vtk-developers] New function: vtkMath::ProjectVector In-Reply-To: References: Message-ID: If it's only one commit, send a link exactly to that commit, so people can click on it and see the diffs right in their web browser: http://github.com/daviddoria/daviddoria-vtk/commit/43efaf1bc09bd8c21e9d15c9366b86b83288f99a If it's a series of commits, be sure you ask for people to look at "the last N commits" or whatever is appropriate. I'll let the math experts chime in and review the actual content of the diffs. A review like this would be easier if you would separate out the "white space only" changes into a separate commit, so the people interested in reviewing the actual diff content don't have to wade through the 80% to find the 20%.... :-) David C. On Sun, Sep 12, 2010 at 9:18 AM, David Doria > wrote: > I added a function called ProjectVector to vtkMath along with a test > for it in TestMath.cxx. > > repo: git at github.com:daviddoria/daviddoria-vtk.git > branch: VTK-VectorProjection > > Any comments/objections? > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Sun Sep 12 11:15:36 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Sun, 12 Sep 2010 11:15:36 -0400 Subject: [vtk-developers] New function: vtkMath::ProjectVector In-Reply-To: References: Message-ID: On Sun, Sep 12, 2010 at 10:40 AM, David Cole wrote: > If it's only one commit, send a link exactly to that commit, so people can > click on it and see the diffs right in their web browser: > http://github.com/daviddoria/daviddoria-vtk/commit/43efaf1bc09bd8c21e9d15c9366b86b83288f99a > If it's a series of commits, be sure you ask for people to look at "the last > N commits" or whatever is appropriate. > I'll let the math experts chime in and review the actual content of the > diffs. > A review like this would be easier if you would separate out the "white > space only" changes into a separate commit, so the people interested in > reviewing the actual diff content don't have to wade through the 80% to find > the 20%.... :-) > > David C. Two good points David C. I will definitely link directly to a commit in the future. I didn't intentionally change any whitespace, I guess there are files that have not been committed since the hooks were in place? It looks my editor removed the trailing whitespace which shouldn't have been there in the first place :) Should we make a pass through and 'touch' all of the files and commit them so they are all checked against the hooks? David D. From david.cole at kitware.com Sun Sep 12 11:28:21 2010 From: david.cole at kitware.com (David Cole) Date: Sun, 12 Sep 2010 11:28:21 -0400 Subject: [vtk-developers] New function: vtkMath::ProjectVector In-Reply-To: References: Message-ID: On Sun, Sep 12, 2010 at 11:15 AM, David Doria > wrote: > On Sun, Sep 12, 2010 at 10:40 AM, David Cole > wrote: > > If it's only one commit, send a link exactly to that commit, so people > can > > click on it and see the diffs right in their web browser: > > > http://github.com/daviddoria/daviddoria-vtk/commit/43efaf1bc09bd8c21e9d15c9366b86b83288f99a > > If it's a series of commits, be sure you ask for people to look at "the > last > > N commits" or whatever is appropriate. > > I'll let the math experts chime in and review the actual content of the > > diffs. > > A review like this would be easier if you would separate out the "white > > space only" changes into a separate commit, so the people interested in > > reviewing the actual diff content don't have to wade through the 80% to > find > > the 20%.... :-) > > > > David C. > > Two good points David C. I will definitely link directly to a commit > in the future. > > I didn't intentionally change any whitespace, I guess there are files > that have not been committed since the hooks were in place? It looks > my editor removed the trailing whitespace which shouldn't have been > there in the first place :) Should we make a pass through and 'touch' > all of the files and commit them so they are all checked against the > hooks? > > David D. > The white space thing shouldn't be that much of a problem, even with files that have present "mistakes" in them... The hooks only check *changed* lines, so maybe change your editor so it doesn't always automatically do that.....? Any math guys out there to comment on the rest of David D's changes? Thx, David C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcplatt at dsl.pipex.com Sun Sep 12 19:49:27 2010 From: jcplatt at dsl.pipex.com (John Platt) Date: Mon, 13 Sep 2010 00:49:27 +0100 Subject: [vtk-developers] New function: vtkMath::ProjectVector References: Message-ID: <5E31EE955B6D40F2886400C60094057F@pafec5> Hi David, There could be a quick exit when b[3] is a zero vector to avoid any trouble computing scale. There is the potential for round off damage and a small inefficiency by squaring the square root computed by Norm(). I can't get {25./26., 5./26., 0} to make (1.2, -1.6, 0) in your test program. HTH John. ----- Original Message ----- From: David Cole To: David Doria Cc: VTK Developers Sent: Sunday, September 12, 2010 4:28 PM Subject: Re: [vtk-developers] New function: vtkMath::ProjectVector On Sun, Sep 12, 2010 at 11:15 AM, David Doria wrote: On Sun, Sep 12, 2010 at 10:40 AM, David Cole wrote: > If it's only one commit, send a link exactly to that commit, so people can > click on it and see the diffs right in their web browser: > http://github.com/daviddoria/daviddoria-vtk/commit/43efaf1bc09bd8c21e9d15c9366b86b83288f99a > If it's a series of commits, be sure you ask for people to look at "the last > N commits" or whatever is appropriate. > I'll let the math experts chime in and review the actual content of the > diffs. > A review like this would be easier if you would separate out the "white > space only" changes into a separate commit, so the people interested in > reviewing the actual diff content don't have to wade through the 80% to find > the 20%.... :-) > > David C. Two good points David C. I will definitely link directly to a commit in the future. I didn't intentionally change any whitespace, I guess there are files that have not been committed since the hooks were in place? It looks my editor removed the trailing whitespace which shouldn't have been there in the first place :) Should we make a pass through and 'touch' all of the files and commit them so they are all checked against the hooks? David D. The white space thing shouldn't be that much of a problem, even with files that have present "mistakes" in them... The hooks only check *changed* lines, so maybe change your editor so it doesn't always automatically do that.....? Any math guys out there to comment on the rest of David D's changes? Thx, David C. ------------------------------------------------------------------------------ _______________________________________________ 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://www.vtk.org/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Sun Sep 12 20:00:26 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Sun, 12 Sep 2010 20:00:26 -0400 Subject: [vtk-developers] New function: vtkMath::ProjectVector In-Reply-To: <5E31EE955B6D40F2886400C60094057F@pafec5> References: <5E31EE955B6D40F2886400C60094057F@pafec5> Message-ID: On Sun, Sep 12, 2010 at 7:49 PM, John Platt wrote: > Hi David, > > There could be a quick exit when b[3] is a zero vector to avoid?any trouble > computing scale. > > There is the potential for round off damage and a small inefficiency by > squaring the square root computed by Norm(). > > I can't get {25./26.,?5./26.,?0} to make (1.2,?-1.6,?0) in your test > program. > > HTH > > John. Hi John, Thanks for looking at this. I added the test for an all zero b vector. Sorry, it was my mistake in the test. I changed the vectors that the test was using but I did not update the text of the error message displayed if it failed. The test passes when the projection is the vector {25./26.,?5./26.,?0} (and it did and still does pass for me). http://github.com/daviddoria/daviddoria-vtk/commit/7fc33a0ebe7c2b589e62f5db396ec4527ee57f79 Do you have a suggestion for how to overcome the roundoff error and inefficiency of the squaring? Thanks, David D. From jcplatt at dsl.pipex.com Mon Sep 13 04:05:18 2010 From: jcplatt at dsl.pipex.com (John Platt) Date: Mon, 13 Sep 2010 09:05:18 +0100 Subject: [vtk-developers] New function: vtkMath::ProjectVector References: <5E31EE955B6D40F2886400C60094057F@pafec5> Message-ID: David, Perhaps the scale factor could be computed by .. const double bSquared = b[0]*b[0] + b[1]*b[1] + b[2]*b[2]; const double scale = bSquared > 0.0 ? vtkMath::Dot(a,b)/bSquared : 0.0; and then continue to scale b[] without the zero check on b[]. It's your decision if you want a zero b[] to be an error as the algorithm should not fail (personally I would let it pass) but it should be documented as a precondition. HTH John. ----- Original Message ----- From: "David Doria" To: "John Platt" Cc: "VTK Developers" Sent: Monday, September 13, 2010 1:00 AM Subject: Re: [vtk-developers] New function: vtkMath::ProjectVector On Sun, Sep 12, 2010 at 7:49 PM, John Platt wrote: > Hi David, > > There could be a quick exit when b[3] is a zero vector to avoid any > trouble > computing scale. > > There is the potential for round off damage and a small inefficiency by > squaring the square root computed by Norm(). > > I can't get {25./26., 5./26., 0} to make (1.2, -1.6, 0) in your test > program. > > HTH > > John. Hi John, Thanks for looking at this. I added the test for an all zero b vector. Sorry, it was my mistake in the test. I changed the vectors that the test was using but I did not update the text of the error message displayed if it failed. The test passes when the projection is the vector {25./26., 5./26., 0} (and it did and still does pass for me). http://github.com/daviddoria/daviddoria-vtk/commit/7fc33a0ebe7c2b589e62f5db396ec4527ee57f79 Do you have a suggestion for how to overcome the roundoff error and inefficiency of the squaring? Thanks, David D. From rogerbramon at gmail.com Tue Sep 14 02:48:56 2010 From: rogerbramon at gmail.com (Roger Bramon Feixas) Date: Tue, 14 Sep 2010 08:48:56 +0200 Subject: [vtk-developers] Performance improvement of vtkCornerAnnotation class using vtkTextActor In-Reply-To: References: Message-ID: Hi, I'm developing on Mac OS X and I recently updated my VTK version from 5.0.4 to 5.6. On Mac Os X, the frame rate of a 2D render window is drastically reduced when vtkCornerAnnotation is set to on. I also noticed that from VTK 5.2 the vtkTextActor implementation uses textures instead of OpenGL sentences but the current implementation of vtkCornerAnnotation uses vtkActor2D instead of vtkTextActor therefore it doesn't take the benefit of using textures. I changed vtkCornerAnnotation implementation in order to test the performance of using textures and the result is really interesting. The frame rate increases from 6 frames/s to 60 frames/s which is the same frame rate when vtkCornerAnnotation isn't used. I attach a zip which includes the implementation (even thought it isn't a nice implementation because I just did the minimum changes to be able to use vtkTextActor), the patch file, and a pdf file which is a summary of my test results done on Windows XP and Mac OS X. On Windows, if we just analyze the frame rate, we could conclude that it isn't necessary to change the implementation to use vtkTextActor, however, we could reduce a lot the CPU usage. I would like to know your opinion about it, and, perhaps, someone could test it on Linux, or with ATI graphics card or on Windows with dual core processor (I test it with quad core processor). Thanks for your attention. Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: performance_vtkCornerAnnotation.zip Type: application/zip Size: 16544 bytes Desc: not available URL: From david.gobbi at gmail.com Tue Sep 14 09:27:06 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 14 Sep 2010 07:27:06 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> <4C86C49F.9020502@sandia.gov> <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> Message-ID: Hi Eric, This morning I added some code that allows the python wrappers to resolve typedefs, so those missing vtkArray methods are wrapped again. Let me know if the new code works for you. David On Tue, Sep 7, 2010 at 7:47 PM, Eric E. Monson wrote: > On Sep 7, 2010, at 7:02 PM, Timothy Shead wrote: > >> On 9/7/10 1:38 PM, David Gobbi wrote: >>> I'm fine with that. ?Wrapper typedef support is something that I had >>> planned from the start, I just didn't expect that it would be needed >>> so soon. ?What do you think of Eric's GetDimensionRange() method >>> suggestion? ?I'd prefer that there are always named-method >>> alternatives to [ ] operator methods. >> >> Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. > > Ah, thank you -- I hadn't seen the vtkArray::GetExtent() option. I can get the values from that for now. > > -Eric > > From sean at rogue-research.com Tue Sep 14 10:43:57 2010 From: sean at rogue-research.com (Sean McBride) Date: Tue, 14 Sep 2010 10:43:57 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts Message-ID: <20100914144357.1007046035@mail.rogue-research.com> Hi all, We've been profiling our app lately, and I've found some of our bottlenecks are in vtkImageReslice. One is vtkResliceRound() here: It has a bunch of incomprehensible (but clever!) CPU-specific implementations, but the general implementation is: inline int vtkResliceRound(double x) { return static_cast(floor(x+0.5)); } The comments indicate that the slow floor() is the reason for the CPU- specific implementations. But I don't see the need for the floor() at all. floor() returns double, but then we cast to int anyway. So why not skip the floor and cast straight to int? In my usage, that change works and is much faster. Is there some edge- case that I'm not seeing? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From berk.geveci at kitware.com Tue Sep 14 11:01:54 2010 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 14 Sep 2010 11:01:54 -0400 Subject: [vtk-developers] Mangled Mesa Unsupported? In-Reply-To: <4C8A7F56.9000703@ohiou.edu> References: <4C8A7F56.9000703@ohiou.edu> Message-ID: I'd say yes to all your questions :-) On Fri, Sep 10, 2010 at 2:56 PM, Kevin H. Hobbs wrote: > While trying to sort out some problems with Mesa from git I found out > that mangled mesa is no longer supported by VTK. > > Should the VTK_USE_MANGLED_MESA CMake variable be removed? > > Should the Rendering/vtkMesa* classes be removed? > > It seems like each vtkMesaXXX.cxx file does : > > #include "vtkOpenGLXXX.h" > #include "vtkMesaXXX.h" > > #define vtkOpenGLXXX vtkMesaXXX > #include "vtkOpenGLXXX.cxx" > #undef vtkOpenGLXXX > > but vtkOpenGLXXX.h and vtkMesaXXX.h differ so much that vtkOpenGLXXX.cxx > cannot be compiled. > > > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From david.gobbi at gmail.com Tue Sep 14 11:08:01 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 14 Sep 2010 09:08:01 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100914144357.1007046035@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> Message-ID: Hi Sean, Casting to int does round-towards-zero, while floor() does round-towards-neg-infinity. The latter rounding mode is needed for vtkImageReslice. Also, even casting to int can be notoriously slow on the x86 CPU. A summary is provided here: http://www.stereopsis.com/FPU.html The general implementation "static_cast(floor())" is the simplest correct implementation, even if it is inefficient, so I'd like to leave it as the general case. But we could easily add an #ifdef to add whichever float-to-int conversion is most efficient for your platform. David On Tue, Sep 14, 2010 at 8:43 AM, Sean McBride wrote: > Hi all, > > We've been profiling our app lately, and I've found some of our > bottlenecks are in vtkImageReslice. > > One is vtkResliceRound() here: > > vtkImageReslice.cxx;h=2c65fbd922fd6b9daeae39110232d19ef21e6b93;hb=HEAD> > > It has a bunch of incomprehensible (but clever!) CPU-specific > implementations, but the general implementation is: > > inline int vtkResliceRound(double x) > { > ?return static_cast(floor(x+0.5)); > } > > The comments indicate that the slow floor() is the reason for the CPU- > specific implementations. ?But I don't see the need for the floor() at > all. ?floor() returns double, but then we cast to int anyway. ?So why > not skip the floor and cast straight to int? > > In my usage, that change works and is much faster. ?Is there some edge- > case that I'm not seeing? > > Thanks, > > -- > ____________________________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > From sean at rogue-research.com Tue Sep 14 12:33:52 2010 From: sean at rogue-research.com (Sean McBride) Date: Tue, 14 Sep 2010 12:33:52 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> Message-ID: <20100914163352.1214385486@mail.rogue-research.com> Hi David, Thanks for your speedy reply! On Tue, 14 Sep 2010 09:08:01 -0600, David Gobbi said: >Casting to int does round-towards-zero, while floor() does >round-towards-neg-infinity. The latter rounding mode is needed for >vtkImageReslice. Ah! Does vtkImageReslice care about other edge cases, like inf, nan, or doubles outside the range of the 'int' type? >Also, even casting to int can be notoriously slow on >the x86 CPU. A summary is provided here: >http://www.stereopsis.com/FPU.html Interesting. Well, there have been so many x86 CPUs... :) For me, the compiler seems to use cvttsd2si, which seems pretty fast. But is doesn't round as desired. >The general implementation "static_cast(floor())" is the simplest >correct implementation, even if it is inefficient, so I'd like to >leave it as the general case. I agree it's good to have a simple correct baseline to compare against. >But we could easily add an #ifdef to >add whichever float-to-int conversion is most efficient for your >platform. The two platforms I deploy to, ppc64 and x86_64, both fall into the general floor() case. :( I don't see anything like cvttsd2si that does round-towards-neg-infinity. But this must be a solved problem... -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Tue Sep 14 12:54:56 2010 From: sean at rogue-research.com (Sean McBride) Date: Tue, 14 Sep 2010 12:54:56 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> Message-ID: <20100914165456.341763210@mail.rogue-research.com> On Tue, 14 Sep 2010 09:08:01 -0600, David Gobbi said: >Casting to int does round-towards-zero, while floor() does >round-towards-neg-infinity. The latter rounding mode is needed for >vtkImageReslice. BTW, no test seems to catch this. Before and after I changed the floor to a simple cast, the same tests pass/fail. (Alas, many tests fail on my config, hopefully none of these failures are masking a test that would have caught this.) -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Tue Sep 14 13:43:54 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 14 Sep 2010 11:43:54 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100914163352.1214385486@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100914163352.1214385486@mail.rogue-research.com> Message-ID: On Tue, Sep 14, 2010 at 10:33 AM, Sean McBride wrote: > > Ah! ?Does vtkImageReslice care about other edge cases, like inf, nan, or > doubles outside the range of the 'int' type? It's only picky about values below zero or close to zero. Any inf, nan, etc. is likely to make the code misbehave badly. > BTW, no test seems to catch this. Before and after I changed the floor > to a simple cast, the same tests pass/fail. (Alas, many tests fail on > my config, hopefully none of these failures are masking a test that > would have caught this.) Yeah, it is a big problem that the tests only cover the non-positive range. The Extent is a signed integer, so the WholeExtent of any image can cover any combination of negative/positive values. But AFAIK all VTK image tests are only testing non-negative extents. There is a similar problem with Spacing: a person can set the Spacing to a negative value, but VTK classes are not tested to make sure they work with negative spacing. I'll see what I can do about adding a couple more tests for ImageReslice. >>Also, even casting to int can be notoriously slow on >>the x86 CPU. ?A summary is provided here: >>http://www.stereopsis.com/FPU.html > > Interesting. ?Well, there have been so many x86 CPUs... :) ?For me, the > compiler seems to use CVTTSD2SI, which seems pretty fast. ?But is > doesn't round as desired. That ImageReslice float-to-int code is old, and compilers only started generating SSE instructions from vanilla C++ code fairly recently. Find something that works fast with your compiler/CPU, make sure that it does round-to-negative-infinity, and send it along. David From david.gobbi at gmail.com Tue Sep 14 14:15:35 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 14 Sep 2010 12:15:35 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100914163352.1214385486@mail.rogue-research.com> Message-ID: On Tue, Sep 14, 2010 at 11:43 AM, David Gobbi wrote: > it is a big problem that the tests only cover the non-positive range. Oops! I meant to say the opposite. The tests all use image extents [a, b, c, d, e, f] where a,b,c,d,e,f are all non-negative. Negative values are the ones that aren't tested. David From emonson at cs.duke.edu Tue Sep 14 14:46:37 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 14 Sep 2010 14:46:37 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> <4C86C49F.9020502@sandia.gov> <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> Message-ID: <534C14F1-94F7-4D3B-A6EF-DD7771B2A63A@cs.duke.edu> Thanks, David, I'll take a look at it in the next day or two and let you know if I have any problems. I appreciate you addressing this so quickly. Talk to you later, -Eric On Sep 14, 2010, at 9:27 AM, David Gobbi wrote: > Hi Eric, > > This morning I added some code that allows the python wrappers to > resolve typedefs, so those missing vtkArray methods are wrapped again. > Let me know if the new code works for you. > > David > > > On Tue, Sep 7, 2010 at 7:47 PM, Eric E. Monson wrote: >> On Sep 7, 2010, at 7:02 PM, Timothy Shead wrote: >> >>> On 9/7/10 1:38 PM, David Gobbi wrote: >>>> I'm fine with that. Wrapper typedef support is something that I had >>>> planned from the start, I just didn't expect that it would be needed >>>> so soon. What do you think of Eric's GetDimensionRange() method >>>> suggestion? I'd prefer that there are always named-method >>>> alternatives to [ ] operator methods. >>> >>> Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. >> >> Ah, thank you -- I hadn't seen the vtkArray::GetExtent() option. I can get the values from that for now. >> >> -Eric >> >> From kmorel at sandia.gov Tue Sep 14 18:37:02 2010 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Tue, 14 Sep 2010 16:37:02 -0600 Subject: [vtk-developers] New function: vtkMath::ProjectVector In-Reply-To: Message-ID: You can get the magnitude squared of any vector by taking the dot product with itself. That's basically what you are doing to compute the bSquared variable although I would suggest using vtkMath::Dot(b,b) instead. -Ken On 9/13/10 2:05 AM, "John Platt" wrote: David, Perhaps the scale factor could be computed by .. const double bSquared = b[0]*b[0] + b[1]*b[1] + b[2]*b[2]; const double scale = bSquared > 0.0 ? vtkMath::Dot(a,b)/bSquared : 0.0; and then continue to scale b[] without the zero check on b[]. It's your decision if you want a zero b[] to be an error as the algorithm should not fail (personally I would let it pass) but it should be documented as a precondition. HTH John. ----- Original Message ----- From: "David Doria" To: "John Platt" Cc: "VTK Developers" Sent: Monday, September 13, 2010 1:00 AM Subject: Re: [vtk-developers] New function: vtkMath::ProjectVector On Sun, Sep 12, 2010 at 7:49 PM, John Platt wrote: > Hi David, > > There could be a quick exit when b[3] is a zero vector to avoid any > trouble > computing scale. > > There is the potential for round off damage and a small inefficiency by > squaring the square root computed by Norm(). > > I can't get {25./26., 5./26., 0} to make (1.2, -1.6, 0) in your test > program. > > HTH > > John. Hi John, Thanks for looking at this. I added the test for an all zero b vector. Sorry, it was my mistake in the test. I changed the vectors that the test was using but I did not update the text of the error message displayed if it failed. The test passes when the projection is the vector {25./26., 5./26., 0} (and it did and still does pass for me). http://github.com/daviddoria/daviddoria-vtk/commit/7fc33a0ebe7c2b589e62f5db396ec4527ee57f79 Do you have a suggestion for how to overcome the roundoff error and inefficiency of the squaring? Thanks, David D. _______________________________________________ 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://www.vtk.org/mailman/listinfo/vtk-developers **** Kenneth Moreland *** Sandia National Laboratories *********** *** *** *** email: kmorel at sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://www.cs.unm.edu/~kmorel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Tue Sep 14 19:40:18 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Tue, 14 Sep 2010 19:40:18 -0400 Subject: [vtk-developers] New function: vtkMath::ProjectVector In-Reply-To: References: Message-ID: On Tue, Sep 14, 2010 at 6:37 PM, Moreland, Kenneth wrote: > You can get the magnitude squared of any vector by taking the dot product > with itself. That?s basically what you are doing to compute the bSquared > variable although I would suggest using vtkMath::Dot(b,b) instead. > > -Ken > Thanks John and Ken, I changed it to use the dot product of b with itself instead of the squared norm. I also changed the function to return a bool. If b is a zero vector it returns false and 'projected' is invalid' (I put a note in the function description about this behavior). Otherwise, it computes the projection and returns true. Here is the latest commit: http://github.com/daviddoria/daviddoria-vtk/commit/e227a729bbd8062c434894d23cc65f72213470c8 Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.fillard at gmail.com Wed Sep 15 07:46:56 2010 From: pierre.fillard at gmail.com (Pierre Fillard) Date: Wed, 15 Sep 2010 13:46:56 +0200 Subject: [vtk-developers] Fwd: Handling multi-touch gestures in VTK In-Reply-To: References: Message-ID: I forward this mail to the VTK developers, as you may be interested as well. Pierre. ---------- Forwarded message ---------- From: Pierre Fillard Date: Wed, Sep 15, 2010 at 11:06 AM Subject: Handling multi-touch gestures in VTK To: vtkusers at vtk.org Hello, I always wanted to use multi-touch gestures such as the pinching, rotating, or swiping features of recent apple's computers in VTK to control zooming, spining and panning of my objects in 3D. Maybe this was already integrated in the VTK master branch (though I didn't see it) or planned to be integrated. But to support my needs, I added support for those new gesture interactions in VTK by adding three new events in the vtkCommand class: - PinchGestureEvent - RotateGestureEvent - SwipeGestureEvent I wrote interfaces in the vtkCocoaGLView class to translate Cocoa's events into those, and I wrote callbacks to handle them properly in vtkInteractorStyleTrackballCamera just as a proof of concept. Moreover, Qt 4.6 proposes gesture events (QGestureEvents) that I properly interfaced in the QVTKWidget class. Thus, with these modifications, using either a Cocoa RenderWindow or a QVTKWidget instance, one is able to zoom by pinching, rotate by drawing a circle on a multi-touch device or panning by (long-)taping on the trackpad. If anyone is interested, I would be happy to share the code, or even give it to kitware for review / integration. Anyone can access it anonymously here. These are just files which should be replaced in your VTK source tree: svn checkout svn:// scm.gforge.inria.fr/svn/parietal-public/Utilities/VTKMultiTouch Note that modifications are based on VTK 5.6 and Qt 4.6. And you need a multi-touch device, of course. Cheers, Pierre. -- Pierre Fillard, Ph.D., Research Scientist INRIA Parietal - Neurospin B?t 145, Point Courrier 156 91191 Gif/Yvette, France tel: +33 1 69 08 79 92 -- Pierre Fillard, Ph.D., Research Scientist INRIA Parietal - Neurospin B?t 145, Point Courrier 156 91191 Gif/Yvette, France tel: +33 1 69 08 79 92 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Sep 15 11:06:24 2010 From: sean at rogue-research.com (Sean McBride) Date: Wed, 15 Sep 2010 11:06:24 -0400 Subject: [vtk-developers] vtkMath inline choices... Message-ID: <20100915150624.1562263698@mail.rogue-research.com> Hi again all, I'm continuing my profiling, and now have a question about vtkMath.h... How was it decided what to inline and what not to? There are some 'big' methods like vtkMath::Cross() that are inline, and yet there are some very short methods like vtkMath::IsNan() that are not inlined. I'm asking because I believe it could be beneficial for IsNan to be inlined (though have not yet tested). 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 kmorel at sandia.gov Wed Sep 15 11:24:14 2010 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Wed, 15 Sep 2010 09:24:14 -0600 Subject: [vtk-developers] vtkMath inline choices... In-Reply-To: <20100915150624.1562263698@mail.rogue-research.com> Message-ID: I can speak to why IsNan is not inlined. The IsNan (and similar non-finite tests) rely on some non-portable functionality. Depending on whether the isnan function is provided, IEEE-754 numbers are used, or if operations on NaNs are trapped, different implementations are provided. Over time this can get even more complicated as we encounter computers and compilers that treat NaNs differently. Quite simply, I did not want to expose all of this complexity in the header file. If you plan to go through the trouble of moving that to the header file, you should do performance tests to make sure that there is a clear advantage to inlining the function. I've been surprised in the past to find an inline function did not really perform any better than a function call. The fact of the matter is that function calls are cheap operations nowadays. -Ken On 9/15/10 9:06 AM, "Sean McBride" wrote: Hi again all, I'm continuing my profiling, and now have a question about vtkMath.h... How was it decided what to inline and what not to? There are some 'big' methods like vtkMath::Cross() that are inline, and yet there are some very short methods like vtkMath::IsNan() that are not inlined. I'm asking because I believe it could be beneficial for IsNan to be inlined (though have not yet tested). 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://www.vtk.org/mailman/listinfo/vtk-developers **** Kenneth Moreland *** Sandia National Laboratories *********** *** *** *** email: kmorel at sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://www.cs.unm.edu/~kmorel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Sep 15 11:42:27 2010 From: sean at rogue-research.com (Sean McBride) Date: Wed, 15 Sep 2010 11:42:27 -0400 Subject: [vtk-developers] vtkMath inline choices... In-Reply-To: References: <20100915150624.1562263698@mail.rogue-research.com> Message-ID: <20100915154227.1595723599@mail.rogue-research.com> On Wed, 15 Sep 2010 09:24:14 -0600, Moreland, Kenneth said: >I can speak to why IsNan is not inlined. The IsNan (and similar non- >finite tests) rely on some non-portable functionality. Depending on >whether the isnan function is provided, IEEE-754 numbers are used, or if >operations on NaNs are trapped, different implementations are provided. >Over time this can get even more complicated as we encounter computers >and compilers that treat NaNs differently. Quite simply, I did not want >to expose all of this complexity in the header file. Ken, Thanks for your informative reply. There are systems VTK supports that don't use IEEE-754 numbers? Didn't know that... Out of curiosity, which? Similarly, where would VTK_HAS_ISNAN be 0? I was kinda hoping it was only with old compilers for which support was recently dropped. :) >If you plan to go through the trouble of moving that to the header file, >you should do performance tests to make sure that there is a clear >advantage to inlining the function. Certainly. As I said, I am in the middle of doing many profiling tests. >I've been surprised in the past to >find an inline function did not really perform any better than a >function call. The fact of the matter is that function calls are cheap >operations nowadays. And inlining can make code bigger, and thus bloat caches. Certainly there are trade offs. And making something faster in one usage can make it slower in another. Optimisation in the general case is tricky with a general and portable framework like VTK. :( OTOH, marking a method inline only makes it eligible for inline, it's not an obligation. One hopes that the compiler can make a good decision. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From kmorel at sandia.gov Wed Sep 15 12:04:10 2010 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Wed, 15 Sep 2010 10:04:10 -0600 Subject: [vtk-developers] vtkMath inline choices... In-Reply-To: <20100915154227.1595723599@mail.rogue-research.com> Message-ID: I don't know of any systems we are currently running on that don't use IEEE-754 numbers, but it's a bad idea to assume that they are. There is nothing in any compiler standard specifying the bit layout of floating point numbers. I can't remember what dashboards didn't have the isnan function, but there definitely were some at the time I write the vtkMath functions (which was not that long ago). The isnan function was relatively recently added to the C standard (C99), so I would expect to run into non-conforming compilers for some time. -Ken On 9/15/10 9:42 AM, "Sean McBride" wrote: On Wed, 15 Sep 2010 09:24:14 -0600, Moreland, Kenneth said: >I can speak to why IsNan is not inlined. The IsNan (and similar non- >finite tests) rely on some non-portable functionality. Depending on >whether the isnan function is provided, IEEE-754 numbers are used, or if >operations on NaNs are trapped, different implementations are provided. >Over time this can get even more complicated as we encounter computers >and compilers that treat NaNs differently. Quite simply, I did not want >to expose all of this complexity in the header file. Ken, Thanks for your informative reply. There are systems VTK supports that don't use IEEE-754 numbers? Didn't know that... Out of curiosity, which? Similarly, where would VTK_HAS_ISNAN be 0? I was kinda hoping it was only with old compilers for which support was recently dropped. :) >If you plan to go through the trouble of moving that to the header file, >you should do performance tests to make sure that there is a clear >advantage to inlining the function. Certainly. As I said, I am in the middle of doing many profiling tests. >I've been surprised in the past to >find an inline function did not really perform any better than a >function call. The fact of the matter is that function calls are cheap >operations nowadays. And inlining can make code bigger, and thus bloat caches. Certainly there are trade offs. And making something faster in one usage can make it slower in another. Optimisation in the general case is tricky with a general and portable framework like VTK. :( OTOH, marking a method inline only makes it eligible for inline, it's not an obligation. One hopes that the compiler can make a good decision. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada **** Kenneth Moreland *** Sandia National Laboratories *********** *** *** *** email: kmorel at sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://www.cs.unm.edu/~kmorel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Wed Sep 15 13:28:34 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Wed, 15 Sep 2010 13:28:34 -0400 Subject: [vtk-developers] Crossing library boundaries Message-ID: I added a functionality to vtkArrowSource (in Graphics) that lets the user specify the end points of the arrow. It does this by aligning the default pair of points ( (0,0,0) and (1,0,0) ) with the user specified points (Point1 and Point2 (like in vtkLineSource) ) using a vtkLandmarkTransform (in Hybrid). I get linker errors when compiling - "undefined reference to 'vtkLandmarkTransform::XYZ". Is something that can/should be fixed in the CMakeLists.txt in /Graphics ? How are these situations typically handled? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.cole at kitware.com Wed Sep 15 13:32:07 2010 From: david.cole at kitware.com (David Cole) Date: Wed, 15 Sep 2010 13:32:07 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: Graphics cannot use stuff from Hybrid. Put a class in Hybrid that depends on both. On Wed, Sep 15, 2010 at 1:28 PM, David Doria > wrote: > I added a functionality to vtkArrowSource (in Graphics) that lets the user > specify the end points of the arrow. It does this by aligning the default > pair of points ( (0,0,0) and (1,0,0) ) with the user specified points > (Point1 and Point2 (like in vtkLineSource) ) using a vtkLandmarkTransform > (in Hybrid). I get linker errors when compiling - "undefined reference to > 'vtkLandmarkTransform::XYZ". Is something that can/should be fixed in the > CMakeLists.txt in /Graphics ? How are these situations typically handled? > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria+vtk at gmail.com Wed Sep 15 13:39:37 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Wed, 15 Sep 2010 13:39:37 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 1:32 PM, David Cole wrote: > Graphics cannot use stuff from Hybrid. > > Put a class in Hybrid that depends on both. > It's only a few lines - not worth a new class. But they're tricky lines, this why I don't want the user to have to know how to do this. It seems reasonable that a user should be able to specify the end points of an arrow (vtkArrowSource) (as well as vtkCylinderSource for that matter), so I think this should be added directly to the vtkArrowSource class. See what I mean? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Sep 15 13:46:35 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Sep 2010 13:46:35 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: I think there is an easier way than using a landmark transform, Bill On Wed, Sep 15, 2010 at 1:39 PM, David Doria wrote: > On Wed, Sep 15, 2010 at 1:32 PM, David Cole wrote: >> >> Graphics cannot use stuff from Hybrid. >> Put a class in Hybrid that depends on both. > > It's only a few lines - not worth a new class. But they're tricky lines, > this why I don't want the user to have to know how to do this. It seems > reasonable that a user should be able to specify the end points of an arrow > (vtkArrowSource) (as well as vtkCylinderSource for that matter), so I think > this should be added directly to the vtkArrowSource class. See what I mean? > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From david.gobbi at gmail.com Wed Sep 15 13:46:58 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 15 Sep 2010 11:46:58 -0600 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: The vtkLandmarkTransform should be moved to Filtering or Common. It is a math utility class that doesn't depend on anything outside of Common. It only went into Hybrid because Hybrid used to be the "Contrib" directory. David On Wed, Sep 15, 2010 at 11:39 AM, David Doria wrote: > On Wed, Sep 15, 2010 at 1:32 PM, David Cole wrote: >> >> Graphics cannot use stuff from Hybrid. >> Put a class in Hybrid that depends on both. > > It's only a few lines - not worth a new class. But they're tricky lines, > this why I don't want the user to have to know how to do this. It seems > reasonable that a user should be able to specify the end points of an arrow > (vtkArrowSource) (as well as vtkCylinderSource for that matter), so I think > this should be added directly to the vtkArrowSource class. See what I mean? > David From bill.lorensen at gmail.com Wed Sep 15 13:49:01 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Sep 2010 13:49:01 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: look here: http://vtk.org/Wiki/VTK/Examples/Cxx/GeometricObjects/OrientedArrow maybe not easier, but another way. On Wed, Sep 15, 2010 at 1:46 PM, Bill Lorensen wrote: > I think there is an easier way than using a landmark transform, > > Bill > > On Wed, Sep 15, 2010 at 1:39 PM, David Doria wrote: >> On Wed, Sep 15, 2010 at 1:32 PM, David Cole wrote: >>> >>> Graphics cannot use stuff from Hybrid. >>> Put a class in Hybrid that depends on both. >> >> It's only a few lines - not worth a new class. But they're tricky lines, >> this why I don't want the user to have to know how to do this. It seems >> reasonable that a user should be able to specify the end points of an arrow >> (vtkArrowSource) (as well as vtkCylinderSource for that matter), so I think >> this should be added directly to the vtkArrowSource class. See what I mean? >> 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://www.vtk.org/mailman/listinfo/vtk-developers >> >> >> > From jimcp at cox.net Wed Sep 15 14:01:28 2010 From: jimcp at cox.net (jimcp at cox.net) Date: Wed, 15 Sep 2010 14:01:28 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: Message-ID: <20100915140128.2OY11.1824100.imail@eastrmwml28> David, I have to agree that what you are describing is a HybridArrow. Consider that somehow the order of compilation has to be adhered to. And at present, Graphics are required to be build before any Hybrid can be build. So to use Hybrid content to create an arrow will have to be build along with the Hybrid library. Hope that helps, Jim ---- David Doria wrote: > On Wed, Sep 15, 2010 at 1:32 PM, David Cole wrote: > > > Graphics cannot use stuff from Hybrid. > > > > Put a class in Hybrid that depends on both. > > > > It's only a few lines - not worth a new class. But they're tricky lines, > this why I don't want the user to have to know how to do this. It seems > reasonable that a user should be able to specify the end points of an arrow > (vtkArrowSource) (as well as vtkCylinderSource for that matter), so I think > this should be added directly to the vtkArrowSource class. See what I mean? > > David From daviddoria+vtk at gmail.com Wed Sep 15 14:04:03 2010 From: daviddoria+vtk at gmail.com (David Doria) Date: Wed, 15 Sep 2010 14:04:03 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 1:49 PM, Bill Lorensen wrote: > look here: > http://vtk.org/Wiki/VTK/Examples/Cxx/GeometricObjects/OrientedArrow > > maybe not easier, but another way. > Bill, my method is here (the AlignRays function (not fully tested yet because of the linker errors) ): http://github.com/daviddoria/daviddoria-vtk/commit/e97738896ed41aa007424f9fefb5a5d2a9a0aa78 Jim, if David Gobbi is right and we can move vtkLandmarkTransform to Common then it would be fine to allow vtkArrowSource to accept a Point1 and Point2, right? David G, if we don't hear any screaming would you volunteer to verify my commit of moving vtkLandmarkTransform to Common (to github) before we push to VTK master? Thanks, David D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 15 14:19:08 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 15 Sep 2010 12:19:08 -0600 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 12:04 PM, David Doria wrote: > > Jim,?if David Gobbi is right and we can move vtkLandmarkTransform to Common > then it would be fine to allow vtkArrowSource to accept a Point1 and Point2, > right? If you need to generate a transform from two points, then you shouldn't be use vtkLandmarkTransform. There are far more efficient ways of doing it. See the code in vtkConeSource for setting the Direction of the cone, for instance. I recommend that you write code similar to that, instead of using vtkLandmarkTransform. > David G, if we don't hear any screaming would you volunteer to verify my > commit of moving vtkLandmarkTransform to Common (to github) before we push > to VTK master? Well, I'm still not sure if it belongs in Common or if it belongs in Filtering. I only want it to be moved once. - David From jimcp at cox.net Wed Sep 15 18:22:41 2010 From: jimcp at cox.net (Jim Peterson) Date: Wed, 15 Sep 2010 18:22:41 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: <4C914731.7060709@cox.net> David, In principle, I agree, if a function is truly isolated, and capable of being used globally it can be "moved up" in the library sequence, moving the vtkLandmarkTransform to common would do that. With the fact that vtkLandmarkTransform is an extension of the vtkLinearTransform which is in Common currently, I don't see a major issue. I would be very careful about this line of thinking though, continuing along this path will migrate everything to Common eventually. It might be worth someone's time to examine the Hybrid contents periodically to see if there is a more natural home for some contents. I suspect the Control library was renamed to Hybrid because of the cross library implementations that may be there. In reference to actually changing vtk, vtk is an enormous system, and again, I am outside my comfort zone in actual knowlege. Regarding the transforms themselves, I am not what I would call informed with the range of transforms present in vtk. I find 27 different transform classes across 5 libraries, with 14 in Common, 2 in Geovis, 4 in Graphics, 6 in Hybrid, and one in Rendering. I know for sure I have not directly used more than 2 or 3 myself. and as far as the vtkArrowSource, isn't it just a tube with a cone at the end? And are there any uses in any of the existing examples? What is so special about the straight line? if we are going to make something generally useful, shouldn't it be able to follow any line source (like a vtkTubeFilter) and "cap" the tube with a Cone? I appologize for ranting if that is what I am doing, and I admit it is kind of selfish, if this system keeps growing, I will never be able to get to the point that I have learned it. In software we too often have a solution that is desperately looking for a problem, and that generally leads to software bloat and additional complexity. HTH Jim David Doria wrote: > On Wed, Sep 15, 2010 at 1:49 PM, Bill Lorensen > > wrote: > > look here: > http://vtk.org/Wiki/VTK/Examples/Cxx/GeometricObjects/OrientedArrow > > maybe not easier, but another way. > > > Bill, my method is here (the AlignRays function (not fully tested yet > because of the linker errors) ): > http://github.com/daviddoria/daviddoria-vtk/commit/e97738896ed41aa007424f9fefb5a5d2a9a0aa78 > > Jim, if David Gobbi is right and we can move vtkLandmarkTransform to > Common then it would be fine to allow vtkArrowSource to accept a > Point1 and Point2, right? > > David G, if we don't hear any screaming would you volunteer to verify > my commit of moving vtkLandmarkTransform to Common (to github) before > we push to VTK master? > > Thanks, > > David D. > ------------------------------------------------------------------------ > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > From bill.lorensen at gmail.com Wed Sep 15 19:28:13 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Sep 2010 19:28:13 -0400 Subject: [vtk-developers] Crossing library boundaries In-Reply-To: References: Message-ID: I agree with David G. The code is ConeSource is straight forward. Perhaps we should add a set direction to ArrowSource and possibly other sources. Maybe a helper class to compute the transform, Bill On Wed, Sep 15, 2010 at 2:19 PM, David Gobbi wrote: > On Wed, Sep 15, 2010 at 12:04 PM, David Doria wrote: >> >> Jim,?if David Gobbi is right and we can move vtkLandmarkTransform to Common >> then it would be fine to allow vtkArrowSource to accept a Point1 and Point2, >> right? > > If you need to generate a transform from two points, then you > shouldn't be use vtkLandmarkTransform. ? There are far more efficient > ways of doing it. ?See the code in vtkConeSource for setting the > Direction of the cone, for instance. ?I recommend that you write code > similar to that, instead of using vtkLandmarkTransform. > >> David G, if we don't hear any screaming would you volunteer to verify my >> commit of moving vtkLandmarkTransform to Common (to github) before we push >> to VTK master? > > Well, I'm still not sure if it belongs in Common or if it belongs in > Filtering. ?I only want it to be moved once. > > ?- David > From emonson at cs.duke.edu Thu Sep 16 11:41:12 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Thu, 16 Sep 2010 11:41:12 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <534C14F1-94F7-4D3B-A6EF-DD7771B2A63A@cs.duke.edu> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> <4C86C49F.9020502@sandia.gov> <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> <534C14F1-94F7-4D3B-A6EF-DD7771B2A63A@cs.duke.edu> Message-ID: <5BA8EDC9-5D1E-4A55-845A-D40076F59A47@cs.duke.edu> Hey David, So far everything is working great -- wonderful job, again!! Thanks, -Eric On Sep 14, 2010, at 2:46 PM, Eric E. Monson wrote: > Thanks, David, > > I'll take a look at it in the next day or two and let you know if I have any problems. I appreciate you addressing this so quickly. > > Talk to you later, > -Eric > > > On Sep 14, 2010, at 9:27 AM, David Gobbi wrote: > >> Hi Eric, >> >> This morning I added some code that allows the python wrappers to >> resolve typedefs, so those missing vtkArray methods are wrapped again. >> Let me know if the new code works for you. >> >> David >> >> >> On Tue, Sep 7, 2010 at 7:47 PM, Eric E. Monson wrote: >>> On Sep 7, 2010, at 7:02 PM, Timothy Shead wrote: >>> >>>> On 9/7/10 1:38 PM, David Gobbi wrote: >>>>> I'm fine with that. Wrapper typedef support is something that I had >>>>> planned from the start, I just didn't expect that it would be needed >>>>> so soon. What do you think of Eric's GetDimensionRange() method >>>>> suggestion? I'd prefer that there are always named-method >>>>> alternatives to [ ] operator methods. >>>> >>>> Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. >>> >>> Ah, thank you -- I hadn't seen the vtkArray::GetExtent() option. I can get the values from that for now. >>> >>> -Eric >>> >>> > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers From david.gobbi at gmail.com Thu Sep 16 11:46:22 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 16 Sep 2010 09:46:22 -0600 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: <5BA8EDC9-5D1E-4A55-845A-D40076F59A47@cs.duke.edu> References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> <4C86C49F.9020502@sandia.gov> <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> <534C14F1-94F7-4D3B-A6EF-DD7771B2A63A@cs.duke.edu> <5BA8EDC9-5D1E-4A55-845A-D40076F59A47@cs.duke.edu> Message-ID: Hi Eric, If you have time, I'd love it if you could email me some code snippets. There still aren't any tests for vtkArray in Python. David On Thu, Sep 16, 2010 at 9:41 AM, Eric E. Monson wrote: > Hey David, > > So far everything is working great -- wonderful job, again!! > > Thanks, > -Eric > > > On Sep 14, 2010, at 2:46 PM, Eric E. Monson wrote: > >> Thanks, David, >> >> I'll take a look at it in the next day or two and let you know if I have any problems. I appreciate you addressing this so quickly. >> >> Talk to you later, >> -Eric >> >> >> On Sep 14, 2010, at 9:27 AM, David Gobbi wrote: >> >>> Hi Eric, >>> >>> This morning I added some code that allows the python wrappers to >>> resolve typedefs, so those missing vtkArray methods are wrapped again. >>> Let me know if the new code works for you. >>> >>> David >>> >>> >>> On Tue, Sep 7, 2010 at 7:47 PM, Eric E. Monson wrote: >>>> On Sep 7, 2010, at 7:02 PM, Timothy Shead wrote: >>>> >>>>> On 9/7/10 1:38 PM, David Gobbi wrote: >>>>>> I'm fine with that. ?Wrapper typedef support is something that I had >>>>>> planned from the start, I just didn't expect that it would be needed >>>>>> so soon. ?What do you think of Eric's GetDimensionRange() method >>>>>> suggestion? ?I'd prefer that there are always named-method >>>>>> alternatives to [ ] operator methods. >>>>> >>>>> Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. >>>> >>>> Ah, thank you -- I hadn't seen the vtkArray::GetExtent() option. I can get the values from that for now. >>>> >>>> -Eric >>>> >>>> >> >> _______________________________________________ >> 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://www.vtk.org/mailman/listinfo/vtk-developers > > From emonson at cs.duke.edu Thu Sep 16 12:10:53 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Thu, 16 Sep 2010 12:10:53 -0400 Subject: [vtk-developers] vtkArrayExtents (and others) Python wrapping In-Reply-To: References: <0CD0EDB2-66C1-4F47-BD71-DFF9AC0A4F57@cs.duke.edu> <5424F12B-8658-4898-A951-B411B3AF398B@cs.duke.edu> <87221F0F-6789-4EBA-BE2B-B92489427EDB@cs.duke.edu> <4C869272.5020201@sandia.gov> <4C86C49F.9020502@sandia.gov> <4912D0D0-D896-4C7D-85C0-8EC89299923C@cs.duke.edu> <534C14F1-94F7-4D3B-A6EF-DD7771B2A63A@cs.duke.edu> <5BA8EDC9-5D1E-4A55-845A-D40076F59A47@cs.duke.edu> Message-ID: <639A1547-736A-4BD2-B30F-F686F51A9ED6@cs.duke.edu> Right now I'm only "testing it out" in the sense that I've been translating a few of the Titan text analysis tests into Python to see how they work wrapped, and some of them use the vtkArray methods in one or two spots. If I write anything that pushes on those classes a bit more, or if I have time to convert over any of the vtkArray cxx tests to Python, I'll definitely pass them along. Talk to you later, -Eric On Sep 16, 2010, at 11:46 AM, David Gobbi wrote: > Hi Eric, > > If you have time, I'd love it if you could email me some code > snippets. There still aren't any tests for vtkArray in Python. > > David > > On Thu, Sep 16, 2010 at 9:41 AM, Eric E. Monson wrote: >> Hey David, >> >> So far everything is working great -- wonderful job, again!! >> >> Thanks, >> -Eric >> >> >> On Sep 14, 2010, at 2:46 PM, Eric E. Monson wrote: >> >>> Thanks, David, >>> >>> I'll take a look at it in the next day or two and let you know if I have any problems. I appreciate you addressing this so quickly. >>> >>> Talk to you later, >>> -Eric >>> >>> >>> On Sep 14, 2010, at 9:27 AM, David Gobbi wrote: >>> >>>> Hi Eric, >>>> >>>> This morning I added some code that allows the python wrappers to >>>> resolve typedefs, so those missing vtkArray methods are wrapped again. >>>> Let me know if the new code works for you. >>>> >>>> David >>>> >>>> >>>> On Tue, Sep 7, 2010 at 7:47 PM, Eric E. Monson wrote: >>>>> On Sep 7, 2010, at 7:02 PM, Timothy Shead wrote: >>>>> >>>>>> On 9/7/10 1:38 PM, David Gobbi wrote: >>>>>>> I'm fine with that. Wrapper typedef support is something that I had >>>>>>> planned from the start, I just didn't expect that it would be needed >>>>>>> so soon. What do you think of Eric's GetDimensionRange() method >>>>>>> suggestion? I'd prefer that there are always named-method >>>>>>> alternatives to [ ] operator methods. >>>>>> >>>>>> Makes sense, although I would strongly prefer vtkArrayExtents::GetExtent(...), for consistency with vtkArray::GetExtent(...), which returns the same value. >>>>> >>>>> Ah, thank you -- I hadn't seen the vtkArray::GetExtent() option. I can get the values from that for now. >>>>> >>>>> -Eric >>>>> >>>>> >>> >>> _______________________________________________ >>> 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://www.vtk.org/mailman/listinfo/vtk-developers >> >> From david.gobbi at gmail.com Fri Sep 17 09:59:57 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 17 Sep 2010 07:59:57 -0600 Subject: [vtk-developers] Announcing new features of python wrappers Message-ID: Hi All, I pushed several improvements to the python wrappers this week. 1) Multi-dimensional array arguments. This adds several vtkMath methods that were not previously wrapped. When passing an array, you can use either a numpy array or a nested list. Values are returned in the array, just as they would be in C++. 2) Reference args. This adds several cell methods that were not previously wrapped. To use these methods, pass a vtk.mutable() object as the arg, and the python wrappers will read the value and then write to it. The 'mutable' object is a new VTK-specific python numeric type that supports assignment. 3) size_t and ssize_t args. These were not wrapped previously. 4) Typedef'd types as args. For now, this is only supported for wrapping within the VTK source tree. I added all VTK typedefs to the vtkKitHierarchy.txt files, and these hierarchy files are not yet exported. 5) Optional args. Any args that are optional in C++ are now optional in Python. 6) Unsigned integer types for array arguments (only for python 2.3 and higher). 7) This change is a few weeks old, but it's worth mentioning: array args of unknown size (like double[] or *double) are wrapped for the SetTuple/GetTuple methods of vtkDataArray and its subclasses. David From david.gobbi at gmail.com Fri Sep 17 11:15:05 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 17 Sep 2010 09:15:05 -0600 Subject: [vtk-developers] WrapVTK - export class interfaces as XML Message-ID: On a note that is related to the wrappers, I've been keeping the VTK wrapper-parser in sync with my WrapVTK project. http://github.com/dgobbi/WrapVTK WrapVTK is a cmake-driven package that generates XML descriptions of all the VTK classes. One of the more interesting things that it does is extract "properties" from the class interface, i.e. for every set/get/add/remove/on/off method it determines the name of the "property" from the method name and then groups the methods accordingly. The properties are listed in the XML files (and available through C data structures). I'm developing WrapVTK for use in a Simulink-based visual programming interface for VTK that some students have been working on. David From daviddoria at gmail.com Fri Sep 17 15:47:26 2010 From: daviddoria at gmail.com (David Doria) Date: Fri, 17 Sep 2010 15:47:26 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray Message-ID: I've found it very troublesome not to be able to cast similar typed arrays back and forth. For example, vtkIdTypeArray as vtkIntArray, or vtkFloatArray as vtkDoubleArray. Here is my usual process: 1) Use a filter that produces an array on the output 2) Write a file of the filter output 3) Open Paraview and open the file to figure out what the array name that was created is and what type it is 4) Note that paraview shows a data array named "RegionId" (I used vtkPolyDataConnectivityFilter) and that its Data Type is "int" (very confusing, because it is actually vtkIdType...) 5) Go back to my VTK code and do this: vtkIntArray::SafeDownCast(filter->GetOutput()->GetArray("RegionId"))->DoSomething(); 6) My program starts crashing unexpectedly. 7) I go back to this line and do vtkIntArray* array = vtkIntArray::SafeDownCast(filter->GetOutput()->GetArray("RegionId")); std::cout << array << std::endl; and notice that it is NULL. 8) Look through vtkPolyDataConnectivity.cxx and realize that this array is a vtkIdTypeArray It would make a lot of sense from a usability standpoint to allow reasonable casts and if they aren't exactly right provide a warning of what happened. In this case, "Warning, you have casted a vtkIdTypeArray to a vtkIntArray", or in other cases, "Warning, you have casted a vtkFloatArray to a vtkDoubleArray". I would even advocate that it is ok even to do "Warning: You have casted a vtkDoubleArray to a vtkFloatArray, some loss of precision may occur." Thoughts? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.cole at kitware.com Fri Sep 17 15:50:23 2010 From: david.cole at kitware.com (David Cole) Date: Fri, 17 Sep 2010 15:50:23 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: That's not a C++ cast, that's a transformation operation.... All the array classes are siblings of each other, aren't they? On Fri, Sep 17, 2010 at 3:47 PM, David Doria wrote: > I've found it very troublesome not to be able to cast similar typed arrays > back and forth. > > For example, vtkIdTypeArray as vtkIntArray, or vtkFloatArray as > vtkDoubleArray. > > Here is my usual process: > > 1) Use a filter that produces an array on the output > > 2) Write a file of the filter output > > 3) Open Paraview and open the file to figure out what the array name that > was created is and what type it is > > 4) Note that paraview shows a data array named "RegionId" (I used > vtkPolyDataConnectivityFilter) and that its Data Type is "int" (very > confusing, because it is actually vtkIdType...) > > 5) Go back to my VTK code and do this: > > > vtkIntArray::SafeDownCast(filter->GetOutput()->GetArray("RegionId"))->DoSomething(); > > 6) My program starts crashing unexpectedly. > > 7) I go back to this line and do > vtkIntArray* array = > vtkIntArray::SafeDownCast(filter->GetOutput()->GetArray("RegionId")); > std::cout << array << std::endl; > > and notice that it is NULL. > > 8) Look through vtkPolyDataConnectivity.cxx and realize that this array is > a vtkIdTypeArray > > It would make a lot of sense from a usability standpoint to allow > reasonable casts and if they aren't exactly right provide a warning of what > happened. In this case, "Warning, you have casted a vtkIdTypeArray to a > vtkIntArray", or in other cases, "Warning, you have casted a vtkFloatArray > to a vtkDoubleArray". I would even advocate that it is ok even to do > "Warning: You have casted a vtkDoubleArray to a vtkFloatArray, some loss of > precision may occur." > > Thoughts? > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria at gmail.com Fri Sep 17 15:53:51 2010 From: daviddoria at gmail.com (David Doria) Date: Fri, 17 Sep 2010 15:53:51 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: On Fri, Sep 17, 2010 at 3:50 PM, David Cole wrote: > That's not a C++ cast, that's a transformation operation.... > > All the array classes are siblings of each other, aren't they? > > Maybe my terminology is off, but whatever it is called I feel that it should work and it currently doesn't :) Yes, they are all siblings. Are you recommending first SafeDownCasting to a vtkDataArray, checking the type, and then performing the appropriate SafeDownCast? That seems like a lot of trouble, no? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.cole at kitware.com Fri Sep 17 15:57:29 2010 From: david.cole at kitware.com (David Cole) Date: Fri, 17 Sep 2010 15:57:29 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: You cannot cast from one sibling class to another. It's not an is-a relationship. You can only cast up or down the hierarchy according to what the class of the object actually is. To go from vtkDoubleArray to vtkFloatArray, you'd have to create a new vtkFloatArray and then copy its elements over one by one, casting each element. Casting only works up and down the parent class chain. If casting is required, then there is a flaw in a design somewhere. In general, it shouldn't be required for well-designed programs. On Fri, Sep 17, 2010 at 3:53 PM, David Doria wrote: > On Fri, Sep 17, 2010 at 3:50 PM, David Cole wrote: > >> That's not a C++ cast, that's a transformation operation.... >> >> All the array classes are siblings of each other, aren't they? >> >> > Maybe my terminology is off, but whatever it is called I feel that it > should work and it currently doesn't :) > > Yes, they are all siblings. Are you recommending first SafeDownCasting to a > vtkDataArray, checking the type, and then performing the appropriate > SafeDownCast? That seems like a lot of trouble, no? > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 17 16:03:54 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 17 Sep 2010 14:03:54 -0600 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: Hi David, I think you misunderstand what "SafeDownCast" does. After every SafeDownCast(), you must check the result to make sure that it isn't NULL. That is what dynamic casting is all about: it is an _attempt_ to do a cast when you aren't sure if the object is of the correct type. You can write code that is robust to a large number of array types by adding a "switch" statement. If you combine the switch with a templated function, then you will end up with the same mechanism that VTK's image filters use to deal with arrays of different types. David On Fri, Sep 17, 2010 at 1:53 PM, David Doria wrote: > On Fri, Sep 17, 2010 at 3:50 PM, David Cole wrote: >> >> That's not a C++ cast, that's a transformation operation.... >> All the array classes are siblings of each other, aren't they? >> > > Maybe my terminology is off, but whatever it is called I feel that it should > work and it currently doesn't :) > Yes, they are all siblings. Are you recommending first SafeDownCasting to a > vtkDataArray, checking the type, and then performing the appropriate > SafeDownCast? That seems like a lot of trouble, no? > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From david.gobbi at gmail.com Fri Sep 17 17:32:49 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 17 Sep 2010 15:32:49 -0600 Subject: [vtk-developers] Python wrappers and pointers Message-ID: Hi all, I've been struggling for a while to think of the best way to wrap pointers in python. It is a difficult thing to do safely, because it is hard to know the size of the memory area that is pointed to, and also because the memory might be freed at an inopportune time, leaving the user with an invalid pointer. The most sensible idea that I've come up with so far is to make a new python array type that is a proxy to a block of memory existing within VTK, usually within a vtkDataArray but potentially from anywhere. This "proxy array" would be much like a numpy array but with vtk-specific features: 1) it would have a weak pointer to the underlying VTK object, to allow it to check that the VTK object still exists before each operation 2) it would store pointers to the Ivars where the VTK object stores the memory pointer and arrays size, so it can check if these change 3) it would store the data type and the dimensions 4) the dimensions would be reshapeable, as long as the full size (i.e. product of all dimensions) remained the same 5) it would support slicing The first and most basic way to get/set this array would be via the SetArray/GetArray methods of the vtkDataArray subclasses. Note that the GetArray() method doesn't exist yet, but I would add it. Eventually all the pointer methods in the vtkAbstractArray and vtkArray hierarchies would be supported, and perhaps those in vtkCellArray and the vtkDataSet. The extensiveness would only depend on the amount of hinting for the wrappers. Any pointer in VTK could be represented either as one of these array objects, or as a slice. All of the checks done in 1 and 2 above would make this a fairly safe mechanism for accessing internal VTK memory. For multithreading, thread safety would be the responsibility of the application developer, i.e. no different from using the VTK objects themselves. The name of the type would be vtk.array() and it would support python's sequence protocols and buffer protocols. Any thoughts on this? Has anyone else done something similar? - David From pat.marion at kitware.com Fri Sep 17 17:42:56 2010 From: pat.marion at kitware.com (pat marion) Date: Fri, 17 Sep 2010 17:42:56 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: David, Instead of saving a file and opening it in paraview, you could try: filter->GetOutput()->Print(cout); This will display all the point & cell arrays on the output and their names and data types. Make sure you have updated the filter first. Also, if you notice that SafeDownCast has failed, you can do a debug print to get the correct class type: cout << filter->GetOutput()->GetArray("RegionId")->GetClassName() << endl; this would print: vtkIdTypeArray GetClassName is great for debugging, but I wouldn't recommend it for comparisons. For example, instead of: if (array->GetClassName() == std::string("vtkIdTypeArray")) cout << "It's an id type array"; it is preferable to use: if (vtkIdTypeArray::SafeDownCast(array)) cout << "It's an id type array"; The compiler can error check a SafeDownCast statement, but can't catch a typo in a string comparison. Pat On Fri, Sep 17, 2010 at 4:03 PM, David Gobbi wrote: > Hi David, > > I think you misunderstand what "SafeDownCast" does. > After every SafeDownCast(), you must check the result > to make sure that it isn't NULL. That is what dynamic > casting is all about: it is an _attempt_ to do a cast when > you aren't sure if the object is of the correct type. > > You can write code that is robust to a large number of > array types by adding a "switch" statement. If you combine > the switch with a templated function, then you will > end up with the same mechanism that VTK's image filters > use to deal with arrays of different types. > > David > > > On Fri, Sep 17, 2010 at 1:53 PM, David Doria wrote: > > On Fri, Sep 17, 2010 at 3:50 PM, David Cole > wrote: > >> > >> That's not a C++ cast, that's a transformation operation.... > >> All the array classes are siblings of each other, aren't they? > >> > > > > Maybe my terminology is off, but whatever it is called I feel that it > should > > work and it currently doesn't :) > > Yes, they are all siblings. Are you recommending first SafeDownCasting to > a > > vtkDataArray, checking the type, and then performing the appropriate > > SafeDownCast? That seems like a lot of trouble, no? > > 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 17 17:58:02 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 17 Sep 2010 15:58:02 -0600 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: Also, don't forget that you can convert an array to a different type via a DeepCopy. vtkIdTypeArray *newArray = vtkIdTypeArray::New(); newArray->DeepCopy(array_of_unknown_type); I get the feeling that this is what you wanted in the first place. David On Fri, Sep 17, 2010 at 3:42 PM, pat marion wrote: > David, > > Instead of saving a file and opening it in paraview, you could try: > > ????? filter->GetOutput()->Print(cout); > > This will display all the point & cell arrays on the output and their names > and data types.? Make sure you have updated the filter first.? Also, if you > notice that SafeDownCast has failed, you can do a debug print to get the > correct class type: > > ?????? cout << filter->GetOutput()->GetArray("RegionId")->GetClassName() << > endl; > > this would print: vtkIdTypeArray > > GetClassName is great for debugging, but I wouldn't recommend it for > comparisons.? For example, instead of: > > ????? if (array->GetClassName() == std::string("vtkIdTypeArray")) cout << > "It's an id type array"; > > it is preferable to use: > > ????? if (vtkIdTypeArray::SafeDownCast(array)) cout << "It's an id type > array"; > > The compiler can error check a SafeDownCast statement, but can't catch a > typo in a string comparison. > > Pat > > > On Fri, Sep 17, 2010 at 4:03 PM, David Gobbi wrote: >> >> Hi David, >> >> I think you misunderstand what "SafeDownCast" does. >> After every SafeDownCast(), you must check the result >> to make sure that it isn't NULL. ?That is what dynamic >> casting is all about: it is an _attempt_ to do a cast when >> you aren't sure if the object is of the correct type. >> >> You can write code that is robust to a large number of >> array types by adding a "switch" statement. ?If you combine >> the switch with a templated function, then you will >> end up with the same mechanism that VTK's image filters >> use to deal with arrays of different types. >> >> ?David >> >> >> On Fri, Sep 17, 2010 at 1:53 PM, David Doria wrote: >> > On Fri, Sep 17, 2010 at 3:50 PM, David Cole >> > wrote: >> >> >> >> That's not a C++ cast, that's a transformation operation.... >> >> All the array classes are siblings of each other, aren't they? >> >> >> > >> > Maybe my terminology is off, but whatever it is called I feel that it >> > should >> > work and it currently doesn't :) >> > Yes, they are all siblings. Are you recommending first SafeDownCasting >> > to a >> > vtkDataArray, checking the type, and then performing the appropriate >> > SafeDownCast? That seems like a lot of trouble, no? >> > 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers >> > > From jimcp at cox.net Sat Sep 18 09:54:15 2010 From: jimcp at cox.net (Jim Peterson) Date: Sat, 18 Sep 2010 09:54:15 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: Message-ID: <4C94C487.8090303@cox.net> Also, The vtkIDType is documented as: vtkIdType is the integer type used for point and cell identification. This type may be either 32-bit or 64-bit, depending on whether VTK_USE_64BIT_IDS is defined. So I believe SafeDownCast is doing it's job well to reject the transform from IDType to INT. Jim David Gobbi wrote: > Hi David, > > I think you misunderstand what "SafeDownCast" does. > After every SafeDownCast(), you must check the result > to make sure that it isn't NULL. That is what dynamic > casting is all about: it is an _attempt_ to do a cast when > you aren't sure if the object is of the correct type. > > You can write code that is robust to a large number of > array types by adding a "switch" statement. If you combine > the switch with a templated function, then you will > end up with the same mechanism that VTK's image filters > use to deal with arrays of different types. > > David > > > On Fri, Sep 17, 2010 at 1:53 PM, David Doria wrote: > >> On Fri, Sep 17, 2010 at 3:50 PM, David Cole wrote: >> >>> That's not a C++ cast, that's a transformation operation.... >>> All the array classes are siblings of each other, aren't they? >>> >>> >> Maybe my terminology is off, but whatever it is called I feel that it should >> work and it currently doesn't :) >> Yes, they are all siblings. Are you recommending first SafeDownCasting to a >> vtkDataArray, checking the type, and then performing the appropriate >> SafeDownCast? That seems like a lot of trouble, no? >> 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > > > From david.gobbi at gmail.com Sat Sep 18 10:59:53 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 18 Sep 2010 08:59:53 -0600 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: <4C94C487.8090303@cox.net> References: <4C94C487.8090303@cox.net> Message-ID: On Sat, Sep 18, 2010 at 7:54 AM, Jim Peterson wrote: > So I believe SafeDownCast is doing it's job well to reject the transform > from IDType to INT. SafeDownCast() is not a transformative operation. It is a pointer cast. From jimcp at cox.net Sat Sep 18 13:10:50 2010 From: jimcp at cox.net (Jim Peterson) Date: Sat, 18 Sep 2010 13:10:50 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: <4C94C487.8090303@cox.net> Message-ID: <4C94F29A.7040503@cox.net> Sorry, and absolutely correct, I should have said "refuse to interpret....". Thanks, David Gobbi wrote: > On Sat, Sep 18, 2010 at 7:54 AM, Jim Peterson wrote: > > >> So I believe SafeDownCast is doing it's job well to reject the transform >> from IDType to INT. >> > > SafeDownCast() is not a transformative operation. It is a pointer cast. > > From david.gobbi at gmail.com Sat Sep 18 13:44:49 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 18 Sep 2010 11:44:49 -0600 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: <4C94F29A.7040503@cox.net> References: <4C94C487.8090303@cox.net> <4C94F29A.7040503@cox.net> Message-ID: Just to make it clear to everyone on the list about SafeDownCast: SafeDownCast() allows or disallows casts based on the hierarchy and nothing else. It refuses to cast a "vtkIdTypeArray *" to a "vtkIntArray *" is because vtkIntArray is not a subclass of vtkIdTypeArray. Also, as I said before, it does not "convert" anything. It merely reinterprets one object pointer type as a different object pointer type. David From bill.lorensen at gmail.com Sat Sep 18 18:20:45 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 18 Sep 2010 18:20:45 -0400 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: <4C94C487.8090303@cox.net> <4C94F29A.7040503@cox.net> Message-ID: David, Why are we using SafeDownCast rather than c++'s dynamic_cast? Bill On Sat, Sep 18, 2010 at 1:44 PM, David Gobbi wrote: > Just to make it clear to everyone on the list about SafeDownCast: > > SafeDownCast() allows or disallows casts based on the hierarchy and > nothing else. > > It refuses to cast a "vtkIdTypeArray *" to a "vtkIntArray *" is > because vtkIntArray is not a subclass of vtkIdTypeArray. ?Also, as I > said before, it does not "convert" anything. ?It merely reinterprets > one object pointer type as a different object pointer type. > > ?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://www.vtk.org/mailman/listinfo/vtk-developers > > From david.gobbi at gmail.com Sat Sep 18 19:29:25 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 18 Sep 2010 17:29:25 -0600 Subject: [vtk-developers] Casting vtkIntArray vs vtkIdTypeArray In-Reply-To: References: <4C94C487.8090303@cox.net> <4C94F29A.7040503@cox.net> Message-ID: The g++ dynamic_cast has problems with shared object boundaries. Specifically, if you dlopen() a shared object, you won't be able to do any rtti between it and any other code unless special conditions are met. http://gcc.gnu.org/faq.html#dso I have personally run into this with loading custom ITK plugins into MATLAB. If I load one plugin, it works fine, but I cannot load multiple plugins and pass an ITK object pointer from one plugin to another. Everything works fine until the first time an rtti is attempted, and then the program crashes. David On Sat, Sep 18, 2010 at 4:20 PM, Bill Lorensen wrote: > David, > > Why are we using SafeDownCast rather than c++'s dynamic_cast? > > Bill > > On Sat, Sep 18, 2010 at 1:44 PM, David Gobbi wrote: >> Just to make it clear to everyone on the list about SafeDownCast: >> >> SafeDownCast() allows or disallows casts based on the hierarchy and >> nothing else. >> >> It refuses to cast a "vtkIdTypeArray *" to a "vtkIntArray *" is >> because vtkIntArray is not a subclass of vtkIdTypeArray. ?Also, as I >> said before, it does not "convert" anything. ?It merely reinterprets >> one object pointer type as a different object pointer type. >> >> ?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://www.vtk.org/mailman/listinfo/vtk-developers >> >> > From emonson at cs.duke.edu Mon Sep 20 11:46:23 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Mon, 20 Sep 2010 11:46:23 -0400 Subject: [vtk-developers] about vtk python bindings and Qt In-Reply-To: <201009161034.52508.clinton@elemtech.com> References: <201009161004.12449.clinton@elemtech.com> <4C9240AF.5010902@inogs.it> <201009161034.52508.clinton@elemtech.com> Message-ID: <718C5D06-DFDE-4FC3-B8F1-C4D374798993@cs.duke.edu> Hey Clint, Just in case this will be helpful to you in developing the PythonSIP install rules. I know it's a bit rambling, but hopefully it will make some sense. On OS X, without the new SIP stuff, I usually don't do a "make instal" into /usr/local, but I do go to [vtk_src]/build/Wrapping/Python and do a "sudo python setup.py install", which puts all of the VTK Python stuff in an egg inside of my site-packages so that I don't have to set the PYTHONPATH at all, but can still "import vtk". With your SIP stuff, to make "import vtk" work without explicitly setting the PYTHONPATH env variable, I have to copy both libvtkQtPython.so and QVTKPython.so to the site-packages/VTK-5.7.0-py2.6.egg/vtk directory. But, somehow with the way that QVTKPython.so imports other modules, even if all of the *PythonSIP.so libraries are sitting in the same directory as the *Python.so files, they're not "seen" when qvtk.py tries to run "from QVTKPython import *". (I get a LinkError: No module named vtkFilteringPythonSIP.) The *PythonSIP.so libraries seem to need to be in the PYTHONPATH for "import vtk" to work and really import QVTKWidget. I can do a bit of a hack and copy all of them into the site-packages/VTK-5.7.0-py2.6.egg/ directory, which is added to the PYTHONPATH by setup tools, but that seems like a non-standard place to put them. One of the main reasons I bring this up is that it also impacts me when I try to create a standalone application bundle with my PyQt/VTK work. I've been using bundlebuilder and CMake's fixup_bundle to create the app bundles, and there, too, the only way I've figured out how to make it work with QVTKWidget is to put all of the *PythonSIP.so libraries in sort of a non-standard place (not with the rest of the VTK *Python.so files) so they'll be "seen". As you can tell, I'm not an expert in any of this, but I guess I'm just passing it along in case it will either help with making install rules, or in case there is some other way of coding the SIP stuff so that the *Python.so and *PythonSIP.so files could all be installed in the same spot. Thanks for putting up with my ramble, and for all the good work getting QVTKWidget wrapped. -Eric ------------------------------------------------------ Eric E Monson Duke Visualization Technology Group On Sep 16, 2010, at 12:34 PM, Clinton Stimpson wrote: > > Ok, I see that it is installing libvtkQtPython to the wrong location. > As a workaround until it is fixed, you can add /usr/local/lib/vtk-5.7/ to your > PYTHONPATH. > > Clint > > On Thursday, September 16, 2010 10:07:11 am Nicola Creati wrote: >> This is the error: >> >> Traceback (most recent call last): >> File "", line 1, in >> File >> "/usr/local/lib/python2.6/dist-packages/VTK-5.7.0-py2.6.egg/vtk/qvtk.py", >> line 8, in >> from libvtkQtPython import * >> ImportError: No module named libvtkQtPython >> >> >> My libvtkQtPython.so and libvtkQtPythonD.so are located in >> /usr/local/lib/vtk-5.7/. >> >> Nicola From clinton at elemtech.com Mon Sep 20 11:55:02 2010 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 20 Sep 2010 09:55:02 -0600 Subject: [vtk-developers] about vtk python bindings and Qt In-Reply-To: <718C5D06-DFDE-4FC3-B8F1-C4D374798993@cs.duke.edu> References: <201009161034.52508.clinton@elemtech.com> <718C5D06-DFDE-4FC3-B8F1-C4D374798993@cs.duke.edu> Message-ID: <201009200955.02652.clinton@elemtech.com> Yes, I've come across the issues you see. I've got a patch to make it work from a "make install" but it breaks when run from a build tree, which also means it breaks tests. Unfortunately, SIP embeds the name of dependent modules in binaries, so if I choose "vtk.vtkCommonPythonSIP" it works when installed. If I choose "vtkCommonPythonSIP" it works in the build tree. Clint On Monday, September 20, 2010 09:46:23 am Eric E. Monson wrote: > Hey Clint, > > Just in case this will be helpful to you in developing the PythonSIP > install rules. I know it's a bit rambling, but hopefully it will make some > sense. > > On OS X, without the new SIP stuff, I usually don't do a "make instal" into > /usr/local, but I do go to [vtk_src]/build/Wrapping/Python and do a "sudo > python setup.py install", which puts all of the VTK Python stuff in an egg > inside of my site-packages so that I don't have to set the PYTHONPATH at > all, but can still "import vtk". > > With your SIP stuff, to make "import vtk" work without explicitly setting > the PYTHONPATH env variable, I have to copy both libvtkQtPython.so and > QVTKPython.so to the site-packages/VTK-5.7.0-py2.6.egg/vtk directory. > > But, somehow with the way that QVTKPython.so imports other modules, even if > all of the *PythonSIP.so libraries are sitting in the same directory as > the *Python.so files, they're not "seen" when qvtk.py tries to run "from > QVTKPython import *". (I get a LinkError: No module named > vtkFilteringPythonSIP.) The *PythonSIP.so libraries seem to need to be in > the PYTHONPATH for "import vtk" to work and really import QVTKWidget. I > can do a bit of a hack and copy all of them into the > site-packages/VTK-5.7.0-py2.6.egg/ directory, which is added to the > PYTHONPATH by setup tools, but that seems like a non-standard place to put > them. > > One of the main reasons I bring this up is that it also impacts me when I > try to create a standalone application bundle with my PyQt/VTK work. I've > been using bundlebuilder and CMake's fixup_bundle to create the app > bundles, and there, too, the only way I've figured out how to make it work > with QVTKWidget is to put all of the *PythonSIP.so libraries in sort of a > non-standard place (not with the rest of the VTK *Python.so files) so > they'll be "seen". > > As you can tell, I'm not an expert in any of this, but I guess I'm just > passing it along in case it will either help with making install rules, or > in case there is some other way of coding the SIP stuff so that the > *Python.so and *PythonSIP.so files could all be installed in the same > spot. > > Thanks for putting up with my ramble, and for all the good work getting > QVTKWidget wrapped. > > -Eric > > ------------------------------------------------------ > Eric E Monson > Duke Visualization Technology Group > > On Sep 16, 2010, at 12:34 PM, Clinton Stimpson wrote: > > Ok, I see that it is installing libvtkQtPython to the wrong location. > > As a workaround until it is fixed, you can add /usr/local/lib/vtk-5.7/ to > > your PYTHONPATH. > > > > Clint > > > > On Thursday, September 16, 2010 10:07:11 am Nicola Creati wrote: > >> This is the error: > >> > >> Traceback (most recent call last): > >> File "", line 1, in > >> File > >> > >> "/usr/local/lib/python2.6/dist-packages/VTK-5.7.0-py2.6.egg/vtk/qvtk.py" > >> , line 8, in > >> > >> from libvtkQtPython import * > >> > >> ImportError: No module named libvtkQtPython > >> > >> > >> My libvtkQtPython.so and libvtkQtPythonD.so are located in > >> /usr/local/lib/vtk-5.7/. > >> > >> Nicola From emonson at cs.duke.edu Mon Sep 20 16:02:06 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Mon, 20 Sep 2010 16:02:06 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize Message-ID: Hey, In vtkChartParallelCoordinates the red boxes that show selection ranges are stored in this->Storage->AxesSelections. This gets cleared on every call to Update(), and I think this is a bit too aggressive since they end up being cleared even when the window is just resized. I'm having some trouble deciding on what test to use, though. Maybe something like this (attached) that (I think) tests whether the data has been changed more recently than the chart was rebuilt? Thanks, -Eric ------------------------------------------------------ Eric E Monson Duke Visualization Technology Group ============================================== diff --git a/Charts/vtkChartParallelCoordinates.cxx b/Charts/vtkChartParallelCoordinates.cxx index 0e17b6d..74b3cac 100644 --- a/Charts/vtkChartParallelCoordinates.cxx +++ b/Charts/vtkChartParallelCoordinates.cxx @@ -142,7 +142,11 @@ void vtkChartParallelCoordinates::Update() } axis->SetTitle(this->VisibleColumns->GetValue(i)); } - this->Storage->AxesSelections.clear(); + + if (table->GetMTime() > this->BuildTime) + { + this->Storage->AxesSelections.clear(); + } this->Storage->AxesSelections.resize(this->Storage->Axes.size()); this->GeometryValid = false; From bill.lorensen at gmail.com Mon Sep 20 16:45:14 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 20 Sep 2010 16:45:14 -0400 Subject: [vtk-developers] Kitware VTK cygwin build Message-ID: Folks, At one time, kitware had a cygwin build for VTK. Can someone revive that? We need to verify that VTK still builds with cygwin and cmake 2.8.2... Bill From dave.partyka at kitware.com Mon Sep 20 16:52:32 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Mon, 20 Sep 2010 16:52:32 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: Hi Bill, Dash14 used to do this build. It stopped working because we need cmake 2.8.x to drive the dashboard because only 2.8.x knows how to update git repositories. I built a cygwin 2.8.2 release binary and have been working with Bill Hoffman on getting it submitted to the cygwin package managers. Once it's done, I can update dash14 packages with their package manager. If this is critical for you I can build cmake 2.8.2 by hand on that machine. Otherwise I will wait for the cygwin guys to make the package available through their package manager. On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen wrote: > Folks, > > At one time, kitware had a cygwin build for VTK. Can someone revive > that? We need to verify that VTK still builds with cygwin and cmake > 2.8.2... > > Bill > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Sep 20 17:02:55 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 20 Sep 2010 17:02:55 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: Dave, I think it would be good to verify that vtk cygwin builds with cmake 2.8.x. I know it builds with 2.6. David Doria and I have been going around on this for a few weeks. He has been working with a cygwin guy to resolve the issue, but their solution looks complex to me. It would be good to have "the experts" verify that VTK can indeed be built with cygwin and cmake 2.8.x. Bill On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka wrote: > Hi Bill, > Dash14 used to do this build. It stopped working because we need cmake 2.8.x > to drive the dashboard because only 2.8.x knows how to update git > repositories. I built a cygwin 2.8.2 release binary and have been working > with Bill Hoffman on getting it submitted to the cygwin package managers. > Once it's done, I can update dash14 packages with their package manager. > If this is critical for you I can build cmake 2.8.2 by hand on that machine. > Otherwise I will wait for the cygwin guys to make the package available > through their package manager. > > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen > wrote: >> >> Folks, >> >> At one time, kitware had a cygwin build for VTK. Can someone revive >> that? We need to verify that VTK still builds with cygwin and cmake >> 2.8.2... >> >> Bill >> _______________________________________________ >> 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://www.vtk.org/mailman/listinfo/vtk-developers >> > > From dave.partyka at kitware.com Mon Sep 20 17:04:20 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Mon, 20 Sep 2010 17:04:20 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: Okay, I'll build it by hand on Dash14. On Mon, Sep 20, 2010 at 5:02 PM, Bill Lorensen wrote: > Dave, > > I think it would be good to verify that vtk cygwin builds with cmake > 2.8.x. I know it builds with 2.6. > > David Doria and I have been going around on this for a few weeks. He > has been working with a cygwin guy to resolve the issue, but their > solution looks complex to me. It would be good to have "the experts" > verify that VTK can indeed be built with cygwin and cmake 2.8.x. > > Bill > > On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka > wrote: > > Hi Bill, > > Dash14 used to do this build. It stopped working because we need cmake > 2.8.x > > to drive the dashboard because only 2.8.x knows how to update git > > repositories. I built a cygwin 2.8.2 release binary and have been working > > with Bill Hoffman on getting it submitted to the cygwin package managers. > > Once it's done, I can update dash14 packages with their package manager. > > If this is critical for you I can build cmake 2.8.2 by hand on that > machine. > > Otherwise I will wait for the cygwin guys to make the package available > > through their package manager. > > > > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen > > wrote: > >> > >> Folks, > >> > >> At one time, kitware had a cygwin build for VTK. Can someone revive > >> that? We need to verify that VTK still builds with cygwin and cmake > >> 2.8.2... > >> > >> Bill > >> _______________________________________________ > >> 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://www.vtk.org/mailman/listinfo/vtk-developers > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.partyka at kitware.com Mon Sep 20 17:40:44 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Mon, 20 Sep 2010 17:40:44 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: It should be all set now. We should get some feedback on the dashboard tomorrow. On Mon, Sep 20, 2010 at 5:04 PM, Dave Partyka wrote: > Okay, I'll build it by hand on Dash14. > > > On Mon, Sep 20, 2010 at 5:02 PM, Bill Lorensen wrote: > >> Dave, >> >> I think it would be good to verify that vtk cygwin builds with cmake >> 2.8.x. I know it builds with 2.6. >> >> David Doria and I have been going around on this for a few weeks. He >> has been working with a cygwin guy to resolve the issue, but their >> solution looks complex to me. It would be good to have "the experts" >> verify that VTK can indeed be built with cygwin and cmake 2.8.x. >> >> Bill >> >> On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka >> wrote: >> > Hi Bill, >> > Dash14 used to do this build. It stopped working because we need cmake >> 2.8.x >> > to drive the dashboard because only 2.8.x knows how to update git >> > repositories. I built a cygwin 2.8.2 release binary and have been >> working >> > with Bill Hoffman on getting it submitted to the cygwin package >> managers. >> > Once it's done, I can update dash14 packages with their package manager. >> > If this is critical for you I can build cmake 2.8.2 by hand on that >> machine. >> > Otherwise I will wait for the cygwin guys to make the package available >> > through their package manager. >> > >> > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen > > >> > wrote: >> >> >> >> Folks, >> >> >> >> At one time, kitware had a cygwin build for VTK. Can someone revive >> >> that? We need to verify that VTK still builds with cygwin and cmake >> >> 2.8.2... >> >> >> >> Bill >> >> _______________________________________________ >> >> 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://www.vtk.org/mailman/listinfo/vtk-developers >> >> >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.partyka at kitware.com Tue Sep 21 09:38:35 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Tue, 21 Sep 2010 09:38:35 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: It's there now. Are these any of the compile errors you guys were experiencing? http://www.cdash.org/CDash/viewBuildError.php?buildid=727533 This cygwin is using gcc-3.4.4. I am pretty tempted to see if I can update it to at least 4.x. On Mon, Sep 20, 2010 at 5:40 PM, Dave Partyka wrote: > It should be all set now. We should get some feedback on the dashboard > tomorrow. > > > On Mon, Sep 20, 2010 at 5:04 PM, Dave Partyka wrote: > >> Okay, I'll build it by hand on Dash14. >> >> >> On Mon, Sep 20, 2010 at 5:02 PM, Bill Lorensen wrote: >> >>> Dave, >>> >>> I think it would be good to verify that vtk cygwin builds with cmake >>> 2.8.x. I know it builds with 2.6. >>> >>> David Doria and I have been going around on this for a few weeks. He >>> has been working with a cygwin guy to resolve the issue, but their >>> solution looks complex to me. It would be good to have "the experts" >>> verify that VTK can indeed be built with cygwin and cmake 2.8.x. >>> >>> Bill >>> >>> On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka >>> wrote: >>> > Hi Bill, >>> > Dash14 used to do this build. It stopped working because we need cmake >>> 2.8.x >>> > to drive the dashboard because only 2.8.x knows how to update git >>> > repositories. I built a cygwin 2.8.2 release binary and have been >>> working >>> > with Bill Hoffman on getting it submitted to the cygwin package >>> managers. >>> > Once it's done, I can update dash14 packages with their package >>> manager. >>> > If this is critical for you I can build cmake 2.8.2 by hand on that >>> machine. >>> > Otherwise I will wait for the cygwin guys to make the package available >>> > through their package manager. >>> > >>> > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen < >>> bill.lorensen at gmail.com> >>> > wrote: >>> >> >>> >> Folks, >>> >> >>> >> At one time, kitware had a cygwin build for VTK. Can someone revive >>> >> that? We need to verify that VTK still builds with cygwin and cmake >>> >> 2.8.2... >>> >> >>> >> Bill >>> >> _______________________________________________ >>> >> 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://www.vtk.org/mailman/listinfo/vtk-developers >>> >> >>> > >>> > >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria at gmail.com Tue Sep 21 15:44:03 2010 From: daviddoria at gmail.com (David Doria) Date: Tue, 21 Sep 2010 15:44:03 -0400 Subject: [vtk-developers] vtkInteractorStyleTrackballActor doesn't respect vtkActor::Dragable flag Message-ID: If you create an actor: vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(mapper); actor->DragableOff(); and then use the vtkInteractorStyleTrackballActor, you can drag the actor around with the middle mouse button. Is it the interactor styles job to handle this? Is this incorrect behavior or am I misunderstanding the Dragable flag? David From will.schroeder at kitware.com Tue Sep 21 16:09:42 2010 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 21 Sep 2010 16:09:42 -0400 Subject: [vtk-developers] vtkInteractorStyleTrackballActor doesn't respect vtkActor::Dragable flag In-Reply-To: References: Message-ID: David- If I remember right, the dragable flag is a feature that we added at a very early point and I suspect it is ignored (unlike the pickable flag). W On Tue, Sep 21, 2010 at 3:44 PM, David Doria wrote: > If you create an actor: > > vtkSmartPointer actor = > vtkSmartPointer::New(); > actor->SetMapper(mapper); > actor->DragableOff(); > > and then use the vtkInteractorStyleTrackballActor, you can drag the > actor around with the middle mouse button. Is it the interactor styles > job to handle this? Is this incorrect behavior or am I > misunderstanding the Dragable flag? > > 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://www.vtk.org/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: From daviddoria at gmail.com Tue Sep 21 16:21:36 2010 From: daviddoria at gmail.com (David Doria) Date: Tue, 21 Sep 2010 16:21:36 -0400 Subject: [vtk-developers] vtkInteractorStyleTrackballActor doesn't respect vtkActor::Dragable flag In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 4:09 PM, Will Schroeder wrote: > David- > If I remember right, the dragable flag is a feature that we added at a very > early point and I suspect it is ignored (unlike the pickable flag). > W Here is a quick fix for the case I found: http://github.com/daviddoria/daviddoria-vtk/commit/3cfd31aec50b2570c5b5f2ed327e7c3b0149694b but as you said it something like this is probably needed in many other places. David From marco_atzeri at yahoo.it Tue Sep 21 16:46:48 2010 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Tue, 21 Sep 2010 20:46:48 +0000 (GMT) Subject: [vtk-developers] building on cygwin Message-ID: <792956.86119.qm@web25501.mail.ukl.yahoo.com> Hi Dave, to simplify the usage of my cmake build I created a full cygwin repository. Using setup -X -O -s http://matzeri.altervista.org you will able to install both my 2.8.2-1 and the previous 2.8.1-11 of Yaakov. Moreover on http://matzeri.altervista.org/works/cmake I put in README a small explanation with reference of why I am using it, and on http://matzeri.altervista.org/works/vtk I put the small patch, my CMakeCache.txt configuration plus build and test logs of my trial on git ten days ago with cmake-2.8.1-11. As you know the build was fine with shared libs, but the test show more failures than my previous tentative on 5.6.0. I have not yet tested with cmake-2.8.2-1, but I expect no real problem. Regards Marco Atzeri From david.gobbi at gmail.com Tue Sep 21 17:51:05 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Sep 2010 15:51:05 -0600 Subject: [vtk-developers] Charts and float/int conversion Message-ID: Hi Marcus, I've noticed that "Charts" uses truncation for its float-to-int conversion. This can lead to rendering problems. E.g. if float x is set to 1.0, some transformation is done to x, then x is now equal to 3.99999 on some platforms, and equal to 4.0000001 on other platforms. i = static_cast(x); // 3 on platform A, 4 on platform B It might be worthwhile to add an inline float-to-int function that does a bit of rounding to vtkContext2D, and then utilize this function wherever int-to-float conversion is done within the Charts directory: inline vtkContext2D::FloatToInt(float x) { return static_cast(x + 1.0625) - 1; } This provides a tolerance of 1/16 of a pixel for the float-to-int conversion. The "1" and "- 1" ensure that float values in the range [-1.0, 0.0] are rounded down, instead of being rounded toward zero. David From jimcp at cox.net Tue Sep 21 18:53:05 2010 From: jimcp at cox.net (Jim Peterson) Date: Tue, 21 Sep 2010 18:53:05 -0400 Subject: [vtk-developers] Charts and float/int conversion In-Reply-To: References: Message-ID: <4C993751.8070906@cox.net> David Gobbi wrote: > inline vtkContext2D::FloatToInt(float x) > { > return static_cast(x + 1.0625) - 1; > } > > This provides a tolerance of 1/16 of a pixel for the float-to-int > conversion. The "1" and "- 1" ensure that float values in the range > [-1.0, 0.0] are rounded down, instead of being rounded toward zero. > > David > David, pardon my ignorance, but if we are rounding float to int, why do we want -0.1 to round to -1 and not 0? in other words, why not x + 1.5 instead of x + 1.0625? Thanks, Jim From david.gobbi at gmail.com Tue Sep 21 19:11:26 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Sep 2010 17:11:26 -0600 Subject: [vtk-developers] Charts and float/int conversion In-Reply-To: <4C993751.8070906@cox.net> References: <4C993751.8070906@cox.net> Message-ID: On Tue, Sep 21, 2010 at 4:53 PM, Jim Peterson wrote: > David Gobbi wrote: >> >> inline vtkContext2D::FloatToInt(float x) >> { >> ?return static_cast(x + 1.0625) - 1; >> } >> >> This provides a tolerance of 1/16 of a pixel for the float-to-int >> conversion. The "1" and "- 1" ensure that float values in the range >> [-1.0, 0.0] are rounded down, instead of being rounded toward zero. >> >> ?David > > David, > pardon my ignorance, but if we are rounding float to int, why do we want > -0.1 to round to -1 and not 0? in other words, why not x + 1.5 instead of x > + 1.0625? > > Thanks, > Jim It all depends on what the rounding is being used for. When rasterizing floating-point coordinates to the screen (i.e. to pixels), it is convention to round down. The IEEE 754 standard describes five rounding modes, each of which is valid for its intended uses: 1) Round toward 0, which is C standard float-to-int 2) Round towards -inf, which is like floor() 3) Round towards +inf, which is like ceil() 4) Round to nearest, towards even number if tie, default mode on many CPUs 5) Round to nearest, away from zero if tie My favorite mode is round to nearest, and towards the higher of the two integers in case of a tie. Unfortunately that isn't in the standard. :P David From sean at rogue-research.com Tue Sep 21 19:32:03 2010 From: sean at rogue-research.com (Sean McBride) Date: Tue, 21 Sep 2010 19:32:03 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> Message-ID: <20100921233203.2128610341@mail.rogue-research.com> On Tue, 14 Sep 2010 09:08:01 -0600, David Gobbi said: >The general implementation "static_cast(floor())" is the simplest >correct implementation, even if it is inefficient, so I'd like to >leave it as the general case. But we could easily add an #ifdef to >add whichever float-to-int conversion is most efficient for your >platform. David, Regarding vtkResliceRound()... one of the conditional implementations is: #elif defined ia64 || defined __ia64__ || defined IA64 x += 103079215104.5; long long i = static_cast(x); return static_cast(i - 103079215104LL); On Mac OS X with the x86_64 arch (the default these days) none of those is #defined. I've been running with "|| defined __x86_64__" added for several days now and all seems well. But I don't understand this code. :) Any reason I should not push this change? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Tue Sep 21 19:47:12 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Sep 2010 17:47:12 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100921233203.2128610341@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> Message-ID: On Tue, Sep 21, 2010 at 5:32 PM, Sean McBride wrote: > David, > > Regarding vtkResliceRound()... one of the conditional implementations is: > > #elif defined ia64 || defined __ia64__ || defined IA64 > ?x += 103079215104.5; > ?long long i = static_cast(x); > ?return static_cast(i - 103079215104LL); > > On Mac OS X with the x86_64 arch (the default these days) none of those > is #defined. > > I've been running with "|| defined __x86_64__" added for several days > now and all seems well. ?But I don't understand this code. ?:) > > Any reason I should not push this change? That #if was originally for Itanium, but should work on most (maybe all?) 64-bit platforms, as long as they can efficiently convert double to 64-bit int. In other words, looks good to me! But maybe I should push it... it also needs to use "vtkTypeInt64" instead of "long long" or some compilers will choke. David From sean at rogue-research.com Tue Sep 21 19:51:58 2010 From: sean at rogue-research.com (Sean McBride) Date: Tue, 21 Sep 2010 19:51:58 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> Message-ID: <20100921235158.1185583542@mail.rogue-research.com> On Tue, 21 Sep 2010 17:47:12 -0600, David Gobbi said: >That #if was originally for Itanium, but should work on most (maybe >all?) 64-bit platforms, as long as they can efficiently convert double >to 64-bit int. In other words, looks good to me! I had wondered if it was endian dependent. So you're saying it should work for ppc64 too then? Though IIRC, int<->float is slow on ppc... I have only tried x86_64 so far, and Instruments confirms it's faster (not surprisingly). >But maybe I should push it... Sure! >it also needs to use "vtkTypeInt64" >instead of "long long" or some compilers will choke. Are such compilers still supported? Or was that only needed for the old borland and VS versions? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Tue Sep 21 20:02:05 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Sep 2010 18:02:05 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100921235158.1185583542@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> Message-ID: On Tue, Sep 21, 2010 at 5:51 PM, Sean McBride wrote: > I had wondered if it was endian dependent. ?So you're saying it should > work for ppc64 too then? ?Though IIRC, int<->float is slow on ppc... Yes, it will work on ppc64. Faster? I don't know. Only the stuff in the #ifdef i386 block is endian-dependent, the other #if blocks don't care about endianness. > I have only tried x86_64 so far, and Instruments confirms it's faster > (not surprisingly). > >>instead of "long long" or some compilers will choke. > > Are such compilers still supported? ?Or was that only needed for the old > borland and VS versions? If VTK sets VTK_TYPE_USE___INT64, then I use __int64 ;) David From sean at rogue-research.com Tue Sep 21 20:08:48 2010 From: sean at rogue-research.com (Sean McBride) Date: Tue, 21 Sep 2010 20:08:48 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> Message-ID: <20100922000848.56856200@mail.rogue-research.com> On Tue, 21 Sep 2010 18:02:05 -0600, David Gobbi said: >On Tue, Sep 21, 2010 at 5:51 PM, Sean McBride wrote: > >> I had wondered if it was endian dependent. ?So you're saying it should >> work for ppc64 too then? ?Though IIRC, int<->float is slow on ppc... > >Yes, it will work on ppc64. Faster? I don't know. Only the stuff in >the #ifdef i386 block is endian-dependent, the other #if blocks don't >care about endianness. OK thanks. So I'll test ppc64 and you push the x86_64 case? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Tue Sep 21 20:58:44 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Sep 2010 18:58:44 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100922000848.56856200@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> Message-ID: On Tue, Sep 21, 2010 at 6:08 PM, Sean McBride wrote: > OK thanks. ?So I'll test ppc64 and you push the x86_64 case? I might as well push __ppc64__ too, because it can't hurt. Are you profiling on the G5? I'm curious whether it will make a difference. David From daviddoria at gmail.com Wed Sep 22 08:14:17 2010 From: daviddoria at gmail.com (David Doria) Date: Wed, 22 Sep 2010 08:14:17 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: > Did anyone get a chance to look at this? > David Can I push this? David From bill.lorensen at gmail.com Wed Sep 22 08:24:41 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 22 Sep 2010 08:24:41 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: Dave, I see today that the cygwin build is getting closer. But none of the tests are running. I am using cygwin version 1.7.7, gcc-4.3.4 and cmake 2.6-patch4. I build with shared libs on. I had to patch one file: Utilities/Cosmo/ParticleDistribute.cxx All built fine except that I get thousands of warnings about "visibility attribute not supported in this configuration". All but 8 tests passed. I think I'll build cmake 2.8 and see if it solves the visibility issue. Bill On Tue, Sep 21, 2010 at 9:38 AM, Dave Partyka wrote: > It's there now. Are these any of the compile errors you guys were > experiencing? > http://www.cdash.org/CDash/viewBuildError.php?buildid=727533 > This cygwin is using gcc-3.4.4. I am pretty tempted to see if I can update > it to at least 4.x. > > On Mon, Sep 20, 2010 at 5:40 PM, Dave Partyka > wrote: >> >> It should be all set now. We should get some feedback on the dashboard >> tomorrow. >> >> On Mon, Sep 20, 2010 at 5:04 PM, Dave Partyka >> wrote: >>> >>> Okay, I'll build it by hand on Dash14. >>> >>> On Mon, Sep 20, 2010 at 5:02 PM, Bill Lorensen >>> wrote: >>>> >>>> Dave, >>>> >>>> I think it would be good to verify that vtk cygwin builds with cmake >>>> 2.8.x. I know it builds with 2.6. >>>> >>>> David Doria and I have been going around on this for a few weeks. He >>>> has been working with a cygwin guy to resolve the issue, but their >>>> solution looks complex to me. It would be good to have "the experts" >>>> verify that VTK can indeed be built with cygwin and cmake 2.8.x. >>>> >>>> Bill >>>> >>>> On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka >>>> wrote: >>>> > Hi Bill, >>>> > Dash14 used to do this build. It stopped working because we need cmake >>>> > 2.8.x >>>> > to drive the dashboard because only 2.8.x knows how to update git >>>> > repositories. I built a cygwin 2.8.2 release binary and have been >>>> > working >>>> > with Bill Hoffman on getting it submitted to the cygwin package >>>> > managers. >>>> > Once it's done, I can update dash14 packages with their package >>>> > manager. >>>> > If this is critical for you I can build cmake 2.8.2 by hand on that >>>> > machine. >>>> > Otherwise I will wait for the cygwin guys to make the package >>>> > available >>>> > through their package manager. >>>> > >>>> > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen >>>> > >>>> > wrote: >>>> >> >>>> >> Folks, >>>> >> >>>> >> At one time, kitware had a cygwin build for VTK. Can someone revive >>>> >> that? We need to verify that VTK still builds with cygwin and cmake >>>> >> 2.8.2... >>>> >> >>>> >> Bill >>>> >> _______________________________________________ >>>> >> 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://www.vtk.org/mailman/listinfo/vtk-developers >>>> >> >>>> > >>>> > >>> >> > > From dave.partyka at kitware.com Wed Sep 22 08:35:57 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Wed, 22 Sep 2010 08:35:57 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: vtkUnicodeString is in vtkCommon which failed to compile thus none of the tests were built. As for the visibility warnings. Visibility is defined in Common\vtkABI.h though it "should" be defining the windows declspecs for Cygwin and not using __attribute__ visibility (Assuming we're talking about the same visibility). Feel free to dig deeper. Dash14 is extremely slow so I may not have any further information until tomorrow. On Wed, Sep 22, 2010 at 8:24 AM, Bill Lorensen wrote: > Dave, > > I see today that the cygwin build is getting closer. But none of the > tests are running. > > I am using cygwin version 1.7.7, gcc-4.3.4 and cmake 2.6-patch4. > > I build with shared libs on. > > I had to patch one file: Utilities/Cosmo/ParticleDistribute.cxx > > All built fine except that I get thousands of warnings about > "visibility attribute not supported in this configuration". > > All but 8 tests passed. > > I think I'll build cmake 2.8 and see if it solves the visibility issue. > > Bill > > On Tue, Sep 21, 2010 at 9:38 AM, Dave Partyka > wrote: > > It's there now. Are these any of the compile errors you guys were > > experiencing? > > http://www.cdash.org/CDash/viewBuildError.php?buildid=727533 > > This cygwin is using gcc-3.4.4. I am pretty tempted to see if I can > update > > it to at least 4.x. > > > > On Mon, Sep 20, 2010 at 5:40 PM, Dave Partyka > > wrote: > >> > >> It should be all set now. We should get some feedback on the dashboard > >> tomorrow. > >> > >> On Mon, Sep 20, 2010 at 5:04 PM, Dave Partyka > > >> wrote: > >>> > >>> Okay, I'll build it by hand on Dash14. > >>> > >>> On Mon, Sep 20, 2010 at 5:02 PM, Bill Lorensen < > bill.lorensen at gmail.com> > >>> wrote: > >>>> > >>>> Dave, > >>>> > >>>> I think it would be good to verify that vtk cygwin builds with cmake > >>>> 2.8.x. I know it builds with 2.6. > >>>> > >>>> David Doria and I have been going around on this for a few weeks. He > >>>> has been working with a cygwin guy to resolve the issue, but their > >>>> solution looks complex to me. It would be good to have "the experts" > >>>> verify that VTK can indeed be built with cygwin and cmake 2.8.x. > >>>> > >>>> Bill > >>>> > >>>> On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka < > dave.partyka at kitware.com> > >>>> wrote: > >>>> > Hi Bill, > >>>> > Dash14 used to do this build. It stopped working because we need > cmake > >>>> > 2.8.x > >>>> > to drive the dashboard because only 2.8.x knows how to update git > >>>> > repositories. I built a cygwin 2.8.2 release binary and have been > >>>> > working > >>>> > with Bill Hoffman on getting it submitted to the cygwin package > >>>> > managers. > >>>> > Once it's done, I can update dash14 packages with their package > >>>> > manager. > >>>> > If this is critical for you I can build cmake 2.8.2 by hand on that > >>>> > machine. > >>>> > Otherwise I will wait for the cygwin guys to make the package > >>>> > available > >>>> > through their package manager. > >>>> > > >>>> > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen > >>>> > > >>>> > wrote: > >>>> >> > >>>> >> Folks, > >>>> >> > >>>> >> At one time, kitware had a cygwin build for VTK. Can someone revive > >>>> >> that? We need to verify that VTK still builds with cygwin and cmake > >>>> >> 2.8.2... > >>>> >> > >>>> >> Bill > >>>> >> _______________________________________________ > >>>> >> 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://www.vtk.org/mailman/listinfo/vtk-developers > >>>> >> > >>>> > > >>>> > > >>> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria at gmail.com Wed Sep 22 08:36:39 2010 From: daviddoria at gmail.com (David Doria) Date: Wed, 22 Sep 2010 08:36:39 -0400 Subject: [vtk-developers] Catching member events in OO style Message-ID: As an example, say I have a vtkImageTracerWidget as a member variable of a subclass of vtkInteractorStyle. To catch the widgets events in a way that I still have access to the class instance data, I have declared a static callback function class MyClass : public vtkInteractoStyle { public: static void KeypressCallbackFunction ( vtkObject* caller, long unsigned int eventId, void* clientData, void* callData ); When I set up the vtkCallbackCommand, I used SetClientData(this) to give the callback access to my interactor style. Unfortunately this is only public access. This seems like a horribly convoluted way to catching these events - is there a more OO-friendly way? Thanks, David From pat.marion at kitware.com Wed Sep 22 08:50:27 2010 From: pat.marion at kitware.com (pat marion) Date: Wed, 22 Sep 2010 08:50:27 -0400 Subject: [vtk-developers] Catching member events in OO style In-Reply-To: References: Message-ID: Take a look at Servers/Filters/vtkMemberFunctionCommand.h in the paraview source directory. Pat On Wed, Sep 22, 2010 at 8:36 AM, David Doria wrote: > As an example, say I have a vtkImageTracerWidget as a member variable > of a subclass of vtkInteractorStyle. To catch the widgets events in a > way that I still have access to the class instance data, I have > declared a static callback function > > class MyClass : public vtkInteractoStyle > { > public: > static void KeypressCallbackFunction ( vtkObject* caller, long > unsigned int eventId, void* clientData, void* callData ); > > When I set up the vtkCallbackCommand, I used SetClientData(this) to > give the callback access to my interactor style. Unfortunately this is > only public access. This seems like a horribly convoluted way to > catching these events - is there a more OO-friendly way? > > Thanks, > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.marion at kitware.com Wed Sep 22 10:45:34 2010 From: pat.marion at kitware.com (pat marion) Date: Wed, 22 Sep 2010 10:45:34 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: Are you talking about pushing your commits 26d55f7a59 thru bb4b221faf2? My opinion is that these commits are not ready to be pushed, but I have not had a lot of time to do a proper review. For ease of reviewing, I'd recommend squashing all your commits into two- the first commit performs adds your new feature, the second commit that adds the tests. Then use git format-patch and attach the commits to the mailing list. Pat On Wed, Sep 22, 2010 at 8:14 AM, David Doria wrote: > > Did anyone get a chance to look at this? > > David > > Can I push this? > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Sep 22 11:32:10 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 22 Sep 2010 11:32:10 -0400 Subject: [vtk-developers] Kitware VTK cygwin build In-Reply-To: References: Message-ID: I was also surprised I got those warnings. I'll keep digging. Bill On Wed, Sep 22, 2010 at 8:35 AM, Dave Partyka wrote: > vtkUnicodeString is in vtkCommon which failed to compile thus none of the > tests were built. > As for the visibility warnings. Visibility is defined in Common\vtkABI.h > though it "should" be defining the windows declspecs for Cygwin and not > using __attribute__ visibility (Assuming we're talking about the same > visibility). Feel free to dig deeper. Dash14 is extremely slow so I may not > have any further information until tomorrow. > > On Wed, Sep 22, 2010 at 8:24 AM, Bill Lorensen > wrote: >> >> Dave, >> >> I see today that the cygwin build is getting closer. But none of the >> tests are running. >> >> I am using cygwin version 1.7.7, gcc-4.3.4 and cmake 2.6-patch4. >> >> I build with shared libs on. >> >> I had to patch one file: Utilities/Cosmo/ParticleDistribute.cxx >> >> All built fine except that I get thousands of warnings about >> "visibility attribute not supported in this configuration". >> >> All but 8 tests passed. >> >> I think I'll build cmake 2.8 and see if it solves the visibility issue. >> >> Bill >> >> On Tue, Sep 21, 2010 at 9:38 AM, Dave Partyka >> wrote: >> > It's there now. Are these any of the compile errors you guys were >> > experiencing? >> > http://www.cdash.org/CDash/viewBuildError.php?buildid=727533 >> > This cygwin is using gcc-3.4.4. I am pretty tempted to see if I can >> > update >> > it to at least 4.x. >> > >> > On Mon, Sep 20, 2010 at 5:40 PM, Dave Partyka >> > wrote: >> >> >> >> It should be all set now. We should get some feedback on the dashboard >> >> tomorrow. >> >> >> >> On Mon, Sep 20, 2010 at 5:04 PM, Dave Partyka >> >> >> >> wrote: >> >>> >> >>> Okay, I'll build it by hand on Dash14. >> >>> >> >>> On Mon, Sep 20, 2010 at 5:02 PM, Bill Lorensen >> >>> >> >>> wrote: >> >>>> >> >>>> Dave, >> >>>> >> >>>> I think it would be good to verify that vtk cygwin builds with cmake >> >>>> 2.8.x. I know it builds with 2.6. >> >>>> >> >>>> David Doria and I have been going around on this for a few weeks. He >> >>>> has been working with a cygwin guy to resolve the issue, but their >> >>>> solution looks complex to me. It would be good to have "the experts" >> >>>> verify that VTK can indeed be built with cygwin and cmake 2.8.x. >> >>>> >> >>>> Bill >> >>>> >> >>>> On Mon, Sep 20, 2010 at 4:52 PM, Dave Partyka >> >>>> >> >>>> wrote: >> >>>> > Hi Bill, >> >>>> > Dash14 used to do this build. It stopped working because we need >> >>>> > cmake >> >>>> > 2.8.x >> >>>> > to drive the dashboard because only 2.8.x knows how to update git >> >>>> > repositories. I built a cygwin 2.8.2 release binary and have been >> >>>> > working >> >>>> > with Bill Hoffman on getting it submitted to the cygwin package >> >>>> > managers. >> >>>> > Once it's done, I can update dash14 packages with their package >> >>>> > manager. >> >>>> > If this is critical for you I can build cmake 2.8.2 by hand on that >> >>>> > machine. >> >>>> > Otherwise I will wait for the cygwin guys to make the package >> >>>> > available >> >>>> > through their package manager. >> >>>> > >> >>>> > On Mon, Sep 20, 2010 at 4:45 PM, Bill Lorensen >> >>>> > >> >>>> > wrote: >> >>>> >> >> >>>> >> Folks, >> >>>> >> >> >>>> >> At one time, kitware had a cygwin build for VTK. Can someone >> >>>> >> revive >> >>>> >> that? We need to verify that VTK still builds with cygwin and >> >>>> >> cmake >> >>>> >> 2.8.2... >> >>>> >> >> >>>> >> Bill >> >>>> >> _______________________________________________ >> >>>> >> 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://www.vtk.org/mailman/listinfo/vtk-developers >> >>>> >> >> >>>> > >> >>>> > >> >>> >> >> >> > >> > > > From sean at rogue-research.com Wed Sep 22 13:34:56 2010 From: sean at rogue-research.com (Sean McBride) Date: Wed, 22 Sep 2010 13:34:56 -0400 Subject: [vtk-developers] Adding const to public API? Message-ID: <20100922173456.1072958790@mail.rogue-research.com> Hi all, Would it break any compatibility or cause any problems with wrapping if I add a 'const' to a parameter of a public API? Specifically: void vtkImplicitFunction::SetTransform(double elements[16]) (I have of course already tried building and running tests, all seems fine.) 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 daviddoria at gmail.com Wed Sep 22 14:04:07 2010 From: daviddoria at gmail.com (David Doria) Date: Wed, 22 Sep 2010 14:04:07 -0400 Subject: [vtk-developers] Catching member events in OO style In-Reply-To: References: Message-ID: On Wed, Sep 22, 2010 at 8:50 AM, pat marion wrote: > Take a look at Servers/Filters/vtkMemberFunctionCommand.h in the paraview > source directory. > > Pat Very cool! Works perfectly. Is there any reason this is not in VTK?? David From david.gobbi at gmail.com Wed Sep 22 14:07:03 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 22 Sep 2010 12:07:03 -0600 Subject: [vtk-developers] Adding const to public API? In-Reply-To: <20100922173456.1072958790@mail.rogue-research.com> References: <20100922173456.1072958790@mail.rogue-research.com> Message-ID: On Wed, Sep 22, 2010 at 11:34 AM, Sean McBride wrote: > Hi all, > > Would it break any compatibility or cause any problems with wrapping if > I add a 'const' to a parameter of a public API? > > Specifically: > void vtkImplicitFunction::SetTransform(double elements[16]) As long as there are no subclasses around that override that signature, I don't think that this change can break anything. So I say go for it. Way back in 1999 most of the Set methods with "char *" parameters were changed to "const char *". I kinda wish that all the Set array parameters had been made const at the same time. David From pppebay at sandia.gov Wed Sep 22 15:02:33 2010 From: pppebay at sandia.gov (=?ISO-8859-15?Q?Philippe_P=E9bay?=) Date: Wed, 22 Sep 2010 12:02:33 -0700 Subject: [vtk-developers] [vtkStatistics] New SAND report documenting serial and parallel order statistics engine Message-ID: <4C9A52C9.8050200@sandia.gov> Hello, David Thompson and I have just released a new SAND report (2010-6466) documenting the use of the order statistics engine, in both serial and parallel versions. It is now available here: https://www.kitware.com/InfovisWiki/index.php/Statistics_Engines It completes the series of reports documenting all statistics engines. The plan is to wrap this up in a single document sometime later this year, as the "Statistics" chapter of the VTK book is already a little outdated with several new functionalities. Philippe -- Philippe P?bay Sandia National Laboratories From david.gobbi at gmail.com Thu Sep 23 10:35:59 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 08:35:59 -0600 Subject: [vtk-developers] ToParent() vs. ToParentCoordinates() Message-ID: Hi Jeff, I notice that the new Context classes use methods like "ToParent()", "FromParent()" etc. for coordinate transformations. Don't short, non-descriptive method names go against the VTK style guidelines? Names like ToParentCoordinates() would have a more obvious meaning. David From david.gobbi at gmail.com Thu Sep 23 13:06:37 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 11:06:37 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> Message-ID: On Tue, Sep 21, 2010 at 6:58 PM, David Gobbi wrote: > On Tue, Sep 21, 2010 at 6:08 PM, Sean McBride wrote: > >> OK thanks. ?So I'll test ppc64 and you push the x86_64 case? I pushed the ifdefs for ppc64 and x86_64. Nothing broke :) David From daviddoria at gmail.com Thu Sep 23 14:42:55 2010 From: daviddoria at gmail.com (David Doria) Date: Thu, 23 Sep 2010 14:42:55 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: On Wed, Sep 22, 2010 at 10:45 AM, pat marion wrote: > Are you talking about pushing your commits 26d55f7a59 thru bb4b221faf2?? My > opinion is that these commits are not ready to be pushed, but I have not had > a lot of time to do a proper review.? For ease of reviewing, I'd recommend > squashing all your commits into two- the first commit performs adds your new > feature, the second commit that adds the tests.? Then use git format-patch > and attach the commits to the mailing list. > > Pat Yes, those are the commits. I did some reading about squashing etc. I see how to combine commits, but I don't know how to separate commits. That is, in most of the commits I worked on the implementation as well as the test. How would I break these apart? Also, why would you want to use git format-patch? Isn't github's interface exactly for this type of review? And the idea of publishing a branch instead of just the files is that a review can clone the branch and try everything out right away, right? And githubs red/green highlighted lines as well as displaying individual files also solves the problem of having the test and the implementation in the same commit, right? It just look to me like this process of preparing the code for a review will take just as much time as writing these tiny patches. Is this the "agreed upon" procedure? I know ITK has been using Gerrit and I know we're not there yet, but would most people know what to do with a git format-patch email? David From pat.marion at kitware.com Thu Sep 23 15:29:15 2010 From: pat.marion at kitware.com (pat marion) Date: Thu, 23 Sep 2010 15:29:15 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: In order to squash everything into two commits I'd probably just do a 'git reset xxxxx' where xxxxx is the hash of the commit that your work is based on. This will undo all your commits, but leave your changes in the working tree. Now just git add the vtk files, commit, git add the test files, commit. Linking to github's diff view probably works as well or better than attaching patches. In your email I only found a link to your repo url and branch name though. I fetched it to look at the diff. I guess I'd find it most convenient to have diffs attached to the email (for small changes) and a link to the repo for those motivated to take a closer look. Pat On Thu, Sep 23, 2010 at 2:42 PM, David Doria wrote: > On Wed, Sep 22, 2010 at 10:45 AM, pat marion > wrote: > > Are you talking about pushing your commits 26d55f7a59 thru bb4b221faf2? > My > > opinion is that these commits are not ready to be pushed, but I have not > had > > a lot of time to do a proper review. For ease of reviewing, I'd > recommend > > squashing all your commits into two- the first commit performs adds your > new > > feature, the second commit that adds the tests. Then use git > format-patch > > and attach the commits to the mailing list. > > > > Pat > > Yes, those are the commits. I did some reading about squashing etc. I > see how to combine commits, but I don't know how to separate commits. > That is, in most of the commits I worked on the implementation as well > as the test. How would I break these apart? > > Also, why would you want to use git format-patch? Isn't github's > interface exactly for this type of review? And the idea of publishing > a branch instead of just the files is that a review can clone the > branch and try everything out right away, right? And githubs red/green > highlighted lines as well as displaying individual files also solves > the problem of having the test and the implementation in the same > commit, right? > > It just look to me like this process of preparing the code for a > review will take just as much time as writing these tiny patches. Is > this the "agreed upon" procedure? I know ITK has been using Gerrit and > I know we're not there yet, but would most people know what to do with > a git format-patch email? > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Sep 23 15:29:31 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 13:29:31 -0600 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: On Thu, Sep 23, 2010 at 12:42 PM, David Doria wrote: > On Wed, Sep 22, 2010 at 10:45 AM, pat marion wrote: >> Are you talking about pushing your commits 26d55f7a59 thru bb4b221faf2?? My >> opinion is that these commits are not ready to be pushed, but I have not had >> a lot of time to do a proper review.? For ease of reviewing, I'd recommend >> squashing all your commits into two- the first commit performs adds your new >> feature, the second commit that adds the tests.? Then use git format-patch >> and attach the commits to the mailing list. >> >> Pat > > Yes, those are the commits. I did some reading about squashing etc. I > see how to combine commits, but I don't know how to separate commits. > That is, in most of the commits I worked on the implementation as well > as the test. How would I break these apart? > > Also, why would you want to use git format-patch? Isn't github's > interface exactly for this type of review? And the idea of publishing > a branch instead of just the files is that a review can clone the > branch and try everything out right away, right? And githubs red/green > highlighted lines as well as displaying individual files also solves > the problem of having the test and the implementation in the same > commit, right? > > It just look to me like this process of preparing the code for a > review will take just as much time as writing these tiny patches. Is > this the "agreed upon" procedure? I know ITK has been using Gerrit and > I know we're not there yet, but would most people know what to do with > a git format-patch email? If you want code to be reviewed, you must make the code easy to review. Give an http link to github that shows the changes as a single diff. Or provide a singe patchfile in "unified" style (though a github link would be preferable to me, at least). But in my opinion, interface methods like this should be added to vtkPointLocator, not to its subclasses. But even then, the small convenience that this method adds is not enough for me to approve of its addition. David From daviddoria at gmail.com Thu Sep 23 15:35:25 2010 From: daviddoria at gmail.com (David Doria) Date: Thu, 23 Sep 2010 15:35:25 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: > If you want code to be reviewed, you must make the code easy to > review. ?Give an http link to github that shows the changes as a > single diff. ?Or provide a singe patchfile in "unified" style (though > a github link would be preferable to me, at least). > > But in my opinion, interface methods like this should be added to > vtkPointLocator, not to its subclasses. ?But even then, the small > convenience that this method adds is not enough for me to approve of > its addition. > > ?David > I agree that it should be easy to review, but it must also be easy to make easy to review. The changes were not made to a subclass, they were made to vtkAbstractPointLocator. Why is everyone so against convenience functions? They make things convenient (read "easy", "intuitive", "clean") to use by definition... David From david.gobbi at gmail.com Thu Sep 23 15:54:47 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 13:54:47 -0600 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: On Thu, Sep 23, 2010 at 1:35 PM, David Doria wrote: > > Why is everyone so against convenience functions? They make things > convenient (read "easy", "intuitive", "clean") to use by definition... Most of us are in it for the long haul (as developers), and the smaller the class interfaces are, the easier it is to maintain the VTK codebase. In my opinion, class interfaces should be orthogonal, meaning that there should be only one method for achieving one specific class functionality. This maximizes code coverage. But the biggest problem with convenience methods is that different people have different opinions about what is the "best/easiest" way of doing something. You can't add new methods to classes just because someone thinks there is a better way of doing things. New methods should add new functionality. Otherwise, they are bloat. David From david.cole at kitware.com Thu Sep 23 15:57:50 2010 From: david.cole at kitware.com (David Cole) Date: Thu, 23 Sep 2010 15:57:50 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: On Thu, Sep 23, 2010 at 3:54 PM, David Gobbi wrote: > On Thu, Sep 23, 2010 at 1:35 PM, David Doria wrote: > > > > Why is everyone so against convenience functions? They make things > > convenient (read "easy", "intuitive", "clean") to use by definition... > > Most of us are in it for the long haul (as developers), and the > smaller the class interfaces are, the easier it is to maintain the VTK > codebase. > > In my opinion, class interfaces should be orthogonal, meaning that > there should be only one method for achieving one specific class > functionality. This maximizes code coverage. > > But the biggest problem with convenience methods is that different > people have different opinions about what is the "best/easiest" way of > doing something. You can't add new methods to classes just because > someone thinks there is a better way of doing things. New methods > should add new functionality. Otherwise, they are bloat. > Well said. "Convenience" makes things more expensive over the long run. > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Sep 23 16:06:22 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 23 Sep 2010 16:06:22 -0400 Subject: [vtk-developers] ANN: VTK topic stage Message-ID: Hi, I wanted to point out that the VTK topic stage is available for use to anyone with push access to VTK's main git repository. At present there is just one integration branch (master), and next will be added in the near future. You can push topic branches to the topic stage, and using the simple command line interface you can merge those topic branches into VTK's master branch. http://www.vtk.org/Wiki/VTK/Git#Topic_Stage This is the only way to make merge commits in VTK, at present this is an optional step for those wishing to use it. Now would be a great time to start using the topic stage, and let us know of any issues you encounter. CMake and Titan are already using the topic stage with master and next, if you are curious to see how this is being employed elsewhere. Thanks, Marcus -- Marcus D. Hanwell, Ph.D. R&D Engineer, Kitware Inc. (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Sep 23 16:13:11 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 14:13:11 -0600 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: On Thu, Sep 23, 2010 at 1:57 PM, David Cole wrote: > Well said. "Convenience" makes things more expensive over the long run. If you want to see a bad interface, look at the vtkImageReslice class that I wrote during my PhD: http://www.vtk.org/doc/nightly/html/classvtkImageReslice.html This class has been a pain in the butt for me to maintain, and the interface is so large and non-orthogonal that it gives everyone who uses it a headache ;) David From daviddoria at gmail.com Thu Sep 23 16:18:26 2010 From: daviddoria at gmail.com (David Doria) Date: Thu, 23 Sep 2010 16:18:26 -0400 Subject: [vtk-developers] KdTree FindPointsWithinRadius In-Reply-To: References: Message-ID: > Well said. "Convenience" makes things more expensive over the long run. I understand your point, and it is a good one. However, this is a completely developer-centric view. In my experience with VTK the experience from a users viewpoint is really not considered at all. There should be a reasonable weighting given to these two points of view before making decisions. It is tough because on the mailing lists (even the "users" list) you are only reaching people interested enough to join the mailing list. The other users (usually 5-10x the amount on the mailing list, and probably 1000x the size of users who actually speak on the list) are the ones we are really supplying code for) have no voice. I am surrounded all day by people who struggle with these awkward interfaces so it is likely I am siding too much with them, but just keep this in mind. David From sean at rogue-research.com Thu Sep 23 18:45:18 2010 From: sean at rogue-research.com (Sean McBride) Date: Thu, 23 Sep 2010 18:45:18 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> Message-ID: <20100923224518.806287166@mail.rogue-research.com> On Thu, 23 Sep 2010 11:06:37 -0600, David Gobbi said: >On Tue, Sep 21, 2010 at 6:58 PM, David Gobbi wrote: >> On Tue, Sep 21, 2010 at 6:08 PM, Sean McBride research.com> wrote: >> >>> OK thanks. ?So I'll test ppc64 and you push the x86_64 case? > >I pushed the ifdefs for ppc64 and x86_64. Nothing broke :) Thanks David. I also tested on ppc64 and can confirm that nothing broke. But I did not have a chance to profile the change. However, I doubt it could be slower since floor() has to check for nan and other standards-compliance things that we don't need. For fun, I searched VTK for "i386"... there are 48 occurrences. Taking a look through them, I note the following: 1) vtkGridTransform.cxx seems to have copy-pasted vtkResliceFloor and named it vtkGridFloor. They were mostly identical, but I suppose they've now diverged further after your commit. This duplication suggests that this code should move to vtkMath (or somewhere). 2) I noticed that vtkMath::Floor() has an "#if defined i386" but no other special cases.... I wonder if it's worth adding others? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Thu Sep 23 19:11:54 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 17:11:54 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100923224518.806287166@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> <20100923224518.806287166@mail.rogue-research.com> Message-ID: On Thu, Sep 23, 2010 at 4:45 PM, Sean McBride wrote: > On Thu, 23 Sep 2010 11:06:37 -0600, David Gobbi said: > For fun, I searched VTK for "i386"... there are 48 occurrences. ?Taking > a look through them, I note the following: > > 1) vtkGridTransform.cxx seems to have copy-pasted vtkResliceFloor and > named it vtkGridFloor. ?They were mostly identical, but I suppose > they've now diverged further after your commit. ?This duplication > suggests that this code should move to vtkMath (or somewhere). > > > 2) I noticed that vtkMath::Floor() has an "#if defined i386" but no > other special cases.... I wonder if it's worth adding others? Ugh. Yeah, if you really look hard you'll find tons of "Floor" and "Round" definitions in VTK, either as inline functions or as preprocessor macros. It is so hard to reach a consensus about the best way to do these things. My vtkResliceFloor is no good as a "general purpose" round because it is not exact. If a float number is just barely below an integer, it will be rounded up instead of down (this is true for both the i386 and the new x86_64 code). For vtkImageReslice, this property of having it "stick to the integers" helps to add stability to the results in the face of roundoff errors in the transformation. But for other uses in VTK, this would not be so good. The vtkMath::Floor() needs to be more exact. Its i386-trick is more exact than the one I have in vtkImageReslice. It could have the following acceleration in place of floor() for non-i386 systems. if (x >= 0) { return static_cast(x); } else { return -static_cast(-x); } Then there is also vtkFastNumericConversion.h, which is used mainly by vtkFixedPointVolumeRayCastMapper. So, yeah, lots of round/floor functions and they dont all have exactly the same roundoff/error behavior. But I should definitely unify the code between GridWarp and ImageReslice. Thanks for pointing that out. David From david.gobbi at gmail.com Thu Sep 23 19:27:36 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Sep 2010 17:27:36 -0600 Subject: [vtk-developers] ANN: VTK topic stage In-Reply-To: References: Message-ID: On Thu, Sep 23, 2010 at 2:06 PM, Marcus D. Hanwell wrote: > Hi, > I wanted to point out that the VTK topic stage is available for use to > anyone with push access to VTK's main git repository. At present there is > just one integration branch (master), and next will be added in the near > future. You can push topic branches to the topic stage, and using the simple > command line interface you can merge those topic branches into VTK's master > branch. > http://www.vtk.org/Wiki/VTK/Git#Topic_Stage > This is the only way to make merge commits in VTK, at present this is an > optional step for those wishing to use it. Now would be a great time to > start using the topic stage, and let us know of any issues you encounter. > CMake and Titan are already using the topic stage with master and next, if > you are curious to see how this is being employed elsewhere. > Thanks, > Marcus > -- > Marcus D. Hanwell, Ph.D. > R&D Engineer, Kitware Inc. > (518) 881-4937 Cool. I followed the instructions on the wiki and everything was easy, all I had to do was upgrade my "git" from 1.6 to 1.7. It was much easier to create and push a topic branch than it was to mess around with forks on github. David From david.gobbi at gmail.com Fri Sep 24 09:34:39 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 07:34:39 -0600 Subject: [vtk-developers] Removed "lib" prefix from python modules Message-ID: Hi All, I've made the bold move of removing the "lib" prefix from the python modules when they are built in unix-like environments. So "if os.name == 'posix':" in all the .py files that load the modules is no longer necessary. In order to minimize the breakage in external packages, I create symlinks in the bin directory: libvtkCommonPython.so -> vtkCommonPython.so This means that ParaView will not break (I've tested it) and hopefully other packages won't break, either. However, I'd recommend that all external packages switch their .py files and cmake files over to the new prefix-less style. David From marcus.hanwell at kitware.com Fri Sep 24 09:40:50 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 24 Sep 2010 09:40:50 -0400 Subject: [vtk-developers] Removed "lib" prefix from python modules In-Reply-To: References: Message-ID: On Fri, Sep 24, 2010 at 9:34 AM, David Gobbi wrote: > Hi All, > > I've made the bold move of removing the "lib" prefix from the python > modules when they are built in unix-like environments. So "if os.name > == 'posix':" in all the .py files that load the modules is no longer > necessary. > I think this is a great change, and it was on my todo list. > > In order to minimize the breakage in external packages, I create > symlinks in the bin directory: > libvtkCommonPython.so -> vtkCommonPython.so > > This means that ParaView will not break (I've tested it) and hopefully > other packages won't break, either. However, I'd recommend that all > external packages switch their .py files and cmake files over to the > new prefix-less style. > > I will take care of that in Titan. Thanks for pushing this in, I never liked the if/else logic necessary just to load a Python module. Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.marion at kitware.com Fri Sep 24 10:12:13 2010 From: pat.marion at kitware.com (pat marion) Date: Fri, 24 Sep 2010 10:12:13 -0400 Subject: [vtk-developers] Removed "lib" prefix from python modules In-Reply-To: References: Message-ID: Not sure if you've done this already David, but there are two files in paraview that will need updating: CoProcessing/CoProcessor/CMakeLists.txt:SET(PYTHON_MODULE_PREFIX ${CMAKE_SHARED_LIBRARY_PREFIX}) Utilities/VTKPythonWrapping/Executable/CMakeLists.txt: SET(PYTHON_MODULE_PREFIX "lib") PYTHON_MODULE_PREFIX can be left undefined, or set to the empty string. It is used by FindPythonLibs.cmake to create "init[prefix][modulename]()" references. Pat On Fri, Sep 24, 2010 at 9:40 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Fri, Sep 24, 2010 at 9:34 AM, David Gobbi wrote: > >> Hi All, >> >> I've made the bold move of removing the "lib" prefix from the python >> modules when they are built in unix-like environments. So "if os.name >> == 'posix':" in all the .py files that load the modules is no longer >> necessary. >> > > I think this is a great change, and it was on my todo list. > >> >> In order to minimize the breakage in external packages, I create >> symlinks in the bin directory: >> libvtkCommonPython.so -> vtkCommonPython.so >> >> This means that ParaView will not break (I've tested it) and hopefully >> other packages won't break, either. However, I'd recommend that all >> external packages switch their .py files and cmake files over to the >> new prefix-less style. >> >> I will take care of that in Titan. Thanks for pushing this in, I never > liked the if/else logic necessary just to load a Python module. > > Marcus > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 24 10:29:27 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 08:29:27 -0600 Subject: [vtk-developers] Removed "lib" prefix from python modules In-Reply-To: References: Message-ID: Hi Pat, I didn't change anything in ParaView, I'll leave that to the ParaView team. But here is a caveat: setting PYTHON_MODULE_PREFIX might not be enough because there is a bug in CMake's Modules/FindPythonLibs.cmake. It does not actually set the prefix of the module, it only sets the prefix in the name of the "init" function. I've fixed this bug in VTK's copy of FindPythonLibs.cmake, and someone should copy my changes from this file into CMake. Because of this bug in CMake, it might be necessary for ParaView to set a null prefix for every python module that it builds, i.e. SET_TARGET_PROPERTIES(... PROPERTIES PREFIX "") But maybe ParaView uses VTK's FindPythonLibs.cmake instead of the one from CMake... I don't know. David On Fri, Sep 24, 2010 at 8:12 AM, pat marion wrote: > Not sure if you've done this already David, but there are two files in > paraview that will need updating: > > CoProcessing/CoProcessor/CMakeLists.txt:SET(PYTHON_MODULE_PREFIX > ${CMAKE_SHARED_LIBRARY_PREFIX}) > Utilities/VTKPythonWrapping/Executable/CMakeLists.txt: > SET(PYTHON_MODULE_PREFIX "lib") > > PYTHON_MODULE_PREFIX can be left undefined, or set to the empty string.? It > is used by FindPythonLibs.cmake to create "init[prefix][modulename]()" > references. > > Pat From janagama_swapna at yahoo.com Fri Sep 24 10:34:51 2010 From: janagama_swapna at yahoo.com (Swapna Janagama) Date: Fri, 24 Sep 2010 07:34:51 -0700 (PDT) Subject: [vtk-developers] How to start Message-ID: <290158.81911.qm@web114711.mail.gq1.yahoo.com> Hi, I am new to VTK, The SnowFlake API and VTK.I am thinking to Write a simple multitouch application using SnowFlake that can be used to control a geometric object in a VTK application. Best Regards : Swapna Janagama -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Fri Sep 24 10:45:52 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 24 Sep 2010 10:45:52 -0400 Subject: [vtk-developers] Removed "lib" prefix from python modules In-Reply-To: References: Message-ID: On Fri, Sep 24, 2010 at 10:29 AM, David Gobbi wrote: > Hi Pat, > > I didn't change anything in ParaView, I'll leave that to the ParaView team. > > But here is a caveat: setting PYTHON_MODULE_PREFIX might not be > enough because there is a bug in CMake's Modules/FindPythonLibs.cmake. > It does not actually set the prefix of the module, it only sets the > prefix in the name of the "init" function. I've fixed this bug in > VTK's copy of FindPythonLibs.cmake, and someone should copy > my changes from this file into CMake. > I can take a look at that. > > Because of this bug in CMake, it might be necessary for ParaView to > set a null prefix for every python module that it builds, i.e. > > SET_TARGET_PROPERTIES(... PROPERTIES PREFIX "") > > But maybe ParaView uses VTK's FindPythonLibs.cmake instead of the > one from CMake... I don't know. > ParaView does use VTK's FindPythonLibs.cmake, and so this should also be fixed there. Marcus > > On Fri, Sep 24, 2010 at 8:12 AM, pat marion > wrote: > > Not sure if you've done this already David, but there are two files in > > paraview that will need updating: > > > > CoProcessing/CoProcessor/CMakeLists.txt:SET(PYTHON_MODULE_PREFIX > > ${CMAKE_SHARED_LIBRARY_PREFIX}) > > Utilities/VTKPythonWrapping/Executable/CMakeLists.txt: > > SET(PYTHON_MODULE_PREFIX "lib") > > > > PYTHON_MODULE_PREFIX can be left undefined, or set to the empty string. > It > > is used by FindPythonLibs.cmake to create "init[prefix][modulename]()" > > references. > > > > Pat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 24 10:57:27 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 08:57:27 -0600 Subject: [vtk-developers] Removed "lib" prefix from python modules In-Reply-To: References: Message-ID: On Fri, Sep 24, 2010 at 8:45 AM, Marcus D. Hanwell wrote: > On Fri, Sep 24, 2010 at 10:29 AM, David Gobbi wrote: >> >> But here is a caveat: setting PYTHON_MODULE_PREFIX might not be >> enough because there is a bug in CMake's Modules/FindPythonLibs.cmake. >> It does not actually set the prefix of the module, it only sets the >> prefix in the name of the "init" function. ?I've fixed this bug in >> VTK's copy of FindPythonLibs.cmake, and someone should copy >> my changes from this file into CMake. > > I can take a look at that. Another thing that FindPythonLibs.cmake does not do is set the suffix to ".pyd" on Windows. It didn't cross my mind when I was fixing the file, but since the ".dll" module suffix is officially deprecated by python, it might be good to have that in FindPythonLibs.cmake instead of scattered around various CMake files in various projects. David From daviddoria at gmail.com Fri Sep 24 11:30:50 2010 From: daviddoria at gmail.com (David Doria) Date: Fri, 24 Sep 2010 11:30:50 -0400 Subject: [vtk-developers] Fwd: [Paraview-developers] Moving vtkMemberFunctionCommand to VTK In-Reply-To: References: Message-ID: On Fri, Sep 24, 2010 at 10:57 AM, David Doria wrote: > A few days ago Pat Marion pointed out on the VTK devel list that > ParaView/Servers/Filters/vtkMemberFunctionCommand.h is a great way to > catch events with class member functions. I tried it out and it is > indeed fantastic! It lets me handle events in a much more structured > way. > > We would like to propose moving this file into VTK so that it can be > used by VTK-only applications (without copying the file into each one, > as I have been doing :) ). Are there any objections to doing this? > Maybe this should actually be done by one of the Paraview devels so > that the appropriate changes can be made to Paraview so that it can > still see the file properly. Any volunteers? > > Please let me know what you think. > > Thanks, > > David > > ---------- Forwarded message ---------- From: Utkarsh Ayachit Date: Fri, Sep 24, 2010 at 11:19 AM Subject: Re: [Paraview-developers] Moving vtkMemberFunctionCommand to VTK To: David Doria Cc: paraview-developers at paraview.org > > That sounds like a good idea. However, you may want to raise the question on the vtk-developers list to chalk out a cleaner API. This would the only code in VTK that requires passing (*this) as an argument which may be a bit non-conventional for VTK. > Utkarsh Please see the proposal and discussion above. Utkarsh sounds like he's on board with change, but would like to make sure no one has a problem with some specifics of the implementation. Would everyone take a look? If we don't hear anything by midweek, we'll assume the interface is acceptable and proceed with the move. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From daisy8738 at gmail.com Fri Sep 24 11:34:59 2010 From: daisy8738 at gmail.com (chen.zhong) Date: Fri, 24 Sep 2010 17:34:59 +0200 Subject: [vtk-developers] Fwd: [Paraview-developers] Moving vtkMemberFunctionCommand to VTK In-Reply-To: References: Message-ID: there is always a mistake with this sentence "vtkPointWidget bottomMoveWidget = new vtkPointWidget();" is there someone can tell me what is wrong? Moreover, private vtkPointWidget bottomMoveWidget = null; bottomMoveWidget = new vtkPointWidget(); is also wrong~! Thanks~! SIncerely, Chen 2010/9/24 David Doria > On Fri, Sep 24, 2010 at 10:57 AM, David Doria > wrote: > > A few days ago Pat Marion pointed out on the VTK devel list that > > ParaView/Servers/Filters/vtkMemberFunctionCommand.h is a great way to > > catch events with class member functions. I tried it out and it is > > indeed fantastic! It lets me handle events in a much more structured > > way. > > > > We would like to propose moving this file into VTK so that it can be > > used by VTK-only applications (without copying the file into each one, > > as I have been doing :) ). Are there any objections to doing this? > > Maybe this should actually be done by one of the Paraview devels so > > that the appropriate changes can be made to Paraview so that it can > > still see the file properly. Any volunteers? > > > > Please let me know what you think. > > > > Thanks, > > > > David > >> >> ---------- Forwarded message ---------- > > From: Utkarsh Ayachit > > Date: Fri, Sep 24, 2010 at 11:19 AM > > Subject: Re: [Paraview-developers] Moving vtkMemberFunctionCommand to VTK > > To: David Doria > > Cc: paraview-developers at paraview.org > > >> >> That sounds like a good idea. However, you may want to raise the > > question on the vtk-developers list to chalk out a cleaner API. This > > would the only code in VTK that requires passing (*this) as an > > argument which may be a bit non-conventional for VTK. > > >> Utkarsh > > > > Please see the proposal and discussion above. Utkarsh sounds like he's on > board with change, but would like to make sure no one has a problem with > some specifics of the implementation. Would everyone take a look? If we > don't hear anything by midweek, we'll assume the interface is acceptable and > proceed with the move. > > Thanks, > > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Fri Sep 24 11:54:36 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 24 Sep 2010 11:54:36 -0400 Subject: [vtk-developers] Charts and float/int conversion In-Reply-To: References: <4C993751.8070906@cox.net> Message-ID: On Tue, Sep 21, 2010 at 7:11 PM, David Gobbi wrote: > On Tue, Sep 21, 2010 at 4:53 PM, Jim Peterson wrote: > > David Gobbi wrote: > >> > >> inline vtkContext2D::FloatToInt(float x) > >> { > >> return static_cast(x + 1.0625) - 1; > >> } > >> > >> This provides a tolerance of 1/16 of a pixel for the float-to-int > >> conversion. The "1" and "- 1" ensure that float values in the range > >> [-1.0, 0.0] are rounded down, instead of being rounded toward zero. > >> > >> David > > > > David, > > pardon my ignorance, but if we are rounding float to int, why do we want > > -0.1 to round to -1 and not 0? in other words, why not x + 1.5 instead of > x > > + 1.0625? > > > > Thanks, > > Jim > > It all depends on what the rounding is being used for. When > rasterizing floating-point coordinates to the screen (i.e. to pixels), > it is convention to round down. > > The IEEE 754 standard describes five rounding modes, each of which is > valid for its intended uses: > 1) Round toward 0, which is C standard float-to-int > 2) Round towards -inf, which is like floor() > 3) Round towards +inf, which is like ceil() > 4) Round to nearest, towards even number if tie, default mode on many CPUs > 5) Round to nearest, away from zero if tie > > My favorite mode is round to nearest, and towards the higher of the > two integers in case of a tie. Unfortunately that isn't in the > standard. :P > > Thanks for the tips, I had been meaning to look into some of the rounding issues. I will test this out and seeing about getting it in. Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Fri Sep 24 11:55:44 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 24 Sep 2010 11:55:44 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: References: Message-ID: On Mon, Sep 20, 2010 at 4:02 PM, Eric E. Monson wrote: > Hey, > > In vtkChartParallelCoordinates the red boxes that show selection ranges are > stored in this->Storage->AxesSelections. This gets cleared on every call to > Update(), and I think this is a bit too aggressive since they end up being > cleared even when the window is just resized. > > I'm having some trouble deciding on what test to use, though. Maybe > something like this (attached) that (I think) tests whether the data has > been changed more recently than the chart was rebuilt? > > Yes, I think that was a little heavy handed. Let me test this out, but it looks like a reasonable criteria to use. Thanks, Marcus -- Marcus D. Hanwell, Ph.D. R&D Engineer, Kitware Inc. (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Sep 24 12:06:16 2010 From: sean at rogue-research.com (Sean McBride) Date: Fri, 24 Sep 2010 12:06:16 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> <20100923224518.806287166@mail.rogue-research.com> Message-ID: <20100924160616.1168749555@mail.rogue-research.com> On Thu, 23 Sep 2010 17:11:54 -0600, David Gobbi said: >Ugh. Yeah, if you really look hard you'll find tons of "Floor" and >"Round" definitions in VTK, either as inline functions or as >preprocessor macros. It is so hard to reach a consensus about the >best way to do these things. I didn't mean to imply that we should have one rounding to rule them all... >But I should definitely unify the code between GridWarp and >ImageReslice. Thanks for pointing that out. ... I mostly meant that copypasta is bad. If this one type of rounding/ flooring is useful in two places, it seems it should be in one single place. We could give it a particular name so that users know it's not a general-case rounder. ex: vtkFunkyFloor() or whatever. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Fri Sep 24 12:13:02 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 10:13:02 -0600 Subject: [vtk-developers] Charts and float/int conversion In-Reply-To: References: <4C993751.8070906@cox.net> Message-ID: On Fri, Sep 24, 2010 at 9:54 AM, Marcus D. Hanwell wrote: > On Tue, Sep 21, 2010 at 7:11 PM, David Gobbi wrote: >> >> On Tue, Sep 21, 2010 at 4:53 PM, Jim Peterson wrote: >> > David Gobbi wrote: >> >> >> >> inline vtkContext2D::FloatToInt(float x) >> >> { >> >> ?return static_cast(x + 1.0625) - 1; >> >> } >> >> >> >> This provides a tolerance of 1/16 of a pixel for the float-to-int >> >> conversion. The "1" and "- 1" ensure that float values in the range >> >> [-1.0, 0.0] are rounded down, instead of being rounded toward zero. >> >> >> >> ?David >> > >> > David, >> > pardon my ignorance, but if we are rounding float to int, why do we want >> > -0.1 to round to -1 and not 0? in other words, why not x + 1.5 instead >> > of x >> > + 1.0625? >> > >> > Thanks, >> > Jim >> >> It all depends on what the rounding is being used for. ?When >> rasterizing floating-point coordinates to the screen (i.e. to pixels), >> it is convention to round down. >> >> The IEEE 754 standard describes five rounding modes, each of which is >> valid for its intended uses: >> 1) Round toward 0, which is C standard float-to-int >> 2) Round towards -inf, which is like floor() >> 3) Round towards +inf, which is like ceil() >> 4) Round to nearest, towards even number if tie, default mode on many CPUs >> 5) Round to nearest, away from zero if tie >> >> My favorite mode is round to nearest, and towards the higher of the >> two integers in case of a tie. ?Unfortunately that isn't in the >> standard. :P >> > Thanks for the tips, I had been meaning to look into some of the rounding > issues. I will test this out and seeing about getting it in. > Marcus I already did a bit of testing, when I was trying to find the bug that caused the ScientificPlot test to fail on Windows. That problem turned out just to be a pow(10.0f, -order) where there should have been a pow(10.0, -order) for greater precision. I can commit my experiments as topic for you to look at. I'll call it charts-float-to-int. David From sean at rogue-research.com Fri Sep 24 12:37:09 2010 From: sean at rogue-research.com (Sean McBride) Date: Fri, 24 Sep 2010 12:37:09 -0400 Subject: [vtk-developers] vtkMatrix3x3 vs vtkMatrix4x4 creation Message-ID: <20100924163709.889347151@mail.rogue-research.com> Hi all, Both vtkMatrix3x3.h and vtkMatrix4x4.h document their creation API like so: // Construct a 3x3 identity matrix. static vtkMatrix3x3 *New(); // Construct a 4x4 identity matrix. static vtkMatrix4x4 *New(); But looking at the implementations, it seems that creating a 3x3 _does_ create an identity matrix, but creating a 4x4 does _not_. It seems weird that two very similar clases diverge in this way. Why is this? And what should be done? I propose changing vtkMatrix4x4 to conform to its documented behaviour. 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 utkarsh.ayachit at kitware.com Fri Sep 24 12:38:46 2010 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 24 Sep 2010 12:38:46 -0400 Subject: [vtk-developers] [Paraview-developers] Moving vtkMemberFunctionCommand to VTK In-Reply-To: References: Message-ID: Couple of suggestions: 1> I think we should change the API to be: SetCallback(ClassT* ...) rather than SetCallback(ClassT& ..) That makes the mode more VTK-like when reading: I'd prefer: obs->SetCallback(this, &vtkMySelf::CallbackHandler); to the current implementation i.e.: obs->SetCallback(*this, &vtkMySelf::CallbackHandler); 2> We should use vtkWeakPointer for the Object ptr, to avoid dangling pointers. 3> The documentation needs to be fixed. Currently there are errors in it, the usage described does not really match the real usage :). 4> Another possibility is simply moving the code to vtkCommand.h. Like David said, let's wait a week to see if people respond, otherwise I will make those changes and move the header to VTK/Common. Utkarsh On Fri, Sep 24, 2010 at 11:30 AM, David Doria wrote: > On Fri, Sep 24, 2010 at 10:57 AM, David Doria wrote: >> A few days ago Pat Marion pointed out on the VTK devel list that >> ParaView/Servers/Filters/vtkMemberFunctionCommand.h is a great way to >> catch events with class member functions. I tried it out and it is >> indeed fantastic! It lets me handle events in a much more structured >> way. >> >> We would like to propose moving this file into VTK so that it can be >> used by VTK-only applications (without copying the file into each one, >> as I have been doing :) ). Are there any objections to doing this? >> Maybe this should actually be done by one of the Paraview devels so >> that the appropriate changes can be made to Paraview so that it can >> still see the file properly. Any volunteers? >> >> Please let me know what you think. >> >> Thanks, >> >> David >> >> ---------- Forwarded message ---------- >> >> From: Utkarsh Ayachit >> >> Date: Fri, Sep 24, 2010 at 11:19 AM >> >> Subject: Re: [Paraview-developers] Moving vtkMemberFunctionCommand to VTK >> >> To: David Doria >> >> Cc: paraview-developers at paraview.org >> >> That sounds like a good idea. However, you may want to raise the >> >> question on ?the vtk-developers list to chalk out a cleaner API. This >> >> would the only code in VTK that requires passing (*this) as an >> >> argument which may be a bit non-conventional for VTK. >> >> Utkarsh > > Please see the proposal and discussion above. Utkarsh sounds like he's on > board with change, but would like to make sure no one has a problem with > some specifics of the implementation. Would everyone take a look? If we > don't hear anything by midweek, we'll assume the interface is acceptable and > proceed with the move. > Thanks, > > David From david.gobbi at gmail.com Fri Sep 24 12:46:19 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 10:46:19 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100924160616.1168749555@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> <20100923224518.806287166@mail.rogue-research.com> <20100924160616.1168749555@mail.rogue-research.com> Message-ID: On Fri, Sep 24, 2010 at 10:06 AM, Sean McBride wrote: > On Thu, 23 Sep 2010 17:11:54 -0600, David Gobbi said: >>But I should definitely unify the code between GridWarp and >>ImageReslice. ?Thanks for pointing that out. > > ... I mostly meant that copypasta is bad. ?If this one type of rounding/ > flooring is useful in two places, it seems it should be in one single > place. ?We could give it a particular name so that users know it's not a > general-case rounder. ?ex: vtkFunkyFloor() or whatever. I know, I know. I hate doing copy-paste. But I started thinking, what header file should I add it to? I just couldn't bring myself to make vtkMath any more cluttered, and certainly didn't want to make a new header file. It was a judgement call. David From marcus.hanwell at kitware.com Fri Sep 24 13:10:01 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 24 Sep 2010 13:10:01 -0400 Subject: [vtk-developers] vtkMatrix3x3 vs vtkMatrix4x4 creation In-Reply-To: <20100924163709.889347151@mail.rogue-research.com> References: <20100924163709.889347151@mail.rogue-research.com> Message-ID: On Fri, Sep 24, 2010 at 12:37 PM, Sean McBride wrote: > Hi all, > > Both vtkMatrix3x3.h and vtkMatrix4x4.h document their creation API like so: > > // Construct a 3x3 identity matrix. > static vtkMatrix3x3 *New(); > > // Construct a 4x4 identity matrix. > static vtkMatrix4x4 *New(); > > But looking at the implementations, it seems that creating a 3x3 _does_ > create an identity matrix, but creating a 4x4 does _not_. > > It seems weird that two very similar clases diverge in this way. Why is > this? And what should be done? I propose changing vtkMatrix4x4 to > conform to its documented behaviour. > > I wrote the 3x3 and it did not occur to me not to initialize it to the identity. It came much later than the 4x4 matrix, and at the time I did not want to change too much in the 4x4 class as so much uses it. What you propose certainly seems reasonable to me. Marcus -- Marcus D. Hanwell, Ph.D. R&D Engineer, Kitware Inc. (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From emonson at cs.duke.edu Fri Sep 24 13:21:49 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Fri, 24 Sep 2010 13:21:49 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: References: Message-ID: Yes, please test it out because I'm not really sure what the right criteria is. I'm fine as long as things like resizing the windows don't clear out the axes selections. Thanks for taking a look, -Eric On Sep 24, 2010, at 11:55 AM, Marcus D. Hanwell wrote: > On Mon, Sep 20, 2010 at 4:02 PM, Eric E. Monson wrote: > Hey, > > In vtkChartParallelCoordinates the red boxes that show selection ranges are stored in this->Storage->AxesSelections. This gets cleared on every call to Update(), and I think this is a bit too aggressive since they end up being cleared even when the window is just resized. > > I'm having some trouble deciding on what test to use, though. Maybe something like this (attached) that (I think) tests whether the data has been changed more recently than the chart was rebuilt? > > Yes, I think that was a little heavy handed. Let me test this out, but it looks like a reasonable criteria to use. > > Thanks, > > Marcus > -- > Marcus D. Hanwell, Ph.D. > R&D Engineer, Kitware Inc. > (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 24 13:32:35 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 11:32:35 -0600 Subject: [vtk-developers] vtkMatrix3x3 vs vtkMatrix4x4 creation In-Reply-To: <20100924163709.889347151@mail.rogue-research.com> References: <20100924163709.889347151@mail.rogue-research.com> Message-ID: On Fri, Sep 24, 2010 at 10:37 AM, Sean McBride wrote: > But looking at the implementations, it seems that creating a 3x3 _does_ > create an identity matrix, but creating a 4x4 does _not_. It looks to me like both of them create an identity matrix. The 4x4 has the constructor in the header, and the 3x3 has the constructor in the .cxx, but otherwise they look identical. David From marcus.hanwell at kitware.com Fri Sep 24 15:08:19 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 24 Sep 2010 15:08:19 -0400 Subject: [vtk-developers] Removed "lib" prefix from python modules In-Reply-To: References: Message-ID: On Fri, Sep 24, 2010 at 10:57 AM, David Gobbi wrote: > On Fri, Sep 24, 2010 at 8:45 AM, Marcus D. Hanwell > wrote: > > On Fri, Sep 24, 2010 at 10:29 AM, David Gobbi > wrote: > >> > >> But here is a caveat: setting PYTHON_MODULE_PREFIX might not be > >> enough because there is a bug in CMake's Modules/FindPythonLibs.cmake. > >> It does not actually set the prefix of the module, it only sets the > >> prefix in the name of the "init" function. I've fixed this bug in > >> VTK's copy of FindPythonLibs.cmake, and someone should copy > >> my changes from this file into CMake. > > > > I can take a look at that. > > Another thing that FindPythonLibs.cmake does not do is set the suffix > to ".pyd" on Windows. It didn't cross my mind when I was fixing the > file, but since the ".dll" module suffix is officially deprecated by > python, it might be good to have that in FindPythonLibs.cmake instead > of scattered around various CMake files in various projects. > > I just pushed the updated FindPythonLibs into next for CMake, thanks for the fixes. I also fixed up ParaView's build system to take account of the new changes and will be looking at Titan next. Thanks, Marcus -- Marcus D. Hanwell, Ph.D. R&D Engineer, Kitware Inc. (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Sep 24 15:16:16 2010 From: sean at rogue-research.com (Sean McBride) Date: Fri, 24 Sep 2010 15:16:16 -0400 Subject: [vtk-developers] vtkMatrix3x3 vs vtkMatrix4x4 creation In-Reply-To: References: <20100924163709.889347151@mail.rogue-research.com> Message-ID: <20100924191616.1927470583@mail.rogue-research.com> On Fri, 24 Sep 2010 11:32:35 -0600, David Gobbi said: >> But looking at the implementations, it seems that creating a 3x3 _does_ >> create an identity matrix, but creating a 4x4 does _not_. > >It looks to me like both of them create an identity matrix. The 4x4 >has the constructor in the header, and the 3x3 has the constructor in >the .cxx, but otherwise they look identical. Ack! You're right... well now I feel dumb. (I'm really not used to implementation being in interface files, as I mostly work in Objective-C where this doesn't happen.) Sorry for the noise. -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Fri Sep 24 15:31:00 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 13:31:00 -0600 Subject: [vtk-developers] vtkMatrix3x3 vs vtkMatrix4x4 creation In-Reply-To: <20100924191616.1927470583@mail.rogue-research.com> References: <20100924163709.889347151@mail.rogue-research.com> <20100924191616.1927470583@mail.rogue-research.com> Message-ID: On Fri, Sep 24, 2010 at 1:16 PM, Sean McBride wrote: > Sorry for the noise. I was confused when I read through those files, too. The Zero() method is at the top of the .cxx file, right where I would expect the constructor to be! David From bill.lorensen at gmail.com Fri Sep 24 15:46:53 2010 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 24 Sep 2010 15:46:53 -0400 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: <20100924160616.1168749555@mail.rogue-research.com> References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> <20100923224518.806287166@mail.rogue-research.com> <20100924160616.1168749555@mail.rogue-research.com> Message-ID: We went through this rounding mess in ITK about a year ago. We have two rounding functions: RoundHalfIntegerUp with is also called Round Round towards nearest integer and RoundHalfIntegerToEven halfway cases are rounded towards the nearest even integer, e.g. * RoundHalfIntegerToEven( 1.5) == 2 * RoundHalfIntegerToEven(-1.5) == -2 * RoundHalfIntegerToEven( 2.5) == 2 * RoundHalfIntegerToEven( 3.5) == 4 They are implemented in what I thin is a complex way, but it seems to work cross platform. The code is in ITK/Code/Common/itkMath.h The implementation are in itkMathDetail. It supports various hardware accelerations. Bill On Fri, Sep 24, 2010 at 12:06 PM, Sean McBride wrote: > On Thu, 23 Sep 2010 17:11:54 -0600, David Gobbi said: > >>Ugh. ?Yeah, if you really look hard you'll find tons of "Floor" and >>"Round" definitions in VTK, either as inline functions or as >>preprocessor macros. ?It is so hard to reach a consensus about the >>best way to do these things. > > I didn't mean to imply that we should have one rounding to rule them all... > >>But I should definitely unify the code between GridWarp and >>ImageReslice. ?Thanks for pointing that out. > > ... I mostly meant that copypasta is bad. ?If this one type of rounding/ > flooring is useful in two places, it seems it should be in one single > place. ?We could give it a particular name so that users know it's not a > general-case rounder. ?ex: vtkFunkyFloor() or whatever. > > -- > ____________________________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > From david.gobbi at gmail.com Fri Sep 24 16:28:14 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 14:28:14 -0600 Subject: [vtk-developers] vtkImageReslice performance questions/improvemnts In-Reply-To: References: <20100914144357.1007046035@mail.rogue-research.com> <20100921233203.2128610341@mail.rogue-research.com> <20100921235158.1185583542@mail.rogue-research.com> <20100922000848.56856200@mail.rogue-research.com> <20100923224518.806287166@mail.rogue-research.com> <20100924160616.1168749555@mail.rogue-research.com> Message-ID: On Fri, Sep 24, 2010 at 1:46 PM, Bill Lorensen wrote: > We went through this rounding mess in ITK about a year ago. ?We have > two rounding functions: > RoundHalfIntegerUp with is also called Round > ?Round towards nearest integer My favorite. I call it "round just like we were taught in grade school". > and > RoundHalfIntegerToEven > ?halfway cases are rounded towards the nearest even ?integer, e.g. > ?* ? ? ? ? ?RoundHalfIntegerToEven( 1.5) == ?2 > ?* ? ? ? ? ?RoundHalfIntegerToEven(-1.5) == -2 > ?* ? ? ? ? ?RoundHalfIntegerToEven( 2.5) == ?2 > ?* ? ? ? ? ?RoundHalfIntegerToEven( 3.5) == ?4 > > They are implemented in what I thin is a complex way, but it seems to > work cross platform. > > The code is in ITK/Code/Common/itkMath.h > > The implementation are in itkMathDetail. It supports various hardware > accelerations. I think it would be great if VTK inherited a version of this that was trimmed down to "double" and "int". These efficient rounding computations are the one thing that you just can't do without inline assembler instructions. The pure "c++" implementations look decent, too. David From david.gobbi at gmail.com Fri Sep 24 18:56:59 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Sep 2010 16:56:59 -0600 Subject: [vtk-developers] How to start In-Reply-To: <290158.81911.qm@web114711.mail.gq1.yahoo.com> References: <290158.81911.qm@web114711.mail.gq1.yahoo.com> Message-ID: Hi Swapna, You might want to look at what this person has done: http://www.vtk.org/pipermail/vtkusers/2010-September/111557.html - David On Fri, Sep 24, 2010 at 8:34 AM, Swapna Janagama wrote: > Hi, > > I am new to VTK, > > The SnowFlake API and VTK.I am thinking to Write a simple multitouch > application using SnowFlake that can be used to control a geometric object > in a VTK application. > > Best Regards : > Swapna Janagama > > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From david.gobbi at gmail.com Sat Sep 25 11:19:55 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 25 Sep 2010 09:19:55 -0600 Subject: [vtk-developers] Fwd: Handling multi-touch gestures in VTK In-Reply-To: References: Message-ID: Hi Pierre, These multi-touch gestures are a must-have. I've rebased your code against the VTK head and set up a branch on github: http://github.com/dgobbi/VTK/commits/multi-touch I've tried it with Cocoa, and the code works well except for swipes: iren->SetSwipeGestureDirection(x) with x=up, down, left, or right I'm not familiar with multi-touch APIs, but I do not think that this is not the right approach. But keep going, I'm eager to see more. As soon as the swipe/pan is working nicely, I'd love to see this pushed into VTK. David On Wed, Sep 15, 2010 at 5:46 AM, Pierre Fillard wrote: > I forward this mail to the VTK developers, as you may be interested as well. > > Pierre. > > ---------- Forwarded message ---------- > From: Pierre Fillard > Date: Wed, Sep 15, 2010 at 11:06 AM > Subject: Handling multi-touch gestures in VTK > To: vtkusers at vtk.org > > > Hello, > > I always wanted to use multi-touch gestures such as the pinching, rotating, > or swiping features of recent apple's computers in VTK to control zooming, > spining and panning of my objects in 3D. > > Maybe this was already integrated in the VTK master branch (though I didn't > see it) or planned to be integrated. But to support my needs, I added > support for those new gesture interactions in VTK by adding three new events > in the vtkCommand class: > - PinchGestureEvent > - RotateGestureEvent > - SwipeGestureEvent > > I wrote interfaces in the vtkCocoaGLView class to translate Cocoa's events > into those, and I wrote callbacks to handle them properly in > vtkInteractorStyleTrackballCamera just as a proof of concept. > Moreover, Qt 4.6 proposes gesture events (QGestureEvents) that I properly > interfaced in the QVTKWidget class. > > Thus, with these modifications, using either a Cocoa RenderWindow or a > QVTKWidget instance, one is able to zoom by pinching, rotate by drawing a > circle on a multi-touch device or?panning?by (long-)taping on the trackpad. > > If anyone is interested, I would be happy to share the code, or even give it > to kitware for review / integration. > > Anyone can access it anonymously here. These are just files which should be > replaced in your VTK source tree: > svn checkout > svn://scm.gforge.inria.fr/svn/parietal-public/Utilities/VTKMultiTouch > > Note that modifications are based on VTK 5.6 and Qt 4.6. And you need a > multi-touch device, of course. > > > Cheers, > Pierre. > > -- > Pierre Fillard, Ph.D., > Research Scientist > INRIA Parietal - Neurospin > B?t 145, Point Courrier 156 > 91191 Gif/Yvette, France > tel: +33 1 69 08 79 92 > > > > -- > Pierre Fillard, Ph.D., > Research Scientist > INRIA Parietal - Neurospin > B?t 145, Point Courrier 156 > 91191 Gif/Yvette, France > tel: +33 1 69 08 79 92 > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > From david.gobbi at gmail.com Sat Sep 25 11:27:08 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 25 Sep 2010 09:27:08 -0600 Subject: [vtk-developers] Fwd: Handling multi-touch gestures in VTK In-Reply-To: References: Message-ID: On Sat, Sep 25, 2010 at 9:19 AM, David Gobbi wrote: > > ...but I do not think that this is not the right approach. Oops. I didn't proofread well enough. It should say "I do not think this is the right approach". David From marcus.hanwell at kitware.com Sat Sep 25 11:32:05 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Sat, 25 Sep 2010 11:32:05 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: References: Message-ID: <201009251132.07145.marcus.hanwell@kitware.com> On Friday 24 September 2010 13:21:49 Eric E. Monson wrote: > Yes, please test it out because I'm not really sure what the right criteria > is. I'm fine as long as things like resizing the windows don't clear out > the axes selections. > It turned out the original patch didn't work so well here, but I just committed a fix (9f1620d) that seems to work very well here, and ties the logic to the axes on which the selections depend. Let me know how this looks. Thanks, Marcus From daviddoria at gmail.com Sun Sep 26 19:04:19 2010 From: daviddoria at gmail.com (David Doria) Date: Sun, 26 Sep 2010 19:04:19 -0400 Subject: [vtk-developers] [Paraview-developers] Moving vtkMemberFunctionCommand to VTK In-Reply-To: References: Message-ID: On Fri, Sep 24, 2010 at 12:38 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Couple of suggestions: > > 1> I think we should change the API to be: > > SetCallback(ClassT* ...) rather than SetCallback(ClassT& ..) > > That makes the mode more VTK-like when reading: > > I'd prefer: > > obs->SetCallback(this, &vtkMySelf::CallbackHandler); > > to the current implementation i.e.: > > obs->SetCallback(*this, &vtkMySelf::CallbackHandler); > > 2> We should use vtkWeakPointer for the Object ptr, to avoid dangling > pointers. > > 3> The documentation needs to be fixed. Currently there are errors in > it, the usage described does not really match the real usage :). > > 4> Another possibility is simply moving the code to vtkCommand.h. > > Like David said, let's wait a week to see if people respond, otherwise > I will make those changes and move the header to VTK/Common. > > Utkarsh > > Is there a way to skip the adapter all together? That is, rather than: adapter = vtkMemberFunctionCommand::New(); adapter->SetCallback(*this, &CustomStyle::CatchWidgetEvent); tracer->AddObserver(vtkCommand::EndInteractionEvent, this->Adapter); could we just do something like: tracer->Add*Class* Observer(vtkCommand::EndInteractionEvent, CatchWidgetEvent); and have it automatically deal with the 'this' pointer and the name of the class? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Sep 27 09:14:44 2010 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 27 Sep 2010 09:14:44 -0400 Subject: [vtk-developers] [Paraview-developers] Moving vtkMemberFunctionCommand to VTK In-Reply-To: References: Message-ID: Not a bad idea at all. Internally, we can still do what we do currently to avoid making any dramatic changes. But, API-wise will make our lives much easier. Let's hope some of the VTK veterans comment :). Utkarsh On Sun, Sep 26, 2010 at 7:04 PM, David Doria wrote: > On Fri, Sep 24, 2010 at 12:38 PM, Utkarsh Ayachit > wrote: >> >> Couple of suggestions: >> >> 1> I think we should change the API to be: >> >> SetCallback(ClassT* ...) rather than SetCallback(ClassT& ..) >> >> That makes the mode more VTK-like when reading: >> >> I'd prefer: >> >> obs->SetCallback(this, &vtkMySelf::CallbackHandler); >> >> to the current implementation i.e.: >> >> obs->SetCallback(*this, &vtkMySelf::CallbackHandler); >> >> 2> We should use vtkWeakPointer for the Object ptr, to avoid dangling >> pointers. >> >> 3> The documentation needs to be fixed. Currently there are errors in >> it, the usage described does not really match the real usage :). >> >> 4> Another possibility is simply moving the code to vtkCommand.h. >> >> Like David said, let's wait a week to see if people respond, otherwise >> I will make those changes and move the header to VTK/Common. >> >> Utkarsh >> > > Is there a way to skip the adapter all together? That is, rather than: > adapter = vtkMemberFunctionCommand::New(); > adapter->SetCallback(*this, &CustomStyle::CatchWidgetEvent); > tracer->AddObserver(vtkCommand::EndInteractionEvent, this->Adapter); > could we just do something like: > tracer->AddClassObserver(vtkCommand::EndInteractionEvent,?CatchWidgetEvent); > and have it automatically deal with the 'this' pointer and the name of the > class? > David From emonson at cs.duke.edu Mon Sep 27 09:43:04 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Mon, 27 Sep 2010 09:43:04 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: <201009251132.07145.marcus.hanwell@kitware.com> References: <201009251132.07145.marcus.hanwell@kitware.com> Message-ID: <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> Hey Marcus, That looks great -- thanks for figuring out the right way to do it. I'm having a strange problem after rebuilding, though: I have a variant on the parallel coordinates chart that draws some extra decorations on the plot. One of these is a semi-transparent white rectangle. Before the paint calls I set painter->GetBrush()->SetColor(254, 254, 254, 150); painter->GetPen()->SetLineType(0); but the rectangle now shows up with a black outline around it... Has there been some change to the 2D drawing classes lately that might be causing this? (I can set the pen opacity to 0 to get rid of this black border line, but it just started showing up with this pull.) Talk to you later, -Eric On Sep 25, 2010, at 11:32 AM, Marcus D. Hanwell wrote: > On Friday 24 September 2010 13:21:49 Eric E. Monson wrote: >> Yes, please test it out because I'm not really sure what the right criteria >> is. I'm fine as long as things like resizing the windows don't clear out >> the axes selections. >> > It turned out the original patch didn't work so well here, but I just > committed a fix (9f1620d) that seems to work very well here, and ties the logic > to the axes on which the selections depend. > > Let me know how this looks. > > Thanks, > > Marcus From marcus.hanwell at kitware.com Mon Sep 27 10:18:48 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Sep 2010 10:18:48 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> References: <201009251132.07145.marcus.hanwell@kitware.com> <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> Message-ID: On Mon, Sep 27, 2010 at 9:43 AM, Eric E. Monson wrote: > Hey Marcus, > > That looks great -- thanks for figuring out the right way to do it. > > I'm having a strange problem after rebuilding, though: I have a variant on > the parallel coordinates chart that draws some extra decorations on the > plot. One of these is a semi-transparent white rectangle. Before the paint > calls I set > > painter->GetBrush()->SetColor(254, 254, 254, 150); > painter->GetPen()->SetLineType(0); > > but the rectangle now shows up with a black outline around it... > > Has there been some change to the 2D drawing classes lately that might be > causing this? (I can set the pen opacity to 0 to get rid of this black > border line, but it just started showing up with this pull.) > > Over the weekend I spent some time refactoring the 2D API in order to optimize some of the drawing operations (ellipse rendering in particular). Could you send me all of that block of rendering code? It would be good to add it to a regression test, as everything seemed to be coming back clear from the regression tests. Thanks, Marcus -- Marcus D. Hanwell, Ph.D. R&D Engineer, Kitware Inc. (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From emonson at cs.duke.edu Mon Sep 27 10:27:35 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Mon, 27 Sep 2010 10:27:35 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: References: <201009251132.07145.marcus.hanwell@kitware.com> <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> Message-ID: Here's the block that was ending up with with a black line around it. Setting the pen opacity to zero (after setting the line type) works fine for getting rid of the black line. Thanks, -Eric // Semi-transparent box over non-valid scales if (this->DrawSets) { int oldLineType = painter->GetPen()->GetLineType(); painter->GetBrush()->SetColor(254, 254, 254, 150); painter->GetPen()->SetLineType(0); int opaquePadding = 4; // extra padding so axes and points themselves are covered for (int i = 0; i < this->VisibleColumns->GetNumberOfTuples(); i+=this->NumPerSet) { if ((i+this->NumPerSet-1) <= static_cast(this->Storage->Axes.size()) && (i/this->NumPerSet == this->CurrentScale+1)) // opaque on next scale { vtkAxis* axis0 = this->Storage->Axes[i]; vtkAxis* axis1 = this->Storage->Axes[this->Storage->Axes.size()-1]; painter->DrawRect(axis0->GetPoint1()[0]-opaquePadding, this->Point1[1]-opaquePadding, axis1->GetPoint1()[0]-axis0->GetPoint1()[0]+(2*opaquePadding), this->Point2[1]-this->Point1[1]+(2*opaquePadding)); } } painter->GetPen()->SetLineType(oldLineType); } On Sep 27, 2010, at 10:18 AM, Marcus D. Hanwell wrote: > On Mon, Sep 27, 2010 at 9:43 AM, Eric E. Monson wrote: > Hey Marcus, > > That looks great -- thanks for figuring out the right way to do it. > > I'm having a strange problem after rebuilding, though: I have a variant on the parallel coordinates chart that draws some extra decorations on the plot. One of these is a semi-transparent white rectangle. Before the paint calls I set > > painter->GetBrush()->SetColor(254, 254, 254, 150); > painter->GetPen()->SetLineType(0); > > but the rectangle now shows up with a black outline around it... > > Has there been some change to the 2D drawing classes lately that might be causing this? (I can set the pen opacity to 0 to get rid of this black border line, but it just started showing up with this pull.) > > Over the weekend I spent some time refactoring the 2D API in order to optimize some of the drawing operations (ellipse rendering in particular). Could you send me all of that block of rendering code? It would be good to add it to a regression test, as everything seemed to be coming back clear from the regression tests. > > Thanks, > > Marcus > -- > Marcus D. Hanwell, Ph.D. > R&D Engineer, Kitware Inc. > (518) 881-4937 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Sep 27 12:53:27 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 27 Sep 2010 10:53:27 -0600 Subject: [vtk-developers] Added github info to wiki Message-ID: I've added a section about github to the VTK wiki: http://www.vtk.org/Wiki/VTK/Git#Github Can someone at Kitware take a look to make sure that it is correct? Thanks, David From sean at rogue-research.com Mon Sep 27 13:28:27 2010 From: sean at rogue-research.com (Sean McBride) Date: Mon, 27 Sep 2010 13:28:27 -0400 Subject: [vtk-developers] intermittant dashboard failure with java wrapping Message-ID: <20100927172827.1765916953@mail.rogue-research.com> Hi all, For a few weeks now, some of our dashboards have been giving errors like this: /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ vtkVTKJavaRenderingDriver.java:163: cannot access vtk.vtkTransformInterpolator bad class file: /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ vtkTransformInterpolator.class class file contains wrong class: vtk.vtkTextureObject Please remove or make sure it appears in the correct subdirectory of the classpath. dummy = new vtkTransformInterpolator(); ^ 1 error For example, today here: Anyone have any ideas why? -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From marcus.hanwell at kitware.com Mon Sep 27 16:02:33 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Sep 2010 16:02:33 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: References: <201009251132.07145.marcus.hanwell@kitware.com> <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> Message-ID: Hi Eric, Good catch! You are abusing the line type to get rid of the outline, and that was not getting set correctly after I refactored the code. If you pull and rebuild now commit 25b58dd should take care of that. Thanks for catching this - I will adjust one of the unit tests to use the line types so that this will be caught in future. Marcus On Mon, Sep 27, 2010 at 10:27 AM, Eric E. Monson wrote: > Here's the block that was ending up with with a black line around > it. Setting the pen opacity to zero (after setting the line type) works fine > for getting rid of the black line. > > Thanks, > -Eric > > > // Semi-transparent box over non-valid scales > if (this->DrawSets) > { > int oldLineType = painter->GetPen()->GetLineType(); > > > painter->GetBrush()->SetColor(254, 254, 254, 150); > painter->GetPen()->SetLineType(0); > int opaquePadding = 4; // extra padding so axes and points themselves > are covered > for (int i = 0; i < this->VisibleColumns->GetNumberOfTuples(); > i+=this->NumPerSet) > { > if ((i+this->NumPerSet-1) <= > static_cast(this->Storage->Axes.size()) && > (i/this->NumPerSet == this->CurrentScale+1)) // opaque on next > scale > { > vtkAxis* axis0 = this->Storage->Axes[i]; > vtkAxis* axis1 = this->Storage->Axes[this->Storage->Axes.size()-1]; > painter->DrawRect(axis0->GetPoint1()[0]-opaquePadding, > this->Point1[1]-opaquePadding, > > axis1->GetPoint1()[0]-axis0->GetPoint1()[0]+(2*opaquePadding), > > this->Point2[1]-this->Point1[1]+(2*opaquePadding)); > } > } > > painter->GetPen()->SetLineType(oldLineType); > > } > > > On Sep 27, 2010, at 10:18 AM, Marcus D. Hanwell wrote: > > On Mon, Sep 27, 2010 at 9:43 AM, Eric E. Monson wrote: > >> Hey Marcus, >> >> That looks great -- thanks for figuring out the right way to do it. >> >> I'm having a strange problem after rebuilding, though: I have a variant on >> the parallel coordinates chart that draws some extra decorations on the >> plot. One of these is a semi-transparent white rectangle. Before the paint >> calls I set >> >> painter->GetBrush()->SetColor(254, 254, 254, 150); >> painter->GetPen()->SetLineType(0); >> >> but the rectangle now shows up with a black outline around it... >> >> Has there been some change to the 2D drawing classes lately that might be >> causing this? (I can set the pen opacity to 0 to get rid of this black >> border line, but it just started showing up with this pull.) >> >> Over the weekend I spent some time refactoring the 2D API in order to > optimize some of the drawing operations (ellipse rendering in particular). > Could you send me all of that block of rendering code? It would be good to > add it to a regression test, as everything seemed to be coming back clear > from the regression tests. > > Thanks, > > Marcus > -- > Marcus D. Hanwell, Ph.D. > R&D Engineer, Kitware Inc. > (518) 881-4937 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Mon Sep 27 16:05:22 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Sep 2010 16:05:22 -0400 Subject: [vtk-developers] ToParent() vs. ToParentCoordinates() In-Reply-To: References: Message-ID: On Thu, Sep 23, 2010 at 10:35 AM, David Gobbi wrote: > Hi Jeff, > > I notice that the new Context classes use methods like "ToParent()", > "FromParent()" etc. for coordinate transformations. > > Don't short, non-descriptive method names go against the VTK style > guidelines? Names like ToParentCoordinates() would have a more > obvious meaning. > > Hi David, As part of some work refactoring I modified those functions - I used MapToParent as it is shorter, and hopefully just as descriptive. Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Sep 27 16:12:56 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 27 Sep 2010 14:12:56 -0600 Subject: [vtk-developers] ToParent() vs. ToParentCoordinates() In-Reply-To: References: Message-ID: On Mon, Sep 27, 2010 at 2:05 PM, Marcus D. Hanwell wrote: > > Hi David, > As part of some work refactoring I modified those functions - I used > MapToParent as it is shorter, and hopefully just as descriptive. No, you have to call it "TransformChildCoordinatesToParentCoordinates()" or else no-one will know that the method is doing! ;) David From marcus.hanwell at kitware.com Mon Sep 27 16:16:44 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Sep 2010 16:16:44 -0400 Subject: [vtk-developers] ToParent() vs. ToParentCoordinates() In-Reply-To: References: Message-ID: On Mon, Sep 27, 2010 at 4:12 PM, David Gobbi wrote: > On Mon, Sep 27, 2010 at 2:05 PM, Marcus D. Hanwell > wrote: > > > > Hi David, > > As part of some work refactoring I modified those functions - I used > > MapToParent as it is shorter, and hopefully just as descriptive. > > No, you have to call it > "TransformChildCoordinatesToParentCoordinates()" > or else no-one will know that the method is doing! ;) > > Glad you had a smiley on there, although if there are major objections to my shorter names I am willing to consider much longer ones. I wrote Doxygen comments too though ;-) Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Sep 27 16:23:38 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 27 Sep 2010 14:23:38 -0600 Subject: [vtk-developers] intermittant dashboard failure with java wrapping In-Reply-To: <20100927172827.1765916953@mail.rogue-research.com> References: <20100927172827.1765916953@mail.rogue-research.com> Message-ID: Hi Sean, The dashboards have had this error popping up for Linux and OS X as far back as they go, which is May 30th. Strangely, in the early dashboards it was the machine "Tar Valon" (OS X 10.6) that was hit most often. These failures predate my changes to the wrappers, so at least I know it isn't my fault, but that doesn't help in finding the solution. This error has happened to me exactly once during a local build, but I wasn't curious enough to investigate. David On Mon, Sep 27, 2010 at 11:28 AM, Sean McBride wrote: > Hi all, > > For a few weeks now, some of our dashboards have been giving errors like this: > > /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ > vtkVTKJavaRenderingDriver.java:163: cannot access vtk.vtkTransformInterpolator > bad class file: /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ > vtkTransformInterpolator.class > class file contains wrong class: vtk.vtkTextureObject > Please remove or make sure it appears in the correct subdirectory of the > classpath. > ? ?dummy = new vtkTransformInterpolator(); > ? ? ? ? ? ? ? ?^ > 1 error > > For example, today here: > > > Anyone have any ideas why? > > -- > ____________________________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > From emonson at cs.duke.edu Mon Sep 27 16:25:36 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Mon, 27 Sep 2010 16:25:36 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: References: <201009251132.07145.marcus.hanwell@kitware.com> <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> Message-ID: <183B4485-BBE8-46DA-AC38-901799492A65@cs.duke.edu> "Abusing"? How should I be getting rid of the line, if not vtkPen::SetLineType(vtkPen::NO_PEN)? -Eric On Sep 27, 2010, at 4:02 PM, Marcus D. Hanwell wrote: > Hi Eric, > > Good catch! You are abusing the line type to get rid of the outline, and that was not getting set correctly after I refactored the code. If you pull and rebuild now commit 25b58dd should take care of that. > > Thanks for catching this - I will adjust one of the unit tests to use the line types so that this will be caught in future. > > Marcus > > On Mon, Sep 27, 2010 at 10:27 AM, Eric E. Monson wrote: > Here's the block that was ending up with with a black line around it. Setting the pen opacity to zero (after setting the line type) works fine for getting rid of the black line. > > Thanks, > -Eric > > > // Semi-transparent box over non-valid scales > if (this->DrawSets) > { > int oldLineType = painter->GetPen()->GetLineType(); > > > painter->GetBrush()->SetColor(254, 254, 254, 150); > painter->GetPen()->SetLineType(0); > int opaquePadding = 4; // extra padding so axes and points themselves are covered > for (int i = 0; i < this->VisibleColumns->GetNumberOfTuples(); i+=this->NumPerSet) > { > if ((i+this->NumPerSet-1) <= static_cast(this->Storage->Axes.size()) && > (i/this->NumPerSet == this->CurrentScale+1)) // opaque on next scale > { > vtkAxis* axis0 = this->Storage->Axes[i]; > vtkAxis* axis1 = this->Storage->Axes[this->Storage->Axes.size()-1]; > painter->DrawRect(axis0->GetPoint1()[0]-opaquePadding, > this->Point1[1]-opaquePadding, > axis1->GetPoint1()[0]-axis0->GetPoint1()[0]+(2*opaquePadding), > this->Point2[1]-this->Point1[1]+(2*opaquePadding)); > } > } > > painter->GetPen()->SetLineType(oldLineType); > > } > > > On Sep 27, 2010, at 10:18 AM, Marcus D. Hanwell wrote: > >> On Mon, Sep 27, 2010 at 9:43 AM, Eric E. Monson wrote: >> Hey Marcus, >> >> That looks great -- thanks for figuring out the right way to do it. >> >> I'm having a strange problem after rebuilding, though: I have a variant on the parallel coordinates chart that draws some extra decorations on the plot. One of these is a semi-transparent white rectangle. Before the paint calls I set >> >> painter->GetBrush()->SetColor(254, 254, 254, 150); >> painter->GetPen()->SetLineType(0); >> >> but the rectangle now shows up with a black outline around it... >> >> Has there been some change to the 2D drawing classes lately that might be causing this? (I can set the pen opacity to 0 to get rid of this black border line, but it just started showing up with this pull.) >> >> Over the weekend I spent some time refactoring the 2D API in order to optimize some of the drawing operations (ellipse rendering in particular). Could you send me all of that block of rendering code? It would be good to add it to a regression test, as everything seemed to be coming back clear from the regression tests. >> >> Thanks, >> >> Marcus >> -- >> Marcus D. Hanwell, Ph.D. >> R&D Engineer, Kitware Inc. >> (518) 881-4937 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Sep 27 16:26:40 2010 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 27 Sep 2010 14:26:40 -0600 Subject: [vtk-developers] ToParent() vs. ToParentCoordinates() In-Reply-To: References: Message-ID: On Mon, Sep 27, 2010 at 2:16 PM, Marcus D. Hanwell wrote: > > Glad you had a smiley on there, although if there are major objections to my > shorter names I am willing to consider much longer ones. I wrote Doxygen > comments too though ;-) That does me no good, because I don't read documentation. Just kidding. Sometimes I do. David From dave.partyka at kitware.com Mon Sep 27 16:31:48 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Mon, 27 Sep 2010 16:31:48 -0400 Subject: [vtk-developers] intermittant dashboard failure with java wrapping In-Reply-To: References: <20100927172827.1765916953@mail.rogue-research.com> Message-ID: This appears to be the issue where you can't build java wrapping in parallel. No one has seems to have tracked it down yet as it is randomly reproducible in that, everyday a different file will have the compile error. On Mon, Sep 27, 2010 at 4:23 PM, David Gobbi wrote: > Hi Sean, > > The dashboards have had this error popping up for Linux and OS X as > far back as they go, which is May 30th. Strangely, in the early > dashboards it was the machine "Tar Valon" (OS X 10.6) that was hit > most often. > > These failures predate my changes to the wrappers, so at least I know > it isn't my fault, but that doesn't help in finding the solution. > This error has happened to me exactly once during a local build, but I > wasn't curious enough to investigate. > > David > > > On Mon, Sep 27, 2010 at 11:28 AM, Sean McBride > wrote: > > Hi all, > > > > For a few weeks now, some of our dashboards have been giving errors like > this: > > > > /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ > > vtkVTKJavaRenderingDriver.java:163: cannot access > vtk.vtkTransformInterpolator > > bad class file: /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ > > vtkTransformInterpolator.class > > class file contains wrong class: vtk.vtkTextureObject > > Please remove or make sure it appears in the correct subdirectory of the > > classpath. > > dummy = new vtkTransformInterpolator(); > > ^ > > 1 error > > > > For example, today here: > > > > > > Anyone have any ideas why? > > > > -- > > ____________________________________________________________ > > 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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Mon Sep 27 16:38:09 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Sep 2010 16:38:09 -0400 Subject: [vtk-developers] ChartParallelCoordinates clearing AxesSelections on resize In-Reply-To: <183B4485-BBE8-46DA-AC38-901799492A65@cs.duke.edu> References: <201009251132.07145.marcus.hanwell@kitware.com> <97589A16-F5C3-4039-844B-DD5792ADAAE7@cs.duke.edu> <183B4485-BBE8-46DA-AC38-901799492A65@cs.duke.edu> Message-ID: Sorry, poor choice of words and not what I meant...I think you are using it in the right way, and it should hopefully be fixed now. Marcus On Mon, Sep 27, 2010 at 4:25 PM, Eric E. Monson wrote: > "Abusing"? How should I be getting rid of the line, if not > vtkPen::SetLineType(vtkPen::NO_PEN)? > > -Eric > > On Sep 27, 2010, at 4:02 PM, Marcus D. Hanwell wrote: > > Hi Eric, > > Good catch! You are abusing the line type to get rid of the outline, and > that was not getting set correctly after I refactored the code. If you pull > and rebuild now commit 25b58dd should take care of that. > > Thanks for catching this - I will adjust one of the unit tests to use the > line types so that this will be caught in future. > > Marcus > > On Mon, Sep 27, 2010 at 10:27 AM, Eric E. Monson wrote: > >> Here's the block that was ending up with with a black line around >> it. Setting the pen opacity to zero (after setting the line type) works fine >> for getting rid of the black line. >> >> Thanks, >> -Eric >> >> >> // Semi-transparent box over non-valid scales >> if (this->DrawSets) >> { >> int oldLineType = painter->GetPen()->GetLineType(); >> >> >> painter->GetBrush()->SetColor(254, 254, 254, 150); >> painter->GetPen()->SetLineType(0); >> int opaquePadding = 4; // extra padding so axes and points >> themselves are covered >> for (int i = 0; i < this->VisibleColumns->GetNumberOfTuples(); >> i+=this->NumPerSet) >> { >> if ((i+this->NumPerSet-1) <= >> static_cast(this->Storage->Axes.size()) && >> (i/this->NumPerSet == this->CurrentScale+1)) // opaque on next >> scale >> { >> vtkAxis* axis0 = this->Storage->Axes[i]; >> vtkAxis* axis1 = >> this->Storage->Axes[this->Storage->Axes.size()-1]; >> painter->DrawRect(axis0->GetPoint1()[0]-opaquePadding, >> this->Point1[1]-opaquePadding, >> >> axis1->GetPoint1()[0]-axis0->GetPoint1()[0]+(2*opaquePadding), >> >> this->Point2[1]-this->Point1[1]+(2*opaquePadding)); >> } >> } >> >> painter->GetPen()->SetLineType(oldLineType); >> >> } >> >> >> On Sep 27, 2010, at 10:18 AM, Marcus D. Hanwell wrote: >> >> On Mon, Sep 27, 2010 at 9:43 AM, Eric E. Monson wrote: >> >>> Hey Marcus, >>> >>> That looks great -- thanks for figuring out the right way to do it. >>> >>> I'm having a strange problem after rebuilding, though: I have a variant >>> on the parallel coordinates chart that draws some extra decorations on the >>> plot. One of these is a semi-transparent white rectangle. Before the paint >>> calls I set >>> >>> painter->GetBrush()->SetColor(254, 254, 254, 150); >>> painter->GetPen()->SetLineType(0); >>> >>> but the rectangle now shows up with a black outline around it... >>> >>> Has there been some change to the 2D drawing classes lately that might be >>> causing this? (I can set the pen opacity to 0 to get rid of this black >>> border line, but it just started showing up with this pull.) >>> >>> Over the weekend I spent some time refactoring the 2D API in order to >> optimize some of the drawing operations (ellipse rendering in particular). >> Could you send me all of that block of rendering code? It would be good to >> add it to a regression test, as everything seemed to be coming back clear >> from the regression tests. >> >> Thanks, >> >> Marcus >> -- >> Marcus D. Hanwell, Ph.D. >> R&D Engineer, Kitware Inc. >> (518) 881-4937 >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Mon Sep 27 16:40:52 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Sep 2010 16:40:52 -0400 Subject: [vtk-developers] intermittant dashboard failure with java wrapping In-Reply-To: References: <20100927172827.1765916953@mail.rogue-research.com> Message-ID: I have had the parallel Java build issue in my work too, it was made less apparent after I moved vtkJVMManager to Titan, but it appears to be a problem where the dependencies are not correct for at least some of the wrapped Java files. Marcus On Mon, Sep 27, 2010 at 4:31 PM, Dave Partyka wrote: > This appears to be the issue where you can't build java wrapping in > parallel. No one has seems to have tracked it down yet as it is > randomly reproducible in that, everyday a different file will have the > compile error. > > > On Mon, Sep 27, 2010 at 4:23 PM, David Gobbi wrote: > >> Hi Sean, >> >> The dashboards have had this error popping up for Linux and OS X as >> far back as they go, which is May 30th. Strangely, in the early >> dashboards it was the machine "Tar Valon" (OS X 10.6) that was hit >> most often. >> >> These failures predate my changes to the wrappers, so at least I know >> it isn't my fault, but that doesn't help in finding the solution. >> This error has happened to me exactly once during a local build, but I >> wasn't curious enough to investigate. >> >> David >> >> >> On Mon, Sep 27, 2010 at 11:28 AM, Sean McBride >> wrote: >> > Hi all, >> > >> > For a few weeks now, some of our dashboards have been giving errors like >> this: >> > >> > /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ >> > vtkVTKJavaRenderingDriver.java:163: cannot access >> vtk.vtkTransformInterpolator >> > bad class file: /Users/builder/kitware/VTK-llvm-dbg-x86_64/java/vtk/ >> > vtkTransformInterpolator.class >> > class file contains wrong class: vtk.vtkTextureObject >> > Please remove or make sure it appears in the correct subdirectory of the >> > classpath. >> > dummy = new vtkTransformInterpolator(); >> > ^ >> > 1 error >> > >> > For example, today here: >> > >> > >> > Anyone have any ideas why? >> > >> > -- >> > ____________________________________________________________ >> > 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://www.vtk.org/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://www.vtk.org/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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouzim at gmail.com Mon Sep 27 17:26:23 2010 From: bouzim at gmail.com (Denis Barbier) Date: Mon, 27 Sep 2010 23:26:23 +0200 Subject: [vtk-developers] intermittant dashboard failure with java wrapping In-Reply-To: References: <20100927172827.1765916953@mail.rogue-research.com> Message-ID: On 2010/9/27 Marcus D. Hanwell wrote: > I have had the parallel Java build issue in my work too, it was made less > apparent after I moved vtkJVMManager to Titan, but it appears to be a > problem where the dependencies are not correct for at least some of the > wrapped Java files. Here is a patch I wrote for Debian. The "-source 5" argument fixes another problem, vtkMPIController.java uses covariant return types and thus Java 5. It worked until 5.6, but does not apply cleanly anymore. Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: vtkWrapJava.patch Type: text/x-patch Size: 1415 bytes Desc: not available URL: From janagama_swapna at yahoo.com Mon Sep 27 22:02:09 2010 From: janagama_swapna at yahoo.com (Swapna Janagama) Date: Mon, 27 Sep 2010 19:02:09 -0700 (PDT) Subject: [vtk-developers] online classes Message-ID: <923499.45105.qm@web114715.mail.gq1.yahoo.com> Hi, I?want to learn VTK,Do you have online classes ? ? Best Regards : Swapna Janagama? -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria at gmail.com Tue Sep 28 07:35:40 2010 From: daviddoria at gmail.com (David Doria) Date: Tue, 28 Sep 2010 07:35:40 -0400 Subject: [vtk-developers] online classes In-Reply-To: <923499.45105.qm@web114715.mail.gq1.yahoo.com> References: <923499.45105.qm@web114715.mail.gq1.yahoo.com> Message-ID: On Mon, Sep 27, 2010 at 10:02 PM, Swapna Janagama wrote: > Hi, > > I want to learn VTK,Do you have online classes ? > > *Best Regards :* > *Swapna Janagama** * > * > * > Unfortunately I do not know of any live online VTK classes. You can find some slides from a brick and mortar class here: http://www.vtk.org/Wiki/VTK/Presentations Paired with http://www.vtk.org/Wiki/VTK/Examples/Cxx , you should be able to get a good start. If you have any questions as you go along, please feel free to send them to the mailing list (but please use the users list, this is the developers list). Good luck! David -------------- next part -------------- An HTML attachment was scrubbed... URL: From emonson at cs.duke.edu Tue Sep 28 07:42:43 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 28 Sep 2010 07:42:43 -0400 Subject: [vtk-developers] online classes In-Reply-To: References: <923499.45105.qm@web114715.mail.gq1.yahoo.com> Message-ID: Hey Swapna, Maybe you know about all of this, but there is also this general list of online resources: http://www.vtk.org/VTK/help/help.html which includes a link to purchasing the VTK books: http://www.vtk.org/VTK/help/book.html -Eric ------------------------------------------------------ Eric E Monson Duke Visualization Technology Group On Sep 28, 2010, at 7:35 AM, David Doria wrote: > On Mon, Sep 27, 2010 at 10:02 PM, Swapna Janagama wrote: > Hi, > > I want to learn VTK,Do you have online classes ? > > Best Regards : > Swapna Janagama > > > Unfortunately I do not know of any live online VTK classes. You can find some slides from a brick and mortar class here: > http://www.vtk.org/Wiki/VTK/Presentations > > Paired with http://www.vtk.org/Wiki/VTK/Examples/Cxx , you should be able to get a good start. If you have any questions as you go along, please feel free to send them to the mailing list (but please use the users list, this is the developers list). > > Good luck! > > 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://www.vtk.org/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emonson at cs.duke.edu Tue Sep 28 10:45:29 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 28 Sep 2010 10:45:29 -0400 Subject: [vtk-developers] ChartParallelCoordinates data switching Message-ID: Hey Marcus, In my application I was switching the data in a parallel coordinates chart and noticed that there are problems (and no intuitive solution) if you swap out the data to a new set which has less axes/columns. If you just do a chart.GetPlot(0).SetInput(table) with a new table that has less columns than the previous one you get a Segmentation Fault. (I'll put a short python script at the end that demonstrates this.) You can get around it by first turning off the visibility of all the current axes, since the plot relies on the column visibility data for its updating routines. (To see that this seems to work, set the if(False) to if(True) in the script.) In my custom version I just added a SetAllColumnsInvisible() method, which just does a this->VisibleColumns->SetNumberOfTuples(0); (plus a Modified and Update), and if I call this before resetting the data in the plot it seems to work fine. This name won't help people, though, since it's not obvious that you'd need to call this before swapping the data... So, I don't have the ideal solution, just one that's working for me, but I thought I'd bring this to your attention since it seems like something that should be addressed at some point. Talk to you later, -Eric ------------------------------------------------------ Eric E Monson Duke Visualization Technology Group ================================================= # This version illustrates a Segmentation Fault when switching to # a new data table that has less columns than the original import vtk import math # Set up a 2D scene, add an XY chart to it view = vtk.vtkContextView() view.GetRenderer().SetBackground(1.0, 1.0, 1.0) view.GetRenderWindow().SetSize(600,300) chart = vtk.vtkChartParallelCoordinates() view.GetScene().AddItem(chart) numPoints = 200 inc = 7.5 / (numPoints-1) # Create arrays that will end up as table columns arrX = vtk.vtkFloatArray() arrX.SetName("XAxis") arrX.SetNumberOfComponents(1) arrX.SetNumberOfTuples(numPoints) arrC = vtk.vtkFloatArray() arrC.SetName("Cosine") arrC.SetNumberOfComponents(1) arrC.SetNumberOfTuples(numPoints) arrS = vtk.vtkFloatArray() arrS.SetName("Sine") arrS.SetNumberOfComponents(1) arrS.SetNumberOfTuples(numPoints) arrS2 = vtk.vtkFloatArray() arrS2.SetName("Tan") arrS2.SetNumberOfComponents(1) arrS2.SetNumberOfTuples(numPoints) # Fill the arrays with data for i in range(numPoints): arrX.SetTuple1(i, i * inc) arrC.SetTuple1(i, math.cos(i * inc) + 0.0) arrS.SetTuple1(i, math.sin(i * inc) + 0.0) arrS2.SetTuple1(i, math.tan(i * inc) + 0.5) # Create a table with some points in it... table = vtk.vtkTable() table.AddColumn(arrX) table.AddColumn(arrC) table.AddColumn(arrS) table.AddColumn(arrS2) chart.GetPlot(0).SetInput(table) view.ResetCamera() view.Render() # * * * * # Set this to "if (True):" to see the program not crash # * * * * if (False): for ii in range(table.GetNumberOfColumns()): t_name = table.GetColumnName(ii) chart.SetColumnVisibility(t_name, False) # Create a new table with less columns than the first table2 = vtk.vtkTable() table2.AddColumn(arrX) table2.AddColumn(arrC) table2.AddColumn(arrS) chart.GetPlot(0).SetInput(table2) view.Render() view.GetInteractor().Start() From marcus.hanwell at kitware.com Tue Sep 28 10:50:58 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 28 Sep 2010 10:50:58 -0400 Subject: [vtk-developers] ChartParallelCoordinates data switching In-Reply-To: References: Message-ID: <201009281050.59266.marcus.hanwell@kitware.com> On Tuesday 28 September 2010 10:45:29 Eric E. Monson wrote: > Hey Marcus, > > In my application I was switching the data in a parallel coordinates chart > and noticed that there are problems (and no intuitive solution) if you > swap out the data to a new set which has less axes/columns. If you just do > a chart.GetPlot(0).SetInput(table) with a new table that has less columns > than the previous one you get a Segmentation Fault. (I'll put a short > python script at the end that demonstrates this.) > > You can get around it by first turning off the visibility of all the > current axes, since the plot relies on the column visibility data for its > updating routines. (To see that this seems to work, set the if(False) to > if(True) in the script.) > > In my custom version I just added a SetAllColumnsInvisible() method, which > just does a this->VisibleColumns->SetNumberOfTuples(0); (plus a Modified > and Update), and if I call this before resetting the data in the plot it > seems to work fine. This name won't help people, though, since it's not > obvious that you'd need to call this before swapping the data... > > So, I don't have the ideal solution, just one that's working for me, but I > thought I'd bring this to your attention since it seems like something > that should be addressed at some point. Hi Eric, I see why that would happen, I think a general solution would be to check if the number of columns changed, and if it did to reset the visible columns. Would this match your expectations? The question then becomes should all columns be made visible by default, or none? Marcus -- Marcus D. Hanwell, Ph.D. R&D Engineer, Kitware Inc. (518) 881-4937 From emonson at cs.duke.edu Tue Sep 28 11:49:17 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 28 Sep 2010 11:49:17 -0400 Subject: [vtk-developers] ChartParallelCoordinates data switching In-Reply-To: <201009281050.59266.marcus.hanwell@kitware.com> References: <201009281050.59266.marcus.hanwell@kitware.com> Message-ID: Hey Marcus, Yes, I think that would work. I guess my preference would be to default to all of the columns visible by default. If people try to put too many columns in the plot (not that I'm doing that... no, no...), then they have to decide, anyway, which ones are really important, and it's unlikely that the first 10 are going to necessarily be the right choice. (Plus, it screwed me up for a little while not understanding why all of my data wasn't showing up.) Thanks, -Eric On Sep 28, 2010, at 10:50 AM, Marcus D. Hanwell wrote: > On Tuesday 28 September 2010 10:45:29 Eric E. Monson wrote: >> Hey Marcus, >> >> In my application I was switching the data in a parallel coordinates chart >> and noticed that there are problems (and no intuitive solution) if you >> swap out the data to a new set which has less axes/columns. If you just do >> a chart.GetPlot(0).SetInput(table) with a new table that has less columns >> than the previous one you get a Segmentation Fault. (I'll put a short >> python script at the end that demonstrates this.) >> >> You can get around it by first turning off the visibility of all the >> current axes, since the plot relies on the column visibility data for its >> updating routines. (To see that this seems to work, set the if(False) to >> if(True) in the script.) >> >> In my custom version I just added a SetAllColumnsInvisible() method, which >> just does a this->VisibleColumns->SetNumberOfTuples(0); (plus a Modified >> and Update), and if I call this before resetting the data in the plot it >> seems to work fine. This name won't help people, though, since it's not >> obvious that you'd need to call this before swapping the data... >> >> So, I don't have the ideal solution, just one that's working for me, but I >> thought I'd bring this to your attention since it seems like something >> that should be addressed at some point. > > Hi Eric, > > I see why that would happen, I think a general solution would be to check if > the number of columns changed, and if it did to reset the visible columns. > Would this match your expectations? The question then becomes should all > columns be made visible by default, or none? > > Marcus > -- > Marcus D. Hanwell, Ph.D. > R&D Engineer, Kitware Inc. > (518) 881-4937 From emonson at cs.duke.edu Tue Sep 28 12:54:43 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Tue, 28 Sep 2010 12:54:43 -0400 Subject: [vtk-developers] ChartParallelCoordinates data switching In-Reply-To: References: <201009281050.59266.marcus.hanwell@kitware.com> Message-ID: One more thing, sort of related: this->Storage->CurrentAxis needs to be reset to -1 when the data changes, too, or sometimes with the Paint routine will try to access an axis that doesn't exist (and it will seem like a strange random crash and it will take someone an hour to track down what's happening... :) Do you want me to file a bug report for these two combined so it'll be easier to keep track of? Thanks, -Eric On Sep 28, 2010, at 11:49 AM, Eric E. Monson wrote: > Hey Marcus, > > Yes, I think that would work. I guess my preference would be to default to all of the columns visible by default. If people try to put too many columns in the plot (not that I'm doing that... no, no...), then they have to decide, anyway, which ones are really important, and it's unlikely that the first 10 are going to necessarily be the right choice. (Plus, it screwed me up for a little while not understanding why all of my data wasn't showing up.) > > Thanks, > -Eric > > On Sep 28, 2010, at 10:50 AM, Marcus D. Hanwell wrote: > >> On Tuesday 28 September 2010 10:45:29 Eric E. Monson wrote: >>> Hey Marcus, >>> >>> In my application I was switching the data in a parallel coordinates chart >>> and noticed that there are problems (and no intuitive solution) if you >>> swap out the data to a new set which has less axes/columns. If you just do >>> a chart.GetPlot(0).SetInput(table) with a new table that has less columns >>> than the previous one you get a Segmentation Fault. (I'll put a short >>> python script at the end that demonstrates this.) >>> >>> You can get around it by first turning off the visibility of all the >>> current axes, since the plot relies on the column visibility data for its >>> updating routines. (To see that this seems to work, set the if(False) to >>> if(True) in the script.) >>> >>> In my custom version I just added a SetAllColumnsInvisible() method, which >>> just does a this->VisibleColumns->SetNumberOfTuples(0); (plus a Modified >>> and Update), and if I call this before resetting the data in the plot it >>> seems to work fine. This name won't help people, though, since it's not >>> obvious that you'd need to call this before swapping the data... >>> >>> So, I don't have the ideal solution, just one that's working for me, but I >>> thought I'd bring this to your attention since it seems like something >>> that should be addressed at some point. >> >> Hi Eric, >> >> I see why that would happen, I think a general solution would be to check if >> the number of columns changed, and if it did to reset the visible columns. >> Would this match your expectations? The question then becomes should all >> columns be made visible by default, or none? >> >> Marcus >> -- >> Marcus D. Hanwell, Ph.D. >> R&D Engineer, Kitware Inc. >> (518) 881-4937 > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers From dave.partyka at kitware.com Tue Sep 28 15:21:35 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Tue, 28 Sep 2010 15:21:35 -0400 Subject: [vtk-developers] ANN: VTK 5.6.1 available for download Message-ID: Hello All, The VTK team is pleased to announce the availability of VTK 5.6.1 for download on the VTK download page ( http://vtk.org/VTK/resources/software.html). VTK 5.6.1 is a patch release over 5.6.0 with a small set of improvements. Some of noteworthy improvements/fixes are: VTK now includes NetCDF 4.1.1 allowing users to take advantage of the latest enhancements to NetCDF. Additionally the C++ version of the library is now also included. A new file format called MPAS has been added. It is a netcdf based reader for ocean and atmosphere data sets. Charts have significant improvements when plotting data on multiple axes in the same plot (up to four), and improved layout of the axes. Initial support for linked selection has also been added to the charts in VTK and ParaView. Support for alpha blending in parallel coordinates plots has also been added. We also cleaned up VTK's build and install rules so that developers shouldn't have to worry about 'rpath' anymore. Also "make install" has been vastly improved on all platforms. As always, we value your feedback. Please report any issues on the VTK mailing list (http://www.vtk.org/VTK/help/mailing.html) or the vtk bug tracker (vtk.org/Bug). Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sebastiancelis.com Tue Sep 28 15:37:21 2010 From: sebastian at sebastiancelis.com (sebastian) Date: Tue, 28 Sep 2010 12:37:21 -0700 (PDT) Subject: [vtk-developers] git 'update' hook Message-ID: <1285702641846-2870228.post@n5.nabble.com> Hello, I've been looking for a server-side git hook that blocks the push if a submodule reference being pushed does not exist in the submodule repository. Then I came across the following wiki page: http://www.itk.org/Wiki/Git/Hooks#update I see that your update hook does this along with some other very useful things. Would you mind sharing the code for that hook with me? I would love to use parts of it in my repositories. Many thanks, Sebastian -- View this message in context: http://vtk.1045678.n5.nabble.com/git-update-hook-tp2870228p2870228.html Sent from the VTK - Dev mailing list archive at Nabble.com. From david.cole at kitware.com Tue Sep 28 23:42:30 2010 From: david.cole at kitware.com (David Cole) Date: Tue, 28 Sep 2010 23:42:30 -0400 Subject: [vtk-developers] SimpleITK survey Message-ID: Hello VTK devs and users: How many of you also use ITK in your work? How many would like to, if only it were easier and simpler? As part of the effort to build the new simple layer for ITK, the ITK team has put together a survey to poll current and potential future users for their opinions. If you have any interest in using a "simple layer" to ITK, please participate in the following survey. It will only take a few minutes of your time, and it will help the ITK developers understand their target audience better. The survey link is: http://www.surveymonkey.com/s/SimpleITKCommunitySurvey Thanks, David C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hel.schumacher at fz-juelich.de Wed Sep 29 09:14:45 2010 From: hel.schumacher at fz-juelich.de (Dr. Helmut Schumacher) Date: Wed, 29 Sep 2010 15:14:45 +0200 Subject: [vtk-developers] WG: DataSetSurfaceFilter supporting blanking with StructuredGrid Message-ID: <005e01cb5fd8$49467500$dbd35f00$@schumacher@fz-juelich.de> Dr. Helmut Schumacher Forschungszentrum J?lich J?lich Supercompting Centre Leo-Brandt-Stra?e 52425 J?lich Tel.: +49-2461/61-2482 Fax: +49-2461/61-6656 -----Urspr?ngliche Nachricht----- Von: Dr. Helmut Schumacher [mailto:hel.schumacher at fz-juelich.de] Gesendet: Mittwoch, 29. September 2010 14:53 An: VTK-Mailing-List (vtkusers at vtk.org) Betreff: DataSetSurfaceFilter supporting blanking with StructuredGrid Hello, I found a very strange solution for my problem. DataSetMapper uses DataSetSurfaceFilter. In VTK 5.4.2 and 5.6.1 DataSetSurfaceFilter does NOT support blanking for a StructuredGrid. But the VTK-Version for ParaView has a method to handle this (for both Cell- and PointBlanking). Unfortunately the controlling "if"-statement selects this branch for CellBlanking only. So I copied the ParaView-Version of DataSetSurfaceFilter to my VTK/Graphics. I changed line 161 of vtkDataSetSurfaceFilter.cxx from if( grid->GetCellBlanking() ) to if( grid->GetCellBlanking() || grid->GetPointBlanking() ) and compiled the changed VTK. As the result I have a VTK with DataSetSurfaceFilter and therefore also DataSetMapper supporting Cell- and PointBlanking. I add my version to this mail and hope you will include it in the next version of VTK. Thanks in advance Dr. Helmut Schumacher Forschungszentrum J?lich J?lich Supercompting Centre Leo-Brandt-Stra?e 52425 J?lich Tel.: +49-2461/61-2482 Fax: +49-2461/61-6656 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vtkDataSetSurfaceFilter.cxx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5713 bytes Desc: not available URL: From hel.schumacher at fz-juelich.de Thu Sep 30 02:54:06 2010 From: hel.schumacher at fz-juelich.de (Dr. Helmut Schumacher) Date: Thu, 30 Sep 2010 08:54:06 +0200 Subject: [vtk-developers] BugFix StructuredGridSurfaceFilter Message-ID: <002f01cb606c$46443240$d2cc96c0$@schumacher@fz-juelich.de> Hello, the version I sent yesterday was buggy. Blanking worked, but non-blanked grids did not. I corrected this bug (it was not mine). Dr. Helmut Schumacher Forschungszentrum J?lich J?lich Supercompting Centre Leo-Brandt-Stra?e 52425 J?lich Tel.: +49-2461/61-2482 Fax: +49-2461/61-6656 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vtkDataSetSurfaceFilter.cxx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5713 bytes Desc: not available URL: From dave.partyka at kitware.com Thu Sep 30 10:40:17 2010 From: dave.partyka at kitware.com (Dave Partyka) Date: Thu, 30 Sep 2010 10:40:17 -0400 Subject: [vtk-developers] WG: DataSetSurfaceFilter supporting blanking with StructuredGrid In-Reply-To: <-6273103562907495098@unknownmsgid> References: <-6273103562907495098@unknownmsgid> Message-ID: Hi Dr. Schumacher, The version of vtkDataSetSurfaceFilter you sent appears to be from a very old version of VTK. Presently none of that logic exists nor does the BlankedStructuredExecute function exist that preformed the blanking. vtkDataSetSurfaceFilter also has more than 70 commits that have been made to it since that version from ~9 years ago so unfortunately I cannot simply restore it to that state. Though I am curious if anyone in the community knows why the functionality was removed or why vtkStructured/UnstructuredGrid still have their GetPointBlanking/GetCellBlanking API as it doesn't appear to be used anymore and leads to the belief that we do support Blanking? On Wed, Sep 29, 2010 at 9:14 AM, Dr. Helmut Schumacher < hel.schumacher at fz-juelich.de> wrote: > > > Dr. Helmut Schumacher > Forschungszentrum J?lich > J?lich Supercompting Centre > Leo-Brandt-Stra?e > 52425 J?lich > Tel.: +49-2461/61-2482 > Fax: +49-2461/61-6656 > > > -----Urspr?ngliche Nachricht----- > Von: Dr. Helmut Schumacher [mailto:hel.schumacher at fz-juelich.de] > Gesendet: Mittwoch, 29. September 2010 14:53 > An: VTK-Mailing-List (vtkusers at vtk.org) > Betreff: DataSetSurfaceFilter supporting blanking with StructuredGrid > > Hello, > > I found a very strange solution for my problem. > > DataSetMapper uses DataSetSurfaceFilter. > > In VTK 5.4.2 and 5.6.1 DataSetSurfaceFilter does NOT support blanking for a > StructuredGrid. > But the VTK-Version for ParaView has a method to handle this (for both > Cell- > and PointBlanking). > Unfortunately the controlling "if"-statement selects this branch for > CellBlanking only. > > So I copied the ParaView-Version of DataSetSurfaceFilter to my > VTK/Graphics. > I changed line 161 of vtkDataSetSurfaceFilter.cxx from > > if( grid->GetCellBlanking() ) > > to > > if( grid->GetCellBlanking() || grid->GetPointBlanking() ) > > and compiled the changed VTK. > > As the result I have a VTK with DataSetSurfaceFilter and therefore also > DataSetMapper supporting Cell- and PointBlanking. > > I add my version to this mail and hope you will include it in the next > version of VTK. > > Thanks in advance > > Dr. Helmut Schumacher > Forschungszentrum J?lich > J?lich Supercompting Centre > Leo-Brandt-Stra?e > 52425 J?lich > Tel.: +49-2461/61-2482 > Fax: +49-2461/61-6656 > > > > _______________________________________________ > 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://www.vtk.org/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Sep 30 14:06:34 2010 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 30 Sep 2010 14:06:34 -0400 Subject: [vtk-developers] ChartParallelCoordinates data switching In-Reply-To: References: <201009281050.59266.marcus.hanwell@kitware.com> Message-ID: On Tue, Sep 28, 2010 at 12:54 PM, Eric E. Monson wrote: > One more thing, sort of related: > > this->Storage->CurrentAxis needs to be reset to -1 when the data changes, > too, or sometimes with the Paint routine will try to access an axis that > doesn't exist (and it will seem like a strange random crash and it will take > someone an hour to track down what's happening... :) > > Do you want me to file a bug report for these two combined so it'll be > easier to keep track of? > > Hi Eric, I just pushed a topic that should address these issues, it no longer segfaults with your Python script. Take a look and let me know if you spot any other issues. Thanks, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From emonson at cs.duke.edu Thu Sep 30 14:31:43 2010 From: emonson at cs.duke.edu (Eric E. Monson) Date: Thu, 30 Sep 2010 14:31:43 -0400 Subject: [vtk-developers] ChartParallelCoordinates data switching In-Reply-To: References: <201009281050.59266.marcus.hanwell@kitware.com> Message-ID: <45BABA57-DAC2-4391-AD46-CA974D58633A@cs.duke.edu> Hey Marcus, Yup, it looks like that took care of the problem nicely (and I can confirm that your other fix is generating David Doria's plot properly now, too). Thanks for taking care of these things so quickly. The only outstanding issues I have left are not with the parallel coordinates (so maybe they should be in a separate thread, but I'm going to go ahead and mention them here). These are the only three differences right now that I have to sustain between VTK proper and the code I need: 1. It would be nice if there was a virtual function in vtkChartXY, something like SetTooltipInfo() which subclasses can override to send different information to tooltip items rather than having that hard-coded into LocatePointInPlots. (see http://www.vtk.org/pipermail/vtk-developers/2010-August/008342.html ). 2. It would be nice if there was some sort of ivar in vtkChartXY which allow users to switch the mouse button assignments without having to subclass. 3. At some point the highlight markers in vtkPlotPoints was switched so they show up behind the standard black markers. I can see how this looks nice in many cases, and looks more like a highlight around the original point, but if you have a big, dense cloud of points all of the highlights disappear behind the data markers. So, in my version I moved the highlight markers back on top (with some transparency), and it's much easier to see in these large, dense data cases. Thanks again, and I'll talk to you later, -Eric On Sep 30, 2010, at 2:06 PM, Marcus D. Hanwell wrote: > On Tue, Sep 28, 2010 at 12:54 PM, Eric E. Monson wrote: > One more thing, sort of related: > > this->Storage->CurrentAxis needs to be reset to -1 when the data changes, too, or sometimes with the Paint routine will try to access an axis that doesn't exist (and it will seem like a strange random crash and it will take someone an hour to track down what's happening... :) > > Do you want me to file a bug report for these two combined so it'll be easier to keep track of? > > Hi Eric, > > I just pushed a topic that should address these issues, it no longer segfaults with your Python script. Take a look and let me know if you spot any other issues. > > Thanks, > > Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: