From dave.demarle at kitware.com Mon Oct 1 09:54:04 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 1 Oct 2018 09:54:04 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: <20180927143927.GA22820@rotor.kitware.com> <20180928130555.GA7447@rotor.kitware.com> Message-ID: Thanks for the input everyone. It seems that noone objects to changing master's name off of 9.0, so I will go ahead and finish up the merge request to reset it to 8.2.0 today. I'll defer the numbering scheme for subsequent releases for a little while. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Sep 28, 2018 at 9:27 AM Bill Lorensen wrote: > That would work. > > On Fri, Sep 28, 2018, 6:05 AM Ben Boeckel wrote: > >> On Thu, Sep 27, 2018 at 20:44:22 -0700, Bill Lorensen wrote: >> > I mean a # that increments nightly. Resets to 0 when a the revision >> > number changes. >> > >> > Major.Minor.Patch.Build >> > >> > Right now if a new class is added you there is no way to know from the >> > version when it was added. >> > >> > I think we used to do this in vtk... >> >> CMake does this, but it is not just a number that resets to 0, but a >> datestamp: >> >> >> https://gitlab.kitware.com/cmake/cmake/commit/8bb0e09e38d3ab75198b1cd9746bfa7a7b80ff94 >> >> It is used *as* the patch number, not a fourth component. This means >> that as soon as we branch and make M.N.0, `master` is already >> M.N.2018MMDD and "bigger". >> >> --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 jcfr at kitware.com Tue Oct 2 13:16:03 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 2 Oct 2018 13:16:03 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: <20180927143927.GA22820@rotor.kitware.com> <20180928130555.GA7447@rotor.kitware.com> Message-ID: Hi Folks, My apology for answering late, I was literally our of town without any connection for the past two weeks and didn't have a chance to comment earlier. While 3D Slicer itself can easily be updated, there are projects that build against 3D Slicer and/or dependent on 3D Slicer while supporting being built against different of VTK. To avoid the burden of updating each one of these projects, I am writing an email to the list to check if others would support reverting back to version 9.0.0 ? Thanks Jc On Mon, Oct 1, 2018 at 9:54 AM David E DeMarle wrote: > Thanks for the input everyone. > > It seems that noone objects to changing master's name off of 9.0, so I > will go ahead and finish up the merge request > to reset it to > 8.2.0 today. > > I'll defer the numbering scheme for subsequent releases for a little while. > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > On Fri, Sep 28, 2018 at 9:27 AM Bill Lorensen > wrote: > >> That would work. >> >> On Fri, Sep 28, 2018, 6:05 AM Ben Boeckel >> wrote: >> >>> On Thu, Sep 27, 2018 at 20:44:22 -0700, Bill Lorensen wrote: >>> > I mean a # that increments nightly. Resets to 0 when a the revision >>> > number changes. >>> > >>> > Major.Minor.Patch.Build >>> > >>> > Right now if a new class is added you there is no way to know from the >>> > version when it was added. >>> > >>> > I think we used to do this in vtk... >>> >>> CMake does this, but it is not just a number that resets to 0, but a >>> datestamp: >>> >>> >>> https://gitlab.kitware.com/cmake/cmake/commit/8bb0e09e38d3ab75198b1cd9746bfa7a7b80ff94 >>> >>> It is used *as* the patch number, not a fourth component. This means >>> that as soon as we branch and make M.N.0, `master` is already >>> M.N.2018MMDD and "bigger". >>> >>> --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 >> >> _______________________________________________ > 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 Wed Oct 3 09:17:58 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 3 Oct 2018 09:17:58 -0400 Subject: [vtk-developers] Removing unreferenced examples Message-ID: <20181003131758.GA28415@rotor> Hi all, In the process of doing the new module system, I've come across many examples which seem to be unreferenced in the CMake code. Should any of them be saved? If so, it would be nice to have them at least behind a `if (SOME_FLAG)` option so there's a chance they can run. Here's a list of unreferenced examples: Commented out: Examples/Array/Cxx Examples/GUI/Win32/SampleMFC Examples/GUI/Win32/SimpleCxx Examples/GUI/Win32/vtkMFC Unreferenced: Examples/GUI/Cocoa David Gobbi mentioned that Sean McBride is maintaining this. How are they run? Manually? Examples/GUI/Qt Examples/GUI/Win32 --Ben From ben.boeckel at kitware.com Wed Oct 3 09:47:31 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 3 Oct 2018 09:47:31 -0400 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: <20181003131758.GA28415@rotor> References: <20181003131758.GA28415@rotor> Message-ID: <20181003134731.GB28415@rotor> On Wed, Oct 03, 2018 at 09:17:58 -0400, Ben Boeckel wrote: > Unreferenced: > Examples/GUI/Cocoa > David Gobbi mentioned that Sean McBride is maintaining this. > How are they run? Manually? > Examples/GUI/Qt > Examples/GUI/Win32 Also in this group are other example files which are unreferenced seen in this commit: https://gitlab.kitware.com/vtk/vtk/merge_requests/4733/diffs?commit_id=ba76d967b37a4b276dcc0b9be6f262bd78aaa23f --Ben From dave.demarle at kitware.com Thu Oct 4 09:51:48 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 4 Oct 2018 09:51:48 -0400 Subject: [vtk-developers] VTK hackathon 7 October 22nd Message-ID: Hey gang, It has been a while since weve had a VTK hackathon. How does October 22nd sound? What area do we want to focus our attentions on this time? For reference the previous hackathons were: Feb 2013 - dashathon Feb 2014 - coveragathon Oct 2014 - bugathon Jul 2016 - bugathon2 April 2017 - examplethon Sept 2017 - depracathalon One promising idea we've kicked around is "contrib-athon" that is looking at and merging as many merge requests and vtk journal articles as we can in a day. Another is thread-athon, with a goal of threading as many internal working as we can get our heads around. As always people are welcome to work outside of the focus area if they like. We'll host it at Kitware Headquarters in Albany NY and open in up remotely with a Google Meeting to all takers. Details to follow once we've settled on a date and topic. 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 Thu Oct 4 10:21:51 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 4 Oct 2018 10:21:51 -0400 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: <20181003134731.GB28415@rotor> References: <20181003131758.GA28415@rotor> <20181003134731.GB28415@rotor> Message-ID: Should these examples be move to the Examples project ? See https://github.com/lorensen/VTKExamples/tree/master/src On Wed, Oct 3, 2018 at 9:47 AM Ben Boeckel wrote: > On Wed, Oct 03, 2018 at 09:17:58 -0400, Ben Boeckel wrote: > > Unreferenced: > > Examples/GUI/Cocoa > > David Gobbi mentioned that Sean McBride is maintaining this. > > How are they run? Manually? > > Examples/GUI/Qt > > Examples/GUI/Win32 > > Also in this group are other example files which are unreferenced seen > in this commit: > > > https://gitlab.kitware.com/vtk/vtk/merge_requests/4733/diffs?commit_id=ba76d967b37a4b276dcc0b9be6f262bd78aaa23f > > --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 dan.lipsa at kitware.com Thu Oct 4 10:28:09 2018 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 4 Oct 2018 10:28:09 -0400 Subject: [vtk-developers] VTK hackathon 7 October 22nd In-Reply-To: References: Message-ID: Another idea is reader-athon (input-athon) People can fix / improve things in their favorite readers (I know I have a few fixes I would like to work on) or go through bug reports look at fixes for readers. Dan On Thu, Oct 4, 2018 at 9:52 AM David E DeMarle wrote: > Hey gang, > > It has been a while since weve had a VTK hackathon. How does October 22nd > sound? > > What area do we want to focus our attentions on this time? For reference > the previous hackathons were: > Feb 2013 - dashathon > Feb 2014 - coveragathon > Oct 2014 - bugathon > Jul 2016 - bugathon2 > April 2017 - examplethon > Sept 2017 - depracathalon > > One promising idea we've kicked around is "contrib-athon" that is looking > at and merging as many merge requests and vtk journal articles as we can in > a day. Another is thread-athon, with a goal of threading as many internal > working as we can get our heads around. As always people are welcome to > work outside of the focus area if they like. > > We'll host it at Kitware Headquarters in Albany NY and open in up remotely > with a Google Meeting to all takers. Details to follow once we've settled > on a date and topic. > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Oct 4 11:01:21 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 4 Oct 2018 08:01:21 -0700 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: References: <20181003131758.GA28415@rotor> <20181003134731.GB28415@rotor> Message-ID: Many have been moved. Perhaps this can be addressed at the upcoming hackathon. On Thu, Oct 4, 2018, 7:22 AM Jean-Christophe Fillion-Robin wrote: > Should these examples be move to the Examples project ? > See https://github.com/lorensen/VTKExamples/tree/master/src > > On Wed, Oct 3, 2018 at 9:47 AM Ben Boeckel > wrote: > >> On Wed, Oct 03, 2018 at 09:17:58 -0400, Ben Boeckel wrote: >> > Unreferenced: >> > Examples/GUI/Cocoa >> > David Gobbi mentioned that Sean McBride is maintaining this. >> > How are they run? Manually? >> > Examples/GUI/Qt >> > Examples/GUI/Win32 >> >> Also in this group are other example files which are unreferenced seen >> in this commit: >> >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/4733/diffs?commit_id=ba76d967b37a4b276dcc0b9be6f262bd78aaa23f >> >> --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 >> >> _______________________________________________ > 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 Thu Oct 4 11:28:21 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 4 Oct 2018 11:28:21 -0400 Subject: [vtk-developers] VTK hackathon 7 October 22nd In-Reply-To: References: Message-ID: <20181004152821.GA26204@rotor.kitware.com> On Thu, Oct 04, 2018 at 09:51:48 -0400, David E DeMarle wrote: > One promising idea we've kicked around is "contrib-athon" that is looking > at and merging as many merge requests and vtk journal articles as we can in I'd prefer a contrib-athon. How about triaging issues as well (since the dashboards are likely to be backed up on MR testing anyways?)? --Ben From bill.lorensen at gmail.com Thu Oct 4 13:13:04 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 4 Oct 2018 10:13:04 -0700 Subject: [vtk-developers] VTK hackathon 7 October 22nd In-Reply-To: <20181004152821.GA26204@rotor.kitware.com> References: <20181004152821.GA26204@rotor.kitware.com> Message-ID: +1 contrib-a-thon On Thu, Oct 4, 2018, 8:28 AM Ben Boeckel wrote: > On Thu, Oct 04, 2018 at 09:51:48 -0400, David E DeMarle wrote: > > One promising idea we've kicked around is "contrib-athon" that is looking > > at and merging as many merge requests and vtk journal articles as we can > in > > I'd prefer a contrib-athon. How about triaging issues as well (since the > dashboards are likely to be backed up on MR testing anyways?)? > > --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 prabhu at aero.iitb.ac.in Mon Oct 8 01:17:40 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Mon, 8 Oct 2018 01:17:40 -0400 Subject: [vtk-developers] Python wheel building breakage in master Message-ID: Hi everyone, I was trying to build wheels with VTKPythonPackage with VTK master but the recent changes with the vtkmodules package seems to have broken things. It is not clear what exact changes we need for this but it looks like this commit may have broken this: https://gitlab.kitware.com/vtk/vtk/commit/867d93c2ab6bb4aaff80503e8037f649fe23cc4f It may be a simple thing to fix with the possible options available but I haven't been able to get it working correctly.? This would be nice to fix before the next VTK release. Thanks! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Oct 8 13:06:34 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 8 Oct 2018 13:06:34 -0400 Subject: [vtk-developers] VTK hackathon 7 October 22nd In-Reply-To: References: Message-ID: OK let's to it on Tuesday October 23'rd. The v-con link is: https://meet.google.com/bvz-dazh-zfz The focus area will be "merge everything!" but of course everyone is welcome to work on whatever they like and contribute to/benefit from the amped-up group mind. Lunch will be provided to those who participate at Kitware in NY. If you plan to attend in person, please let me know soon so I can arrange a visitor badge for you. Thanks. See you all in just over two weeks! David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Oct 4, 2018 at 9:51 AM David E DeMarle wrote: > Hey gang, > > It has been a while since weve had a VTK hackathon. How does October 22nd > sound? > > What area do we want to focus our attentions on this time? For reference > the previous hackathons were: > Feb 2013 - dashathon > Feb 2014 - coveragathon > Oct 2014 - bugathon > Jul 2016 - bugathon2 > April 2017 - examplethon > Sept 2017 - depracathalon > > One promising idea we've kicked around is "contrib-athon" that is looking > at and merging as many merge requests and vtk journal articles as we can in > a day. Another is thread-athon, with a goal of threading as many internal > working as we can get our heads around. As always people are welcome to > work outside of the focus area if they like. > > We'll host it at Kitware Headquarters in Albany NY and open in up remotely > with a Google Meeting to all takers. Details to follow once we've settled > on a date and topic. > > 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 cory.quammen at kitware.com Mon Oct 8 13:21:14 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 8 Oct 2018 13:21:14 -0400 Subject: [vtk-developers] VTK hackathon 7 October 22nd In-Reply-To: References: Message-ID: If we are going to be reviewing/merging outstanding merge requests, it would be good for folks to rebase branches on master and retest on the dashboards ahead of time. Waiting until the day of the merge-a-thon will lead to enormous dashboard queues. Any ideas on how to encourage that or make it happen, ideally more efficient than prodding the 143 open merge requests individually? Thanks, Cory On Mon, Oct 8, 2018 at 1:06 PM David E DeMarle wrote: > OK let's to it on Tuesday October 23'rd. The v-con link is: > https://meet.google.com/bvz-dazh-zfz > > The focus area will be "merge everything!" but of course everyone is > welcome to work on whatever they like and contribute to/benefit from the > amped-up group mind. > > Lunch will be provided to those who participate at Kitware in NY. If you > plan to attend in person, please let me know soon so I can arrange a > visitor badge for you. > > Thanks. See you all in just over two weeks! > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > On Thu, Oct 4, 2018 at 9:51 AM David E DeMarle > wrote: > >> Hey gang, >> >> It has been a while since weve had a VTK hackathon. How does October 22nd >> sound? >> >> What area do we want to focus our attentions on this time? For reference >> the previous hackathons were: >> Feb 2013 - dashathon >> Feb 2014 - coveragathon >> Oct 2014 - bugathon >> Jul 2016 - bugathon2 >> April 2017 - examplethon >> Sept 2017 - depracathalon >> >> One promising idea we've kicked around is "contrib-athon" that is looking >> at and merging as many merge requests and vtk journal articles as we can in >> a day. Another is thread-athon, with a goal of threading as many internal >> working as we can get our heads around. As always people are welcome to >> work outside of the focus area if they like. >> >> We'll host it at Kitware Headquarters in Albany NY and open in up >> remotely with a Google Meeting to all takers. Details to follow once we've >> settled on a date and topic. >> >> 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 > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Wed Oct 10 08:16:15 2018 From: simon.esneault at gmail.com (Simon Esneault) Date: Wed, 10 Oct 2018 14:16:15 +0200 Subject: [vtk-developers] [vtkusers] Message-ID: Hello community, We sometimes get an ugly crash in our app, for the first rendering on a 3D view on OSX. We are using QT 5.9.4, and VTK 8.1. Here is the stacktrace, does that ring a bell to anyone ? ********************************************************************************** 0: Process: App_Starter [65595] 1: Path: /Applications/EndoSize.app/Contents/MacOS/App_Starter 2: Identifier: App_Starter 3: Version: ??? 4: Code Type: X86-64 (Native) 5: Parent Process: ??? [1] 6: Responsible: App_Starter [65595] 7: User ID: 501 8: 9: Date/Time: 2018-10-10 13:41:35.706 +0200 10: OS Version: Mac OS X 10.13.6 (17G65) 11: Report Version: 12 12: Anonymous UUID: 2296AEBE-E6B4-BDDD-C0D9-5C1C10D27782 13: 14: Sleep/Wake UUID: E59AB7AB-66BB-4E40-9F86-4E6D8239F26B 15: 16: Time Awake Since Boot: 540000 seconds 17: Time Since Wake: 250 seconds 18: 19: System Integrity Protection: enabled 20: 21: Crashed Thread: 0 Dispatch queue: com.apple.main-thread 22: 23: Exception Type: EXC_CRASH (SIGABRT) 24: Exception Codes: 0x0000000000000000, 0x0000000000000000 25: Exception Note: EXC_CORPSE_NOTIFY 26: 27: Application Specific Information: 28: abort() called 29: 30: Application Specific Signatures: 31: Graphics hardware encountered an error and was reset: 0x00000003 32: 33: 34: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 35: 0 libsystem_kernel.dylib 0x00007fff51aacb66 __pthread_kill + 10 36: 1 libsystem_pthread.dylib 0x00007fff51c77080 pthread_kill + 333 37: 2 libsystem_c.dylib 0x00007fff51a081ae abort + 127 38: 3 libGPUSupportMercury.dylib 0x00007fff4259a0f1 gpusGenerateCrashLog + 168 39: 4 com.apple.driver.AppleIntelHD5000GraphicsGLDriver 0x0000000116900c5d gpusKillClientExt + 9 40: 5 libGPUSupportMercury.dylib 0x00007fff4259b63a gpusSubmitDataBuffers + 540 41: 6 com.apple.driver.AppleIntelHD5000GraphicsGLDriver 0x00000001164b963a IntelCommandBuffer::getNew(GLDContextRec*) + 178 42: 7 com.apple.driver.AppleIntelHD5000GraphicsGLDriver 0x00000001164b9232 intelSubmitCommands + 178 43: 8 com.apple.driver.AppleIntelHD5000GraphicsGLDriver 0x00000001164c6b76 intelFinishCommands + 187 44: 9 com.apple.driver.AppleIntelHD5000GraphicsGLDriver 0x00000001164c60e0 glrReadFramebufferData + 4556 45: 10 GLEngine 0x00007fff3406d4f9 glReadPixels_Exec + 1032 46: 11 libGL.dylib 0x00007fff334b7dc3 glReadPixels + 42 47: 12 libThVtk.dylib 0x000000010a49ae87 vtkOpenGLRenderWindow::ReadPixels(vtkRecti const&, int, int, int, void*, int) + 743 48: 13 libThVtk.dylib 0x000000010a49aa9d vtkOpenGLRenderWindow::GetPixelData(int, int, int, int, int, int) + 157 49: 14 libThVtk.dylib 0x000000010a5ccc43 vtkRenderer::Render() + 1683 50: 15 libThVtk.dylib 0x000000010a5cba09 vtkRendererCollection::Render() + 137 51: 16 libThVtk.dylib 0x000000010a5d624c vtkRenderWindow::DoStereoRender() + 140 52: 17 libThVtk.dylib 0x000000010a5d5559 vtkRenderWindow::Render() + 649 53: 18 libThVtk.dylib 0x000000010a42af02 vtkGenericOpenGLRenderWindow::Render() + 34 54: 19 libThVtk.dylib 0x000000010a5d9627 vtkRenderWindowInteractor::Render() + 39 55: 20 libThVtk.dylib 0x000000010a16b90a QVTKOpenGLWindow::paintGL() + 138 56: 21 QtGui 0x0000000110ef87a5 0x110e8f000 + 432037 57: 22 QtGui 0x0000000110ef85ad QPaintDeviceWindow::exposeEvent(QExposeEvent*) + 173 58: 23 QtGui 0x0000000110ecd25e QWindow::event(QEvent*) + 798 59: 24 QtGui 0x0000000110ef8656 QPaintDeviceWindow::event(QEvent*) + 118 60: 25 QtWidgets 0x00000001108f4c52 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 306 61: 26 QtWidgets 0x00000001108f5f6f QApplication::notify(QObject*, QEvent*) + 383 ********************************************************************************** Thanks Simon -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Oct 10 09:21:57 2018 From: sean at rogue-research.com (Sean McBride) Date: Wed, 10 Oct 2018 09:21:57 -0400 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: <20181003131758.GA28415@rotor> References: <20181003131758.GA28415@rotor> Message-ID: <20181010132157.69584353@mail.rogue-research.com> On Wed, 3 Oct 2018 09:17:58 -0400, Ben Boeckel said: >In the process of doing the new module system, I've come across many >examples which seem to be unreferenced in the CMake code. Should any of >them be saved? If so, it would be nice to have them at least behind a >`if (SOME_FLAG)` option so there's a chance they can run. > >Here's a list of unreferenced examples: > >Commented out: > Examples/Array/Cxx > Examples/GUI/Win32/SampleMFC > Examples/GUI/Win32/SimpleCxx > Examples/GUI/Win32/vtkMFC > >Unreferenced: > Examples/GUI/Cocoa > David Gobbi mentioned that Sean McBride is maintaining this. > How are they run? Manually? I do maintain it. It can be built either by the included Xcode project or using the included CMakeLists.txt. When you say "unreferenced" what do you mean? Sean From ben.boeckel at kitware.com Wed Oct 10 13:54:55 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Oct 2018 13:54:55 -0400 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: <20181010132157.69584353@mail.rogue-research.com> References: <20181003131758.GA28415@rotor> <20181010132157.69584353@mail.rogue-research.com> Message-ID: <20181010175455.GA16553@rotor.kitware.com> On Wed, Oct 10, 2018 at 09:21:57 -0400, Sean McBride wrote: > I do maintain it. It can be built either by the included Xcode > project or using the included CMakeLists.txt. > > When you say "unreferenced" what do you mean? That there's no CMake code which builds the example. That is, the example is only manually built and therefore not tested (or testable!) to our dashboards. Is there some way we can get it available through something like: ```cmake if (VTK_BUILD_COCOA_EXAMPLE) add_test(NAME Example-Cocoa COMMAND ...) endif () ``` ? --Ben From sean at rogue-research.com Wed Oct 10 14:25:27 2018 From: sean at rogue-research.com (Sean McBride) Date: Wed, 10 Oct 2018 14:25:27 -0400 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: <20181010175455.GA16553@rotor.kitware.com> References: <20181003131758.GA28415@rotor> <20181010132157.69584353@mail.rogue-research.com> <20181010175455.GA16553@rotor.kitware.com> Message-ID: <20181010182527.1252203027@mail.rogue-research.com> On Wed, 10 Oct 2018 13:54:55 -0400, Ben Boeckel said: >On Wed, Oct 10, 2018 at 09:21:57 -0400, Sean McBride wrote: >> I do maintain it. It can be built either by the included Xcode >> project or using the included CMakeLists.txt. >> >> When you say "unreferenced" what do you mean? > >That there's no CMake code which builds the example. That is, the >example is only manually built and therefore not tested (or testable!) >to our dashboards. > >Is there some way we can get it available through something like: > >```cmake >if (VTK_BUILD_COCOA_EXAMPLE) > add_test(NAME Example-Cocoa COMMAND ...) >endif () >``` It certainly would be nice if it got built automagically, so as to keep API changes and whatnot from breaking it. But it's not a test, it's an example of an interactive application. Since it has its own CMakeLists.txt, isn't it just a matter of some higher level CMake stuff building it? I'm afraid my knowledge of CMake is limited to 'cd bin; cmake ../VTK; make install'. :) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ben.boeckel at kitware.com Wed Oct 10 15:41:57 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Oct 2018 15:41:57 -0400 Subject: [vtk-developers] Removing unreferenced examples In-Reply-To: <20181010182527.1252203027@mail.rogue-research.com> References: <20181003131758.GA28415@rotor> <20181010132157.69584353@mail.rogue-research.com> <20181010175455.GA16553@rotor.kitware.com> <20181010182527.1252203027@mail.rogue-research.com> Message-ID: <20181010194157.GA15644@rotor.kitware.com> On Wed, Oct 10, 2018 at 14:25:27 -0400, Sean McBride wrote: > It certainly would be nice if it got built automagically, so as to > keep API changes and whatnot from breaking it. But it's not a test, > it's an example of an interactive application. Since it has its own > CMakeLists.txt, isn't it just a matter of some higher level CMake > stuff building it? I'm afraid my knowledge of CMake is limited to 'cd > bin; cmake ../VTK; make install'. :) As far as VTK is concerned, *building* the example *is* a test. If it has tests, running them too would be great as well. Basically, the command for the test should be: ctest --build-and-test -- \ "-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}" \ --test-command "${CMAKE_CTEST_COMMAND}" --Ben From dan.lipsa at kitware.com Thu Oct 11 10:55:45 2018 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 11 Oct 2018 10:55:45 -0400 Subject: [vtk-developers] Add pugixml to VTK In-Reply-To: References: <87FC3B44-C211-4882-A35E-ACCB8890A532@kitware.com> <3E8B5C57-7401-4F3F-88AE-343A3499C363@kitware.com> <1BEB88D0-94FE-446C-8BFB-6190E4F95BD2@spiria.com> Message-ID: Hi all, Pugixml has been added to VTK master. https://gitlab.kitware.com/vtk/vtk/merge_requests/4597 Dan On Tue, Jul 17, 2018 at 9:54 AM Dan Lipsa wrote: > Hi all, > I have 4 responses so far, all for adding pugixml to VTK. I'll go ahead > and do it. ParaView, CMB and SMTK would benefit > as they'll have less maintenance cost and VTK will have access to pugi. > > On Fri, Jul 6, 2018 at 9:20 PM Patrick Bergeron > wrote: > >> Have you guys tried profiling what happens during those 2 minutes? >> >> > On Jul 6, 2018, at 17:56, Elvis Stansvik >> wrote: >> > >> > 2018-07-06 23:26 GMT+02:00 Jonathan Borduas < >> jonathan.borduas at caboma.com>: >> >> Hi, >> >> >> >> Here?s a large xml (paraview statefile with 200+ sphere). It weighs >> 17.5 MB. >> >> It takes 1-2 minutes to load with pugixml 1.4 on ParaView. >> > >> > Indeed, this seem like a long time. Do you mind filing a bug report and > attaching the state file. Not sure what is the reason for this. > > >> > Alright. That shows the time of XML parsing is minuscule compared to >> > other things in that use case. That file parses in < 400 ms with >> > libxml2 here, and I guess pugixml would be even faster. > > > >> > Elvis >> > >> >> >> >> >> >> >> >> Best, >> >> >> >> >> >> >> >> Jonathan Borduas >> >> >> >> >> >> >> >> From: vtk-developers On >> Behalf >> >> Of Dan Lipsa >> >> Sent: Friday, July 06, 2018 4:59 PM >> >> To: elvis.stansvik at orexplore.com >> >> Cc: VTK Developers >> >> Subject: Re: [vtk-developers] Add pugixml to VTK >> >> >> >> >> >> >> >> >> >> >> >> >> >> Alright. Maybe this could actually benefit from being done in a >> >> streaming fashion (? la libxml2's reader API)? Or will it be >> >> beneficial/easier to have access to the whole DOM in memory? >> >> >> >> >> >> >> >> You are right - it could be implemented in streaming fashion. >> >> >> >> I think the trade off is >> >> >> >> - streaming: slower than dom, less memory than dom, possibly more >> >> complicated as you may need to store data for later. >> >> >> >> - dom: quickest, more memory than streaming, simplest way to access >> citygml >> >> data. >> >> >> >> >> >> >> >> For now I lean toward dom as our input data is tiled to start with so I >> >> don't expect really large files. I realize I have to revise the specs >> of the >> >> problem: >> >> >> >> I'll need to parse many medium size XML files. >> >> >> >> Dan >> >> >> >> >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > 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 mhalle at bwh.harvard.edu Wed Oct 17 22:06:15 2018 From: mhalle at bwh.harvard.edu (Halle, Michael Wilfred,Ph.D.) Date: Thu, 18 Oct 2018 02:06:15 +0000 Subject: [vtk-developers] please support the Open Anatomy Project: vote for funding! Message-ID: <81059E99-D9AB-44AE-95C2-F070B68B7ED7@bwh.harvard.edu> Dear VTK community, I wanted to write to you to ask your support for the Open Anatomy Project, which is the result of the medical imaging analysis and open source software development work done over the last 25 years at the Surgical Planning Lab at Brigham and Women's Hospital. If you haven't seen it yet, please visit: https://openanatomy.org (While you are there, please vote for the Open Anatomy Project as part of a BWH research prize. Anyone can vote! Tell your friends!) We are building ways to publish annotated, structured image and geometry data, the underlying data representation of anatomy atlases but also a great way to represent lots of meaningful visualization data. The tools we are developing include an atlas data format, web-based data viewers, and a backend community portal for developing collaborative atlases. Once completed, we hope to have "one button export" from VTK-based applications such as 3D Slicer to produce atlases that can then be published for easy viewing and data reuse. The portal site will offer Wikipedia-like user access to atlases and a vaguely GitHub-like developer experience. We are publishing atlases that we have developed over the years, but that's just the start. We want to build up a rich library of atlases, the pieces of which can be used for any purpose (3D printing, VR, ...). This site ultimately will be one-stop shopping for medical atlases of all sorts, including normal anatomy, anatomical variations, pathology, and surgical plans. We already using these atlases for educational outreach around the globe. For instance, we are working with African medical partners to develop medical classroom materials to teach the next generation of African medical students. This is a grand but important vision. We are just at the beginning of this project. But the success of the VTK, ITK, and Slicer communities proves to us that vibrant communities can emerge around meaningful software and data projects. Your help is welcome! Could you please vote for our project by following the "Vote" link when you visit our home page at https://openanatomy.org ? It will help us secure next year's funding and raise the profile of the project. Thanks so much. Michael Halle Ron Kikinis and the rest of the Open Anatomy Team. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. From ken.martin at kitware.com Thu Oct 18 08:52:08 2018 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 18 Oct 2018 08:52:08 -0400 Subject: [vtk-developers] Eeloo Failing Test Message-ID: On eeloo we seem to quite often have this test fail vtkGUISupportQtCxx-TestQVTKOpenGLWidgetPicking is someone willing to track this down and try fixing it? Not sure how much we care about it. If not then we should suppress it for this platform. Thanks! Ken -- 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 mathieu.westphal at kitware.com Thu Oct 18 09:41:29 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 18 Oct 2018 15:41:29 +0200 Subject: [vtk-developers] Eeloo Failing Test In-Reply-To: References: Message-ID: I will try to track it down. Mathieu Westphal On Thu, Oct 18, 2018 at 2:52 PM Ken Martin wrote: > On eeloo we seem to quite often have this test fail > > vtkGUISupportQtCxx-TestQVTKOpenGLWidgetPicking > > > is someone willing to track this down and try fixing it? Not sure how > much we care about it. > > If not then we should suppress it for this platform. > > Thanks! > Ken > > > -- > 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. > _______________________________________________ > 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 aron.helser at kitware.com Thu Oct 18 16:31:31 2018 From: aron.helser at kitware.com (Aron Helser) Date: Thu, 18 Oct 2018 16:31:31 -0400 Subject: [vtk-developers] vtk test data for remote module? Message-ID: I have a collaborator working with a VTK remote module (MomentInvariants). It so happens that this code was previously part of VTK proper, and was moved to a remote module. It includes some tests, with external test data. We now need to update the test data, and so are trying to change from md5 to sha512, as instructed here: https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md The cmake and build parts work just as they used to, but unfortunately the git parts, like the pre-commit hook and the gitlab-push command are no longer available in the remote module, since it lives in it's own repository. Has anyone dealt with this before? What should we do? The data is about 2.7 Mb, so one possibility is to just commit the data directly in the remote repository, I suppose, but I'm not sure how ctest will then interact with it. Thanks! Aron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Thu Oct 18 17:01:11 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 18 Oct 2018 17:01:11 -0400 Subject: [vtk-developers] vtk test data for remote module? In-Reply-To: References: Message-ID: Hi Aaron, > the git parts, like the pre-commit hook and the gitlab-push command are no longer available in the remote module > The data is about 2.7 Mb, so one possibility is to just commit the data directly in the remote repository, I suppose, but I'm not sure how ctest will then interact with it The hook and other bash function are just a convenience, you could upload the file named to Girder and add a template to ensure it can be downloaded. For example, see here That said, if the module vtkExternalData is already included by the remote build buildsysten, uploading the data manually to girder will be sufficient. Hth Jc On Thu, Oct 18, 2018 at 4:33 PM Aron Helser wrote: > I have a collaborator working with a VTK remote module (MomentInvariants). > It so happens that this code was previously part of VTK proper, and was > moved to a remote module. It includes some tests, with external test data. > We now need to update the test data, and so are trying to change from md5 > to sha512, as instructed here: > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md > > The cmake and build parts work just as they used to, but unfortunately the > git parts, like the pre-commit hook and the gitlab-push command are no > longer available in the remote module, since it lives in it's own > repository. > > Has anyone dealt with this before? What should we do? > > The data is about 2.7 Mb, so one possibility is to just commit the data > directly in the remote repository, I suppose, but I'm not sure how ctest > will then interact with it. > > Thanks! > Aron > _______________________________________________ > 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 aron.helser at kitware.com Thu Oct 18 18:04:13 2018 From: aron.helser at kitware.com (Aron Helser) Date: Thu, 18 Oct 2018 18:04:13 -0400 Subject: [vtk-developers] vtk test data for remote module? In-Reply-To: References: Message-ID: Jc, The remote module is built as part of VTK, so it is already using vtkExternalData. Looking at those lines you referenced: > # Data published by Girder > "https://data.kitware.com/api/v1/file/hashsum/%(algo)/%(hash)/download" > # Data published by developers using git-gitlab-push. > "https://www.vtk.org/files/ExternalData/%(algo)/%(hash)" That means I can provide the files at that URL at data.kitware.com? How do I do that? On Thu, Oct 18, 2018 at 5:01 PM Jean-Christophe Fillion-Robin < jcfr at kitware.com> wrote: > Hi Aaron, > > > the git parts, like the pre-commit hook and the gitlab-push command are > no longer available in the remote module > > The data is about 2.7 Mb, so one possibility is to just commit the data > directly in the remote repository, I suppose, but I'm not sure how ctest > will then interact with it > > The hook and other bash function are just a convenience, you could upload > the file named to Girder and add a template to ensure it can be downloaded. > For example, see here > > That said, if the module vtkExternalData is already included by the remote > build buildsysten, uploading the data manually to girder will be sufficient. > > Hth > Jc > > > On Thu, Oct 18, 2018 at 4:33 PM Aron Helser > wrote: > >> I have a collaborator working with a VTK remote module >> (MomentInvariants). It so happens that this code was previously part of VTK >> proper, and was moved to a remote module. It includes some tests, with >> external test data. We now need to update the test data, and so are trying >> to change from md5 to sha512, as instructed here: >> https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md >> >> The cmake and build parts work just as they used to, but unfortunately >> the git parts, like the pre-commit hook and the gitlab-push command are no >> longer available in the remote module, since it lives in it's own >> repository. >> >> Has anyone dealt with this before? What should we do? >> >> The data is about 2.7 Mb, so one possibility is to just commit the data >> directly in the remote repository, I suppose, but I'm not sure how ctest >> will then interact with it. >> >> Thanks! >> Aron >> _______________________________________________ >> 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 Fri Oct 19 07:39:10 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 19 Oct 2018 07:39:10 -0400 Subject: [vtk-developers] vtk test data for remote module? In-Reply-To: References: Message-ID: <20181019113910.GA11282@rotor.localdomain> On Thu, Oct 18, 2018 at 18:04:13 -0400, Aron Helser wrote: > > # Data published by Girder > > "https://data.kitware.com/api/v1/file/hashsum/%(algo)/%(hash)/download" > > # Data published by developers using git-gitlab-push. > > "https://www.vtk.org/files/ExternalData/%(algo)/%(hash)" > > That means I can provide the files at that URL at data.kitware.com? How do > I do that? I believe the `hashsum` plugin for Girder looks through all public (or private if authenticated) data for files with the given hash, so as long as it is public somewhere on `data.kitware.com`, it should be available to VTK as well. --Ben From aron.helser at kitware.com Fri Oct 19 10:05:35 2018 From: aron.helser at kitware.com (Aron Helser) Date: Fri, 19 Oct 2018 10:05:35 -0400 Subject: [vtk-developers] vtk test data for remote module? In-Reply-To: <20181019113910.GA11282@rotor.localdomain> References: <20181019113910.GA11282@rotor.localdomain> Message-ID: Thanks! It all seems to be working. I uploaded all the data we needed to my public directory, https://data.kitware.com/#user/575742dc8d777f68be8f3fb3/folder/5bc9d1138d777f06b92d9d27 and now the vtk build is able to find it. I'll add a link back to this thread in https://www.vtk.org/Wiki/VTK/Remote_Modules Thanks, Aron On Fri, Oct 19, 2018 at 7:39 AM Ben Boeckel wrote: > On Thu, Oct 18, 2018 at 18:04:13 -0400, Aron Helser wrote: > > > # Data published by Girder > > > "https://data.kitware.com/api/v1/file/hashsum/%(algo)/%(hash)/download > " > > > # Data published by developers using git-gitlab-push. > > > "https://www.vtk.org/files/ExternalData/%(algo)/%(hash)" > > > > That means I can provide the files at that URL at data.kitware.com? > How do > > I do that? > > I believe the `hashsum` plugin for Girder looks through all public (or > private if authenticated) data for files with the given hash, so as > long as it is public somewhere on `data.kitware.com`, it should be > available to VTK as well. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Fri Oct 19 15:58:46 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 19 Oct 2018 15:58:46 -0400 Subject: [vtk-developers] vtk test data for remote module? In-Reply-To: References: <20181019113910.GA11282@rotor.localdomain> Message-ID: Hi Aron, This documentation maintained by ITK community is particularly useful to explain how to upload data and get the content link file: See https://itk.org/ITKExamples/Documentation/Contribute/UploadBinaryData.html It may be sensible to also reference it. Hth Jc On Fri, Oct 19, 2018 at 10:07 AM Aron Helser wrote: > Thanks! It all seems to be working. > I uploaded all the data we needed to my public directory, > https://data.kitware.com/#user/575742dc8d777f68be8f3fb3/folder/5bc9d1138d777f06b92d9d27 > and now the vtk build is able to find it. > > I'll add a link back to this thread in > https://www.vtk.org/Wiki/VTK/Remote_Modules > Thanks, > Aron > > On Fri, Oct 19, 2018 at 7:39 AM Ben Boeckel > wrote: > >> On Thu, Oct 18, 2018 at 18:04:13 -0400, Aron Helser wrote: >> > > # Data published by Girder >> > > " >> https://data.kitware.com/api/v1/file/hashsum/%(algo)/%(hash)/download" >> > > # Data published by developers using git-gitlab-push. >> > > "https://www.vtk.org/files/ExternalData/%(algo)/%(hash)" >> > >> > That means I can provide the files at that URL at data.kitware.com? >> How do >> > I do that? >> >> I believe the `hashsum` plugin for Girder looks through all public (or >> private if authenticated) data for files with the given hash, so as >> long as it is public somewhere on `data.kitware.com`, it should be >> available to VTK as well. >> >> --Ben >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Oct 20 11:48:54 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 20 Oct 2018 08:48:54 -0700 Subject: [vtk-developers] Hackathon: Spreadsheet of VTK/Examples Message-ID: Folks, This spreadsheet shows the status of code in VTK/Examples/. Green means Cxx and Python examples exist in the VTKExamples repo. Yellow means either a Cxx or Python example exists. Bill VTK Examples - https://docs.google.com/spreadsheets/d/1eH5TbWEQoZ9OrGpNwIdgZNV6-X3ghz357WQdRas-JQc/edit?usp=sharing From bill.lorensen at gmail.com Mon Oct 22 16:34:28 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 22 Oct 2018 13:34:28 -0700 Subject: [vtk-developers] Hackathon: Book update Message-ID: I'd like to have 15 minutes to give a book update. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Oct 23 00:52:49 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 22 Oct 2018 21:52:49 -0700 Subject: [vtk-developers] Hackathon links Message-ID: Here are some useful links for tomorrow's hackathon VTK Books Latex - https://raw.githubusercontent.com/lorensen/VTKExamples/master/src/VTKBookLaTeX/VTKTextBook.pdf Markdown - https://lorensen.github.io/VTKExamples/site/VTKBook/00Preface/-- Unpaid intern in BillsParadise at noware dot com VTK/Examples - https://docs.google.com/spreadsheets/d/1eH5TbWEQoZ9OrGpNwIdgZNV6-X3ghz357WQdRas-JQc/edit#gid=0 See you at 10, 7 my time... Bill From ben.boeckel at kitware.com Tue Oct 23 10:48:32 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 23 Oct 2018 10:48:32 -0400 Subject: [vtk-developers] Triage of issues with reproducer examples Message-ID: <20181023144832.GA13216@rotor.localdomain> Hi, I'm going through and triaging issues. There are a lot of issues with reproducer examples: https://gitlab.kitware.com/vtk/vtk/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=triage%3Ahasexample&assignee_id=0 It'd be great if we could divvy up verifying the issues and seeing if the example code still shows the mentioned problem. If the issue isn't seen, I'd just close it as "maybe fixed in master" with a note to reopen if that's not the case. Thanks, --Ben From mathieu.westphal at kitware.com Wed Oct 24 12:38:59 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 24 Oct 2018 18:38:59 +0200 Subject: [vtk-developers] Eeloo Failing Test In-Reply-To: References: Message-ID: For some reason the actor can't pick any actor at certain position. Hard to say if this is important or not. I'm unable to reproduce locally. Someone with access to eeloo will need to tackle this. Best, Mathieu Westphal On Thu, Oct 18, 2018 at 3:41 PM Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > I will try to track it down. > > Mathieu Westphal > > > On Thu, Oct 18, 2018 at 2:52 PM Ken Martin wrote: > >> On eeloo we seem to quite often have this test fail >> >> vtkGUISupportQtCxx-TestQVTKOpenGLWidgetPicking >> >> >> is someone willing to track this down and try fixing it? Not sure how >> much we care about it. >> >> If not then we should suppress it for this platform. >> >> Thanks! >> Ken >> >> >> -- >> 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. >> _______________________________________________ >> 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 ken.martin at kitware.com Fri Oct 26 08:43:57 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 26 Oct 2018 08:43:57 -0400 Subject: [vtk-developers] dejagore Message-ID: Any clue what is up with dejagore? It started failing between 8:16am and 10:36am yesterday morning Eastern time. ALL topics started failing at that point so I doubt it is a VTK MR but rather a system change etc. The failing tests seem to have something to do with gl2s or pdf files. Any takers? -- 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 ben.boeckel at kitware.com Fri Oct 26 10:08:39 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 26 Oct 2018 10:08:39 -0400 Subject: [vtk-developers] dejagore In-Reply-To: References: Message-ID: <20181026140839.GA12009@rotor.localdomain> On Fri, Oct 26, 2018 at 08:43:57 -0400, Ken Martin wrote: > Any clue what is up with dejagore? It started failing between 8:16am and > 10:36am yesterday morning Eastern time. ALL topics started failing at that > point so I doubt it is a VTK MR but rather a system change etc. The failing > tests seem to have something to do with gl2s or pdf files. Any takers? >From what I saw, it just didn't have (a properly configured) X running anymore. Meant to tell Rob that yesterday, but he had already left by that point. Headed over now. --Ben From robert.maynard at kitware.com Fri Oct 26 10:16:38 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 26 Oct 2018 10:16:38 -0400 Subject: [vtk-developers] dejagore In-Reply-To: <20181026140839.GA12009@rotor.localdomain> References: <20181026140839.GA12009@rotor.localdomain> Message-ID: <6CF11EBF-FFB8-4F5B-9871-E29AA296C3E5@kitware.com> The machine required a reboot yesterday for a kernel update and that looks to have been part of the issue. > On Oct 26, 2018, at 10:08 AM, Ben Boeckel wrote: > >> On Fri, Oct 26, 2018 at 08:43:57 -0400, Ken Martin wrote: >> Any clue what is up with dejagore? It started failing between 8:16am and >> 10:36am yesterday morning Eastern time. ALL topics started failing at that >> point so I doubt it is a VTK MR but rather a system change etc. The failing >> tests seem to have something to do with gl2s or pdf files. Any takers? > > From what I saw, it just didn't have (a properly configured) X running > anymore. Meant to tell Rob that yesterday, but he had already left by > that point. Headed over now. > > --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 robert.maynard at kitware.com Fri Oct 26 11:07:29 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 26 Oct 2018 11:07:29 -0400 Subject: [vtk-developers] dejagore In-Reply-To: <6CF11EBF-FFB8-4F5B-9871-E29AA296C3E5@kitware.com> References: <20181026140839.GA12009@rotor.localdomain> <6CF11EBF-FFB8-4F5B-9871-E29AA296C3E5@kitware.com> Message-ID: Dejagore is now running correctly On Fri, Oct 26, 2018 at 10:16 AM Robert Maynard wrote: > > The machine required a reboot yesterday for a kernel update and that looks to have been part of the issue. > > > On Oct 26, 2018, at 10:08 AM, Ben Boeckel wrote: > > > >> On Fri, Oct 26, 2018 at 08:43:57 -0400, Ken Martin wrote: > >> Any clue what is up with dejagore? It started failing between 8:16am and > >> 10:36am yesterday morning Eastern time. ALL topics started failing at that > >> point so I doubt it is a VTK MR but rather a system change etc. The failing > >> tests seem to have something to do with gl2s or pdf files. Any takers? > > > > From what I saw, it just didn't have (a properly configured) X running > > anymore. Meant to tell Rob that yesterday, but he had already left by > > that point. Headed over now. > > > > --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 ken.martin at kitware.com Fri Oct 26 11:10:37 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 26 Oct 2018 11:10:37 -0400 Subject: [vtk-developers] dejagore In-Reply-To: References: <20181026140839.GA12009@rotor.localdomain> <6CF11EBF-FFB8-4F5B-9871-E29AA296C3E5@kitware.com> Message-ID: Thanks! On Fri, Oct 26, 2018 at 11:07 AM, Robert Maynard wrote: > Dejagore is now running correctly > On Fri, Oct 26, 2018 at 10:16 AM Robert Maynard > wrote: > > > > The machine required a reboot yesterday for a kernel update and that > looks to have been part of the issue. > > > > > On Oct 26, 2018, at 10:08 AM, Ben Boeckel > wrote: > > > > > >> On Fri, Oct 26, 2018 at 08:43:57 -0400, Ken Martin wrote: > > >> Any clue what is up with dejagore? It started failing between 8:16am > and > > >> 10:36am yesterday morning Eastern time. ALL topics started failing > at that > > >> point so I doubt it is a VTK MR but rather a system change etc. The > failing > > >> tests seem to have something to do with gl2s or pdf files. Any takers? > > > > > > From what I saw, it just didn't have (a properly configured) X running > > > anymore. Meant to tell Rob that yesterday, but he had already left by > > > that point. Headed over now. > > > > > > --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 > > > > -- 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 ben.boeckel at kitware.com Mon Oct 29 12:07:20 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 12:07:20 -0400 Subject: [vtk-developers] New module system preview Message-ID: <20181029160720.GA3379@rotor.localdomain> Hi all, I've gotten the new module system to a point that I'd like to open up testing to other developers. It's not 100% complete (see the known issues listing below), but it's pretty close. I'd highly recommend using a new build tree for building the branch. Notes for WIP things on the branch: - There's a hard-coded list of "don't build this" in CMakeLists.txt currently just for my convenience. Feel free to edit the `REJECT_MODULES` argument list as needed for your machine(s). Overview of changes: - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` files. These are basically CMake argument lists, but no variable expansion is allowed. If there are optional dependencies, they must be private dependencies. Optional public dependencies indicate that a new module should be made instead. - Modules may now be "rejected" and never built. This turns off *dependent* modules. If a module is required and also has a rejected module as a dependency, an error occurs. - Minimum CMake is still 3.3, but kit support requires CMake 3.12+ for object library features. - There are no more `vtk_mpi_link` or `vtk_opengl_link` "magic" functions. Instead, just depend on the `VTK::mpi` and `VTK::opengl` modules. - Third party modules now declare whether they support external copies or not (i.e., no more useless `VTK_USE_SYSTEM_kwsys` variable). See the `ThirdParty` directory for various examples. Other third parties only support external copies (e.g., `VTK::mpi` and `VTK::opengl`). - Imported targets are now preferred for `find_package` callers. Third party packages warn about this usage, but others do not. There is also the `vtk_module_find_package` call which also adds required `find_package` calls to the `vtk-config.cmake` file for external consumers (only necessary when using imported targets). - Module names now look like `VTK::CommonCore`. This is a target name which can be used anywhere, within or outside of the VTK source tree. Non-module projects now do: ```cmake # Find VTK. find_package(VTK REQUIRED COMPONENTS CommonCore) # Make two programs. add_executable(myexe1 myexe1.c) add_executable(myexe2 myexe2.c) # Add include directories, link line, compile definitions, etc. # necessary to use VTK::CommonCore. target_link_libraries(myexe1 PRIVATE VTK::CommonCore) target_link_libraries(myexe2 PRIVATE VTK::CommonCore) # Add VTK_AUTOINIT defines to the targets. vtk_module_autoinit(TARGETS myexe1 myexe2 MODULES VTK::CommonCore) ``` - To add requirements to a module, the module system offers some functions in lieu of CMake's `target_*`. This is in order to properly support kits (the `CommonCore` target is just an `INTERFACE` library in this case and `PRIVATE` link libraries need copied onto the containing kit). The functions: * `vtk_module_compile_options` * `vtk_module_definitions` * `vtk_module_include` * `vtk_module_link` * `vtk_module_link_options` (depends on `target_link_options` in CMake 3.13+) It is currently based on `master` as of a week ago, but I'll probably rebase again this week. Please file issues found with the branch on my fork of VTK: https://gitlab.kitware.com/ben.boeckel/vtk/issues to make things easier to track. Since Gitlab doesn't support MRs between sibling forks (yet), please attach patches to issues if you have a fix. Known issues: - Running generated Java wrappers needs some attention. Missing symbols (from Java code?) happen when running the tests. - Windows support (there are some `:` characters left in filenames yet). Unimplemented: - Remote modules (conceptually the same as before, but there are no remote modules that have been ported right now) - `OPTIONAL_PYTHON_LINK` magic keyword. This can now just be supported in the `VTK::Python` module, but has not been implemented. Untested: - Multi-config generators (e.g., Xcode and Visual Studio). - Mobile device support. Thanks, --Ben From ben.boeckel at kitware.com Mon Oct 29 12:43:21 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 12:43:21 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029160720.GA3379@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> Message-ID: <20181029164321.GB3379@rotor.localdomain> On Mon, Oct 29, 2018 at 12:07:20 -0400, Ben Boeckel wrote: > I've gotten the new module system to a point that I'd like to open up > testing to other developers. It's not 100% complete (see the known > issues listing below), but it's pretty close. I'd highly recommend using > a new build tree for building the branch. It occurs to me that I forgot to add a link to the actual code: https://gitlab.kitware.com/ben.boeckel/vtk/tree/new-cmake-module --Ben From bill.lorensen at gmail.com Mon Oct 29 13:01:34 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 29 Oct 2018 10:01:34 -0700 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029164321.GB3379@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <20181029164321.GB3379@rotor.localdomain> Message-ID: Will the old module system still work? On Mon, Oct 29, 2018, 9:43 AM Ben Boeckel On Mon, Oct 29, 2018 at 12:07:20 -0400, Ben Boeckel wrote: > > I've gotten the new module system to a point that I'd like to open up > > testing to other developers. It's not 100% complete (see the known > > issues listing below), but it's pretty close. I'd highly recommend using > > a new build tree for building the branch. > > It occurs to me that I forgot to add a link to the actual code: > > https://gitlab.kitware.com/ben.boeckel/vtk/tree/new-cmake-module > > --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 elvis.stansvik at orexplore.com Mon Oct 29 13:13:43 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 Oct 2018 18:13:43 +0100 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029160720.GA3379@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> Message-ID: Fantastic work Ben. One question below. Den m?n 29 okt. 2018 17:07Ben Boeckel skrev: > Hi all, > > I've gotten the new module system to a point that I'd like to open up > testing to other developers. It's not 100% complete (see the known > issues listing below), but it's pretty close. I'd highly recommend using > a new build tree for building the branch. > > Notes for WIP things on the branch: > > - There's a hard-coded list of "don't build this" in CMakeLists.txt > currently just for my convenience. Feel free to edit the > `REJECT_MODULES` argument list as needed for your machine(s). > > Overview of changes: > > - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` > files. These are basically CMake argument lists, but no variable > expansion is allowed. If there are optional dependencies, they must > be private dependencies. Optional public dependencies indicate that > a new module should be made instead. > > - Modules may now be "rejected" and never built. This turns off > *dependent* modules. If a module is required and also has a rejected > module as a dependency, an error occurs. > > - Minimum CMake is still 3.3, but kit support requires CMake 3.12+ for > object library features. > > - There are no more `vtk_mpi_link` or `vtk_opengl_link` "magic" > functions. Instead, just depend on the `VTK::mpi` and `VTK::opengl` > modules. > > - Third party modules now declare whether they support external copies > or not (i.e., no more useless `VTK_USE_SYSTEM_kwsys` variable). See > the `ThirdParty` directory for various examples. Other third parties > only support external copies (e.g., `VTK::mpi` and `VTK::opengl`). > > - Imported targets are now preferred for `find_package` callers. Third > party packages warn about this usage, but others do not. There is > also the `vtk_module_find_package` call which also adds required > `find_package` calls to the `vtk-config.cmake` file for external > consumers (only necessary when using imported targets). > > - Module names now look like `VTK::CommonCore`. This is a target name > which can be used anywhere, within or outside of the VTK source > tree. Non-module projects now do: > > ```cmake > # Find VTK. > find_package(VTK REQUIRED COMPONENTS CommonCore) > # Make two programs. > add_executable(myexe1 myexe1.c) > add_executable(myexe2 myexe2.c) > # Add include directories, link line, compile definitions, etc. > # necessary to use VTK::CommonCore. > target_link_libraries(myexe1 PRIVATE VTK::CommonCore) > target_link_libraries(myexe2 PRIVATE VTK::CommonCore) > # Add VTK_AUTOINIT defines to the targets. > vtk_module_autoinit(TARGETS myexe1 myexe2 MODULES VTK::CommonCore) > Can this not be brought in automatically via the target's interface definitions? With the current setup, I'm getting them via ${VTK_DEFINITIONS} I think. Would be nice to avoid the repeated target name. Elvis ``` > > - To add requirements to a module, the module system offers some > functions in lieu of CMake's `target_*`. This is in order to > properly support kits (the `CommonCore` target is just an > `INTERFACE` library in this case and `PRIVATE` link libraries need > copied onto the containing kit). The functions: > * `vtk_module_compile_options` > * `vtk_module_definitions` > * `vtk_module_include` > * `vtk_module_link` > * `vtk_module_link_options` (depends on `target_link_options` in > CMake 3.13+) > > It is currently based on `master` as of a week ago, but I'll probably > rebase again this week. > > Please file issues found with the branch on my fork of VTK: > > https://gitlab.kitware.com/ben.boeckel/vtk/issues > > to make things easier to track. Since Gitlab doesn't support MRs between > sibling forks (yet), please attach patches to issues if you have a fix. > > Known issues: > > - Running generated Java wrappers needs some attention. Missing > symbols (from Java code?) happen when running the tests. > - Windows support (there are some `:` characters left in filenames > yet). > > Unimplemented: > > - Remote modules (conceptually the same as before, but there are no > remote modules that have been ported right now) > - `OPTIONAL_PYTHON_LINK` magic keyword. This can now just be supported > in the `VTK::Python` module, but has not been implemented. > > Untested: > > - Multi-config generators (e.g., Xcode and Visual Studio). > - Mobile device support. > > Thanks, > > --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 ben.boeckel at kitware.com Mon Oct 29 13:32:49 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 13:32:49 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> Message-ID: <20181029173249.GA24794@rotor.localdomain> On Mon, Oct 29, 2018 at 18:13:43 +0100, Elvis Stansvik wrote: > > # Add VTK_AUTOINIT defines to the targets. > > vtk_module_autoinit(TARGETS myexe1 myexe2 MODULES VTK::CommonCore) > > > > Can this not be brought in automatically via the target's interface > definitions? No, because the set of AUTOINIT defines depends on the modules you link. Linking `VTK::ChemistryOpenGL2` and `VTK::ParallelChemistry` gives a different AUTOINIT define than just linking `VTK::ChemistryOpenGL2`. > With the current setup, I'm getting them via ${VTK_DEFINITIONS} I think. This is true. Currently, it is for all modules that VTK is told to find. > Would be nice to avoid the repeated target name. I think instead of `MODULES`, it might be possible to instead rummage around in the link properties of the passed targets. However, looking at the documentation, this is not necessarily trivial to parse: https://cmake.org/cmake/help/latest/prop_tgt/LINK_LIBRARIES.html I'll add a TODO item for it, but I imagine that it will not work for all possible ways to use `target_link_libraries`. --Ben From ben.boeckel at kitware.com Mon Oct 29 13:34:02 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 13:34:02 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <20181029164321.GB3379@rotor.localdomain> Message-ID: <20181029173402.GB24794@rotor.localdomain> On Mon, Oct 29, 2018 at 10:01:34 -0700, Bill Lorensen wrote: > Will the old module system still work? No, it is completely removed on the branch. This is mainly because the old module system doesn't support imported targets at all (e.g., it assumes that non-module dependencies are filesystem paths). --Ben From david.thompson at kitware.com Mon Oct 29 13:57:02 2018 From: david.thompson at kitware.com (David Thompson) Date: Mon, 29 Oct 2018 13:57:02 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029160720.GA3379@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> Message-ID: <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> Hi Ben, I'm really looking forward to imported targets! > - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` > files. These are basically CMake argument lists, but no variable > expansion is allowed. If there are optional dependencies, they must > be private dependencies. Optional public dependencies indicate that > a new module should be made instead. Is there a reason these things need to be separate files (vtk.module/vtk.kit) at all? Thanks, David From bill.lorensen at gmail.com Mon Oct 29 13:57:10 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 29 Oct 2018 10:57:10 -0700 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029173402.GB24794@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <20181029164321.GB3379@rotor.localdomain> <20181029173402.GB24794@rotor.localdomain> Message-ID: Will I be able to support both old and new? On Mon, Oct 29, 2018, 10:34 AM Ben Boeckel On Mon, Oct 29, 2018 at 10:01:34 -0700, Bill Lorensen wrote: > > Will the old module system still work? > > No, it is completely removed on the branch. This is mainly because the > old module system doesn't support imported targets at all (e.g., it > assumes that non-module dependencies are filesystem paths). > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Oct 29 14:05:24 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 14:05:24 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> Message-ID: <20181029180524.GA6078@rotor.localdomain> On Mon, Oct 29, 2018 at 13:57:02 -0400, David Thompson wrote: > I'm really looking forward to imported targets! > > > - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` > > files. These are basically CMake argument lists, but no variable > > expansion is allowed. If there are optional dependencies, they must > > be private dependencies. Optional public dependencies indicate that > > a new module should be made instead. > > Is there a reason these things need to be separate files > (vtk.module/vtk.kit) at all? The `vtk.kit` declares a kit. Membership into a kit is via `vtk.module`. Example `vtk.kit`: ``` NAME VTK::Common LIBRARY_NAME vtkCommon DESCRIPTION Core utilities for VTK. ``` and `vtk.module`: ``` NAME VTK::CommonCore LIBRARY_NAME vtkCommonCore DESCRIPTION The base VTK library. KIT VTK::Common GROUPS StandAlone DEPENDS VTK::kwiml VTK::vtksys PRIVATE_DEPENDS VTK::utf8 TEST_DEPENDS VTK::CommonSystem VTK::CommonTransforms VTK::TestingCore VTK::vtksys ``` --Ben From ben.boeckel at kitware.com Mon Oct 29 14:18:50 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 14:18:50 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <20181029164321.GB3379@rotor.localdomain> <20181029173402.GB24794@rotor.localdomain> Message-ID: <20181029181850.GB6078@rotor.localdomain> On Mon, Oct 29, 2018 at 10:57:10 -0700, Bill Lorensen wrote: > Will I be able to support both old and new? As a consumer of modules is much easier than as a module. The variable names which control things are completely different (now "namespaced" via naming conventions). `find_package(VTK)` is similar as long as `VTK_LIBRARIES` was used and components are specified, but the old module's CMake API is gone. Old "is X enabled" detection (though this shouldn't be necessary in general[1]): ```cmake if (Module_X) ``` New: ```cmake if (TARGET X) ``` But, the module names are also different now in the new VTK as well, so that makes consuming harder (though predictable). Building a library used to be: ```cmake vtk_module_library(X ${srcs}) ``` and now has a much richer API: ```cmake vtk_module_add_module(X SOURCES ${srcs} HEADERS ${headers} PRIVATE_HEADERS ${private_headers}) ``` though there is also `CLASSES` which does the de-facto standard `.cxx`/`.h` pairing for `SOURCES` and `HEADERS` automatically. In addition to the ineffectiveness of `target_*` functions on module names due to the kits implementation, making a module which supports both APIs is not going to be trivial. --Ben [1]Optional dependencies now pass `-DVTK_MODULE_ENABLE_X=` as 1 or 0 if available where `X` is a "safe" name for the module (basically `::` replaced by `_`). This is to promote `#if` rather than `#ifdef` usage for optional dependency detection in C++ code which triggers errors if present in public headers (though in consuming targets) and also triggers warnings if the optional dependency is removed or made non-optional (because the define is no longer present). From david.thompson at kitware.com Mon Oct 29 14:23:27 2018 From: david.thompson at kitware.com (David Thompson) Date: Mon, 29 Oct 2018 14:23:27 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029180524.GA6078@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> Message-ID: >>> - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` >>> files. These are basically CMake argument lists, but no variable >>> expansion is allowed. If there are optional dependencies, they must >>> be private dependencies. Optional public dependencies indicate that >>> a new module should be made instead. >> >> Is there a reason these things need to be separate files >> (vtk.module/vtk.kit) at all? > > The `vtk.kit` declares a kit. Membership into a kit is via `vtk.module`. > Example `vtk.kit`: Yes, but why can't these declarations for modules and kits be inside CMakeLists.txt as function calls instead of separate files? David From marcus.hanwell at kitware.com Mon Oct 29 14:24:42 2018 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 29 Oct 2018 14:24:42 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> Message-ID: On Mon, Oct 29, 2018 at 2:23 PM David Thompson wrote: > >>> - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` > >>> files. These are basically CMake argument lists, but no variable > >>> expansion is allowed. If there are optional dependencies, they must > >>> be private dependencies. Optional public dependencies indicate that > >>> a new module should be made instead. > >> > >> Is there a reason these things need to be separate files > >> (vtk.module/vtk.kit) at all? > > > > The `vtk.kit` declares a kit. Membership into a kit is via `vtk.module`. > > Example `vtk.kit`: > > Yes, but why can't these declarations for modules and kits be inside > CMakeLists.txt as function calls instead of separate files? > Guessing, but likely because we still use a two-pass approach - scan module/kit files, build up dep list, then actually add the things that are enabled in the second pass. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Oct 29 14:32:41 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 29 Oct 2018 11:32:41 -0700 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029181850.GB6078@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <20181029164321.GB3379@rotor.localdomain> <20181029173402.GB24794@rotor.localdomain> <20181029181850.GB6078@rotor.localdomain> Message-ID: I will need the VTKExamples to support both api's. Also a few remote modules. On Mon, Oct 29, 2018, 11:18 AM Ben Boeckel On Mon, Oct 29, 2018 at 10:57:10 -0700, Bill Lorensen wrote: > > Will I be able to support both old and new? > > As a consumer of modules is much easier than as a module. The variable > names which control things are completely different (now "namespaced" > via naming conventions). `find_package(VTK)` is similar as long as > `VTK_LIBRARIES` was used and components are specified, but the old > module's CMake API is gone. > > Old "is X enabled" detection (though this shouldn't be necessary in > general[1]): > > ```cmake > if (Module_X) > ``` > > New: > > ```cmake > if (TARGET X) > ``` > > But, the module names are also different now in the new VTK as well, so > that makes consuming harder (though predictable). > > Building a library used to be: > > ```cmake > vtk_module_library(X ${srcs}) > ``` > > and now has a much richer API: > > ```cmake > vtk_module_add_module(X > SOURCES ${srcs} > HEADERS ${headers} > PRIVATE_HEADERS ${private_headers}) > ``` > > though there is also `CLASSES` which does the de-facto standard > `.cxx`/`.h` pairing for `SOURCES` and `HEADERS` automatically. In > addition to the ineffectiveness of `target_*` functions on module names > due to the kits implementation, making a module which supports both APIs > is not going to be trivial. > > --Ben > > [1]Optional dependencies now pass `-DVTK_MODULE_ENABLE_X=` as 1 or 0 if > available where `X` is a "safe" name for the module (basically `::` > replaced by `_`). This is to promote `#if` rather than `#ifdef` usage > for optional dependency detection in C++ code which triggers errors if > present in public headers (though in consuming targets) and also > triggers warnings if the optional dependency is removed or made > non-optional (because the define is no longer present). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Oct 29 14:43:35 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 14:43:35 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> Message-ID: <20181029184335.GA21724@rotor.localdomain> On Mon, Oct 29, 2018 at 14:23:27 -0400, David Thompson wrote: > >>> - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` > >>> files. These are basically CMake argument lists, but no variable > >>> expansion is allowed. If there are optional dependencies, they must > >>> be private dependencies. Optional public dependencies indicate that > >>> a new module should be made instead. > >> > >> Is there a reason these things need to be separate files > >> (vtk.module/vtk.kit) at all? > > > > The `vtk.kit` declares a kit. Membership into a kit is via `vtk.module`. > > Example `vtk.kit`: > > Yes, but why can't these declarations for modules and kits be inside > CMakeLists.txt as function calls instead of separate files? There's still a two-pass build pipeline. First is to get the declaration of the modules and build up the dependency graph. There is then a build step which builds modules in dependency order. Unlike the old module system, these steps are now distinct: ```cmake vtk_module_find_modules(vtk_module_files ${vtk_source_directories}) vtk_module_find_kits(vtk_kit_files ${vtk_source_directories}) vtk_module_scan( MODULE_FILES ${vtk_module_files} KIT_FILES ${vtk_kit_files} REQUEST_MODULES ${vtk_requested_modules} REJECT_MODULES ${vtk_rejected_modules} PROVIDES_MODULES vtk_modules PROVIDES_KITS vtk_kits REQUIRES_MODULES vtk_required_modules UNRECOGNIZED_MODULES vtk_unrecognized_modules WANT_BY_DEFAULT ON ENABLE_TESTS DEFAULT) # Check to see if any modules were mentioned that we don't know how to # build. if (vtk_required_modules OR vtk_unrecognized_modules) message(FATAL_ERROR "The following modules were requested or required, but not found: " "${vtk_required_modules};${vtk_unrecognized_modules}.") endif () vtk_module_build( MODULES ${vtk_modules} KITS ${vtk_kits} BUILD_WITH_KITS ${VTK_ENABLE_KITS} INSTALL_EXPORT VTK HEADERS_DESTINATION "include/vtk-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}" CMAKE_DESTINATION "lib/cmake/vtk-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}" LIBRARY_NAME_SUFFIX "${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}" VERSION "${VTK_VERSION}" SOVERSION "1" TEST_DATA_TARGET VTKData TEST_INPUT_DATA_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/Testing" TEST_OUTPUT_DATA_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/ExternalData/Testing") ``` The `scan` step processes dependencies found in the specified module and kit files. This is also where we find out what modules we're actually going to build. Once we have the list, we can then build them (assuming that all mentioned modules actually exist). The reason for the two-phase is to support embedding module-using projects (e.g., VTK in ParaView). ParaView works something like this: ```cmake vtk_module_find_modules(pv_module_files ${pv_source_directories}) vtk_module_find_kits(pv_kit_files ${pv_source_directories}) vtk_module_scan( MODULE_FILES ${pv_module_files} KIT_FILES ${pv_kit_files} REQUEST_MODULES ${pv_requested_modules} REJECT_MODULES ${pv_rejected_modules} PROVIDES_MODULES pv_modules PROVIDES_KITS pv_kits REQUIRES_MODULES pv_required_modules UNRECOGNIZED_MODULES pv_unrecognized_modules ENABLE_TESTS DEFAULT) # Now build VTK modules required by the enabled ParaView modules. # Alternatively, using an external VTK is now just crafting the # appropriate `find_package(VTK)` component list. vtk_module_find_modules(vtk_module_files ${vtk_source_directories}) vtk_module_find_kits(vtk_kit_files ${vtk_source_directories}) vtk_module_scan( MODULE_FILES ${vtk_module_files} KIT_FILES ${vtk_kit_files} REQUEST_MODULES ${pv_required_modules} ${pv_unrecognized_modules} PROVIDES_MODULES vtk_modules PROVIDES_KITS vtk_kits REQUIRES_MODULES vtk_required_modules UNRECOGNIZED_MODULES vtk_unrecognized_modules WANT_BY_DEFAULT OFF HIDE_MODULES_FROM_CACHE ON ENABLE_TESTS DEFAULT) # Check to see if any modules were mentioned that we don't know how to # build. if (vtk_required_modules OR vtk_unrecognized_modules) message(FATAL_ERROR "The following modules were requested or required, but not found: " "${vtk_required_modules};${vtk_unrecognized_modules}.") endif () # Build VTK modules. vtk_module_build( MODULES ${vtk_modules} KITS ${vtk_kits} BUILD_WITH_KITS ${PARAVIEW_ENABLE_KITS} INSTALL_EXPORT VTK HEADERS_DESTINATION "include/paraview-${PARAVIEW_MAJOR_VERSION}.${PARAVIEW_MINOR_VERSION}" CMAKE_DESTINATION "lib/cmake/paraview-${PARAVIEW_MAJOR_VERSION}.${PARAVIEW_MINOR_VERSION}" LIBRARY_NAME_SUFFIX "-pv${PARAVIEW_MAJOR_VERSION}.${PARAVIEW_MINOR_VERSION}" VERSION "${PARAVIEW_VERSION}" SOVERSION "1" TEST_DATA_TARGET ParaViewData TEST_INPUT_DATA_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/VTK/Testing" TEST_OUTPUT_DATA_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/ExternalData/VTK/Testing") # Build ParaView modules. vtk_module_build( MODULES ${pv_modules} KITS ${pv_kits} BUILD_WITH_KITS ${PARAVIEW_ENABLE_KITS} INSTALL_EXPORT ParaView HEADERS_DESTINATION "include/paraview-${PARAVIEW_MAJOR_VERSION}.${PARAVIEW_MINOR_VERSION}" CMAKE_DESTINATION "lib/cmake/paraview-${PARAVIEW_MAJOR_VERSION}.${PARAVIEW_MINOR_VERSION}" LIBRARY_NAME_SUFFIX "-pv${PARAVIEW_MAJOR_VERSION}.${PARAVIEW_MINOR_VERSION}" VERSION "${PARAVIEW_VERSION}" SOVERSION "1" TEST_DATA_TARGET ParaViewData TEST_INPUT_DATA_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/Testing" TEST_OUTPUT_DATA_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/ExternalData/Testing") ``` The no-extra-files approach is what the superbuild has. All code in `CMakeLists.txt` now needs to handle being called twice which breaks things like `cmake_dependent_option` and also means that `configure_file` should be guarded by the appropriate phase. However, the superbuild has a *much* simpler API and is smaller to boot. --Ben From ben.boeckel at kitware.com Mon Oct 29 15:43:24 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 15:43:24 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <20181029164321.GB3379@rotor.localdomain> <20181029173402.GB24794@rotor.localdomain> <20181029181850.GB6078@rotor.localdomain> Message-ID: <20181029194324.GA1336@rotor.localdomain> On Mon, Oct 29, 2018 at 11:32:41 -0700, Bill Lorensen wrote: > I will need the VTKExamples to support both api's. Also a few remote > modules. VTKExamples doesn't look too hard. Looking briefly at the remote modules, they'd likely not be too hard to support both either since they're relatively simple. --Ben From david.thompson at kitware.com Mon Oct 29 15:45:36 2018 From: david.thompson at kitware.com (David Thompson) Date: Mon, 29 Oct 2018 15:45:36 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029184335.GA21724@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> Message-ID: <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> >>>>> - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit` >>>>> files. These are basically CMake argument lists, but no variable >>>>> expansion is allowed. If there are optional dependencies, they must >>>>> be private dependencies. Optional public dependencies indicate that >>>>> a new module should be made instead. >>>> >>>> Is there a reason these things need to be separate files >>>> (vtk.module/vtk.kit) at all? >>> >>> The `vtk.kit` declares a kit. Membership into a kit is via `vtk.module`. >>> Example `vtk.kit`: >> >> Yes, but why can't these declarations for modules and kits be inside >> CMakeLists.txt as function calls instead of separate files? > > There's still a two-pass build pipeline. First is to get the declaration > of the modules and build up the dependency graph. There is then a build > step which builds modules in dependency order. Even if it is two passes, why can't it be done from CMakeLists.txt? The second pass just adds library dependencies, header search paths, other target properties, and install rules, correct? Can't that be done any time after the libraries are declared? It just feels like VTK and ParaView should be "best practices" examples. Your branch gets things a *lot* closer, but some twiddly details (the special .module/.kit files, no use of add_subdirectory, etc) get in the way of someone familiar with CMake but not these projects. David From dave.demarle at kitware.com Mon Oct 29 16:04:29 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 29 Oct 2018 16:04:29 -0400 Subject: [vtk-developers] (no subject) Message-ID: Hi, Does anyone have work in progress that should delay the branch point for VTK 8.2? We would like to branch and start the release candidate cycle for 8.2 now. The top issues that are driving this release are: a desire to deprecate support for Visual Studio 2013 in order to get a more complete c++11 basis, and a desire to start getting Ben's CMake updates tested in master on all of the dashboards. Branching now will let us preserve everyone's improvements in master within an easy to migrate to official release. 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 dave.demarle at kitware.com Mon Oct 29 16:06:26 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 29 Oct 2018 16:06:26 -0400 Subject: [vtk-developers] ready for vtk 8.2 release? In-Reply-To: References: Message-ID: On Mon, Oct 29, 2018 at 4:04 PM David E DeMarle wrote: > Hi, > > Does anyone have work in progress that should delay the branch point for > VTK 8.2? > > We would like to branch and start the release candidate cycle for 8.2 now. > The top issues that are driving this release are: a desire to deprecate > support for Visual Studio 2013 in order to get a more complete c++11 basis, > and a desire to start getting Ben's CMake updates tested in master on all > of the dashboards. Branching now will let us preserve everyone's > improvements in master within an easy to migrate to official release. > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Oct 29 16:42:26 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 16:42:26 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> Message-ID: <20181029204225.GA22076@rotor.localdomain> On Mon, Oct 29, 2018 at 15:45:36 -0400, David Thompson wrote: > Even if it is two passes, why can't it be done from CMakeLists.txt? > The second pass just adds library dependencies, header search paths, > other target properties, and install rules, correct? Can't that be > done any time after the libraries are declared? First, the concept would require `target_link_libraries` support for out-of-directory targets. That can't be done without 3.13.0 (still in its rc cycle). It also means that we wouldn't be able to say "no" to building some modules without somehow "undo"ing an `add_library` call. Second, it's an ease-of-use problem. Say I don't have MPI on my machine. I can't `add_subdirectory` *any* directory which requires `VTK::mpi` because that module can't exist on my machine. How is the module system supposed to know what directories can and cannot be included? If it is `CMakeLists.txt` via `add_subdirectory` or `include`, the structure would end up like: ```cmake if (vtk_module_phase STREQUAL "scan") vtk_module_declare() elseif (vtk_module_phase STREQUAL "build") vtk_module_add_module(...) endif () ``` Third, part of the point of `vtk.module` is so that there *is no logic* allowed. Making it part of `CMakeLists.txt` makes it much harder to enforce this. Though this does make me think that we could stuff the `vtk.module` contents in a comment header of the associated `CMakeLists.txt`. That might be worth looking into. I'll add a TODO item for it. Towards the third point, it was a mistake to allow `${VTK_RENDERING_BACKEND}` in the old module system's `module.cmake` files. VTK should have supported building OpenGL1 *and* OpenGL2 backends at the same time with executables using the object factory mechanism to decide which one gets used. It also meant that some modules had classes popping in and out of existence depending on other flags (e.g., `vtkIOMovie` contains `vtkOggTheoraWriter` depending on whether or not `vtkoggtheora` is available?not something easy to have Just Work via `find_package(VTK)` failing (the new module system now has a `VTK::IOOggTheora` module for this class). > It just feels like VTK and ParaView should be "best practices" > examples. Your branch gets things a *lot* closer, but some twiddly > details (the special .module/.kit files, no use of add_subdirectory, > etc) get in the way of someone familiar with CMake but not these > projects. Unfortunately, things like kits, optional component building, complex dependency graphs, etc. are not "common" and doing them via "best practices" applicable to CMake projects in general isn't easy. IMO, "best practices" would tell me that VTK should be many repositories (or, many top-level builds at least) and each build has *no options* to turn on or off bits of the build (modulo platform support and deprecation). If one wants MPI support, go build the MPI subdirectory and you get VTK MPI support. Granted, there might be a top-level "enable these sections of code" flag which runs all the subprojects like a superbuild, but I don't think the downsides of the superbuild (i.e., ExternalProject) are ignorable for projects with a developer and user community the size of VTK as-is. --Ben From elvis.stansvik at orexplore.com Mon Oct 29 17:31:38 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 Oct 2018 22:31:38 +0100 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029204225.GA22076@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> Message-ID: Den m?n 29 okt. 2018 kl 21:42 skrev Ben Boeckel : > > On Mon, Oct 29, 2018 at 15:45:36 -0400, David Thompson wrote: > > Even if it is two passes, why can't it be done from CMakeLists.txt? > > The second pass just adds library dependencies, header search paths, > > other target properties, and install rules, correct? Can't that be > > done any time after the libraries are declared? > > First, the concept would require `target_link_libraries` support for > out-of-directory targets. That can't be done without 3.13.0 (still in > its rc cycle). It also means that we wouldn't be able to say "no" to > building some modules without somehow "undo"ing an `add_library` call. > > Second, it's an ease-of-use problem. Say I don't have MPI on my machine. > I can't `add_subdirectory` *any* directory which requires `VTK::mpi` > because that module can't exist on my machine. How is the module system > supposed to know what directories can and cannot be included? If it is > `CMakeLists.txt` via `add_subdirectory` or `include`, the structure > would end up like: > > ```cmake > if (vtk_module_phase STREQUAL "scan") > vtk_module_declare() > elseif (vtk_module_phase STREQUAL "build") > vtk_module_add_module(...) > endif () > ``` > > Third, part of the point of `vtk.module` is so that there *is no logic* > allowed. Making it part of `CMakeLists.txt` makes it much harder to > enforce this. Though this does make me think that we could stuff the > `vtk.module` contents in a comment header of the associated > `CMakeLists.txt`. That might be worth looking into. I'll add a TODO item > for it. Let me just jump in and say that while it sounds neat to embed it comments, it might make it slightly harder to make an updated version of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). I kind of like the VTK system with these separate files. Even if it's a bit unorthodox, they're very concise descriptions of the modules. I like how I can do find . -name module.cmake to find all modules, or cat Some/Dir/module.cmake to get info about a module. It's very inspectable using standard tools. It's just my 2 cents though, so take it or leave it :) Elvis > > Towards the third point, it was a mistake to allow > `${VTK_RENDERING_BACKEND}` in the old module system's `module.cmake` > files. VTK should have supported building OpenGL1 *and* OpenGL2 backends > at the same time with executables using the object factory mechanism to > decide which one gets used. It also meant that some modules had classes > popping in and out of existence depending on other flags (e.g., > `vtkIOMovie` contains `vtkOggTheoraWriter` depending on whether or not > `vtkoggtheora` is available?not something easy to have Just Work via > `find_package(VTK)` failing (the new module system now has a > `VTK::IOOggTheora` module for this class). > > > It just feels like VTK and ParaView should be "best practices" > > examples. Your branch gets things a *lot* closer, but some twiddly > > details (the special .module/.kit files, no use of add_subdirectory, > > etc) get in the way of someone familiar with CMake but not these > > projects. > > Unfortunately, things like kits, optional component building, complex > dependency graphs, etc. are not "common" and doing them via "best > practices" applicable to CMake projects in general isn't easy. > > IMO, "best practices" would tell me that VTK should be many repositories > (or, many top-level builds at least) and each build has *no options* to > turn on or off bits of the build (modulo platform support and > deprecation). If one wants MPI support, go build the MPI subdirectory > and you get VTK MPI support. > > Granted, there might be a top-level "enable these sections of code" flag > which runs all the subprojects like a superbuild, but I don't think the > downsides of the superbuild (i.e., ExternalProject) are ignorable for > projects with a developer and user community the size of VTK as-is. > > --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 elvis.stansvik at orexplore.com Mon Oct 29 17:35:04 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 Oct 2018 22:35:04 +0100 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029173249.GA24794@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <20181029173249.GA24794@rotor.localdomain> Message-ID: Den m?n 29 okt. 2018 kl 18:32 skrev Ben Boeckel : > > On Mon, Oct 29, 2018 at 18:13:43 +0100, Elvis Stansvik wrote: > > > # Add VTK_AUTOINIT defines to the targets. > > > vtk_module_autoinit(TARGETS myexe1 myexe2 MODULES VTK::CommonCore) > > > > > > > Can this not be brought in automatically via the target's interface > > definitions? > > No, because the set of AUTOINIT defines depends on the modules you link. > Linking `VTK::ChemistryOpenGL2` and `VTK::ParallelChemistry` gives a > different AUTOINIT define than just linking `VTK::ChemistryOpenGL2`. Aha, thanks for clarifying. I never looked closely at how these things work. It just worked :) Elvis > > > With the current setup, I'm getting them via ${VTK_DEFINITIONS} I think. > > This is true. Currently, it is for all modules that VTK is told to find. > > > Would be nice to avoid the repeated target name. > > I think instead of `MODULES`, it might be possible to instead rummage > around in the link properties of the passed targets. However, looking at > the documentation, this is not necessarily trivial to parse: > > https://cmake.org/cmake/help/latest/prop_tgt/LINK_LIBRARIES.html > > I'll add a TODO item for it, but I imagine that it will not work for all > possible ways to use `target_link_libraries`. > > --Ben From ben.boeckel at kitware.com Mon Oct 29 17:42:11 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 29 Oct 2018 17:42:11 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> Message-ID: <20181029214211.GA16451@rotor.localdomain> On Mon, Oct 29, 2018 at 22:31:38 +0100, Elvis Stansvik wrote: > Let me just jump in and say that while it sounds neat to embed it > comments, it might make it slightly harder to make an updated version > of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). Thanks for the reminder that this file needs updated. CMake supports long-form comments now, so I'd think it'd be in blocks like this: ```cmake #[==[vtk.kit ... #]==] #[==[vtk.module ... #]==] ``` with a limit of one `vtk.module` per file. Easy to slice out with a simple `sed` call. Not so easy in CMake, but also not ridiculous. This is similar to the way the new module system is documented: ```cmake #[==[.md ... #]==] ``` which will make it possible to extract out these blocks and feed them to Doxygen and get the module system API docs on the web with the rest of VTK. There's also `#[==[.md INTERNAL` for internal function documentation as well. --Ben From elvis.stansvik at orexplore.com Mon Oct 29 17:56:10 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 Oct 2018 22:56:10 +0100 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029214211.GA16451@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> Message-ID: Den m?n 29 okt. 2018 kl 22:42 skrev Ben Boeckel : > > On Mon, Oct 29, 2018 at 22:31:38 +0100, Elvis Stansvik wrote: > > Let me just jump in and say that while it sounds neat to embed it > > comments, it might make it slightly harder to make an updated version > > of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). > > Thanks for the reminder that this file needs updated. > > CMake supports long-form comments now, so I'd think it'd be in blocks > like this: > > ```cmake > #[==[vtk.kit > ... > #]==] > #[==[vtk.module > ... > #]==] > ``` > > with a limit of one `vtk.module` per file. Easy to slice out with a > simple `sed` call. Not so easy in CMake, but also not ridiculous. Fair enough, not as simple as a cat, but almost. Elvis > > This is similar to the way the new module system is documented: > > ```cmake > #[==[.md > ... > #]==] > ``` > > which will make it possible to extract out these blocks and feed them to > Doxygen and get the module system API docs on the web with the rest of > VTK. > > There's also `#[==[.md INTERNAL` for internal function documentation as > well. > > --Ben From will.schroeder at kitware.com Tue Oct 30 06:21:34 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 30 Oct 2018 06:21:34 -0400 Subject: [vtk-developers] (no subject) In-Reply-To: References: Message-ID: Dave- If you can give me a few days I'd like to push the high speed unstructured isocontouring that I am just finishing up.... Best, W On Mon, Oct 29, 2018 at 4:04 PM David E DeMarle wrote: > Hi, > > Does anyone have work in progress that should delay the branch point for > VTK 8.2? > > We would like to branch and start the release candidate cycle for 8.2 now. > The top issues that are driving this release are: a desire to deprecate > support for Visual Studio 2013 in order to get a more complete c++11 basis, > and a desire to start getting Ben's CMake updates tested in master on all > of the dashboards. Branching now will let us preserve everyone's > improvements in master within an easy to migrate to official release. > > 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 > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Oct 30 08:57:17 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 30 Oct 2018 08:57:17 -0400 Subject: [vtk-developers] (no subject) In-Reply-To: References: Message-ID: Thanks. Please try and get it merged to master by Friday. If that is not possible ping me and we'll figure something out. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Oct 30, 2018 at 6:21 AM Will Schroeder wrote: > Dave- > > If you can give me a few days I'd like to push the high speed unstructured > isocontouring that I am just finishing up.... > > Best, > W > > On Mon, Oct 29, 2018 at 4:04 PM David E DeMarle > wrote: > >> Hi, >> >> Does anyone have work in progress that should delay the branch point for >> VTK 8.2? >> >> We would like to branch and start the release candidate cycle for 8.2 >> now. The top issues that are driving this release are: a desire to >> deprecate support for Visual Studio 2013 in order to get a more complete >> c++11 basis, and a desire to start getting Ben's CMake updates tested in >> master on all of the dashboards. Branching now will let us preserve >> everyone's improvements in master within an easy to migrate to official >> release. >> >> 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 >> >> > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Oct 30 14:09:29 2018 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 30 Oct 2018 14:09:29 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: <20181029214211.GA16451@rotor.localdomain> References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> Message-ID: So.... if we are significantly changing the modules shoudl we also take the time to rename OpenGL2 back to OpenGL as was the original intent? On Mon, Oct 29, 2018 at 5:42 PM, Ben Boeckel wrote: > On Mon, Oct 29, 2018 at 22:31:38 +0100, Elvis Stansvik wrote: > > Let me just jump in and say that while it sounds neat to embed it > > comments, it might make it slightly harder to make an updated version > > of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). > > Thanks for the reminder that this file needs updated. > > CMake supports long-form comments now, so I'd think it'd be in blocks > like this: > > ```cmake > #[==[vtk.kit > ... > #]==] > #[==[vtk.module > ... > #]==] > ``` > > with a limit of one `vtk.module` per file. Easy to slice out with a > simple `sed` call. Not so easy in CMake, but also not ridiculous. > > This is similar to the way the new module system is documented: > > ```cmake > #[==[.md > ... > #]==] > ``` > > which will make it possible to extract out these blocks and feed them to > Doxygen and get the module system API docs on the web with the rest of > VTK. > > There's also `#[==[.md INTERNAL` for internal function documentation as > well. > > --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 > > -- 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 dave.demarle at kitware.com Tue Oct 30 14:15:56 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 30 Oct 2018 14:15:56 -0400 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> Message-ID: +1 for rename On Tue, Oct 30, 2018, 2:09 PM Ken Martin wrote: > So.... if we are significantly changing the modules shoudl we also take > the time to rename OpenGL2 back to OpenGL as was the original intent? > > On Mon, Oct 29, 2018 at 5:42 PM, Ben Boeckel > wrote: > >> On Mon, Oct 29, 2018 at 22:31:38 +0100, Elvis Stansvik wrote: >> > Let me just jump in and say that while it sounds neat to embed it >> > comments, it might make it slightly harder to make an updated version >> > of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). >> >> Thanks for the reminder that this file needs updated. >> >> CMake supports long-form comments now, so I'd think it'd be in blocks >> like this: >> >> ```cmake >> #[==[vtk.kit >> ... >> #]==] >> #[==[vtk.module >> ... >> #]==] >> ``` >> >> with a limit of one `vtk.module` per file. Easy to slice out with a >> simple `sed` call. Not so easy in CMake, but also not ridiculous. >> >> This is similar to the way the new module system is documented: >> >> ```cmake >> #[==[.md >> ... >> #]==] >> ``` >> >> which will make it possible to extract out these blocks and feed them to >> Doxygen and get the module system API docs on the web with the rest of >> VTK. >> >> There's also `#[==[.md INTERNAL` for internal function documentation as >> well. >> >> --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 >> >> > > > -- > 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. > _______________________________________________ > 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 pbergeron at spiria.com Tue Oct 30 15:10:28 2018 From: pbergeron at spiria.com (Patrick Bergeron) Date: Tue, 30 Oct 2018 19:10:28 +0000 Subject: [vtk-developers] Multiple textures Message-ID: Hi folks. I sent this a while back on vtk-users but got no response. I am sending this to vtk-developers because if the features isn't implemented, I will implement it. I am trying to pass multiple texture buffers to a fragment shader. I saw I can do: 1) actor->SetTexture(vtkTexture*) takes only a single vtkTexture 2) actor->GetProperty()->SetTexture(int unit, vtkTexture*) takes a texture that I can associate to a texture unit, but those functions are deprecated. In fact, I think that (2) doesn't even work anymore with the OpenGL2 backend, at least my shader code doesn't seem to be getting them, maybe I am doing something wrong. In any case, I get a vtk warning saying I should not do that. Some folks have said I should combine multiple images into a single image before sending as a texture image. But I can't do this, because I need to send texture images as well as multiple data (non-image) buffers to the shader as well. How can I attach multiple image buffers to the actor and/or ogl mapper? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Oct 30 15:16:10 2018 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 30 Oct 2018 15:16:10 -0400 Subject: [vtk-developers] Multiple textures In-Reply-To: References: Message-ID: I responded yesterday so maybe check your spam folder etc. Here is the link https://markmail.org/thread/7gtvznk7jql7uv74 On Tue, Oct 30, 2018 at 3:10 PM, Patrick Bergeron wrote: > Hi folks. I sent this a while back on vtk-users but got no response. > > > > I am sending this to vtk-developers because if the features isn't > implemented, I will implement it. > > > I am trying to pass multiple texture buffers to a fragment shader. > > > I saw I can do: > > > 1) actor->SetTexture(vtkTexture*) takes only a single vtkTexture > > > 2) actor->GetProperty()->SetTexture(int unit, vtkTexture*) takes a > texture that I can associate to a texture unit, but those functions are > deprecated. > > > In fact, I think that (2) doesn't even work anymore with the OpenGL2 > backend, at least my shader code doesn't seem to be getting them, maybe I > am doing something wrong. In any case, I get a vtk warning saying I should > not do that. > > > > Some folks have said I should combine multiple images into a single image > before sending as a texture image. But I can't do this, because I need to > send texture images as well as multiple data (non-image) buffers to the > shader as well. > > > How can I attach multiple image buffers to the actor and/or ogl mapper? > > > > > _______________________________________________ > 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 > > > -- 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 pbergeron at spiria.com Tue Oct 30 20:09:31 2018 From: pbergeron at spiria.com (Patrick Bergeron) Date: Wed, 31 Oct 2018 00:09:31 +0000 Subject: [vtk-developers] Multiple textures In-Reply-To: References: , Message-ID: You rock. I will give it a try. Not sure how I missed it. BTW, Google is my friend, but I kept finding this link whatever search terms I gave google. http://vtk.1045678.n5.nabble.com/Using-multile-texture-files-in-vtkOBJImporter-td5744430.html "It is possible to have multiple texture maps applied to a single surface where the texture maps are blended together using a blending function. That is the part we do not support. " I wasn't sure what to make of that comment! :-) Many other places in archives also state that only one texture and one texture coordinate is supported... ________________________________ From: Ken Martin Sent: October 30, 2018 3:16:10 PM To: Patrick Bergeron Cc: vtk-developers at public.kitware.com Subject: Re: [vtk-developers] Multiple textures I responded yesterday so maybe check your spam folder etc. Here is the link https://markmail.org/thread/7gtvznk7jql7uv74 On Tue, Oct 30, 2018 at 3:10 PM, Patrick Bergeron > wrote: Hi folks. I sent this a while back on vtk-users but got no response. I am sending this to vtk-developers because if the features isn't implemented, I will implement it. I am trying to pass multiple texture buffers to a fragment shader. I saw I can do: 1) actor->SetTexture(vtkTexture*) takes only a single vtkTexture 2) actor->GetProperty()->SetTexture(int unit, vtkTexture*) takes a texture that I can associate to a texture unit, but those functions are deprecated. In fact, I think that (2) doesn't even work anymore with the OpenGL2 backend, at least my shader code doesn't seem to be getting them, maybe I am doing something wrong. In any case, I get a vtk warning saying I should not do that. Some folks have said I should combine multiple images into a single image before sending as a texture image. But I can't do this, because I need to send texture images as well as multiple data (non-image) buffers to the shader as well. How can I attach multiple image buffers to the actor and/or ogl mapper? _______________________________________________ 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 -- 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 ken.martin at kitware.com Wed Oct 31 08:50:20 2018 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 31 Oct 2018 08:50:20 -0400 Subject: [vtk-developers] Multiple textures In-Reply-To: References: Message-ID: At one time we supported multiple textures, then we didn't and now we do again. So the archives do give a lot of conflicting answers. On Tue, Oct 30, 2018 at 8:09 PM, Patrick Bergeron wrote: > You rock. > > > I will give it a try. Not sure how I missed it. > > > BTW, Google is my friend, but I kept finding this link whatever search > terms I gave google. > > > http://vtk.1045678.n5.nabble.com/Using-multile-texture- > files-in-vtkOBJImporter-td5744430.html > > > > "It is possible to have multiple texture maps applied to a single surface > where the texture maps are blended together using a blending function. That > is the part we do not support. " > > > I wasn't sure what to make of that comment! :-) > > Many other places in archives also state that only one texture and > one texture coordinate is supported... > > > > > ------------------------------ > *From:* Ken Martin > *Sent:* October 30, 2018 3:16:10 PM > *To:* Patrick Bergeron > *Cc:* vtk-developers at public.kitware.com > *Subject:* Re: [vtk-developers] Multiple textures > > I responded yesterday so maybe check your spam folder etc. Here is the > link > > https://markmail.org/thread/7gtvznk7jql7uv74 > > > > On Tue, Oct 30, 2018 at 3:10 PM, Patrick Bergeron > wrote: > > Hi folks. I sent this a while back on vtk-users but got no response. > > > > I am sending this to vtk-developers because if the features isn't > implemented, I will implement it. > > > I am trying to pass multiple texture buffers to a fragment shader. > > > I saw I can do: > > > 1) actor->SetTexture(vtkTexture*) takes only a single vtkTexture > > > 2) actor->GetProperty()->SetTexture(int unit, vtkTexture*) takes a > texture that I can associate to a texture unit, but those functions are > deprecated. > > > In fact, I think that (2) doesn't even work anymore with the OpenGL2 > backend, at least my shader code doesn't seem to be getting them, maybe I > am doing something wrong. In any case, I get a vtk warning saying I should > not do that. > > > > Some folks have said I should combine multiple images into a single image > before sending as a texture image. But I can't do this, because I need to > send texture images as well as multiple data (non-image) buffers to the > shader as well. > > > How can I attach multiple image buffers to the actor and/or ogl mapper? > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/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 > > > > > > -- > 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. > -- 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 stas.truhan at gmail.com Wed Oct 31 09:21:13 2018 From: stas.truhan at gmail.com (take5v) Date: Wed, 31 Oct 2018 06:21:13 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS Message-ID: <1540992073353-0.post@n5.nabble.com> Dear developers and others, I'd like to visualize grayscale images with python, VTK and PyQt5. So, I've made this script with Qt Application and embedded QVTKRenderWindowInteractor. Please have a look into my gist https://gist.github.com/take5v/1df1e4f4222f49cf05cbf59b1f89a9ea. The issue is that the vtkPropPicker gives wrong world coordinates while event coordinates are correct. This bug I could reproduce only on Mac Os, not on Windows and Ubuntu. I found probably a workaround that was made for c++ QVTKOpenGLWindow class which wasn't been wrapped for python: https://github.com/Kitware/VTK/blob/c6eb8803c44b13947f959aed7b4e551e5e2915db/GUISupport/Qt/QVTKOpenGLWindow.cxx#L266. My setup: macOS Mojave 10.14 python 3.6.4 vtk-python 8.1.1 PyQt 5.11.3 Best regards, Stas ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From mathieu.westphal at kitware.com Wed Oct 31 09:54:15 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 31 Oct 2018 14:54:15 +0100 Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1540992073353-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> Message-ID: Hi Stas, You may want to try with the last development version of VTK, as these class have been reimplemented. https://gitlab.kitware.com/vtk/vtk Best Regards, Mathieu Westphal On Wed, Oct 31, 2018 at 2:21 PM take5v wrote: > Dear developers and others, > > I'd like to visualize grayscale images with python, VTK and PyQt5. So, I've > made this script with Qt Application and embedded > QVTKRenderWindowInteractor. Please have a look into my gist > https://gist.github.com/take5v/1df1e4f4222f49cf05cbf59b1f89a9ea. > > The issue is that the vtkPropPicker gives wrong world coordinates while > event coordinates are correct. This bug I could reproduce only on Mac Os, > not on Windows and Ubuntu. > > I found probably a workaround that was made for c++ QVTKOpenGLWindow class > which wasn't been wrapped for python: > > https://github.com/Kitware/VTK/blob/c6eb8803c44b13947f959aed7b4e551e5e2915db/GUISupport/Qt/QVTKOpenGLWindow.cxx#L266 > . > > My setup: > macOS Mojave 10.14 > python 3.6.4 > vtk-python 8.1.1 > PyQt 5.11.3 > > Best regards, > Stas > > > > > > ----- > Best regards, > Stanislau Trukhan > -- > Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Oct 31 09:38:01 2018 From: sean at rogue-research.com (Sean McBride) Date: Wed, 31 Oct 2018 09:38:01 -0400 Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1540992073353-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> Message-ID: <20181031133801.572991736@mail.rogue-research.com> On Wed, 31 Oct 2018 06:21:13 -0700, take5v said: >The issue is that the vtkPropPicker gives wrong world coordinates while >event coordinates are correct. This bug I could reproduce only on Mac Os, >not on Windows and Ubuntu. Is this on a "retina" display? If so, check if it's correct on a non-Retina display... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From stas.truhan at gmail.com Wed Oct 31 09:42:05 2018 From: stas.truhan at gmail.com (take5v) Date: Wed, 31 Oct 2018 06:42:05 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <20181031133801.572991736@mail.rogue-research.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> Message-ID: <1540993325645-0.post@n5.nabble.com> Sean McBride wrote > Is this on a "retina" display? If so, check if it's correct on a > non-Retina display... I tested only on a "retina" display. ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From stas.truhan at gmail.com Wed Oct 31 11:15:05 2018 From: stas.truhan at gmail.com (take5v) Date: Wed, 31 Oct 2018 08:15:05 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1540993325645-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> Message-ID: <1540998905857-0.post@n5.nabble.com> When switching off HiDPI all works well. So, apparently, the issue is concerning HiDPU support in python wrappers. Best regards, Stas ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From david.gobbi at gmail.com Wed Oct 31 11:59:56 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 31 Oct 2018 09:59:56 -0600 Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1540998905857-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> Message-ID: Hi Stas, An important retina change was made to QVTKRenderWindowInteractor.py since 8.1.1: https://gitlab.kitware.com/vtk/vtk/merge_requests/4201/diffs You could try adding these same changes to your own QVTKRenderWindowInteractor.py. Note that QVTKRenderWindowInteractor.py and the vtk GUISupport/Qt classes are completely independent, so changes to GUISupport/Qt have no impact on the behaviour of QVTKRenderWindowInteractor.py and vice-versa. So the changes to GUISupport/Qt that Mathieu was referring to aren't actually useful to you, since those classes aren't wrapped (the reason they aren't wrapped is that they are Qt classes, so they would have to be wrapped with sip, rather than with the VTK wrapper tools). - David On Wed, Oct 31, 2018 at 9:15 AM take5v wrote: > When switching off HiDPI all works well. So, apparently, the issue is > concerning HiDPU support in python wrappers. > > Best regards, > Stas > > > > ----- > Best regards, > Stanislau Trukhan > -- > Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stas.truhan at gmail.com Wed Oct 31 12:15:53 2018 From: stas.truhan at gmail.com (take5v) Date: Wed, 31 Oct 2018 09:15:53 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> Message-ID: <1541002553335-0.post@n5.nabble.com> Hi David, Thank you very much, now it works like a charm! Looking forward to the new VTK release in pip. Best regards, Stas ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From stas.truhan at gmail.com Wed Oct 31 12:57:25 2018 From: stas.truhan at gmail.com (take5v) Date: Wed, 31 Oct 2018 09:57:25 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1541002553335-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> <1541002553335-0.post@n5.nabble.com> Message-ID: <1541005045046-0.post@n5.nabble.com> Another issue but within the same context of mine toy example (script of which I posted above) is a slow fps during window/level change on Windows. This process is slow and laggy even during rendering the super small image of vtk.png from VTKData. CPU: GeForce GTX 680 GPU: Intel i7-3770K ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From david.gobbi at gmail.com Wed Oct 31 13:27:36 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 31 Oct 2018 11:27:36 -0600 Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1541005045046-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> <1541002553335-0.post@n5.nabble.com> <1541005045046-0.post@n5.nabble.com> Message-ID: Hi Stas, Here are a couple things to try to improve fps (no guarantees, though). With QVTKRenderWindowInteractor, it is best to let Qt handle the render calls, rather than calling Render() directly. So try replacing all of your calls to Render() with calls to self.update(), where 'self' is the QVTKRenderWindowInteractor. If you do not do this, then it is possible that the Render() is hidden because it isn't associated with a Qt paint operation. By calling update() on a Qt widget, you ensure that Qt will call Render() synchronously with its paintEvent(). A second thing to try is to call Update() on your reader before using its output. Most readers will 'stream' which means that they only read the slices that are requested by the VTK pipeline (possibly causing the reader to re-execute on future pipeline requests), unless you specifically call Update() which forces all the slices to be read into memory at once. Since your example only has one input slice, I doubt that this is what is causing a slow-down for you, but it is still a good habit when working with VTK readers. - David On Wed, Oct 31, 2018 at 10:57 AM take5v wrote: > Another issue but within the same context of mine toy example (script of > which I posted above) is a slow fps during window/level change on Windows. > This process is slow and laggy even during rendering the super small image > of vtk.png from VTKData. > > CPU: GeForce GTX 680 > GPU: Intel i7-3770K > > > > ----- > Best regards, > Stanislau Trukhan > -- > Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sal.choueib at queensu.ca Wed Oct 31 14:14:17 2018 From: sal.choueib at queensu.ca (Sal Choueib) Date: Wed, 31 Oct 2018 18:14:17 +0000 Subject: [vtk-developers] VTK to GLTF Exporter Message-ID: Dear developers and others, I am looking to develop a VTK exporter to the GLTF data format. I was wondering if someone has already begun developing this so that perhaps we could communicate. Thank you, Sal Choueib -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Wed Oct 31 15:31:04 2018 From: pieper at isomics.com (Steve Pieper) Date: Wed, 31 Oct 2018 15:31:04 -0400 Subject: [vtk-developers] VTK to GLTF Exporter In-Reply-To: References: Message-ID: Hi Sal - I did a gltf 1.0 exporter from slicer a while back [1]. I've been wanting to factor it out into an independent library and upgrade it to gltf 2.0. Most of the code is generic VTK, but with some extra context extracted from Slicer data structures. Here's a web page [2] that shows an exported scene displayed with a-frame (also works with WebVR if you have it). I would be glad to see this move forward - I was just a Qt event yesterday and the new KDAB Kuesa [3] tools use gltf 2.0 with QML in ways that could be fun. Best, Steve [1] https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 [2] https://pieper.github.io/scenes/spl-pnl-brain-atlas/ [3] https://www.kdab.com/expertise/3dgraphicsandcompute/kuesa/ On Wed, Oct 31, 2018 at 2:14 PM Sal Choueib wrote: > Dear developers and others, > > > > I am looking to develop a VTK exporter to the GLTF data > format. I was wondering if someone has already begun developing this so > that perhaps we could communicate. > > > > Thank you, > Sal Choueib > > > _______________________________________________ > 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 stas.truhan at gmail.com Wed Oct 31 18:57:48 2018 From: stas.truhan at gmail.com (take5v) Date: Wed, 31 Oct 2018 15:57:48 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> <1541002553335-0.post@n5.nabble.com> <1541005045046-0.post@n5.nabble.com> Message-ID: <1541026668499-0.post@n5.nabble.com> Hi David! Thank you for the detailed response. I've changed Render call with QVTKRenderWindowInteractor update method but I observed no performance change. But I got lucky twice when changing window/level was real-time without any lags. I have no idea how to reproduce this behavior again but I do confirm the same inconsistency in Slicer3D on Windows machine. I found changing window/level of 2d slices is slow but 3d volume rendering is fast. There is a thread, apparently, with similar performance issue from Slicer3D: https://discourse.slicer.org/t/2d-views-in-slicer-extremely-slow-on-windows/782. I also tried vtkImageViewer2 without qt and got the same laggy behavior. Nvidia driver: 411.31 David Gobbi wrote > Hi Stas, > > Here are a couple things to try to improve fps (no guarantees, though). > > With QVTKRenderWindowInteractor, it is best to let Qt handle the > render calls, rather than calling Render() directly. So try replacing > all of your calls to Render() with calls to self.update(), where 'self' is > the QVTKRenderWindowInteractor. If you do not do this, then it is > possible that the Render() is hidden because it isn't associated with > a Qt paint operation. By calling update() on a Qt widget, you ensure > that Qt will call Render() synchronously with its paintEvent(). > > A second thing to try is to call Update() on your reader before using > its output. Most readers will 'stream' which means that they only > read the slices that are requested by the VTK pipeline (possibly > causing the reader to re-execute on future pipeline requests), > unless you specifically call Update() which forces all the slices to be > read into memory at once. Since your example only has one input > slice, I doubt that this is what is causing a slow-down for you, but it > is still a good habit when working with VTK readers. > > - David > > > On Wed, Oct 31, 2018 at 10:57 AM take5v < > stas.truhan@ > > wrote: > >> Another issue but within the same context of mine toy example (script of >> which I posted above) is a slow fps during window/level change on >> Windows. >> This process is slow and laggy even during rendering the super small >> image >> of vtk.png from VTKData. >> >> CPU: GeForce GTX 680 >> GPU: Intel i7-3770K >> >> >> >> ----- >> Best regards, >> Stanislau Trukhan >> -- >> Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> 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 ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From pieper at isomics.com Wed Oct 31 20:15:22 2018 From: pieper at isomics.com (Steve Pieper) Date: Wed, 31 Oct 2018 20:15:22 -0400 Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1541026668499-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> <1541002553335-0.post@n5.nabble.com> <1541005045046-0.post@n5.nabble.com> <1541026668499-0.post@n5.nabble.com> Message-ID: Hi Stas - We think the Slicer display issues have all been resolved since the thread you linked - can you try the latest 4.10 release (from just a few days ago) and see if you still see the issue? We tracked some issues to the graphics drivers, but others had to do with optimizing the reslice theading and render compression settings. Best, Steve On Wed, Oct 31, 2018 at 6:57 PM take5v wrote: > Hi David! > > Thank you for the detailed response. I've changed Render call with > QVTKRenderWindowInteractor update method but I observed no performance > change. But I got lucky twice when changing window/level was real-time > without any lags. I have no idea how to reproduce this behavior again but I > do confirm the same inconsistency in Slicer3D on Windows machine. I found > changing window/level of 2d slices is slow but 3d volume rendering is fast. > There is a thread, apparently, with similar performance issue from > Slicer3D: > > https://discourse.slicer.org/t/2d-views-in-slicer-extremely-slow-on-windows/782 > . > I also tried vtkImageViewer2 without qt and got the same laggy behavior. > > Nvidia driver: 411.31 > > > > David Gobbi wrote > > Hi Stas, > > > > Here are a couple things to try to improve fps (no guarantees, though). > > > > With QVTKRenderWindowInteractor, it is best to let Qt handle the > > render calls, rather than calling Render() directly. So try replacing > > all of your calls to Render() with calls to self.update(), where 'self' > is > > the QVTKRenderWindowInteractor. If you do not do this, then it is > > possible that the Render() is hidden because it isn't associated with > > a Qt paint operation. By calling update() on a Qt widget, you ensure > > that Qt will call Render() synchronously with its paintEvent(). > > > > A second thing to try is to call Update() on your reader before using > > its output. Most readers will 'stream' which means that they only > > read the slices that are requested by the VTK pipeline (possibly > > causing the reader to re-execute on future pipeline requests), > > unless you specifically call Update() which forces all the slices to be > > read into memory at once. Since your example only has one input > > slice, I doubt that this is what is causing a slow-down for you, but it > > is still a good habit when working with VTK readers. > > > > - David > > > > > > On Wed, Oct 31, 2018 at 10:57 AM take5v < > > > stas.truhan@ > > > > wrote: > > > >> Another issue but within the same context of mine toy example (script of > >> which I posted above) is a slow fps during window/level change on > >> Windows. > >> This process is slow and laggy even during rendering the super small > >> image > >> of vtk.png from VTKData. > >> > >> CPU: GeForce GTX 680 > >> GPU: Intel i7-3770K > >> > >> > >> > >> ----- > >> Best regards, > >> Stanislau Trukhan > >> -- > >> Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> 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 > > > > > > ----- > Best regards, > Stanislau Trukhan > -- > Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Wed Oct 31 21:17:15 2018 From: lasso at queensu.ca (Andras Lasso) Date: Thu, 1 Nov 2018 01:17:15 +0000 Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: <1541026668499-0.post@n5.nabble.com> References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> <1541002553335-0.post@n5.nabble.com> <1541005045046-0.post@n5.nabble.com> <1541026668499-0.post@n5.nabble.com> Message-ID: Initially, when 3D Slicer switched to VTK8/Qt5/OpenGL2 backend, image reslice speed was about 5-10x slower than using the old VTK7/Qt4/OpenGL backend. We could achieve acceptable performance by: 1. Switching to TBB SMP backend in VTK. This primarily helped on Windows computers with i7 CPU and strong NVidia GPU (https://github.com/Slicer/Slicer/pull/930). 2. Tuning strategy how ScheduleRender() calls are converted to Render() calls. This helped in particular in getting consistent frame rates on MacOSX. (https://github.com/commontk/CTK/blob/master/Libs/Visualization/VTK/Widgets/ctkVTKAbstractView.h) Still, image reslicing is about 10-20% slower with VTK8/Qt5/OpenGL2, especially on laptops and computers with combined integrated+discrete GPU. It seems most time is spent in the OpenGL driver, mainly due to calls made from vtkOpenGLTexture::Load (https://issues.slicer.org/view.php?id=4496). Andras -----Original Message----- From: vtk-developers On Behalf Of take5v Sent: Wednesday, October 31, 2018 6:58 PM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS Hi David! Thank you for the detailed response. I've changed Render call with QVTKRenderWindowInteractor update method but I observed no performance change. But I got lucky twice when changing window/level was real-time without any lags. I have no idea how to reproduce this behavior again but I do confirm the same inconsistency in Slicer3D on Windows machine. I found changing window/level of 2d slices is slow but 3d volume rendering is fast. There is a thread, apparently, with similar performance issue from Slicer3D: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.slicer.org%2Ft%2F2d-views-in-slicer-extremely-slow-on-windows%2F782&data=02%7C01%7Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=z%2F85pd7WeC8GI7%2FmnMlNsUcx3JRogc5sJfByit0kA0Q%3D&reserved=0. I also tried vtkImageViewer2 without qt and got the same laggy behavior. Nvidia driver: 411.31 David Gobbi wrote > Hi Stas, > > Here are a couple things to try to improve fps (no guarantees, though). > > With QVTKRenderWindowInteractor, it is best to let Qt handle the > render calls, rather than calling Render() directly. So try replacing > all of your calls to Render() with calls to self.update(), where > 'self' is the QVTKRenderWindowInteractor. If you do not do this, then > it is possible that the Render() is hidden because it isn't associated > with a Qt paint operation. By calling update() on a Qt widget, you > ensure that Qt will call Render() synchronously with its paintEvent(). > > A second thing to try is to call Update() on your reader before using > its output. Most readers will 'stream' which means that they only > read the slices that are requested by the VTK pipeline (possibly > causing the reader to re-execute on future pipeline requests), unless > you specifically call Update() which forces all the slices to be read > into memory at once. Since your example only has one input slice, I > doubt that this is what is causing a slow-down for you, but it is > still a good habit when working with VTK readers. > > - David > > > On Wed, Oct 31, 2018 at 10:57 AM take5v < > stas.truhan@ > > wrote: > >> Another issue but within the same context of mine toy example (script >> of which I posted above) is a slow fps during window/level change on >> Windows. >> This process is slow and laggy even during rendering the super small >> image of vtk.png from VTKData. >> >> CPU: GeForce GTX 680 >> GPU: Intel i7-3770K >> >> >> >> ----- >> Best regards, >> Stanislau Trukhan >> -- >> Sent from: >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvtk.1 >> 045678.n5.nabble.com%2FVTK-Dev-f1251487.html&data=02%7C01%7Classo >> %40queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582 >> c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=EOxcLPZE4jDzrxX >> k0KOIf9RqXouukZgL7HC46iwz6NU%3D&reserved=0 >> _______________________________________________ >> Powered by >> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&am >> p;data=02%7C01%7Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f84489 >> 1%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008& >> ;sdata=iZoyvIzvUo3wwXD0sMcGmJaw2kRTyRVktar3DnBYOFM%3D&reserved=0 >> >> Visit other Kitware open-source projects at >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k >> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40 >> queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4e >> fb2838b925c%7C1%7C0%7C636766234722688008&sdata=f%2BKMU0xm65TMwdPj >> TMLZwBorIQ7cwgA8mjdrNIHYCQg%3D&reserved=0 >> >> Search the list archives at: >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkm >> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40q >> ueensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4ef >> b2838b925c%7C1%7C0%7C636766234722688008&sdata=sHi5aRgy7vD%2BLy%2B >> dcLgAfMntvGLyfl3ZhHdddq270ow%3D&reserved=0 >> >> Follow this link to subscribe/unsubscribe: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubl >> ic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01 >> %7Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38 >> b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=fQsqBZg >> 8c8fc2sL4duw2325P8PnFuE75a%2BowRhAFWcQ%3D&reserved=0 >> >> > > _______________________________________________ > Powered by > https://na01.safelinks.protection.outlook.com/?url=www.kitware.com& > ;data=02%7C01%7Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f844891% > 7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sd > ata=iZoyvIzvUo3wwXD0sMcGmJaw2kRTyRVktar3DnBYOFM%3D&reserved=0 > > Visit other Kitware open-source projects at > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki > tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40qu > eensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2 > 838b925c%7C1%7C0%7C636766234722688008&sdata=f%2BKMU0xm65TMwdPjTMLZ > wBorIQ7cwgA8mjdrNIHYCQg%3D&reserved=0 > > Search the list archives at: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma > il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40que > ensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb28 > 38b925c%7C1%7C0%7C636766234722688008&sdata=sHi5aRgy7vD%2BLy%2BdcLg > AfMntvGLyfl3ZhHdddq270ow%3D&reserved=0 > > Follow this link to subscribe/unsubscribe: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubli > c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7 > Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b14 > 2d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=fQsqBZg8c8f > c2sL4duw2325P8PnFuE75a%2BowRhAFWcQ%3D&reserved=0 ----- Best regards, Stanislau Trukhan -- Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvtk.1045678.n5.nabble.com%2FVTK-Dev-f1251487.html&data=02%7C01%7Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=EOxcLPZE4jDzrxXk0KOIf9RqXouukZgL7HC46iwz6NU%3D&reserved=0 _______________________________________________ Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=iZoyvIzvUo3wwXD0sMcGmJaw2kRTyRVktar3DnBYOFM%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%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=f%2BKMU0xm65TMwdPjTMLZwBorIQ7cwgA8mjdrNIHYCQg%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%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=sHi5aRgy7vD%2BLy%2BdcLgAfMntvGLyfl3ZhHdddq270ow%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%7C60be52993c6448c59bbb08d63f844891%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636766234722688008&sdata=fQsqBZg8c8fc2sL4duw2325P8PnFuE75a%2BowRhAFWcQ%3D&reserved=0