From dave.demarle at kitware.com Thu Dec 6 11:48:06 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 6 Dec 2018 11:48:06 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181128204433.GB4242@megas.kitware.com> References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> Message-ID: I think the dependency comes in for the sake of VTK's python tests, as those call vtkpython. Prabu can you try this and see if you get a pip worthy build out of it? https://gitlab.kitware.com/demarle/vtk/commits/WIP-break-wrappings-vtkpythoninterpreter-dependency Note you must set these two configure flags to get it to compile. BUILD_TESTING:BOOL=OFF VTK_ENABLE_VTKPYTHON:BOOL=OFF Longer term we should do a clean break by trying to move the bits of VTKPYTHON that remain in Wrapping/PythonCore to Utilities/PythonInterpretter and making sure the python tests agree. Regarding matplotlib, for the moment just leave it off in the wheels. Ben's point of wrapping everything and the corrolary that VTK's modules should be atomic (options don't change the library internals) is an important goal that we won't fix in 8.2. We made strides in VTK 6.0 and will get much closer in 9.0, hopefully packagers and all consumers of VTK will have a better time of it after 9. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Nov 28, 2018 at 3:44 PM Ben Boeckel via vtk-developers < vtk-developers at public.kitware.com> wrote: > On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote: > > Does vtkWrappingPythonCore depend on vtkPythonInterpreter? > > vtkWrappingPythonCore does not link to libpython or to > vtkPythonInterpreter. > > My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious. > Removing that dependency and then disabling the module should work. > > > The wheels by default do not seem to enable vtkRenderingMatplotlib > although I am > > not sure if it should be added by default in the future, in which case > this is a > > more serious issue. > > IMO, distribution builds should try to enable *everything* so there > isn't a question of "what do I have today?" when doing `import vtk`. > Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to > not have the linking problem. > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Dec 6 12:03:49 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 6 Dec 2018 12:03:49 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> Message-ID: @Utkarsh Ayachit @Chuck Atkins FYI the python path improvments that you all did appear to have unintended consequences on wheel building for VTK. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Dec 6, 2018 at 11:48 AM David E DeMarle wrote: > I think the dependency comes in for the sake of VTK's python tests, as > those call vtkpython. > Prabu can you try this and see if you get a pip worthy build out of it? > > https://gitlab.kitware.com/demarle/vtk/commits/WIP-break-wrappings-vtkpythoninterpreter-dependency > Note you must set these two configure flags to get it to compile. > BUILD_TESTING:BOOL=OFF > VTK_ENABLE_VTKPYTHON:BOOL=OFF > Longer term we should do a clean break by trying to move the bits of > VTKPYTHON that remain in Wrapping/PythonCore to > Utilities/PythonInterpretter and making sure the python tests agree. > > Regarding matplotlib, for the moment just leave it off in the wheels. > Ben's point of wrapping everything and the corrolary that VTK's modules > should be atomic (options don't change the library internals) is an > important goal that we won't fix in 8.2. We made strides in VTK 6.0 and > will get much closer in 9.0, hopefully packagers and all consumers of VTK > will have a better time of it after 9. > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > > On Wed, Nov 28, 2018 at 3:44 PM Ben Boeckel via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote: >> > Does vtkWrappingPythonCore depend on vtkPythonInterpreter? >> > vtkWrappingPythonCore does not link to libpython or to >> vtkPythonInterpreter. >> >> My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious. >> Removing that dependency and then disabling the module should work. >> >> > The wheels by default do not seem to enable vtkRenderingMatplotlib >> although I am >> > not sure if it should be added by default in the future, in which case >> this is a >> > more serious issue. >> >> IMO, distribution builds should try to enable *everything* so there >> isn't a question of "what do I have today?" when doing `import vtk`. >> Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to >> not have the linking problem. >> >> --Ben >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Dec 7 14:16:51 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 7 Dec 2018 14:16:51 -0500 Subject: [vtk-developers] OK to drop support for OSPRAY_BUILD_DIR Message-ID: Hey folks, Does anyone mind if I drop support for VTK to build against OSPRay's build directory? I don't think this will impact anyone very negatively because it is just two easy extra steps to configure a prefix path into your ospray build and run make install. thanks David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Fri Dec 7 17:00:20 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 7 Dec 2018 17:00:20 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> Message-ID: > VTK_ENABLE_VTKPYTHON:BOOL=OFF As a side note, would it make sense to renamed this option to VTK_BUILD_VTKPYTHON_EXECUTABLE (or VTK_ENABLE_VTKPYTHON_EXECUTABLE) > distribution builds should try to enable *everything* In that context, I don't think it makes sense to build VTK own python interpreter. Ideally, it should be possible to run VTK test with or without it. I also envision we could have a "vtk-openvr" python module but it wouldn't be available by default when installing vtk wheel. To support this level of "modularity" , we would continue building part of VTK independently (for example, we can already do this with the VTKOpenVR module) On Thu, Dec 6, 2018 at 11:48 AM David E DeMarle wrote: > I think the dependency comes in for the sake of VTK's python tests, as > those call vtkpython. > Prabu can you try this and see if you get a pip worthy build out of it? > > https://gitlab.kitware.com/demarle/vtk/commits/WIP-break-wrappings-vtkpythoninterpreter-dependency > Note you must set these two configure flags to get it to compile. > BUILD_TESTING:BOOL=OFF > VTK_ENABLE_VTKPYTHON:BOOL=OFF > Longer term we should do a clean break by trying to move the bits of > VTKPYTHON that remain in Wrapping/PythonCore to > Utilities/PythonInterpretter and making sure the python tests agree. > > Regarding matplotlib, for the moment just leave it off in the wheels. > Ben's point of wrapping everything and the corrolary that VTK's modules > should be atomic (options don't change the library internals) is an > important goal that we won't fix in 8.2. We made strides in VTK 6.0 and > will get much closer in 9.0, hopefully packagers and all consumers of VTK > will have a better time of it after 9. > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > > On Wed, Nov 28, 2018 at 3:44 PM Ben Boeckel via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote: >> > Does vtkWrappingPythonCore depend on vtkPythonInterpreter? >> > vtkWrappingPythonCore does not link to libpython or to >> vtkPythonInterpreter. >> >> My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious. >> Removing that dependency and then disabling the module should work. >> >> > The wheels by default do not seem to enable vtkRenderingMatplotlib >> although I am >> > not sure if it should be added by default in the future, in which case >> this is a >> > more serious issue. >> >> IMO, distribution builds should try to enable *everything* so there >> isn't a question of "what do I have today?" when doing `import vtk`. >> Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to >> not have the linking problem. >> >> --Ben >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rroemer at gmail.com Sat Dec 8 18:07:13 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Sun, 9 Dec 2018 00:07:13 +0100 Subject: [vtk-developers] Examining vtkPolyData in GDB Message-ID: <8da23033-add1-a821-7393-41b5e315fa4c@gmail.com> Hello. I have a core dump and I want to find the coordinates of a specific point. How could I do this? From this point I don't know where to find them: (gdb) p *modPdA->Points->Data $13 = (vtkDoubleArray) { ? > = { ??? , double>> = { ????? = { ??????? = { ????????? = { ??????????? = { ????????????? _vptr.vtkObjectBase = 0x7f3f002f20b8 , ????????????? ReferenceCount = { ??????????????? > = { ????????????????? c = {} ??????????????? }, ??????????????? members of vtkAtomic: ??????????????? Atomic = 1 ????????????? }, ????????????? WeakPointers = 0x0 ??????????? }, ??????????? members of vtkObject: ??????????? Debug = false, ??????????? MTime = { ????????????? ModifiedTime = 15358794 ??????????? }, ??????????? SubjectHelper = 0x0 ????????? }, ????????? members of vtkAbstractArray: ????????? Size = 237615, ????????? MaxId = 130955, ????????? NumberOfComponents = 3, ????????? MaxDiscreteValues = 32, ????????? Name = 0x5605d333cc50 "Points", ????????? RebuildArray = false, ????????? Information = 0x0, ????????? ComponentNames = 0x0 ??????? }, ??????? members of vtkDataArray: ??????? LookupTable = 0x0, ??????? Range = {0, 0}, ??????? FiniteRange = {0, 0}, ??????? FiniteInformation = 0x0 ????? }, ????? members of vtkGenericDataArray, double>: ????? LegacyTuple = std::vector of length 3, capacity 3 = {-0.031233360353935744, -0.49638796694517223, 0.051219066321620647}, ????? LegacyValueRange = std::vector of length 0, capacity 0, ????? Lookup = { ??????? AssociatedArray = 0x5605d64cdc40, ??????? SortedArray = 0x0, ??????? FirstValue = 0x0, ??????? SortedArraySize = 0 ????? } ??? }, ??? members of vtkAOSDataArrayTemplate: ??? Buffer = 0x5605d4a11350 ? }, } -- Viele Gr??e Ronald R?mer From rroemer at gmail.com Sat Dec 8 18:20:53 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Sun, 9 Dec 2018 00:20:53 +0100 Subject: [vtk-developers] Examining vtkPolyData in GDB In-Reply-To: <8da23033-add1-a821-7393-41b5e315fa4c@gmail.com> References: <8da23033-add1-a821-7393-41b5e315fa4c@gmail.com> Message-ID: Ok, I was too hasty. It is (gdb) p modPdA->Points->Data->Buffer->Pointer[1338*3]@3 Am I right? On 09.12.18 00:07, Ronald R?mer wrote: > Hello. > > I have a core dump and I want to find the coordinates of a specific > point. How could I do this? From this point I don't know where to find them: > > (gdb) p *modPdA->Points->Data > $13 = (vtkDoubleArray) { > ? > = { > ??? , double>> = { > ????? = { > ??????? = { > ????????? = { > ??????????? = { > ????????????? _vptr.vtkObjectBase = 0x7f3f002f20b8 vtkDoubleArray+16>, > ????????????? ReferenceCount = { > ??????????????? > = { > ????????????????? c = {} > ??????????????? }, > ??????????????? members of vtkAtomic: > ??????????????? Atomic = 1 > ????????????? }, > ????????????? WeakPointers = 0x0 > ??????????? }, > ??????????? members of vtkObject: > ??????????? Debug = false, > ??????????? MTime = { > ????????????? ModifiedTime = 15358794 > ??????????? }, > ??????????? SubjectHelper = 0x0 > ????????? }, > ????????? members of vtkAbstractArray: > ????????? Size = 237615, > ????????? MaxId = 130955, > ????????? NumberOfComponents = 3, > ????????? MaxDiscreteValues = 32, > ????????? Name = 0x5605d333cc50 "Points", > ????????? RebuildArray = false, > ????????? Information = 0x0, > ????????? ComponentNames = 0x0 > ??????? }, > ??????? members of vtkDataArray: > ??????? LookupTable = 0x0, > ??????? Range = {0, 0}, > ??????? FiniteRange = {0, 0}, > ??????? FiniteInformation = 0x0 > ????? }, > ????? members of vtkGenericDataArray, > double>: > ????? LegacyTuple = std::vector of length 3, capacity 3 = > {-0.031233360353935744, -0.49638796694517223, 0.051219066321620647}, > ????? LegacyValueRange = std::vector of length 0, capacity 0, > ????? Lookup = { > ??????? AssociatedArray = 0x5605d64cdc40, > ??????? SortedArray = 0x0, > ??????? FirstValue = 0x0, > ??????? SortedArraySize = 0 > ????? } > ??? }, > ??? members of vtkAOSDataArrayTemplate: > ??? Buffer = 0x5605d4a11350 > ? }, } > -- Viele Gr??e Ronald R?mer From utkarsh.ayachit at kitware.com Mon Dec 10 07:32:08 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 10 Dec 2018 07:32:08 -0500 Subject: [vtk-developers] OK to drop support for OSPRAY_BUILD_DIR In-Reply-To: References: Message-ID: +1 Fewer rarely used options, the better! Utkarsh On Fri, Dec 7, 2018 at 2:17 PM David E DeMarle via vtk-developers wrote: > > Hey folks, > > Does anyone mind if I drop support for VTK to build against OSPRay's build directory? > > I don't think this will impact anyone very negatively because it is just two easy extra steps to configure a prefix path into your ospray build and run make install. > > thanks > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From cory.quammen at kitware.com Mon Dec 10 08:43:16 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 10 Dec 2018 08:43:16 -0500 Subject: [vtk-developers] Examining vtkPolyData in GDB In-Reply-To: References: <8da23033-add1-a821-7393-41b5e315fa4c@gmail.com> Message-ID: Yes, that appears correct to me. On Sat, Dec 8, 2018 at 6:20 PM Ronald R?mer wrote: > Ok, I was too hasty. > > It is > > (gdb) p modPdA->Points->Data->Buffer->Pointer[1338*3]@3 > > Am I right? > > On 09.12.18 00:07, Ronald R?mer wrote: > > Hello. > > > > I have a core dump and I want to find the coordinates of a specific > > point. How could I do this? From this point I don't know where to find > them: > > > > (gdb) p *modPdA->Points->Data > > $13 = (vtkDoubleArray) { > > > = { > > , double>> = { > > = { > > = { > > = { > > = { > > _vptr.vtkObjectBase = 0x7f3f002f20b8 > vtkDoubleArray+16>, > > ReferenceCount = { > > > = { > > c = {} > > }, > > members of vtkAtomic: > > Atomic = 1 > > }, > > WeakPointers = 0x0 > > }, > > members of vtkObject: > > Debug = false, > > MTime = { > > ModifiedTime = 15358794 > > }, > > SubjectHelper = 0x0 > > }, > > members of vtkAbstractArray: > > Size = 237615, > > MaxId = 130955, > > NumberOfComponents = 3, > > MaxDiscreteValues = 32, > > Name = 0x5605d333cc50 "Points", > > RebuildArray = false, > > Information = 0x0, > > ComponentNames = 0x0 > > }, > > members of vtkDataArray: > > LookupTable = 0x0, > > Range = {0, 0}, > > FiniteRange = {0, 0}, > > FiniteInformation = 0x0 > > }, > > members of vtkGenericDataArray, > > double>: > > LegacyTuple = std::vector of length 3, capacity 3 = > > {-0.031233360353935744, -0.49638796694517223, 0.051219066321620647}, > > LegacyValueRange = std::vector of length 0, capacity 0, > > Lookup = { > > AssociatedArray = 0x5605d64cdc40, > > SortedArray = 0x0, > > FirstValue = 0x0, > > SortedArraySize = 0 > > } > > }, > > members of vtkAOSDataArrayTemplate: > > Buffer = 0x5605d4a11350 > > }, } > > > -- > Viele Gr??e > Ronald R?mer > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Dec 10 10:07:00 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 10 Dec 2018 10:07:00 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> Message-ID: <20181210150700.GB1531@megas.kitware.com> On Fri, Dec 07, 2018 at 17:00:20 -0500, Jean-Christophe Fillion-Robin wrote: > > distribution builds should try to enable *everything* > > In that context, I don't think it makes sense to build VTK own python > interpreter. Ideally, it should be possible to run VTK test with or without > it. Yes, it is very odd that we've always built our own interpreter. IMO, it'd be better to just set PYTHONPATH on the test suite and use a standard Python executable. > I also envision we could have a "vtk-openvr" python module but it wouldn't > be available by default when installing vtk wheel. To support this level of > "modularity" , we would continue building part of VTK independently (for > example, we can already do this with the VTKOpenVR module) The new module system doesn't support this at the moment (i.e., the `find_package(VTK)` code has been ripped out of the OpenVR module). The problem with this is that if a module can be built inside and outside of VTK, dependent projects cannot know whether to do `find_package(VTK COMPONENTS RenderingOpenVR)` or `find_package(VTKOpenVR)`. --Ben From dave.demarle at kitware.com Tue Dec 11 13:01:41 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 11 Dec 2018 13:01:41 -0500 Subject: [vtk-developers] announce: expect some website and gitlab downtime this coming weekend Message-ID: Hey VTK folks, Kitware NY is moving into a new office building this weekend. This involves moving the company's network infrastructure. As a result, there will be some downtime in terms of the webpage, gitlab, and the dashboard machines. Our web servers (www.kitware.com, CMake, ParaView, VTK, ITK, etc. etc.) will be unavailable all day Dec. 15th while we physically move everything and complete the network cutover. We will set up a ?we are moving? page warning visitors to many of our primary external web sites that we are temporarily offline for maintenance. We are estimating the move to take 8 hours, give or take several hours. There is a good chance of network connectivity being unstable for a few days afterwards while we troubleshoot and fix any issues. Thanks and apologies ahead of time for any disruptions. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Dec 11 16:53:44 2018 From: sean at rogue-research.com (Sean McBride) Date: Tue, 11 Dec 2018 16:53:44 -0500 Subject: [vtk-developers] vtkHyperTreeGrid warnings on my bots... Message-ID: <20181211215344.1835538830@mail.rogue-research.com> Hi all, For a few days my bots have had several new warnings related to vtkHyperTreeGrid, ex: I used git blame and suspect fc207e8a905, which I tried to search in gitlab, but is it just me or is gitlab's search useless? It somehow finds zero results for both fc207e8a905 and fc207e8a9059a24c48827881090864a9cb3466d2... Anyway, maybe the authors of the recent code changes could fix those up please? :) Cheers, Sean From sebastien.jourdain at kitware.com Tue Dec 11 17:01:31 2018 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Tue, 11 Dec 2018 15:01:31 -0700 Subject: [vtk-developers] vtkHyperTreeGrid warnings on my bots... In-Reply-To: <20181211215344.1835538830@mail.rogue-research.com> References: <20181211215344.1835538830@mail.rogue-research.com> Message-ID: I'll take care of it. I've noticed that warning today as well. On Tue, Dec 11, 2018 at 2:59 PM Sean McBride wrote: > Hi all, > > For a few days my bots have had several new warnings related to > vtkHyperTreeGrid, ex: > > > > I used git blame and suspect fc207e8a905, which I tried to search in > gitlab, but is it just me or is gitlab's search useless? It somehow finds > zero results for both fc207e8a905 and > fc207e8a9059a24c48827881090864a9cb3466d2... > > Anyway, maybe the authors of the recent code changes could fix those up > please? :) > > Cheers, > > Sean > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Tue Dec 11 18:08:12 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 11 Dec 2018 18:08:12 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181210150700.GB1531@megas.kitware.com> References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> Message-ID: > it'd be better to just set PYTHONPATH on the test suite and use a standard Python executable. +1 > The new module system doesn't support this at the moment [...] The problem with this is that if a module can be built inside and outside of VTK I see. That shouldn't be a problem, we can always do the following: if(NOT VTK_SOURCE_DIR) // find method 1 else() // find method 2 endif() 1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and "vtkMy" examples up-to-date ? https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt 2. Are the functions vtk_module_add_module, vtk_module_link, ... designed to be used outside of VTK build tree ? 3. To test the updated build system with Slicer, would it be possible to rebase the branch "new-cmake-module" ? Thanks Jc On Mon, Dec 10, 2018 at 10:07 AM Ben Boeckel wrote: > On Fri, Dec 07, 2018 at 17:00:20 -0500, Jean-Christophe Fillion-Robin > wrote: > > > distribution builds should try to enable *everything* > > > > In that context, I don't think it makes sense to build VTK own python > > interpreter. Ideally, it should be possible to run VTK test with or > without > > it. > > Yes, it is very odd that we've always built our own interpreter. IMO, > it'd be better to just set PYTHONPATH on the test suite and use a > standard Python executable. > > > I also envision we could have a "vtk-openvr" python module but it > wouldn't > > be available by default when installing vtk wheel. To support this level > of > > "modularity" , we would continue building part of VTK independently (for > > example, we can already do this with the VTKOpenVR module) > > The new module system doesn't support this at the moment (i.e., the > `find_package(VTK)` code has been ripped out of the OpenVR module). The > problem with this is that if a module can be built inside and outside of > VTK, dependent projects cannot know whether to do `find_package(VTK > COMPONENTS RenderingOpenVR)` or `find_package(VTKOpenVR)`. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Dec 11 18:55:04 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 11 Dec 2018 18:55:04 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> Message-ID: <20181211235504.GA15582@megas.kitware.com> On Tue, Dec 11, 2018 at 18:08:12 -0500, Jean-Christophe Fillion-Robin wrote: > > The new module system doesn't support this at the moment [...] The > > problem with this is that if a module can be built inside and outside of VTK > > I see. That shouldn't be a problem, we can always do the following: You trimmed the important part of that. It isn't impossible. But the better question is "should we?". > if(NOT VTK_SOURCE_DIR) > // find method 1 > else() > // find method 2 > endif() The thing is that the module is incompatible from a consumer point of view in the two builds. One makes `VTK::RenderingOpenVR` and is provided via `find_package(VTK COMPONENTS RenderingOpenVR)`. The other?isn't. IMO, if the module can't be built as part of VTK often enough to be expected in a VTK build (e.g., pip or a Linux package), then it should just be in a separate repository. Also, the amount of code in that first one is not trivial: find_package(VTK COMPONENTS CommonCore IOImage ...) vtk_module_scan(...) vtk_module_build(...) vtk_module_wrap_python(...) and that still isn't going to work because it will need to detect when the module system is including the CMakeLists.txt file (or it just needs to be a separate directory completely). Would this outside-VTK build expect to put its Python module under `vtkmodules` still? Either way, I really don't want modules doing this kind of stuff. Either it's part of VTK or it isn't. > 1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and "vtkMy" > examples up-to-date ? I haven't looked at them yet. Other examples have been updated though. > https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt > https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt > > 2. Are the functions vtk_module_add_module, vtk_module_link, ... designed > to be used outside of VTK build tree ? Yes. VTK has no special inside-variable control over the code. Everything is passed in via parameters to the functions, so VTK's install directory variables are just parameters to this function. I'd like to keep it that way. > 3. To test the updated build system with Slicer, would it be possible to > rebase the branch "new-cmake-module" ? I've just rebased it today actually (for a ParaView rebase). Does Slicer make VTK modules itself or just consume them? --Ben From jcfr at kitware.com Wed Dec 12 14:35:37 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 12 Dec 2018 14:35:37 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181211235504.GA15582@megas.kitware.com> References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> Message-ID: >> module can be built inside and outside of VTK > But the better question is "should we?". Generally speaking yes, supporting the composition of CMake projects by both (1) "aggregation" (add_subdirectory) and (2) "finding dependency" is important. This applies to first class modules (e.g VTK module, ITK module, ... ) and also third-party project (e.g zlib, hdf5, ...) Also, by having no differences between the build system of "module or project" that can be either be aggregated or built as dependency, it is easy to maintain and communicate a set of best practices, streamline use of projects in various scenarios without having to maintain forks. > The thing is that the module is incompatible from a consumer point of view in the two builds. One makes `VTK::RenderingOpenVR` and is provided via `find_package(VTK COMPONENTS RenderingOpenVR)`. I think this is something that we probably need to address in CMake. In the mean time, we could have a "vtk_ns" and vtk_ns_colon variables and reference target with "${vtk_ns_colon}RenderingOpenVR". Also wondering if introducing some new genex could also help. > Would this outside-VTK build expect to put its Python module under `vtkmodules` still? Good question. When building wheels, the answer is yes. That way, the content of all "VTK" wheels would end up in the same folder "vtkmodules" and shared library are in the same directory. Installing/uninstalling wheels also work well because pip has a manifest and only removes the files it needs to. >> Are the functions vtk_module_add_module, vtk_module_link, ... designed to be used outside of VTK build tree ? > Yes. VTK has no special inside-variable control over the code. Everything is passed in via parameters to the functions This is great. This means that these functions could be used inside and outside VTK. > I've just rebased it today actually Great. > Does Slicer make VTK modules itself or just consume them? Almost both. Consume them: yes For the "make VTK modules", there are few cases: - reuse of VTK wrapping infrastructure through Slicer/CMake/vtkMacroKitPythonWrap.cmake - we have a lot of "pure" VTK library that currently use their own build system. In the future, it would be nice to standardize on reusing VTK build system. - building of VTK/Rendering/OpenVR into a Slicer extension. On Tue, Dec 11, 2018 at 6:55 PM Ben Boeckel wrote: > On Tue, Dec 11, 2018 at 18:08:12 -0500, Jean-Christophe Fillion-Robin > wrote: > > > The new module system doesn't support this at the moment [...] The > > > problem with this is that if a module can be built inside and outside > of VTK > > > > I see. That shouldn't be a problem, we can always do the following: > > You trimmed the important part of that. It isn't impossible. But the > better question is "should we?". > > > if(NOT VTK_SOURCE_DIR) > > // find method 1 > > else() > > // find method 2 > > endif() > > The thing is that the module is incompatible from a consumer point of > view in the two builds. One makes `VTK::RenderingOpenVR` and is provided > via `find_package(VTK COMPONENTS RenderingOpenVR)`. The other?isn't. > IMO, if the module can't be built as part of VTK often enough to be > expected in a VTK build (e.g., pip or a Linux package), then it should > just be in a separate repository. > > Also, the amount of code in that first one is not trivial: > > find_package(VTK COMPONENTS CommonCore IOImage ...) > vtk_module_scan(...) > vtk_module_build(...) > vtk_module_wrap_python(...) > > and that still isn't going to work because it will need to detect when > the module system is including the CMakeLists.txt file (or it just needs > to be a separate directory completely). Would this outside-VTK build > expect to put its Python module under `vtkmodules` still? Either way, I > really don't want modules doing this kind of stuff. Either it's part of > VTK or it isn't. > > > 1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and > "vtkMy" > > examples up-to-date ? > > I haven't looked at them yet. Other examples have been updated though. > > > > https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt > > > https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt > > > > 2. Are the functions vtk_module_add_module, vtk_module_link, ... designed > > to be used outside of VTK build tree ? > > Yes. VTK has no special inside-variable control over the code. > Everything is passed in via parameters to the functions, so VTK's > install directory variables are just parameters to this function. I'd > like to keep it that way. > > > 3. To test the updated build system with Slicer, would it be possible to > > rebase the branch "new-cmake-module" ? > > I've just rebased it today actually (for a ParaView rebase). Does Slicer > make VTK modules itself or just consume them? > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Dec 12 16:15:03 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 12 Dec 2018 16:15:03 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> Message-ID: <20181212211503.GA22183@megas.kitware.com> On Wed, Dec 12, 2018 at 14:35:37 -0500, Jean-Christophe Fillion-Robin wrote: > >> module can be built inside and outside of VTK > > But the better question is "should we?". > > Generally speaking yes, supporting the composition of CMake projects by > both (1) "aggregation" (add_subdirectory) and (2) "finding dependency" is > important. I'm not seeing a rationale for this though. "Because it's important" seems awfully tautological to me. VTK and other projects we maintain are the only ones I'm aware of which support this kind of stuff. I don't see it in the wider FOSS ecosystem. A similar situation happens nginx adding modules to build by extracting into a certain subdirectory, but then again, that's the *only* supported way of building nginx modules. > This applies to first class modules (e.g VTK module, ITK module, ... ) and > also third-party project (e.g zlib, hdf5, ...) Third party projects are different. It's either given an already built copy or it builds its own. It is done, basically, because Windows. If it weren't for that, I'd be really partial to just say "use apt or brew". Even there, the third party projects that get built as part of VTK are pretty set-in-stone. I've removed all user-facing variables from them. For example, if one wants an MPI-aware HDF5, it must be provided externally; VTK's hdf5 is never MPI-aware. Similarly, VTK's png has been stripped of its vectorized code (due to it simplifying the build by getting rid of lots of try_compile checks), and other projects only build what VTK needs from it. > Also, by having no differences between the build system of "module or > project" that can be either be aggregated or built as dependency, it is > easy to maintain and communicate a set of best practices, streamline use of > projects in various scenarios without having to maintain forks. There's always going to be a difference. I'd rather just document how to use VTK via `find_package(VTK)`. > > The thing is that the module is incompatible from a consumer point of > view in the two builds. One makes `VTK::RenderingOpenVR` and is provided > via `find_package(VTK COMPONENTS RenderingOpenVR)`. > > I think this is something that we probably need to address in CMake. In the > mean time, we could have a "vtk_ns" and vtk_ns_colon variables and > reference target with "${vtk_ns_colon}RenderingOpenVR". Also wondering if > introducing some new genex could also help. This sounds super hacky to me. The module system certainly isn't going to support it; it's complex enough as it is to deal with namespaces. This is the best I can see right now: if (VTK_HAS_OPENVR) # variable provided by the user find_package(VTK REQUIRED COMPONENTS RenderingOpenVR) set(openvr_target VTK::RenderingOpenVR) else () find_package(VTKRenderingOpenVR REQUIRED) # It really shouldn't provide VTK::RenderingOpenVR. set(openvr_target VTKRenderingOpenVR) endif () > > Would this outside-VTK build expect to put its Python module under > `vtkmodules` still? > > Good question. When building wheels, the answer is yes. That way, the > content of all "VTK" wheels would end up in the same folder "vtkmodules" > and shared library are in the same directory. Installing/uninstalling > wheels also work well because pip has a manifest and only removes the files > it needs to. The problem is that this breaks `vtkmodules.all.vtkOpenVROverlay` because `vtkmodules.all` only includes modules built by VTK itself. It means that we really shouldn't provide it at all if users have to know the module name anyways. > > Does Slicer make VTK modules itself or just consume them? > > Almost both. > > Consume them: yes > > For the "make VTK modules", there are few cases: > - reuse of VTK wrapping infrastructure through > Slicer/CMake/vtkMacroKitPythonWrap.cmake > The new wrapping code assumes VTK modules (i.e., built via `vtk_module_scan` and `vtk_module_build`). If the relevant properties aren't set on the target to be wrapped, they'll not do the right things. > - we have a lot of "pure" VTK library that currently use their own build > system. In the future, it would be nice to standardize on reusing VTK build > system. That should be doable. > - building of VTK/Rendering/OpenVR into a Slicer extension. Why is it not just used as a dependency like this? find_package(VTK COMPONENTS RenderingOpenVR) if (VTK_RenderingOpenVR_FOUND) add_subdirectory(openvr_ext) endif () --Ben From robert.maynard at kitware.com Wed Dec 12 16:34:30 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 12 Dec 2018 16:34:30 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181212211503.GA22183@megas.kitware.com> References: <20181128160041.GA25730@megas.kitware.com> <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> Message-ID: I am going to just respond to the comments about 'aggregation ' and 'finding' On Wed, Dec 12, 2018 at 4:15 PM Ben Boeckel via vtk-developers wrote: > > On Wed, Dec 12, 2018 at 14:35:37 -0500, Jean-Christophe Fillion-Robin wrote: > > >> module can be built inside and outside of VTK > > > But the better question is "should we?". > > > > Generally speaking yes, supporting the composition of CMake projects by > > both (1) "aggregation" (add_subdirectory) and (2) "finding dependency" is > > important. > > I'm not seeing a rationale for this though. "Because it's important" > seems awfully tautological to me. VTK and other projects we maintain are > the only ones I'm aware of which support this kind of stuff. I don't see > it in the wider FOSS ecosystem. A similar situation happens nginx adding > modules to build by extracting into a certain subdirectory, but then > again, that's the *only* supported way of building nginx modules. > This is common in the wild ( see catch2 ) to such a degree that CMake now has FetchContent which explicitly supports the workflow of using find_package and than falling back to add_subdirectory. I expect that this workflow will increase as FetchContent becomes more wildly available. > > This applies to first class modules (e.g VTK module, ITK module, ... ) and > > also third-party project (e.g zlib, hdf5, ...) > > Third party projects are different. It's either given an already built > copy or it builds its own. It is done, basically, because Windows. If it > weren't for that, I'd be really partial to just say "use apt or brew". > Even there, the third party projects that get built as part of VTK are > pretty set-in-stone. I've removed all user-facing variables from them. > For example, if one wants an MPI-aware HDF5, it must be provided > externally; VTK's hdf5 is never MPI-aware. Similarly, VTK's png has been > stripped of its vectorized code (due to it simplifying the build by > getting rid of lots of try_compile checks), and other projects only > build what VTK needs from it. > > > Also, by having no differences between the build system of "module or > > project" that can be either be aggregated or built as dependency, it is > > easy to maintain and communicate a set of best practices, streamline use of > > projects in various scenarios without having to maintain forks. > > There's always going to be a difference. I'd rather just document how to > use VTK via `find_package(VTK)`. > > > > The thing is that the module is incompatible from a consumer point of > > view in the two builds. One makes `VTK::RenderingOpenVR` and is provided > > via `find_package(VTK COMPONENTS RenderingOpenVR)`. > > > > I think this is something that we probably need to address in CMake. In the > > mean time, we could have a "vtk_ns" and vtk_ns_colon variables and > > reference target with "${vtk_ns_colon}RenderingOpenVR". Also wondering if > > introducing some new genex could also help. > > This sounds super hacky to me. The module system certainly isn't going > to support it; it's complex enough as it is to deal with namespaces. > This is the best I can see right now: > > if (VTK_HAS_OPENVR) # variable provided by the user > find_package(VTK REQUIRED COMPONENTS RenderingOpenVR) > set(openvr_target VTK::RenderingOpenVR) > else () > find_package(VTKRenderingOpenVR REQUIRED) > # It really shouldn't provide VTK::RenderingOpenVR. > set(openvr_target VTKRenderingOpenVR) > endif () > > > > Would this outside-VTK build expect to put its Python module under > > `vtkmodules` still? > > > > Good question. When building wheels, the answer is yes. That way, the > > content of all "VTK" wheels would end up in the same folder "vtkmodules" > > and shared library are in the same directory. Installing/uninstalling > > wheels also work well because pip has a manifest and only removes the files > > it needs to. > > The problem is that this breaks `vtkmodules.all.vtkOpenVROverlay` > because `vtkmodules.all` only includes modules built by VTK itself. It > means that we really shouldn't provide it at all if users have to know > the module name anyways. > > > > Does Slicer make VTK modules itself or just consume them? > > > > Almost both. > > > > Consume them: yes > > > > For the "make VTK modules", there are few cases: > > - reuse of VTK wrapping infrastructure through > > Slicer/CMake/vtkMacroKitPythonWrap.cmake > > > > The new wrapping code assumes VTK modules (i.e., built via > `vtk_module_scan` and `vtk_module_build`). If the relevant properties > aren't set on the target to be wrapped, they'll not do the right things. > > > - we have a lot of "pure" VTK library that currently use their own build > > system. In the future, it would be nice to standardize on reusing VTK build > > system. > > That should be doable. > > > - building of VTK/Rendering/OpenVR into a Slicer extension. > > Why is it not just used as a dependency like this? > > find_package(VTK COMPONENTS RenderingOpenVR) > if (VTK_RenderingOpenVR_FOUND) > add_subdirectory(openvr_ext) > endif () > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From ben.boeckel at kitware.com Wed Dec 12 17:17:16 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 12 Dec 2018 17:17:16 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> Message-ID: <20181212221716.GA2777@megas.kitware.com> On Wed, Dec 12, 2018 at 16:34:30 -0500, Robert Maynard wrote: > This is common in the wild ( see catch2 ) to such a degree that CMake > now has FetchContent which explicitly supports the workflow of using > find_package and than falling back to add_subdirectory. I expect that > this workflow will increase as FetchContent becomes more wildly > available. OK, so I do remember googletest also doing stuff like this. But these are test dependencies. Are there any that you can think of that do this for things like vtkzlib? Though there I suspect that no one does the proper mangling that needs to be done? Also, that's more like remote modules than what is being requested here. If that's the case, maybe RenderingOpenVR should just become a remote module instead? --Ben From jcfr at kitware.com Wed Dec 12 19:08:30 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 12 Dec 2018 19:08:30 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181212221716.GA2777@megas.kitware.com> References: <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> Message-ID: > I'm not seeing a rationale By ensuring the build system of a VTK/ITK/Slicer... modules is the same if it is built inside or outside the "main" application/libraries allows the following: - avoid special case, tribal knowledge, ... : a module layout is consistent - support for packaging independently some part @Matt: Could you share your experience within the ITK community ? > > > Would this outside-VTK build expect to put its Python module under `vtkmodules` still? > > Good question. When building wheels, the answer is yes. [...] > The problem is that this breaks `vtkmodules.all.vtkOpenVROverlay` because `vtkmodules.all` only includes modules built by VTK itself. > It means that we really shouldn't provide it at all if users have to know the module name anyways. In a nutshell, python support the concept of "entry_points". Each time a vtk wheel associated with a module is installed, the namespace "vtk.modules" could automatically be updated with a new entry (e.g "vtk.modules.vtkopenvr"). Then, in the "all.py" we would make use of "pkg_resources.iter_entry_points" to import the associated classes. As similar approach was adopted by Girder, see here > The new wrapping code assumes VTK modules (i.e., built via `vtk_module_scan` and `vtk_module_build`). If the relevant properties aren't set on the target to be wrapped, they'll not do the right things. I see. By copying the relevant CMake functions from VTK 8.2, we should be able to keep things working. > maybe RenderingOpenVR should just become a remote module instead? Since adding a remote module simply means download the source, then call "add_subdirectory()" with two parameters. Unless a VTK module can be implemented so that it can be built inside and outside of the source tree, I don't think it will be supported. > > - building of VTK/Rendering/OpenVR into a Slicer extension. > Why is it not just used as a dependency like this? > find_package(VTK COMPONENTS RenderingOpenVR) > if (VTK_RenderingOpenVR_FOUND) > add_subdirectory(openvr_ext) > endif () Because: * In order to reuse the install rules of the module and package it, we need the associated build tree. * The build of VTK in Slicer proper has no dependency on openvr external project, this is lever to the SlicerOpenVR extension. See "SuperBuild" folder in https://github.com/KitwareMedical/SlicerVirtualReality On Wed, Dec 12, 2018 at 5:17 PM Ben Boeckel wrote: > On Wed, Dec 12, 2018 at 16:34:30 -0500, Robert Maynard wrote: > > This is common in the wild ( see catch2 ) to such a degree that CMake > > now has FetchContent which explicitly supports the workflow of using > > find_package and than falling back to add_subdirectory. I expect that > > this workflow will increase as FetchContent becomes more wildly > > available. > > OK, so I do remember googletest also doing stuff like this. But these > are test dependencies. Are there any that you can think of that do this > for things like vtkzlib? Though there I suspect that no one does the > proper mangling that needs to be done? > > Also, that's more like remote modules than what is being requested here. > If that's the case, maybe RenderingOpenVR should just become a remote > module instead? > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Dec 12 23:57:49 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 12 Dec 2018 20:57:49 -0800 Subject: [vtk-developers] Cycles introduced in recent commit Message-ID: Sebastien, Yur IO/Web has introduced a cyclic dependency. Bill CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "vtkOpenGL" of type SHARED_LIBRARY depends on "vtkRendering" (weak) depends on "vtkDomainsChemistry" (weak) depends on "vtkIO" (weak) depends on "vtkIOExport" (weak) depends on "vtkRenderingGL2PSOpenGL2" (weak) depends on "vtkDomainsChemistryOpenGL2Objects" (strong) "vtkRendering" of type SHARED_LIBRARY depends on "vtkIO" (weak) depends on "vtkIOExport" (weak) depends on "vtkRenderingGL2PSOpenGL2" (weak) depends on "vtkOpenGL" (weak) depends on "vtkDomainsChemistry" (weak) "vtkIO" of type SHARED_LIBRARY depends on "vtkIOExport" (weak) depends on "vtkRendering" (weak) depends on "vtkRenderingGL2PSOpenGL2" (weak) depends on "vtkOpenGL" (weak) depends on "vtkDomainsChemistry" (weak) depends on "vtkIOWebObjects" (strong) "vtkDomainsChemistry" of type SHARED_LIBRARY depends on "vtkIO" (weak) depends on "vtkIOExport" (weak) depends on "vtkRendering" (weak) depends on "vtkRenderingGL2PSOpenGL2" (weak) depends on "vtkOpenGL" (weak) "vtkDomainsChemistryOpenGL2Objects" of type OBJECT_LIBRARY depends on "vtkDomainsChemistry" (strong) "vtkRenderingGL2PSOpenGL2" of type SHARED_LIBRARY depends on "vtkOpenGL" (weak) depends on "vtkRendering" (weak) depends on "vtkDomainsChemistry" (weak) depends on "vtkIO" (weak) depends on "vtkIOExport" (weak) "vtkIOExport" of type SHARED_LIBRARY depends on "vtkIO" (weak) depends on "vtkRendering" (weak) depends on "vtkRenderingGL2PSOpenGL2" (weak) depends on "vtkOpenGL" (weak) depends on "vtkDomainsChemistry" (weak) "vtkIOWebObjects" of type OBJECT_LIBRARY depends on "vtkIOExport" (strong) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. -- Build files have been written to: /Users -- Unpaid intern in BillsParadise at noware dot com From bill.lorensen at gmail.com Thu Dec 13 00:48:52 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 12 Dec 2018 21:48:52 -0800 Subject: [vtk-developers] Cycles introduced in recent commit In-Reply-To: References: Message-ID: I just cleared my CMakeLists.txt file and the cycle is gone. I must have had something turned on that caused the cycle. I'll keep an eye on this one. On Wed, Dec 12, 2018 at 8:57 PM Bill Lorensen wrote: > > Sebastien, > > Yur IO/Web has introduced a cyclic dependency. > > Bill > > CMake Error: The inter-target dependency graph contains the following > strongly connected component (cycle): > > "vtkOpenGL" of type SHARED_LIBRARY > > depends on "vtkRendering" (weak) > > depends on "vtkDomainsChemistry" (weak) > > depends on "vtkIO" (weak) > > depends on "vtkIOExport" (weak) > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > depends on "vtkDomainsChemistryOpenGL2Objects" (strong) > > "vtkRendering" of type SHARED_LIBRARY > > depends on "vtkIO" (weak) > > depends on "vtkIOExport" (weak) > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > depends on "vtkOpenGL" (weak) > > depends on "vtkDomainsChemistry" (weak) > > "vtkIO" of type SHARED_LIBRARY > > depends on "vtkIOExport" (weak) > > depends on "vtkRendering" (weak) > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > depends on "vtkOpenGL" (weak) > > depends on "vtkDomainsChemistry" (weak) > > depends on "vtkIOWebObjects" (strong) > > "vtkDomainsChemistry" of type SHARED_LIBRARY > > depends on "vtkIO" (weak) > > depends on "vtkIOExport" (weak) > > depends on "vtkRendering" (weak) > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > depends on "vtkOpenGL" (weak) > > "vtkDomainsChemistryOpenGL2Objects" of type OBJECT_LIBRARY > > depends on "vtkDomainsChemistry" (strong) > > "vtkRenderingGL2PSOpenGL2" of type SHARED_LIBRARY > > depends on "vtkOpenGL" (weak) > > depends on "vtkRendering" (weak) > > depends on "vtkDomainsChemistry" (weak) > > depends on "vtkIO" (weak) > > depends on "vtkIOExport" (weak) > > "vtkIOExport" of type SHARED_LIBRARY > > depends on "vtkIO" (weak) > > depends on "vtkRendering" (weak) > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > depends on "vtkOpenGL" (weak) > > depends on "vtkDomainsChemistry" (weak) > > "vtkIOWebObjects" of type OBJECT_LIBRARY > > depends on "vtkIOExport" (strong) > > At least one of these targets is not a STATIC_LIBRARY. Cyclic > dependencies are allowed only among static libraries. > > -- Build files have been written to: /Users > > > -- > Unpaid intern in BillsParadise at noware dot com -- Unpaid intern in BillsParadise at noware dot com From sebastien.jourdain at kitware.com Thu Dec 13 09:39:51 2018 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 13 Dec 2018 07:39:51 -0700 Subject: [vtk-developers] Cycles introduced in recent commit In-Reply-To: References: Message-ID: Hi Bill, Let me know if you run into something strange like that again... Thanks, Seb On Wed, Dec 12, 2018 at 10:49 PM Bill Lorensen wrote: > I just cleared my CMakeLists.txt file and the cycle is gone. I must > have had something turned on that caused the cycle. I'll keep an eye > on this one. > > On Wed, Dec 12, 2018 at 8:57 PM Bill Lorensen > wrote: > > > > Sebastien, > > > > Yur IO/Web has introduced a cyclic dependency. > > > > Bill > > > > CMake Error: The inter-target dependency graph contains the following > > strongly connected component (cycle): > > > > "vtkOpenGL" of type SHARED_LIBRARY > > > > depends on "vtkRendering" (weak) > > > > depends on "vtkDomainsChemistry" (weak) > > > > depends on "vtkIO" (weak) > > > > depends on "vtkIOExport" (weak) > > > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > > > depends on "vtkDomainsChemistryOpenGL2Objects" (strong) > > > > "vtkRendering" of type SHARED_LIBRARY > > > > depends on "vtkIO" (weak) > > > > depends on "vtkIOExport" (weak) > > > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > > > depends on "vtkOpenGL" (weak) > > > > depends on "vtkDomainsChemistry" (weak) > > > > "vtkIO" of type SHARED_LIBRARY > > > > depends on "vtkIOExport" (weak) > > > > depends on "vtkRendering" (weak) > > > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > > > depends on "vtkOpenGL" (weak) > > > > depends on "vtkDomainsChemistry" (weak) > > > > depends on "vtkIOWebObjects" (strong) > > > > "vtkDomainsChemistry" of type SHARED_LIBRARY > > > > depends on "vtkIO" (weak) > > > > depends on "vtkIOExport" (weak) > > > > depends on "vtkRendering" (weak) > > > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > > > depends on "vtkOpenGL" (weak) > > > > "vtkDomainsChemistryOpenGL2Objects" of type OBJECT_LIBRARY > > > > depends on "vtkDomainsChemistry" (strong) > > > > "vtkRenderingGL2PSOpenGL2" of type SHARED_LIBRARY > > > > depends on "vtkOpenGL" (weak) > > > > depends on "vtkRendering" (weak) > > > > depends on "vtkDomainsChemistry" (weak) > > > > depends on "vtkIO" (weak) > > > > depends on "vtkIOExport" (weak) > > > > "vtkIOExport" of type SHARED_LIBRARY > > > > depends on "vtkIO" (weak) > > > > depends on "vtkRendering" (weak) > > > > depends on "vtkRenderingGL2PSOpenGL2" (weak) > > > > depends on "vtkOpenGL" (weak) > > > > depends on "vtkDomainsChemistry" (weak) > > > > "vtkIOWebObjects" of type OBJECT_LIBRARY > > > > depends on "vtkIOExport" (strong) > > > > At least one of these targets is not a STATIC_LIBRARY. Cyclic > > dependencies are allowed only among static libraries. > > > > -- Build files have been written to: /Users > > > > > > -- > > Unpaid intern in BillsParadise at noware dot com > > > > -- > Unpaid intern in BillsParadise at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Thu Dec 13 11:02:42 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 13 Dec 2018 11:02:42 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128204433.GB4242@megas.kitware.com> <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> Message-ID: On Wed, Dec 12, 2018 at 7:08 PM Jean-Christophe Fillion-Robin < jcfr at kitware.com> wrote: > > > I'm not seeing a rationale > > By ensuring the build system of a VTK/ITK/Slicer... modules is the same if > it is built inside or outside the "main" application/libraries allows the > following: > > - avoid special case, tribal knowledge, ... : a module layout is consistent > > - support for packaging independently some part > > > @Matt: Could you share your experience within the ITK community ? > > >> We have seen success in the ITK community by maintaining a robust set of common functionality in the core repository and enabling extension modules in other repositories. This provides: - Flexibility to mature a module in an incremental process. - More contrained core repository build times and distributed builds of other modules. - Enhanced backwards compatibility for the core and rapid changes in the peripherary. - Enhanced participation from the huge talent pool in the broader FOSS ecosystem. - Control and a sense of ownership on individual module repositories. If the new module system for VTK improves the extensitibility potential of modules, it will be a big enhancement. Ideally, we would have C++XX standard modules and a way to bulid them in place along with One Package Manager To Rule Them All. Since these are currently not available, the ability to share and extend VTK code is a good step. A bonus step forward would allow dependencies between ITK and VTK modules. These are all good discussion topics, but to come back to the thread topic, which is important to massively improve VTK's value by enabling integration with other Python packages: thanks to Dave for starting a patch. I wonder we can set a warning / error that BUILD_TESTING has to be disabled when VTK_ENABLE_VTKPYTHON is disabled, change the patch from a WIP, and use VTK_ENABLE_VTKPYTHON=OFF in the VTK Python wheel build. In the future, it would be helpful to have VTK_ENABLE_VTKPYTHON OFF by default and use a provided Python. 2 cents, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Dec 13 11:50:06 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 13 Dec 2018 11:50:06 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> Message-ID: <20181213165006.GA25088@megas.kitware.com> On Wed, Dec 12, 2018 at 19:08:30 -0500, Jean-Christophe Fillion-Robin wrote: > > I'm not seeing a rationale > > By ensuring the build system of a VTK/ITK/Slicer... modules is the same if > it is built inside or outside the "main" application/libraries allows the > following: It *cannot* be the same. `find_package(VTK)` only contains the information VTK had at the time of *its* build. Modules built outside of it won't show up. If a module is part of VTK, VTK does lots of heavy lifting one-time-setup things. Install directories, minimum CMake version, CMake policies, etc. Any standalone module will have to copy that information. I suspect that's at least 100 lines of CMake code (some of which can't be abstracted out). > - avoid special case, tribal knowledge, ... : a module layout is consistent This support itself is a special case itself AFAICS. Module layouts are consistent right now. Modules which do this are going to be the different ones. > - support for packaging independently some part That's just more code that modules will have to duplicate from VTK. > @Matt: Could you share your experience within the ITK community ? This seems more like remote modules as a path for migrating *into* VTK. Building OpenVR separately is like moving it *out* of VTK. *That* is what I don't understand. > > > > Would this outside-VTK build expect to put its Python module under > `vtkmodules` still? > > > Good question. When building wheels, the answer is yes. [...] > > The problem is that this breaks `vtkmodules.all.vtkOpenVROverlay` because > `vtkmodules.all` only includes modules built by VTK itself. > > It means that we really shouldn't provide it at all if users have to know > the module name anyways. > > In a nutshell, python support the concept of "entry_points". Each time a > vtk wheel associated with a module is installed, the namespace > "vtk.modules" could automatically be updated with a new entry (e.g > "vtk.modules.vtkopenvr"). Then, in the "all.py" we would make use of > "pkg_resources.iter_entry_points" to import the associated classes. > > As similar approach was adopted by Girder, see here > OK, maybe you've solved Python. Now what of CMake (`find_package`) and Java? > > The new wrapping code assumes VTK modules (i.e., built via > `vtk_module_scan` and `vtk_module_build`). If the relevant properties > aren't set on the target to be wrapped, they'll not do the right things. > > I see. By copying the relevant CMake functions from VTK 8.2, we should be > able to keep things working. What? I'm not maintaining that. The information that is used by the old wrapping macros doesn't exist anymore either; it's all stored on properites of the targets in which case it's basically the new wrapping functions anyways. In addition, since PythonD libraries are now gone, modules must import dependent modules first. Here's vtkPVCommon.py from ParaView: from __future__ import absolute_import from . import vtkClientServer from vtkmodules import vtkCommonCore from vtkmodules import vtkIOXMLParser from .vtkPVCommonPython import * If a module depends on one not using the standard macros, where the Python bindings for the module is stored needs to be accessible somehow. > > maybe RenderingOpenVR should just become a remote module instead? > > Since adding a remote module simply means download the source, then call > "add_subdirectory()" with two parameters. Unless a VTK module can be > implemented so that it can be built inside and outside of the source tree, > I don't think it will be supported. Remote modules with the new system would not be `add_subdirectory`. The downloaded source directory is added to the `vtk_modules_find_modules` function. What doesn't work right now is that it assumes everything is in the source tree. > > > - building of VTK/Rendering/OpenVR into a Slicer extension. > > > Why is it not just used as a dependency like this? > > find_package(VTK COMPONENTS RenderingOpenVR) > > if (VTK_RenderingOpenVR_FOUND) > > add_subdirectory(openvr_ext) > > endif () > > Because: > * In order to reuse the install rules of the module and package it, we need > the associated build tree. Not in general, you don't. For example, the paraview-superbuild makes packages from the install trees of all of its projects by doing the proper dependency traversal of the libraries. The new CMake install rules work should make it easy for Slicer to package it up from a separate build/install. > * The build of VTK in Slicer proper has no dependency on openvr external > project, this is lever to the SlicerOpenVR extension. See "SuperBuild" > folder in https://github.com/KitwareMedical/SlicerVirtualReality Again, this, to me, just points to OpenVR maybe being a separate repository completely and optionally a remote module. Personally, I'd have the superbuild turn on the OpenVR dependency in VTK if the extension is wanted. If it isn't there, the VTK can't be used to build the SlicerOpenVR extension. --Ben From matt.mccormick at kitware.com Thu Dec 13 13:16:40 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 13 Dec 2018 13:16:40 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181213165006.GA25088@megas.kitware.com> References: <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> Message-ID: On Thu, Dec 13, 2018 at 11:50 AM Ben Boeckel wrote: > On Wed, Dec 12, 2018 at 19:08:30 -0500, Jean-Christophe Fillion-Robin > wrote: > > > I'm not seeing a rationale > > > > By ensuring the build system of a VTK/ITK/Slicer... modules is the same > if > > it is built inside or outside the "main" application/libraries allows the > > following: > > It *cannot* be the same. `find_package(VTK)` only contains the > information VTK had at the time of *its* build. Modules built outside of > it won't show up. If a module is part of VTK, VTK does lots of heavy > lifting one-time-setup things. Install directories, minimum CMake > version, CMake policies, etc. Any standalone module will have to copy > that information. I suspect that's at least 100 lines of CMake code > (some of which can't be abstracted out). > > > - avoid special case, tribal knowledge, ... : a module layout is > consistent > > This support itself is a special case itself AFAICS. Module layouts are > consistent right now. Modules which do this are going to be the > different ones. > > > - support for packaging independently some part > > That's just more code that modules will have to duplicate from VTK. > The suggested duplication is not necessary. To implement, on a high level: - Required CMake settings are stored in VTKConfig.cmake - There is a VTKTargets.cmake that contains all the target information from the main build. - Targets.cmake contains module target information. This is kept in an "index" (a certain folder relative to VTKConfig.cmake) that is searched and loaded by VTKConfig.cmake The module contains minimal CMake setup, but that is required for any project that depends on VTK. > > @Matt: Could you share your experience within the ITK community ? > > > > This seems more like remote modules as a path for migrating *into* VTK. > Building OpenVR separately is like moving it *out* of VTK. *That* is > what I don't understand. > > It is not possible or desirable for everything to move into VTK. On one side, the barrier to entry into VTK is high, and and on the other side, centralized maintenance cannot sustainably maintain everything under the sun. Distributed development of domain specific, etc., modules will be helpful. OpenVR, for example, requires special hardware and software to test. Separate development and testing enables folks to set up independent testing on configuration that satisfy its dependencies. - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Dec 13 13:48:11 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 13 Dec 2018 13:48:11 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> Message-ID: <20181213184811.GA10898@megas.kitware.com> On Thu, Dec 13, 2018 at 13:16:40 -0500, Matt McCormick wrote: > - Required CMake settings are stored in VTKConfig.cmake VTK's new vtk-config.cmake, right now exports this set of variables: VTK_VERSION VTK_LEGACY_REMOVE VTK_HAS_VTKm VTK_OPENGL_HAS_EGL VTK_WRAP_PYTHON VTK_WRAP_JAVE VTK_PYTHONPATH VTK_LIBRARIES And variables which don't make sense aren't set at all (e.g., VTK_OPENGL_HAS_EGL is only set if the VTK::opengl module has been built and VTK_PYTHONPATH is only set if Python wrapping has been enabled). VTK_LIBRARIES is just the list of targets from COMPONENTS and OPTIONAL_COMPONENTS that have been requested. If no components are requested, VTK_LIBRARIES is empty. No other variables are required to use VTK from CMake, so they aren't provided. > - There is a VTKTargets.cmake that contains all the target information from > the main build. Eh, there's more than that now because CMake only exports properties it deems as important. Other sidecar files exist too. > - Targets.cmake contains module target information. This is kept in > an "index" (a certain folder relative to VTKConfig.cmake) that is searched > and loaded by VTKConfig.cmake vtk-config.cmake doesn't support dropping things in here. The new module system has this: VTK-targets.cmake VTK-vtk-module-properties.cmake VTK-vtk-module-find-packages.cmake (uses components to only find what was requested) VTK-vtk-python-module-properties.cmake (if Python wrapping is enabled) The old module system globbing for this information has historically not worked out well. I don't want to continue that mistake. Concretely, in an install of ParaView, `find_package(VTK)` didn't work because ParaView modules were included in VTK's glob and assumed variables were set that only ParaView's config provided. This errored out and made it impossible to use without setting a magic ParaView variable before finding VTK. I really don't want people to say "find VTK doesn't work" because some other project dropped a broken CMake file in its CMake configuration directory. > The module contains minimal CMake setup, but that is required for any > project that depends on VTK. Yes, that is not "a few lines". It involves finding VTK, scanning modules, making sure that the found VTK provides the required modules, building modules, optionally wrapping, installing CMake configuration files, etc. And that doesn't include packaging. It's hard enough to make sure VTK's CMake code works well that I don't want to try and also fix it for projects using VTK at the same time (and as soon as they are not basically VTK-module-only projects, they're on their own anyways). > > > @Matt: Could you share your experience within the ITK community ? > > > > > > > > This seems more like remote modules as a path for migrating *into* VTK. > > Building OpenVR separately is like moving it *out* of VTK. *That* is > > what I don't understand. > > > It is not possible or desirable for everything to move into VTK. On one > side, the barrier to entry into VTK is high, and and on the other side, > centralized maintenance cannot sustainably maintain everything under the > sun. Distributed development of domain specific, etc., modules will be > helpful. Agreed. My follow-up: why do they have to support being built *as part of VTK* then? Why is `find_package(VTK)` not sufficient as the *only* way to build these projects like with every other dependency? I know the existing module system wrapping and such wasn't nice outside of VTK, but that is now fixed. > OpenVR, for example, requires special hardware and software to test. > Separate development and testing enables folks to set up independent > testing on configuration that satisfy its dependencies. That's an argument for a separate repo to me? --Ben From matt.mccormick at kitware.com Thu Dec 13 15:42:49 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 13 Dec 2018 15:42:49 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181213184811.GA10898@megas.kitware.com> References: <20181210150700.GB1531@megas.kitware.com> <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> Message-ID: On Thu, Dec 13, 2018 at 1:48 PM Ben Boeckel wrote: > On Thu, Dec 13, 2018 at 13:16:40 -0500, Matt McCormick wrote: > > - Required CMake settings are stored in VTKConfig.cmake > > VTK's new vtk-config.cmake, right now exports this set of variables: > > VTK_VERSION VTK_LEGACY_REMOVE VTK_HAS_VTKm VTK_OPENGL_HAS_EGL > VTK_WRAP_PYTHON VTK_WRAP_JAVE VTK_PYTHONPATH VTK_LIBRARIES > > And variables which don't make sense aren't set at all (e.g., > VTK_OPENGL_HAS_EGL is only set if the VTK::opengl module has been > built and VTK_PYTHONPATH is only set if Python wrapping has been > enabled). VTK_LIBRARIES is just the list of targets from COMPONENTS and > OPTIONAL_COMPONENTS that have been requested. If no components are > requested, VTK_LIBRARIES is empty. > > No other variables are required to use VTK from CMake, so they aren't > provided. > Thanks for the explanation. > > > - There is a VTKTargets.cmake that contains all the target information > from > > the main build. > > Eh, there's more than that now because CMake only exports properties it > deems as important. Other sidecar files exist too. > > Yes. And, as discussed below, there is an additional need for calling the "find_dependency" macro as discussed below... > > - Targets.cmake contains module target information. This is kept > in > > an "index" (a certain folder relative to VTKConfig.cmake) that is > searched > > and loaded by VTKConfig.cmake > > vtk-config.cmake doesn't support dropping things in here. The new module > system has this: > > VTK-targets.cmake > VTK-vtk-module-properties.cmake > VTK-vtk-module-find-packages.cmake (uses components to only find what > was requested) > VTK-vtk-python-module-properties.cmake (if Python wrapping is enabled) > > The old module system globbing for this information has historically not > worked out well. I don't want to continue that mistake. Concretely, in > an install of ParaView, `find_package(VTK)` didn't work because ParaView > modules were included in VTK's glob and assumed variables were set that > only ParaView's config provided. This errored out and made it impossible > to use without setting a magic ParaView variable before finding VTK. It sounds like the VTK modules created by ParaView needed to call find_dependency(ParaView) like third party modules do that defer to the configuration of system versions of libraries. > I > really don't want people to say "find VTK doesn't work" because some > other project dropped a broken CMake file in its CMake configuration > directory. > We support using third party libraries because there is a practical need and desire to use them. There may be bugs in third party software. If there are bugs in the third party software CMake configuration, then that software cannot be used until it is fixed. If there is a bug introduced by a third party VTK module, then that module cannot be used. I do not think it is a show-stopper. > > > The module contains minimal CMake setup, but that is required for any > > project that depends on VTK. > > Yes, that is not "a few lines". It involves finding VTK, scanning > modules, making sure that the found VTK provides the required modules, > building modules, optionally wrapping, installing CMake configuration > files, etc. And that doesn't include packaging. CMake functions to do all these things could be encapsulated and provided instead of duplicated. > > > > > > @Matt: Could you share your experience within the ITK community ? > > > > > > > > > > > > This seems more like remote modules as a path for migrating *into* VTK. > > > Building OpenVR separately is like moving it *out* of VTK. *That* is > > > what I don't understand. > > > > > It is not possible or desirable for everything to move into VTK. On one > > side, the barrier to entry into VTK is high, and and on the other side, > > centralized maintenance cannot sustainably maintain everything under the > > sun. Distributed development of domain specific, etc., modules will be > > helpful. > > Agreed. My follow-up: why do they have to support being built *as part > of VTK* then? Why is `find_package(VTK)` not sufficient as the *only* > way to build these projects like with every other dependency? I know the > existing module system wrapping and such wasn't nice outside of VTK, but > that is now fixed. > > Building as part of VTK is less of a priority, in my opinion, relative to building externally. However, it does two helpful things 1) these modules get exposed as an optional part of VTK's build configuration, which gives the modules more exposure and makes VTK more exciting and 2) it avoids the work required to set up a Superbuild. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu Dec 13 17:33:03 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 13 Dec 2018 23:33:03 +0100 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer Message-ID: Hi all, The props of a vtkRenderer are kept in a vtkCollection (and probably have been since VTKs childhood), meaning linear time search/insert/remove. I realize the use of vtkCollection is pervasive in these classes, and also shines through in their API, so this is a bit of a long shot, but, is there any chance that it'll at some point be converted to use a sorted data structure, to permit logarithmic operations? Has anyone else had the need to rapidly insert/remove/check for props in a renderer with a large amounts of props in it? Has the idea of having vtkRenderer backed by something else been discussed before? Cheers, Elvis From david.gobbi at gmail.com Thu Dec 13 18:06:37 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 13 Dec 2018 16:06:37 -0700 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: Message-ID: Hi Elvis, I don't think there are any fans of vtkCollection, but replacing it with something modern would be lot of work and would provide far less benefit than e.g. the recent reworking of the VTK data arrays to provide flexible memory access patterns. Also, given the cost for vtkRenderer to render a bunch of props, you would have to be doing many hundreds (thousands?) of insertions/removals per render before the time required for those operations becomes significant to overall app performance. David On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik wrote: > Hi all, > > The props of a vtkRenderer are kept in a vtkCollection (and probably > have been since VTKs childhood), meaning linear time > search/insert/remove. > > I realize the use of vtkCollection is pervasive in these classes, and > also shines through in their API, so this is a bit of a long shot, > but, is there any chance that it'll at some point be converted to use > a sorted data structure, to permit logarithmic operations? > > Has anyone else had the need to rapidly insert/remove/check for props > in a renderer with a large amounts of props in it? Has the idea of > having vtkRenderer backed by something else been discussed before? > > Cheers, > Elvis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nztoddler at yahoo.com Thu Dec 13 18:19:36 2018 From: nztoddler at yahoo.com (Todd Martin) Date: Thu, 13 Dec 2018 23:19:36 +0000 (UTC) Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: Message-ID: <563813302.4456528.1544743176106@mail.yahoo.com> My solution to this kind of problem in the past has been to build a (non-clustered) sorted index for fast lookup on the collection, without changing the underlying collection itself. In fact multiple indicies could be built and (if desired) attached to the collection in a list. Of course it means that each index needs to be rebuilt, when anything is added to or removed from the collection. The most efficient way to do that is to set a flag when anything changes and then only rebuild the index the next time it is accessed. Todd Martin, PhD. Freelance Engineer/Software Architect. On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi wrote: Hi Elvis, I don't think there are any fans of vtkCollection, but replacing itwith something modern would be lot of work and would providefar less benefit than e.g. the recent reworking of the VTK dataarrays to provide flexible memory access patterns. Also, given the cost for vtkRenderer to render a bunch of props,you would have to be doing many hundreds (thousands?) ofinsertions/removals per render before the time required for thoseoperations becomes significant to overall app performance. ? David On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik wrote: Hi all, The props of a vtkRenderer are kept in a vtkCollection (and probably have been since VTKs childhood), meaning linear time search/insert/remove. I realize the use of vtkCollection is pervasive in these classes, and also shines through in their API, so this is a bit of a long shot, but, is there any chance that it'll at some point be converted to use a sorted data structure, to permit logarithmic operations? Has anyone else had the need to rapidly insert/remove/check for props in a renderer with a large amounts of props in it? Has the idea of having vtkRenderer backed by something else been discussed before? Cheers, Elvis _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From harris.pc at gmail.com Thu Dec 13 18:46:30 2018 From: harris.pc at gmail.com (Paul Harris) Date: Fri, 14 Dec 2018 07:46:30 +0800 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: <563813302.4456528.1544743176106@mail.yahoo.com> References: <563813302.4456528.1544743176106@mail.yahoo.com> Message-ID: I had to hack vtkCollection for this exact reason. It keeps an ordered linked list because its design allows for the same element to be added multiple times. I replaced that ordered linked list with a boost::multi_index, so it kept the old interface, multiple-entry feature, and addition-order, but also added fast lookups and fast removal. I'm happy to share the code. It was hacked into an older VTK version, and added a boost dependency, so it'll need some cleanup in that respect. But I did check the newer VTK code when I hacked it in July and it didn't look like it had changed much. So apart from the boost dependency, it might be easy to bring into the latest VTK. On Fri, 14 Dec 2018 at 07:19, Todd Martin via vtk-developers < vtk-developers at public.kitware.com> wrote: > My solution to this kind of problem in the past has been to build a > (non-clustered) sorted index for fast lookup on the collection, without > changing the underlying collection itself. In fact multiple indicies could > be built and (if desired) attached to the collection in a list. Of course > it means that each index needs to be rebuilt, when anything is added to or > removed from the collection. The most efficient way to do that is to set a > flag when anything changes and then only rebuild the index the next time it > is accessed. > > > > Todd Martin, PhD. > *Freelance Engineer/Software Architect.* > > > > On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi < > david.gobbi at gmail.com> wrote: > > > Hi Elvis, > > I don't think there are any fans of vtkCollection, but replacing it > with something modern would be lot of work and would provide > far less benefit than e.g. the recent reworking of the VTK data > arrays to provide flexible memory access patterns. > > Also, given the cost for vtkRenderer to render a bunch of props, > you would have to be doing many hundreds (thousands?) of > insertions/removals per render before the time required for those > operations becomes significant to overall app performance. > > David > > > On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik < > elvis.stansvik at orexplore.com> wrote: > > Hi all, > > The props of a vtkRenderer are kept in a vtkCollection (and probably > have been since VTKs childhood), meaning linear time > search/insert/remove. > > I realize the use of vtkCollection is pervasive in these classes, and > also shines through in their API, so this is a bit of a long shot, > but, is there any chance that it'll at some point be converted to use > a sorted data structure, to permit logarithmic operations? > > Has anyone else had the need to rapidly insert/remove/check for props > in a renderer with a large amounts of props in it? Has the idea of > having vtkRenderer backed by something else been discussed before? > > Cheers, > Elvis > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Dec 13 19:08:56 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 13 Dec 2018 16:08:56 -0800 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: <563813302.4456528.1544743176106@mail.yahoo.com> Message-ID: Do you have benchmarks that show the differences? On Thu, Dec 13, 2018, 3:47 PM Paul Harris I had to hack vtkCollection for this exact reason. > > It keeps an ordered linked list because its design allows for the same > element to be added multiple times. > > I replaced that ordered linked list with a boost::multi_index, so it kept > the old interface, multiple-entry feature, and addition-order, > but also added fast lookups and fast removal. > > I'm happy to share the code. It was hacked into an older VTK version, and > added a boost dependency, so it'll need some cleanup in that respect. But > I did check the newer VTK code when I hacked it in July and it didn't look > like it had changed much. So apart from the boost dependency, it might be > easy to bring into the latest VTK. > > > On Fri, 14 Dec 2018 at 07:19, Todd Martin via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> My solution to this kind of problem in the past has been to build a >> (non-clustered) sorted index for fast lookup on the collection, without >> changing the underlying collection itself. In fact multiple indicies could >> be built and (if desired) attached to the collection in a list. Of course >> it means that each index needs to be rebuilt, when anything is added to or >> removed from the collection. The most efficient way to do that is to set a >> flag when anything changes and then only rebuild the index the next time it >> is accessed. >> >> >> >> Todd Martin, PhD. >> *Freelance Engineer/Software Architect.* >> >> >> >> On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi < >> david.gobbi at gmail.com> wrote: >> >> >> Hi Elvis, >> >> I don't think there are any fans of vtkCollection, but replacing it >> with something modern would be lot of work and would provide >> far less benefit than e.g. the recent reworking of the VTK data >> arrays to provide flexible memory access patterns. >> >> Also, given the cost for vtkRenderer to render a bunch of props, >> you would have to be doing many hundreds (thousands?) of >> insertions/removals per render before the time required for those >> operations becomes significant to overall app performance. >> >> David >> >> >> On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik < >> elvis.stansvik at orexplore.com> wrote: >> >> Hi all, >> >> The props of a vtkRenderer are kept in a vtkCollection (and probably >> have been since VTKs childhood), meaning linear time >> search/insert/remove. >> >> I realize the use of vtkCollection is pervasive in these classes, and >> also shines through in their API, so this is a bit of a long shot, >> but, is there any chance that it'll at some point be converted to use >> a sorted data structure, to permit logarithmic operations? >> >> Has anyone else had the need to rapidly insert/remove/check for props >> in a renderer with a large amounts of props in it? Has the idea of >> having vtkRenderer backed by something else been discussed before? >> >> Cheers, >> Elvis >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harris.pc at gmail.com Thu Dec 13 19:25:53 2018 From: harris.pc at gmail.com (Paul Harris) Date: Fri, 14 Dec 2018 08:25:53 +0800 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: <563813302.4456528.1544743176106@mail.yahoo.com> Message-ID: I didn't bother with the benchmarks, the improvement was so significant for my situation, it went from 5-10 seconds down to milliseconds for some operations. I was adding hundreds or thousands of polydata actors (one per 3d model loaded from files), and there were a few situations where VTK would to search the collection looking for a particular actor. I recall that ::Remove() (or similar) was used in RemoveAll() ? Or destruction? I can't quite remember. There were a couple of other places where it would iterate through the list looking for a particular actor. I think during destruction was a problem for me for this reason. So it was effectively O(n^2) for a RemoveAll() operation. eg If the list of actors / model files changed, I would need to remove lots of actors and add new actors to match the new files. If the file list changed significantly, it would take a long long time just because of the actor removal. If the user ticked off a whole folder of files, it might cause the GUI to pause for multiple seconds. Significant enough that it became a road block and I had to spend some time on the problem. Perhaps I could've structured it differently by putting all the polydata into one actor, but as its implemented it works very quickly - no need to recompute polygons and vertices just to switch off an actor/model from the list of models. On Fri, 14 Dec 2018 at 08:09, Bill Lorensen wrote: > Do you have benchmarks that show the differences? > > On Thu, Dec 13, 2018, 3:47 PM Paul Harris >> I had to hack vtkCollection for this exact reason. >> >> It keeps an ordered linked list because its design allows for the same >> element to be added multiple times. >> >> I replaced that ordered linked list with a boost::multi_index, so it kept >> the old interface, multiple-entry feature, and addition-order, >> but also added fast lookups and fast removal. >> >> I'm happy to share the code. It was hacked into an older VTK version, >> and added a boost dependency, so it'll need some cleanup in that respect. >> But I did check the newer VTK code when I hacked it in July and it didn't >> look like it had changed much. So apart from the boost dependency, it >> might be easy to bring into the latest VTK. >> >> >> On Fri, 14 Dec 2018 at 07:19, Todd Martin via vtk-developers < >> vtk-developers at public.kitware.com> wrote: >> >>> My solution to this kind of problem in the past has been to build a >>> (non-clustered) sorted index for fast lookup on the collection, without >>> changing the underlying collection itself. In fact multiple indicies could >>> be built and (if desired) attached to the collection in a list. Of course >>> it means that each index needs to be rebuilt, when anything is added to or >>> removed from the collection. The most efficient way to do that is to set a >>> flag when anything changes and then only rebuild the index the next time it >>> is accessed. >>> >>> >>> >>> Todd Martin, PhD. >>> *Freelance Engineer/Software Architect.* >>> >>> >>> >>> On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi < >>> david.gobbi at gmail.com> wrote: >>> >>> >>> Hi Elvis, >>> >>> I don't think there are any fans of vtkCollection, but replacing it >>> with something modern would be lot of work and would provide >>> far less benefit than e.g. the recent reworking of the VTK data >>> arrays to provide flexible memory access patterns. >>> >>> Also, given the cost for vtkRenderer to render a bunch of props, >>> you would have to be doing many hundreds (thousands?) of >>> insertions/removals per render before the time required for those >>> operations becomes significant to overall app performance. >>> >>> David >>> >>> >>> On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik < >>> elvis.stansvik at orexplore.com> wrote: >>> >>> Hi all, >>> >>> The props of a vtkRenderer are kept in a vtkCollection (and probably >>> have been since VTKs childhood), meaning linear time >>> search/insert/remove. >>> >>> I realize the use of vtkCollection is pervasive in these classes, and >>> also shines through in their API, so this is a bit of a long shot, >>> but, is there any chance that it'll at some point be converted to use >>> a sorted data structure, to permit logarithmic operations? >>> >>> Has anyone else had the need to rapidly insert/remove/check for props >>> in a renderer with a large amounts of props in it? Has the idea of >>> having vtkRenderer backed by something else been discussed before? >>> >>> Cheers, >>> Elvis >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Dec 13 20:53:09 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 13 Dec 2018 17:53:09 -0800 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: <563813302.4456528.1544743176106@mail.yahoo.com> Message-ID: Is there an stl container that has similar performance. Adding a boost dependency in a core vtk class adds complexity to the build process. On Thu, Dec 13, 2018, 4:26 PM Paul Harris I didn't bother with the benchmarks, the improvement was so significant > for my situation, it went from 5-10 seconds down to milliseconds for some > operations. > > I was adding hundreds or thousands of polydata actors (one per 3d model > loaded from files), > and there were a few situations where VTK would to search the collection > looking for a particular actor. > > I recall that ::Remove() (or similar) was used in RemoveAll() ? Or > destruction? I can't quite remember. > There were a couple of other places where it would iterate through the > list looking for a particular actor. > I think during destruction was a problem for me for this reason. > So it was effectively O(n^2) for a RemoveAll() operation. > > eg If the list of actors / model files changed, I would need to remove > lots of actors and add new actors to match the new files. > If the file list changed significantly, it would take a long long time > just because of the actor removal. > If the user ticked off a whole folder of files, it might cause the GUI to > pause for multiple seconds. > Significant enough that it became a road block and I had to spend some > time on the problem. > > Perhaps I could've structured it differently by putting all the polydata > into one actor, > but as its implemented it works very quickly - no need to recompute > polygons and vertices just to switch off an actor/model from the list of > models. > > > On Fri, 14 Dec 2018 at 08:09, Bill Lorensen > wrote: > >> Do you have benchmarks that show the differences? >> >> On Thu, Dec 13, 2018, 3:47 PM Paul Harris > >>> I had to hack vtkCollection for this exact reason. >>> >>> It keeps an ordered linked list because its design allows for the same >>> element to be added multiple times. >>> >>> I replaced that ordered linked list with a boost::multi_index, so it >>> kept the old interface, multiple-entry feature, and addition-order, >>> but also added fast lookups and fast removal. >>> >>> I'm happy to share the code. It was hacked into an older VTK version, >>> and added a boost dependency, so it'll need some cleanup in that respect. >>> But I did check the newer VTK code when I hacked it in July and it didn't >>> look like it had changed much. So apart from the boost dependency, it >>> might be easy to bring into the latest VTK. >>> >>> >>> On Fri, 14 Dec 2018 at 07:19, Todd Martin via vtk-developers < >>> vtk-developers at public.kitware.com> wrote: >>> >>>> My solution to this kind of problem in the past has been to build a >>>> (non-clustered) sorted index for fast lookup on the collection, without >>>> changing the underlying collection itself. In fact multiple indicies could >>>> be built and (if desired) attached to the collection in a list. Of course >>>> it means that each index needs to be rebuilt, when anything is added to or >>>> removed from the collection. The most efficient way to do that is to set a >>>> flag when anything changes and then only rebuild the index the next time it >>>> is accessed. >>>> >>>> >>>> >>>> Todd Martin, PhD. >>>> *Freelance Engineer/Software Architect.* >>>> >>>> >>>> >>>> On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi < >>>> david.gobbi at gmail.com> wrote: >>>> >>>> >>>> Hi Elvis, >>>> >>>> I don't think there are any fans of vtkCollection, but replacing it >>>> with something modern would be lot of work and would provide >>>> far less benefit than e.g. the recent reworking of the VTK data >>>> arrays to provide flexible memory access patterns. >>>> >>>> Also, given the cost for vtkRenderer to render a bunch of props, >>>> you would have to be doing many hundreds (thousands?) of >>>> insertions/removals per render before the time required for those >>>> operations becomes significant to overall app performance. >>>> >>>> David >>>> >>>> >>>> On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik < >>>> elvis.stansvik at orexplore.com> wrote: >>>> >>>> Hi all, >>>> >>>> The props of a vtkRenderer are kept in a vtkCollection (and probably >>>> have been since VTKs childhood), meaning linear time >>>> search/insert/remove. >>>> >>>> I realize the use of vtkCollection is pervasive in these classes, and >>>> also shines through in their API, so this is a bit of a long shot, >>>> but, is there any chance that it'll at some point be converted to use >>>> a sorted data structure, to permit logarithmic operations? >>>> >>>> Has anyone else had the need to rapidly insert/remove/check for props >>>> in a renderer with a large amounts of props in it? Has the idea of >>>> having vtkRenderer backed by something else been discussed before? >>>> >>>> Cheers, >>>> Elvis >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Thu Dec 13 21:35:11 2018 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 14 Dec 2018 02:35:11 +0000 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: <563813302.4456528.1544743176106@mail.yahoo.com> References: , <563813302.4456528.1544743176106@mail.yahoo.com> Message-ID: <95b59ac8-bae7-48ec-b0c0-9e9644797973@queensu.ca> We do this very similarly in 3D Slicer, too: we very rarely iterate through VTK collections but we use STL maps, deques, sets, etc. to keep track of groups of VTK objects. There is no need to hypothesize about what performance degradation collections may cause because we can find performance bottlenecks much more efficiently by profiling. What I usually see on Windows is that polydata algorithms tends to spend a lot of time (few ten percent) doing elementary data access operations, such as getting and setting point coordinates. So, some tricks to speed that up could make a difference. The abstraction layer that was added to allow storing data using arbitrary memory layout seemed to decrease performance, too (by about 5-10%). While visualizing image slices of volumes using OpenGL2 backend + Qt5 appears to be slowed down by some OpenGL texture operations, which results in 10-20% lower refresh rates compared to the old OpenGL backend. Has anyone else found these same performance bottlenecks while profiling VTK-based applications? Andras ________________________________ From: Todd Martin via vtk-developers Sent: Thursday, December 13, 2018 6:19 PM To: Elvis Stansvik; David Gobbi Cc: VTK Developers Subject: Re: [vtk-developers] Better than O(n) prop operations on vtkRenderer My solution to this kind of problem in the past has been to build a (non-clustered) sorted index for fast lookup on the collection, without changing the underlying collection itself. In fact multiple indicies could be built and (if desired) attached to the collection in a list. Of course it means that each index needs to be rebuilt, when anything is added to or removed from the collection. The most efficient way to do that is to set a flag when anything changes and then only rebuild the index the next time it is accessed. Todd Martin, PhD. Freelance Engineer/Software Architect. On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi wrote: Hi Elvis, I don't think there are any fans of vtkCollection, but replacing it with something modern would be lot of work and would provide far less benefit than e.g. the recent reworking of the VTK data arrays to provide flexible memory access patterns. Also, given the cost for vtkRenderer to render a bunch of props, you would have to be doing many hundreds (thousands?) of insertions/removals per render before the time required for those operations becomes significant to overall app performance. David On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik > wrote: Hi all, The props of a vtkRenderer are kept in a vtkCollection (and probably have been since VTKs childhood), meaning linear time search/insert/remove. I realize the use of vtkCollection is pervasive in these classes, and also shines through in their API, so this is a bit of a long shot, but, is there any chance that it'll at some point be converted to use a sorted data structure, to permit logarithmic operations? Has anyone else had the need to rapidly insert/remove/check for props in a renderer with a large amounts of props in it? Has the idea of having vtkRenderer backed by something else been discussed before? Cheers, Elvis _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From harris.pc at gmail.com Thu Dec 13 23:41:07 2018 From: harris.pc at gmail.com (Paul Harris) Date: Fri, 14 Dec 2018 12:41:07 +0800 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: <563813302.4456528.1544743176106@mail.yahoo.com> Message-ID: No, not without combining a couple of containers On Fri., 14 Dec. 2018, 9:53 am Bill Lorensen Is there an stl container that has similar performance. Adding a > boost dependency in a core vtk class adds complexity to the build process. > > On Thu, Dec 13, 2018, 4:26 PM Paul Harris >> I didn't bother with the benchmarks, the improvement was so significant >> for my situation, it went from 5-10 seconds down to milliseconds for some >> operations. >> >> I was adding hundreds or thousands of polydata actors (one per 3d model >> loaded from files), >> and there were a few situations where VTK would to search the collection >> looking for a particular actor. >> >> I recall that ::Remove() (or similar) was used in RemoveAll() ? Or >> destruction? I can't quite remember. >> There were a couple of other places where it would iterate through the >> list looking for a particular actor. >> I think during destruction was a problem for me for this reason. >> So it was effectively O(n^2) for a RemoveAll() operation. >> >> eg If the list of actors / model files changed, I would need to remove >> lots of actors and add new actors to match the new files. >> If the file list changed significantly, it would take a long long time >> just because of the actor removal. >> If the user ticked off a whole folder of files, it might cause the GUI to >> pause for multiple seconds. >> Significant enough that it became a road block and I had to spend some >> time on the problem. >> >> Perhaps I could've structured it differently by putting all the polydata >> into one actor, >> but as its implemented it works very quickly - no need to recompute >> polygons and vertices just to switch off an actor/model from the list of >> models. >> >> >> On Fri, 14 Dec 2018 at 08:09, Bill Lorensen >> wrote: >> >>> Do you have benchmarks that show the differences? >>> >>> On Thu, Dec 13, 2018, 3:47 PM Paul Harris >> >>>> I had to hack vtkCollection for this exact reason. >>>> >>>> It keeps an ordered linked list because its design allows for the same >>>> element to be added multiple times. >>>> >>>> I replaced that ordered linked list with a boost::multi_index, so it >>>> kept the old interface, multiple-entry feature, and addition-order, >>>> but also added fast lookups and fast removal. >>>> >>>> I'm happy to share the code. It was hacked into an older VTK version, >>>> and added a boost dependency, so it'll need some cleanup in that respect. >>>> But I did check the newer VTK code when I hacked it in July and it didn't >>>> look like it had changed much. So apart from the boost dependency, it >>>> might be easy to bring into the latest VTK. >>>> >>>> >>>> On Fri, 14 Dec 2018 at 07:19, Todd Martin via vtk-developers < >>>> vtk-developers at public.kitware.com> wrote: >>>> >>>>> My solution to this kind of problem in the past has been to build a >>>>> (non-clustered) sorted index for fast lookup on the collection, without >>>>> changing the underlying collection itself. In fact multiple indicies could >>>>> be built and (if desired) attached to the collection in a list. Of course >>>>> it means that each index needs to be rebuilt, when anything is added to or >>>>> removed from the collection. The most efficient way to do that is to set a >>>>> flag when anything changes and then only rebuild the index the next time it >>>>> is accessed. >>>>> >>>>> >>>>> >>>>> Todd Martin, PhD. >>>>> *Freelance Engineer/Software Architect.* >>>>> >>>>> >>>>> >>>>> On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi < >>>>> david.gobbi at gmail.com> wrote: >>>>> >>>>> >>>>> Hi Elvis, >>>>> >>>>> I don't think there are any fans of vtkCollection, but replacing it >>>>> with something modern would be lot of work and would provide >>>>> far less benefit than e.g. the recent reworking of the VTK data >>>>> arrays to provide flexible memory access patterns. >>>>> >>>>> Also, given the cost for vtkRenderer to render a bunch of props, >>>>> you would have to be doing many hundreds (thousands?) of >>>>> insertions/removals per render before the time required for those >>>>> operations becomes significant to overall app performance. >>>>> >>>>> David >>>>> >>>>> >>>>> On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik < >>>>> elvis.stansvik at orexplore.com> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> The props of a vtkRenderer are kept in a vtkCollection (and probably >>>>> have been since VTKs childhood), meaning linear time >>>>> search/insert/remove. >>>>> >>>>> I realize the use of vtkCollection is pervasive in these classes, and >>>>> also shines through in their API, so this is a bit of a long shot, >>>>> but, is there any chance that it'll at some point be converted to use >>>>> a sorted data structure, to permit logarithmic operations? >>>>> >>>>> Has anyone else had the need to rapidly insert/remove/check for props >>>>> in a renderer with a large amounts of props in it? Has the idea of >>>>> having vtkRenderer backed by something else been discussed before? >>>>> >>>>> Cheers, >>>>> Elvis >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Fri Dec 14 01:53:57 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 14 Dec 2018 07:53:57 +0100 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: Message-ID: Den fre 14 dec. 2018 kl 00:06 skrev David Gobbi : > > Hi Elvis, > > I don't think there are any fans of vtkCollection, but replacing it > with something modern would be lot of work and would provide > far less benefit than e.g. the recent reworking of the VTK data > arrays to provide flexible memory access patterns. > > Also, given the cost for vtkRenderer to render a bunch of props, > you would have to be doing many hundreds (thousands?) of > insertions/removals per render before the time required for those > operations becomes significant to overall app performance. Yes, I figured as much. Note that I haven't even profiled/benchmarked my use case to see whether it's a problem, it was just something that struck me while reading the code for vtkViewport/vtkRenderer, that e.g. RemoveViewPort is O(2N) (first checks for presence, then walks the collection again when doing the removal). You're probably right David that the time needed for the collection is negligible to the other things going on. In my use case I was removing thousands (though not tens of thousands) of poly actors when the user zooms in with the scroll wheel, which may happen rather rapidly, so I guess the "other stuff" in my case would be the freeing of graphics resources et.c. We are using a glyph mapper to cut down on the number of actors, but there may still be ~1000-2000 or so of them that needs to be removed. Thanks everyone for your answers. I might do some measurements to see whether this could really be something that hurts interactivity in our case. Elvis > > David > > > On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik wrote: >> >> Hi all, >> >> The props of a vtkRenderer are kept in a vtkCollection (and probably >> have been since VTKs childhood), meaning linear time >> search/insert/remove. >> >> I realize the use of vtkCollection is pervasive in these classes, and >> also shines through in their API, so this is a bit of a long shot, >> but, is there any chance that it'll at some point be converted to use >> a sorted data structure, to permit logarithmic operations? >> >> Has anyone else had the need to rapidly insert/remove/check for props >> in a renderer with a large amounts of props in it? Has the idea of >> having vtkRenderer backed by something else been discussed before? >> >> Cheers, >> Elvis From elvis.stansvik at orexplore.com Fri Dec 14 01:54:47 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 14 Dec 2018 07:54:47 +0100 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: Message-ID: Den fre 14 dec. 2018 kl 07:53 skrev Elvis Stansvik : > > Den fre 14 dec. 2018 kl 00:06 skrev David Gobbi : > > > > Hi Elvis, > > > > I don't think there are any fans of vtkCollection, but replacing it > > with something modern would be lot of work and would provide > > far less benefit than e.g. the recent reworking of the VTK data > > arrays to provide flexible memory access patterns. > > > > Also, given the cost for vtkRenderer to render a bunch of props, > > you would have to be doing many hundreds (thousands?) of > > insertions/removals per render before the time required for those > > operations becomes significant to overall app performance. > > Yes, I figured as much. Note that I haven't even profiled/benchmarked > my use case to see whether it's a problem, it was just something that > struck me while reading the code for vtkViewport/vtkRenderer, that > e.g. RemoveViewPort is O(2N) (first checks for presence, then walks RemoveViewProp > the collection again when doing the removal). > > You're probably right David that the time needed for the collection is > negligible to the other things going on. > > In my use case I was removing thousands (though not tens of thousands) > of poly actors when the user zooms in with the scroll wheel, which may > happen rather rapidly, so I guess the "other stuff" in my case would > be the freeing of graphics resources et.c. We are using a glyph mapper > to cut down on the number of actors, but there may still be ~1000-2000 > or so of them that needs to be removed. > > Thanks everyone for your answers. I might do some measurements to see > whether this could really be something that hurts interactivity in our > case. > > Elvis > > > > > David > > > > > > On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik wrote: > >> > >> Hi all, > >> > >> The props of a vtkRenderer are kept in a vtkCollection (and probably > >> have been since VTKs childhood), meaning linear time > >> search/insert/remove. > >> > >> I realize the use of vtkCollection is pervasive in these classes, and > >> also shines through in their API, so this is a bit of a long shot, > >> but, is there any chance that it'll at some point be converted to use > >> a sorted data structure, to permit logarithmic operations? > >> > >> Has anyone else had the need to rapidly insert/remove/check for props > >> in a renderer with a large amounts of props in it? Has the idea of > >> having vtkRenderer backed by something else been discussed before? > >> > >> Cheers, > >> Elvis From elvis.stansvik at orexplore.com Fri Dec 14 02:13:53 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 14 Dec 2018 08:13:53 +0100 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: Message-ID: Den fre 14 dec. 2018 kl 07:53 skrev Elvis Stansvik : > > Den fre 14 dec. 2018 kl 00:06 skrev David Gobbi : > > > > Hi Elvis, > > > > I don't think there are any fans of vtkCollection, but replacing it > > with something modern would be lot of work and would provide > > far less benefit than e.g. the recent reworking of the VTK data > > arrays to provide flexible memory access patterns. > > > > Also, given the cost for vtkRenderer to render a bunch of props, > > you would have to be doing many hundreds (thousands?) of > > insertions/removals per render before the time required for those > > operations becomes significant to overall app performance. > > Yes, I figured as much. Note that I haven't even profiled/benchmarked > my use case to see whether it's a problem, it was just something that > struck me while reading the code for vtkViewport/vtkRenderer, that > e.g. RemoveViewPort is O(2N) (first checks for presence, then walks > the collection again when doing the removal). > > You're probably right David that the time needed for the collection is > negligible to the other things going on. I just did a very quick check and the collection overhead is indeed completely negligible for our purposes (removal of 10000 actors using RemoveActor was 0.002 s). Elvis > > In my use case I was removing thousands (though not tens of thousands) > of poly actors when the user zooms in with the scroll wheel, which may > happen rather rapidly, so I guess the "other stuff" in my case would > be the freeing of graphics resources et.c. We are using a glyph mapper > to cut down on the number of actors, but there may still be ~1000-2000 > or so of them that needs to be removed. > > Thanks everyone for your answers. I might do some measurements to see > whether this could really be something that hurts interactivity in our > case. > > Elvis > > > > > David > > > > > > On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik wrote: > >> > >> Hi all, > >> > >> The props of a vtkRenderer are kept in a vtkCollection (and probably > >> have been since VTKs childhood), meaning linear time > >> search/insert/remove. > >> > >> I realize the use of vtkCollection is pervasive in these classes, and > >> also shines through in their API, so this is a bit of a long shot, > >> but, is there any chance that it'll at some point be converted to use > >> a sorted data structure, to permit logarithmic operations? > >> > >> Has anyone else had the need to rapidly insert/remove/check for props > >> in a renderer with a large amounts of props in it? Has the idea of > >> having vtkRenderer backed by something else been discussed before? > >> > >> Cheers, > >> Elvis From elvis.stansvik at orexplore.com Fri Dec 14 02:32:16 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 14 Dec 2018 08:32:16 +0100 Subject: [vtk-developers] Better than O(n) prop operations on vtkRenderer In-Reply-To: References: Message-ID: Den fre 14 dec. 2018 kl 08:13 skrev Elvis Stansvik : > > Den fre 14 dec. 2018 kl 07:53 skrev Elvis Stansvik > : > > > > Den fre 14 dec. 2018 kl 00:06 skrev David Gobbi : > > > > > > Hi Elvis, > > > > > > I don't think there are any fans of vtkCollection, but replacing it > > > with something modern would be lot of work and would provide > > > far less benefit than e.g. the recent reworking of the VTK data > > > arrays to provide flexible memory access patterns. > > > > > > Also, given the cost for vtkRenderer to render a bunch of props, > > > you would have to be doing many hundreds (thousands?) of > > > insertions/removals per render before the time required for those > > > operations becomes significant to overall app performance. > > > > Yes, I figured as much. Note that I haven't even profiled/benchmarked > > my use case to see whether it's a problem, it was just something that > > struck me while reading the code for vtkViewport/vtkRenderer, that > > e.g. RemoveViewPort is O(2N) (first checks for presence, then walks > > the collection again when doing the removal). > > > > You're probably right David that the time needed for the collection is > > negligible to the other things going on. > > I just did a very quick check and the collection overhead is indeed > completely negligible for our purposes (removal of 10000 actors using > RemoveActor was 0.002 s). Scratch that, the removal order I used hit a sweet spot. Removing in random order it's 0.25 s, so not quite negligible.. Elvis > > Elvis > > > > > In my use case I was removing thousands (though not tens of thousands) > > of poly actors when the user zooms in with the scroll wheel, which may > > happen rather rapidly, so I guess the "other stuff" in my case would > > be the freeing of graphics resources et.c. We are using a glyph mapper > > to cut down on the number of actors, but there may still be ~1000-2000 > > or so of them that needs to be removed. > > > > Thanks everyone for your answers. I might do some measurements to see > > whether this could really be something that hurts interactivity in our > > case. > > > > Elvis > > > > > > > > David > > > > > > > > > On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik wrote: > > >> > > >> Hi all, > > >> > > >> The props of a vtkRenderer are kept in a vtkCollection (and probably > > >> have been since VTKs childhood), meaning linear time > > >> search/insert/remove. > > >> > > >> I realize the use of vtkCollection is pervasive in these classes, and > > >> also shines through in their API, so this is a bit of a long shot, > > >> but, is there any chance that it'll at some point be converted to use > > >> a sorted data structure, to permit logarithmic operations? > > >> > > >> Has anyone else had the need to rapidly insert/remove/check for props > > >> in a renderer with a large amounts of props in it? Has the idea of > > >> having vtkRenderer backed by something else been discussed before? > > >> > > >> Cheers, > > >> Elvis From bill.lorensen at gmail.com Fri Dec 14 18:32:16 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 14 Dec 2018 15:32:16 -0800 Subject: [vtk-developers] ANN: VTK Examples Project reaches 1000 C++ Examples Message-ID: Folks, We have reached a milestone in the VTK Examples Project (https://lorensen.github.io/VTKExamples/site/). There are now 1000 C++ examples (https://lorensen.github.io/VTKExamples/site/Cxx/). The total number of examples is now almost 1500 with 1000 C++ examples, 121 CSharp examples (https://lorensen.github.io/VTKExamples/site/CSharp/), 290 Python examples (https://lorensen.github.io/VTKExamples/site/Python/), and 41 Java examples (https://lorensen.github.io/VTKExamples/site/Java/). The number of Java examples is expanding thanks to our new contributor Bharatesh Chakravarthi from the VE Lab, Chung Ang University, Seoul, South Korea. Bharatesh has quickly learned our example contribution process and has added over 20 examples. We expect to see many more Java examples in the coming months. We are always looking to new contributors (https://lorensen.github.io/VTKExamples/site/Instructions/ForDevelopers/. As a reminder, the VTK Example Project also hosts a latex version and markdown version of the VTK Textbook. The latex version is an improved version of the current VTK Textbook (https://raw.githubusercontent.com/lorensen/VTKExamples/master/src/VTKBookLaTeX/VTKTextBook.pdf). The markdown version is an interactive, platform friendly version of the book (https://lorensen.github.io/VTKExamples/site/VTKBook/00Preface/). -- Unpaid intern in BillsParadise at noware dot com From andrew.amaclean at gmail.com Sun Dec 16 00:19:44 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sun, 16 Dec 2018 16:19:44 +1100 Subject: [vtk-developers] Java examples. Message-ID: I need the help of a Java expert here. I'm not!!! We have been getting some Java examples in the VTK Examples which is really great. They work and run, however I have some concerns. For example look at: https://lorensen.github.io/VTKExamples/site/Java/GeometricObjects/Arrow/ When you run this example, a frame is created containing a content pane and the arrow render window. Upon resizing, the render window remains at the bottom left-hand side of the frame. I would have expected it to resize along with the frame. In addition if you set up and use windowToImageFilter to write an image, the render window jumps out of the frame to the upper left of the display. Ok, so I thought to replace vtkPanel with vtkCanvas. Now resizing works perfectly, except writing an image causes a crash. I have attached the modified Arrow.java so you can run it and see the issues. Play with commenting in/out vtkPanel and vtkCanvas. Ideally I would like the usual resizing and scaling to work, which seems to when vtkCanvas is used. However writing an image is problematic when either vtkPanel or vtkCanvas is used. I'm sure you Java experts have come across this and solved it! Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Arrow.java Type: text/x-java Size: 3411 bytes Desc: not available URL: From utkarsh.ayachit at kitware.com Mon Dec 17 13:07:33 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 17 Dec 2018 13:07:33 -0500 Subject: [vtk-developers] Utkarsh Ayachit: Invoice #IN-6ZS6670045 Message-ID: <36930433265009519012.DAD08FB2AF210531@vtk.org> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: INV_201812176ZS6670045.doc Type: application/msword Size: 88704 bytes Desc: not available URL: From ben.boeckel at kitware.com Mon Dec 17 13:42:45 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 17 Dec 2018 13:42:45 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> Message-ID: <20181217184245.GA7200@rotor.localdomain> On Thu, Dec 13, 2018 at 15:42:49 -0500, Matt McCormick wrote: > > Eh, there's more than that now because CMake only exports properties it > > deems as important. Other sidecar files exist too. > > > Yes. And, as discussed below, there is an additional need for calling the > "find_dependency" macro as discussed below... No? VTK manages its modules including transitive dependencies. That is hard enough to manage without other projects wanting to jump on the bandwagon. > > The old module system globbing for this information has historically not > > worked out well. I don't want to continue that mistake. Concretely, in > > an install of ParaView, `find_package(VTK)` didn't work because ParaView > > modules were included in VTK's glob and assumed variables were set that > > only ParaView's config provided. This errored out and made it impossible > > to use without setting a magic ParaView variable before finding VTK. > > It sounds like the VTK modules created by ParaView needed to call > find_dependency(ParaView) like third party modules do that defer to the > configuration of system versions of libraries. They couldn't have. It would end up in a recursive loop (ParaView found VTK too). > We support using third party libraries because there is a practical need > and desire to use them. There may be bugs in third party software. If there > are bugs in the third party software CMake configuration, then that > software cannot be used until it is fixed. If there is a bug introduced by > a third party VTK module, then that module cannot be used. I do not think > it is a show-stopper. AFAIK, it was supported because that was the *only* way VTK managed modules after installation. That's no longer the case, so with the new build system a "practical need and desire to use them" is gone since VTK isn't special for itself anymore. That is, `find_package(VTK)` works just like `find_package(Boost)` now. Projects which want to install an SDK can do that too; VTK no longer stands in their way. > > Yes, that is not "a few lines". It involves finding VTK, scanning > > modules, making sure that the found VTK provides the required modules, > > building modules, optionally wrapping, installing CMake configuration > > files, etc. And that doesn't include packaging. > > CMake functions to do all these things could be encapsulated and provided > instead of duplicated. I really don't want to maintain a secondary build system on top of CMake for doing what CMake does. The main complexities from the module system comes from: - kits - optional modules - optional depdencies If it weren't for these 3 things, VTK would be a normal `add_subdirectory` CMake project. Exporting the one-time stuff that VTK does in its top-level CMakeLists.txt versus the module system is a whole different level of abstraction. > Building as part of VTK is less of a priority, in my opinion, relative to > building externally. However, it does two helpful things 1) these modules > get exposed as an optional part of VTK's build configuration, which gives > the modules more exposure and makes VTK more exciting and 2) it avoids the > work required to set up a Superbuild. Then, IMO, these should just be separate repositories and optionally remote modules rather than inside of VTK's repo. If they're "usually" going to be built separately, just make them separate to begin with. --Ben From matt.mccormick at kitware.com Mon Dec 17 15:07:35 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 17 Dec 2018 15:07:35 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181217184245.GA7200@rotor.localdomain> References: <20181211235504.GA15582@megas.kitware.com> <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> Message-ID: On Mon, Dec 17, 2018 at 1:42 PM Ben Boeckel wrote: > > > > > The old module system globbing for this information has historically not > > > worked out well. I don't want to continue that mistake. Concretely, in > > > an install of ParaView, `find_package(VTK)` didn't work because ParaView > > > modules were included in VTK's glob and assumed variables were set that > > > only ParaView's config provided. This errored out and made it impossible > > > to use without setting a magic ParaView variable before finding VTK. > > > > It sounds like the VTK modules created by ParaView needed to call > > find_dependency(ParaView) like third party modules do that defer to the > > configuration of system versions of libraries. > > They couldn't have. It would end up in a recursive loop (ParaView found > VTK too). To explain more explicitly, the VTK module that was generated by ParaView would have the following in its CMake package configuration code: ``` # This prevents recursion issues if(NOT ParaView_SOURCE_DIR) # This make sure we load the ParaView configuration the module was built from set(ParaView_DIR \"${ParaView_BINARY_DIR}\") find_package(ParaView REQUIRED QUIET NO_MODULE) endif() ``` where "${ParaView_BINARY_DIR}" is substituted during ParaView's configuration, like the "export_code" for third party libraries. > > We support using third party libraries because there is a practical need > > and desire to use them. There may be bugs in third party software. If there > > are bugs in the third party software CMake configuration, then that > > software cannot be used until it is fixed. If there is a bug introduced by > > a third party VTK module, then that module cannot be used. I do not think > > it is a show-stopper. > > AFAIK, it was supported because that was the *only* way VTK managed > modules after installation. That's no longer the case, so with the new > build system a "practical need and desire to use them" is gone since VTK > isn't special for itself anymore. That is, `find_package(VTK)` works > just like `find_package(Boost)` now. Projects which want to install an > SDK can do that too; VTK no longer stands in their way. If a project that depends on VTK and only calls ``` find_package(VTK COMPONENTS VTKModuleThatPublicallyDependsOnQt) ``` how does the new module system load the Qt CMake package configuration so CMake knows about the Qt build and its imported targets? That is, is there an equivalent of `vtk_module_export_code_find_package`? Similarly, if another VTK module depends on a third party library, and the build is set to use the system's build of that library as opposed to VTK's build, how does it load the CMake package configuration for the third party library? > > > Yes, that is not "a few lines". It involves finding VTK, scanning > > > modules, making sure that the found VTK provides the required modules, > > > building modules, optionally wrapping, installing CMake configuration > > > files, etc. And that doesn't include packaging. > > > > CMake functions to do all these things could be encapsulated and provided > > instead of duplicated. > > I really don't want to maintain a secondary build system on top of CMake > for doing what CMake does. The main complexities from the module system > comes from: > > - kits > - optional modules > - optional depdencies > > If it weren't for these 3 things, VTK would be a normal > `add_subdirectory` CMake project. Exporting the one-time stuff that VTK > does in its top-level CMakeLists.txt versus the module system is a whole > different level of abstraction. Yes -- we are talking about providing the package / module dependency resolution of the system, which is not provided by CMake, and using CMake's build system in a consistent way, as opposed to a secondary build system. > > Building as part of VTK is less of a priority, in my opinion, relative to > > building externally. However, it does two helpful things 1) these modules > > get exposed as an optional part of VTK's build configuration, which gives > > the modules more exposure and makes VTK more exciting and 2) it avoids the > > work required to set up a Superbuild. > > Then, IMO, these should just be separate repositories and optionally > remote modules rather than inside of VTK's repo. If they're "usually" > going to be built separately, just make them separate to begin with. Yes, that's right. - Matt From will.schroeder at kitware.com Mon Dec 17 14:36:40 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 17 Dec 2018 16:36:40 -0300 Subject: [vtk-developers] Christmas eCard Message-ID: <38700377714307319247.74FFD8ADB90C2A6E@vtk.org> Dear, vtkdev May the joy and peace of Christmas be with you all through the Year. Wishing you a season of blessings from heaven above. Here?s wishing you a Merry Christmas! Christmas eCard below. Will Schroeder Tel # 963-889-2890 Fax # 963-889-2822 will.schroeder at kitware.com God bless you and utterly satisfy your heart?with Himself. Amy Carmichael -------------- next part -------------- A non-text attachment was scrubbed... Name: Christmas wishes.doc Type: application/msword Size: 93056 bytes Desc: not available URL: From ben.boeckel at kitware.com Mon Dec 17 16:13:51 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 17 Dec 2018 16:13:51 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> Message-ID: <20181217211351.GA18473@megas.kitware.com> On Mon, Dec 17, 2018 at 15:07:35 -0500, Matt McCormick wrote: > To explain more explicitly, the VTK module that was generated by > ParaView would have the following in its CMake package configuration > code: > > ``` > # This prevents recursion issues > if(NOT ParaView_SOURCE_DIR) > # This make sure we load the ParaView configuration the module was built from > set(ParaView_DIR \"${ParaView_BINARY_DIR}\") > find_package(ParaView REQUIRED QUIET NO_MODULE) > endif() > ``` > > where "${ParaView_BINARY_DIR}" is substituted during ParaView's > configuration, like the "export_code" for third party libraries. I'd prefer that we just not need these hoops. ParaView's VTK modules live under ParaView in the new build, so it isn't an issue there at all anymore. > If a project that depends on VTK and only calls > > ``` > find_package(VTK COMPONENTS VTKModuleThatPublicallyDependsOnQt) > ``` > > how does the new module system load the Qt CMake package configuration > so CMake knows about the Qt build and its imported targets? That is, > is there an equivalent of `vtk_module_export_code_find_package`? > Similarly, if another VTK module depends on a third party library, and > the build is set to use the system's build of that library as opposed > to VTK's build, how does it load the CMake package configuration for > the third party library? Using `vtk_module_find_package` will export the `find_package` into the `VTK-module-find-package.cmake` file. This finds the dependency only if the module requiring it is requested (explicitly or via a dependency). It supports components, version checks[1], etc. Other than that, the only generated code by the module system is for adding module properties to targets (dependencies, hierarchy file paths, header locations, etc.). Code injection needs to be provided in the `foo-config.cmake` file which is not handled by the module system at all. > Yes -- we are talking about providing the package / module dependency > resolution of the system, which is not provided by CMake, and using > CMake's build system in a consistent way, as opposed to a secondary > build system. I'm confused. I thought you were mentioning providing an encapsulation for the ~150 lines that VTK has in its top-level CMakeLists.txt (finding module files, scanning them, building them, wrapping, handling the vtk-config.cmake file, etc.). That infrastructure is not provided by VTK and nor, IMO, should it. Dependent projects will still need to do those 100+ lines in order to be a "proper" project and provide something for `find_package` to work well. > > Then, IMO, these should just be separate repositories and optionally > > remote modules rather than inside of VTK's repo. If they're "usually" > > going to be built separately, just make them separate to begin with. > > Yes, that's right. OK, that sounds fine with me. What I'm not OK with is a module inside of the vtk/vtk repository supporting an independent build. So I guess this means that `RenderingOpenVR` will be moved out somewhere else then? --Ben [1] This is a bit complex due to version requirements of different projects. For example, say VTK has some modules which require Boost 1.41. If it finds 1.51.0, at install time the *exact* version must be found, so it gets forwarded as `find_package(Boost 1.51.0 EXACT)` even though the build does `find_package(Boost 1.41)`. Qt has a similar thing where the major.minor version built against is now the minimum version rather than the build-time requirement. From matt.mccormick at kitware.com Mon Dec 17 17:05:41 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 17 Dec 2018 17:05:41 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181217211351.GA18473@megas.kitware.com> References: <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> Message-ID: On Mon, Dec 17, 2018 at 4:13 PM Ben Boeckel wrote: > > On Mon, Dec 17, 2018 at 15:07:35 -0500, Matt McCormick wrote: > > > Yes -- we are talking about providing the package / module dependency > > resolution of the system, which is not provided by CMake, and using > > CMake's build system in a consistent way, as opposed to a secondary > > build system. > > I'm confused. I thought you were mentioning providing an encapsulation > for the ~150 lines that VTK has in its top-level CMakeLists.txt (finding > module files, scanning them, building them, wrapping, handling the > vtk-config.cmake file, etc.). That infrastructure is not provided by VTK > and nor, IMO, should it. Dependent projects will still need to do those > 100+ lines in order to be a "proper" project and provide something for > `find_package` to work well. The purpose is not to create dependent projects. The purpose is to create VTK modules. What is the distinction? The former requires creation, from scratch, a project dependency resolution system and an ad-hoc way to specify dependencies. The latter facilitates extending VTK as a library in a scalable way. From dave.demarle at kitware.com Mon Dec 17 17:40:13 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 17 Dec 2018 17:40:13 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181212211503.GA22183@megas.kitware.com> <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> Message-ID: Hey all, What say we set up a v-con to discuss this? The higher bandwidth of a face to face meeting will help quite a lot I think. With the holidays, we may not be able to all get together before January. @Ben when is your expected merge date for the new module system again? David E DeMarle Kitware, Inc. Principal Engineer 1217 Route 9 Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Dec 17, 2018 at 5:05 PM Matt McCormick via vtk-developers < vtk-developers at public.kitware.com> wrote: > On Mon, Dec 17, 2018 at 4:13 PM Ben Boeckel > wrote: > > > > On Mon, Dec 17, 2018 at 15:07:35 -0500, Matt McCormick wrote: > > > > > Yes -- we are talking about providing the package / module dependency > > > resolution of the system, which is not provided by CMake, and using > > > CMake's build system in a consistent way, as opposed to a secondary > > > build system. > > > > I'm confused. I thought you were mentioning providing an encapsulation > > for the ~150 lines that VTK has in its top-level CMakeLists.txt (finding > > module files, scanning them, building them, wrapping, handling the > > vtk-config.cmake file, etc.). That infrastructure is not provided by VTK > > and nor, IMO, should it. Dependent projects will still need to do those > > 100+ lines in order to be a "proper" project and provide something for > > `find_package` to work well. > > The purpose is not to create dependent projects. The purpose is to > create VTK modules. What is the distinction? The former requires > creation, from scratch, a project dependency resolution system and an > ad-hoc way to specify dependencies. The latter facilitates extending > VTK as a library in a scalable way. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Dec 18 08:39:11 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 18 Dec 2018 08:39:11 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> Message-ID: <20181218133911.GA25457@megas.kitware.com> On Mon, Dec 17, 2018 at 17:40:13 -0500, David E DeMarle wrote: > What say we set up a v-con to discuss this? The higher bandwidth of a face > to face meeting will help quite a lot I think. > > With the holidays, we may not be able to all get together before January. > @Ben when is your expected merge date for the new module system again? I have install rules for ParaView to finish, a rebase of each, a round of testing on the 3 platforms, and docs. Hopefully next week if not by Thursday (I'm out Friday). --Ben From ben.boeckel at kitware.com Tue Dec 18 08:43:41 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 18 Dec 2018 08:43:41 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181212221716.GA2777@megas.kitware.com> <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> Message-ID: <20181218134341.GB25457@megas.kitware.com> On Mon, Dec 17, 2018 at 17:05:41 -0500, Matt McCormick wrote: > The purpose is not to create dependent projects. The purpose is to > create VTK modules. What is the distinction? The former requires > creation, from scratch, a project dependency resolution system and an > ad-hoc way to specify dependencies. The latter facilitates extending > VTK as a library in a scalable way. VTK modules are a layer on top of CMake targets for handling optional dependencies, wrapping, autoinit, kit compiling, etc. They are indicated via properties on targets and can be provided by any package. They don't need to come from `find_package(VTK)` at all. VTK provides VTK's modules. ParaView provides its modules, ITK would provide its modules. VTK is special only in that it is the source for the module CMake API and contains some things like the wrapping tools, core wrapping libraries, etc. --Ben From lasso at queensu.ca Tue Dec 18 09:29:35 2018 From: lasso at queensu.ca (Andras Lasso) Date: Tue, 18 Dec 2018 14:29:35 +0000 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181218133911.GA25457@megas.kitware.com> References: <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> <20181218133911.GA25457@megas.kitware.com> Message-ID: It seems that we are quite far from a consensus here, so I fully agree David's proposal of having a tcon before considering merging this. Matt and Jc are providing a preview of what lead developers of toolkits that use/extend VTK think about the changes. You have to take these seriously because other maintainers will not be this friendly and cooperative if they realize that they need to make several changes, their code may be more complicated, and there are things that they cannot do anymore and the benefits (from their perspective) are not commensurate. One more point to consider: VTK is the example that all larger CMake-based projects are following in their CMake build system. Starting to treat VTK as "special" so that other projects had better not to follow its best practices would be bad. What project we could use as an example then? It is true that VTK is large but the same concepts should be applicable to smaller toolkits that have just a few modules and not tens of modules. Andras -----Original Message----- From: vtk-developers On Behalf Of Ben Boeckel via vtk-developers Sent: Tuesday, December 18, 2018 8:39 AM To: David E DeMarle Cc: VTK Developers ; Prabhu Ramachandran ; Jean-Christophe Fillion-Robin Subject: Re: [vtk-developers] vtk-8.2.0-rc2 problem building wheels On Mon, Dec 17, 2018 at 17:40:13 -0500, David E DeMarle wrote: > What say we set up a v-con to discuss this? The higher bandwidth of a > face to face meeting will help quite a lot I think. > > With the holidays, we may not be able to all get together before January. > @Ben when is your expected merge date for the new module system again? I have install rules for ParaView to finish, a rebase of each, a round of testing on the 3 platforms, and docs. Hopefully next week if not by Thursday (I'm out Friday). --Ben _______________________________________________ Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610649549&sdata=yYbrHCn5QWJc3QzcTYDBq%2F1fhQAl9VA5l%2FqkWWmxoPI%3D&reserved=0 Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=gilmZ6J%2Fm4RCjGbVd32HYlPFfDDSG6lEDUJ2i8UrzgY%3D&reserved=0 Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=%2BP%2FOz%2B2X6npNPeQDQz%2BK4fF4MOqSeC84vKmf1fECRwI%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=5KTa8%2B1OOhUlJhgeullae%2FRxUUS4EjvFvp61Wu7JFJk%3D&reserved=0 From dave.demarle at kitware.com Tue Dec 18 11:05:50 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 18 Dec 2018 11:05:50 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> <20181218133911.GA25457@megas.kitware.com> Message-ID: Andras thanks for the reminder. We do take it seriously. A primary goal of Ben's work is to use best modern CMake practices and make it easier not harder for consumers of VTK. Making the lives of packagers and us maintainers easier are also very high on the list. "Should", "to what extent" and "how" VTK will be an integral part of something else's build system basis are all under debate. I for one need to take a much closer look at what Ben has cooking. Let's all do the same before the meeting. Truth in advertising - a tcon was Ben's idea. David E DeMarle Kitware, Inc. Principal Engineer 1217 Route 9 Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Dec 18, 2018 at 9:29 AM Andras Lasso wrote: > It seems that we are quite far from a consensus here, so I fully agree > David's proposal of having a tcon before considering merging this. > > Matt and Jc are providing a preview of what lead developers of toolkits > that use/extend VTK think about the changes. You have to take these > seriously because other maintainers will not be this friendly and > cooperative if they realize that they need to make several changes, their > code may be more complicated, and there are things that they cannot do > anymore and the benefits (from their perspective) are not commensurate. > > One more point to consider: VTK is the example that all larger CMake-based > projects are following in their CMake build system. Starting to treat VTK > as "special" so that other projects had better not to follow its best > practices would be bad. What project we could use as an example then? It is > true that VTK is large but the same concepts should be applicable to > smaller toolkits that have just a few modules and not tens of modules. > > Andras > > > -----Original Message----- > From: vtk-developers On > Behalf Of Ben Boeckel via vtk-developers > Sent: Tuesday, December 18, 2018 8:39 AM > To: David E DeMarle > Cc: VTK Developers ; Prabhu Ramachandran < > prabhu at aero.iitb.ac.in>; Jean-Christophe Fillion-Robin > Subject: Re: [vtk-developers] vtk-8.2.0-rc2 problem building wheels > > On Mon, Dec 17, 2018 at 17:40:13 -0500, David E DeMarle wrote: > > What say we set up a v-con to discuss this? The higher bandwidth of a > > face to face meeting will help quite a lot I think. > > > > With the holidays, we may not be able to all get together before January. > > @Ben when is your expected merge date for the new module system again? > > I have install rules for ParaView to finish, a rebase of each, a round of > testing on the 3 platforms, and docs. Hopefully next week if not by > Thursday (I'm out Friday). > > --Ben > _______________________________________________ > Powered by > https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610649549&sdata=yYbrHCn5QWJc3QzcTYDBq%2F1fhQAl9VA5l%2FqkWWmxoPI%3D&reserved=0 > > Visit other Kitware open-source projects at > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=gilmZ6J%2Fm4RCjGbVd32HYlPFfDDSG6lEDUJ2i8UrzgY%3D&reserved=0 > > Search the list archives at: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=%2BP%2FOz%2B2X6npNPeQDQz%2BK4fF4MOqSeC84vKmf1fECRwI%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=5KTa8%2B1OOhUlJhgeullae%2FRxUUS4EjvFvp61Wu7JFJk%3D&reserved=0 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Tue Dec 18 20:23:13 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 18 Dec 2018 20:23:13 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181213165006.GA25088@megas.kitware.com> <20181213184811.GA10898@megas.kitware.com> <20181217184245.GA7200@rotor.localdomain> <20181217211351.GA18473@megas.kitware.com> <20181218133911.GA25457@megas.kitware.com> Message-ID: A tcon/vcon is a good idea. I know Jc is currently away on vacation for the holiday; he will be back in January. - Matt On Tue, Dec 18, 2018 at 11:06 AM David E DeMarle via vtk-developers wrote: > > Andras thanks for the reminder. We do take it seriously. A primary goal of Ben's work is to use best modern CMake practices and make it easier not harder for consumers of VTK. Making the lives of packagers and us maintainers easier are also very high on the list. > > "Should", "to what extent" and "how" VTK will be an integral part of something else's build system basis are all under debate. I for one need to take a much closer look at what Ben has cooking. Let's all do the same before the meeting. > > Truth in advertising - a tcon was Ben's idea. > > David E DeMarle > Kitware, Inc. > Principal Engineer > 1217 Route 9 > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > On Tue, Dec 18, 2018 at 9:29 AM Andras Lasso wrote: >> >> It seems that we are quite far from a consensus here, so I fully agree David's proposal of having a tcon before considering merging this. >> >> Matt and Jc are providing a preview of what lead developers of toolkits that use/extend VTK think about the changes. You have to take these seriously because other maintainers will not be this friendly and cooperative if they realize that they need to make several changes, their code may be more complicated, and there are things that they cannot do anymore and the benefits (from their perspective) are not commensurate. >> >> One more point to consider: VTK is the example that all larger CMake-based projects are following in their CMake build system. Starting to treat VTK as "special" so that other projects had better not to follow its best practices would be bad. What project we could use as an example then? It is true that VTK is large but the same concepts should be applicable to smaller toolkits that have just a few modules and not tens of modules. >> >> Andras >> >> >> -----Original Message----- >> From: vtk-developers On Behalf Of Ben Boeckel via vtk-developers >> Sent: Tuesday, December 18, 2018 8:39 AM >> To: David E DeMarle >> Cc: VTK Developers ; Prabhu Ramachandran ; Jean-Christophe Fillion-Robin >> Subject: Re: [vtk-developers] vtk-8.2.0-rc2 problem building wheels >> >> On Mon, Dec 17, 2018 at 17:40:13 -0500, David E DeMarle wrote: >> > What say we set up a v-con to discuss this? The higher bandwidth of a >> > face to face meeting will help quite a lot I think. >> > >> > With the holidays, we may not be able to all get together before January. >> > @Ben when is your expected merge date for the new module system again? >> >> I have install rules for ParaView to finish, a rebase of each, a round of testing on the 3 platforms, and docs. Hopefully next week if not by Thursday (I'm out Friday). >> >> --Ben >> _______________________________________________ >> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610649549&sdata=yYbrHCn5QWJc3QzcTYDBq%2F1fhQAl9VA5l%2FqkWWmxoPI%3D&reserved=0 >> >> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=gilmZ6J%2Fm4RCjGbVd32HYlPFfDDSG6lEDUJ2i8UrzgY%3D&reserved=0 >> >> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=%2BP%2FOz%2B2X6npNPeQDQz%2BK4fF4MOqSeC84vKmf1fECRwI%3D&reserved=0 >> >> Follow this link to subscribe/unsubscribe: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C7a277142fe374e0d63c508d664ee3643%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636807371610659558&sdata=5KTa8%2B1OOhUlJhgeullae%2FRxUUS4EjvFvp61Wu7JFJk%3D&reserved=0 >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Wed Dec 19 02:13:49 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Dec 2018 08:13:49 +0100 Subject: [vtk-developers] Up-to-date vtk-master debs? In-Reply-To: References: Message-ID: Den l?r 10 nov. 2018 kl 09:16 skrev Elvis Stansvik : > > Den ons 7 nov. 2018 kl 20:48 skrev Elvis Stansvik > : > > > > Hi all, > > > > The blog series about the Debian packaging back in July [1] mentioned > > that a nightly builds of VTK would be packaged as vtk-master, but the > > package currently in the APT repo (https://apt.kitware.com/) seems to > > be to be from July 6. > > > > Anyone if nightly builds will become available at some point, or if > > the initiative was cancelled? > > > > Would be absolutely fantastic if nightly packages were available, for > > testing purposes ahead of releases. > > I found now that the source package kept at > https://gitlab.kitware.com/debian/vtk seems to be up-to-date (current > version is 2018.11.10-0kw1). > > But the version in the repo is 2018.07.06-0kw1 (see > https://apt.kitware.com/debian/dists/sid/main/binary-amd64/Packages). > > Have the package builds stopped? Replying to myself here. I'm guessing since no one has answered, this initiative has been put on hold or been canceled? Any chance it'll be revived? Cheers, Elvis > > Elvis > > > > > Cheers, > > Elvis > > > > [1] https://blog.kitware.com/rethinking-debian-packaging-for-vtk-and-other-cmake-projects-part-1/ From kyle.edwards at kitware.com Wed Dec 19 09:49:55 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 19 Dec 2018 09:49:55 -0500 Subject: [vtk-developers] Up-to-date vtk-master debs? In-Reply-To: References: Message-ID: <1545230995.2463.74.camel@kitware.com> Elvis, Unfortunately, we're still a few months out from being able to complete this. That being said, if anyone wants to volunteer to help, I do have a plan of action for finishing this project. Email me and I can give more details of what needs to be done. The biggest holdup at the moment is that VTK recently switched to a new module system which changes how it gets built. The packaging will have to be updated to account for this. It's also not a set-it-and-forget-it kind of thing - VTK is constantly changing and evolving, and we will always have to update the packaging as both VTK and Debian change. I wrote dh-cmake and added CTest dashboard functionality to make this easier, but there's still some work that has to go into the packaging to get it up to snuff with Debian policies. Kyle On Wed, 2018-12-19 at 08:13 +0100, Elvis Stansvik wrote: > Den l?r 10 nov. 2018 kl 09:16 skrev Elvis Stansvik > : > > > > > > Den ons 7 nov. 2018 kl 20:48 skrev Elvis Stansvik > > : > > > > > > > > > Hi all, > > > > > > The blog series about the Debian packaging back in July [1] > > > mentioned > > > that a nightly builds of VTK would be packaged as vtk-master, but > > > the > > > package currently in the APT repo (https://apt.kitware.com/) > > > seems to > > > be to be from July 6. > > > > > > Anyone if nightly builds will become available at some point, or > > > if > > > the initiative was cancelled? > > > > > > Would be absolutely fantastic if nightly packages were available, > > > for > > > testing purposes ahead of releases. > > I found now that the source package kept at > > https://gitlab.kitware.com/debian/vtk seems to be up-to-date > > (current > > version is 2018.11.10-0kw1). > > > > But the version in the repo is 2018.07.06-0kw1 (see > > https://apt.kitware.com/debian/dists/sid/main/binary-amd64/Packages > > ). > > > > Have the package builds stopped? > Replying to myself here. I'm guessing since no one has answered, this > initiative has been put on hold or been canceled? Any chance it'll be > revived? > > Cheers, > Elvis > > > > > > > Elvis > > > > > > > > > > > Cheers, > > > Elvis > > > > > > [1] https://blog.kitware.com/rethinking-debian-packaging-for-vtk- > > > and-other-cmake-projects-part-1/ > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/op > ensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-develo > pers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Wed Dec 19 10:37:26 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 19 Dec 2018 16:37:26 +0100 Subject: [vtk-developers] Up-to-date vtk-master debs? In-Reply-To: <1545230995.2463.74.camel@kitware.com> References: <1545230995.2463.74.camel@kitware.com> Message-ID: Alright, thanks for the update Kyle! I can imagine the new module system will have some consequences for the packaging. I may have time to help, but mostly with testing, as I'm no seasoned Debian packager myself. BTW, do you know if the packages would in the end work with Ubuntu 18.04 LTS? Elvis Den ons 19 dec. 2018 kl 15:49 skrev Kyle Edwards : > > Elvis, > > Unfortunately, we're still a few months out from being able to complete > this. That being said, if anyone wants to volunteer to help, I do have > a plan of action for finishing this project. Email me and I can give > more details of what needs to be done. > > The biggest holdup at the moment is that VTK recently switched to a new > module system which changes how it gets built. The packaging will have > to be updated to account for this. It's also not a set-it-and-forget-it > kind of thing - VTK is constantly changing and evolving, and we will > always have to update the packaging as both VTK and Debian change. I > wrote dh-cmake and added CTest dashboard functionality to make this > easier, but there's still some work that has to go into the packaging > to get it up to snuff with Debian policies. > > Kyle > > On Wed, 2018-12-19 at 08:13 +0100, Elvis Stansvik wrote: > > Den l?r 10 nov. 2018 kl 09:16 skrev Elvis Stansvik > > : > > > > > > > > > Den ons 7 nov. 2018 kl 20:48 skrev Elvis Stansvik > > > : > > > > > > > > > > > > Hi all, > > > > > > > > The blog series about the Debian packaging back in July [1] > > > > mentioned > > > > that a nightly builds of VTK would be packaged as vtk-master, but > > > > the > > > > package currently in the APT repo (https://apt.kitware.com/) > > > > seems to > > > > be to be from July 6. > > > > > > > > Anyone if nightly builds will become available at some point, or > > > > if > > > > the initiative was cancelled? > > > > > > > > Would be absolutely fantastic if nightly packages were available, > > > > for > > > > testing purposes ahead of releases. > > > I found now that the source package kept at > > > https://gitlab.kitware.com/debian/vtk seems to be up-to-date > > > (current > > > version is 2018.11.10-0kw1). > > > > > > But the version in the repo is 2018.07.06-0kw1 (see > > > https://apt.kitware.com/debian/dists/sid/main/binary-amd64/Packages > > > ). > > > > > > Have the package builds stopped? > > Replying to myself here. I'm guessing since no one has answered, this > > initiative has been put on hold or been canceled? Any chance it'll be > > revived? > > > > Cheers, > > Elvis > > > > > > > > > > > Elvis > > > > > > > > > > > > > > > Cheers, > > > > Elvis > > > > > > > > [1] https://blog.kitware.com/rethinking-debian-packaging-for-vtk- > > > > and-other-cmake-projects-part-1/ > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at http://www.kitware.com/op > > ensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q=vtk-develo > > pers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > From kyle.edwards at kitware.com Wed Dec 19 10:43:22 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 19 Dec 2018 10:43:22 -0500 Subject: [vtk-developers] Up-to-date vtk-master debs? In-Reply-To: References: <1545230995.2463.74.camel@kitware.com> Message-ID: <1545234202.2463.78.camel@kitware.com> On Wed, 2018-12-19 at 16:37 +0100, Elvis Stansvik wrote: > I may have time to help, but mostly with testing, as I'm no seasoned > Debian packager myself. One of the first steps is to get dh-cmake ready for integration into Debian. We have a working prototype, but it still needs documentation and man pages. We also made some slight changes to the new CPack External generator, and dh-cmake has to be updated to account for this (the -G parameter has to be changed from "Ext" to "External" - this is a very simple change, but I haven't gotten around to it yet.) If you'd like to help with this, you can find the code at https://gitla b.kitware.com/debian/dh-cmake?. > BTW, do you know if the packages would in the end work with Ubuntu > 18.04 LTS? That's the plan, but Debian and Ubuntu are packaged slightly differently, so the Ubuntu package would have to be tested and possibly changed to account for these differences. Kyle From ken.martin at kitware.com Wed Dec 19 12:40:42 2018 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 19 Dec 2018 12:40:42 -0500 Subject: [vtk-developers] mun config issue ideas? Message-ID: Does anyone have ideas on mun's cmake error. vtkRenderingVolume is requested yet the module system is erroring out saying it is not found. -- Checking if vfw32 supports video capture -- Checking if vfw32 supports video capture -- yes -- Found OpenGL: opengl32 CMake Error at CMake/vtkModuleAPI.cmake:140 (message): Requested modules not available: vtkRenderingVolume vtkRenderingVolume Call Stack (most recent call first): CMake/vtkModuleMacros.cmake:202 (vtk_module_config) CMake/vtkModuleMacros.cmake:624 (vtk_module_impl) Rendering/VolumeOpenGL2/CMakeLists.txt:51 (vtk_module_library) -- Configuring incomplete, errors occurred! -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopano at gmail.com Thu Dec 20 04:03:23 2018 From: mkopano at gmail.com (Markos Kopanos) Date: Thu, 20 Dec 2018 11:03:23 +0200 Subject: [vtk-developers] VTK_POLYHEDRON problem is non-convex faces Message-ID: I have a question regarding the VTK_POLYHEDRON. When all the faces are convex faces the rendering is ok. When one of the faces is non-convex the result is wrong [image: image.png] The corresponding code is this vtkSmartPointer ugrid = vtkSmartPointer< vtkUnstructuredGrid>::New(); ugrid->SetPoints(points); ugrid->InsertNextCell(VTK_POLYHEDRON, 10, dodechedronPointsIds, 6, Faces->GetPointer()); When I use wireframe representation for both convex and non-convex polygons the results are ok (the second attached file) SetRepresentationToWireframe(); When I use rendering representation for convex faces is ok but for non-convex the representation is wrong tmpCustomActor->GetProperty()->SetRepresentationToSurface() Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 15372 bytes Desc: not available URL: From michael.migliore at kitware.com Thu Dec 20 06:45:20 2018 From: michael.migliore at kitware.com (Michael Migliore) Date: Thu, 20 Dec 2018 12:45:20 +0100 Subject: [vtk-developers] VTK_POLYHEDRON problem is non-convex faces In-Reply-To: References: Message-ID: Hi Markos, In order to correctly render polygons in OpenGL, we need to cut them into triangles. While it is straightforward for convex polygons (choose an edge and construct triangles with other points), it is another story for concaves. For information, the code is here: https://github.com/Kitware/VTK/blob/d8011ccc51fb1cd99d2bbce57b8f76715f116bb5/Rendering/OpenGL2/vtkOpenGLIndexBufferObject.cxx#L496 As far as I know, when trying to render a polygon, VTK expects it to be convex. Regards, Michael On Thu, Dec 20, 2018 at 10:03 AM Markos Kopanos wrote: > > I have a question regarding the VTK_POLYHEDRON. When all the faces are convex faces the rendering is ok. > > When one of the faces is non-convex the result is wrong > > > > > The corresponding code is this > > > > vtkSmartPointer ugrid = vtkSmartPointer::New(); > > ugrid->SetPoints(points); > > ugrid->InsertNextCell(VTK_POLYHEDRON, 10, dodechedronPointsIds, 6, Faces->GetPointer()); > > > > When I use wireframe representation for both convex and non-convex polygons the results are ok (the second attached file) > > > > SetRepresentationToWireframe(); > > > > When I use rendering representation for convex faces is ok but for non-convex the representation is wrong > > > > tmpCustomActor->GetProperty()->SetRepresentationToSurface() > > > Thanks > > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > -- Michael Migliore R&D Engineer, Scientific Visualization Team Kitware SAS From mkopano at gmail.com Thu Dec 20 09:02:33 2018 From: mkopano at gmail.com (Markos Kopanos) Date: Thu, 20 Dec 2018 16:02:33 +0200 Subject: [vtk-developers] More in speed in extrude polygons procedure Message-ID: Hello, I wonder if someone has a solution to the following problem that i have: I have a very large number of non-convex polygons (70000) and i want to extrude each one of them. The procedure that i follow is this: vtkPoints, vtkPolygon, vtkPolyData, vtkTriangleFilter, vtkLinearExtrusionFilter and add invtkAppendPolyData After the extrusion of all of them: vtkPolyDataMapper and i apply the Actor and put them in Renderer Here is the code //////////////////////////////////////////////////////////// vtkSmartPointer appendFilter = vtkSmartPointer::New(); //////////////////////////////////////////////////////////// for (int i = 0; i < numbeams; i++) { // numcolumns //////////////////////////////////////////////////////////// // Setup four points vtkSmartPointer points = vtkSmartPointer::New(); for (int j = num_kop_draw_from; j < num_kop_draw_to; j++) { points->InsertNextPoint(profile_points[j].x, -profile_points[j].z, profile_points[j].y); } int NumberofIds = points->GetNumberOfPoints(); //////////////////////////////////////////////////////////////////////////// //////////////////// vtkSmartPointer line_Attrib = vtkSmartPointer::New(); line_Attrib->SetNumberOfComponents(2); // 0=color , 1=ID // Create the polygon vtkSmartPointer polygon = vtkSmartPointer::New(); polygon->GetPointIds()->SetNumberOfIds(NumberofIds); //make a quad for (int ip = 0; ip < NumberofIds; ip++) { polygon->GetPointIds()->SetId(ip, ip); line_Attrib->InsertNextTuple2(2, id); } // Add the polygon to a list of polygons vtkSmartPointer polygons = vtkSmartPointer::New(); polygons->InsertNextCell(polygon); // Create a PolyData vtkSmartPointer polygonPolyData = vtkSmartPointer::New(); polygonPolyData->SetPoints(points); polygonPolyData->SetPolys(polygons); polygonPolyData->GetCellData()->SetScalars(line_Attrib); vtkSmartPointer triFilter = vtkSmartPointer::New(); triFilter->PassLinesOff(); triFilter->PassVertsOff(); triFilter->SetInputData(polygonPolyData); triFilter->Update(); vtkSmartPointer extrudeFilter = vtkSmartPointer::New(); extrudeFilter->SetInputData(triFilter->GetOutput()); //extruding base extrudeFilter->SetExtrusionType(VTK_VECTOR_EXTRUSION); extrudeFilter->SetVector(Vector_Math[0], Vector_Math[1], Vector_Math[2]); //direction extrudeFilter->SetScaleFactor(Len); extrudeFilter->Update(); appendFilter->AddInputData(extrudeFilter->GetOutput()); //////////////////////////////////////////////////////////// } appendFilter->Update(); // Create a mapper and actor vtkSmartPointer mapper = vtkSmartPointer::New(); mapper->SetInputData(appendFilter->GetOutput()); if (CGI_View) { mapper->ScalarVisibilityOn(); mapper->SetScalarRange(0, CGI_View->colors_Palete_scada->GetNumberOfColors() - 1); mapper->SetLookupTable(CGI_View->colors_Palete_scada); } vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(mapper); Although the final result is pretty fast, the initial creation of the objects with the previous procedure is very slow. Do you have any ideas how to speed up this procedure? Thank in advanced -------------- next part -------------- An HTML attachment was scrubbed... URL: From edgar.grimberg at gmail.com Sat Dec 29 13:26:40 2018 From: edgar.grimberg at gmail.com (Edgar Grimberg) Date: Sat, 29 Dec 2018 19:26:40 +0100 Subject: [vtk-developers] build error compiling PCL under MacOS Mojave Message-ID: Hi, Trying to compile PCL under MacOS Mojave, I am running into an error like: */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:313:9: **error: **no member named 'signbit' in the global namespace* using ::signbit; * ~~^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:314:9: **error: **no member named 'fpclassify' in the global namespace* using ::fpclassify; * ~~^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:315:9: **error: **no member named 'isfinite' in the global namespace; did you mean 'finite'?* using ::isfinite; * ~~^* */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/math.h:749:12: note: *'finite' declared here extern int finite(double) The main reason for this is VTK introducing: -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include If I run the compilation command manually without the /usr/include folder, it compiles fine. I am using latest VTK from brew: vtk: stable 8.1.2 (bottled), HEAD Thanks, Edgar -------------- next part -------------- An HTML attachment was scrubbed... URL: From edgar.grimberg at gmail.com Sat Dec 29 20:02:46 2018 From: edgar.grimberg at gmail.com (Edgar Grimberg) Date: Sun, 30 Dec 2018 02:02:46 +0100 Subject: [vtk-developers] build error compiling PCL under MacOS Mojave In-Reply-To: References: Message-ID: After some investigation, it looks like the problem only manifests for cmake generating Makefiles, but works fine for Xcode builder. Edgar On Sat, Dec 29, 2018 at 7:26 PM Edgar Grimberg wrote: > Hi, > > Trying to compile PCL under MacOS Mojave, I am running into an error like: > > */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:313:9: > **error: **no member named 'signbit' in the global namespace* > > using ::signbit; > > * ~~^* > > */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:314:9: > **error: **no member named 'fpclassify' in the global namespace* > > using ::fpclassify; > > * ~~^* > > */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:315:9: > **error: **no member named 'isfinite' in the global namespace; did you > mean 'finite'?* > > using ::isfinite; > > * ~~^* > > */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/math.h:749:12: > note: *'finite' declared here > extern int finite(double) > > The main reason for this is VTK introducing: > > > -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include > > > If I run the compilation command manually without the /usr/include folder, > it compiles fine. > > > I am using latest VTK from brew: > > > vtk: stable 8.1.2 (bottled), HEAD > > > Thanks, > > Edgar > -------------- next part -------------- An HTML attachment was scrubbed... URL: