From berk.geveci at kitware.com Wed Jul 1 10:02:38 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 1 Jul 2015 10:02:38 -0400 Subject: [vtk-developers] [vtkusers] [EXTERNAL] vtk 6.3 and vtk 7.0 In-Reply-To: References: Message-ID: I am fairly novice in Java so I apologize if this sounds naive. Doesn't Java do its own memory management and actually automatically move data from one memory location to another? How does one map a Java array to a C++ array and make sure that it is not moved and of course garbage collected? Interfacing to numpy arrays works fine because Python provides a buffer interface where it is guaranteed that a Python object holds a buffer (an array essentially) that does not move. The Python wrappers simply expose a functionality that allows the C++ layer to get a pointer from a buffer object. Then this array can simply be passed to any C++ method that takes an array. This is the only efficient way of sharing array between the two layers. Doing a "zero copy" array where each array access such as GetTuple() goes through a Java layer would be terribly inefficient and impractical. Best, -berk On Wed, Jul 1, 2015 at 9:00 AM, Alexandre Dufour wrote: > Hi, > > I am not familiar with the nitty-gritty of the wrapping aspects, but as a > Java-based user (icy.bioimageanalysis.org), I believe the issue has to do > with the fact that transferring some Java array down to a vtk structure > (via any setJavaArray() method) always(?) implies a copy of said structure > down to the C++ layer, hence the issue of duplication. This typically > happens when your data/image structure is first handled on the Java side, > then passed over to VTK for rendering purposes. > > Does this make sense? Is there any way around this? I doubted that for a > while, but then remembered the good old Unsafe class in Java that might > help do ?dirty but efficient? communication? > > My 2 (unexperienced) cents. Very excited about this anyhow!! > > Alexandre > > *?* > *Alexandre Dufour, PhD* > > *Senior Research Fellow @ **Biological Image Analysis* > * group* > *Institut Pasteur* *, **Dpt. of Cell Biology & > Infection, **Paris campus (France)* > *CNRS UMR 3691 ?Pathological and Physiological Cell Dynamics? * > > *Meet **Icy* *, the next-generation > Bioimage Informatics platform* > > On 30 Jun 2015, at 15:46, Utkarsh Ayachit > wrote: > > Gerrick, > > The *new* zero copy design literally started a week or two ago, so it is > in its infancy, but I will write a design document soon. It doesn't however > do anything new for access through wrapped languages. What exactly is your > use-case. I am not sure what aspect is lacking in the current > implementation in that regard. > > Utkarsh > > On Mon, Jun 29, 2015 at 6:04 PM Gerrick Bivins < > Gerrick.Bivins at halliburton.com> wrote: > >> ?* deprecate the existing zero copy array API in preparation for a >> significant refactoring that will come in 7.0. The refactor will make zero >> copy arrays both simpler to use and perform better.? >> >> >> >> Where can I find more information about this? >> >> Does the ?Zero copy array refactor? expose this framework to wrapped >> languages, Java in particular? >> >> Currently the duplication of data is one of the things holding up >> adoption of VTK in our application. >> >> >> >> Gerrick >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *David E DeMarle >> *Sent:* Monday, June 29, 2015 9:42 AM >> *To:* vtkdev; vtkusers at vtk.org >> *Subject:* [EXTERNAL] [vtk-developers] vtk 6.3 and vtk 7.0 >> >> >> >> Hey vtkers, >> >> >> >> We are hoping to do a vtk 6.3 release in the next couple of weeks and >> then immediately follow that up with a 7.0 release. >> >> >> >> We'd are putting out a 6.3 out in order to: >> >> * deprecate the existing zero copy array API in preparation for a >> significant refactoring that will come in 7.0. The refactor will make zero >> copy arrays both simpler to use and perform better. >> >> * package up all of the progress that has been made in the master >> branch's OpenGL2 surface and volume rendering. The vtkpython binaries will >> switch over to using the OpenGL2 back end this release. >> >> >> >> Please let us know if you have any feedback, critical bugs especially, >> and developers let us know if there is any work you have in a partially >> finished state that we should be sure to get into 6.3. >> >> >> >> If all goes well we'll have a release candidate for 6.3 next week. >> >> >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> This e-mail, including any attached files, may contain confidential >> and privileged information for the sole use of the intended recipient. Any >> review, use, distribution, or disclosure by others is strictly prohibited. >> If you are not the intended recipient (or authorized to receive information >> for the intended recipient), please contact the sender by reply e-mail and >> delete all copies of this message. >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerrick.Bivins at halliburton.com Wed Jul 1 11:44:51 2015 From: Gerrick.Bivins at halliburton.com (Gerrick Bivins) Date: Wed, 1 Jul 2015 15:44:51 +0000 Subject: [vtk-developers] [vtkusers] [EXTERNAL] vtk 6.3 and vtk 7.0 In-Reply-To: References: Message-ID: Is there some way that java.nio API?s can help here? Possibly the ByteBuffer or MappedByteBuffer: http://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html http://docs.oracle.com/javase/8/docs/api/java/nio/MappedByteBuffer.html Gerrick From: vtkusers [mailto:vtkusers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Wednesday, July 01, 2015 9:03 AM To: Alexandre Dufour Cc: vtkdev; vtkusers at vtk.org Subject: Re: [vtkusers] [vtk-developers] [EXTERNAL] vtk 6.3 and vtk 7.0 I am fairly novice in Java so I apologize if this sounds naive. Doesn't Java do its own memory management and actually automatically move data from one memory location to another? How does one map a Java array to a C++ array and make sure that it is not moved and of course garbage collected? Interfacing to numpy arrays works fine because Python provides a buffer interface where it is guaranteed that a Python object holds a buffer (an array essentially) that does not move. The Python wrappers simply expose a functionality that allows the C++ layer to get a pointer from a buffer object. Then this array can simply be passed to any C++ method that takes an array. This is the only efficient way of sharing array between the two layers. Doing a "zero copy" array where each array access such as GetTuple() goes through a Java layer would be terribly inefficient and impractical. Best, -berk On Wed, Jul 1, 2015 at 9:00 AM, Alexandre Dufour > wrote: Hi, I am not familiar with the nitty-gritty of the wrapping aspects, but as a Java-based user (icy.bioimageanalysis.org), I believe the issue has to do with the fact that transferring some Java array down to a vtk structure (via any setJavaArray() method) always(?) implies a copy of said structure down to the C++ layer, hence the issue of duplication. This typically happens when your data/image structure is first handled on the Java side, then passed over to VTK for rendering purposes. Does this make sense? Is there any way around this? I doubted that for a while, but then remembered the good old Unsafe class in Java that might help do ?dirty but efficient? communication? My 2 (unexperienced) cents. Very excited about this anyhow!! Alexandre ? Alexandre Dufour, PhD Senior Research Fellow @ Biological Image Analysis group Institut Pasteur, Dpt. of Cell Biology & Infection, Paris campus (France) CNRS UMR 3691 ?Pathological and Physiological Cell Dynamics? Meet Icy, the next-generation Bioimage Informatics platform On 30 Jun 2015, at 15:46, Utkarsh Ayachit > wrote: Gerrick, The *new* zero copy design literally started a week or two ago, so it is in its infancy, but I will write a design document soon. It doesn't however do anything new for access through wrapped languages. What exactly is your use-case. I am not sure what aspect is lacking in the current implementation in that regard. Utkarsh On Mon, Jun 29, 2015 at 6:04 PM Gerrick Bivins > wrote: ?* deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better.? Where can I find more information about this? Does the ?Zero copy array refactor? expose this framework to wrapped languages, Java in particular? Currently the duplication of data is one of the things holding up adoption of VTK in our application. Gerrick From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David E DeMarle Sent: Monday, June 29, 2015 9:42 AM To: vtkdev; vtkusers at vtk.org Subject: [EXTERNAL] [vtk-developers] vtk 6.3 and vtk 7.0 Hey vtkers, We are hoping to do a vtk 6.3 release in the next couple of weeks and then immediately follow that up with a 7.0 release. We'd are putting out a 6.3 out in order to: * deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better. * package up all of the progress that has been made in the master branch's OpenGL2 surface and volume rendering. The vtkpython binaries will switch over to using the OpenGL2 back end this release. Please let us know if you have any feedback, critical bugs especially, and developers let us know if there is any work you have in a partially finished state that we should be sure to get into 6.3. If all goes well we'll have a release candidate for 6.3 next week. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ Search the list archives at: http://markmail.org/search/?q=vtkusers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtkusers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ Search the list archives at: http://markmail.org/search/?q=vtkusers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtkusers -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Thu Jul 2 04:25:38 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 2 Jul 2015 10:25:38 +0200 Subject: [vtk-developers] Disable wrapping java for a non vtkObject class Message-ID: So i've added this class wich does not inherit from vtkObjectBase I've added it as a WRAP_EXCLUDE class in the CMaleLists.txt, hewever, buildbot keep complaining about it: /Users/kitware/Dashboards/buildbot/vtk-kamino-osx-shared-release_clang_java_mpi_python_qt_tbb/build/java/vtk/vtkParticleBase.java:51: cannot find symbol symbol : method VTKRegister() location: class vtk.vtkParticleBase this.VTKRegister(); ^ /Users/kitware/Dashboards/buildbot/vtk-kamino-osx-shared-release_clang_java_mpi_python_qt_tbb/build/java/vtk/vtkParticleBase.java:52: registerJavaObject(java.lang.Long,vtk.vtkObjectBase) in vtk.vtkJavaMemoryManager cannot be applied to (long,vtk.vtkParticleBase) vtkObjectBase.JAVA_OBJECT_MANAGER.registerJavaObject(this.vtkId, this); ^ Note: /Users/kitware/Dashboards/buildbot/vtk-kamino-osx-shared-release_clang_java_mpi_python_qt_tbb/build/java/vtk/vtkJavaMemoryManagerImpl.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 2 errors Any insight ? Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Thu Jul 2 06:33:54 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 2 Jul 2015 12:33:54 +0200 Subject: [vtk-developers] Disable wrapping java for a non vtkObject class In-Reply-To: References: Message-ID: Mathieu, Your code is: set_source_files_properties( vtkParticleBase vtkParticleExample WRAP_EXCLUDE) which is incorrect because those are not sources files that will be checked by vtkWrapJava.cmake (line 78). set_source_files_properties( vtkParticleBase.cxx vtkParticleExample.cxx WRAP_EXCLUDE) should do the trick. Joachim :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Jul 2 09:01:27 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 2 Jul 2015 09:01:27 -0400 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: References: Message-ID: <2CE400AE-BADE-42F0-94B8-C693F222147C@kitware.com> Hi Alex, I think there is a third option that would be much more usable; generating a multiblock dataset that uses a single actor and mapper, but in which each block can be independently replaced with an edited version. As long as the source only regenerates a small number of leaf nodes, this would not have a large impact on memory, rendering, or picking performance. David On Jul 1, 2015, at 11:49 PM, Alex Malyushytskyy wrote: > As a user I think VTK during last 2 major releases acquired performance issues which makes it very difficult if not impossible to use for my needs as a developer of CAD type applications. > > Let me explain. Typical CAD application functionality can be demonstrated on the building model. > Building consists of a few type of structural components: columns, beams, slabs and walls. > Geometry of such component is defined by different attributes. For column for example it might be section shape, cross-section dimension, etc. > User of the CAD system should be able to select/pick components on the screen, change such component attributes and should see geometry change on the screen fast enough. > > Lets say we want to create 60 story building with 100 rooms per floor. > This gives us 6000 components or about 50k rectangular cells. > > With vtk developer basically has 2 choices of the implementation: > 1) minimize number of actors. Lets say actor for whole building. In such case every component geometry is appended to the building polydata. So finally you have only 1 dataset, 1 mapper and 1 actor. > 2) create actor per component. In this case you have 1 dataset, 1 mapper and 1 actor per component. > > Unfortunately neither approach works well for CAD application when model has to be editable by user. At least not with VTK 6.0.1. > > Comparison of usage cases: > > - when you need to re-generate whole model geometry (for example file withy model description loaded). > Approach 1 demonstrates better performance even though it requires additional append filter execution. > Approach 2 is slow - from 6 to 10 times slower. For a building described above it would be 7-8 sec for Approach 1 and 30-40 sec for approach 2 on my system. > > - when you need to modify a single component and update presentation. > > Approach 1 takes basically the same time as regenerate model from the scratch. > It takes basically the same time as regenerate model from the scratch. > But 7 sec are not acceptable anymore. > Modification of the dataset itself takes no time. All time is taken by vtk pipeline. > So basically there is no way for improvement. > > - picking/selection components. > Approach 1 is slow. Keep in mind that user have to select components, not cells. > So in this case you have to add to cell field which would allow to keep track which component picked cells belong to. Then selection is equivalent of adding data field to polydata and after picking setting value to such field for all cells which belong to that component. > This is definitely slower than for Approach 2. When all you need to keep tracking and select appropriate actor . > > > Approach 2 is very fast(less than second). > User would might be able to survive slow initial model loading, > if there were not any other differences. > > Unfortunately when you look at the application memory usage such model when approach 2 is used will take over 1.5 GB of memory when in case of approach 1 just about 140k. > That is for single view. You would not be able to display such model in 2 views on 32 bit Windows. > > > That is counting that you static mode and ImmediateModeRenderingOn were set for mapper, > and no intermediate filters are stored ( vtkPolydata -> Mapper -> actor pipeline is used). > > With number of components increasing memory usage and time grow. > So basically described above model is about as big editable model as VTK can handle without user breaking monitor after 30 min of work. > > For comparison I was using hoops3d (1998-2000) for developing of 3D FEM pre-, post-processing application with similar capabilities. 15 years ago on the appropriate systems I've seen better performance. Also I believe that 10 years ago VTK did not require such memory to display such size of data with exactly the same pipeline. > I blame changes in vtk 5 and 6. > > As a conclusion I afraid vtk 6 is not useable if you have to deal with dynamic changeable systems of average size on a single computer. > > I wish that was targeted. If not in vtk 6, may be in vtk7. > > > On Tue, Jun 30, 2015 at 1:24 PM, Berk Geveci wrote: > Yup. Python 3 is now on the roadmap. Probably the first release after 7, in a few months. > > -berk > > On Tue, Jun 30, 2015 at 3:48 PM, David Gobbi wrote: > On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett wrote: > Hi, > > On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci wrote: > > Hi folks, > > > > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. VTK 7 > > will follow very shortly (in weeks). I'd like to shed some light here on our > > thinking and how we are planning to move forward. > > > > As was previously discussed in the VTK developers list [1] [2], we are > > considering maintaining VTK 6.x for a long time (3-5 years) while moving > > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes > > happening in the computing and C++ worlds and we would like evolve VTK more > > quickly to stay up to date. Some of the major changes that we are > > considering and/or working on are: > > > > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) > > * Multi/many-core support / SMP computing on CPUs and accelerators. VTK-m > > integration [3]. > > * Changes to data model to support zero copy interface to other data > > layouts, more efficient APIs, more cell types, more dataset types etc. > > * Better separation of a public, wrapped API and toolkit/C++ internal API > > mainly to support efficiency > > * Introduction of C++ 11 features > > > > Much of this will require introducing changes that break backwards > > compatibility and also require newer compilers, graphics cards / drivers > > etc. So the idea is that we will do our best to support as much as possible > > a broad set of architectures and backwards compatibility but break things > > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that folks > > that are stuck on legacy systems or code bases can continue to benefit from > > bug fixes. We have a way of continuing to maintain a broad set of dashboards > > and also the same review process as VTK master so that we can continue to > > ensure the quality of VTK 6.x as well as new releases. > > > > What do you guys think? Please provide feedback so that we can adjust our > > plans to meet the needs of the community as much as possible. > > I would like to put in a humble plea to add Python 3 compatibility to that list: > > http://astrofrog.github.io/blog/2015/05/09/2015-survey-results > > Python 3 is being worked on (right now by me, and others can join in a couple weeks once the core pieces are in place). No, it won't be part of 6.3, however. > > - David > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers From deb63 at pitt.edu Thu Jul 2 08:35:32 2015 From: deb63 at pitt.edu (Busch, David E) Date: Thu, 2 Jul 2015 12:35:32 +0000 Subject: [vtk-developers] Future development timeline for VTK on iOS? Message-ID: Earlier we had anticipated releasing an iOS app to the app store that made use of VES and the KiwiViewer. However, as of February, Apple no longer accepts apps that do not have 64-bit support. Although VTK is supposed to support iOS now, it appears as though the build is still in an alpha state. Additionally, we noticed that there is VTK 2015 Google summer of code project proposal for to update the KiwiViewer model viewer to work with VTK. What are Kitware's thoughts about a timeline for a full-featured VTK and Kiwi or iOS, with maybe Kiwi as a 64-bit app store compliant replacement for the original VES/Kiwi? David Busch Mobile Applications Developer University of Pittsburgh -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Jul 2 09:12:53 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Jul 2015 09:12:53 -0400 Subject: [vtk-developers] vtkExplicitCell Message-ID: Folks, vtkExplicitCell is not used nor tested anywhere in vtk. Can it be removed? Bill From berk.geveci at kitware.com Thu Jul 2 09:20:44 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 2 Jul 2015 09:20:44 -0400 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: <2CE400AE-BADE-42F0-94B8-C693F222147C@kitware.com> References: <2CE400AE-BADE-42F0-94B8-C693F222147C@kitware.com> Message-ID: I agree with David. This is currently the best path for scene graph style use, especially combined with the OpenGL2 backend. This will be available in VTK 6.3 and VTK 7 but continues to evolve. So please let us know if you run into issues, performance or otherwise. We also discussed developing a full-featured scene graph actor but it was not a high priority. VTK's major use cases center around a few large geometry objects or a large number of small objects that have related properties coming from a point/cell array (molecules, tensors etc.) However, we will continue to add more scene graph style capabilities to multi-block rendering. Probably including transform support per block, inheritance of properties from an upper node etc. Best, -berk On Thu, Jul 2, 2015 at 9:01 AM, David Thompson wrote: > Hi Alex, > > I think there is a third option that would be much more usable; generating > a multiblock dataset that uses a single actor and mapper, but in which each > block can be independently replaced with an edited version. As long as the > source only regenerates a small number of leaf nodes, this would not have a > large impact on memory, rendering, or picking performance. > > David > > On Jul 1, 2015, at 11:49 PM, Alex Malyushytskyy > wrote: > > > As a user I think VTK during last 2 major releases acquired performance > issues which makes it very difficult if not impossible to use for my needs > as a developer of CAD type applications. > > > > Let me explain. Typical CAD application functionality can be > demonstrated on the building model. > > Building consists of a few type of structural components: columns, > beams, slabs and walls. > > Geometry of such component is defined by different attributes. For > column for example it might be section shape, cross-section dimension, etc. > > User of the CAD system should be able to select/pick components on the > screen, change such component attributes and should see geometry change on > the screen fast enough. > > > > Lets say we want to create 60 story building with 100 rooms per floor. > > This gives us 6000 components or about 50k rectangular cells. > > > > With vtk developer basically has 2 choices of the implementation: > > 1) minimize number of actors. Lets say actor for whole building. In > such case every component geometry is appended to the building polydata. So > finally you have only 1 dataset, 1 mapper and 1 actor. > > 2) create actor per component. In this case you have 1 dataset, 1 mapper > and 1 actor per component. > > > > Unfortunately neither approach works well for CAD application when model > has to be editable by user. At least not with VTK 6.0.1. > > > > Comparison of usage cases: > > > > - when you need to re-generate whole model geometry (for example file > withy model description loaded). > > Approach 1 demonstrates better performance even though it requires > additional append filter execution. > > Approach 2 is slow - from 6 to 10 times slower. For a building > described above it would be 7-8 sec for Approach 1 and 30-40 sec for > approach 2 on my system. > > > > - when you need to modify a single component and update presentation. > > > > Approach 1 takes basically the same time as regenerate model from the > scratch. > > It takes basically the same time as regenerate model from the scratch. > > But 7 sec are not acceptable anymore. > > Modification of the dataset itself takes no time. All time is taken by > vtk pipeline. > > So basically there is no way for improvement. > > > > - picking/selection components. > > Approach 1 is slow. Keep in mind that user have to select components, > not cells. > > So in this case you have to add to cell field which would allow to keep > track which component picked cells belong to. Then selection is equivalent > of adding data field to polydata and after picking setting value to such > field for all cells which belong to that component. > > This is definitely slower than for Approach 2. When all you need to keep > tracking and select appropriate actor . > > > > > > Approach 2 is very fast(less than second). > > User would might be able to survive slow initial model loading, > > if there were not any other differences. > > > > Unfortunately when you look at the application memory usage such model > when approach 2 is used will take over 1.5 GB of memory when in case of > approach 1 just about 140k. > > That is for single view. You would not be able to display such model in > 2 views on 32 bit Windows. > > > > > > That is counting that you static mode and ImmediateModeRenderingOn were > set for mapper, > > and no intermediate filters are stored ( vtkPolydata -> Mapper -> actor > pipeline is used). > > > > With number of components increasing memory usage and time grow. > > So basically described above model is about as big editable model as VTK > can handle without user breaking monitor after 30 min of work. > > > > For comparison I was using hoops3d (1998-2000) for developing of 3D FEM > pre-, post-processing application with similar capabilities. 15 years ago > on the appropriate systems I've seen better performance. Also I believe > that 10 years ago VTK did not require such memory to display such size of > data with exactly the same pipeline. > > I blame changes in vtk 5 and 6. > > > > As a conclusion I afraid vtk 6 is not useable if you have to deal with > dynamic changeable systems of average size on a single computer. > > > > I wish that was targeted. If not in vtk 6, may be in vtk7. > > > > > > On Tue, Jun 30, 2015 at 1:24 PM, Berk Geveci > wrote: > > Yup. Python 3 is now on the roadmap. Probably the first release after > 7, in a few months. > > > > -berk > > > > On Tue, Jun 30, 2015 at 3:48 PM, David Gobbi > wrote: > > On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett > wrote: > > Hi, > > > > On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci > wrote: > > > Hi folks, > > > > > > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. > VTK 7 > > > will follow very shortly (in weeks). I'd like to shed some light here > on our > > > thinking and how we are planning to move forward. > > > > > > As was previously discussed in the VTK developers list [1] [2], we are > > > considering maintaining VTK 6.x for a long time (3-5 years) while > moving > > > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes > > > happening in the computing and C++ worlds and we would like evolve VTK > more > > > quickly to stay up to date. Some of the major changes that we are > > > considering and/or working on are: > > > > > > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) > > > * Multi/many-core support / SMP computing on CPUs and accelerators. > VTK-m > > > integration [3]. > > > * Changes to data model to support zero copy interface to other data > > > layouts, more efficient APIs, more cell types, more dataset types etc. > > > * Better separation of a public, wrapped API and toolkit/C++ internal > API > > > mainly to support efficiency > > > * Introduction of C++ 11 features > > > > > > Much of this will require introducing changes that break backwards > > > compatibility and also require newer compilers, graphics cards / > drivers > > > etc. So the idea is that we will do our best to support as much as > possible > > > a broad set of architectures and backwards compatibility but break > things > > > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that > folks > > > that are stuck on legacy systems or code bases can continue to benefit > from > > > bug fixes. We have a way of continuing to maintain a broad set of > dashboards > > > and also the same review process as VTK master so that we can continue > to > > > ensure the quality of VTK 6.x as well as new releases. > > > > > > What do you guys think? Please provide feedback so that we can adjust > our > > > plans to meet the needs of the community as much as possible. > > > > I would like to put in a humble plea to add Python 3 compatibility to > that list: > > > > http://astrofrog.github.io/blog/2015/05/09/2015-survey-results > > > > Python 3 is being worked on (right now by me, and others can join in a > couple weeks once the core pieces are in place). No, it won't be part of > 6.3, however. > > > > - David > > > > _______________________________________________ > > 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: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtkusers > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtkusers > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Jul 2 09:23:02 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 2 Jul 2015 09:23:02 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: Hi Lin, > It works. :-) > I will look into the CGM then. Great. I am working on CGM as well, but you may beat me to it as my time is tight right now. David > > On Tue, Jun 30, 2015 at 3:30 PM, Lin M wrote: > This is a good idea! > > On Tue, Jun 30, 2015 at 3:24 PM, David Thompson wrote: > Hmmm. I think this would be a good time to use vtkMappedDataArray to create a version of the control point coordinates with 3 components that divides x, y, and z by the homogeneous coordinate. The vtkStructuredGrid's vtkPoints instance would own the vtkMappedDataArray, which would own a reference to the 4-component array (also owned by the PointData() of the vtkStructuredGrid). > > That will make rendering the control polygon easy and let GetDimensions() return the correct value. Just make sure that you call SetDimensions() before setting the vtkPoints array to be the vtkMappedDataArray. > > David > > > On Jun 30, 2015, at 3:19 PM, Lin M wrote: > > > > Yes, I can store it in PointData(), but splineData->GetDimensions(numControlPointsPerAxis) will not return the correct number of control points. It will return {0,0,0} if we hold the control points in PointData(). Though we can also hold a simple 1*3 array in vtkFieldData just like we store the length of knot vectors. > > > > On Tue, Jun 30, 2015 at 2:10 PM, David Thompson wrote: > > Hi Lin, > > > > > I didn't separate the homogenous coordinate with point coordinates but stored them all in a vtkDataArray with 4 components per tuple just as you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The current API is like > > > > > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) > > > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold information and data of nurbs control points, and the vtkSturcturedGrid only holds knot vectors and length. > > > > Actually, the vtkStructuredGrid can hold the control points as PointData() (as opposed to Point coordinates). There is no constraint on the number of components per tuple. The idea is to access the control points and knot data like this: > > > > vtkStructuredGrid* splineData; > > vtkDataArray* controlPoints = splineData->GetPointData()->GetArrayByName("control polygon"); > > vtkDataArray* knotVector = splineData->GetFieldData()->GetArrayByName("knot vector"); > > int numControlPointsPerAxis[3]; > > splineData->GetDimensions(numControlPointsPerAxis); > > > > That way all of the spline data is grouped into one dataset; it's just that the splineData's vtkPoints would not hold the control points. We could also store additional information in the arrays of splineData->GetFieldData(). For example, flags indicating which axes (if any) were periodic could be stored in a separate field-data array since there is no constraint on the number of components or tuples of field-data arrays. > > > > Does that make sense? > > > > David > > > > > > > From mathieu.westphal at kitware.com Thu Jul 2 09:24:11 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 2 Jul 2015 15:24:11 +0200 Subject: [vtk-developers] Failing test rendering problem Message-ID: Hi I have some problem with tests wich render and compare to an image. Lots of test do the rendering which can be seen on screen, but the generated image is completelly black ( or white ) and the test fail. Most of these failing tests are python test but not only. The list of failing tests is attached. I've tried to understood what was going on, so i've tried to fix sync3dAll.py Adding : import time time.sleep(1) renWin.Render() time.sleep(1) after the first render() did the trick. It look like the renderring is not done fast enough ans the produced image is empty as it has not yet been rendered. Any help appreciated. Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tests Type: application/octet-stream Size: 3794 bytes Desc: not available URL: From david.thompson at kitware.com Thu Jul 2 09:37:25 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 2 Jul 2015 09:37:25 -0400 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: Hi Mathieu, Thanks for looking into this. I've been noticing failures like that in VTK and in some projects that use it. However, given the number of image tests that VTK runs, adding 2s of delay to each one would slow the dashboards down too much to be usable. However, it is a great start on figuring out how to fix the issue. I don't see anywhere that vtkRenderWindow::WaitForCompletion() (which calls glFinish) gets called when grabbing the framebuffer. Perhaps adding this would be faster than a timer. Can you verify that it works? If so, maybe we can figure out where to add it to avoid slowing production code down for testing. Thanks, David > I have some problem with tests wich render and compare to an image. > > Lots of test do the rendering which can be seen on screen, but the generated image is completelly black ( or white ) and the test fail. > > Most of these failing tests are python test but not only. > The list of failing tests is attached. > > I've tried to understood what was going on, so i've tried to fix > sync3dAll.py > > Adding : > import time > time.sleep(1) > renWin.Render() > time.sleep(1) > > after the first render() did the trick. It look like the renderring is not done fast enough ans the produced image is empty as it has not yet been rendered. > > Any help appreciated. > > Mathieu Westphal > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From will.schroeder at kitware.com Thu Jul 2 10:10:45 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 2 Jul 2015 10:10:45 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: Bill I assume it's a leftover from some sort of sandbox experiment, so it makes sense to remove it unless there is a compelling application or integration hook, etc. I presume that you would also remove the (commented out) references in: ./Common/DataModel/Testing/Cxx/TestInterpolationDerivs.cxx ./Common/DataModel/Testing/Cxx/TestInterpolationFunctions.cxx W On Thu, Jul 2, 2015 at 9:12 AM, Bill Lorensen wrote: > Folks, > > vtkExplicitCell is not used nor tested anywhere in vtk. > > Can it be removed? > > Bill > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Jul 2 10:27:51 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 2 Jul 2015 10:27:51 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: I say yank it. On Thu, Jul 2, 2015 at 9:12 AM, Bill Lorensen wrote: > Folks, > > vtkExplicitCell is not used nor tested anywhere in vtk. > > Can it be removed? > > Bill > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Thu Jul 2 10:37:46 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 2 Jul 2015 10:37:46 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: Scratching my head a little bit I think I know why that class was created. There was a time when we were fooling around with making the NURBS, Bezier, etc. basis a type of cell. The idea was that if you had thousands of spline surfaces as in a CAD model you would explicitly instantiate these as cells, with all the commensurate trim edges, knot points, weights, etc. Currently I believe that there is a GSoC effort underway to introduce NURBS into VTK (again). I haven't followed it closely but from what I understand they are taking a different path. However given that this class is not currently used, there's no reason not to put it in the attic until a real reason for keeping it emerges. W On Thu, Jul 2, 2015 at 10:10 AM, Will Schroeder wrote: > Bill I assume it's a leftover from some sort of sandbox experiment, so it > makes sense to remove it unless there is a compelling application or > integration hook, etc. > > I presume that you would also remove the (commented out) references in: > ./Common/DataModel/Testing/Cxx/TestInterpolationDerivs.cxx > ./Common/DataModel/Testing/Cxx/TestInterpolationFunctions.cxx > > W > > On Thu, Jul 2, 2015 at 9:12 AM, Bill Lorensen > wrote: > >> Folks, >> >> vtkExplicitCell is not used nor tested anywhere in vtk. >> >> Can it be removed? >> >> Bill >> > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Thu Jul 2 10:45:39 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 2 Jul 2015 16:45:39 +0200 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: David, We discovered that interesting comment in vtkTesting.cxx (line 775): // Typically, the image testing is done using the back buffer // to avoid accidentally capturing overlapping window artifacts // in the image when using the front buffer. However, some graphics // drivers do not have up to date contents in the back buffer, // causing "failed" tests even though, upon visual inspection, the // front buffer looks perfectly valid... So: // // If the test failed using the back buffer, re-test using the // front buffer. This way, more tests pass on dashboards run with // the Intel HD built-in graphics drivers. We gonna change Testing.py to do the same - question: why this has never been done? :) J. *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-02 15:37 GMT+02:00 David Thompson : > Hi Mathieu, > > Thanks for looking into this. I've been noticing failures like that in VTK > and in some projects that use it. However, given the number of image tests > that VTK runs, adding 2s of delay to each one would slow the dashboards > down too much to be usable. However, it is a great start on figuring out > how to fix the issue. I don't see anywhere that > vtkRenderWindow::WaitForCompletion() (which calls glFinish) gets called > when grabbing the framebuffer. Perhaps adding this would be faster than a > timer. Can you verify that it works? If so, maybe we can figure out where > to add it to avoid slowing production code down for testing. > > Thanks, > David > > > I have some problem with tests wich render and compare to an image. > > > > Lots of test do the rendering which can be seen on screen, but the > generated image is completelly black ( or white ) and the test fail. > > > > Most of these failing tests are python test but not only. > > The list of failing tests is attached. > > > > I've tried to understood what was going on, so i've tried to fix > > sync3dAll.py > > > > Adding : > > import time > > time.sleep(1) > > renWin.Render() > > time.sleep(1) > > > > after the first render() did the trick. It look like the renderring is > not done fast enough ans the produced image is empty as it has not yet been > rendered. > > > > Any help appreciated. > > > > Mathieu Westphal > > _______________________________________________ > > 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: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Jul 2 10:49:17 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Jul 2015 10:49:17 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: All cells have a method IsExplicitCell(). They all return 0. I assume we should keep this method for backward compatibility? Bill On Thu, Jul 2, 2015 at 10:27 AM, Berk Geveci wrote: > I say yank it. > > On Thu, Jul 2, 2015 at 9:12 AM, Bill Lorensen > wrote: >> >> Folks, >> >> vtkExplicitCell is not used nor tested anywhere in vtk. >> >> Can it be removed? >> >> Bill >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From mathieu.westphal at kitware.com Thu Jul 2 10:49:43 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 2 Jul 2015 16:49:43 +0200 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: Hi It does not work sadly, tests behave exactly the same. Actually the test is passing only when the time is inferior or equal to 0.20 s, it will fait when the it's above. I've pinpointed the bug to be linked to a Front/Back buffer problem Thanks to jpuderoux, here is the fix https://gitlab.kitware.com/vtk/vtk/merge_requests/361 Mathieu Westphal On Thu, Jul 2, 2015 at 3:37 PM, David Thompson wrote: > Hi Mathieu, > > Thanks for looking into this. I've been noticing failures like that in VTK > and in some projects that use it. However, given the number of image tests > that VTK runs, adding 2s of delay to each one would slow the dashboards > down too much to be usable. However, it is a great start on figuring out > how to fix the issue. I don't see anywhere that > vtkRenderWindow::WaitForCompletion() (which calls glFinish) gets called > when grabbing the framebuffer. Perhaps adding this would be faster than a > timer. Can you verify that it works? If so, maybe we can figure out where > to add it to avoid slowing production code down for testing. > > Thanks, > David > > > I have some problem with tests wich render and compare to an image. > > > > Lots of test do the rendering which can be seen on screen, but the > generated image is completelly black ( or white ) and the test fail. > > > > Most of these failing tests are python test but not only. > > The list of failing tests is attached. > > > > I've tried to understood what was going on, so i've tried to fix > > sync3dAll.py > > > > Adding : > > import time > > time.sleep(1) > > renWin.Render() > > time.sleep(1) > > > > after the first render() did the trick. It look like the renderring is > not done fast enough ans the produced image is empty as it has not yet been > rendered. > > > > Any help appreciated. > > > > Mathieu Westphal > > _______________________________________________ > > 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: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.thirion at kitware.com Thu Jul 2 11:05:15 2015 From: tim.thirion at kitware.com (Tim Thirion) Date: Thu, 2 Jul 2015 11:05:15 -0400 Subject: [vtk-developers] Future development timeline for VTK on iOS? In-Reply-To: References: Message-ID: Hey David, To answer your various questions: iOS support in VTK is still young, yes, but we are encouraging developers to make the transition. In fact, I've used VTK for several iOS projects already, including the the project I'm working on today. Aside from a few minor bugs, I've found it to be 'full-featured,' as you said. We're eager to support early adopters, especially those who can tell us what's lacking for them. Other proposals edged out the KiwiViewer-to-VTK GSoC project, so that's on hold for now. We would still like to make that port when the resources become available. We don't have an exact timeline, but again, I encourage you to try out VTK for iOS. There are a couple iOS examples in the source tree that are good starting points. Hope that helps, Tim On Thu, Jul 2, 2015 at 8:35 AM, Busch, David E wrote: > Earlier we had anticipated releasing an iOS app to the app store that > made use of VES and the KiwiViewer. However, as of February, Apple no > longer accepts apps that do not have 64-bit support. Although VTK is > supposed to support iOS now, it appears as though the build is still in an > alpha state. Additionally, we noticed that there is VTK 2015 Google summer > of code project proposal for to update the KiwiViewer model viewer to work > with VTK. What are Kitware?s thoughts about a timeline for a full-featured > VTK and Kiwi or iOS, with maybe Kiwi as a 64-bit app store compliant > replacement for the original VES/Kiwi? > > David Busch > Mobile Applications Developer > University of Pittsburgh > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Jul 2 11:07:03 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 2 Jul 2015 11:07:03 -0400 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: You may notice from git blame, those comments were added only recently, in October 2014 in commit e136e01e... I didn't even know when I did that commit that there was a python equivalent to vtkTesting.cxx. I wonder why vtkTesting.cxx isn't simply wrapped and used directly from python...? David C. On Thu, Jul 2, 2015 at 10:45 AM, Joachim Pouderoux wrote: > David, > > We discovered that interesting comment in vtkTesting.cxx (line 775): > > // Typically, the image testing is done using the back buffer > // to avoid accidentally capturing overlapping window artifacts > // in the image when using the front buffer. However, some graphics > // drivers do not have up to date contents in the back buffer, > // causing "failed" tests even though, upon visual inspection, the > // front buffer looks perfectly valid... So: > // > // If the test failed using the back buffer, re-test using the > // front buffer. This way, more tests pass on dashboards run with > // the Intel HD built-in graphics drivers. > > We gonna change Testing.py to do the same - question: why this has never > been done? :) > > J. > > Joachim Pouderoux > > PhD, Technical Expert > Kitware SAS > > > 2015-07-02 15:37 GMT+02:00 David Thompson : >> >> Hi Mathieu, >> >> Thanks for looking into this. I've been noticing failures like that in VTK >> and in some projects that use it. However, given the number of image tests >> that VTK runs, adding 2s of delay to each one would slow the dashboards down >> too much to be usable. However, it is a great start on figuring out how to >> fix the issue. I don't see anywhere that >> vtkRenderWindow::WaitForCompletion() (which calls glFinish) gets called when >> grabbing the framebuffer. Perhaps adding this would be faster than a timer. >> Can you verify that it works? If so, maybe we can figure out where to add it >> to avoid slowing production code down for testing. >> >> Thanks, >> David >> >> > I have some problem with tests wich render and compare to an image. >> > >> > Lots of test do the rendering which can be seen on screen, but the >> > generated image is completelly black ( or white ) and the test fail. >> > >> > Most of these failing tests are python test but not only. >> > The list of failing tests is attached. >> > >> > I've tried to understood what was going on, so i've tried to fix >> > sync3dAll.py >> > >> > Adding : >> > import time >> > time.sleep(1) >> > renWin.Render() >> > time.sleep(1) >> > >> > after the first render() did the trick. It look like the renderring is >> > not done fast enough ans the produced image is empty as it has not yet been >> > rendered. >> > >> > Any help appreciated. >> > >> > Mathieu Westphal >> > _______________________________________________ >> > 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: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From joachim.pouderoux at kitware.com Thu Jul 2 11:14:32 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 2 Jul 2015 17:14:32 +0200 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: Indeed, sorry David, I should have blame, I mean greet your for this fix! :) *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-02 17:07 GMT+02:00 David Cole : > You may notice from git blame, those comments were added only > recently, in October 2014 in commit e136e01e... > > I didn't even know when I did that commit that there was a python > equivalent to vtkTesting.cxx. I wonder why vtkTesting.cxx isn't simply > wrapped and used directly from python...? > > > David C. > > > > On Thu, Jul 2, 2015 at 10:45 AM, Joachim Pouderoux > wrote: > > David, > > > > We discovered that interesting comment in vtkTesting.cxx (line 775): > > > > // Typically, the image testing is done using the back buffer > > // to avoid accidentally capturing overlapping window artifacts > > // in the image when using the front buffer. However, some graphics > > // drivers do not have up to date contents in the back buffer, > > // causing "failed" tests even though, upon visual inspection, the > > // front buffer looks perfectly valid... So: > > // > > // If the test failed using the back buffer, re-test using the > > // front buffer. This way, more tests pass on dashboards run with > > // the Intel HD built-in graphics drivers. > > > > We gonna change Testing.py to do the same - question: why this has never > > been done? :) > > > > J. > > > > Joachim Pouderoux > > > > PhD, Technical Expert > > Kitware SAS > > > > > > 2015-07-02 15:37 GMT+02:00 David Thompson : > >> > >> Hi Mathieu, > >> > >> Thanks for looking into this. I've been noticing failures like that in > VTK > >> and in some projects that use it. However, given the number of image > tests > >> that VTK runs, adding 2s of delay to each one would slow the dashboards > down > >> too much to be usable. However, it is a great start on figuring out how > to > >> fix the issue. I don't see anywhere that > >> vtkRenderWindow::WaitForCompletion() (which calls glFinish) gets called > when > >> grabbing the framebuffer. Perhaps adding this would be faster than a > timer. > >> Can you verify that it works? If so, maybe we can figure out where to > add it > >> to avoid slowing production code down for testing. > >> > >> Thanks, > >> David > >> > >> > I have some problem with tests wich render and compare to an image. > >> > > >> > Lots of test do the rendering which can be seen on screen, but the > >> > generated image is completelly black ( or white ) and the test fail. > >> > > >> > Most of these failing tests are python test but not only. > >> > The list of failing tests is attached. > >> > > >> > I've tried to understood what was going on, so i've tried to fix > >> > sync3dAll.py > >> > > >> > Adding : > >> > import time > >> > time.sleep(1) > >> > renWin.Render() > >> > time.sleep(1) > >> > > >> > after the first render() did the trick. It look like the renderring is > >> > not done fast enough ans the produced image is empty as it has not > yet been > >> > rendered. > >> > > >> > Any help appreciated. > >> > > >> > Mathieu Westphal > >> > _______________________________________________ > >> > 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: > >> > http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Jul 2 11:28:37 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 2 Jul 2015 11:28:37 -0400 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: > You may notice from git blame, those comments were added only > recently, in October 2014 in commit e136e01e... > > I didn't even know when I did that commit that there was a python > equivalent to vtkTesting.cxx. I wonder why vtkTesting.cxx isn't simply > wrapped and used directly from python...? Python's unittest.TestCase framework is handy, familiar to Python users, and breaks things into chunks that make running from an interpreter easier than the traditional tests (since you can import a test module, create the test instance, run setup, and manually run a test then tweak things from the interpreter after the test has run). I do not oppose wrapping vtkTesting, but do oppose banishing the vtk.test.vtkTest class. David From abhishek.iitd16 at gmail.com Fri Jul 3 00:32:10 2015 From: abhishek.iitd16 at gmail.com (Abhishek Kumar) Date: Fri, 3 Jul 2015 10:02:10 +0530 Subject: [vtk-developers] GSOC Project mid term summary Message-ID: Hello everyone, I have updated my project blog with week-wise summaries. I have listed tasks attempted, completed and problems faced during the tasks. Blog link: http://ilikeitparallel.blogspot.com. Please have a look. -- Regards Abhishek Kumar abhishekkumar.me Senior Undergraduate, IIT Delhi CSE -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Jul 3 04:34:00 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 3 Jul 2015 10:34:00 +0200 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: After further investigation, Joachim and me consider that the vtkTesting::FrontBuffer and associated argument "-FrontBuffer" to be basically useless, as one do not care if a test succeed using an image from the Front or the Back buffer, as long as a corresponding image can be found in any image buffer. Is anyone using this "-FrontBuffer" option ? If not we will deprecate it for further removal. it will allow to *always* check front and back buffer in vtkTesting, which is already the case when using static method vtkTesting::test. We propose this because there is a wrapping of vtkTesting which is massivelly used in Python test : vtkTclTest2Py/rtImageTest.py and may fail for the same reason explained before in this thread. And we think that removing the FrontBuffer option from vtkTesting is the right way to go here. It will not change the already proposed and working patch for Testing.py which do not use vtkTesting. Mathieu Westphal On Thu, Jul 2, 2015 at 5:28 PM, David Thompson wrote: > > You may notice from git blame, those comments were added only > > recently, in October 2014 in commit e136e01e... > > > > I didn't even know when I did that commit that there was a python > > equivalent to vtkTesting.cxx. I wonder why vtkTesting.cxx isn't simply > > wrapped and used directly from python...? > > Python's unittest.TestCase framework is handy, familiar to Python users, > and breaks things into chunks that make running from an interpreter easier > than the traditional tests (since you can import a test module, create the > test instance, run setup, and manually run a test then tweak things from > the interpreter after the test has run). > > I do not oppose wrapping vtkTesting, but do oppose banishing the > vtk.test.vtkTest class. > > David > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Jul 3 04:54:17 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 3 Jul 2015 10:54:17 +0200 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: Also, another track could be investigated, the use of vtkRenderWindow::SetOffScreenRendering remove the need of any Front/Bak buffer fiddling, the image being always accessible. However, it means we need to render it two times, one for the tester to actually see the image, one for the offscreen renderring. it would look like that in Testing.py: w2if = vtk.vtkWindowToImageFilter() # w2if.ReadFrontBufferOff() removing this renwin.Render() # adding this renwin.SetOffScreenRendering(1) # and that w2if.SetInput(renwin) w2if.Update() compareImageWithSavedImage(w2if, img_fname, threshold) But we may encounter some problem with the offscreen rendering, (antialiasing? multisampling? i don't know much about it ). What do you think ? Mathieu Westphal On Fri, Jul 3, 2015 at 10:34 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > After further investigation, Joachim and me consider that the > vtkTesting::FrontBuffer and associated argument "-FrontBuffer" to be > basically useless, as one do not care if a test succeed using an image from > the Front or the Back buffer, as long as a corresponding image can be found > in any image buffer. > > Is anyone using this "-FrontBuffer" option ? If not we will deprecate it > for further removal. > > it will allow to *always* check front and back buffer in vtkTesting, which > is already the case when using static method vtkTesting::test. > We propose this because there is a wrapping of vtkTesting which is > massivelly used in Python test : vtkTclTest2Py/rtImageTest.py and may fail > for the same reason explained before in this thread. > > And we think that removing the FrontBuffer option from vtkTesting is the > right way to go here. > It will not change the already proposed and working patch for Testing.py > which do not use vtkTesting. > > > Mathieu Westphal > > On Thu, Jul 2, 2015 at 5:28 PM, David Thompson > wrote: > >> > You may notice from git blame, those comments were added only >> > recently, in October 2014 in commit e136e01e... >> > >> > I didn't even know when I did that commit that there was a python >> > equivalent to vtkTesting.cxx. I wonder why vtkTesting.cxx isn't simply >> > wrapped and used directly from python...? >> >> Python's unittest.TestCase framework is handy, familiar to Python users, >> and breaks things into chunks that make running from an interpreter easier >> than the traditional tests (since you can import a test module, create the >> test instance, run setup, and manually run a test then tweak things from >> the interpreter after the test has run). >> >> I do not oppose wrapping vtkTesting, but do oppose banishing the >> vtk.test.vtkTest class. >> >> David >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Jul 3 05:56:13 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 3 Jul 2015 11:56:13 +0200 Subject: [vtk-developers] Adding a GIL ensure call before all call to python Message-ID: A client requesting us to apply a patch to paraview so every single call to python (PyRun, Py_Decref, PyImport, PyObject, PyString... ) to be surrounded by PyGILState_Ensure PyGILState_Release if VTK_NO_PYTHON_THREADS is not defined. is this acceptable ? some python calls are already done like that, see vtkPythonUtil.cxx. This option is defined to 1 by default. Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Jul 3 08:47:57 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 3 Jul 2015 08:47:57 -0400 Subject: [vtk-developers] Adding a GIL ensure call before all call to python In-Reply-To: References: Message-ID: Careful there. We took something very much like that out at ParaView 4.0. The GIL made ParaView incompatible with many python packages. When I get to my desk I can check my notes and refresh my memory. On Jul 3, 2015 5:56 AM, "Mathieu Westphal" wrote: > A client requesting us to apply a patch to paraview so every single call > to python > (PyRun, Py_Decref, PyImport, PyObject, PyString... ) to be surrounded by > PyGILState_Ensure > PyGILState_Release > > if VTK_NO_PYTHON_THREADS is not defined. > > is this acceptable ? some python calls are already done like that, see > vtkPythonUtil.cxx. > > This option is defined to 1 by default. > > > Mathieu Westphal > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jul 3 09:04:47 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 3 Jul 2015 09:04:47 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: Hi all, You are correct that the GSoC project is not using vtkExplicitCell. Instead, each NURBS patch will be a vtkStructuredGrid of control points with field data specifying knots. Collections of NURBS could live in a multiblock dataset. If you would prefer NURBS to be represented as cells instead of a special way to use a dataset, then we can keep vtkExplicit cell and adapt to it. But given that there are many different spline interpolants (NURBS, NURCCs, T-splines, point-based splines) it might be better to just consider them as datasets that are discretized at some point in a pipeline than as cells in their own right. David On Jul 2, 2015, at 10:49 AM, Bill Lorensen wrote: > All cells have a method IsExplicitCell(). They all return 0. I assume > we should keep this method for backward compatibility? > > Bill > > > On Thu, Jul 2, 2015 at 10:27 AM, Berk Geveci wrote: >> I say yank it. >> >> On Thu, Jul 2, 2015 at 9:12 AM, Bill Lorensen >> wrote: >>> >>> Folks, >>> >>> vtkExplicitCell is not used nor tested anywhere in vtk. >>> >>> Can it be removed? >>> >>> Bill >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers From david.thompson at kitware.com Fri Jul 3 09:10:36 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 3 Jul 2015 09:10:36 -0400 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: Hi Mathieu, > Also, another track could be investigated, the use of vtkRenderWindow::SetOffScreenRendering remove the need of any Front/Bak buffer fiddling, the image being always accessible. ... > But we may encounter some problem with the offscreen rendering, (antialiasing? multisampling? i don't know much about it ). I think you are correct in anticipating trouble. At least on some old platforms (and probably some newer ones, too) offscreen rendering is handled differently by the driver and often as software-only rendering. That would slow down many tests as well as make their results different from what users would see (making them not really test what we want). However, I know a lot of developers want to be able to run image tests in the background without windows popping up. So I am all for adding it as an option dependent on some environment variable or command-line argument being set. It should not be the default, though. David From will.schroeder at kitware.com Fri Jul 3 09:11:31 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 3 Jul 2015 09:11:31 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: Long term I'd like to think how we could represent a CAD model with a large number of trimmed splines. On Fri, Jul 3, 2015 at 9:04 AM, David Thompson wrote: > Hi all, > > You are correct that the GSoC project is not using vtkExplicitCell. > Instead, each NURBS patch will be a vtkStructuredGrid of control points > with field data specifying knots. Collections of NURBS could live in a > multiblock dataset. > > If you would prefer NURBS to be represented as cells instead of a special > way to use a dataset, then we can keep vtkExplicit cell and adapt to it. > But given that there are many different spline interpolants (NURBS, NURCCs, > T-splines, point-based splines) it might be better to just consider them as > datasets that are discretized at some point in a pipeline than as cells in > their own right. > > David > > On Jul 2, 2015, at 10:49 AM, Bill Lorensen > wrote: > > > All cells have a method IsExplicitCell(). They all return 0. I assume > > we should keep this method for backward compatibility? > > > > Bill > > > > > > On Thu, Jul 2, 2015 at 10:27 AM, Berk Geveci > wrote: > >> I say yank it. > >> > >> On Thu, Jul 2, 2015 at 9:12 AM, Bill Lorensen > >> wrote: > >>> > >>> Folks, > >>> > >>> vtkExplicitCell is not used nor tested anywhere in vtk. > >>> > >>> Can it be removed? > >>> > >>> Bill > >>> _______________________________________________ > >>> 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: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >> > > > > > > > > -- > > Unpaid intern in BillsBasement at noware dot com > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jul 3 09:15:01 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 3 Jul 2015 09:15:01 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: > Long term I'd like to think how we could represent a CAD model with a large number of trimmed splines. What problem do you foresee with a multiblock of structured grids? The memory overhead of vtkStructuredGrid? It seems pretty minimal to me compared to the b-reps CAD packages use and the multiblock dataset need not be flat... it could be a bounding box hierarchy for fast culling of irrelevant patches. David From mathieu.westphal at kitware.com Fri Jul 3 09:18:31 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 3 Jul 2015 15:18:31 +0200 Subject: [vtk-developers] Failing test rendering problem In-Reply-To: References: Message-ID: Yes, I supose it would remove overlapping problem as well. an option would be nice. Well my initial fix is working great. I will wait a bit to see if anyone is disturbed by the vtkTesting::FrontFrame deprecation before merging. Mathieu Westphal On Fri, Jul 3, 2015 at 3:10 PM, David Thompson wrote: > Hi Mathieu, > > > Also, another track could be investigated, the use of > vtkRenderWindow::SetOffScreenRendering remove the need of any Front/Bak > buffer fiddling, the image being always accessible. ... > > But we may encounter some problem with the offscreen rendering, > (antialiasing? multisampling? i don't know much about it ). > > I think you are correct in anticipating trouble. At least on some old > platforms (and probably some newer ones, too) offscreen rendering is > handled differently by the driver and often as software-only rendering. > That would slow down many tests as well as make their results different > from what users would see (making them not really test what we want). > > However, I know a lot of developers want to be able to run image tests in > the background without windows popping up. So I am all for adding it as an > option dependent on some environment variable or command-line argument > being set. It should not be the default, though. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Jul 3 09:43:21 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 3 Jul 2015 09:43:21 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: This could work, although I'm not quite seeing how trim edges would fit in. Also sometimes there are supplemental structures like polygonal tessellations to help speed up geometric operations, etc. On Fri, Jul 3, 2015 at 9:15 AM, David Thompson wrote: > > Long term I'd like to think how we could represent a CAD model with a > large number of trimmed splines. > > What problem do you foresee with a multiblock of structured grids? The > memory overhead of vtkStructuredGrid? It seems pretty minimal to me > compared to the b-reps CAD packages use and the multiblock dataset need not > be flat... it could be a bounding box hierarchy for fast culling of > irrelevant patches. > > David -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Jul 3 09:59:59 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 3 Jul 2015 09:59:59 -0400 Subject: [vtk-developers] Adding a GIL ensure call before all call to python In-Reply-To: References: Message-ID: This was the commit I was referring to. http://review.source.kitware.com/#/c/11214/ David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Jul 3, 2015 at 8:47 AM, David E DeMarle wrote: > Careful there. We took something very much like that out at ParaView 4.0. > The GIL made ParaView incompatible with many python packages. When I get to > my desk I can check my notes and refresh my memory. > On Jul 3, 2015 5:56 AM, "Mathieu Westphal" > wrote: > >> A client requesting us to apply a patch to paraview so every single call >> to python >> (PyRun, Py_Decref, PyImport, PyObject, PyString... ) to be surrounded by >> PyGILState_Ensure >> PyGILState_Release >> >> if VTK_NO_PYTHON_THREADS is not defined. >> >> is this acceptable ? some python calls are already done like that, see >> vtkPythonUtil.cxx. >> >> This option is defined to 1 by default. >> >> >> Mathieu Westphal >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jul 3 11:22:40 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 3 Jul 2015 11:22:40 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: References: Message-ID: <81D70D39-F3AB-4578-BD9A-630BDA49AE72@kitware.com> > This could work, although I'm not quite seeing how trim edges would fit in. All the trimming I've seen done in CAD BReps is in world coordinates with splined curves that represent the bounding edges of the surface, not in parameter space; meaning that the bounding curves would also exist in the multiblock of structured grids and could thus be referenced in a surface's field data (by block ID, for instance). I agree that we would have to figure something out if given a trim polygon in parameter-space coordinates. That doesn't seem like an insurmountable obstacle, though. And having a NURBS representation using standard VTK datasets with adaptor classes that provide access and convenience methods seems really desirable so that filters can be used on the control polygon point coordinates and point data (e.g., vtkArrayCalculator, vtkWarpScalars/Vectors). > Also sometimes there are supplemental structures like polygonal tessellations to help speed up geometric operations, etc. What Lin is working on now is generating those tessellations for rendering. Assuming we generate a multiblock of unstructured grid tessellations in the same tree structure, it could be used for both rendering and accelerating geometric operations. David > > On Fri, Jul 3, 2015 at 9:15 AM, David Thompson wrote: > > Long term I'd like to think how we could represent a CAD model with a large number of trimmed splines. > > What problem do you foresee with a multiblock of structured grids? The memory overhead of vtkStructuredGrid? It seems pretty minimal to me compared to the b-reps CAD packages use and the multiblock dataset need not be flat... it could be a bounding box hierarchy for fast culling of irrelevant patches. > > David > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 From will.schroeder at kitware.com Fri Jul 3 11:39:31 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 3 Jul 2015 11:39:31 -0400 Subject: [vtk-developers] vtkExplicitCell In-Reply-To: <81D70D39-F3AB-4578-BD9A-630BDA49AE72@kitware.com> References: <81D70D39-F3AB-4578-BD9A-630BDA49AE72@kitware.com> Message-ID: This is very exciting. Thanks for the update. Once we can represent NURBS properly we'll have to build a CAD modeller (just a few decades of work :-) but boy would I like to have a nice, open modeller that interfaces into VTK well). W On Fri, Jul 3, 2015 at 11:22 AM, David Thompson wrote: > > This could work, although I'm not quite seeing how trim edges would fit > in. > > All the trimming I've seen done in CAD BReps is in world coordinates with > splined curves that represent the bounding edges of the surface, not in > parameter space; meaning that the bounding curves would also exist in the > multiblock of structured grids and could thus be referenced in a surface's > field data (by block ID, for instance). > > I agree that we would have to figure something out if given a trim polygon > in parameter-space coordinates. That doesn't seem like an insurmountable > obstacle, though. And having a NURBS representation using standard VTK > datasets with adaptor classes that provide access and convenience methods > seems really desirable so that filters can be used on the control polygon > point coordinates and point data (e.g., vtkArrayCalculator, > vtkWarpScalars/Vectors). > > > Also sometimes there are supplemental structures like polygonal > tessellations to help speed up geometric operations, etc. > > What Lin is working on now is generating those tessellations for > rendering. Assuming we generate a multiblock of unstructured grid > tessellations in the same tree structure, it could be used for both > rendering and accelerating geometric operations. > > David > > > > > On Fri, Jul 3, 2015 at 9:15 AM, David Thompson < > david.thompson at kitware.com> wrote: > > > Long term I'd like to think how we could represent a CAD model with a > large number of trimmed splines. > > > > What problem do you foresee with a multiblock of structured grids? The > memory overhead of vtkStructuredGrid? It seems pretty minimal to me > compared to the b-reps CAD packages use and the multiblock dataset need not > be flat... it could be a bounding box hierarchy for fast culling of > irrelevant patches. > > > > David > > > > > > > > -- > > William J. Schroeder, PhD > > Kitware, Inc. > > 28 Corporate Drive > > Clifton Park, NY 12065 > > will.schroeder at kitware.com > > http://www.kitware.com > > (518) 881-4902 > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Jul 6 14:16:17 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Jul 2015 14:16:17 -0400 Subject: [vtk-developers] QVTKWidget2 status Message-ID: <20150706181617.GA27725@megas.kitware.com> Hi, Does anyone have any experience with QVTKWidget2? I've been having trouble integrating it into ParaView with the following results: - simply replacing it causes an external window to appear where the rendering happens (which looks correct), but with no interaction at all; - making a vtkGenericOpenGLRenderWindow (or vtkExternalOpenGLRenderWindow) and passing it to the widget gets rid of the extra window, but it never rendered (either blank or random previous bits of video memory shown); - hooking up events and callbacks to manually call updateGL, paintGL, and Frame has the background render, but none of the actors (which are present according to gdb). I've tried a small application which adds QVTKWidget2 to a QMainWindow and it never renders anything, it just shows previous video memory chunks. The example which uses it (qtgraphicsview) crashes with either Qt4 or Qt5 when making the OpenGL graphics context current. There is a test in GUISupport/Qt/Python which (tries) to use it, but it isn't added to the VTK test suite[1] and doesn't work anyways (QVTKWidget2 is not wrapped into Python[2]). The only non-VTK reference I've been able to find of QVTKWidget2 (that isn't from 2012 or earlier) is from a github project[3] where QVTKWidget works, but QVTKWidget2 does not (with master). All of this points to QVTKWidget2 having worked at one point, but it got broken somewhere along the line. Does anyone know of a good hash or tag to start bisecting from (I'm starting to jump back releases until my test programs stop compiling)? Thanks, --Ben [1]Seems it got removed here, probably by accident: commit c13ff7ba71fb01995a7232b766ab960124af57dc Author: VTK Developers Date: Mon Apr 9 10:03:20 2012 -0400 Remove monolithic VTK files not used after modularization The modular VTK build system completely replaces the old monolithic CMake code. [2]There is a .sip file for it, but nothing uses it. The CMake code for SIP logic also looks very outdated; from 2010. [3]https://github.com/jlabroquere/vtkwidget-test From dave.demarle at kitware.com Mon Jul 6 14:52:36 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 6 Jul 2015 14:52:36 -0400 Subject: [vtk-developers] GSOC Project mid term summary In-Reply-To: References: Message-ID: Thanks for the updates Abhishek. Looks like you are picking up speed and have gotten over most of the big software on big machines annoyances now. Here's to smoother sailing forward! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Jul 3, 2015 at 12:32 AM, Abhishek Kumar wrote: > Hello everyone, > > I have updated my project blog with week-wise summaries. I have listed > tasks attempted, completed and problems faced during the tasks. > > Blog link: http://ilikeitparallel.blogspot.com. > > Please have a look. > > -- > Regards > > Abhishek Kumar > abhishekkumar.me > Senior Undergraduate, IIT Delhi CSE > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Jul 6 16:10:30 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Jul 2015 16:10:30 -0400 Subject: [vtk-developers] QVTKWidget2 status In-Reply-To: <20150706181617.GA27725@megas.kitware.com> References: <20150706181617.GA27725@megas.kitware.com> Message-ID: <20150706201030.GA6564@megas.kitware.com> On Mon, Jul 06, 2015 at 14:16:17 -0400, Ben Boeckel wrote: > All of this points to QVTKWidget2 having worked at one point, but it got > broken somewhere along the line. Does anyone know of a good hash or tag > to start bisecting from (I'm starting to jump back releases until my > test programs stop compiling)? Status update. 6.1 works and I started bisecting there. One problem (crashes on master) is avoided by commenting out: this->SetMultiSamples(this->mRenWin->GetGlobalMaximumNumberOfMultiSamples()); in QVTKWidget2::SetRenderWindow. It was introduced here: commit 87b5c8c813a9b77e70040bd4da2da3a443c07d14 Author: Christoph Kolb Date: Wed Jan 14 15:37:20 2015 +0100 Add a method to enable multisampling in the QVTKWidget2 GetGlobalMaximumNumberOfMultiSamples is used as the default value in order to restore the default behavior of QVTKWidget I'm bisecting with this line commented out to find out why the view is blank. --Ben From ben.boeckel at kitware.com Mon Jul 6 18:02:50 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Jul 2015 18:02:50 -0400 Subject: [vtk-developers] QVTKWidget2 status In-Reply-To: <20150706201030.GA6564@megas.kitware.com> References: <20150706181617.GA27725@megas.kitware.com> <20150706201030.GA6564@megas.kitware.com> Message-ID: <20150706220250.GA13304@megas.kitware.com> On Mon, Jul 06, 2015 at 16:10:30 -0400, Ben Boeckel wrote: > Status update. 6.1 works and I started bisecting there. One problem > (crashes on master) is avoided by commenting out: > > this->SetMultiSamples(this->mRenWin->GetGlobalMaximumNumberOfMultiSamples()); Poking around with this so far today, it seems that the only things I can get to happen are either segfaults or blank screens. There also still appears to be problems with depth testing with Qt5 (you can see through some faces unless Cull Backface is used). Depth testing is enabled however, so something weirder is going on. > I'm bisecting with this line commented out to find out why the view is > blank. https://gitlab.kitware.com/vtk/vtk/merge_requests/372 --Ben From mathieu.westphal at kitware.com Tue Jul 7 02:30:10 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 7 Jul 2015 08:30:10 +0200 Subject: [vtk-developers] Adding a GIL ensure call before all call to python In-Reply-To: References: Message-ID: Ok, so we may add another option in cmake like : VTK_PYTHON_GIL_EVERYWHERE, so it will not break anything. Mathieu Westphal On Fri, Jul 3, 2015 at 3:59 PM, David E DeMarle wrote: > This was the commit I was referring to. > http://review.source.kitware.com/#/c/11214/ > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Fri, Jul 3, 2015 at 8:47 AM, David E DeMarle > wrote: > >> Careful there. We took something very much like that out at ParaView 4.0. >> The GIL made ParaView incompatible with many python packages. When I get to >> my desk I can check my notes and refresh my memory. >> On Jul 3, 2015 5:56 AM, "Mathieu Westphal" >> wrote: >> >>> A client requesting us to apply a patch to paraview so every single call >>> to python >>> (PyRun, Py_Decref, PyImport, PyObject, PyString... ) to be surrounded by >>> PyGILState_Ensure >>> PyGILState_Release >>> >>> if VTK_NO_PYTHON_THREADS is not defined. >>> >>> is this acceptable ? some python calls are already done like that, see >>> vtkPythonUtil.cxx. >>> >>> This option is defined to 1 by default. >>> >>> >>> Mathieu Westphal >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Tue Jul 7 06:08:27 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 7 Jul 2015 03:08:27 -0700 (MST) Subject: [vtk-developers] Shoemake's arcball in VTK Message-ID: <1436263707921-5732740.post@n5.nabble.com> Hello everyone, I was just wondering whether someone had thought or worked towards an implementation of Shoemake's arcball in VTK which seems to me way better that the traditional trackball that I've seen so far. If not I think I'm going to try and implement it but I may need some help to integrate it to VTK. Have a very nice day, Best, Lonni -- View this message in context: http://vtk.1045678.n5.nabble.com/Shoemake-s-arcball-in-VTK-tp5732740.html Sent from the VTK - Dev mailing list archive at Nabble.com. From mathieu.westphal at kitware.com Tue Jul 7 07:54:06 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 7 Jul 2015 13:54:06 +0200 Subject: [vtk-developers] Reload button Message-ID: Hello A client is willing to have a reload button on it's filter panel, but we think it would be woth it to add a reload button on the interface, wich would basically Invoke Modified on a reader and apply the pipeline again. It may not work with some caching reader, but other than that i think it should be allright. What do you think ? Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Jul 7 14:58:27 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 7 Jul 2015 14:58:27 -0400 Subject: [vtk-developers] Ready to branch for 6.3? Message-ID: <20150707185827.GA26915@megas.kitware.com> Hi, Does anyone out that have work in progress that we should delay the release branch point for? We are hoping to get 6.3 started by the end of the week. Thanks, --Ben From andy.bauer at kitware.com Tue Jul 7 15:14:54 2015 From: andy.bauer at kitware.com (Andy Bauer) Date: Tue, 7 Jul 2015 15:14:54 -0400 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: <20150707185827.GA26915@megas.kitware.com> References: <20150707185827.GA26915@megas.kitware.com> Message-ID: I'm working on a slight improvement to particle paths that I'm testing right now that I'd like to get in 6.3. On Tue, Jul 7, 2015 at 2:58 PM, Ben Boeckel wrote: > Hi, > > Does anyone out that have work in progress that we should delay the > release branch point for? > > We are hoping to get 6.3 started by the end of the week. > > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Jul 7 15:24:13 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 07 Jul 2015 19:24:13 +0000 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: References: <20150707185827.GA26915@megas.kitware.com> Message-ID: Working with Dave L., I need to work on marking all mapped array classes are deprecated for 6.3 to be removed in 7.0. On Tue, Jul 7, 2015 at 3:15 PM Andy Bauer wrote: > I'm working on a slight improvement to particle paths that I'm testing > right now that I'd like to get in 6.3. > > On Tue, Jul 7, 2015 at 2:58 PM, Ben Boeckel > wrote: > >> Hi, >> >> Does anyone out that have work in progress that we should delay the >> release branch point for? >> >> We are hoping to get 6.3 started by the end of the week. >> >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Tue Jul 7 15:38:59 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 7 Jul 2015 15:38:59 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: Hi Dr. Thompson, I read the document for BRep format and checked those files in CGM/test. It seems that only a small part of the test files contains bezier/b-spline surfaces and all these files contains quite a number of different kinds of shapes. I can write a class to read such file but it will only display the bezier/b-spline part. I'm afraid that it will just be a piece of the original shape which the file represents. Do you think I should do that or there is a better way to load external shape? PS. I opened a new google doc to summarize what we have done now. I will update new progress to it during the development. (link ) Best, Lin On Thu, Jul 2, 2015 at 9:23 AM, David Thompson wrote: > Hi Lin, > > > It works. :-) > > I will look into the CGM then. > > Great. I am working on CGM as well, but you may beat me to it as my time > is tight right now. > > David > > > > > On Tue, Jun 30, 2015 at 3:30 PM, Lin M wrote: > > This is a good idea! > > > > On Tue, Jun 30, 2015 at 3:24 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hmmm. I think this would be a good time to use vtkMappedDataArray to > create a version of the control point coordinates with 3 components that > divides x, y, and z by the homogeneous coordinate. The vtkStructuredGrid's > vtkPoints instance would own the vtkMappedDataArray, which would own a > reference to the 4-component array (also owned by the PointData() of the > vtkStructuredGrid). > > > > That will make rendering the control polygon easy and let > GetDimensions() return the correct value. Just make sure that you call > SetDimensions() before setting the vtkPoints array to be the > vtkMappedDataArray. > > > > David > > > > > On Jun 30, 2015, at 3:19 PM, Lin M wrote: > > > > > > Yes, I can store it in PointData(), but > splineData->GetDimensions(numControlPointsPerAxis) will not return the > correct number of control points. It will return {0,0,0} if we hold the > control points in PointData(). Though we can also hold a simple 1*3 array > in vtkFieldData just like we store the length of knot vectors. > > > > > > On Tue, Jun 30, 2015 at 2:10 PM, David Thompson < > david.thompson at kitware.com> wrote: > > > Hi Lin, > > > > > > > I didn't separate the homogenous coordinate with point coordinates > but stored them all in a vtkDataArray with 4 components per tuple just as > you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. > The current API is like > > > > > > > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* > outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) > > > > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold > information and data of nurbs control points, and the vtkSturcturedGrid > only holds knot vectors and length. > > > > > > Actually, the vtkStructuredGrid can hold the control points as > PointData() (as opposed to Point coordinates). There is no constraint on > the number of components per tuple. The idea is to access the control > points and knot data like this: > > > > > > vtkStructuredGrid* splineData; > > > vtkDataArray* controlPoints = > splineData->GetPointData()->GetArrayByName("control polygon"); > > > vtkDataArray* knotVector = > splineData->GetFieldData()->GetArrayByName("knot vector"); > > > int numControlPointsPerAxis[3]; > > > splineData->GetDimensions(numControlPointsPerAxis); > > > > > > That way all of the spline data is grouped into one dataset; it's just > that the splineData's vtkPoints would not hold the control points. We could > also store additional information in the arrays of > splineData->GetFieldData(). For example, flags indicating which axes (if > any) were periodic could be stored in a separate field-data array since > there is no constraint on the number of components or tuples of field-data > arrays. > > > > > > Does that make sense? > > > > > > David > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jul 8 13:12:36 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Jul 2015 13:12:36 -0400 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: <20150707185827.GA26915@megas.kitware.com> References: <20150707185827.GA26915@megas.kitware.com> Message-ID: <20150708171236.270037860@mail.rogue-research.com> On Tue, 7 Jul 2015 14:58:27 -0400, Ben Boeckel said: >Does anyone out that have work in progress that we should delay the >release branch point for? > >We are hoping to get 6.3 started by the end of the week. We've just today noticed a serious performance regression in our app that seems to have been caused by something between VTK 6.2 and 20e54ae5e893e38a19d81701b6df92ab8ab17c8b (2015-04-21). I'm looking into this today... Also, I'd like to get this into 6.3: Considering the plan to start requiring newer OS/compilers, it would be good start by documenting current requirements, IMHO. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Wed Jul 8 14:11:11 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Jul 2015 14:11:11 -0400 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). Message-ID: <20150708181111.1666394198@mail.rogue-research.com> Hi all, As a mentioned in another thread, we've found a big slowdown in our app between 6.2 and 6.3. Profiling with Instruments reveals lots of time is being spent locking & unlocking a mutex in vtkLookupTableMapData(). Looking through git history shows the culprit: ---------------------------- commit dac748aedd7ffdc5aca6d555e74c668451ef4772 Author: Cory Quammen Date: Sun Mar 15 00:33:11 2015 -0400 BUG 15365: Fixed crash in function called from multiple threads vtkLookupTableMapData() was not thread safe and could lead to crashes when accessed from multiple threads. Added a mutex around the logic to determine if the color table size needed to be increased. Added a multi-threaded test that crashes on occasion prior to this patch, but does not crash with this patch applied. ---------------------------- Indeed the added code has the comment: // Since this involves a potential array resize and this function // might be accessed concurently from more than one thread, we need a // mutex here. This shouldn't affect performance much if this function // is used to map many input values, but if it is called repeatedly // with short input arrays, performance may be much worse. So, for my use case, performance is indeed much worse. :( As a hack, I removed the lock/unlock and performance is back to 6.2-level. Help? :) -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From cory.quammen at kitware.com Wed Jul 8 14:40:47 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 8 Jul 2015 13:40:47 -0500 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). In-Reply-To: <20150708181111.1666394198@mail.rogue-research.com> References: <20150708181111.1666394198@mail.rogue-research.com> Message-ID: Sean, I will take a look. Cory On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride wrote: > Hi all, > > As a mentioned in another thread, we've found a big slowdown in our app > between 6.2 and 6.3. Profiling with Instruments reveals lots of time is > being spent locking & unlocking a mutex in vtkLookupTableMapData(). > Looking through git history shows the culprit: > > ---------------------------- > commit dac748aedd7ffdc5aca6d555e74c668451ef4772 > Author: Cory Quammen > Date: Sun Mar 15 00:33:11 2015 -0400 > > BUG 15365: Fixed crash in function called from multiple threads > > vtkLookupTableMapData() was not thread safe and could lead to > crashes when accessed from multiple threads. Added a mutex around > the logic to determine if the color table size needed to be > increased. > > Added a multi-threaded test that crashes on occasion prior > to this patch, but does not crash with this patch applied. > ---------------------------- > > Indeed the added code has the comment: > > // Since this involves a potential array resize and this function > // might be accessed concurently from more than one thread, we need a > // mutex here. This shouldn't affect performance much if this function > // is used to map many input values, but if it is called repeatedly > // with short input arrays, performance may be much worse. > > So, for my use case, performance is indeed much worse. :( > > As a hack, I removed the lock/unlock and performance is back to 6.2-level. > > Help? :) > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Wed Jul 8 14:47:41 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 8 Jul 2015 14:47:41 -0400 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). In-Reply-To: References: <20150708181111.1666394198@mail.rogue-research.com> Message-ID: Okay I am going to tread where I have no business going so please be patient :-) I'm curious as to whether anyone has tried vtkSMPTools atomics or any other form of atomic integers.... W On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen wrote: > Sean, > > I will take a look. > > Cory > > On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride > wrote: > >> Hi all, >> >> As a mentioned in another thread, we've found a big slowdown in our app >> between 6.2 and 6.3. Profiling with Instruments reveals lots of time is >> being spent locking & unlocking a mutex in vtkLookupTableMapData(). >> Looking through git history shows the culprit: >> >> ---------------------------- >> commit dac748aedd7ffdc5aca6d555e74c668451ef4772 >> Author: Cory Quammen >> Date: Sun Mar 15 00:33:11 2015 -0400 >> >> BUG 15365: Fixed crash in function called from multiple threads >> >> vtkLookupTableMapData() was not thread safe and could lead to >> crashes when accessed from multiple threads. Added a mutex around >> the logic to determine if the color table size needed to be >> increased. >> >> Added a multi-threaded test that crashes on occasion prior >> to this patch, but does not crash with this patch applied. >> ---------------------------- >> >> Indeed the added code has the comment: >> >> // Since this involves a potential array resize and this function >> // might be accessed concurently from more than one thread, we need a >> // mutex here. This shouldn't affect performance much if this function >> // is used to map many input values, but if it is called repeatedly >> // with short input arrays, performance may be much worse. >> >> So, for my use case, performance is indeed much worse. :( >> >> As a hack, I removed the lock/unlock and performance is back to 6.2-level. >> >> Help? :) >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Jul 8 15:01:58 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 8 Jul 2015 15:01:58 -0400 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). In-Reply-To: References: <20150708181111.1666394198@mail.rogue-research.com> Message-ID: It looks like that code can be refactored to do the resizing in some sort of initialization method. This comment: // Resize the internal table to hold the special colors at the // end. When this function is called repeatedly with the same size // lookup table, memory reallocation will be done only one the first // call if at all. indicates that the size does not change dynamically. Maybe it can be changed to always allocate for the special colors from the beginning? -berk On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen wrote: > Sean, > > I will take a look. > > Cory > > On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride > wrote: > >> Hi all, >> >> As a mentioned in another thread, we've found a big slowdown in our app >> between 6.2 and 6.3. Profiling with Instruments reveals lots of time is >> being spent locking & unlocking a mutex in vtkLookupTableMapData(). >> Looking through git history shows the culprit: >> >> ---------------------------- >> commit dac748aedd7ffdc5aca6d555e74c668451ef4772 >> Author: Cory Quammen >> Date: Sun Mar 15 00:33:11 2015 -0400 >> >> BUG 15365: Fixed crash in function called from multiple threads >> >> vtkLookupTableMapData() was not thread safe and could lead to >> crashes when accessed from multiple threads. Added a mutex around >> the logic to determine if the color table size needed to be >> increased. >> >> Added a multi-threaded test that crashes on occasion prior >> to this patch, but does not crash with this patch applied. >> ---------------------------- >> >> Indeed the added code has the comment: >> >> // Since this involves a potential array resize and this function >> // might be accessed concurently from more than one thread, we need a >> // mutex here. This shouldn't affect performance much if this function >> // is used to map many input values, but if it is called repeatedly >> // with short input arrays, performance may be much worse. >> >> So, for my use case, performance is indeed much worse. :( >> >> As a hack, I removed the lock/unlock and performance is back to 6.2-level. >> >> Help? :) >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Jul 8 17:06:53 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 8 Jul 2015 17:06:53 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: Hi Lin, > I read the document for BRep format and checked those files in CGM/test. It seems that only a small part of the test files contains bezier/b-spline surfaces and all these files contains quite a number of different kinds of shapes. I can write a class to read such file but it will only display the bezier/b-spline part. I'm afraid that it will just be a piece of the original shape which the file represents. Do you think I should do that or there is a better way to load external shape? I think it would be great to start with the parts of the CGM files that are NURBS. The remaining shapes should either be straight (lines, planes) or conics (for which you have written a few routines we can use to create patches that will represent them properly). > PS. I opened a new google doc to summarize what we have done now. I will update new progress to it during the development. (link) Great! David From ken.martin at kitware.com Wed Jul 8 17:19:20 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 8 Jul 2015 17:19:20 -0400 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: References: <2CE400AE-BADE-42F0-94B8-C693F222147C@kitware.com> Message-ID: Hello Alex, Your use case is definitely one that I would like to see work well in the current VTK with the new OpenGL2 backend. Currently the right mapper for this type of work is something called vtkCompositePolyDataMapper2 taking a composite dataset as input (See Rendering/Core/Testing/Cxx/TestCompositePolyDataMapper2.cxx for an example) Your use case may still run into performance issues as I have not tested changing just one part of a composite dataset, but if it does run into performance issues let me know as I do want that use case to work well and it really should :-) Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Berk Geveci *Sent:* Thursday, July 2, 2015 9:21 AM *To:* David Thompson *Cc:* Alex Malyushytskyy; VTK Developers; VTK Users *Subject:* Re: [vtk-developers] [vtkusers] VTK Roadmap I agree with David. This is currently the best path for scene graph style use, especially combined with the OpenGL2 backend. This will be available in VTK 6.3 and VTK 7 but continues to evolve. So please let us know if you run into issues, performance or otherwise. We also discussed developing a full-featured scene graph actor but it was not a high priority. VTK's major use cases center around a few large geometry objects or a large number of small objects that have related properties coming from a point/cell array (molecules, tensors etc.) However, we will continue to add more scene graph style capabilities to multi-block rendering. Probably including transform support per block, inheritance of properties from an upper node etc. Best, -berk On Thu, Jul 2, 2015 at 9:01 AM, David Thompson wrote: Hi Alex, I think there is a third option that would be much more usable; generating a multiblock dataset that uses a single actor and mapper, but in which each block can be independently replaced with an edited version. As long as the source only regenerates a small number of leaf nodes, this would not have a large impact on memory, rendering, or picking performance. David On Jul 1, 2015, at 11:49 PM, Alex Malyushytskyy wrote: > As a user I think VTK during last 2 major releases acquired performance issues which makes it very difficult if not impossible to use for my needs as a developer of CAD type applications. > > Let me explain. Typical CAD application functionality can be demonstrated on the building model. > Building consists of a few type of structural components: columns, beams, slabs and walls. > Geometry of such component is defined by different attributes. For column for example it might be section shape, cross-section dimension, etc. > User of the CAD system should be able to select/pick components on the screen, change such component attributes and should see geometry change on the screen fast enough. > > Lets say we want to create 60 story building with 100 rooms per floor. > This gives us 6000 components or about 50k rectangular cells. > > With vtk developer basically has 2 choices of the implementation: > 1) minimize number of actors. Lets say actor for whole building. In such case every component geometry is appended to the building polydata. So finally you have only 1 dataset, 1 mapper and 1 actor. > 2) create actor per component. In this case you have 1 dataset, 1 mapper and 1 actor per component. > > Unfortunately neither approach works well for CAD application when model has to be editable by user. At least not with VTK 6.0.1. > > Comparison of usage cases: > > - when you need to re-generate whole model geometry (for example file withy model description loaded). > Approach 1 demonstrates better performance even though it requires additional append filter execution. > Approach 2 is slow - from 6 to 10 times slower. For a building described above it would be 7-8 sec for Approach 1 and 30-40 sec for approach 2 on my system. > > - when you need to modify a single component and update presentation. > > Approach 1 takes basically the same time as regenerate model from the scratch. > It takes basically the same time as regenerate model from the scratch. > But 7 sec are not acceptable anymore. > Modification of the dataset itself takes no time. All time is taken by vtk pipeline. > So basically there is no way for improvement. > > - picking/selection components. > Approach 1 is slow. Keep in mind that user have to select components, not cells. > So in this case you have to add to cell field which would allow to keep track which component picked cells belong to. Then selection is equivalent of adding data field to polydata and after picking setting value to such field for all cells which belong to that component. > This is definitely slower than for Approach 2. When all you need to keep tracking and select appropriate actor . > > > Approach 2 is very fast(less than second). > User would might be able to survive slow initial model loading, > if there were not any other differences. > > Unfortunately when you look at the application memory usage such model when approach 2 is used will take over 1.5 GB of memory when in case of approach 1 just about 140k. > That is for single view. You would not be able to display such model in 2 views on 32 bit Windows. > > > That is counting that you static mode and ImmediateModeRenderingOn were set for mapper, > and no intermediate filters are stored ( vtkPolydata -> Mapper -> actor pipeline is used). > > With number of components increasing memory usage and time grow. > So basically described above model is about as big editable model as VTK can handle without user breaking monitor after 30 min of work. > > For comparison I was using hoops3d (1998-2000) for developing of 3D FEM pre-, post-processing application with similar capabilities. 15 years ago on the appropriate systems I've seen better performance. Also I believe that 10 years ago VTK did not require such memory to display such size of data with exactly the same pipeline. > I blame changes in vtk 5 and 6. > > As a conclusion I afraid vtk 6 is not useable if you have to deal with dynamic changeable systems of average size on a single computer. > > I wish that was targeted. If not in vtk 6, may be in vtk7. > > > On Tue, Jun 30, 2015 at 1:24 PM, Berk Geveci wrote: > Yup. Python 3 is now on the roadmap. Probably the first release after 7, in a few months. > > -berk > > On Tue, Jun 30, 2015 at 3:48 PM, David Gobbi wrote: > On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett wrote: > Hi, > > On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci wrote: > > Hi folks, > > > > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. VTK 7 > > will follow very shortly (in weeks). I'd like to shed some light here on our > > thinking and how we are planning to move forward. > > > > As was previously discussed in the VTK developers list [1] [2], we are > > considering maintaining VTK 6.x for a long time (3-5 years) while moving > > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes > > happening in the computing and C++ worlds and we would like evolve VTK more > > quickly to stay up to date. Some of the major changes that we are > > considering and/or working on are: > > > > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) > > * Multi/many-core support / SMP computing on CPUs and accelerators. VTK-m > > integration [3]. > > * Changes to data model to support zero copy interface to other data > > layouts, more efficient APIs, more cell types, more dataset types etc. > > * Better separation of a public, wrapped API and toolkit/C++ internal API > > mainly to support efficiency > > * Introduction of C++ 11 features > > > > Much of this will require introducing changes that break backwards > > compatibility and also require newer compilers, graphics cards / drivers > > etc. So the idea is that we will do our best to support as much as possible > > a broad set of architectures and backwards compatibility but break things > > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that folks > > that are stuck on legacy systems or code bases can continue to benefit from > > bug fixes. We have a way of continuing to maintain a broad set of dashboards > > and also the same review process as VTK master so that we can continue to > > ensure the quality of VTK 6.x as well as new releases. > > > > What do you guys think? Please provide feedback so that we can adjust our > > plans to meet the needs of the community as much as possible. > > I would like to put in a humble plea to add Python 3 compatibility to that list: > > http://astrofrog.github.io/blog/2015/05/09/2015-survey-results > > Python 3 is being worked on (right now by me, and others can join in a couple weeks once the core pieces are in place). No, it won't be part of 6.3, however. > > - David > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ Search the list archives at: http://markmail.org/search/?q=vtkusers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtkusers -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jul 8 18:46:33 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Jul 2015 18:46:33 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? Message-ID: <20150708224633.1147757911@mail.rogue-research.com> Hi all, Is there a way to detect at compile-time OpenGL vs OpenGL2 mode? Since my app uses Xcode, I have to do the factory initialization thing, and I'd like to be able to handle both cases as I test between both OpenGLs, ie: #if ??? #define vtkRenderingCore_AUTOINIT 3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL) #elif ??? #define vtkRenderingCore_AUTOINIT 3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL2) #endif I don't see anything in vtkConfigure.h. Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From andrew.amaclean at gmail.com Wed Jul 8 22:16:55 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Jul 2015 12:16:55 +1000 Subject: [vtk-developers] Ready to branch for 6.3? Message-ID: A minor thing relating to documentation. In http://www.vtk.org/doc/nightly/html/ the version number should be 6.3.0, this is generally updated to the next version once a version is released. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Jul 8 23:33:44 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 8 Jul 2015 23:33:44 -0400 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: References: Message-ID: Thanks. That is on the checklist and will happen after the branch occurs. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Jul 8, 2015 at 10:16 PM, Andrew Maclean wrote: > A minor thing relating to documentation. > > In http://www.vtk.org/doc/nightly/html/ the version number should be > 6.3.0, this is generally updated to the next version once a version is > released. > > Regards > Andrew > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Jul 9 03:17:35 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Jul 2015 17:17:35 +1000 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: References: Message-ID: Thanks David On Thu, Jul 9, 2015 at 1:33 PM, David E DeMarle wrote: > Thanks. > > That is on the checklist and will happen after the branch occurs. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Jul 8, 2015 at 10:16 PM, Andrew Maclean > wrote: > >> A minor thing relating to documentation. >> >> In http://www.vtk.org/doc/nightly/html/ the version number should be >> 6.3.0, this is generally updated to the next version once a version is >> released. >> >> Regards >> Andrew >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Thu Jul 9 06:10:17 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 9 Jul 2015 12:10:17 +0200 Subject: [vtk-developers] bug in vtkPointSet::FindCell Message-ID: There is a bug in vtkPointCell::FindCell I copy here my mantis bug and associated notes: http://www.vtk.org/Bug/view.php?id=15573 The current implementation of FindCell/ FindCellWalk is just wrong and not working in some case : See atached image. In the current implementation there is three pass : 1 : FindPoint, Check CellPoint 2 : Check first neighbor 3 : Check CellPoint within tolerance In the associated image, one can see the the first pass will find red star and only check Cell 1 the second pass will only check cell 2 the third pass will not check anything more Cell 3 will never be found. I propose a solution based on vtkStreamTracer surface implementation, which walk among neighbors more smartly using pcoords and cell boundary. See : https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 [^ ] What do you think ? Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled.png Type: image/png Size: 5477 bytes Desc: not available URL: From andrew.amaclean at gmail.com Thu Jul 9 07:39:26 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Jul 2015 21:39:26 +1000 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? Message-ID: Hi Sean, Off the top of my head, I think VTK_RENDERING_BACKEND is visible and this has the values OpenGL or OpenGL2. Regards Andrew > > ---------- Forwarded message ---------- > From: Sean McBride > To: > Cc: > Date: Wed, 8 Jul 2015 18:46:33 -0400 > Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? > Hi all, > > Is there a way to detect at compile-time OpenGL vs OpenGL2 mode? > > Since my app uses Xcode, I have to do the factory initialization thing, and I'd like to be able to handle both cases as I test between both OpenGLs, ie: > > #if ??? > #define vtkRenderingCore_AUTOINIT 3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL) > #elif ??? > #define vtkRenderingCore_AUTOINIT 3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL2) > #endif > > I don't see anything in vtkConfigure.h. > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Jul 9 09:04:14 2015 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 9 Jul 2015 09:04:14 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: References: Message-ID: I have been doing something like the following in my CMakeLists files if(VTK_RENDERING_BACKEND STREQUAL "OpenGL2") set_source_files_properties( vtkPSurfaceLICComposite.cxx PROPERTIES COMPILE_FLAGS -DVTK_OPENGL2) endif() Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Andrew Maclean *Sent:* Thursday, July 9, 2015 7:39 AM *To:* VTK Developers; Sean McBride *Subject:* Re: [vtk-developers] Detecting OpenGL2 mode at compile time? Hi Sean, Off the top of my head, I think VTK_RENDERING_BACKEND is visible and this has the values OpenGL or OpenGL2. Regards Andrew > > ---------- Forwarded message ---------- > From: Sean McBride > To: > Cc: > Date: Wed, 8 Jul 2015 18:46:33 -0400 > Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? > Hi all, > > Is there a way to detect at compile-time OpenGL vs OpenGL2 mode? > > Since my app uses Xcode, I have to do the factory initialization thing, and I'd like to be able to handle both cases as I test between both OpenGLs, ie: > > #if ??? > #define vtkRenderingCore_AUTOINIT 3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL) > #elif ??? > #define vtkRenderingCore_AUTOINIT 3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL2) > #endif > > I don't see anything in vtkConfigure.h. > > Thanks, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Jul 9 09:45:21 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 9 Jul 2015 09:45:21 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: References: Message-ID: <20150709134521.GB16313@megas.kitware.com> On Thu, Jul 09, 2015 at 09:04:14 -0400, Ken Martin wrote: > if(VTK_RENDERING_BACKEND STREQUAL "OpenGL2") > set_source_files_properties( > vtkPSurfaceLICComposite.cxx > PROPERTIES COMPILE_FLAGS -DVTK_OPENGL2) > endif() Some places use VTKGL2 and others use VTK_OPENGL2. I started using the former, but that's because I saw it first. We should probably make these consistent though. --Ben From utkarsh.ayachit at kitware.com Thu Jul 9 10:03:49 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 09 Jul 2015 14:03:49 +0000 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: References: <2CE400AE-BADE-42F0-94B8-C693F222147C@kitware.com> Message-ID: > > > On top it seems fixes (might be only partially) behavior of > vtkHardwareSelector. At least now it returns selection which I can track > back to block. Why partially? Cause even I am sure I am selecting a single > block area selection produces extra blocks. Interesting that if window is > defined as a point (x1=x2, y1=y2) only correct result is produced. > Do you have sample code to demonstrate this? We use this vtkConvertSelection in ParaView without this issue. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Thu Jul 9 10:15:53 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 9 Jul 2015 10:15:53 -0400 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Mathieu- I am going to look this over on the weekend. There are several known issues due to a variety of complex reasons; and if I remember right there are pathological cases with what you propose (walking across neighbors) because if there is topological separation/cracks between neighboring cells it's possible to fail too. Anyway I'll have a chance to look this weekend and we'll talk soon. I think the bottom line is that to 100% guarantee to find the containing cell a cell locator is needed, but for performance/memory reasons a point locator has been used in the past (unfortunately a performance tradeoff that comes back to bite us repeatedly). There may be more intelligent ways to consider the N closest points from FindPoint which may produce better results and don't cost too much in performance/memory. W On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > There is a bug in vtkPointCell::FindCell > > I copy here my mantis bug and associated notes: > http://www.vtk.org/Bug/view.php?id=15573 > > The current implementation of FindCell/ FindCellWalk is just wrong and not > working in some case : > > See atached image. > In the current implementation there is three pass : > > 1 : FindPoint, Check CellPoint > 2 : Check first neighbor > 3 : Check CellPoint within tolerance > > In the associated image, one can see the the first pass will find red star > and only check Cell 1 > the second pass will only check cell 2 > the third pass will not check anything more > > Cell 3 will never be found. > > I propose a solution based on vtkStreamTracer surface implementation, > which walk among neighbors more smartly using pcoords and cell boundary. > > See : > > https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 > [^ > > ] > > What do you think ? > > Mathieu Westphal > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Jul 9 10:47:25 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 9 Jul 2015 10:47:25 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <20150709134521.GB16313@megas.kitware.com> References: <20150709134521.GB16313@megas.kitware.com> Message-ID: <20150709144725.1299465356@mail.rogue-research.com> On Thu, 9 Jul 2015 09:45:21 -0400, Ben Boeckel said: >> if(VTK_RENDERING_BACKEND STREQUAL "OpenGL2") >> set_source_files_properties( >> vtkPSurfaceLICComposite.cxx >> PROPERTIES COMPILE_FLAGS -DVTK_OPENGL2) >> endif() > >Some places use VTKGL2 and others use VTK_OPENGL2. I started using the >former, but that's because I saw it first. We should probably make these >consistent though. There are 23 of the former, and 27 of the latter. I guess the latter is better, being both more descriptive and more numerous. Shall I make a find/replace patch? On Thu, 9 Jul 2015 09:04:14 -0400, Ken Martin said: >I have been doing something like the following in my CMakeLists files > >if(VTK_RENDERING_BACKEND STREQUAL "OpenGL2") > > set_source_files_properties( > > vtkPSurfaceLICComposite.cxx > > PROPERTIES COMPILE_FLAGS -DVTK_OPENGL2) > >endif() Alas, I have no CMakeLists file to to that in. Neither VTKGL2 nor VTK_OPENGL2 are exported in any public .h file. Would it be reasonable to #define it in vtkConfigure.h? 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 sankhesh.jhaveri at kitware.com Thu Jul 9 10:47:05 2015 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Thu, 9 Jul 2015 10:47:05 -0400 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: <20150707185827.GA26915@megas.kitware.com> References: <20150707185827.GA26915@megas.kitware.com> Message-ID: I'm working with Will to get his FlyingEdges and UnstructuredSpanSpace branches merged in. Not sure how much time but should be minor test failures. Warm Regards, Sankhesh Jhaveri Research & Development Engineer Kitware, Inc. *Phone*: (518) 881 4417 *Fax*: (518) 371 4573 On Tue, Jul 7, 2015 at 2:58 PM, Ben Boeckel wrote: > Hi, > > Does anyone out that have work in progress that we should delay the > release branch point for? > > We are hoping to get 6.3 started by the end of the week. > > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Jul 9 10:56:22 2015 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 9 Jul 2015 10:56:22 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <20150709144725.1299465356@mail.rogue-research.com> References: <20150709134521.GB16313@megas.kitware.com> <20150709144725.1299465356@mail.rogue-research.com> Message-ID: <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> If you could make a patch Sean that would be awesome. And yes we should probably stick it in vtkConfigure.h, that will also clean up some of the CMakeLists files a bit. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.? Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.? Thank you. -----Original Message----- From: Sean McBride [mailto:sean at rogue-research.com] Sent: Thursday, July 9, 2015 10:47 AM To: ben.boeckel at kitware.com; Ken Martin Cc: andrew.amaclean at gmail.com; VTK Developers Subject: Re: [vtk-developers] Detecting OpenGL2 mode at compile time? On Thu, 9 Jul 2015 09:45:21 -0400, Ben Boeckel said: >> if(VTK_RENDERING_BACKEND STREQUAL "OpenGL2") >> set_source_files_properties( >> vtkPSurfaceLICComposite.cxx >> PROPERTIES COMPILE_FLAGS -DVTK_OPENGL2) >> endif() > >Some places use VTKGL2 and others use VTK_OPENGL2. I started using the >former, but that's because I saw it first. We should probably make >these consistent though. There are 23 of the former, and 27 of the latter. I guess the latter is better, being both more descriptive and more numerous. Shall I make a find/replace patch? On Thu, 9 Jul 2015 09:04:14 -0400, Ken Martin said: >I have been doing something like the following in my CMakeLists files > >if(VTK_RENDERING_BACKEND STREQUAL "OpenGL2") > > set_source_files_properties( > > vtkPSurfaceLICComposite.cxx > > PROPERTIES COMPILE_FLAGS -DVTK_OPENGL2) > >endif() Alas, I have no CMakeLists file to to that in. Neither VTKGL2 nor VTK_OPENGL2 are exported in any public .h file. Would it be reasonable to #define it in vtkConfigure.h? 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 mathieu.westphal at kitware.com Thu Jul 9 11:03:01 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 9 Jul 2015 17:03:01 +0200 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: I have no better solution for topological cracks that what is currently implemented with the radius. Actually i've looking at it too fast, there is no design problem in the current implementation, and I understand complettelly why we need to limit the walk. However there is a typo ! if(cell->EvaluatePosition(x, closestPoint, subId, pcoords, dist2, weights) == 1 && (dist2 <= tol2)) { return cellId; } Should be : int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, dist2, weights); if (ret == 1 || ( ret == 0 && dist2 <= tol2)) { return cellId; } Doesn't it ? Mathieu Westphal On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder wrote: > Mathieu- > > I am going to look this over on the weekend. There are several known > issues due to a variety of complex reasons; and if I remember right there > are pathological cases with what you propose (walking across neighbors) > because if there is topological separation/cracks between neighboring cells > it's possible to fail too. > > Anyway I'll have a chance to look this weekend and we'll talk soon. I > think the bottom line is that to 100% guarantee to find the containing cell > a cell locator is needed, but for performance/memory reasons a point > locator has been used in the past (unfortunately a performance tradeoff > that comes back to bite us repeatedly). There may be more intelligent ways > to consider the N closest points from FindPoint which may produce better > results and don't cost too much in performance/memory. > > W > > On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> There is a bug in vtkPointCell::FindCell >> >> I copy here my mantis bug and associated notes: >> http://www.vtk.org/Bug/view.php?id=15573 >> >> The current implementation of FindCell/ FindCellWalk is just wrong and >> not working in some case : >> >> See atached image. >> In the current implementation there is three pass : >> >> 1 : FindPoint, Check CellPoint >> 2 : Check first neighbor >> 3 : Check CellPoint within tolerance >> >> In the associated image, one can see the the first pass will find red >> star and only check Cell 1 >> the second pass will only check cell 2 >> the third pass will not check anything more >> >> Cell 3 will never be found. >> >> I propose a solution based on vtkStreamTracer surface implementation, >> which walk among neighbors more smartly using pcoords and cell boundary. >> >> See : >> >> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >> [^ >> >> ] >> >> What do you think ? >> >> Mathieu Westphal >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Jul 9 11:44:31 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 9 Jul 2015 11:44:31 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> References: <20150709134521.GB16313@megas.kitware.com> <20150709144725.1299465356@mail.rogue-research.com> <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> Message-ID: <20150709154431.GA943@megas.kitware.com> On Thu, Jul 09, 2015 at 10:56:22 -0400, Ken Martin wrote: > If you could make a patch Sean that would be awesome. And yes we should > probably stick it in vtkConfigure.h, that will also clean up some of the > CMakeLists files a bit. At the expense of more things needing recompiles when switching backends, but I doubt many others reuse the same build tree for that kind of stuff anyways :) . I'm always for CMake cleanups though. --Ben From ben.boeckel at kitware.com Thu Jul 9 11:45:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 9 Jul 2015 11:45:10 -0400 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: References: <20150707185827.GA26915@megas.kitware.com> Message-ID: <20150709154510.GB943@megas.kitware.com> On Thu, Jul 09, 2015 at 10:47:05 -0400, Sankhesh Jhaveri wrote: > I'm working with Will to get his FlyingEdges and UnstructuredSpanSpace > branches merged in. > > Not sure how much time but should be minor test failures. Thanks. Please mention Dave and I on the MRs so we can keep track of their progress. --Ben From sean at rogue-research.com Thu Jul 9 13:43:27 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 9 Jul 2015 13:43:27 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> References: <20150709134521.GB16313@megas.kitware.com> <20150709144725.1299465356@mail.rogue-research.com> <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> Message-ID: <20150709174327.1212844705@mail.rogue-research.com> On Thu, 9 Jul 2015 10:56:22 -0400, Ken Martin said: >If you could make a patch Sean that would be awesome. And yes we should >probably stick it in vtkConfigure.h, that will also clean up some of the >CMakeLists files a bit. Here's a patch for VTKGL2 -> VTK_OPENGL2: I'm also adding an OpenGL2 dashboard from Rogue13 (i7 CPU, Intel Iris GPU, OS X 10.10.4), first results now on the dashboard under "Mac10.10-clang-dbg-OpenGL2-x86_64". There's an -Wimplicit-fallthrough warning that looks deliberate: Someone want to mark that dashboard expected? 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 Thu Jul 9 14:46:53 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 9 Jul 2015 14:46:53 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <20150709174327.1212844705@mail.rogue-research.com> References: <20150709134521.GB16313@megas.kitware.com> <20150709144725.1299465356@mail.rogue-research.com> <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> <20150709174327.1212844705@mail.rogue-research.com> Message-ID: <20150709184653.GA4611@megas.kitware.com> On Thu, Jul 09, 2015 at 13:43:27 -0400, Sean McBride wrote: > Here's a patch for VTKGL2 -> VTK_OPENGL2: > > Thanks. > I'm also adding an OpenGL2 dashboard from Rogue13 (i7 CPU, Intel Iris > GPU, OS X 10.10.4), first results now on the dashboard under > "Mac10.10-clang-dbg-OpenGL2-x86_64". There's an > -Wimplicit-fallthrough warning that looks deliberate: > > > > Someone want to mark that dashboard expected? Done. Is it still going to submit as Experimental? --Ben From sankhesh.jhaveri at kitware.com Thu Jul 9 16:09:13 2015 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Thu, 9 Jul 2015 16:09:13 -0400 Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1435143495909-5732515.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> <1435126237747-5732513.post@n5.nabble.com> <1435143495909-5732515.post@n5.nabble.com> Message-ID: Hello Lonni, It seems the VTK_DIR that you are pointing to is not compiled with Qt support. You can verify this by adding the following lines, right after include(VTK_USE_FILE) message (FATAL_ERROR "VTK_DIR: ${VTK_DIR}, VTK_QT_VERSION: ${VTK_QT_VERSION}) This above line should print the VTK build tree that you are pointing to and the Qt version it was compiled with. That should give you some clues. Warm Regards, Sankhesh Jhaveri Research & Development Engineer Kitware, Inc. *Phone*: (518) 881 4417 *Fax*: (518) 371 4573 On Wed, Jun 24, 2015 at 6:58 AM, Lonni Besan?on wrote: > To be more precise about my previous post (sorry I did not have the windows > computer nearby when I answered), when trying to use the example from the > Wiki: RenderWindowNoUiFile I get the error in /Cmake: > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindQt4.cmake:1326 (message): > Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x > Call Stack (most recent call first): > CMakeLists.txt:18 (find_package) > / > Which is completely logical since I don't have QT4 installed. > > Yet if I take a look at the CMakeList.txt it doesn't make sense as the > CMakeList contains: > / > cmake_minimum_required(VERSION 2.8) > > if(POLICY CMP0020) > cmake_policy(SET CMP0020 NEW) > endif() > > PROJECT(RenderWindowNoUiFile) > > find_package(VTK REQUIRED) > include(${VTK_USE_FILE}) > > if(${VTK_VERSION} VERSION_GREATER "6" AND VTK_QT_VERSION VERSION_GREATER > "4") > # Instruct CMake to run moc automatically when needed. > set(CMAKE_AUTOMOC ON) > find_package(Qt5Widgets REQUIRED QUIET) > else() > find_package(Qt4 REQUIRED) > include(${QT_USE_FILE}) > endif() > > include_directories(${CMAKE_CURRENT_SOURCE_DIR} > ${CMAKE_CURRENT_BINARY_DIR}) > > file(GLOB UI_FILES *.ui) > file(GLOB QT_WRAP *.h) > file(GLOB CXX_FILES *.cxx) > > if(${VTK_VERSION} VERSION_GREATER "6" AND VTK_QT_VERSION VERSION_GREATER > "4") > qt5_wrap_ui(UISrcs ${UI_FILES} ) > # CMAKE_AUTOMOC in ON so the MocHdrs will be automatically wrapped. > add_executable(RenderWindowNoUiFile MACOSX_BUNDLE > ${CXX_FILES} ${UISrcs} ${QT_WRAP}) > qt5_use_modules(RenderWindowNoUiFile Core Gui) > target_link_libraries(RenderWindowNoUiFile ${VTK_LIBRARIES}) > else() > QT4_WRAP_UI(UISrcs ${UI_FILES}) > QT4_WRAP_CPP(MOCSrcs ${QT_WRAP}) > add_executable(RenderWindowNoUiFile MACOSX_BUNDLE ${CXX_FILES} ${UISrcs} > ${MOCSrcs}) > > if(VTK_LIBRARIES) > if(${VTK_VERSION} VERSION_LESS "6") > target_link_libraries(RenderWindowNoUiFile ${VTK_LIBRARIES} QVTK) > else() > target_link_libraries(RenderWindowNoUiFile ${VTK_LIBRARIES}) > endif() > else() > target_link_libraries(RenderWindowNoUiFile vtkHybrid QVTK vtkViews > ${QT_LIBRARIES}) > endif() > endif() > > / > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732515.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerald.Lodron at joanneum.at Fri Jul 10 02:59:05 2015 From: Gerald.Lodron at joanneum.at (Lodron, Gerald) Date: Fri, 10 Jul 2015 06:59:05 +0000 Subject: [vtk-developers] Crash on vtkImageData with QNan Message-ID: Hi I wrote an application to watch some normal 2D image data. When I load a floating point image (monochrome) including QNan's I get a complete crash. I tried compiling my program in debug mode but here the app only hangs up (no crash directly), pressing on debugs pause seems to hang anywhere in window's nvoglv64.dll. When I compile my program in DebugWithRel Runtime it seemed that it is anywhere in vtkImageStatistics.dll. I am using image statistics but their functions were not called by my app (user needs to call special GUI entry), should not be called in current application usage so crash must be anywhere in rendering pipeline..... I also debugged it using std::cout's in release mode but it seems that my pipeline building up works perfectly and returns, crash seems to be later after some "interactor" or "Mapper" pipeline stuff.... Any ideas/suggestions to find the error? Replacing pixel values before rendering would be an option but is not very nice since I want to show the image data and not modified image data.... Thanks, best regards Gerald Lodron Machine Vision Applications DIGITAL - Institute for Information and Communication Technologies JOANNEUM RESEARCH Forschungsgesellschaft mbH Steyrergasse 17, 8010 Graz, AUSTRIA phone: +43-316-876-1751 fax: +43-316-876-1751 web: http://www.joanneum.at/digital e-mail: gerald.lodron at joanneum.at -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Fri Jul 10 05:42:19 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 10 Jul 2015 11:42:19 +0200 Subject: [vtk-developers] Issue with Linux extra linker flags Message-ID: Hi, I have issues when compiling VTK in release mode with gcc 4.9.2 Linking CXX shared library ../../lib/libvtkFiltersParallelMPI-6.3.so CMakeFiles/vtkFiltersParallelMPI.dir/vtkDistributedDataFilter.cxx.o: In function `vtkDistributedDataFilter::AddConstantUnsignedCharPointArray(vtkUnstructuredGrid*, char const*, unsigned char)': vtkDistributedDataFilter.cxx:(.text+0x2a03): warning: memset used with constant zero length parameter; this could be due to transposed parameters collect2: error: ld returned 1 exit status Filters/ParallelMPI/CMakeFiles/vtkFiltersParallelMPI.dir/build.make:214: recipe for target 'lib/libvtkFiltersParallelMPI-6.3.so.1' failed make[2]: *** [lib/libvtkFiltersParallelMPI-6.3.so.1] Error 1 This warning is due to a gcc bug that exists in many versions and the error arises because a linker option is automatically added by VTK on linux : "-Wl,--fatal-warnings" (see vtkCompilerExtras.cmake:15). Several users had the same issues and propose different fixes: see https://github.com/Kitware/VTK/pull/7 or https://github.com/gentoo/gentoo-portage-rsync-mirror/blob/master/sci-visualization/paraview/files/paraview-4.1.0-no-fatal-warnings.patch I prefer the second patch that consists in removing this --fatal-warnings options. I do not understand why this is performed automatically and cannot be disabled. Any objection in removing this linker flag by default? Best, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Jul 10 09:03:48 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 10 Jul 2015 07:03:48 -0600 Subject: [vtk-developers] [vtkusers] Crash on vtkImageData with QNan In-Reply-To: References: Message-ID: Hi Gerald, It is possible that the NAN is being cast to an int, which is then used as an index somewhere. It should be possible to catch this with a memory checker like valgrind or purify. If you can identify the class that is at fault, then I'll gladly do a fix. - David On Fri, Jul 10, 2015 at 12:59 AM, Lodron, Gerald wrote: > Hi > > > > I wrote an application to watch some normal 2D image data. When I load a > floating point image (monochrome) including QNan?s I get a complete crash. > I tried compiling my program in debug mode but here the app only hangs up > (no crash directly), pressing on debugs pause seems to hang anywhere in > window?s nvoglv64.dll. When I compile my program in DebugWithRel Runtime it > seemed that it is anywhere in vtkImageStatistics.dll. I am using image > statistics but their functions were not called by my app (user needs to > call special GUI entry), should not be called in current application usage > so crash must be anywhere in rendering pipeline..... I also debugged it > using std::cout?s in release mode but it seems that my pipeline building up > works perfectly and returns, crash seems to be later after some > ?interactor? or ?Mapper? pipeline stuff.... > > > > Any ideas/suggestions to find the error? Replacing pixel values before > rendering would be an option but is not very nice since I want to show the > image data and not modified image data.... > > > > Thanks, best regards > > > > Gerald Lodron > > Machine Vision Applications > > DIGITAL ? Institute for Information and Communication Technologies > > > > JOANNEUM RESEARCH Forschungsgesellschaft mbH > Steyrergasse 17, 8010 Graz, AUSTRIA > > phone: +43-316-876-1751 > > fax: +43-316-876-1751 > web: http://www.joanneum.at/digital > e-mail: gerald.lodron at joanneum.at > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From casey.goodlett at kitware.com Fri Jul 10 10:35:20 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Fri, 10 Jul 2015 10:35:20 -0400 Subject: [vtk-developers] Fwd: [PCL-users] Closing a visualizer window In-Reply-To: References: <1436515269280-4038790.post@n3.nabble.com> Message-ID: Hi VTK developers, The PCL community is experiencing an issue with the CloseWindow example http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/CloseWindow . Is someone aware of the cause of this issue? Thanks ---------- Forwarded message ---------- From: Victor L Date: Fri, Jul 10, 2015 at 4:19 AM Subject: Re: [PCL-users] Closing a visualizer window To: "Point Cloud Library (PCL) users" Hello, Please see this issue: https://github.com/PointCloudLibrary/pcl/issues/172 This is VTK related; http://www.vtk.org/Bug/view.php?id=14985 Please confirm the bug on the VTK tracker to give it visibility. Bye 2015-07-10 10:01 GMT+02:00 Mire : > Hi, > > did anybody manage to close a window instance of > pcl::visualization::PCLVisualizer in linux? > I tried the call pcl::visualization::PCLVisualizer()::Close() but the > window > doesn't disappear. > I'm using pcl1.8 on linux ubuntu 14.10. > > Thanks > > > > -- > View this message in context: > http://www.pcl-users.org/Closing-a-visualizer-window-tp4038790.html > Sent from the Point Cloud Library (PCL) Users mailing list mailing list > archive at Nabble.com. > _______________________________________________ > PCL-users at pointclouds.org / http://pointclouds.org > http://pointclouds.org/mailman/listinfo/pcl-users > _______________________________________________ PCL-users at pointclouds.org / http://pointclouds.org http://pointclouds.org/mailman/listinfo/pcl-users -- Casey B Goodlett, PhD Technical Leader Kitware, Inc. - North Carolina Office http://www.kitware.com (919) 969-6990 x310 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Jul 10 11:12:34 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 10 Jul 2015 11:12:34 -0400 Subject: [vtk-developers] [vtkusers] Crash on vtkImageData with QNan In-Reply-To: References: Message-ID: <20150710151234.1898014420@mail.rogue-research.com> On Fri, 10 Jul 2015 07:03:48 -0600, David Gobbi said: >It is possible that the NAN is being cast to an int, which is then used as >an index somewhere. It should be possible to catch this with a memory >checker like valgrind or purify. If you can identify the class that is at >fault, then I'll gladly do a fix. Casting NAN to int is undefined behaviour that is caught by 'undefined behaviour sanitizer' (aka UBSan) available in both clang and gcc. Some of my dashboards have (a subset of) UBSan enabled and there are indeed VTK tests that make these kinds of illegal conversions, though I think I've disabled some of those particular flags. :( 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 lonni.besancon at gmail.com Fri Jul 10 11:22:59 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Fri, 10 Jul 2015 08:22:59 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: References: <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> <1435126237747-5732513.post@n5.nabble.com> <1435143495909-5732515.post@n5.nabble.com> Message-ID: <1436541779791-5732826.post@n5.nabble.com> Seems you must be right. Yet I cannot try now as I'm on a business trip till the end of July. Will try it out ASAP and let you know on here ok? -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732826.html Sent from the VTK - Dev mailing list archive at Nabble.com. From cory.quammen at kitware.com Fri Jul 10 12:19:29 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Fri, 10 Jul 2015 11:19:29 -0500 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). In-Reply-To: References: <20150708181111.1666394198@mail.rogue-research.com> Message-ID: Berk, Yes, that might be possible. The tricky part is that the resize needs to be done correctly in the various places where the original table size is modified, of which there are a few (vtkLookupTable::SetNumberOfTableValues(), ::SetNumberOfColors(), ::SetTable(), etc.). I'll try it out and push a patch when I get the chance. Best, Cory On Wed, Jul 8, 2015 at 2:01 PM, Berk Geveci wrote: > It looks like that code can be refactored to do the resizing in some sort > of initialization method. This comment: > > // Resize the internal table to hold the special colors at the > // end. When this function is called repeatedly with the same size > // lookup table, memory reallocation will be done only one the first > // call if at all. > > indicates that the size does not change dynamically. Maybe it can be > changed to always allocate for the special colors from the beginning? > > -berk > > On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen > wrote: > >> Sean, >> >> I will take a look. >> >> Cory >> >> On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride >> wrote: >> >>> Hi all, >>> >>> As a mentioned in another thread, we've found a big slowdown in our app >>> between 6.2 and 6.3. Profiling with Instruments reveals lots of time is >>> being spent locking & unlocking a mutex in vtkLookupTableMapData(). >>> Looking through git history shows the culprit: >>> >>> ---------------------------- >>> commit dac748aedd7ffdc5aca6d555e74c668451ef4772 >>> Author: Cory Quammen >>> Date: Sun Mar 15 00:33:11 2015 -0400 >>> >>> BUG 15365: Fixed crash in function called from multiple threads >>> >>> vtkLookupTableMapData() was not thread safe and could lead to >>> crashes when accessed from multiple threads. Added a mutex around >>> the logic to determine if the color table size needed to be >>> increased. >>> >>> Added a multi-threaded test that crashes on occasion prior >>> to this patch, but does not crash with this patch applied. >>> ---------------------------- >>> >>> Indeed the added code has the comment: >>> >>> // Since this involves a potential array resize and this function >>> // might be accessed concurently from more than one thread, we need a >>> // mutex here. This shouldn't affect performance much if this function >>> // is used to map many input values, but if it is called repeatedly >>> // with short input arrays, performance may be much worse. >>> >>> So, for my use case, performance is indeed much worse. :( >>> >>> As a hack, I removed the lock/unlock and performance is back to >>> 6.2-level. >>> >>> Help? :) >>> >>> -- >>> ____________________________________________________________ >>> Sean McBride, B. Eng sean at rogue-research.com >>> Rogue Research www.rogue-research.com >>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>> >>> >> >> >> -- >> Cory Quammen >> R&D Engineer >> Kitware, Inc. >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Jul 10 13:59:00 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 10 Jul 2015 13:59:00 -0400 Subject: [vtk-developers] Ready to branch for 6.3? In-Reply-To: <20150707185827.GA26915@megas.kitware.com> References: <20150707185827.GA26915@megas.kitware.com> Message-ID: Also, now is a good time to look at gitlab: * Are their topic that you've neglected to review? Hey, review them, don't be such a rude slacker. * Do you have any outstanding topics that you want in this release? Push them through test, review and merge, politely pester the rude slackers you are waiting on. * Do you have stale topics in gitlab that you don't intend to continue? Come on don't litter, abandon them so they don't clutter up the place. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Jul 7, 2015 at 2:58 PM, Ben Boeckel wrote: > Hi, > > Does anyone out that have work in progress that we should delay the > release branch point for? > > We are hoping to get 6.3 started by the end of the week. > > Thanks, > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Jul 10 16:53:03 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 10 Jul 2015 16:53:03 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <20150709184653.GA4611@megas.kitware.com> References: <20150709134521.GB16313@megas.kitware.com> <20150709144725.1299465356@mail.rogue-research.com> <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> <20150709174327.1212844705@mail.rogue-research.com> <20150709184653.GA4611@megas.kitware.com> Message-ID: <20150710205303.1022862377@mail.rogue-research.com> On Thu, 9 Jul 2015 14:46:53 -0400, Ben Boeckel said: >Done. Is it still going to submit as Experimental? No, "Nightly". 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 Fri Jul 10 17:06:22 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 10 Jul 2015 17:06:22 -0400 Subject: [vtk-developers] Detecting OpenGL2 mode at compile time? In-Reply-To: <20150710205303.1022862377@mail.rogue-research.com> References: <20150709134521.GB16313@megas.kitware.com> <20150709144725.1299465356@mail.rogue-research.com> <8004737cfa18691a6b18ab8654fd470a@mail.gmail.com> <20150709174327.1212844705@mail.rogue-research.com> <20150709184653.GA4611@megas.kitware.com> <20150710205303.1022862377@mail.rogue-research.com> Message-ID: <20150710210622.GA20508@megas.kitware.com> On Fri, Jul 10, 2015 at 16:53:03 -0400, Sean McBride wrote: > On Thu, 9 Jul 2015 14:46:53 -0400, Ben Boeckel said: > >Done. Is it still going to submit as Experimental? > > No, "Nightly". It is now marked as expected in Nightly (and cleared from Experimental). --Ben From lonni.besancon at gmail.com Sat Jul 11 10:28:03 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Sat, 11 Jul 2015 07:28:03 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1436607684538-5732846.post@n5.nabble.com> References: <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> <1435126237747-5732513.post@n5.nabble.com> <1435143495909-5732515.post@n5.nabble.com> <1436541779791-5732826.post@n5.nabble.com> <1436607684538-5732846.post@n5.nabble.com> Message-ID: <1436624883564-5732848.post@n5.nabble.com> Thanks for your input on that problem. Yet I'm on a business trip so I cannot try before I get back (end of July). Will however keep you posted ASAP. Thanks again, Have a good day, -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732848.html Sent from the VTK - Dev mailing list archive at Nabble.com. From cory.quammen at kitware.com Sun Jul 12 23:56:32 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Sun, 12 Jul 2015 23:56:32 -0400 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). In-Reply-To: References: <20150708181111.1666394198@mail.rogue-research.com> Message-ID: Hi all, I've created a merge request with a possible fix here: https://gitlab.kitware.com/vtk/vtk/merge_requests/406 Please try it out and let me know if you find any problems. Thanks, Cory On Fri, Jul 10, 2015 at 12:19 PM, Cory Quammen wrote: > Berk, > > Yes, that might be possible. The tricky part is that the resize needs to > be done correctly in the various places where the original table size is > modified, of which there are a few > (vtkLookupTable::SetNumberOfTableValues(), ::SetNumberOfColors(), > ::SetTable(), etc.). I'll try it out and push a patch when I get the chance. > > Best, > Cory > > > > On Wed, Jul 8, 2015 at 2:01 PM, Berk Geveci > wrote: > >> It looks like that code can be refactored to do the resizing in some sort >> of initialization method. This comment: >> >> // Resize the internal table to hold the special colors at the >> // end. When this function is called repeatedly with the same size >> // lookup table, memory reallocation will be done only one the first >> // call if at all. >> >> indicates that the size does not change dynamically. Maybe it can be >> changed to always allocate for the special colors from the beginning? >> >> -berk >> >> On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen >> wrote: >> >>> Sean, >>> >>> I will take a look. >>> >>> Cory >>> >>> On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride >>> wrote: >>> >>>> Hi all, >>>> >>>> As a mentioned in another thread, we've found a big slowdown in our app >>>> between 6.2 and 6.3. Profiling with Instruments reveals lots of time is >>>> being spent locking & unlocking a mutex in vtkLookupTableMapData(). >>>> Looking through git history shows the culprit: >>>> >>>> ---------------------------- >>>> commit dac748aedd7ffdc5aca6d555e74c668451ef4772 >>>> Author: Cory Quammen >>>> Date: Sun Mar 15 00:33:11 2015 -0400 >>>> >>>> BUG 15365: Fixed crash in function called from multiple threads >>>> >>>> vtkLookupTableMapData() was not thread safe and could lead to >>>> crashes when accessed from multiple threads. Added a mutex around >>>> the logic to determine if the color table size needed to be >>>> increased. >>>> >>>> Added a multi-threaded test that crashes on occasion prior >>>> to this patch, but does not crash with this patch applied. >>>> ---------------------------- >>>> >>>> Indeed the added code has the comment: >>>> >>>> // Since this involves a potential array resize and this function >>>> // might be accessed concurently from more than one thread, we need a >>>> // mutex here. This shouldn't affect performance much if this function >>>> // is used to map many input values, but if it is called repeatedly >>>> // with short input arrays, performance may be much worse. >>>> >>>> So, for my use case, performance is indeed much worse. :( >>>> >>>> As a hack, I removed the lock/unlock and performance is back to >>>> 6.2-level. >>>> >>>> Help? :) >>>> >>>> -- >>>> ____________________________________________________________ >>>> Sean McBride, B. Eng sean at rogue-research.com >>>> Rogue Research www.rogue-research.com >>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>> >>>> >>>> >>> >>> >>> -- >>> Cory Quammen >>> R&D Engineer >>> Kitware, Inc. >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerald.Lodron at joanneum.at Mon Jul 13 00:46:24 2015 From: Gerald.Lodron at joanneum.at (Lodron, Gerald) Date: Mon, 13 Jul 2015 04:46:24 +0000 Subject: [vtk-developers] [vtkusers] Crash on vtkImageData with QNan In-Reply-To: <20150710151234.1898014420@mail.rogue-research.com> References: <20150710151234.1898014420@mail.rogue-research.com> Message-ID: <11563eab05664f29a277bb6bca5f1707@RZJMBX2.jr1.local> Hi I am using Windows Visual studio 2013 Pro with vtk of Paraview 4.3.0 (but in this project I am not using Paraview itself...), on 64bit. I currently saw that 4.3.1 is released but an update will cost me some time....(then I need to rebuild a brunch of others too)... I will check purify next days, i think we have a licence anywhere in my company... Thanks, Best regards Gerald -----Urspr?ngliche Nachricht----- Von: Sean McBride [mailto:sean at rogue-research.com] Gesendet: Freitag, 10. Juli 2015 17:13 An: David Gobbi; Lodron, Gerald Cc: VTK Developer (vtk-developers at vtk.org) Betreff: Re: [vtk-developers] [vtkusers] Crash on vtkImageData with QNan On Fri, 10 Jul 2015 07:03:48 -0600, David Gobbi said: >It is possible that the NAN is being cast to an int, which is then used >as an index somewhere. It should be possible to catch this with a >memory checker like valgrind or purify. If you can identify the class >that is at fault, then I'll gladly do a fix. Casting NAN to int is undefined behaviour that is caught by 'undefined behaviour sanitizer' (aka UBSan) available in both clang and gcc. Some of my dashboards have (a subset of) UBSan enabled and there are indeed VTK tests that make these kinds of illegal conversions, though I think I've disabled some of those particular flags. :( 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 ken.martin at kitware.com Mon Jul 13 09:52:01 2015 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 13 Jul 2015 09:52:01 -0400 Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1435652138043-5732589.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> <1435575547017-5732575.post@n5.nabble.com> <1435652138043-5732589.post@n5.nabble.com> Message-ID: <11df3927a876e7347a6471a975aa786d@mail.gmail.com> OK I managed to get a build of VTK on Android + Windows. Right now the build process for windows is a bit of a mess but I can share what I did and maybe it will help. I was using ndk r9d and adt bundle from 20140702 with a VTK from last night. I did not use the superbuild approach as I do not have a windows shell that is suitable for both native builds and cross compiling builds. Instead I did a $ SET ANDROID_NDK=C:\absolute\path\to\the\android-ndk $ mkdir vtkbin && cd vtkbin $ cmake.exe -G"MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=path\to\the\android.toolchain.cmake -DCMAKE_MAKE_PROGRAM="%ANDROID_NDK%\prebuilt\windows\bin\make.exe" .. I think that cmake failed but it gets the basics that are required into a cache. From there I ran the cmake gui from the same shell and specified any missing variables/settings. I turned on examples and had to specify where ant was and where the android executable was. $ cmake.exe --build . I have included my cache below in case that helps. I did have to make a compiler fix to the vtkEGLRenderWindow which is checked in a merged with master. When I get time I'll have to revisit the build process for windows and try to fix up some of this. For Linux I suspect it would be much more straight forward. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.? Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.? Thank you. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Tuesday, June 30, 2015 4:16 AM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() Alright ! In that case when you come back and start looking at that would you mind posting to this thread again? Or maybe email me directly? Have fun in the meantime. Lonni -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderW indow-New-tp5732418p5732589.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- # This is the CMakeCache file. # For build in directory: c:/Users/ken.martin/Documents/vtk/vtkes # It was generated by CMake: C:/Program Files (x86)/CMake/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## ANDROID:BOOL=ON //The target ABI for Android. If arm, then armeabi-v7a is recommended // for hardware floating point. ANDROID_ABI:STRING=armeabi-v7a //The android command-line tool ANDROID_EXECUTABLE:FILEPATH=C:/Users/ken.martin/Documents/adt-bundle-windows-x86_64-20140702/sdk/tools/android.bat //Prevent cmake from working under cygwin and using cygwin tools ANDROID_FORBID_SYGWIN:BOOL=ON //Use 32-bit ARM instructions instead of Thumb-1 ANDROID_FORCE_ARM_BUILD:BOOL=OFF //Put each function in separate section and enable garbage collection // of unused input sections at link time ANDROID_FUNCTION_LEVEL_LINKING:BOOL=ON //Enables gold linker ANDROID_GOLD_LINKER:BOOL=ON //Android API level for native code ANDROID_NATIVE_API_LEVEL:STRING=19 //Try to use 64-bit compiler toolchain ANDROID_NDK_HOST_X64:BOOL=ON //The inner layout of NDK ANDROID_NDK_LAYOUT:STRING=RELEASE //Allows or disallows undefined symbols in shared libraries ANDROID_NOEXECSTACK:BOOL=ON //Show all undefined symbols as linker errors ANDROID_NO_UNDEFINED:BOOL=ON //Enables RELRO - a memory corruption mitigation technique ANDROID_RELRO:BOOL=ON //Allows or disallows undefined symbols in shared libraries ANDROID_SO_UNDEFINED:BOOL=OFF //C++ runtime ANDROID_STL:STRING=gnustl_static //automatically configure rtti and exceptions support based on // C++ runtime ANDROID_STL_FORCE_FEATURES:BOOL=ON //The Android API to target ANDROID_TARGET:STRING=android-20 //The ant build tool ANT_EXECUTABLE:FILEPATH=C:/Users/ken.martin/Documents/adt-bundle-windows-x86_64-20140702/eclipse/plugins/org.apache.ant_1.8.3.v201301120609/bin/ant.bat //Build the VTK documentation BUILD_DOCUMENTATION:BOOL=OFF //Build VTK examples. BUILD_EXAMPLES:BOOL=ON //should be off for embedded BUILD_SHARED_LIBS:BOOL=OFF //Build the testing tree. BUILD_TESTING:BOOL=OFF //Path to a program. BZRCOMMAND:FILEPATH=BZRCOMMAND-NOTFOUND //archive CMAKE_AR:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-ar.exe //assembler CMAKE_ASM_COMPILER:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe //Choose the type of build. CMAKE_BUILD_TYPE:STRING=Debug //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //C++ compiler CMAKE_CXX_COMPILER:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++.exe //c++ flags CMAKE_CXX_FLAGS:STRING= //c++ Debug flags CMAKE_CXX_FLAGS_DEBUG:STRING=-O0 -g -DDEBUG -D_DEBUG //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //c++ Release flags CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //C compiler CMAKE_C_COMPILER:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe //c flags CMAKE_C_FLAGS:STRING= //c Debug flags CMAKE_C_FLAGS_DEBUG:STRING=-O0 -g -DDEBUG -D_DEBUG //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //c Release flags CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //executable linker flags CMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-z,nocopyreloc //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //path for installing CMAKE_INSTALL_PREFIX:STRING=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/user //linker CMAKE_LINKER:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-ld.exe //Path to a program. CMAKE_MAKE_PROGRAM:FILEPATH=C:/Users/ken.martin/Documents/android-ndk-r9d/prebuilt/windows-x86_64/bin/make.exe //module linker flags CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //nm CMAKE_NM:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-nm.exe //objcopy CMAKE_OBJCOPY:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-objcopy.exe //objdump CMAKE_OBJDUMP:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-objdump.exe //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=VTK //ranlib CMAKE_RANLIB:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-ranlib.exe //Result from TRY_RUN CMAKE_REQUIRE_LARGE_FILE_SUPPORT:STRING=2 //Output from TRY_RUN CMAKE_REQUIRE_LARGE_FILE_SUPPORT__TRYRUN_OUTPUT:STRING= //Path to a program. CMAKE_SH:FILEPATH=CMAKE_SH-NOTFOUND //shared linker flags CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when installing shared libraries, // but are added when building. CMAKE_SKIP_INSTALL_RPATH:BOOL=OFF //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=ON //Flags used by the linker during the creation of static libraries. CMAKE_STATIC_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= //strip CMAKE_STRIP:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin/arm-linux-androideabi-strip.exe //Thread library used. CMAKE_THREAD_LIBS:STRING= //If true, cmake will use relative paths in makefiles and projects. CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=OFF //Path to the coverage program that CTest uses for performing coverage // inspection COVERAGE_COMMAND:FILEPATH=COVERAGE_COMMAND-NOTFOUND //Extra command line flags to pass to the coverage tool COVERAGE_EXTRA_FLAGS:STRING=-l //How many times to retry timed-out CTest submissions. CTEST_SUBMIT_RETRY_COUNT:STRING=3 //How long to wait between timed-out CTest submissions. CTEST_SUBMIT_RETRY_DELAY:STRING=5 //Path to a program. CVSCOMMAND:FILEPATH=CVSCOMMAND-NOTFOUND //Options passed to the cvs update command. CVS_UPDATE_OPTIONS:STRING=-d -A -P //Maximum time allowed before CTest will kill the test. DART_TESTING_TIMEOUT:STRING=1500 //Value Computed by CMake DICOMParser_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/Utilities/DICOMParser //Value Computed by CMake DICOMParser_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/DICOMParser //Path to a library. EXECINFO_LIB:FILEPATH=EXECINFO_LIB-NOTFOUND //Additional URL templates for the ExternalData CMake script to // look for testing data. E.g. //\nfile:///var/bigharddrive/%(algo)/%(hash) ExternalData_URL_TEMPLATES:STRING= //Path to a program. GITCOMMAND:FILEPATH=GITCOMMAND-NOTFOUND //Path to a program. HGCOMMAND:FILEPATH=HGCOMMAND-NOTFOUND //Value Computed by CMake JavaVTK_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/Examples/Android/JavaVTK //Dependencies for the target JavaVTK_LIB_DEPENDS:STATIC=general;vtkInteractionStyle;general;vtkFiltersExtraction;general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonCore;general;vtksys;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtkCommonExecutionModel;general;vtkFiltersCore;general;vtkFiltersGeneral;general;vtkCommonComputationalGeometry;general;vtkFiltersStatistics;general;vtkImagingFourier;general;vtkImagingCore;general;vtkalglib;general;vtkFiltersSources;general;vtkRenderingCore;general;vtkCommonColor;general;vtkFiltersGeometry;general;vtkRenderingOpenGL2;general;vtkImagingHybrid;general;vtkIOImage;general;vtkDICOMParser;general;vtkIOCore;general;vtkzlib;general;vtkmetaio;general;vtkjpeg;general;vtkpng;general;vtktiff;general;vtkglew;general;android;general;log; //Value Computed by CMake JavaVTK_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/Examples/Android/JavaVTK //Value Computed by CMake JsonCpp_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/jsoncpp/vtkjsoncpp //Value Computed by CMake JsonCpp_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/jsoncpp/vtkjsoncpp //Result from TRY_RUN KWSYS_CHAR_IS_SIGNED:STRING=1 //Result from TRY_RUN KWSYS_LFS_WORKS:STRING=2 //Output from TRY_RUN KWSYS_LFS_WORKS__TRYRUN_OUTPUT:STRING= //Command to build the project MAKECOMMAND:STRING=C:/Program\ Files\ (x86)/CMake/bin/cmake.exe --build . --config "${CTEST_CONFIGURATION_TYPE}" -- -i //Path to the memory checking command, used for memory error detection. MEMORYCHECK_COMMAND:FILEPATH=MEMORYCHECK_COMMAND-NOTFOUND //File that contains suppressions for the memory checker MEMORYCHECK_SUPPRESSIONS_FILE:FILEPATH= //Request building AutobahnPython Module_AutobahnPython:BOOL=OFF //Request building SixPython Module_SixPython:BOOL=OFF //Request building Twisted Module_Twisted:BOOL=OFF //Request building ZopeInterface Module_ZopeInterface:BOOL=OFF //Request building vtkAcceleratorsDax Module_vtkAcceleratorsDax:BOOL=OFF //Request building vtkAcceleratorsPiston Module_vtkAcceleratorsPiston:BOOL=OFF //Request building vtkChartsCore Module_vtkChartsCore:BOOL=OFF //Request building vtkDomainsChemistry Module_vtkDomainsChemistry:BOOL=OFF //Request building vtkDomainsChemistryOpenGL2 Module_vtkDomainsChemistryOpenGL2:BOOL=OFF //Request building vtkFiltersAMR Module_vtkFiltersAMR:BOOL=OFF //Request building vtkFiltersCore Module_vtkFiltersCore:BOOL=ON //Request building vtkFiltersFlowPaths Module_vtkFiltersFlowPaths:BOOL=OFF //Request building vtkFiltersGeneric Module_vtkFiltersGeneric:BOOL=OFF //Request building vtkFiltersGeometry Module_vtkFiltersGeometry:BOOL=ON //Request building vtkFiltersHybrid Module_vtkFiltersHybrid:BOOL=OFF //Request building vtkFiltersHyperTree Module_vtkFiltersHyperTree:BOOL=OFF //Request building vtkFiltersImaging Module_vtkFiltersImaging:BOOL=OFF //Request building vtkFiltersMatlab Module_vtkFiltersMatlab:BOOL=OFF //Request building vtkFiltersModeling Module_vtkFiltersModeling:BOOL=ON //Request building vtkFiltersParallel Module_vtkFiltersParallel:BOOL=OFF //Request building vtkFiltersParallelFlowPaths Module_vtkFiltersParallelFlowPaths:BOOL=OFF //Request building vtkFiltersParallelGeometry Module_vtkFiltersParallelGeometry:BOOL=OFF //Request building vtkFiltersParallelImaging Module_vtkFiltersParallelImaging:BOOL=OFF //Request building vtkFiltersParallelMPI Module_vtkFiltersParallelMPI:BOOL=OFF //Request building vtkFiltersParallelStatistics Module_vtkFiltersParallelStatistics:BOOL=OFF //Request building vtkFiltersProgrammable Module_vtkFiltersProgrammable:BOOL=OFF //Request building vtkFiltersReebGraph Module_vtkFiltersReebGraph:BOOL=OFF //Request building vtkFiltersSMP Module_vtkFiltersSMP:BOOL=OFF //Request building vtkFiltersSelection Module_vtkFiltersSelection:BOOL=OFF //Request building vtkFiltersSources Module_vtkFiltersSources:BOOL=ON //Request building vtkFiltersStatisticsGnuR Module_vtkFiltersStatisticsGnuR:BOOL=OFF //Request building vtkFiltersTexture Module_vtkFiltersTexture:BOOL=OFF //Request building vtkFiltersVerdict Module_vtkFiltersVerdict:BOOL=OFF //Request building vtkGUISupportQt Module_vtkGUISupportQt:BOOL=OFF //Request building vtkGUISupportQtOpenGL Module_vtkGUISupportQtOpenGL:BOOL=OFF //Request building vtkGUISupportQtSQL Module_vtkGUISupportQtSQL:BOOL=OFF //Request building vtkGUISupportQtWebkit Module_vtkGUISupportQtWebkit:BOOL=OFF //Request building vtkGeovisCore Module_vtkGeovisCore:BOOL=OFF //Request building vtkIOADIOS Module_vtkIOADIOS:BOOL=OFF //Request building vtkIOAMR Module_vtkIOAMR:BOOL=OFF //Request building vtkIOEnSight Module_vtkIOEnSight:BOOL=OFF //Request building vtkIOExodus Module_vtkIOExodus:BOOL=OFF //Request building vtkIOExport Module_vtkIOExport:BOOL=OFF //Request building vtkIOFFMPEG Module_vtkIOFFMPEG:BOOL=OFF //Request building vtkIOGDAL Module_vtkIOGDAL:BOOL=OFF //Request building vtkIOGeoJSON Module_vtkIOGeoJSON:BOOL=OFF //Request building vtkIOGeometry Module_vtkIOGeometry:BOOL=ON //Request building vtkIOImage Module_vtkIOImage:BOOL=ON //Request building vtkIOImport Module_vtkIOImport:BOOL=OFF //Request building vtkIOInfovis Module_vtkIOInfovis:BOOL=ON //Request building vtkIOLSDyna Module_vtkIOLSDyna:BOOL=OFF //Request building vtkIOLegacy Module_vtkIOLegacy:BOOL=ON //Request building vtkIOMINC Module_vtkIOMINC:BOOL=OFF //Request building vtkIOMPIImage Module_vtkIOMPIImage:BOOL=OFF //Request building vtkIOMPIParallel Module_vtkIOMPIParallel:BOOL=OFF //Request building vtkIOMovie Module_vtkIOMovie:BOOL=OFF //Request building vtkIOMySQL Module_vtkIOMySQL:BOOL=OFF //Request building vtkIONetCDF Module_vtkIONetCDF:BOOL=OFF //Request building vtkIOODBC Module_vtkIOODBC:BOOL=OFF //Request building vtkIOPLY Module_vtkIOPLY:BOOL=ON //Request building vtkIOParallel Module_vtkIOParallel:BOOL=OFF //Request building vtkIOParallelExodus Module_vtkIOParallelExodus:BOOL=OFF //Request building vtkIOParallelLSDyna Module_vtkIOParallelLSDyna:BOOL=OFF //Request building vtkIOParallelNetCDF Module_vtkIOParallelNetCDF:BOOL=OFF //Request building vtkIOParallelXML Module_vtkIOParallelXML:BOOL=OFF //Request building vtkIOPostgreSQL Module_vtkIOPostgreSQL:BOOL=OFF //Request building vtkIOSQL Module_vtkIOSQL:BOOL=OFF //Request building vtkIOVPIC Module_vtkIOVPIC:BOOL=OFF //Request building vtkIOVideo Module_vtkIOVideo:BOOL=OFF //Request building vtkIOXdmf2 Module_vtkIOXdmf2:BOOL=OFF //Request building vtkIOXdmf3 Module_vtkIOXdmf3:BOOL=OFF //Request building vtkImagingColor Module_vtkImagingColor:BOOL=OFF //Request building vtkImagingCore Module_vtkImagingCore:BOOL=ON //Request building vtkImagingGeneral Module_vtkImagingGeneral:BOOL=OFF //Request building vtkImagingMath Module_vtkImagingMath:BOOL=OFF //Request building vtkImagingMorphological Module_vtkImagingMorphological:BOOL=OFF //Request building vtkImagingSources Module_vtkImagingSources:BOOL=OFF //Request building vtkImagingStatistics Module_vtkImagingStatistics:BOOL=OFF //Request building vtkImagingStencil Module_vtkImagingStencil:BOOL=OFF //Request building vtkInfovisBoost Module_vtkInfovisBoost:BOOL=OFF //Request building vtkInfovisBoostGraphAlgorithms Module_vtkInfovisBoostGraphAlgorithms:BOOL=OFF //Request building vtkInfovisLayout Module_vtkInfovisLayout:BOOL=OFF //Request building vtkInfovisParallel Module_vtkInfovisParallel:BOOL=OFF //Request building vtkInteractionImage Module_vtkInteractionImage:BOOL=OFF //Request building vtkInteractionStyle Module_vtkInteractionStyle:BOOL=ON //Request building vtkInteractionWidgets Module_vtkInteractionWidgets:BOOL=OFF //Request building vtkParallelCore Module_vtkParallelCore:BOOL=OFF //Request building vtkParallelMPI Module_vtkParallelMPI:BOOL=OFF //Request building vtkParseOGLExt Module_vtkParseOGLExt:BOOL=OFF //Request building vtkPython Module_vtkPython:BOOL=OFF //Request building vtkPythonInterpreter Module_vtkPythonInterpreter:BOOL=OFF //Request building vtkRenderingAnnotation Module_vtkRenderingAnnotation:BOOL=OFF //Request building vtkRenderingContext2D Module_vtkRenderingContext2D:BOOL=OFF //Request building vtkRenderingContextOpenGL Module_vtkRenderingContextOpenGL:BOOL=OFF //Request building vtkRenderingContextOpenGL2 Module_vtkRenderingContextOpenGL2:BOOL=OFF //Request building vtkRenderingCore Module_vtkRenderingCore:BOOL=ON //Request building vtkRenderingExternal Module_vtkRenderingExternal:BOOL=OFF //Request building vtkRenderingFreeType Module_vtkRenderingFreeType:BOOL=OFF //Request building vtkRenderingFreeTypeFontConfig Module_vtkRenderingFreeTypeFontConfig:BOOL=OFF //Request building vtkRenderingGL2PS Module_vtkRenderingGL2PS:BOOL=OFF //Request building vtkRenderingImage Module_vtkRenderingImage:BOOL=OFF //Request building vtkRenderingLIC Module_vtkRenderingLIC:BOOL=OFF //Request building vtkRenderingLICOpenGL2 Module_vtkRenderingLICOpenGL2:BOOL=OFF //Request building vtkRenderingLOD Module_vtkRenderingLOD:BOOL=OFF //Request building vtkRenderingLabel Module_vtkRenderingLabel:BOOL=OFF //Request building vtkRenderingMatplotlib Module_vtkRenderingMatplotlib:BOOL=OFF //Request building vtkRenderingOpenGL Module_vtkRenderingOpenGL:BOOL=OFF //Request building vtkRenderingParallel Module_vtkRenderingParallel:BOOL=OFF //Request building vtkRenderingParallelLIC Module_vtkRenderingParallelLIC:BOOL=OFF //Request building vtkRenderingQt Module_vtkRenderingQt:BOOL=OFF //Request building vtkRenderingTk Module_vtkRenderingTk:BOOL=OFF //Request building vtkRenderingVolume Module_vtkRenderingVolume:BOOL=OFF //Request building vtkRenderingVolumeAMR Module_vtkRenderingVolumeAMR:BOOL=OFF //Request building vtkRenderingVolumeOpenGL Module_vtkRenderingVolumeOpenGL:BOOL=OFF //Request building vtkRenderingVolumeOpenGL2 Module_vtkRenderingVolumeOpenGL2:BOOL=OFF //Request building vtkTclTk Module_vtkTclTk:BOOL=OFF //Request building vtkTestingCore Module_vtkTestingCore:BOOL=OFF //Request building vtkTestingGenericBridge Module_vtkTestingGenericBridge:BOOL=OFF //Request building vtkTestingIOSQL Module_vtkTestingIOSQL:BOOL=OFF //Request building vtkTestingRendering Module_vtkTestingRendering:BOOL=OFF //Request building vtkUtilitiesBenchmarks Module_vtkUtilitiesBenchmarks:BOOL=OFF //Request building vtkUtilitiesHashSource Module_vtkUtilitiesHashSource:BOOL=OFF //Request building vtkVPIC Module_vtkVPIC:BOOL=OFF //Request building vtkViewsContext2D Module_vtkViewsContext2D:BOOL=OFF //Request building vtkViewsCore Module_vtkViewsCore:BOOL=OFF //Request building vtkViewsGeovis Module_vtkViewsGeovis:BOOL=OFF //Request building vtkViewsInfovis Module_vtkViewsInfovis:BOOL=OFF //Request building vtkViewsQt Module_vtkViewsQt:BOOL=OFF //Request building vtkWebApplications Module_vtkWebApplications:BOOL=OFF //Request building vtkWebCore Module_vtkWebCore:BOOL=OFF //Request building vtkWebGLExporter Module_vtkWebGLExporter:BOOL=OFF //Request building vtkWebInstall Module_vtkWebInstall:BOOL=OFF //Request building vtkWebJavaScript Module_vtkWebJavaScript:BOOL=OFF //Request building vtkWebPython Module_vtkWebPython:BOOL=OFF //Request building vtkWrappingJava Module_vtkWrappingJava:BOOL=OFF //Request building vtkWrappingPythonCore Module_vtkWrappingPythonCore:BOOL=OFF //Request building vtkWrappingTcl Module_vtkWrappingTcl:BOOL=OFF //Request building vtkWrappingTools Module_vtkWrappingTools:BOOL=OFF //Request building vtkexodusII Module_vtkexodusII:BOOL=OFF //Request building vtkfreetype Module_vtkfreetype:BOOL=OFF //Request building vtkftgl Module_vtkftgl:BOOL=OFF //Request building vtkgl2ps Module_vtkgl2ps:BOOL=OFF //Request building vtkhdf5 Module_vtkhdf5:BOOL=OFF //Request building vtklibproj4 Module_vtklibproj4:BOOL=OFF //Request building vtkmpi4py Module_vtkmpi4py:BOOL=OFF //Request building vtknetcdf Module_vtknetcdf:BOOL=OFF //Request building vtkoggtheora Module_vtkoggtheora:BOOL=OFF //Request building vtksqlite Module_vtksqlite:BOOL=OFF //Request building vtkverdict Module_vtkverdict:BOOL=OFF //Request building vtkxdmf2 Module_vtkxdmf2:BOOL=OFF //Request building vtkxdmf3 Module_vtkxdmf3:BOOL=OFF //Value Computed by CMake NativeVTK_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/Examples/Android/NativeVTK //Dependencies for the target NativeVTK_LIB_DEPENDS:STATIC=general;vtkInteractionStyle;general;vtkFiltersExtraction;general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonCore;general;vtksys;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtkCommonExecutionModel;general;vtkFiltersCore;general;vtkFiltersGeneral;general;vtkCommonComputationalGeometry;general;vtkFiltersStatistics;general;vtkImagingFourier;general;vtkImagingCore;general;vtkalglib;general;vtkFiltersSources;general;vtkRenderingCore;general;vtkCommonColor;general;vtkFiltersGeometry;general;vtkRenderingOpenGL2;general;vtkImagingHybrid;general;vtkIOImage;general;vtkDICOMParser;general;vtkIOCore;general;vtkzlib;general;vtkmetaio;general;vtkjpeg;general;vtkpng;general;vtktiff;general;vtkglew;general;android;general;log; //Value Computed by CMake NativeVTK_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/Examples/Android/NativeVTK OPENGL_ES_VERSION:STRING=2.0 //Path to a file. OPENGL_INCLUDE_DIR:PATH=C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/include //Path to a library. OPENGL_egl_LIBRARY:FILEPATH=C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libEGL.so //Path to a library. OPENGL_gl_LIBRARY:FILEPATH=C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libGLESv2.so //Path to a library. OPENGL_glu_LIBRARY:FILEPATH=OPENGL_glu_LIBRARY-NOTFOUND //Path to a file. OPENGL_xmesa_INCLUDE_DIR:PATH=OPENGL_xmesa_INCLUDE_DIR-NOTFOUND //Path to a program. P4COMMAND:FILEPATH=P4COMMAND-NOTFOUND //Path to a program. PYTHON_EXECUTABLE:FILEPATH=PYTHON_EXECUTABLE-NOTFOUND //Path to scp command, used by CTest for submitting results to // a Dart server SCPCOMMAND:FILEPATH=SCPCOMMAND-NOTFOUND //Name of the computer/site where compile is being run SITE:STRING=ATHENA //Path to the SLURM sbatch executable SLURM_SBATCH_COMMAND:FILEPATH=SLURM_SBATCH_COMMAND-NOTFOUND //Path to the SLURM srun executable SLURM_SRUN_COMMAND:FILEPATH=SLURM_SRUN_COMMAND-NOTFOUND //Path to a program. SVNCOMMAND:FILEPATH=SVNCOMMAND-NOTFOUND //Use HIDDEN visibility support if available. USE_COMPILER_HIDDEN_VISIBILITY:BOOL=ON //The directory containing a CMake configuration file for VTKCompileTools. VTKCompileTools_DIR:PATH=C:/Users/ken.martin/Documents/vtk/vtkbin //Value Computed by CMake VTKEXPAT_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/expat/vtkexpat //Value Computed by CMake VTKEXPAT_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/expat/vtkexpat //Value Computed by CMake VTKExamples_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/Examples //Value Computed by CMake VTKExamples_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/Examples //Value Computed by CMake VTKGLEW_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/glew/vtkglew //Value Computed by CMake VTKGLEW_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/glew/vtkglew //Value Computed by CMake VTKJPEG_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/jpeg/vtkjpeg //Value Computed by CMake VTKJPEG_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/jpeg/vtkjpeg //Value Computed by CMake VTKPNG_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/png/vtkpng //Value Computed by CMake VTKPNG_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/png/vtkpng //Value Computed by CMake VTKTIFF_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/tiff/vtktiff //Value Computed by CMake VTKTIFF_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/tiff/vtktiff //Value Computed by CMake VTKZLIB_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/zlib/vtkzlib //Value Computed by CMake VTKZLIB_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/zlib/vtkzlib //Build all vtkObject derived classes with object factory new methods. VTK_ALL_NEW_OBJECT_FACTORY:BOOL=OFF //Build VTK for Android VTK_ANDROID_BUILD:BOOL=OFF //Result from TRY_RUN VTK_ANSI_STREAM_EOF_RESULT:STRING=0 //Value Computed by CMake VTK_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes //Request to build all modules VTK_BUILD_ALL_MODULES:BOOL=OFF //Directory where python modules will be put inside the build tree VTK_BUILD_PYTHON_MODULE_DIR:PATH=-NOTFOUND //Exclude test data download from default 'all' target. VTK_DATA_EXCLUDE_FROM_ALL:BOOL=OFF //Local directory holding ExternalData objects in the layout %(algo)/%(hash). VTK_DATA_STORE:PATH=C:/Users/ken.martin/Documents/vtk/VTKExternalData //Build leak checking support into VTK. VTK_DEBUG_LEAKS:BOOL=OFF //Build VTK using kits instead of modules. VTK_ENABLE_KITS:BOOL=OFF //Add compiler flags to do stricter checking when building debug. VTK_EXTRA_COMPILER_WARNINGS:BOOL=OFF //Location of the OpenGL extensions header file (glext.h). VTK_GLEXT_FILE:FILEPATH=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/ParseOGLExt/headers/glext.h //Location of the GLX extensions header file (glxext.h). VTK_GLXEXT_FILE:FILEPATH=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/ParseOGLExt/headers/glxext.h //Request building Imaging modules VTK_Group_Imaging:BOOL=OFF //Request building MPI modules VTK_Group_MPI:BOOL=OFF //Request building Qt modules VTK_Group_Qt:BOOL=OFF //Request building Rendering modules VTK_Group_Rendering:BOOL=OFF //Request building of all stand alone modules (no external dependencies // required) VTK_Group_StandAlone:BOOL=OFF //Request building Tk modules VTK_Group_Tk:BOOL=OFF //Request building Views modules VTK_Group_Views:BOOL=OFF //Request building Web modules VTK_Group_Web:BOOL=OFF //Directory where python modules will be installed VTK_INSTALL_PYTHON_MODULE_DIR:PATH=-NOTFOUND //Build vtk.framework for iOS VTK_IOS_BUILD:BOOL=OFF //Remove all legacy code completely. VTK_LEGACY_REMOVE:BOOL=OFF //Silence all legacy code messages. VTK_LEGACY_SILENT:BOOL=OFF //Should all modules build instantiators VTK_MAKE_INSTANTIATORS:BOOL=OFF //Max number of threads vktMultiThreader will allocate. VTK_MAX_THREADS:STRING=64 //The OpenGL library being used supports off screen Mesa calls VTK_OPENGL_HAS_OSMESA:BOOL=OFF //Python version to use: 2, 2.x, or empty VTK_PYTHON_VERSION:STRING=2 //Enable OpenGL error check and report VTK_REPORT_OPENGL_ERRORS:BOOL=ON //Enable OpenGL error check and reporting in non-debug builds. VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS:BOOL=OFF //Which multi-threaded parallelism implementation to use. Options // are Sequential, Simple, Kaapi, OpenMP or TBB VTK_SMP_IMPLEMENTATION_TYPE:STRING=Sequential //Value Computed by CMake VTK_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK //Result from TRY_RUN VTK_TYPE_CHAR_IS_SIGNED:STRING=1 //Build VTK with 64 bit ids VTK_USE_64BIT_IDS:BOOL=OFF //Use GCC visibility support if available. VTK_USE_GCC_VISIBILITY:BOOL=OFF //Enable tests requiring "large" data VTK_USE_LARGE_DATA:BOOL=OFF //Use off screen calls by default VTK_USE_OFFSCREEN:BOOL=OFF //Use system-installed EXPAT VTK_USE_SYSTEM_EXPAT:BOOL=OFF //Use system-installed Freetype VTK_USE_SYSTEM_FREETYPE:BOOL=OFF //Use system-installed GLEW VTK_USE_SYSTEM_GLEW:BOOL=OFF //Use system-installed JPEG VTK_USE_SYSTEM_JPEG:BOOL=OFF //Use system-installed JsonCpp VTK_USE_SYSTEM_JSONCPP:BOOL=OFF //Use the system's libraries by default. VTK_USE_SYSTEM_LIBRARIES:BOOL=OFF //Use system-installed LibXml2 VTK_USE_SYSTEM_LIBXML2:BOOL=OFF //Use system-installed PNG VTK_USE_SYSTEM_PNG:BOOL=OFF //Use system-installed TIFF VTK_USE_SYSTEM_TIFF:BOOL=OFF //Use system-installed ZLIB VTK_USE_SYSTEM_ZLIB:BOOL=OFF //Use X for VTK render windows VTK_USE_X:BOOL=OFF //Location of the WGL extensions header file (wglext.h). VTK_WGLEXT_FILE:FILEPATH=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/ParseOGLExt/headers/wglext.h //Path to a file. VTK_WRAP_HINTS:FILEPATH=C:/Users/ken.martin/Documents/vtk/VTK/Wrapping/Tools/hints //Should VTK Java wrapping be built? VTK_WRAP_JAVA:BOOL=OFF //Should VTK Python wrapping be built? VTK_WRAP_PYTHON:BOOL=OFF //Should VTK Tcl wrapping be built? VTK_WRAP_TCL:BOOL=OFF //Value Computed by CMake alglib_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/alglib //Value Computed by CMake alglib_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/alglib //Dependencies for the target vtkCommonColor_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkCommonComputationalGeometry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonSystem; //Dependencies for the target vtkCommonCore_LIB_DEPENDS:STATIC=general;vtksys; //Dependencies for the target vtkCommonDataModel_LIB_DEPENDS:STATIC=general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtksys; //Dependencies for the target vtkCommonExecutionModel_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkCommonMath_LIB_DEPENDS:STATIC=general;vtkCommonCore; //Dependencies for the target vtkCommonMisc_LIB_DEPENDS:STATIC=general;vtkCommonMath; //Dependencies for the target vtkCommonSystem_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtksys; //Dependencies for the target vtkCommonTransforms_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkCommonMath; //Dependencies for target vtkDICOMParser_LIB_DEPENDS:STATIC= //Dependencies for the target vtkFiltersCore_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms; //Dependencies for the target vtkFiltersExtraction_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkFiltersCore;general;vtkFiltersGeneral;general;vtkFiltersStatistics; //Dependencies for the target vtkFiltersGeneral_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersCore; //Dependencies for the target vtkFiltersGeometry_LIB_DEPENDS:STATIC=general;vtkFiltersCore; //Dependencies for the target vtkFiltersModeling_LIB_DEPENDS:STATIC=general;vtkFiltersGeneral;general;vtkFiltersSources; //Dependencies for the target vtkFiltersSources_LIB_DEPENDS:STATIC=general;vtkCommonComputationalGeometry;general;vtkFiltersGeneral; //Dependencies for the target vtkFiltersStatistics_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonTransforms;general;vtkImagingFourier;general;vtkalglib; //Dependencies for the target vtkIOCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMisc;general;vtkzlib;general;vtksys; //Dependencies for the target vtkIOGeometry_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkzlib;general;vtkjsoncpp;general;vtksys; //Dependencies for the target vtkIOImage_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtkIOCore;general;vtkjpeg;general;vtkpng;general;vtktiff;general;vtkmetaio;general;vtkDICOMParser;general;vtkzlib;general;vtksys; //Dependencies for the target vtkIOInfovis_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkIOLegacy;general;vtkIOXML;general;vtkInfovisCore;general;vtklibxml2;general;vtksys; //Dependencies for the target vtkIOLegacy_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtksys; //Dependencies for the target vtkIOPLY_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkCommonMisc;general;vtkIOGeometry; //Dependencies for the target vtkIOXMLParser_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkIOCore;general;vtkexpat; //Dependencies for the target vtkIOXML_LIB_DEPENDS:STATIC=general;vtkIOGeometry;general;vtkIOXMLParser;general;vtksys; //Dependencies for the target vtkImagingCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonExecutionModel;general;vtkCommonMath;general;vtkCommonSystem;general;vtkCommonTransforms; //Dependencies for the target vtkImagingFourier_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtksys; //Dependencies for the target vtkImagingHybrid_LIB_DEPENDS:STATIC=general;vtkIOImage;general;vtkImagingCore; //Dependencies for the target vtkInfovisCore_LIB_DEPENDS:STATIC=general;vtkCommonDataModel;general;vtkCommonSystem;general;vtkFiltersExtraction;general;vtkFiltersGeneral; //Dependencies for the target vtkInteractionStyle_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkFiltersSources;general;vtkFiltersExtraction; //Dependencies for the target vtkParallelCore_LIB_DEPENDS:STATIC=general;vtkCommonCore;general;vtkIOLegacy;general;vtksys; //Dependencies for the target vtkRenderingCore_LIB_DEPENDS:STATIC=general;vtkCommonColor;general;vtkCommonExecutionModel;general;vtkCommonTransforms;general;vtkFiltersSources;general;vtkFiltersGeometry;general;vtkFiltersExtraction;general;vtksys; //Dependencies for the target vtkRenderingFreeType_LIB_DEPENDS:STATIC=general;vtkRenderingCore;general;vtkRenderingCore;general;vtkfreetype;general;vtkftgl; //Dependencies for the target vtkRenderingOpenGL2_LIB_DEPENDS:STATIC=general;vtkCommonExecutionModel;general;vtkRenderingCore;general;vtkImagingHybrid;general;vtkglew;general;vtksys;general;C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libGLESv2.so;general;C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libEGL.so; //Dependencies for the target vtkTestingGenericBridge_LIB_DEPENDS:STATIC=general;vtkCommonDataModel; //Dependencies for the target vtkTestingRendering_LIB_DEPENDS:STATIC=general;vtkImagingCore;general;vtkRenderingCore;general;vtksys;general;vtkIOImage; //Dependencies for target vtkalglib_LIB_DEPENDS:STATIC= //Dependencies for target vtkexpat_LIB_DEPENDS:STATIC= //Dependencies for the target vtkfreetype_LIB_DEPENDS:STATIC=general;vtkzlib; //Dependencies for the target vtkftgl_LIB_DEPENDS:STATIC=general;C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libGLESv2.so;general;vtkfreetype; //Dependencies for the target vtkglew_LIB_DEPENDS:STATIC=general;C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libGLESv2.so; //Dependencies for target vtkjpeg_LIB_DEPENDS:STATIC= //Dependencies for target vtkjsoncpp_LIB_DEPENDS:STATIC= //Value Computed by CMake vtklibxml2_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/ThirdParty/libxml2/vtklibxml2 //Dependencies for the target vtklibxml2_LIB_DEPENDS:STATIC=general;vtkzlib;general;dl;general;dl;general;m; //Value Computed by CMake vtklibxml2_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/ThirdParty/libxml2/vtklibxml2 //Value Computed by CMake vtkmetaio_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/Utilities/MetaIO/vtkmetaio //Dependencies for the target vtkmetaio_LIB_DEPENDS:STATIC=general;vtkzlib; //Value Computed by CMake vtkmetaio_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/MetaIO/vtkmetaio //Dependencies for the target vtkpng_LIB_DEPENDS:STATIC=general;vtkzlib;general;-lm; //Value Computed by CMake vtksys_BINARY_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/vtkes/Utilities/KWSys/vtksys //Dependencies for the target vtksys_LIB_DEPENDS:STATIC=general;dl; //Value Computed by CMake vtksys_SOURCE_DIR:STATIC=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/KWSys/vtksys //Dependencies for the target vtktiff_LIB_DEPENDS:STATIC=general;vtkzlib;general;vtkjpeg;general;-lm; //Dependencies for target vtkzlib_LIB_DEPENDS:STATIC= ######################## # INTERNAL cache entries ######################## ALGLIB_SHARED_LIB:INTERNAL=OFF //STRINGS property for variable: ANDROID_ABI ANDROID_ABI-STRINGS:INTERNAL=armeabi;armeabi-v6 with VFP;armeabi-v7a;armeabi-v7a with NEON;armeabi-v7a with VFPV3 //Android specific c/c++ flags ANDROID_CXX_FLAGS:INTERNAL=-Wno-psabi --sysroot=C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm -funwind-tables -finline-limit=64 -fsigned-char -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections -ffunction-sections -Wa,--noexecstack //Android specific c/c++ Debug flags ANDROID_CXX_FLAGS_DEBUG:INTERNAL=-marm -fno-omit-frame-pointer -fno-strict-aliasing //Android specific c/c++ Release flags ANDROID_CXX_FLAGS_RELEASE:INTERNAL=-mthumb -fomit-frame-pointer -fno-strict-aliasing //ADVANCED property for variable: ANDROID_FORBID_SYGWIN ANDROID_FORBID_SYGWIN-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_FORCE_ARM_BUILD ANDROID_FORCE_ARM_BUILD-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_FUNCTION_LEVEL_LINKING ANDROID_FUNCTION_LEVEL_LINKING-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_GOLD_LINKER ANDROID_GOLD_LINKER-ADVANCED:INTERNAL=1 //Android specific c/c++ linker flags ANDROID_LINKER_FLAGS:INTERNAL= -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,--gc-sections -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now //STRINGS property for variable: ANDROID_NATIVE_API_LEVEL ANDROID_NATIVE_API_LEVEL-STRINGS:INTERNAL=12;13;14;15;16;17;18;19;3;4;5;8;9 //Path of the Android NDK ANDROID_NDK:INTERNAL=C:/Users/ken.martin/Documents/android-ndk-r9d //ADVANCED property for variable: ANDROID_NDK_HOST_X64 ANDROID_NDK_HOST_X64-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_NDK_LAYOUT ANDROID_NDK_LAYOUT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_NOEXECSTACK ANDROID_NOEXECSTACK-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_NO_UNDEFINED ANDROID_NO_UNDEFINED-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_RELRO ANDROID_RELRO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_SO_UNDEFINED ANDROID_SO_UNDEFINED-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_STL ANDROID_STL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ANDROID_STL_FORCE_FEATURES ANDROID_STL_FORCE_FEATURES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: BZRCOMMAND BZRCOMMAND-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE CMAKE_ANSI_FOR_SCOPE:INTERNAL=TRUE //Have include iostream CMAKE_ANSI_STREAM_HEADERS:INTERNAL=1 //STRINGS property for variable: CMAKE_BUILD_TYPE CMAKE_BUILD_TYPE-STRINGS:INTERNAL=Debug;Release;MinSizeRel;RelWithDebInfo //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=c:/Users/ken.martin/Documents/vtk/vtkes //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=2 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=3 //ADVANCED property for variable: CMAKE_COLOR_MAKEFILE CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/cmake.exe //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/cpack.exe //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/ctest.exe //ADVANCED property for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=C:/Program Files (x86)/CMake/bin/cmake-gui.exe //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Name of external makefile project generator. CMAKE_EXTRA_GENERATOR:INTERNAL= //Name of generator. CMAKE_GENERATOR:INTERNAL=MinGW Makefiles //Name of generator platform. CMAKE_GENERATOR_PLATFORM:INTERNAL= //Name of generator toolset. CMAKE_GENERATOR_TOOLSET:INTERNAL= //Result of TRY_COMPILE CMAKE_HAS_ANSI_STRING_STREAM:INTERNAL=TRUE //Have symbol pthread_create CMAKE_HAVE_LIBC_CREATE:INTERNAL=1 //Have include pthread.h CMAKE_HAVE_PTHREAD_H:INTERNAL=1 //Start directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=C:/Users/ken.martin/Documents/vtk/VTK //Install .so files without execute permission. CMAKE_INSTALL_SO_NO_EXE:INTERNAL=0 //ADVANCED property for variable: CMAKE_MAKE_PROGRAM CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Does the compiler support ansi for scope. CMAKE_NO_ANSI_FOR_SCOPE:INTERNAL=0 //ADVANCED property for variable: CMAKE_NO_ANSI_STREAM_HEADERS CMAKE_NO_ANSI_STREAM_HEADERS-ADVANCED:INTERNAL=1 //Does the compiler support headers like iostream. CMAKE_NO_ANSI_STREAM_HEADERS:INTERNAL=0 //Does the compiler support sstream CMAKE_NO_ANSI_STRING_STREAM:INTERNAL=0 //Does the compiler support std::. CMAKE_NO_STD_NAMESPACE:INTERNAL=0 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=61 //Path to CMake installation. CMAKE_ROOT:INTERNAL=C:/Program Files (x86)/CMake/share/cmake-3.2 //ADVANCED property for variable: CMAKE_SH CMAKE_SH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(unsigned short) CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=2 //ADVANCED property for variable: CMAKE_SKIP_INSTALL_RPATH CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE CMAKE_STD_NAMESPACE:INTERNAL=TRUE //Suppress Warnings that are meant for the author of the CMakeLists.txt // files. CMAKE_SUPPRESS_DEVELOPER_WARNINGS:INTERNAL=FALSE //ADVANCED property for variable: CMAKE_THREAD_LIBS CMAKE_THREAD_LIBS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Result of TEST_BIG_ENDIAN CMAKE_WORDS_BIGENDIAN:INTERNAL=0 //Compiler support for a deprecated attribute COMPILER_HAS_DEPRECATED:INTERNAL=1 //Test COMPILER_HAS_DEPRECATED_ATTR COMPILER_HAS_DEPRECATED_ATTR:INTERNAL=1 //Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY COMPILER_HAS_HIDDEN_INLINE_VISIBILITY:INTERNAL=1 //Test COMPILER_HAS_HIDDEN_VISIBILITY COMPILER_HAS_HIDDEN_VISIBILITY:INTERNAL=1 //ADVANCED property for variable: COVERAGE_COMMAND COVERAGE_COMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: COVERAGE_EXTRA_FLAGS COVERAGE_EXTRA_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CTEST_SUBMIT_RETRY_COUNT CTEST_SUBMIT_RETRY_COUNT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CTEST_SUBMIT_RETRY_DELAY CTEST_SUBMIT_RETRY_DELAY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CVSCOMMAND CVSCOMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CVS_UPDATE_OPTIONS CVS_UPDATE_OPTIONS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: DART_TESTING_TIMEOUT DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: EXECINFO_LIB EXECINFO_LIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: ExternalData_URL_TEMPLATES ExternalData_URL_TEMPLATES-ADVANCED:INTERNAL=1 //Details about finding OpenGL FIND_PACKAGE_MESSAGE_DETAILS_OpenGL:INTERNAL=[C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/lib/libGLESv2.so][C:/Users/ken.martin/Documents/android-ndk-r9d/platforms/android-19/arch-arm/usr/include][v()] //Details about finding Threads FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()] //ADVANCED property for variable: GITCOMMAND GITCOMMAND-ADVANCED:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;ansidecl.h HAVE_ANSIDECL_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h HAVE_ARPA_INET_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h HAVE_ARPA_NAMESER_H:INTERNAL=1 //Have include assert.h HAVE_ASSERT_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_CMAKE_REQUIRE_LARGE_FILE_SUPPORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_CMAKE_SIZEOF_UNSIGNED_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_CMAKE_WORDS_BIGENDIAN:INTERNAL=TRUE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h HAVE_CTYPE_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h HAVE_DIRENT_H:INTERNAL=1 //Have include dlfcn.h HAVE_DLFCN_H:INTERNAL=1 //Have library dl;dl;m HAVE_DLOPEN:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;dl.h HAVE_DL_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h HAVE_ERRNO_H:INTERNAL=1 //Have include fcntl.h HAVE_FCNTL_H:INTERNAL=1 //Have include fenv.h HAVE_FENV_H:INTERNAL=1 //Have symbol finite HAVE_FINITE:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h HAVE_FLOAT_H:INTERNAL=1 //Have function floor HAVE_FLOOR:INTERNAL= //Have symbol fpclass HAVE_FPCLASS:INTERNAL= //Have symbol fprintf HAVE_FPRINTF:INTERNAL=1 //Have symbol fp_class HAVE_FP_CLASS:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;fp_class.h HAVE_FP_CLASS_H:INTERNAL= //Have symbol ftime HAVE_FTIME:INTERNAL=1 //Test HAVE_GCC_ERROR_RETURN_TYPE HAVE_GCC_ERROR_RETURN_TYPE:INTERNAL=1 //Test HAVE_GCC_VISIBILITY HAVE_GCC_VISIBILITY:INTERNAL=1 //Result of TRY_COMPILE HAVE_GETADDRINFO_COMPILED:INTERNAL=TRUE //Have function getopt HAVE_GETOPT:INTERNAL=1 //Have symbol gettimeofday HAVE_GETTIMEOFDAY:INTERNAL=1 //Have includes ieeefp.h HAVE_IEEEFP_H:INTERNAL= //Have include inttypes.h HAVE_INTTYPES_H:INTERNAL=1 //Have function isascii HAVE_ISASCII:INTERNAL=1 //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_KWSYS_SIZEOF___INT64:INTERNAL=FALSE //Have library dl; HAVE_LIBDL:INTERNAL=1 //Have include limits.h HAVE_LIMITS_H:INTERNAL=1 //Have symbol localtime HAVE_LOCALTIME:INTERNAL=1 //Have include malloc.h HAVE_MALLOC_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h HAVE_MATH_H:INTERNAL=1 //Have function memmove HAVE_MEMMOVE:INTERNAL=1 //Have include memory.h HAVE_MEMORY_H:INTERNAL=1 //Have function memset HAVE_MEMSET:INTERNAL=1 //Have function mmap HAVE_MMAP:INTERNAL=1 //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;nan.h HAVE_NAN_H:INTERNAL= //Have includes stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;ndir.h HAVE_NDIR_H:INTERNAL= //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h HAVE_NETDB_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h HAVE_NETINET_IN_H:INTERNAL=1 //Have function pow HAVE_POW:INTERNAL= //Have symbol printf HAVE_PRINTF:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h HAVE_PTHREAD_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h HAVE_RESOLV_H:INTERNAL=1 //Have library dld;dl HAVE_SHLLOAD:INTERNAL= //Have symbol signal HAVE_SIGNAL:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h HAVE_SIGNAL_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_SIZEOF_LONG:INTERNAL=TRUE //Have symbol snprintf HAVE_SNPRINTF:INTERNAL=1 //Result of TRY_COMPILE HAVE_SOCKLEN_T_COMPILED:INTERNAL=TRUE //Have symbol sprintf HAVE_SPRINTF:INTERNAL=1 //Have function sqrt HAVE_SQRT:INTERNAL= //Have symbol sscanf HAVE_SSCANF:INTERNAL=1 //Have symbol stat HAVE_STAT:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h;stdarg.h HAVE_STDARG_H:INTERNAL=1 //Have include stddef.h HAVE_STDDEF_H:INTERNAL=1 //Have include stdint.h HAVE_STDINT_H:INTERNAL=1 //Have include ;stdio.h HAVE_STDIO_H:INTERNAL=1 //Have include stdlib.h HAVE_STDLIB_H:INTERNAL=1 //Have function strcasecmp HAVE_STRCASECMP:INTERNAL=1 //Have function strchr HAVE_STRCHR:INTERNAL=1 //Have symbol strdup HAVE_STRDUP:INTERNAL=1 //Have symbol strerror HAVE_STRERROR:INTERNAL=1 //Have symbol strftime HAVE_STRFTIME:INTERNAL=1 //Have include strings.h HAVE_STRINGS_H:INTERNAL=1 //Have include string.h HAVE_STRING_H:INTERNAL=1 //Have symbol strndup HAVE_STRNDUP:INTERNAL=1 //Have function strrchr HAVE_STRRCHR:INTERNAL=1 //Have function strstr HAVE_STRSTR:INTERNAL=1 //Have function strtol HAVE_STRTOL:INTERNAL=1 //Have function strtoul HAVE_STRTOUL:INTERNAL=1 //Result of TRY_COMPILE HAVE_SYS_DIR_H_COMPILED:INTERNAL=FALSE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h;stdarg.h;sys/mman.h HAVE_SYS_MMAN_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_SYS_NDIR_H_COMPILED:INTERNAL=FALSE //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h HAVE_SYS_SELECT_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h HAVE_SYS_SOCKET_H:INTERNAL=1 //Have include sys/stat.h HAVE_SYS_STAT_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h;unistd.h;signal.h;errno.h;arpa/inet.h;arpa/nameser.h;ctype.h;dirent.h;float.h;math.h;pthread.h;resolv.h;stdarg.h;sys/mman.h;sys/timeb.h HAVE_SYS_TIMEB_H:INTERNAL=1 //Have include sys/time.h HAVE_SYS_TIME_H:INTERNAL=1 //Have include sys/types.h HAVE_SYS_TYPES_H:INTERNAL=1 //Have include stdio.h;stddef.h;sys/types.h;inttypes.h;dlfcn.h;fcntl.h;malloc.h;memory.h;netdb.h;limits.h;sys/socket.h;netinet/in.h;sys/select.h;stdint.h;stdlib.h;string.h;strings.h;sys/stat.h;sys/time.h;time.h HAVE_TIME_H:INTERNAL=1 //Have include unistd.h HAVE_UNISTD_H:INTERNAL=1 //Result of TRY_COMPILE HAVE_VA_COPY_COMPILED:INTERNAL=TRUE //Have symbol vfprintf HAVE_VFPRINTF:INTERNAL=1 //Have symbol vsnprintf HAVE_VSNPRINTF:INTERNAL=1 //Have symbol vsprintf HAVE_VSPRINTF:INTERNAL=1 //Result of TRY_COMPILE HAVE_VTK_SIZEOF_CHAR:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_DOUBLE:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_FLOAT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_INT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_LONG_LONG:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF_SHORT:INTERNAL=TRUE //Result of TRY_COMPILE HAVE_VTK_SIZEOF___INT64:INTERNAL=FALSE //Result of TRY_COMPILE HAVE_VTK_UINTPTR_T:INTERNAL=TRUE //Have includes windows.h HAVE_WINDOWS_H:INTERNAL= //Have symbol _stat HAVE__STAT:INTERNAL= //Result of TRY_COMPILE HAVE___VA_COPY_COMPILED:INTERNAL=TRUE //ADVANCED property for variable: HGCOMMAND HGCOMMAND-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE KWSYS_CXX_HAS_ARGUMENT_DEPENDENT_LOOKUP_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ATOLL_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ATOL_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_CSTDDEF_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_CSTDIO_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H_COMPILED:INTERNAL=FALSE //Have include execinfo.h KWSYS_CXX_HAS_EXECINFOH:INTERNAL= //Result of TRY_COMPILE KWSYS_CXX_HAS_FULL_SPECIALIZATION_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_LONG_LONG_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_MEMBER_TEMPLATES_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_NULL_TEMPLATE_ARGS_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_RLIMIT64_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_SETENV_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_UNSETENV_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS_UTIMENSAT_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS_UTIMES_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_CXX_HAS__ATOI64_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_CXX_HAS___INT64_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_C_HAS_PTRDIFF_T_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_C_HAS_SSIZE_T_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_C_TYPE_MACROS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_HAVE_BINARY_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_HAVE_STD_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_USE_ANSI_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_IOS_USE_SSTREAM_COMPILED:INTERNAL=TRUE //CHECK_TYPE_SIZE: sizeof(char) KWSYS_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: __int64 unknown KWSYS_SIZEOF___INT64:INTERNAL= //Result of TRY_COMPILE KWSYS_STAT_HAS_ST_MTIM_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_MAX_SIZE_ARGUMENT_COMPILED:INTERNAL=FALSE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_OBJECTS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_REBIND_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ALLOCATOR_TEMPLATE_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_ITERATOR_TRAITS_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAS_WSTRING_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_HAVE_STD_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE KWSYS_STL_STRING_HAVE_NEQ_CHAR_COMPILED:INTERNAL=TRUE //Have includes sys/types.h;ifaddrs.h KWSYS_SYS_HAS_IFADDRS_H:INTERNAL= //ADVANCED property for variable: MAKECOMMAND MAKECOMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MEMORYCHECK_COMMAND MEMORYCHECK_COMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MEMORYCHECK_SUPPRESSIONS_FILE MEMORYCHECK_SUPPRESSIONS_FILE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_AutobahnPython Module_AutobahnPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_SixPython Module_SixPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_Twisted Module_Twisted-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_ZopeInterface Module_ZopeInterface-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkAcceleratorsDax Module_vtkAcceleratorsDax-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkAcceleratorsPiston Module_vtkAcceleratorsPiston-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkChartsCore Module_vtkChartsCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkCommonColor Module_vtkCommonColor-ADVANCED:INTERNAL=1 //Request building vtkCommonColor Module_vtkCommonColor:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonComputationalGeometry Module_vtkCommonComputationalGeometry-ADVANCED:INTERNAL=1 //Request building vtkCommonComputationalGeometry Module_vtkCommonComputationalGeometry:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonCore Module_vtkCommonCore-ADVANCED:INTERNAL=1 //Request building vtkCommonCore Module_vtkCommonCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonDataModel Module_vtkCommonDataModel-ADVANCED:INTERNAL=1 //Request building vtkCommonDataModel Module_vtkCommonDataModel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonExecutionModel Module_vtkCommonExecutionModel-ADVANCED:INTERNAL=1 //Request building vtkCommonExecutionModel Module_vtkCommonExecutionModel:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonMath Module_vtkCommonMath-ADVANCED:INTERNAL=1 //Request building vtkCommonMath Module_vtkCommonMath:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonMisc Module_vtkCommonMisc-ADVANCED:INTERNAL=1 //Request building vtkCommonMisc Module_vtkCommonMisc:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonSystem Module_vtkCommonSystem-ADVANCED:INTERNAL=1 //Request building vtkCommonSystem Module_vtkCommonSystem:INTERNAL=OFF //ADVANCED property for variable: Module_vtkCommonTransforms Module_vtkCommonTransforms-ADVANCED:INTERNAL=1 //Request building vtkCommonTransforms Module_vtkCommonTransforms:INTERNAL=OFF //ADVANCED property for variable: Module_vtkDICOMParser Module_vtkDICOMParser-ADVANCED:INTERNAL=1 //Request building vtkDICOMParser Module_vtkDICOMParser:INTERNAL=OFF //ADVANCED property for variable: Module_vtkDomainsChemistry Module_vtkDomainsChemistry-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkDomainsChemistryOpenGL2 Module_vtkDomainsChemistryOpenGL2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersAMR Module_vtkFiltersAMR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersCore Module_vtkFiltersCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersExtraction Module_vtkFiltersExtraction-ADVANCED:INTERNAL=1 //Request building vtkFiltersExtraction Module_vtkFiltersExtraction:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersFlowPaths Module_vtkFiltersFlowPaths-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersGeneral Module_vtkFiltersGeneral-ADVANCED:INTERNAL=1 //Request building vtkFiltersGeneral Module_vtkFiltersGeneral:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersGeneric Module_vtkFiltersGeneric-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersGeometry Module_vtkFiltersGeometry-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersHybrid Module_vtkFiltersHybrid-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersHyperTree Module_vtkFiltersHyperTree-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersImaging Module_vtkFiltersImaging-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersMatlab Module_vtkFiltersMatlab-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersModeling Module_vtkFiltersModeling-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallel Module_vtkFiltersParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelFlowPaths Module_vtkFiltersParallelFlowPaths-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelGeometry Module_vtkFiltersParallelGeometry-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelImaging Module_vtkFiltersParallelImaging-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelMPI Module_vtkFiltersParallelMPI-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersParallelStatistics Module_vtkFiltersParallelStatistics-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersProgrammable Module_vtkFiltersProgrammable-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersReebGraph Module_vtkFiltersReebGraph-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersSMP Module_vtkFiltersSMP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersSelection Module_vtkFiltersSelection-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersSources Module_vtkFiltersSources-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersStatistics Module_vtkFiltersStatistics-ADVANCED:INTERNAL=1 //Request building vtkFiltersStatistics Module_vtkFiltersStatistics:INTERNAL=OFF //ADVANCED property for variable: Module_vtkFiltersStatisticsGnuR Module_vtkFiltersStatisticsGnuR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersTexture Module_vtkFiltersTexture-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkFiltersVerdict Module_vtkFiltersVerdict-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQt Module_vtkGUISupportQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtOpenGL Module_vtkGUISupportQtOpenGL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtSQL Module_vtkGUISupportQtSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGUISupportQtWebkit Module_vtkGUISupportQtWebkit-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkGeovisCore Module_vtkGeovisCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOADIOS Module_vtkIOADIOS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOAMR Module_vtkIOAMR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOCore Module_vtkIOCore-ADVANCED:INTERNAL=1 //Request building vtkIOCore Module_vtkIOCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOEnSight Module_vtkIOEnSight-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOExodus Module_vtkIOExodus-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOExport Module_vtkIOExport-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOFFMPEG Module_vtkIOFFMPEG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGDAL Module_vtkIOGDAL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGeoJSON Module_vtkIOGeoJSON-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOGeometry Module_vtkIOGeometry-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOImage Module_vtkIOImage-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOImport Module_vtkIOImport-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOInfovis Module_vtkIOInfovis-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOLSDyna Module_vtkIOLSDyna-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOLegacy Module_vtkIOLegacy-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMINC Module_vtkIOMINC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMPIImage Module_vtkIOMPIImage-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMPIParallel Module_vtkIOMPIParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMovie Module_vtkIOMovie-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOMySQL Module_vtkIOMySQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIONetCDF Module_vtkIONetCDF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOODBC Module_vtkIOODBC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOPLY Module_vtkIOPLY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallel Module_vtkIOParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelExodus Module_vtkIOParallelExodus-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelLSDyna Module_vtkIOParallelLSDyna-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelNetCDF Module_vtkIOParallelNetCDF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOParallelXML Module_vtkIOParallelXML-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOPostgreSQL Module_vtkIOPostgreSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOSQL Module_vtkIOSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOVPIC Module_vtkIOVPIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOVideo Module_vtkIOVideo-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOXML Module_vtkIOXML-ADVANCED:INTERNAL=1 //Request building vtkIOXML Module_vtkIOXML:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXMLParser Module_vtkIOXMLParser-ADVANCED:INTERNAL=1 //Request building vtkIOXMLParser Module_vtkIOXMLParser:INTERNAL=OFF //ADVANCED property for variable: Module_vtkIOXdmf2 Module_vtkIOXdmf2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkIOXdmf3 Module_vtkIOXdmf3-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingColor Module_vtkImagingColor-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingCore Module_vtkImagingCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingFourier Module_vtkImagingFourier-ADVANCED:INTERNAL=1 //Request building vtkImagingFourier Module_vtkImagingFourier:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingGeneral Module_vtkImagingGeneral-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingHybrid Module_vtkImagingHybrid-ADVANCED:INTERNAL=1 //Request building vtkImagingHybrid Module_vtkImagingHybrid:INTERNAL=OFF //ADVANCED property for variable: Module_vtkImagingMath Module_vtkImagingMath-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingMorphological Module_vtkImagingMorphological-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingSources Module_vtkImagingSources-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingStatistics Module_vtkImagingStatistics-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkImagingStencil Module_vtkImagingStencil-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisBoost Module_vtkInfovisBoost-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisBoostGraphAlgorithms Module_vtkInfovisBoostGraphAlgorithms-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisCore Module_vtkInfovisCore-ADVANCED:INTERNAL=1 //Request building vtkInfovisCore Module_vtkInfovisCore:INTERNAL=OFF //ADVANCED property for variable: Module_vtkInfovisLayout Module_vtkInfovisLayout-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInfovisParallel Module_vtkInfovisParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInteractionImage Module_vtkInteractionImage-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInteractionStyle Module_vtkInteractionStyle-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkInteractionWidgets Module_vtkInteractionWidgets-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkMetaIO Module_vtkMetaIO-ADVANCED:INTERNAL=1 //Request building vtkMetaIO Module_vtkMetaIO:INTERNAL=OFF //ADVANCED property for variable: Module_vtkParallelCore Module_vtkParallelCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkParallelMPI Module_vtkParallelMPI-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkParseOGLExt Module_vtkParseOGLExt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkPython Module_vtkPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkPythonInterpreter Module_vtkPythonInterpreter-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingAnnotation Module_vtkRenderingAnnotation-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingContext2D Module_vtkRenderingContext2D-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingContextOpenGL Module_vtkRenderingContextOpenGL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingContextOpenGL2 Module_vtkRenderingContextOpenGL2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingCore Module_vtkRenderingCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingExternal Module_vtkRenderingExternal-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingFreeType Module_vtkRenderingFreeType-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingFreeTypeFontConfig Module_vtkRenderingFreeTypeFontConfig-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingGL2PS Module_vtkRenderingGL2PS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingImage Module_vtkRenderingImage-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingLIC Module_vtkRenderingLIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingLICOpenGL2 Module_vtkRenderingLICOpenGL2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingLOD Module_vtkRenderingLOD-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingLabel Module_vtkRenderingLabel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingMatplotlib Module_vtkRenderingMatplotlib-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingOpenGL Module_vtkRenderingOpenGL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingOpenGL2 Module_vtkRenderingOpenGL2-ADVANCED:INTERNAL=1 //Request building vtkRenderingOpenGL2 Module_vtkRenderingOpenGL2:INTERNAL=OFF //ADVANCED property for variable: Module_vtkRenderingParallel Module_vtkRenderingParallel-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingParallelLIC Module_vtkRenderingParallelLIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingQt Module_vtkRenderingQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingTk Module_vtkRenderingTk-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingVolume Module_vtkRenderingVolume-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingVolumeAMR Module_vtkRenderingVolumeAMR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingVolumeOpenGL Module_vtkRenderingVolumeOpenGL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkRenderingVolumeOpenGL2 Module_vtkRenderingVolumeOpenGL2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTclTk Module_vtkTclTk-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingCore Module_vtkTestingCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingGenericBridge Module_vtkTestingGenericBridge-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingIOSQL Module_vtkTestingIOSQL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkTestingRendering Module_vtkTestingRendering-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkUtilitiesBenchmarks Module_vtkUtilitiesBenchmarks-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkUtilitiesEncodeString Module_vtkUtilitiesEncodeString-ADVANCED:INTERNAL=1 //Request building vtkUtilitiesEncodeString Module_vtkUtilitiesEncodeString:INTERNAL=OFF //ADVANCED property for variable: Module_vtkUtilitiesHashSource Module_vtkUtilitiesHashSource-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkVPIC Module_vtkVPIC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsContext2D Module_vtkViewsContext2D-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsCore Module_vtkViewsCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsGeovis Module_vtkViewsGeovis-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsInfovis Module_vtkViewsInfovis-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkViewsQt Module_vtkViewsQt-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebApplications Module_vtkWebApplications-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebCore Module_vtkWebCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebGLExporter Module_vtkWebGLExporter-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebInstall Module_vtkWebInstall-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebJavaScript Module_vtkWebJavaScript-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWebPython Module_vtkWebPython-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingJava Module_vtkWrappingJava-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingPythonCore Module_vtkWrappingPythonCore-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingTcl Module_vtkWrappingTcl-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkWrappingTools Module_vtkWrappingTools-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkalglib Module_vtkalglib-ADVANCED:INTERNAL=1 //Request building vtkalglib Module_vtkalglib:INTERNAL=OFF //ADVANCED property for variable: Module_vtkexodusII Module_vtkexodusII-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkexpat Module_vtkexpat-ADVANCED:INTERNAL=1 //Request building vtkexpat Module_vtkexpat:INTERNAL=OFF //ADVANCED property for variable: Module_vtkfreetype Module_vtkfreetype-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkftgl Module_vtkftgl-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkgl2ps Module_vtkgl2ps-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkglew Module_vtkglew-ADVANCED:INTERNAL=1 //Request building vtkglew Module_vtkglew:INTERNAL=OFF //ADVANCED property for variable: Module_vtkhdf5 Module_vtkhdf5-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkjpeg Module_vtkjpeg-ADVANCED:INTERNAL=1 //Request building vtkjpeg Module_vtkjpeg:INTERNAL=OFF //ADVANCED property for variable: Module_vtkjsoncpp Module_vtkjsoncpp-ADVANCED:INTERNAL=1 //Request building vtkjsoncpp Module_vtkjsoncpp:INTERNAL=OFF //ADVANCED property for variable: Module_vtklibproj4 Module_vtklibproj4-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtklibxml2 Module_vtklibxml2-ADVANCED:INTERNAL=1 //Request building vtklibxml2 Module_vtklibxml2:INTERNAL=OFF //ADVANCED property for variable: Module_vtkmpi4py Module_vtkmpi4py-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtknetcdf Module_vtknetcdf-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkoggtheora Module_vtkoggtheora-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkpng Module_vtkpng-ADVANCED:INTERNAL=1 //Request building vtkpng Module_vtkpng:INTERNAL=OFF //ADVANCED property for variable: Module_vtksqlite Module_vtksqlite-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtksys Module_vtksys-ADVANCED:INTERNAL=1 //Request building vtksys Module_vtksys:INTERNAL=OFF //ADVANCED property for variable: Module_vtktiff Module_vtktiff-ADVANCED:INTERNAL=1 //Request building vtktiff Module_vtktiff:INTERNAL=OFF //ADVANCED property for variable: Module_vtkverdict Module_vtkverdict-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkxdmf2 Module_vtkxdmf2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkxdmf3 Module_vtkxdmf3-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Module_vtkzlib Module_vtkzlib-ADVANCED:INTERNAL=1 //Request building vtkzlib Module_vtkzlib:INTERNAL=OFF //ADVANCED property for variable: OPENGL_INCLUDE_DIR OPENGL_INCLUDE_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: OPENGL_gl_LIBRARY OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: OPENGL_glu_LIBRARY OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: OPENGL_xmesa_INCLUDE_DIR OPENGL_xmesa_INCLUDE_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: P4COMMAND P4COMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: PYTHON_EXECUTABLE PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: SCPCOMMAND SCPCOMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: SITE SITE-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(int) SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long) SIZEOF_LONG:INTERNAL=4 //ADVANCED property for variable: SLURM_SBATCH_COMMAND SLURM_SBATCH_COMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: SLURM_SRUN_COMMAND SLURM_SRUN_COMMAND-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE SUPPORT_IP6_COMPILED:INTERNAL=TRUE //ADVANCED property for variable: SVNCOMMAND SVNCOMMAND-ADVANCED:INTERNAL=1 //ADVANCED property for variable: USE_COMPILER_HIDDEN_VISIBILITY USE_COMPILER_HIDDEN_VISIBILITY-ADVANCED:INTERNAL=1 VTKFREETYPE_BINARY_DIR:INTERNAL=C:/Users/ken.martin/Documents/vtk/vtkes/Utilities/freetype VTKFREETYPE_SOURCE_DIR:INTERNAL=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/freetype VTKFTGL_BINARY_DIR:INTERNAL=C:/Users/ken.martin/Documents/vtk/vtkes/Utilities/ftgl VTKFTGL_SOURCE_DIR:INTERNAL=C:/Users/ken.martin/Documents/vtk/VTK/Utilities/ftgl //ADVANCED property for variable: VTK_ALL_NEW_OBJECT_FACTORY VTK_ALL_NEW_OBJECT_FACTORY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_BUILD_ALL_MODULES VTK_BUILD_ALL_MODULES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_BUILD_ALL_MODULES_FOR_TESTS VTK_BUILD_ALL_MODULES_FOR_TESTS-ADVANCED:INTERNAL=1 //Enable modules as needed for testing all the enabled modules VTK_BUILD_ALL_MODULES_FOR_TESTS:INTERNAL=OFF //ADVANCED property for variable: VTK_BUILD_PYTHON_MODULE_DIR VTK_BUILD_PYTHON_MODULE_DIR-ADVANCED:INTERNAL=1 //Support for full template specialization syntax VTK_COMPILER_HAS_FULL_SPECIALIZATION:INTERNAL=1 //Test VTK_CONST_REVERSE_ITERATOR_COMPARISON VTK_CONST_REVERSE_ITERATOR_COMPARISON:INTERNAL=1 //ADVANCED property for variable: VTK_DATA_EXCLUDE_FROM_ALL VTK_DATA_EXCLUDE_FROM_ALL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_DATA_STORE VTK_DATA_STORE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_DEBUG_LEAKS VTK_DEBUG_LEAKS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_ENABLE_KITS VTK_ENABLE_KITS-ADVANCED:INTERNAL=1 //Support for C++ explict templates VTK_EXPLICIT_TEMPLATES:INTERNAL=1 //Have symbol feenableexcept VTK_HAS_FEENABLEEXCEPT:INTERNAL=1 //Have symbol finite VTK_HAS_FINITE:INTERNAL= //Have symbol isfinite VTK_HAS_ISFINITE:INTERNAL=1 //Have symbol isinf VTK_HAS_ISINF:INTERNAL=1 //Have symbol isnan VTK_HAS_ISNAN:INTERNAL=1 //Test VTK_HAS_STD_ISFINITE VTK_HAS_STD_ISFINITE:INTERNAL=1 //Test VTK_HAS_STD_ISINF VTK_HAS_STD_ISINF:INTERNAL=1 //Test VTK_HAS_STD_ISNAN VTK_HAS_STD_ISNAN:INTERNAL=1 //Support for getsockname with socklen_t VTK_HAVE_GETSOCKNAME_WITH_SOCKLEN_T:INTERNAL=1 //Have library socket VTK_HAVE_LIBSOCKET:INTERNAL= //Have symbol SO_REUSEADDR VTK_HAVE_SO_REUSEADDR:INTERNAL=1 //For __sync atomic builtins. VTK_HAVE_SYNC_BUILTINS:INTERNAL=1 //VTK modular always ignores BTX VTK_IGNORE_BTX:INTERNAL=ON //ADVANCED property for variable: VTK_INSTALL_PYTHON_MODULE_DIR VTK_INSTALL_PYTHON_MODULE_DIR-ADVANCED:INTERNAL=1 //Whether istream supports long long VTK_ISTREAM_SUPPORTS_LONG_LONG:INTERNAL=1 //ADVANCED property for variable: VTK_LEGACY_REMOVE VTK_LEGACY_REMOVE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_LEGACY_SILENT VTK_LEGACY_SILENT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_MAKE_INSTANTIATORS VTK_MAKE_INSTANTIATORS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_MAX_THREADS VTK_MAX_THREADS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_OPENGL_HAS_OSMESA VTK_OPENGL_HAS_OSMESA-ADVANCED:INTERNAL=1 //Whether ostream supports long long VTK_OSTREAM_SUPPORTS_LONG_LONG:INTERNAL=1 //ADVANCED property for variable: VTK_REPORT_OPENGL_ERRORS VTK_REPORT_OPENGL_ERRORS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS VTK_REPORT_OPENGL_ERRORS_IN_RELEASE_BUILDS-ADVANCED:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(char) VTK_SIZEOF_CHAR:INTERNAL=1 //CHECK_TYPE_SIZE: sizeof(double) VTK_SIZEOF_DOUBLE:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(float) VTK_SIZEOF_FLOAT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(int) VTK_SIZEOF_INT:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long) VTK_SIZEOF_LONG:INTERNAL=4 //CHECK_TYPE_SIZE: sizeof(long long) VTK_SIZEOF_LONG_LONG:INTERNAL=8 //CHECK_TYPE_SIZE: sizeof(short) VTK_SIZEOF_SHORT:INTERNAL=2 //CHECK_TYPE_SIZE: __int64 unknown VTK_SIZEOF___INT64:INTERNAL= //STRINGS property for variable: VTK_SMP_IMPLEMENTATION_TYPE VTK_SMP_IMPLEMENTATION_TYPE-STRINGS:INTERNAL=Sequential;Simple;Kaapi;OpenMP;TBB //Result of TRY_COMPILE VTK_TEST_SYNC_BUILTINS_COMPILED:INTERNAL=TRUE //CHECK_TYPE_SIZE: sizeof(uintptr_t) VTK_UINTPTR_T:INTERNAL=4 //ADVANCED property for variable: VTK_USE_64BIT_IDS VTK_USE_64BIT_IDS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_GCC_VISIBILITY VTK_USE_GCC_VISIBILITY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_OFFSCREEN VTK_USE_OFFSCREEN-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_EXPAT VTK_USE_SYSTEM_EXPAT-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_FREETYPE VTK_USE_SYSTEM_FREETYPE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_GLEW VTK_USE_SYSTEM_GLEW-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_JPEG VTK_USE_SYSTEM_JPEG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_JSONCPP VTK_USE_SYSTEM_JSONCPP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_LIBRARIES VTK_USE_SYSTEM_LIBRARIES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_LIBXML2 VTK_USE_SYSTEM_LIBXML2-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_PNG VTK_USE_SYSTEM_PNG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_TIFF VTK_USE_SYSTEM_TIFF-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_SYSTEM_ZLIB VTK_USE_SYSTEM_ZLIB-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_USE_X VTK_USE_X-ADVANCED:INTERNAL=1 //ADVANCED property for variable: VTK_WRAP_HINTS VTK_WRAP_HINTS-ADVANCED:INTERNAL=1 From berk.geveci at kitware.com Mon Jul 13 10:26:57 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 13 Jul 2015 10:26:57 -0400 Subject: [vtk-developers] Fwd: ANNOUNCE: Kitware is hiring In-Reply-To: References: Message-ID: Hi folks, We are looking to hire visualization developers to our Scientific Computing team. If you are a talented visualization researcher and developer with strong C++ skills, please consider applying. You will join a great team and work on many interesting and challenging technical problems - always aiming to deliver robust and widely used software solutions. For the full posting see: http://tinyurl.com/l8sgvzw JOB DESCRIPTION Kitware is seeking to hire highly skilled Research and Development Engineers (R&D Engineers) to join our Scientific Computing team and contribute to our scientific and information visualization efforts. Candidates will work to develop and improve leading visualization software solutions. Kitware collaborates on a multitude of basic and applied research and development projects. Our collaborators include the top universities from around the world, national research labs, medical device manufacturers, car manufacturers, oil and gas companies, financial institutes, and many others. The projects range from extending our open source C++ libraries and applications, such as VTK, ParaView, and CMake, to developing proprietary domain-specific vertical applications for a wide array of platforms including web and mobile devices. By joining our team you will participate in a dynamic work environment with exceptionally talented and friendly coworkers who are committed to high-quality development practices. You will collaborate with esteemed researchers from around the world by: * Designing and developing scalable data analysis and visualization tools for use by researchers and professionals from various domains; * Solving a wide array of problems ranging from developing distributed memory parallel algorithms for data analysis, optimizing distributed parallel codes to compiling and maintaining software on supercomputers. * Designing and developing tools to improve scientific data analysis workflows; * Contributing to and supporting our dynamic open source communities built around several of our open source tools. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Mon Jul 13 14:09:10 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 13 Jul 2015 14:09:10 -0400 Subject: [vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData(). In-Reply-To: References: <20150708181111.1666394198@mail.rogue-research.com> Message-ID: The patch at [1] has been merged. Performance should be back to normal. - Cory [1] https://gitlab.kitware.com/vtk/vtk/merge_requests/406 On Sun, Jul 12, 2015 at 11:56 PM, Cory Quammen wrote: > Hi all, > > I've created a merge request with a possible fix here: > > https://gitlab.kitware.com/vtk/vtk/merge_requests/406 > > Please try it out and let me know if you find any problems. > > Thanks, > Cory > > On Fri, Jul 10, 2015 at 12:19 PM, Cory Quammen > wrote: > >> Berk, >> >> Yes, that might be possible. The tricky part is that the resize needs to >> be done correctly in the various places where the original table size is >> modified, of which there are a few >> (vtkLookupTable::SetNumberOfTableValues(), ::SetNumberOfColors(), >> ::SetTable(), etc.). I'll try it out and push a patch when I get the chance. >> >> Best, >> Cory >> >> >> >> On Wed, Jul 8, 2015 at 2:01 PM, Berk Geveci >> wrote: >> >>> It looks like that code can be refactored to do the resizing in some >>> sort of initialization method. This comment: >>> >>> // Resize the internal table to hold the special colors at the >>> // end. When this function is called repeatedly with the same size >>> // lookup table, memory reallocation will be done only one the first >>> // call if at all. >>> >>> indicates that the size does not change dynamically. Maybe it can be >>> changed to always allocate for the special colors from the beginning? >>> >>> -berk >>> >>> On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen >>> wrote: >>> >>>> Sean, >>>> >>>> I will take a look. >>>> >>>> Cory >>>> >>>> On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> As a mentioned in another thread, we've found a big slowdown in our >>>>> app between 6.2 and 6.3. Profiling with Instruments reveals lots of time >>>>> is being spent locking & unlocking a mutex in vtkLookupTableMapData(). >>>>> Looking through git history shows the culprit: >>>>> >>>>> ---------------------------- >>>>> commit dac748aedd7ffdc5aca6d555e74c668451ef4772 >>>>> Author: Cory Quammen >>>>> Date: Sun Mar 15 00:33:11 2015 -0400 >>>>> >>>>> BUG 15365: Fixed crash in function called from multiple threads >>>>> >>>>> vtkLookupTableMapData() was not thread safe and could lead to >>>>> crashes when accessed from multiple threads. Added a mutex around >>>>> the logic to determine if the color table size needed to be >>>>> increased. >>>>> >>>>> Added a multi-threaded test that crashes on occasion prior >>>>> to this patch, but does not crash with this patch applied. >>>>> ---------------------------- >>>>> >>>>> Indeed the added code has the comment: >>>>> >>>>> // Since this involves a potential array resize and this function >>>>> // might be accessed concurently from more than one thread, we need a >>>>> // mutex here. This shouldn't affect performance much if this function >>>>> // is used to map many input values, but if it is called repeatedly >>>>> // with short input arrays, performance may be much worse. >>>>> >>>>> So, for my use case, performance is indeed much worse. :( >>>>> >>>>> As a hack, I removed the lock/unlock and performance is back to >>>>> 6.2-level. >>>>> >>>>> Help? :) >>>>> >>>>> -- >>>>> ____________________________________________________________ >>>>> Sean McBride, B. Eng sean at rogue-research.com >>>>> Rogue Research www.rogue-research.com >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Cory Quammen >>>> R&D Engineer >>>> Kitware, Inc. >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >> >> >> -- >> Cory Quammen >> R&D Engineer >> Kitware, Inc. >> > > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Jul 13 15:00:56 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 13 Jul 2015 15:00:56 -0400 Subject: [vtk-developers] Delayed mouse interaction due to event-loop bug in Qt5 In-Reply-To: <54F07857.4060302@dkfz-heidelberg.de> References: <54E8E057.1060409@dkfz-heidelberg.de> <54F07857.4060302@dkfz-heidelberg.de> Message-ID: <20150713190056.GA5368@megas.kitware.com> On Fri, Feb 27, 2015 at 14:59:51 +0100, Christoph Kolb wrote: > I am not sure if the Qt5 bug is ever going to be fixed, because the > report (and patch) is very old. It could even be intentional... > In the worst case, it might be necessary to compress the events in VTK. > Or to prioritize them somehow. > > But I'm still very curious why this issue is showing only on some > machines. Is it possible that the rendering is just slower in my case? > I have compared my test execution times with those of > https://open.cdash.org/buildSummary.php?buildid=3711375 > and they seem to be equal. Is the described problem also showing there? I'm chasing this down for ParaView currently. Looks like Qt has merged a related fix: https://codereview.qt-project.org/#/c/112967 Other related patches (these seems more relevant): https://codereview.qt-project.org/#/c/108275/ https://codereview.qt-project.org/#/c/115531/ I'll do a check of ParaView against 5.5 to see if it fixes the problem (with and without these patches). Thanks, --Ben From ben.boeckel at kitware.com Mon Jul 13 16:51:34 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 13 Jul 2015 16:51:34 -0400 Subject: [vtk-developers] Delayed mouse interaction due to event-loop bug in Qt5 In-Reply-To: <20150713190056.GA5368@megas.kitware.com> References: <54E8E057.1060409@dkfz-heidelberg.de> <54F07857.4060302@dkfz-heidelberg.de> <20150713190056.GA5368@megas.kitware.com> Message-ID: <20150713205134.GA14903@megas.kitware.com> On Mon, Jul 13, 2015 at 15:00:56 -0400, Ben Boeckel wrote: > https://codereview.qt-project.org/#/c/115531/ Applying this patch (with one conflicting hunk) to 5.5.0 fixes the problem for me. I'll poke the review to see if some movement can't be made. --Ben From utkarsh.ayachit at kitware.com Mon Jul 13 17:07:32 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 13 Jul 2015 21:07:32 +0000 Subject: [vtk-developers] Proposal: Supporting Arrays With Arbitrary Memory Layouts Message-ID: Folks, As the recent VTK release roadmap alluded to, we're looking into refactoring the zero-copy/mapped arrays infrastructure in VTK to allow for arbitrary layouts with easier ways of adding new array types, and minimal overhead iterator access. While this is still under development, I wanted to put the draft for the current design/implementation out so folks can review and provide feedback. http://www.vtk.org/Wiki/VTK/Supporting_Arrays_With_Arbitrary_Memory_Layouts If everything goes smoothly, the plan is to deprecate Mapped Arrays and supporting classes in VTK 6.3 and replace it with the proposed Generic Arrays in VTK 7.0. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Jul 13 18:51:29 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 13 Jul 2015 18:51:29 -0400 Subject: [vtk-developers] Proposal: Supporting Arrays With Arbitrary Memory Layouts In-Reply-To: References: Message-ID: <20150713225129.1123501140@mail.rogue-research.com> On Mon, 13 Jul 2015 21:07:32 +0000, Utkarsh Ayachit said: >If everything goes smoothly, the plan is to deprecate Mapped Arrays and >supporting classes in VTK 6.3 and replace it with the proposed Generic >Arrays in VTK 7.0. Am I reading that wrong? You can't mark things deprecated without providing a replacement. People's apps will get deprecation warnings with 6.3 that they can't fix because the replacement API doesn't exist in 6.3. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From utkarsh.ayachit at kitware.com Tue Jul 14 05:12:56 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 14 Jul 2015 09:12:56 +0000 Subject: [vtk-developers] Proposal: Supporting Arrays With Arbitrary Memory Layouts In-Reply-To: <20150713225129.1123501140@mail.rogue-research.com> References: <20150713225129.1123501140@mail.rogue-research.com> Message-ID: Sean, That is what I meant :/. The main reason for that was the question that how many users are really using Mapped arrays? My suspicion after discussing with a few folks was few and far between. While it will be nearly impossible support both class hierarchies at the same time for vtkDataArray, maybe it's possible to support the 2 things that people using mapped arrays did: write a vtkMappedDataArray subclass and use vtkDataArrayIteratorMacro. Utkarsh On Mon, Jul 13, 2015 at 6:51 PM Sean McBride wrote: > On Mon, 13 Jul 2015 21:07:32 +0000, Utkarsh Ayachit said: > > >If everything goes smoothly, the plan is to deprecate Mapped Arrays and > >supporting classes in VTK 6.3 and replace it with the proposed Generic > >Arrays in VTK 7.0. > > Am I reading that wrong? You can't mark things deprecated without > providing a replacement. People's apps will get deprecation warnings with > 6.3 that they can't fix because the replacement API doesn't exist in 6.3. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Jul 14 09:22:50 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 14 Jul 2015 09:22:50 -0400 Subject: [vtk-developers] Buildbot now scanning for build warnings Message-ID: <20150714132250.GA14351@megas.kitware.com> Hi, As you may have noticed, buildbot will now be coloring the grid yellow where build warnings occur. Now it should be even easier to keep the warnings column in CDash green :) . --Ben From andy.bauer at kitware.com Tue Jul 14 15:40:43 2015 From: andy.bauer at kitware.com (Andy Bauer) Date: Tue, 14 Jul 2015 15:40:43 -0400 Subject: [vtk-developers] image pyramids in VTK Message-ID: Hi, I'm trying to see if there's need for "image pyramids" in VTK ( https://en.wikipedia.org/wiki/Pyramid_%28image_processing%29). Ashray Malhotra is working on implementing the Eulerian Video Magnification work ( http://people.csail.mit.edu/mrub/vidmag/) inside of VTK as part of his GSoC project. Part of his work includes implementing image pyramids. He has limited time so he can't spend a lot of time on doing a general image pyramid implementation with a nice API but I wanted to see if anyone developing VTK would like the functionality and/or has already done that functionality. Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Jul 14 17:57:58 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 14 Jul 2015 15:57:58 -0600 Subject: [vtk-developers] image pyramids in VTK In-Reply-To: References: Message-ID: Hi Andy & Ashray, Yes, image pyramids would be a useful addition to VTK. A few years back when I though I would get to work on some large microscopy data sets, I started working on an image algorithm class that would create and store pyramid, and allow downstream filters to select the desired resolution (unfortunately, nothing came out of it). Pyramids can be useful even in some fairly basic image viewing pipelines. - David On Tue, Jul 14, 2015 at 1:40 PM, Andy Bauer wrote: > Hi, > > I'm trying to see if there's need for "image pyramids" in VTK ( > https://en.wikipedia.org/wiki/Pyramid_%28image_processing%29). Ashray > Malhotra is working on implementing the Eulerian Video Magnification work ( > http://people.csail.mit.edu/mrub/vidmag/) inside of VTK as part of his > GSoC project. Part of his work includes implementing image pyramids. He has > limited time so he can't spend a lot of time on doing a general image > pyramid implementation with a nice API but I wanted to see if anyone > developing VTK would like the functionality and/or has already done that > functionality. > > Thanks, > Andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Wed Jul 15 07:43:28 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Wed, 15 Jul 2015 13:43:28 +0200 Subject: [vtk-developers] Issue with Linux extra linker flags In-Reply-To: References: Message-ID: For information I have created a merge request to fix the issue: https://gitlab.kitware.com/vtk/vtk/merge_requests/424 Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-10 11:42 GMT+02:00 Joachim Pouderoux : > Hi, > > I have issues when compiling VTK in release mode with gcc 4.9.2 > > Linking CXX shared library ../../lib/libvtkFiltersParallelMPI-6.3.so > CMakeFiles/vtkFiltersParallelMPI.dir/vtkDistributedDataFilter.cxx.o: In > function > `vtkDistributedDataFilter::AddConstantUnsignedCharPointArray(vtkUnstructuredGrid*, > char const*, unsigned char)': > vtkDistributedDataFilter.cxx:(.text+0x2a03): warning: memset used with > constant zero length parameter; this could be due to transposed parameters > collect2: error: ld returned 1 exit status > Filters/ParallelMPI/CMakeFiles/vtkFiltersParallelMPI.dir/build.make:214: > recipe for target 'lib/libvtkFiltersParallelMPI-6.3.so.1' failed > make[2]: *** [lib/libvtkFiltersParallelMPI-6.3.so.1] Error 1 > > This warning is due to a gcc bug that exists in many versions and the > error arises because a linker option is automatically added by VTK on linux > : "-Wl,--fatal-warnings" (see vtkCompilerExtras.cmake:15). > > Several users had the same issues and propose different fixes: > see https://github.com/Kitware/VTK/pull/7 > or > > https://github.com/gentoo/gentoo-portage-rsync-mirror/blob/master/sci-visualization/paraview/files/paraview-4.1.0-no-fatal-warnings.patch > > I prefer the second patch that consists in removing this --fatal-warnings > options. I do not understand why this is performed automatically and cannot > be disabled. > Any objection in removing this linker flag by default? > > Best, > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Wed Jul 15 08:16:09 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 15 Jul 2015 14:16:09 +0200 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Hello I've created a fix for FindCell : https://gitlab.kitware.com/vtk/vtk/merge_requests/399 But they are a dozen of bugs, can I have your advice about my fix and what would be the correct way to do it ? Mathieu Westphal On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > I have no better solution for topological cracks that what is currently > implemented with the radius. > Actually i've looking at it too fast, there is no design problem in the > current implementation, and I understand complettelly why we need to limit > the walk. > > However there is a typo ! > if(cell->EvaluatePosition(x, closestPoint, subId, > pcoords, dist2, weights) == 1 > && (dist2 <= tol2)) > { > return cellId; > } > > Should be : > > int ret = cell->EvaluatePosition(x, closestPoint, subId, > pcoords, dist2, weights); > if (ret == 1 || ( ret == 0 && dist2 <= tol2)) > { > return cellId; > } > > Doesn't it ? > > > Mathieu Westphal > > On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder > wrote: > >> Mathieu- >> >> I am going to look this over on the weekend. There are several known >> issues due to a variety of complex reasons; and if I remember right there >> are pathological cases with what you propose (walking across neighbors) >> because if there is topological separation/cracks between neighboring cells >> it's possible to fail too. >> >> Anyway I'll have a chance to look this weekend and we'll talk soon. I >> think the bottom line is that to 100% guarantee to find the containing cell >> a cell locator is needed, but for performance/memory reasons a point >> locator has been used in the past (unfortunately a performance tradeoff >> that comes back to bite us repeatedly). There may be more intelligent ways >> to consider the N closest points from FindPoint which may produce better >> results and don't cost too much in performance/memory. >> >> W >> >> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> There is a bug in vtkPointCell::FindCell >>> >>> I copy here my mantis bug and associated notes: >>> http://www.vtk.org/Bug/view.php?id=15573 >>> >>> The current implementation of FindCell/ FindCellWalk is just wrong and >>> not working in some case : >>> >>> See atached image. >>> In the current implementation there is three pass : >>> >>> 1 : FindPoint, Check CellPoint >>> 2 : Check first neighbor >>> 3 : Check CellPoint within tolerance >>> >>> In the associated image, one can see the the first pass will find red >>> star and only check Cell 1 >>> the second pass will only check cell 2 >>> the third pass will not check anything more >>> >>> Cell 3 will never be found. >>> >>> I propose a solution based on vtkStreamTracer surface implementation, >>> which walk among neighbors more smartly using pcoords and cell boundary. >>> >>> See : >>> >>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>> [^ >>> >>> ] >>> >>> What do you think ? >>> >>> Mathieu Westphal >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jul 15 09:37:50 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 15 Jul 2015 09:37:50 -0400 Subject: [vtk-developers] Issue with Linux extra linker flags In-Reply-To: References: Message-ID: <20150715133750.GA17336@megas.kitware.com> On Wed, Jul 15, 2015 at 13:43:28 +0200, Joachim Pouderoux wrote: > For information I have created a merge request to fix the issue: > https://gitlab.kitware.com/vtk/vtk/merge_requests/424 Might be useful to have it as an advanced flag, but it looks OK to me. --Ben From ken.martin at kitware.com Wed Jul 15 15:18:57 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 15 Jul 2015 15:18:57 -0400 Subject: [vtk-developers] Some OpenGL2 Polygonal Updates etc In-Reply-To: f4206e582026c10a0aea45de5cd8365a@mail.gmail.com References: f4206e582026c10a0aea45de5cd8365a@mail.gmail.com Message-ID: <97de1334b9789c4759f7306d537992ad@mail.gmail.com> It has been a while and I am overdue for updates on the new OpenGL rendering engine. We are in pretty good shape in terms of the new rendering engine with VTK. Tests are passing and we are generally ready to make it the default for the upcoming VTK release. The old engine will also be available as a CMake option. Here are some specific changes since the last update. 1) Added support in the PointGaussianMapper for rendering points as points ( /golfclap ). Sometimes in cosmology distant regions will be rendered as points while closer regions are rendered as splats. Now this mapper can handle both cases. This also makes this mapper an efficient mapper in VTK for rendering point clouds. It will render vtkPoints with colors quickly and with minimal memory. 2) Moved the new backend to OpenGL 3.2. While it still should mostly work with OpenGL 2.1 our target version is 3.2 which adds some nice features and yet is still fairly old. One of the big additions is support for geometry shaders. VTK now supports the use of geometry shaders and vtkOpenGLPolyDataMapper has some features to help make writing a geometry shader easier for all the numerous rendering cases VTK supports. 3) One of the features OpenGL 3.2 does not always support is rendering thick lines. The spec only requires support for thicknesses up to 1.0. So we have implemented support in VTK using a geometry shader for thick lines on systems that do not support them. 4) Had a chance to work with the Mesa folks to fix an issue in Mesa that was causing problems with cell coloring and picking. They were great to work with and as of Mesa version 10.5.5 this is fixed. 5) Made a large change to how cell coloring and picking was handled. In the old OpenGL2 code we would duplicate vertices to handle cell coloring so that each vertex was only used by one cell. This caused a huge explosion in memory required for those cases. The new approach makes use of gl_PrimitiveID to lookup cell colors (or cell normals or pick ids) in a texture map which saves us from having to duplicate vertices. Unfortunately gl_PrimitiveID is buggy on current Apple systems with AMD hardware so we had to implement a workaround for those systems which does impact performance on those systems. Apple is aware of the issue and will hopefully have a fix in the future. 6) Many fixes to vtkCompositePolyDataMapper2 to handle complex cases that ParaView testing exposed. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* Ken Martin [mailto:ken.martin at kitware.com] *Sent:* Monday, February 2, 2015 11:26 AM *To:* 'vtkdev' *Subject:* Some OpenGL2 Polygonal Updates etc Here are a few updates to the polygonal work we?ve been doing on the new OpenGL2 backend in VTK. 1) Created a vtkPointGaussianMapper [3] class for cosmology for quickly rendering lots of translucent Gaussian splats. This class will get refined a bit as it starts getting used more. Similar in concept to the PointSprite extensions that were added into Paraview by John Biddiscombe, Ugo Varetto and Stephane Ploix from CSCS and EDF. 2) Changed how the transformation matrices were handled in the vertex shader [7]. It was doing V? = VCDC * MCVC * V and a couple tests were failing. Instead we now compute MCDC on the CPU in double precision and instead do V? = MCDC * V in the shader which fixed the test and is generally a better way to do it. We often need the other two matrices as well which is why the original code just used those. 3) Added a rendering timing framework/executable [5] to make it easier to run test sequences across machines and see the results. Marcus and Rob have expanded on it and Aashish has added a volume rendering test. 4) Rewrote the vtkParametricFunctionSource [6] to be significantly faster (4x) and more memory efficient. We use this source to generate surfaces for rendering timings and it was a bit slow. 5) A bunch of fixes related to getting IceT to work with OpenGL2 [1] which led to some release graphics resource issues being fixed [2]. 6) ?Fixed? a longstanding failing test, TestChartXYZ [4] which was intermittently failing on some systems. 7) Marcus and Rob ran some rendering benchmarks showing upwards of 3 billion triangles per second on a 300 million triangle model. That is a big model and some solid performance. Currently I am wrapping up a change to the vtkCompositePolyDataMapper2 so that in some common circumstances it will render significantly faster (maybe 10x). This is targeted at helping apps that have lots of small polygonal parts that are not glyphed. Also adding in support for texture coordinate transformation matrices which are used by the GeoView classes in VTK. Tim Thirion is fixing up some iOS build issues and David Lonnie is working on removing an old text mapper that was causing some issues. JC has been working on updating Slicer to build against the current VTK with OpenGL2. Thanks Ken [1] http://review.source.kitware.com/#/t/5130/ [2] http://review.source.kitware.com/#/t/5171/ [3] http://review.source.kitware.com/#/t/5198/ [4] http://review.source.kitware.com/#/t/5248/ [5] http://review.source.kitware.com/#/t/5276/ [6] http://review.source.kitware.com/#/t/5302/ [7] http://review.source.kitware.com/#/t/5327/ Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Jul 16 15:44:43 2015 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 16 Jul 2015 15:44:43 -0400 Subject: [vtk-developers] Green Dashboard!!! Message-ID: <42ce314e80a5c3620a4f5aeb4404f8be@mail.gmail.com> At least the top two sections are green which are the key sections. Kudos everyone! https://open.cdash.org/index.php?project=VTK [image: http://media1.giphy.com/media/TSn2zVInxOm2c/giphy.gif] Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 39945 bytes Desc: not available URL: From simon.esneault at gmail.com Fri Jul 17 04:43:11 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 17 Jul 2015 10:43:11 +0200 Subject: [vtk-developers] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers Message-ID: Hi All, We're experiencing GPU volume rendering failure on a lot (maybe all ?) Intel HD windows system with up to date drivers. This is reproducible in Paraview or with the GPURenderDemo example from VTK, just load a volume and try to render the volume... Here is a result image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with GPU rendering [1] and the same volume with CPU VR rendering [2]. Interestingly, the volume rendering used to work with drivers older or equal to the version 10.18.10.3496 [3]. As a work around, we ask our customers to downgrade their driver version to this one, and they're enjoying smooth GPU rendering. But this driver is quite old and does not support recent chipset... I've built and tested the GPURenderDemo with the brand new OpenGL2 backend on an affected machine and of course it does work out of the box (congratulations for this amazing work !). But our application is FDA/CE marked and we need to wait that this new backend is completely ready for prime time. So for now, we have to stick with VTK 6.1 ... Anyone has any clue ? They're some warning that pop up from paraview related to the extension "gl_version_1_2" that could not be loaded, not sure if that could be related ? Following this thread [4] and the fix proposed, I've tried to replace /*****************/ extensions->LoadExtension("GL_VERSION_1_2") /*****************/ by /*****************/ extensions->LoadExtension("GL_EXT_texture3D"); extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); /*****************/ in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but there is still no volume rendering (tested with GPURenderDemo). Maybe it needs some others extensions ? Should I fill a bug in paraview, vtk ? Are there any plan to maintain and maybe fix this for the old backend ? Thanks, -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Jul 17 08:52:02 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 17 Jul 2015 08:52:02 -0400 Subject: [vtk-developers] Intel Developer Forum, software-defined visualization, San Francisco August 18-20 Message-ID: Greetings lists, The vis and rendering folks at Intel will be showing off the things they've been working on and are bringing to VTK, ParaView and the rest. See the attached flyer for registration promo-codes if you plan to attend the conference. Hope to see you there. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IDF_wPromoCodes.pdf Type: application/pdf Size: 71463 bytes Desc: not available URL: From aashish.chaudhary at kitware.com Fri Jul 17 09:04:01 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 17 Jul 2015 09:04:01 -0400 Subject: [vtk-developers] Green Dashboard!!! In-Reply-To: <42ce314e80a5c3620a4f5aeb4404f8be@mail.gmail.com> References: <42ce314e80a5c3620a4f5aeb4404f8be@mail.gmail.com> Message-ID: +1000 -:) On Thu, Jul 16, 2015 at 3:44 PM, Ken Martin wrote: > At least the top two sections are green which are the key sections. Kudos > everyone! > > > > https://open.cdash.org/index.php?project=VTK > > > > [image: http://media1.giphy.com/media/TSn2zVInxOm2c/giphy.gif] > > > > Ken Martin PhD > > Chairman & CFO > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > ken.martin at kitware.com > > 919 869-8871 (w) > > > > > > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 39945 bytes Desc: not available URL: From dave.demarle at kitware.com Fri Jul 17 09:09:12 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 17 Jul 2015 09:09:12 -0400 Subject: [vtk-developers] Proposal: Supporting Arrays With Arbitrary Memory Layouts In-Reply-To: References: <20150713225129.1123501140@mail.rogue-research.com> Message-ID: Utkarsh A, David L, Please put Ben and I on the MR as reviewers for the deprecation commit so we know when to start the release branch. thanks David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Jul 14, 2015 at 5:12 AM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Sean, > > That is what I meant :/. The main reason for that was the question that > how many users are really using Mapped arrays? My suspicion after > discussing with a few folks was few and far between. While it will be > nearly impossible support both class hierarchies at the same time for > vtkDataArray, maybe it's possible to support the 2 things that people using > mapped arrays did: write a vtkMappedDataArray subclass and > use vtkDataArrayIteratorMacro. > > Utkarsh > > On Mon, Jul 13, 2015 at 6:51 PM Sean McBride > wrote: > >> On Mon, 13 Jul 2015 21:07:32 +0000, Utkarsh Ayachit said: >> >> >If everything goes smoothly, the plan is to deprecate Mapped Arrays and >> >supporting classes in VTK 6.3 and replace it with the proposed Generic >> >Arrays in VTK 7.0. >> >> Am I reading that wrong? You can't mark things deprecated without >> providing a replacement. People's apps will get deprecation warnings with >> 6.3 that they can't fix because the replacement API doesn't exist in 6.3. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Jul 17 10:22:14 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 17 Jul 2015 10:22:14 -0400 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Dear Simon, On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT wrote: > Hi All, > > We're experiencing GPU volume rendering failure on a lot (maybe all ?) > Intel HD windows system with up to date drivers. > > This is reproducible in Paraview or with the GPURenderDemo example from > VTK, just load a volume and try to render the volume... Here is a result > image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with > GPU rendering [1] and the same volume with CPU VR rendering [2]. > Interestingly, the volume rendering used to work with drivers older or > equal to the version 10.18.10.3496 [3]. As a work around, we ask our > customers to downgrade their driver version to this one, and they're > enjoying smooth GPU rendering. But this driver is quite old and does not > support recent chipset... > > I've built and tested the GPURenderDemo with the brand new OpenGL2 backend > on an affected machine and of course it does work out of the box > (congratulations for this amazing work !). > Great! > But our application is FDA/CE marked and we need to wait that this new > backend is completely ready for prime time. So for now, we have to stick > with VTK 6.1 ... > Most of the tests are passing for OpenGL2 ( https://open.cdash.org/index.php?project=VTK) on most of the dashboards (various configurations etc) but it is a moving target just like VTK itself is a moving target. I guess you are waiting for a VTK release that defaults to OpenGL2 as oppose to OpenGL? > > Anyone has any clue ? They're some warning that pop up from paraview > related to the extension "gl_version_1_2" that could not be loaded, not > sure if that could be related ? Following this thread [4] and the fix > proposed, I've tried to replace > /*****************/ > extensions->LoadExtension("GL_VERSION_1_2") > /*****************/ > by > /*****************/ > extensions->LoadExtension("GL_EXT_texture3D"); > extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); > /*****************/ > in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but > there is still no volume rendering (tested with GPURenderDemo). Maybe it > needs some others extensions ? > Yes, there is a patch and I can send it to you. I have to talk to folks here if we can fix the old mapper with those changes but as of now it is not in the plan. > > Should I fill a bug in paraview, vtk ? Are there any plan to maintain and > maybe fix this for the old backend ? > - Aashish > > Thanks, > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > > [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG > [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG > [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 > [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Search the list archives at: http://markmail.org/search/?q=ParaView > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/paraview > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Fri Jul 17 11:34:43 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 17 Jul 2015 17:34:43 +0200 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Dear Aashish, Thank you very much for you answer. Yes you are right, we are waiting for a new VTK release that defaults to the new OpenGL2 backend, for safety and because a change of VTK version requires a lot of extra work with our current framework... But the green dashboard indeed looks really promising, and we will probably make the move as soon as it's ready ! Meanwhile, I would be really glad if you could send me the patch that solves this issue with the old backend, or guide me through the needed modification to make it work. Thanks again Simon 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary : > Dear Simon, > > On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT > wrote: > >> Hi All, >> >> We're experiencing GPU volume rendering failure on a lot (maybe all ?) >> Intel HD windows system with up to date drivers. >> >> This is reproducible in Paraview or with the GPURenderDemo example from >> VTK, just load a volume and try to render the volume... Here is a result >> image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with >> GPU rendering [1] and the same volume with CPU VR rendering [2]. >> Interestingly, the volume rendering used to work with drivers older or >> equal to the version 10.18.10.3496 [3]. As a work around, we ask our >> customers to downgrade their driver version to this one, and they're >> enjoying smooth GPU rendering. But this driver is quite old and does not >> support recent chipset... >> >> I've built and tested the GPURenderDemo with the brand new OpenGL2 >> backend on an affected machine and of course it does work out of the box >> (congratulations for this amazing work !). >> > Great! > > >> But our application is FDA/CE marked and we need to wait that this new >> backend is completely ready for prime time. So for now, we have to stick >> with VTK 6.1 ... >> > > Most of the tests are passing for OpenGL2 ( > https://open.cdash.org/index.php?project=VTK) on most of the dashboards > (various configurations etc) but it is a moving target just like VTK itself > is a moving target. I guess you are waiting for a VTK release that defaults > to OpenGL2 as oppose to OpenGL? > >> >> Anyone has any clue ? They're some warning that pop up from paraview >> related to the extension "gl_version_1_2" that could not be loaded, not >> sure if that could be related ? Following this thread [4] and the fix >> proposed, I've tried to replace >> /*****************/ >> extensions->LoadExtension("GL_VERSION_1_2") >> /*****************/ >> by >> /*****************/ >> extensions->LoadExtension("GL_EXT_texture3D"); >> extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); >> /*****************/ >> in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but >> there is still no volume rendering (tested with GPURenderDemo). Maybe it >> needs some others extensions ? >> > > Yes, there is a patch and I can send it to you. I have to talk to folks > here if we can fix the old mapper with those changes but as of now it is > not in the plan. > > >> >> Should I fill a bug in paraview, vtk ? Are there any plan to maintain and >> maybe fix this for the old backend ? >> > > - Aashish > > >> >> Thanks, >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> >> [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG >> [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG >> [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 >> [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Search the list archives at: http://markmail.org/search/?q=ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/paraview >> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Fri Jul 17 11:40:21 2015 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 17 Jul 2015 15:40:21 +0000 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Please share the patch publicly, we would need it for some of our projects, too. Thank you! Andras From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Simon ESNEAULT Sent: Friday, July 17, 2015 11:35 AM To: Aashish Chaudhary Cc: VTK Developers; vtkusers at vtk.org; ParaView list Subject: Re: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers Dear Aashish, Thank you very much for you answer. Yes you are right, we are waiting for a new VTK release that defaults to the new OpenGL2 backend, for safety and because a change of VTK version requires a lot of extra work with our current framework... But the green dashboard indeed looks really promising, and we will probably make the move as soon as it's ready ! Meanwhile, I would be really glad if you could send me the patch that solves this issue with the old backend, or guide me through the needed modification to make it work. Thanks again Simon 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary >: Dear Simon, On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT > wrote: Hi All, We're experiencing GPU volume rendering failure on a lot (maybe all ?) Intel HD windows system with up to date drivers. This is reproducible in Paraview or with the GPURenderDemo example from VTK, just load a volume and try to render the volume... Here is a result image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with GPU rendering [1] and the same volume with CPU VR rendering [2]. Interestingly, the volume rendering used to work with drivers older or equal to the version 10.18.10.3496 [3]. As a work around, we ask our customers to downgrade their driver version to this one, and they're enjoying smooth GPU rendering. But this driver is quite old and does not support recent chipset... I've built and tested the GPURenderDemo with the brand new OpenGL2 backend on an affected machine and of course it does work out of the box (congratulations for this amazing work !). Great! But our application is FDA/CE marked and we need to wait that this new backend is completely ready for prime time. So for now, we have to stick with VTK 6.1 ... Most of the tests are passing for OpenGL2 (https://open.cdash.org/index.php?project=VTK) on most of the dashboards (various configurations etc) but it is a moving target just like VTK itself is a moving target. I guess you are waiting for a VTK release that defaults to OpenGL2 as oppose to OpenGL? Anyone has any clue ? They're some warning that pop up from paraview related to the extension "gl_version_1_2" that could not be loaded, not sure if that could be related ? Following this thread [4] and the fix proposed, I've tried to replace /*****************/ extensions->LoadExtension("GL_VERSION_1_2") /*****************/ by /*****************/ extensions->LoadExtension("GL_EXT_texture3D"); extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); /*****************/ in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but there is still no volume rendering (tested with GPURenderDemo). Maybe it needs some others extensions ? Yes, there is a patch and I can send it to you. I have to talk to folks here if we can fix the old mapper with those changes but as of now it is not in the plan. Should I fill a bug in paraview, vtk ? Are there any plan to maintain and maybe fix this for the old backend ? - Aashish Thanks, -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Fri Jul 17 13:22:58 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 17 Jul 2015 17:22:58 +0000 Subject: [vtk-developers] Proposal: Supporting Arrays With Arbitrary Memory Layouts In-Reply-To: References: <20150713225129.1123501140@mail.rogue-research.com> Message-ID: Dave D. We're not deprecating in 6.3 anymore. Following, Shawn's comment, we'll deprecate in 7.0 when we will have the replacement architecture in place as well. Utkarsh On Fri, Jul 17, 2015 at 9:09 AM David E DeMarle wrote: > Utkarsh A, David L, > > Please put Ben and I on the MR as reviewers for the deprecation commit so > we know when to start the release branch. > > thanks > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Jul 14, 2015 at 5:12 AM, Utkarsh Ayachit < > utkarsh.ayachit at kitware.com> wrote: > >> Sean, >> >> That is what I meant :/. The main reason for that was the question that >> how many users are really using Mapped arrays? My suspicion after >> discussing with a few folks was few and far between. While it will be >> nearly impossible support both class hierarchies at the same time for >> vtkDataArray, maybe it's possible to support the 2 things that people using >> mapped arrays did: write a vtkMappedDataArray subclass and >> use vtkDataArrayIteratorMacro. >> >> Utkarsh >> >> On Mon, Jul 13, 2015 at 6:51 PM Sean McBride >> wrote: >> >>> On Mon, 13 Jul 2015 21:07:32 +0000, Utkarsh Ayachit said: >>> >>> >If everything goes smoothly, the plan is to deprecate Mapped Arrays and >>> >supporting classes in VTK 6.3 and replace it with the proposed Generic >>> >Arrays in VTK 7.0. >>> >>> Am I reading that wrong? You can't mark things deprecated without >>> providing a replacement. People's apps will get deprecation warnings with >>> 6.3 that they can't fix because the replacement API doesn't exist in 6.3. >>> >>> Cheers, >>> >>> -- >>> ____________________________________________________________ >>> Sean McBride, B. Eng sean at rogue-research.com >>> Rogue Research www.rogue-research.com >>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>> >>> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Jul 17 14:38:58 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 17 Jul 2015 14:38:58 -0400 Subject: [vtk-developers] Open Position Research Programmer Message-ID: Hi folks, This is from our friends at the UIUC Parallel Programming Laboratory: Now accepting applications for Visiting Research Programmer Close date: Monday, August 3, 2015 (extended) The primary functions of the position are to extend the OpenAtom software and to develop the Argo exascale operating system prototype. Working with the senior research programmer and research staff, the visiting research programmer will help improve Charm++ functionalities as necessary for these and other projects as well as write software for parallel supercomputers and clusters. See full description at: http://charm.cs.illinois.edu/career Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Jul 17 19:59:03 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 17 Jul 2015 19:59:03 -0400 Subject: [vtk-developers] CFP: SC '15 Scientific Visualization Showcase - deadline near Message-ID: Hi folks, Just a reminder that the deadline for the Scientific Visualization Showcase is near. Best, -berk On Tue, May 26, 2015 at 8:18 AM, Berk Geveci wrote: > Hi folks, > > The Call for Participation for the SC '15 Scientific Visualization > Showcase is out. This is a great opportunity for the community to highlight > the wonderful visualization work going on. Please consider submitting an > entry (or more). > > http://sc15.supercomputing.org/program/scientific-visualization-showcase > > SC15?s Visualization and Data Analytics Showcase Program provides a forum > for the year's most instrumental movies in HPC. Six finalists will compete > for the Best Visualization Award, and each finalist will present his or her > movie during a dedicated session at SC15 in a 15-minute presentation. > Movies are judged based on how their movie illuminates science, by the > quality of the movie, and for innovations in the process used for creating > the movie. > > Best, > -berk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonogi1979 at live.jp Mon Jul 20 03:18:41 2015 From: sonogi1979 at live.jp (sonogi1979 at live.jp) Date: Mon, 20 Jul 2015 00:18:41 -0700 (MST) Subject: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation Message-ID: <1437376720973-5732977.post@n5.nabble.com> Hi, You know GPGPU is very hot technology in medical/scientific computing. Especially, I'm working 3D volume processing by using GPGPU(CUDA). To use GPGPU with vtk, I hope an interface for OpenGL-CUDA intraoperation to reduce redundant CPU-GPU data transfer. Simple hack of vtkOpenGLGPUVolumeRayCastMapper is followings: vtkTextureObject* vtkOpenGLGPUVolumeRayCastMapper::GetTextureObject() { return this->Impl->VolumeTextureObject; } When I get the texture object, I can access and operate a volume stored in GPU memory easily by using cudaGraphicsGLRegisterImage, cudaGraphicsMapResources, cudaGraphicsSubResourceGetMappedArray, and cudaBindSurfaceToArray because vtkTextureObject provides a texture handle and texture dimensions. On the other hand, the method is not well designed: no synchronization method among vtkImageData and vtkTextureObject, processed results does not affect in original vtkImageData. If you know better way, please let me know. Thank you, Shinya -- View this message in context: http://vtk.1045678.n5.nabble.com/Regarding-of-OpenGL-GPGPU-intraoperation-tp5732977.html Sent from the VTK - Dev mailing list archive at Nabble.com. From simon.esneault at gmail.com Mon Jul 20 05:02:27 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Mon, 20 Jul 2015 11:02:27 +0200 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Hi Aashish, Thanks for the patchs. However, I've tried them but without success, the GPU rendering won't show up on an Intel HD chipset using the GPURenderDemo (the same exe/dll works fine on a machine with an NVidia/Ati card). The warning disappeared though ... The proposed patchs seems to affect only the TextureMapper 3D, shouldn't there be modification to the vtkOpenGLGPUVolumeRayCastMapper::LoadExtensions method as well? I've tried to uncomment all added lines in the GL_VERSION_1_2_DEPRECATED part of vtkgl.cxx, build correctly everything, and on the problematic machine the checkIfNull() fail for all the lines, the program prints out : Function pointer vtkgl::ColorTable is invalid Function pointer vtkgl::.. is invalid For every one of them. Also the vtkgl.cxx file is generated by the vtkParseOGLExt exe, shouldn't there be modification in the headers glext.h/glxext.h/wglext.h instead ? Maybe this is causing some troubles elsewhere... If you have some other magical trick to solve this, I would be glad to hear about it! Also I can provide more informations if you want Thank You Simon 2015-07-17 17:48 GMT+02:00 Aashish Chaudhary : > Hi Andras, > > Please find the patchs attached. If you run into issues let me know. I > should mention that apply these patches at your discretion as I have not > done enough testing to ensure the quality of the patches but the test > passed last time I applied them. > > > > On Fri, Jul 17, 2015 at 11:40 AM, Andras Lasso wrote: > >> Please share the patch publicly, we would need it for some of our >> projects, too. Thank you! >> >> >> >> Andras >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *Simon ESNEAULT >> *Sent:* Friday, July 17, 2015 11:35 AM >> *To:* Aashish Chaudhary >> *Cc:* VTK Developers; vtkusers at vtk.org; ParaView list >> *Subject:* Re: [vtk-developers] [Paraview] GPU volume rendering failure >> on Intel HD XXXX/Iris, Windows and recent drivers >> >> >> >> Dear Aashish, >> >> >> >> Thank you very much for you answer. >> >> Yes you are right, we are waiting for a new VTK release that defaults to >> the new OpenGL2 backend, for safety and because a change of VTK version >> requires a lot of extra work with our current framework... But the green >> dashboard indeed looks really promising, and we will probably make the move >> as soon as it's ready ! >> >> Meanwhile, I would be really glad if you could send me the patch that >> solves this issue with the old backend, or guide me through the needed >> modification to make it work. >> >> Thanks again >> >> Simon >> >> >> >> 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >> Dear Simon, >> >> >> >> On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT >> wrote: >> >> Hi All, >> >> We're experiencing GPU volume rendering failure on a lot (maybe all ?) >> Intel HD windows system with up to date drivers. >> >> >> This is reproducible in Paraview or with the GPURenderDemo example from >> VTK, just load a volume and try to render the volume... Here is a result >> image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with >> GPU rendering [1] and the same volume with CPU VR rendering [2]. >> Interestingly, the volume rendering used to work with drivers older or >> equal to the version 10.18.10.3496 [3]. As a work around, we ask our >> customers to downgrade their driver version to this one, and they're >> enjoying smooth GPU rendering. But this driver is quite old and does not >> support recent chipset... >> >> I've built and tested the GPURenderDemo with the brand new OpenGL2 >> backend on an affected machine and of course it does work out of the box >> (congratulations for this amazing work !). >> >> Great! >> >> >> >> But our application is FDA/CE marked and we need to wait that this new >> backend is completely ready for prime time. So for now, we have to stick >> with VTK 6.1 ... >> >> >> >> Most of the tests are passing for OpenGL2 ( >> https://open.cdash.org/index.php?project=VTK) on most of the dashboards >> (various configurations etc) but it is a moving target just like VTK itself >> is a moving target. I guess you are waiting for a VTK release that defaults >> to OpenGL2 as oppose to OpenGL? >> >> >> Anyone has any clue ? They're some warning that pop up from paraview >> related to the extension "gl_version_1_2" that could not be loaded, not >> sure if that could be related ? Following this thread [4] and the fix >> proposed, I've tried to replace >> >> /*****************/ >> >> extensions->LoadExtension("GL_VERSION_1_2") >> >> /*****************/ >> >> by >> >> /*****************/ >> >> extensions->LoadExtension("GL_EXT_texture3D"); >> extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); >> >> /*****************/ >> >> in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but >> there is still no volume rendering (tested with GPURenderDemo). Maybe it >> needs some others extensions ? >> >> >> >> Yes, there is a patch and I can send it to you. I have to talk to folks >> here if we can fix the old mapper with those changes but as of now it is >> not in the plan. >> >> >> >> >> Should I fill a bug in paraview, vtk ? Are there any plan to maintain and >> maybe fix this for the old backend ? >> >> >> >> - Aashish >> >> >> >> >> Thanks, >> -- >> >> ------------------------------------------------------------------ >> Simon Esneault >> >> Rennes, France >> ------------------------------------------------------------------ >> >> >> [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG >> >> [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG >> >> [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 >> [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Search the list archives at: http://markmail.org/search/?q=ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/paraview >> >> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> >> >> >> >> >> -- >> >> ------------------------------------------------------------------ >> Simon Esneault >> >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.rosa at kuleuven.be Mon Jul 20 05:11:25 2015 From: benoit.rosa at kuleuven.be (Benoit Rosa) Date: Mon, 20 Jul 2015 11:11:25 +0200 Subject: [vtk-developers] 3DConnexion, regression with VTK6 (was: Build error with 3d Connexion device) In-Reply-To: <55A934AA.7000306@kuleuven.be> References: <55A934AA.7000306@kuleuven.be> Message-ID: <55ACBB3D.7070003@kuleuven.be> Hi all, Following up on the previously reported problem, I just tried to build everything with VTK 5 (VTK 5.10.1 tarball source available on the VTK downloads page). The result is that it works perfectly. I checked again, and in VTK6 the cmake does not make use of the VTK_TDX_INCLUDE_PATH and VTK_TDX_OBJECT_PATH variables, and as such does not find the 3DConnexion library at link, even if it is inside the LD_LIBRARY_PATH. The problem is the same with the 6.1 and 6.2 tarballs from the website, as well as with a fresh checkout from the git repository. I always get a lot of "undefined reference to MagellanX" errors while building : http://pastebin.com/MstU9PbN It seems like a regression to me, since I can't build any VTK 6 version with TDx support. I had a look at the source files that VTK6 can't build with TDx support, and they are mostly similar to VTK5 implementations, so I don't think any problem comes from there. It really looks like there is a problem in the build process that has been introduced with VTK6. I will now forward the following of the discussion to the vtk-developers mailing list, I just posted it on the users list as a pointer, in case somebody encounters the same problem as I do. Best, Benoit On 17/07/15 19:00, Benoit Rosa wrote: > Hi all, > > I try to make a 3DConnexion space navigator work with VTK+Qt on Linux. > I Basically followed the steps given here : > http://www.vtk.org/Wiki/VTK/3DConnexion_Devices_Support (by the way, > the link to the CMakeLists.txt file is wrong). > > I use VTK 6.2 (also tried with version 6.3) and Qt 5, on ubuntu 12.04 > with cmake. > > I will make a long post (sorry) explaining all the different hassles > that I had, because there are many. I tried to look a lot on the > internet for possible resolution, but without much luck. > > Everything goes fine on the driver side, I can run examples and > happily see the cube moving on the screen. Installation of the SDK > goes well, and I can also run xapp without any problem. > > Hassle begins with the Cmake. I can run ccmake and turn on the > VTK_USE_TDx to ON, but have no variable named VTK_TDX_INCLUDE_PATH or > VTK_TDX_OBJECT_PATH. WHen I try to run directly cmake and define those > variables, cmake fires a warning saying that they are not used by the > project. > > Anyway, configuration goes through so let's try to build ... And here > comes a lot of "Undefined reference to MagellanX" errors. I managed to > go through those by editing > Rendering/OpenGL/CMakeFiles/vtkRenderingOpenGL.dir/link.txt and adding > -lxdrvlib to the linker dependencies, but this is getting nasty > already ... But fixing the link, we can go further. > > Now at link of ../../lib/libvtkGUISupportQt-6.2.so, I get the following : > > CMakeFiles/vtkGUISupportQt.dir/QVTKApplication.cxx.o: In function > `QVTKApplication::setDevice(vtkTDxDevice*)': > [home]/VTK-6.2.0/GUISupport/Qt/QVTKApplication.cxx:58: undefined > reference to `QVTKApplication::CreateDevice(vtkTDxDevice*)' > > This error is particularly weird, since CreateDevice is a signal > defined in QVTKApplication.h, I don't really get why it appears. > Moreover, the QObject::connect on line 28 of the same file connects > SIGNAL(CreateDevice(vtkTDxDevice *) , so the undefined reference error > should already fire at that moment ? > > If anybody has some clues for my problem, that would be great. I tried > to hack in here and there, and I manage to get the thing finally > compiling, but get then runtime errors about missing slot > QVTKApplication::setDevice, so I guess I should compile correctly > without hacking in before continuing. > > Thanks for your help ! > Benoit > -- Benoit Rosa, Postdoctoral researcher, PhD KU Leuven, Department of Mechanical Engineering, division PMA Celestijnenlaan 300, box 2420 3001 Leuven Email :benoit.rosa at kuleuven.be Phone : +32 16 37 79 00 -- From aashish.chaudhary at kitware.com Mon Jul 20 09:21:53 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 20 Jul 2015 09:21:53 -0400 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Hi Simon, On Mon, Jul 20, 2015 at 5:02 AM, Simon ESNEAULT wrote: > Hi Aashish, > > Thanks for the patchs. > However, I've tried them but without success, the GPU rendering won't show > up on an Intel HD chipset using the GPURenderDemo (the same exe/dll works > fine on a machine with an NVidia/Ati card). The warning disappeared though > ... > The old mapper had issues on some of the ATI cards (specifically on Mac) and Intel chipset as well. So I am not surprised that it didn't work. > The proposed patchs seems to affect only the TextureMapper 3D, shouldn't > there be modification to > the vtkOpenGLGPUVolumeRayCastMapper::LoadExtensions method as well? > That method calls the vtkGL method I believe which I took care of it. I will have a second look at it today. > > I've tried to uncomment all added lines in the GL_VERSION_1_2_DEPRECATED > part of vtkgl.cxx, build correctly everything, and on the problematic > machine the checkIfNull() fail for all the lines, the program prints out : > Function pointer vtkgl::ColorTable is invalid > Function pointer vtkgl::.. is invalid > For every one of them. > > Also the vtkgl.cxx file is generated by the vtkParseOGLExt exe, shouldn't > there be modification in the headers glext.h/glxext.h/wglext.h instead ? > Maybe this is causing some troubles elsewhere... > Yes and No. Basically what happened was that newer drivers stopped reporting *1_2* variables and that's why you are running into issues. Since the newer backend uses GLEW, all of this mostly works correctly. > > If you have some other magical trick to solve this, I would be glad to > hear about it! Also I can provide more informations if you want > I will have a look at it but even if we can fix all the extension issue, things may not work on Intel. - Aashish > > Thank You > Simon > > > 2015-07-17 17:48 GMT+02:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> Hi Andras, >> >> Please find the patchs attached. If you run into issues let me know. I >> should mention that apply these patches at your discretion as I have not >> done enough testing to ensure the quality of the patches but the test >> passed last time I applied them. >> >> >> >> On Fri, Jul 17, 2015 at 11:40 AM, Andras Lasso wrote: >> >>> Please share the patch publicly, we would need it for some of our >>> projects, too. Thank you! >>> >>> >>> >>> Andras >>> >>> >>> >>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>> Behalf Of *Simon ESNEAULT >>> *Sent:* Friday, July 17, 2015 11:35 AM >>> *To:* Aashish Chaudhary >>> *Cc:* VTK Developers; vtkusers at vtk.org; ParaView list >>> *Subject:* Re: [vtk-developers] [Paraview] GPU volume rendering failure >>> on Intel HD XXXX/Iris, Windows and recent drivers >>> >>> >>> >>> Dear Aashish, >>> >>> >>> >>> Thank you very much for you answer. >>> >>> Yes you are right, we are waiting for a new VTK release that defaults to >>> the new OpenGL2 backend, for safety and because a change of VTK version >>> requires a lot of extra work with our current framework... But the green >>> dashboard indeed looks really promising, and we will probably make the move >>> as soon as it's ready ! >>> >>> Meanwhile, I would be really glad if you could send me the patch that >>> solves this issue with the old backend, or guide me through the needed >>> modification to make it work. >>> >>> Thanks again >>> >>> Simon >>> >>> >>> >>> 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>> Dear Simon, >>> >>> >>> >>> On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>> Hi All, >>> >>> We're experiencing GPU volume rendering failure on a lot (maybe all ?) >>> Intel HD windows system with up to date drivers. >>> >>> >>> This is reproducible in Paraview or with the GPURenderDemo example from >>> VTK, just load a volume and try to render the volume... Here is a result >>> image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with >>> GPU rendering [1] and the same volume with CPU VR rendering [2]. >>> Interestingly, the volume rendering used to work with drivers older or >>> equal to the version 10.18.10.3496 [3]. As a work around, we ask our >>> customers to downgrade their driver version to this one, and they're >>> enjoying smooth GPU rendering. But this driver is quite old and does not >>> support recent chipset... >>> >>> I've built and tested the GPURenderDemo with the brand new OpenGL2 >>> backend on an affected machine and of course it does work out of the box >>> (congratulations for this amazing work !). >>> >>> Great! >>> >>> >>> >>> But our application is FDA/CE marked and we need to wait that this new >>> backend is completely ready for prime time. So for now, we have to stick >>> with VTK 6.1 ... >>> >>> >>> >>> Most of the tests are passing for OpenGL2 ( >>> https://open.cdash.org/index.php?project=VTK) on most of the dashboards >>> (various configurations etc) but it is a moving target just like VTK itself >>> is a moving target. I guess you are waiting for a VTK release that defaults >>> to OpenGL2 as oppose to OpenGL? >>> >>> >>> Anyone has any clue ? They're some warning that pop up from paraview >>> related to the extension "gl_version_1_2" that could not be loaded, not >>> sure if that could be related ? Following this thread [4] and the fix >>> proposed, I've tried to replace >>> >>> /*****************/ >>> >>> extensions->LoadExtension("GL_VERSION_1_2") >>> >>> /*****************/ >>> >>> by >>> >>> /*****************/ >>> >>> extensions->LoadExtension("GL_EXT_texture3D"); >>> extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); >>> >>> /*****************/ >>> >>> in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but >>> there is still no volume rendering (tested with GPURenderDemo). Maybe it >>> needs some others extensions ? >>> >>> >>> >>> Yes, there is a patch and I can send it to you. I have to talk to folks >>> here if we can fix the old mapper with those changes but as of now it is >>> not in the plan. >>> >>> >>> >>> >>> Should I fill a bug in paraview, vtk ? Are there any plan to maintain >>> and maybe fix this for the old backend ? >>> >>> >>> >>> - Aashish >>> >>> >>> >>> >>> Thanks, >>> -- >>> >>> ------------------------------------------------------------------ >>> Simon Esneault >>> >>> Rennes, France >>> ------------------------------------------------------------------ >>> >>> >>> [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG >>> >>> [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG >>> >>> [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 >>> [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the ParaView Wiki at: >>> http://paraview.org/Wiki/ParaView >>> >>> Search the list archives at: http://markmail.org/search/?q=ParaView >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/paraview >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >>> >>> >>> >>> >>> -- >>> >>> ------------------------------------------------------------------ >>> Simon Esneault >>> >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Mon Jul 20 10:11:57 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Mon, 20 Jul 2015 16:11:57 +0200 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Hi Aashish, Thanks you very much for looking into this issue. Our customers (and I believe the community since the issue is visible in paraview) would really benefit from such a fix. Quite a lot of new computers just have an intel chipset nowadays. This of course until the new OpenGL2 backend is ready ! Please let me know if there is anything I can do to help. Thanks a lot Simon 2015-07-20 15:21 GMT+02:00 Aashish Chaudhary : > Hi Simon, > > On Mon, Jul 20, 2015 at 5:02 AM, Simon ESNEAULT > wrote: > >> Hi Aashish, >> >> Thanks for the patchs. >> However, I've tried them but without success, the GPU rendering won't >> show up on an Intel HD chipset using the GPURenderDemo (the same exe/dll >> works fine on a machine with an NVidia/Ati card). The warning disappeared >> though ... >> > > The old mapper had issues on some of the ATI cards (specifically on Mac) > and Intel chipset as well. So I am not surprised that it didn't work. > > >> The proposed patchs seems to affect only the TextureMapper 3D, shouldn't >> there be modification to >> the vtkOpenGLGPUVolumeRayCastMapper::LoadExtensions method as well? >> > > That method calls the vtkGL method I believe which I took care of it. I > will have a second look at it today. > >> >> I've tried to uncomment all added lines in the GL_VERSION_1_2_DEPRECATED >> part of vtkgl.cxx, build correctly everything, and on the problematic >> machine the checkIfNull() fail for all the lines, the program prints out : >> Function pointer vtkgl::ColorTable is invalid >> Function pointer vtkgl::.. is invalid >> For every one of them. >> >> Also the vtkgl.cxx file is generated by the vtkParseOGLExt exe, shouldn't >> there be modification in the headers glext.h/glxext.h/wglext.h instead ? >> Maybe this is causing some troubles elsewhere... >> > > Yes and No. Basically what happened was that newer drivers stopped > reporting *1_2* variables and that's why you are running into issues. Since > the newer backend uses GLEW, all of this mostly works correctly. > >> >> If you have some other magical trick to solve this, I would be glad to >> hear about it! Also I can provide more informations if you want >> > > I will have a look at it but even if we can fix all the extension issue, > things may not work on Intel. > > - Aashish > >> >> Thank You >> Simon >> >> >> 2015-07-17 17:48 GMT+02:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> Hi Andras, >>> >>> Please find the patchs attached. If you run into issues let me know. I >>> should mention that apply these patches at your discretion as I have not >>> done enough testing to ensure the quality of the patches but the test >>> passed last time I applied them. >>> >>> >>> >>> On Fri, Jul 17, 2015 at 11:40 AM, Andras Lasso wrote: >>> >>>> Please share the patch publicly, we would need it for some of our >>>> projects, too. Thank you! >>>> >>>> >>>> >>>> Andras >>>> >>>> >>>> >>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>> Behalf Of *Simon ESNEAULT >>>> *Sent:* Friday, July 17, 2015 11:35 AM >>>> *To:* Aashish Chaudhary >>>> *Cc:* VTK Developers; vtkusers at vtk.org; ParaView list >>>> *Subject:* Re: [vtk-developers] [Paraview] GPU volume rendering >>>> failure on Intel HD XXXX/Iris, Windows and recent drivers >>>> >>>> >>>> >>>> Dear Aashish, >>>> >>>> >>>> >>>> Thank you very much for you answer. >>>> >>>> Yes you are right, we are waiting for a new VTK release that defaults >>>> to the new OpenGL2 backend, for safety and because a change of VTK version >>>> requires a lot of extra work with our current framework... But the green >>>> dashboard indeed looks really promising, and we will probably make the move >>>> as soon as it's ready ! >>>> >>>> Meanwhile, I would be really glad if you could send me the patch that >>>> solves this issue with the old backend, or guide me through the needed >>>> modification to make it work. >>>> >>>> Thanks again >>>> >>>> Simon >>>> >>>> >>>> >>>> 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>> Dear Simon, >>>> >>>> >>>> >>>> On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>> Hi All, >>>> >>>> We're experiencing GPU volume rendering failure on a lot (maybe all ?) >>>> Intel HD windows system with up to date drivers. >>>> >>>> >>>> This is reproducible in Paraview or with the GPURenderDemo example from >>>> VTK, just load a volume and try to render the volume... Here is a result >>>> image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with >>>> GPU rendering [1] and the same volume with CPU VR rendering [2]. >>>> Interestingly, the volume rendering used to work with drivers older or >>>> equal to the version 10.18.10.3496 [3]. As a work around, we ask our >>>> customers to downgrade their driver version to this one, and they're >>>> enjoying smooth GPU rendering. But this driver is quite old and does not >>>> support recent chipset... >>>> >>>> I've built and tested the GPURenderDemo with the brand new OpenGL2 >>>> backend on an affected machine and of course it does work out of the box >>>> (congratulations for this amazing work !). >>>> >>>> Great! >>>> >>>> >>>> >>>> But our application is FDA/CE marked and we need to wait that this >>>> new backend is completely ready for prime time. So for now, we have to >>>> stick with VTK 6.1 ... >>>> >>>> >>>> >>>> Most of the tests are passing for OpenGL2 ( >>>> https://open.cdash.org/index.php?project=VTK) on most of the >>>> dashboards (various configurations etc) but it is a moving target just like >>>> VTK itself is a moving target. I guess you are waiting for a VTK release >>>> that defaults to OpenGL2 as oppose to OpenGL? >>>> >>>> >>>> Anyone has any clue ? They're some warning that pop up from paraview >>>> related to the extension "gl_version_1_2" that could not be loaded, not >>>> sure if that could be related ? Following this thread [4] and the fix >>>> proposed, I've tried to replace >>>> >>>> /*****************/ >>>> >>>> extensions->LoadExtension("GL_VERSION_1_2") >>>> >>>> /*****************/ >>>> >>>> by >>>> >>>> /*****************/ >>>> >>>> extensions->LoadExtension("GL_EXT_texture3D"); >>>> extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); >>>> >>>> /*****************/ >>>> >>>> in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but >>>> there is still no volume rendering (tested with GPURenderDemo). Maybe it >>>> needs some others extensions ? >>>> >>>> >>>> >>>> Yes, there is a patch and I can send it to you. I have to talk to folks >>>> here if we can fix the old mapper with those changes but as of now it is >>>> not in the plan. >>>> >>>> >>>> >>>> >>>> Should I fill a bug in paraview, vtk ? Are there any plan to maintain >>>> and maybe fix this for the old backend ? >>>> >>>> >>>> >>>> - Aashish >>>> >>>> >>>> >>>> >>>> Thanks, >>>> -- >>>> >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>>> >>>> [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG >>>> >>>> [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG >>>> >>>> [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 >>>> [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Please keep messages on-topic and check the ParaView Wiki at: >>>> http://paraview.org/Wiki/ParaView >>>> >>>> Search the list archives at: http://markmail.org/search/?q=ParaView >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/paraview >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Jul 20 10:14:33 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 20 Jul 2015 10:14:33 -0400 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: The OpenGL2 mapper works on most of the intel chipset. I cannot promise that we can get the old mapper working on Intel cards unless it can be fixed by telling it that all the extensions are there. - Aashish On Mon, Jul 20, 2015 at 10:11 AM, Simon ESNEAULT wrote: > Hi Aashish, > > Thanks you very much for looking into this issue. Our customers (and I > believe the community since the issue is visible in paraview) would really > benefit from such a fix. Quite a lot of new computers just have an intel > chipset nowadays. > This of course until the new OpenGL2 backend is ready ! > > Please let me know if there is anything I can do to help. > > Thanks a lot > Simon > > 2015-07-20 15:21 GMT+02:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> Hi Simon, >> >> On Mon, Jul 20, 2015 at 5:02 AM, Simon ESNEAULT > > wrote: >> >>> Hi Aashish, >>> >>> Thanks for the patchs. >>> However, I've tried them but without success, the GPU rendering won't >>> show up on an Intel HD chipset using the GPURenderDemo (the same exe/dll >>> works fine on a machine with an NVidia/Ati card). The warning disappeared >>> though ... >>> >> >> The old mapper had issues on some of the ATI cards (specifically on Mac) >> and Intel chipset as well. So I am not surprised that it didn't work. >> >> >>> The proposed patchs seems to affect only the TextureMapper 3D, shouldn't >>> there be modification to >>> the vtkOpenGLGPUVolumeRayCastMapper::LoadExtensions method as well? >>> >> >> That method calls the vtkGL method I believe which I took care of it. I >> will have a second look at it today. >> >>> >>> I've tried to uncomment all added lines in the GL_VERSION_1_2_DEPRECATED >>> part of vtkgl.cxx, build correctly everything, and on the problematic >>> machine the checkIfNull() fail for all the lines, the program prints out : >>> Function pointer vtkgl::ColorTable is invalid >>> Function pointer vtkgl::.. is invalid >>> For every one of them. >>> >>> Also the vtkgl.cxx file is generated by the vtkParseOGLExt exe, >>> shouldn't there be modification in the headers glext.h/glxext.h/wglext.h >>> instead ? Maybe this is causing some troubles elsewhere... >>> >> >> Yes and No. Basically what happened was that newer drivers stopped >> reporting *1_2* variables and that's why you are running into issues. Since >> the newer backend uses GLEW, all of this mostly works correctly. >> >>> >>> If you have some other magical trick to solve this, I would be glad to >>> hear about it! Also I can provide more informations if you want >>> >> >> I will have a look at it but even if we can fix all the extension issue, >> things may not work on Intel. >> >> - Aashish >> >>> >>> Thank You >>> Simon >>> >>> >>> 2015-07-17 17:48 GMT+02:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> Hi Andras, >>>> >>>> Please find the patchs attached. If you run into issues let me know. I >>>> should mention that apply these patches at your discretion as I have not >>>> done enough testing to ensure the quality of the patches but the test >>>> passed last time I applied them. >>>> >>>> >>>> >>>> On Fri, Jul 17, 2015 at 11:40 AM, Andras Lasso >>>> wrote: >>>> >>>>> Please share the patch publicly, we would need it for some of our >>>>> projects, too. Thank you! >>>>> >>>>> >>>>> >>>>> Andras >>>>> >>>>> >>>>> >>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>> Behalf Of *Simon ESNEAULT >>>>> *Sent:* Friday, July 17, 2015 11:35 AM >>>>> *To:* Aashish Chaudhary >>>>> *Cc:* VTK Developers; vtkusers at vtk.org; ParaView list >>>>> *Subject:* Re: [vtk-developers] [Paraview] GPU volume rendering >>>>> failure on Intel HD XXXX/Iris, Windows and recent drivers >>>>> >>>>> >>>>> >>>>> Dear Aashish, >>>>> >>>>> >>>>> >>>>> Thank you very much for you answer. >>>>> >>>>> Yes you are right, we are waiting for a new VTK release that defaults >>>>> to the new OpenGL2 backend, for safety and because a change of VTK version >>>>> requires a lot of extra work with our current framework... But the green >>>>> dashboard indeed looks really promising, and we will probably make the move >>>>> as soon as it's ready ! >>>>> >>>>> Meanwhile, I would be really glad if you could send me the patch that >>>>> solves this issue with the old backend, or guide me through the needed >>>>> modification to make it work. >>>>> >>>>> Thanks again >>>>> >>>>> Simon >>>>> >>>>> >>>>> >>>>> 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>> Dear Simon, >>>>> >>>>> >>>>> >>>>> On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> We're experiencing GPU volume rendering failure on a lot (maybe all ?) >>>>> Intel HD windows system with up to date drivers. >>>>> >>>>> >>>>> This is reproducible in Paraview or with the GPURenderDemo example >>>>> from VTK, just load a volume and try to render the volume... Here is a >>>>> result image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), >>>>> with GPU rendering [1] and the same volume with CPU VR rendering [2]. >>>>> Interestingly, the volume rendering used to work with drivers older or >>>>> equal to the version 10.18.10.3496 [3]. As a work around, we ask our >>>>> customers to downgrade their driver version to this one, and they're >>>>> enjoying smooth GPU rendering. But this driver is quite old and does not >>>>> support recent chipset... >>>>> >>>>> I've built and tested the GPURenderDemo with the brand new OpenGL2 >>>>> backend on an affected machine and of course it does work out of the box >>>>> (congratulations for this amazing work !). >>>>> >>>>> Great! >>>>> >>>>> >>>>> >>>>> But our application is FDA/CE marked and we need to wait that this >>>>> new backend is completely ready for prime time. So for now, we have to >>>>> stick with VTK 6.1 ... >>>>> >>>>> >>>>> >>>>> Most of the tests are passing for OpenGL2 ( >>>>> https://open.cdash.org/index.php?project=VTK) on most of the >>>>> dashboards (various configurations etc) but it is a moving target just like >>>>> VTK itself is a moving target. I guess you are waiting for a VTK release >>>>> that defaults to OpenGL2 as oppose to OpenGL? >>>>> >>>>> >>>>> Anyone has any clue ? They're some warning that pop up from paraview >>>>> related to the extension "gl_version_1_2" that could not be loaded, not >>>>> sure if that could be related ? Following this thread [4] and the fix >>>>> proposed, I've tried to replace >>>>> >>>>> /*****************/ >>>>> >>>>> extensions->LoadExtension("GL_VERSION_1_2") >>>>> >>>>> /*****************/ >>>>> >>>>> by >>>>> >>>>> /*****************/ >>>>> >>>>> extensions->LoadExtension("GL_EXT_texture3D"); >>>>> extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); >>>>> >>>>> /*****************/ >>>>> >>>>> in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but >>>>> there is still no volume rendering (tested with GPURenderDemo). Maybe it >>>>> needs some others extensions ? >>>>> >>>>> >>>>> >>>>> Yes, there is a patch and I can send it to you. I have to talk to >>>>> folks here if we can fix the old mapper with those changes but as of now it >>>>> is not in the plan. >>>>> >>>>> >>>>> >>>>> >>>>> Should I fill a bug in paraview, vtk ? Are there any plan to maintain >>>>> and maybe fix this for the old backend ? >>>>> >>>>> >>>>> >>>>> - Aashish >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> -- >>>>> >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>>> >>>>> [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG >>>>> >>>>> [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG >>>>> >>>>> [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 >>>>> [4] >>>>> http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html >>>>> >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Please keep messages on-topic and check the ParaView Wiki at: >>>>> http://paraview.org/Wiki/ParaView >>>>> >>>>> Search the list archives at: http://markmail.org/search/?q=ParaView >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/paraview >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Jul 20 11:01:58 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 20 Jul 2015 11:01:58 -0400 Subject: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation In-Reply-To: <1437376720973-5732977.post@n5.nabble.com> References: <1437376720973-5732977.post@n5.nabble.com> Message-ID: Dear Shinya, This sounds great. Please see my comments below: On Mon, Jul 20, 2015 at 3:18 AM, sonogi1979 at live.jp wrote: > Hi, > > You know GPGPU is very hot technology in medical/scientific computing. > Especially, I'm working 3D volume processing by using GPGPU(CUDA). To use > GPGPU with vtk, I hope an interface for OpenGL-CUDA intraoperation to > reduce > redundant CPU-GPU data transfer. > > Simple hack of vtkOpenGLGPUVolumeRayCastMapper is followings: > > vtkTextureObject* vtkOpenGLGPUVolumeRayCastMapper::GetTextureObject() > { > return this->Impl->VolumeTextureObject; > } > When I get the texture object, I can access and operate a volume stored in > GPU memory easily by using cudaGraphicsGLRegisterImage, > cudaGraphicsMapResources, cudaGraphicsSubResourceGetMappedArray, and > cudaBindSurfaceToArray because vtkTextureObject provides a texture handle > and texture dimensions. > > On the other hand, the method is not well designed: no synchronization > method among vtkImageData and vtkTextureObject, processed results does not > affect in original vtkImageData. > Right. If the mapper has not been invoked once, then this will return a un-initialized texture object. I believe the vtkTextureObject has an API to check for its validity. What exactly you are planning to do in CUDA? Thanks, Aashish > > If you know better way, please let me know. > > Thank you, > > Shinya > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Regarding-of-OpenGL-GPGPU-intraoperation-tp5732977.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Jul 20 11:31:17 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 20 Jul 2015 09:31:17 -0600 Subject: [vtk-developers] New-style python classes Message-ID: Hi All, For people who are curious about Python 3 progress, I've created a merge request that updates the python wrappers so that they use new-style python classes (one PyTypeObject per wrapped class). This is the first necessary step towards Py3K compatibility (it'll still be a month or so before you'll be able to use Py3K, however). https://gitlab.kitware.com/vtk/vtk/merge_requests/436 I've done a lot of work to ensure that the wrappers properly respect the C++ rules for method overloading. The concept of method overloading doesn't exist in Python: every python method has only one signature. That means the wrappers are responsible for checking the supplied python arguments and deciding which C++ overload to call. To further complicate the issue, in C++ it is possible for a method to have some signatures that are static and other signatures that are not (in fact, VTK is full of such methods). Python doesn't support this natively, its methods are either static or not, and the whole concept of a method being static or non-static according to what arguments are passed is completely foreign to Python. But for the vtk wrappers this works fine, due to a bunch of custom method generation code. If anyone has a chance to try this out, I'd be interested in hearing the results. It isn't going to be merged until after the VTK 6.3 release has branched. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonogi1979 at live.jp Tue Jul 21 02:25:19 2015 From: sonogi1979 at live.jp (=?iso-2022-jp?B?GyRCPi5MbkxaGyhCIBskQj8/OkgbKEI=?=) Date: Tue, 21 Jul 2015 15:25:19 +0900 Subject: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation In-Reply-To: References: <1437376720973-5732977.post@n5.nabble.com>, Message-ID: Dear Aashish, Thanks for your reply. > What exactly you are planning to do in CUDA? e.g. real-time visualization and reconstruction of freehand 3D ultrasound, reconstructed volume filtering on GPU, etc. Thanks, Shinya ________________________________ > Date: Mon, 20 Jul 2015 11:01:58 -0400 > From: aashish.chaudhary at kitware.com > To: sonogi1979 at live.jp > CC: vtk-developers at vtk.org > Subject: Re: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation > > Dear Shinya, > > This sounds great. Please see my comments below: > > On Mon, Jul 20, 2015 at 3:18 AM, > sonogi1979 at live.jp > > wrote: > Hi, > > You know GPGPU is very hot technology in medical/scientific computing. > Especially, I'm working 3D volume processing by using GPGPU(CUDA). To use > GPGPU with vtk, I hope an interface for OpenGL-CUDA intraoperation to reduce > redundant CPU-GPU data transfer. > > Simple hack of vtkOpenGLGPUVolumeRayCastMapper is followings: > > vtkTextureObject* vtkOpenGLGPUVolumeRayCastMapper::GetTextureObject() > { > return this->Impl->VolumeTextureObject; > } > > When I get the texture object, I can access and operate a volume stored in > GPU memory easily by using cudaGraphicsGLRegisterImage, > cudaGraphicsMapResources, cudaGraphicsSubResourceGetMappedArray, and > cudaBindSurfaceToArray because vtkTextureObject provides a texture handle > and texture dimensions. > > On the other hand, the method is not well designed: no synchronization > method among vtkImageData and vtkTextureObject, processed results does not > affect in original vtkImageData. > > Right. If the mapper has not been invoked once, then this will return a > un-initialized texture object. I believe the vtkTextureObject has an > API to check for its validity. > > What exactly you are planning to do in CUDA? > > Thanks, > Aashish > > If you know better way, please let me know. > > Thank you, > > Shinya > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Regarding-of-OpenGL-GPGPU-intraoperation-tp5732977.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -- > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > | http://www.kitware.com/company/team/chaudhary.html > > _______________________________________________ Powered by > www.kitware.com Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html Search the list > archives at: http://markmail.org/search/?q=vtk-developers Follow this > link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers From robert.maynard at kitware.com Tue Jul 21 10:25:02 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Jul 2015 10:25:02 -0400 Subject: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation In-Reply-To: References: <1437376720973-5732977.post@n5.nabble.com> Message-ID: Hi, Are you going to be mapping the textures for read or write? Are you planning on only binding to 2 and 3D textures, or are you also planning on needing access to the render buffer? On Tue, Jul 21, 2015 at 2:25 AM, ??? ?? wrote: > > Dear Aashish, > > Thanks for your reply. > >> What exactly you are planning to do in CUDA? > > e.g. real-time visualization and reconstruction of freehand 3D ultrasound, reconstructed volume filtering on GPU, etc. > > Thanks, > > Shinya > > ________________________________ >> Date: Mon, 20 Jul 2015 11:01:58 -0400 >> From: aashish.chaudhary at kitware.com >> To: sonogi1979 at live.jp >> CC: vtk-developers at vtk.org >> Subject: Re: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation >> >> Dear Shinya, >> >> This sounds great. Please see my comments below: >> >> On Mon, Jul 20, 2015 at 3:18 AM, >> sonogi1979 at live.jp >> > wrote: >> Hi, >> >> You know GPGPU is very hot technology in medical/scientific computing. >> Especially, I'm working 3D volume processing by using GPGPU(CUDA). To use >> GPGPU with vtk, I hope an interface for OpenGL-CUDA intraoperation to reduce >> redundant CPU-GPU data transfer. >> >> Simple hack of vtkOpenGLGPUVolumeRayCastMapper is followings: >> >> vtkTextureObject* vtkOpenGLGPUVolumeRayCastMapper::GetTextureObject() >> { >> return this->Impl->VolumeTextureObject; >> } >> >> When I get the texture object, I can access and operate a volume stored in >> GPU memory easily by using cudaGraphicsGLRegisterImage, >> cudaGraphicsMapResources, cudaGraphicsSubResourceGetMappedArray, and >> cudaBindSurfaceToArray because vtkTextureObject provides a texture handle >> and texture dimensions. >> >> On the other hand, the method is not well designed: no synchronization >> method among vtkImageData and vtkTextureObject, processed results does not >> affect in original vtkImageData. >> >> Right. If the mapper has not been invoked once, then this will return a >> un-initialized texture object. I believe the vtkTextureObject has an >> API to check for its validity. >> >> What exactly you are planning to do in CUDA? >> >> Thanks, >> Aashish >> >> If you know better way, please let me know. >> >> Thank you, >> >> Shinya >> >> >> >> >> -- >> View this message in context: >> http://vtk.1045678.n5.nabble.com/Regarding-of-OpenGL-GPGPU-intraoperation-tp5732977.html >> Sent from the VTK - Dev mailing list archive at Nabble.com. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> -- >> | Aashish Chaudhary >> | Technical Leader >> | Kitware Inc. >> | http://www.kitware.com/company/team/chaudhary.html >> >> _______________________________________________ Powered by >> www.kitware.com Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html Search the list >> archives at: http://markmail.org/search/?q=vtk-developers Follow this >> link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From houssen at ipgp.fr Tue Jul 21 13:01:18 2015 From: houssen at ipgp.fr (houssen) Date: Tue, 21 Jul 2015 19:01:18 +0200 Subject: [vtk-developers] =?utf-8?q?How_to_get_data_from_a_vtk_pipeline_?= =?utf-8?q?=3F?= Message-ID: <898f6f208d6c170af82768bdf2f7d50d@imap.ipgp.fr> How to get data (node coords, node values, cell values for instance) from a vtk pipeline (that renders a vtkStructuredGrid for instance) ? I have a vtkRenderer. From there, I get a list of vtkActor (for me an actor identify one pipeline - several actors means several pipelines managed by the same renderer : correct ?). From there, for each actor, I get a vtkMapper. How to get data "behind" the mapper (the ones created by the initial source or reader) as, for instance, a vtkStructuredGrid ? I tried vtkMapper::GetInput but I get a crash in several different cases I tried. What is the correct way to get the data ? Is there an example somewhere ? Franck From bill.lorensen at gmail.com Tue Jul 21 13:09:44 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 21 Jul 2015 13:09:44 -0400 Subject: [vtk-developers] vtksys_stl vs std Message-ID: Folks, I believe that vtksys_stl was introduced because at one time, stl was not portable(?). Can we replace all occurrences of vtksys_stl with std? I'm not suggesting that we remove vtksys_stl. But it seems a bit confusing to use it if portability is no ;longer an issues. Currently there are over 400 uses of vtksys_stl (outside of KWsys). std::string vs kwsys_stl::string : 3421 vs 62 std::vector vs kwsys_stl::vector: 2772 vs 96 std::map vs kwsys_stl::map : 891 vs 90 ... Bill From brad.king at kitware.com Tue Jul 21 13:11:44 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 13:11:44 -0400 Subject: [vtk-developers] vtksys_stl vs std In-Reply-To: References: Message-ID: <55AE7D50.6050108@kitware.com> On 07/21/2015 01:09 PM, Bill Lorensen wrote: > Can we replace all occurrences of vtksys_stl with std? Yes, we should be able to do this outside of KWSys. We no longer need vtksys_stl for any of the supported compilers. -Brad From bill.lorensen at gmail.com Tue Jul 21 13:13:01 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 21 Jul 2015 13:13:01 -0400 Subject: [vtk-developers] vtksys_stl vs std In-Reply-To: <55AE7D50.6050108@kitware.com> References: <55AE7D50.6050108@kitware.com> Message-ID: Great, I'll put it on my "it's a bad day for golf" to-do list. On Tue, Jul 21, 2015 at 1:11 PM, Brad King wrote: > On 07/21/2015 01:09 PM, Bill Lorensen wrote: >> Can we replace all occurrences of vtksys_stl with std? > > Yes, we should be able to do this outside of KWSys. We no longer need > vtksys_stl for any of the supported compilers. > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From majcjc at gmail.com Tue Jul 21 22:01:29 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 21 Jul 2015 22:01:29 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: Hi Dr. Thompson, Besides loading external NURBS files, what's the next thing to do? Based on our proposal, we should work on implementing the operation algorithms now. Where do you think I can start with? Best, Lin On Wed, Jul 8, 2015 at 5:06 PM, David Thompson wrote: > Hi Lin, > > > I read the document for BRep format and checked those files in CGM/test. > It seems that only a small part of the test files contains bezier/b-spline > surfaces and all these files contains quite a number of different kinds of > shapes. I can write a class to read such file but it will only display the > bezier/b-spline part. I'm afraid that it will just be a piece of the > original shape which the file represents. Do you think I should do that or > there is a better way to load external shape? > > I think it would be great to start with the parts of the CGM files that > are NURBS. The remaining shapes should either be straight (lines, planes) > or conics (for which you have written a few routines we can use to create > patches that will represent them properly). > > > PS. I opened a new google doc to summarize what we have done now. I will > update new progress to it during the development. (link) > > Great! > > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Jul 21 23:14:12 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 21 Jul 2015 23:14:12 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: <761BA72E-CB7D-4BF5-B9F6-59B3AD87B443@kitware.com> Hi Lin, There are a couple things to do to prepare for the operations 1. Besides handling a square patch (where parametric coordinates are bounded by a d-dimensional rectangle), it would be useful to support a simplicial patch using barycentric coordinates (i.e., (r,s,t) in [0,R]x [0,S]x [0,T] subject to r+s+t <= 1, r >= 0, s >= 0, t >= 0). This can be used to create sets of patches that cover parametric domains of any polyhedral shape, not possible when using only square patches without introducing singularities. We will use this in the contouring algorithm. See https://en.wikipedia.org/wiki/B%C3%A9zier_triangle 2. While you've implemented interpolation, there is also point inversion: determining the parametric coordinates (r,s,t) nearest a given point in world coordinates (x,y,z). The NURBS Book covers this on p. 229. We must use this when cutting (to find where, if anywhere, a patch intersects a cutting surface) and contouring (to find parametric coordinates where a patch takes on a particular scalar value). David > On Jul 21, 2015, at 22:01, Lin M wrote: > > Hi Dr. Thompson, > > Besides loading external NURBS files, what's the next thing to do? Based on our proposal, we should work on implementing the operation algorithms now. Where do you think I can start with? > > Best, > Lin > >> On Wed, Jul 8, 2015 at 5:06 PM, David Thompson wrote: >> Hi Lin, >> >> > I read the document for BRep format and checked those files in CGM/test. It seems that only a small part of the test files contains bezier/b-spline surfaces and all these files contains quite a number of different kinds of shapes. I can write a class to read such file but it will only display the bezier/b-spline part. I'm afraid that it will just be a piece of the original shape which the file represents. Do you think I should do that or there is a better way to load external shape? >> >> I think it would be great to start with the parts of the CGM files that are NURBS. The remaining shapes should either be straight (lines, planes) or conics (for which you have written a few routines we can use to create patches that will represent them properly). >> >> > PS. I opened a new google doc to summarize what we have done now. I will update new progress to it during the development. (link) >> >> Great! >> >> David >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manole.buican at terrasigna.com Wed Jul 22 10:47:00 2015 From: manole.buican at terrasigna.com (Manole Buican) Date: Wed, 22 Jul 2015 14:47:00 +0000 Subject: [vtk-developers] PNG problem Message-ID: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> Hi all, Code like void DlgResVis2D::saveTmpPicture(QString &filename) { vtkNew windowToImageFilter; vtkWindow* pRenderWindow = (vtkWindow *) m_pView->GetRenderWindow(); windowToImageFilter->SetInput(pRenderWindow); windowToImageFilter->SetMagnification(1); windowToImageFilter->SetInputBufferTypeToRGBA(); windowToImageFilter->Update(); vtkSmartPointer writer = vtkSmartPointer ::New(); writer->SetFileName(filename.toAscii()); writer->SetInputConnection(windowToImageFilter->GetOutputPort()); writer->Write(); } exports a picture in PNG on 5 computers. On the sixth computer produce only a 2KB empty PNG file (no error is prompted), while on each other 5 computers produce 35KB PNG file with the same image. Does anybody encounter the same behavior? Thx in advance, Manole Buican -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Wed Jul 22 11:05:23 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Wed, 22 Jul 2015 17:05:23 +0200 Subject: [vtk-developers] PNG problem In-Reply-To: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> Message-ID: Hi Manole, Is the the 2KB PNG file valid and defines an empty/all black image ? Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-22 16:47 GMT+02:00 Manole Buican : > Hi all, > > Code like > > void DlgResVis2D::saveTmpPicture(QString &filename) > { > vtkNew windowToImageFilter; > vtkWindow* pRenderWindow = (vtkWindow *) > m_pView->GetRenderWindow(); > > windowToImageFilter->SetInput(pRenderWindow); > windowToImageFilter->SetMagnification(1); > windowToImageFilter->SetInputBufferTypeToRGBA(); > windowToImageFilter->Update(); > > vtkSmartPointer writer = vtkSmartPointer > ::New(); > writer->SetFileName(filename.toAscii()); > writer->SetInputConnection(windowToImageFilter->GetOutputPort()); > writer->Write(); > } > > exports a picture in PNG on 5 computers. On the sixth computer produce > only a 2KB empty PNG file (no error is prompted), while on each other 5 > computers produce 35KB PNG file with the same image. > Does anybody encounter the same behavior? > > Thx in advance, > Manole Buican > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manole.buican at terrasigna.com Wed Jul 22 11:07:05 2015 From: manole.buican at terrasigna.com (Manole Buican) Date: Wed, 22 Jul 2015 15:07:05 +0000 Subject: [vtk-developers] PNG problem In-Reply-To: References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local>, Message-ID: <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local> Hi Joachim It's a valid white file. Manole ________________________________ From: Joachim Pouderoux [joachim.pouderoux at kitware.com] Sent: Wednesday, July 22, 2015 6:05 PM To: Manole Buican Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] PNG problem Hi Manole, Is the the 2KB PNG file valid and defines an empty/all black image ? Joachim Joachim Pouderoux PhD, Technical Expert Kitware SAS 2015-07-22 16:47 GMT+02:00 Manole Buican >: Hi all, Code like void DlgResVis2D::saveTmpPicture(QString &filename) { vtkNew windowToImageFilter; vtkWindow* pRenderWindow = (vtkWindow *) m_pView->GetRenderWindow(); windowToImageFilter->SetInput(pRenderWindow); windowToImageFilter->SetMagnification(1); windowToImageFilter->SetInputBufferTypeToRGBA(); windowToImageFilter->Update(); vtkSmartPointer writer = vtkSmartPointer ::New(); writer->SetFileName(filename.toAscii()); writer->SetInputConnection(windowToImageFilter->GetOutputPort()); writer->Write(); } exports a picture in PNG on 5 computers. On the sixth computer produce only a 2KB empty PNG file (no error is prompted), while on each other 5 computers produce 35KB PNG file with the same image. Does anybody encounter the same behavior? Thx in advance, Manole Buican _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Wed Jul 22 11:08:49 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Wed, 22 Jul 2015 17:08:49 +0200 Subject: [vtk-developers] PNG problem In-Reply-To: <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local> References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local> Message-ID: Can you try to add windowToImageFilter->ReadFrontBufferOff(); before calling Update()? *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-22 17:07 GMT+02:00 Manole Buican : > Hi Joachim > > > > It's a valid white file. > > > > Manole > > > ------------------------------ > *From:* Joachim Pouderoux [joachim.pouderoux at kitware.com] > *Sent:* Wednesday, July 22, 2015 6:05 PM > *To:* Manole Buican > *Cc:* vtk-developers at vtk.org > *Subject:* Re: [vtk-developers] PNG problem > > Hi Manole, > > Is the the 2KB PNG file valid and defines an empty/all black image ? > > Joachim > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > > 2015-07-22 16:47 GMT+02:00 Manole Buican : > >> Hi all, >> >> Code like >> >> void DlgResVis2D::saveTmpPicture(QString &filename) >> { >> vtkNew windowToImageFilter; >> vtkWindow* pRenderWindow = (vtkWindow *) >> m_pView->GetRenderWindow(); >> >> windowToImageFilter->SetInput(pRenderWindow); >> windowToImageFilter->SetMagnification(1); >> windowToImageFilter->SetInputBufferTypeToRGBA(); >> windowToImageFilter->Update(); >> >> vtkSmartPointer writer = vtkSmartPointer >> ::New(); >> writer->SetFileName(filename.toAscii()); >> writer->SetInputConnection(windowToImageFilter->GetOutputPort()); >> writer->Write(); >> } >> >> exports a picture in PNG on 5 computers. On the sixth computer produce >> only a 2KB empty PNG file (no error is prompted), while on each other 5 >> computers produce 35KB PNG file with the same image. >> Does anybody encounter the same behavior? >> >> Thx in advance, >> Manole Buican >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonogi1979 at live.jp Thu Jul 23 00:35:58 2015 From: sonogi1979 at live.jp (sonogi1979 at live.jp) Date: Wed, 22 Jul 2015 21:35:58 -0700 (MST) Subject: [vtk-developers] Regarding of OpenGL/GPGPU intraoperation In-Reply-To: References: <1437376720973-5732977.post@n5.nabble.com> Message-ID: <1437626158323-5733058.post@n5.nabble.com> Dear Robert, To change volume data of vtkOpenGLGPUVolumeRayCastMapper directly, I'm mapping vtkTextureObject to surface object of CUDA. Also, I succeeded real-time US volume reconstruction by the method. As for me, render buffer is not needed now, but someone may need. My post is just a request of vtk - GPGPU interop interface in future and to share current my approach to access volume data in GPU memory. Thanks, Shinya -- View this message in context: http://vtk.1045678.n5.nabble.com/Regarding-of-OpenGL-GPGPU-intraoperation-tp5732977p5733058.html Sent from the VTK - Dev mailing list archive at Nabble.com. From manole.buican at terrasigna.com Thu Jul 23 07:46:11 2015 From: manole.buican at terrasigna.com (Manole Buican) Date: Thu, 23 Jul 2015 11:46:11 +0000 Subject: [vtk-developers] PNG problem In-Reply-To: References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local>, Message-ID: <9760009C9287EB4EB29C17692C0F5DE52B47F399@SBS.CSCA.local> Yes I did. but does not work. The same results. Thx, Manole Buican ________________________________ From: Joachim Pouderoux [joachim.pouderoux at kitware.com] Sent: Wednesday, July 22, 2015 6:08 PM To: Manole Buican Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] PNG problem Can you try to add windowToImageFilter->ReadFrontBufferOff(); before calling Update()? Joachim Pouderoux PhD, Technical Expert Kitware SAS 2015-07-22 17:07 GMT+02:00 Manole Buican >: Hi Joachim It's a valid white file. Manole ________________________________ From: Joachim Pouderoux [joachim.pouderoux at kitware.com] Sent: Wednesday, July 22, 2015 6:05 PM To: Manole Buican Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] PNG problem Hi Manole, Is the the 2KB PNG file valid and defines an empty/all black image ? Joachim Joachim Pouderoux PhD, Technical Expert Kitware SAS 2015-07-22 16:47 GMT+02:00 Manole Buican >: Hi all, Code like void DlgResVis2D::saveTmpPicture(QString &filename) { vtkNew windowToImageFilter; vtkWindow* pRenderWindow = (vtkWindow *) m_pView->GetRenderWindow(); windowToImageFilter->SetInput(pRenderWindow); windowToImageFilter->SetMagnification(1); windowToImageFilter->SetInputBufferTypeToRGBA(); windowToImageFilter->Update(); vtkSmartPointer writer = vtkSmartPointer ::New(); writer->SetFileName(filename.toAscii()); writer->SetInputConnection(windowToImageFilter->GetOutputPort()); writer->Write(); } exports a picture in PNG on 5 computers. On the sixth computer produce only a 2KB empty PNG file (no error is prompted), while on each other 5 computers produce 35KB PNG file with the same image. Does anybody encounter the same behavior? Thx in advance, Manole Buican _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From updega2 at berkeley.edu Thu Jul 23 14:12:38 2015 From: updega2 at berkeley.edu (updega2) Date: Thu, 23 Jul 2015 11:12:38 -0700 (MST) Subject: [vtk-developers] Changes in vtkDelaunay2D between vtk 6.0 and 6.2 Message-ID: <1437675158550-5733077.post@n5.nabble.com> Hi all, A while ago, I wrote some code that used and worked well with vtk 6.0. I upgraded to vtk 6.2, and now I get different results from the code and it crashes fairly often. I was able to locate that the errors were occurring in vtkDelaunay2D. I noticed that instead of using a std::set for some points, the class is now using vtk structures. I was wondering what is the best way to find out exactly what changes were made between the versions and why these changes were made? It seems like the filter has become less robust, and I would like to be able to continue using my code with an updated vtk. Thanks in advance! Adam -- View this message in context: http://vtk.1045678.n5.nabble.com/Changes-in-vtkDelaunay2D-between-vtk-6-0-and-6-2-tp5733077.html Sent from the VTK - Dev mailing list archive at Nabble.com. From will.schroeder at kitware.com Thu Jul 23 14:16:25 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 23 Jul 2015 14:16:25 -0400 Subject: [vtk-developers] Changes in vtkDelaunay2D between vtk 6.0 and 6.2 In-Reply-To: <1437675158550-5733077.post@n5.nabble.com> References: <1437675158550-5733077.post@n5.nabble.com> Message-ID: I'm sorry to hear about your hassles. The best ways to deal with situations like this is to create a test and provide data that demonstrates the behavior. Is this possible? W On Thu, Jul 23, 2015 at 2:12 PM, updega2 wrote: > Hi all, > > A while ago, I wrote some code that used and worked well with vtk 6.0. I > upgraded to vtk 6.2, and now I get different results from the code and it > crashes fairly often. I was able to locate that the errors were occurring > in > vtkDelaunay2D. I noticed that instead of using a std::set for some points, > the class is now using vtk structures. > > I was wondering what is the best way to find out exactly what changes were > made between the versions and why these changes were made? It seems like > the > filter has become less robust, and I would like to be able to continue > using > my code with an updated vtk. > > Thanks in advance! > > Adam > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Changes-in-vtkDelaunay2D-between-vtk-6-0-and-6-2-tp5733077.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From updega2 at berkeley.edu Thu Jul 23 14:19:46 2015 From: updega2 at berkeley.edu (updega2) Date: Thu, 23 Jul 2015 11:19:46 -0700 (MST) Subject: [vtk-developers] Changes in vtkDelaunay2D between vtk 6.0 and 6.2 In-Reply-To: References: <1437675158550-5733077.post@n5.nabble.com> Message-ID: <1437675586029-5733079.post@n5.nabble.com> Hi Will, Thanks for the response. I should be able to do this. When I get data together, what is the best way to get it to you/vtk? Thanks, Adam -- View this message in context: http://vtk.1045678.n5.nabble.com/Changes-in-vtkDelaunay2D-between-vtk-6-0-and-6-2-tp5733077p5733079.html Sent from the VTK - Dev mailing list archive at Nabble.com. From will.schroeder at kitware.com Thu Jul 23 14:25:11 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 23 Jul 2015 14:25:11 -0400 Subject: [vtk-developers] Changes in vtkDelaunay2D between vtk 6.0 and 6.2 In-Reply-To: <1437675586029-5733079.post@n5.nabble.com> References: <1437675158550-5733077.post@n5.nabble.com> <1437675586029-5733079.post@n5.nabble.com> Message-ID: The "best" way is to create a topic branch in gitlab with the new test and data. And then we can pull it over here. That way you'll retain some ownership, etc. If this is too much work, just sent it to me / or let me know where to grab the data and test and we'll grab it, etc. W On Thu, Jul 23, 2015 at 2:19 PM, updega2 wrote: > Hi Will, > > Thanks for the response. I should be able to do this. When I get data > together, what is the best way to get it to you/vtk? > > Thanks, > > Adam > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Changes-in-vtkDelaunay2D-between-vtk-6-0-and-6-2-tp5733077p5733079.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Thu Jul 23 15:00:00 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 23 Jul 2015 21:00:00 +0200 Subject: [vtk-developers] Changes in vtkDelaunay2D between vtk 6.0 and 6.2 In-Reply-To: <1437675158550-5733077.post@n5.nabble.com> References: <1437675158550-5733077.post@n5.nabble.com> Message-ID: Adam, *> I noticed that instead of using a std::set for some points, the class is now using vtk structures.* Actually it seems to be the contrary, I added some piece of code that use std::set since VTK 6.1. Please send the input data (a VTK file for instance) that generates an issue along with the filter parameters you use and I will try understand what is happening here. Best, Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-23 20:12 GMT+02:00 updega2 : > Hi all, > > A while ago, I wrote some code that used and worked well with vtk 6.0. I > upgraded to vtk 6.2, and now I get different results from the code and it > crashes fairly often. I was able to locate that the errors were occurring > in > vtkDelaunay2D. I noticed that instead of using a std::set for some points, > the class is now using vtk structures. > > I was wondering what is the best way to find out exactly what changes were > made between the versions and why these changes were made? It seems like > the > filter has become less robust, and I would like to be able to continue > using > my code with an updated vtk. > > Thanks in advance! > > Adam > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Changes-in-vtkDelaunay2D-between-vtk-6-0-and-6-2-tp5733077.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From updega2 at berkeley.edu Thu Jul 23 15:02:32 2015 From: updega2 at berkeley.edu (updega2) Date: Thu, 23 Jul 2015 12:02:32 -0700 (MST) Subject: [vtk-developers] Changes in vtkDelaunay2D between vtk 6.0 and 6.2 In-Reply-To: References: <1437675158550-5733077.post@n5.nabble.com> Message-ID: <1437678152146-5733085.post@n5.nabble.com> Okay, Thank you Will and Joachim. I will let you guys know when I have done this, and we can try to figure it out. Thanks, Adam -- View this message in context: http://vtk.1045678.n5.nabble.com/Changes-in-vtkDelaunay2D-between-vtk-6-0-and-6-2-tp5733077p5733085.html Sent from the VTK - Dev mailing list archive at Nabble.com. From hahnse at ornl.gov Thu Jul 23 18:12:12 2015 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Thu, 23 Jul 2015 22:12:12 +0000 Subject: [vtk-developers] vtkGridSynchronizedTemplates3D and zero copy arrays In-Reply-To: References: Message-ID: I noticed that the changes to vtkGridSynchronizedTemplates3D() for zero copy arrays discussed in the Kitware blog(http://www.kitware.com/blog/home/post/846) aren't currently in VTK. Are there any plans to merge these changes into master? Best, Steven Hahn -------------- next part -------------- An HTML attachment was scrubbed... URL: From manole.buican at terrasigna.com Fri Jul 24 03:44:33 2015 From: manole.buican at terrasigna.com (Manole Buican) Date: Fri, 24 Jul 2015 07:44:33 +0000 Subject: [vtk-developers] PNG problem In-Reply-To: References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local>, Message-ID: <9760009C9287EB4EB29C17692C0F5DE52B47F3D1@SBS.CSCA.local> Hi Joachim, I tried what you suggested, but.. the same results. The system involved is a machine with Genuine Intel (R) CPU, U7300 @ 1.3 GHz, RAM 4 GB, Win 7, 64 bits and Mobile Intel(R) 4 Series Express Chipset Family video card. Thx, Manole ________________________________ From: Joachim Pouderoux [joachim.pouderoux at kitware.com] Sent: Wednesday, July 22, 2015 6:08 PM To: Manole Buican Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] PNG problem Can you try to add windowToImageFilter->ReadFrontBufferOff(); before calling Update()? Joachim Pouderoux PhD, Technical Expert Kitware SAS 2015-07-22 17:07 GMT+02:00 Manole Buican >: Hi Joachim It's a valid white file. Manole ________________________________ From: Joachim Pouderoux [joachim.pouderoux at kitware.com] Sent: Wednesday, July 22, 2015 6:05 PM To: Manole Buican Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] PNG problem Hi Manole, Is the the 2KB PNG file valid and defines an empty/all black image ? Joachim Joachim Pouderoux PhD, Technical Expert Kitware SAS 2015-07-22 16:47 GMT+02:00 Manole Buican >: Hi all, Code like void DlgResVis2D::saveTmpPicture(QString &filename) { vtkNew windowToImageFilter; vtkWindow* pRenderWindow = (vtkWindow *) m_pView->GetRenderWindow(); windowToImageFilter->SetInput(pRenderWindow); windowToImageFilter->SetMagnification(1); windowToImageFilter->SetInputBufferTypeToRGBA(); windowToImageFilter->Update(); vtkSmartPointer writer = vtkSmartPointer ::New(); writer->SetFileName(filename.toAscii()); writer->SetInputConnection(windowToImageFilter->GetOutputPort()); writer->Write(); } exports a picture in PNG on 5 computers. On the sixth computer produce only a 2KB empty PNG file (no error is prompted), while on each other 5 computers produce 35KB PNG file with the same image. Does anybody encounter the same behavior? Thx in advance, Manole Buican _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Fri Jul 24 04:24:32 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 24 Jul 2015 10:24:32 +0200 Subject: [vtk-developers] PNG problem In-Reply-To: <9760009C9287EB4EB29C17692C0F5DE52B47F3D1@SBS.CSCA.local> References: <9760009C9287EB4EB29C17692C0F5DE52B47EB4F@SBS.CSCA.local> <9760009C9287EB4EB29C17692C0F5DE52B47F368@SBS.CSCA.local> <9760009C9287EB4EB29C17692C0F5DE52B47F3D1@SBS.CSCA.local> Message-ID: Could you try to add a pRenderWindow->Render(); before calling windowToImageFilter->Update(); ? Do that and try with and ReadFrontBufferOff() and then with ReadFrontBufferOn(). Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-24 9:44 GMT+02:00 Manole Buican : > Hi Joachim, > > > > I tried what you suggested, but.. the same results. The system involved is > a machine with Genuine Intel (R) CPU, U7300 @ 1.3 GHz, RAM 4 GB, Win 7, 64 > bits and Mobile Intel(R) 4 Series Express Chipset Family video card. > > > > Thx, > > Manole > > > ------------------------------ > *From:* Joachim Pouderoux [joachim.pouderoux at kitware.com] > *Sent:* Wednesday, July 22, 2015 6:08 PM > > *To:* Manole Buican > *Cc:* vtk-developers at vtk.org > *Subject:* Re: [vtk-developers] PNG problem > > Can you try to add windowToImageFilter->ReadFrontBufferOff(); before > calling Update()? > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > > 2015-07-22 17:07 GMT+02:00 Manole Buican : > >> Hi Joachim >> >> >> >> It's a valid white file. >> >> >> >> Manole >> >> >> ------------------------------ >> *From:* Joachim Pouderoux [joachim.pouderoux at kitware.com] >> *Sent:* Wednesday, July 22, 2015 6:05 PM >> *To:* Manole Buican >> *Cc:* vtk-developers at vtk.org >> *Subject:* Re: [vtk-developers] PNG problem >> >> Hi Manole, >> >> Is the the 2KB PNG file valid and defines an empty/all black image ? >> >> Joachim >> >> *Joachim Pouderoux* >> >> *PhD, Technical Expert* >> *Kitware SAS * >> >> >> 2015-07-22 16:47 GMT+02:00 Manole Buican : >> >>> Hi all, >>> >>> Code like >>> >>> void DlgResVis2D::saveTmpPicture(QString &filename) >>> { >>> vtkNew windowToImageFilter; >>> vtkWindow* pRenderWindow = (vtkWindow *) >>> m_pView->GetRenderWindow(); >>> >>> windowToImageFilter->SetInput(pRenderWindow); >>> windowToImageFilter->SetMagnification(1); >>> windowToImageFilter->SetInputBufferTypeToRGBA(); >>> windowToImageFilter->Update(); >>> >>> vtkSmartPointer writer = vtkSmartPointer >>> ::New(); >>> writer->SetFileName(filename.toAscii()); >>> >>> writer->SetInputConnection(windowToImageFilter->GetOutputPort()); >>> writer->Write(); >>> } >>> >>> exports a picture in PNG on 5 computers. On the sixth computer produce >>> only a 2KB empty PNG file (no error is prompted), while on each other 5 >>> computers produce 35KB PNG file with the same image. >>> Does anybody encounter the same behavior? >>> >>> Thx in advance, >>> Manole Buican >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Fri Jul 24 08:59:01 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 24 Jul 2015 12:59:01 +0000 Subject: [vtk-developers] vtkGridSynchronizedTemplates3D and zero copy arrays In-Reply-To: References: Message-ID: Steven, We're working on a newer version of the zero-copy infrastructure. This and other such filters will be update to use this newer infrastructure when that happens. It's currently planned for VTK 7.0/ParaVIew 5.0 release. You can follow the development/discussion here: http://public.kitware.com/pipermail/vtk-developers/2015-July/032250.html Utkarsh On Thu, Jul 23, 2015 at 6:12 PM Hahn, Steven E. wrote: > I noticed that the changes to vtkGridSynchronizedTemplates3D() for zero > copy arrays discussed in the Kitware blog( > http://www.kitware.com/blog/home/post/846) aren?t currently in VTK. Are > there any plans to merge these changes into master? > > Best, > Steven Hahn > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Jul 24 15:07:54 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Jul 2015 15:07:54 -0400 Subject: [vtk-developers] Announce: vtk 6.3.0 release candidate 1 is ready Message-ID: <20150724190754.GA29467@megas.kitware.com> The VTK developement team is happy to announce that VTK 6.3 has entered the release candidate stage! You can find the source, data, and new vtkpython binary packages here: http://www.vtk.org/VTK/resources/software.html#releasecandidate Please try this version of VTK and report any issues to the list or the bug tracker so that we can try to address them before VTK 6.3.0 final. The official release notes will be available when VTK final is released in the next few weeks. In the meantime here is a preview: - new OpenMP backend for vtkSMPTools; - new MPI-IO backend for PLOT3D reader; - new vtkPlotArea for rendering area (or range) plots; - multithreaded Gaussian splatter class; - multithreading support in the vtkSampleFunction; - compiler uplifts: gcc-4.1 and Visual Studio 2008 or newer are required; - the Piston and Dax accelerator modules are deprecated; - writing side and node sets in Exodus files; - skip NaN values in vtkDataArray::GetRange(); - reading compressed TIFF files with sub-extents; - support for OpenGL 3.2 in the (still experimental, but much less so) OpenGL2 backend; - text rendering now respects the DPI of the vtkWindow; - vtkAxis respects the TileScale setting of vtkWindow; And many bug fixes across the codebase. We hope you enjoy this release of VTK! As always, contact Kitware and the mailing lists for assistance. Thanks, --Ben -------------- next part -------------- Aashish Chaudhary (41): 57e88c1 Maximize or minimize each component for independent components 8449d38 Fixed additive blending for independent components 1a9bf2c Added initial support for 2 and 3 components f965f01 Fixed style 4f1b234 Fixed bad switch case 51af002 Compute the range correctly when dealing with 2-3 components f43b21b Keep the comments in the final shader string 0267974 Added support for dependent components 0e116ee Match tokens with method names 763a34b Fixing shader for 2 & 3 component f1560bd Fixed dependent component test failing cf8933f Fix GL extensions not reported on Mac OpenGL2 context 68696e8 Reset active texture to texture 0 50f28ce Saving and restoring GL state 921f8ae Fixed comment 157cbce Clamp texture unit to 0 and GL_MAX_TEXTURE_IMAGE_UNITS 0c0e6fe Fixed accessing invalid texture unit manager 4b16378 Using a consistent style within a method 77cafc5 Compute light position only once 64a5d18 Optimize lighting code some more 0951daa Reset number of lights b19c903 Some more optimizations for better performance 29d82b5 Respect interpolation type set on volume property e79e082 Fixed invalid variable names used for gradient computation 46a99ec Fixed check on interpolation type a4f6ac2 Updated default interpolation type for test 8b6889e Fixed style 501b9e5 Added check on when to update volume parameters a2f1b5f Do not update light parameters if shading is OFF ed6d37a Fixed compiler warning 65bcee5 Some more optimizations 921a22e Do not compute color if opacity is zero 6d4e699 Updated code to new computeColor signature 298d5a8 Avoid computation of fragment world position repeatedly 4fa1bd3 Fixed failing VTK tests ab7e903 Removed debug message 938c879 Fixed issues with interactive volume rendering a5890e6 Fixed styles and added notes 5df033a Fixed ReductionFactor not initialized that was causing tests to hangup 20b2a4a Added alternate baseline with jitter for GL2 f95de30 Updated test to new ivar to turn off auto adjust sample distance Andras Lasso (1): d307b83 BUG: Fixed vtkImageReslice HitInputExtent update Andrew Bauer (6): 4c8af46 Fix for bad cached cell id for flow path filters. 76c2b85 Particle path fixes. a002739 Getting rid of unused variable warning in release builds. b8ce5c3 Fixed memory issue and reinject frequency counter. bdf2e02 Adding in piece information for XMLPMultiBlockDataWriter. 56f0d7e Fix issue if there aren't any blocks. Andrew Maclean (20): 5637ce6 Remove the unnecessary find_package command. 70d3510 Visual Studio 2013 requires the header. 9349a38 Visual Studio 2013 requires the header. 8b81b92 A minor fix eliminating a CMP0043 warning. 23d1d38 Added TestEmptyInput.py 4a1cec5 Refactoring TestEmptyInput.py 19a774f Convert TestSetGet from TCL to Python. 87eb785 Added a new class to exclude. 14eb327 Missing comma. 0492d1f Adding another class to exclude in an attempt to fix release mode on OSX. 7c09e25 Removing two classes in LinuxExceptions. 713bb57 Adding back some classes to the exception list. c49a214 Test - see if vtkView as a friend is causing failures. 9425e69 Reverting 10084b6 Reverting c136c15 A patch from Utkarsh ef5e00b These scripts only run using Python 2.6 or greater. 22e17c5 Display information about the VTK test folders. 3a65a45 Converted more Tcl scripts to Python. 7fb2289 BUG: This import is unnecessary. Arnaud Gelas (1): fae5f10 Fix typo in FindTBB.cmake which makes it impossible to use TBB on MacOSX Ben Boeckel (35): a701e9c windows: compile the vtkpython.rc file separately b144b68 vtkpython: avoid vtkpythonrc hack in Visual Studio 4265bc0 docs: add buildbot information 2967cbb docs: buildbot label is no more 8d04f57 python: silence warnings about round redefinition eaa25b5 vtkMPICommunicator: check for 2.0 89fb55e java: remove screamake and quote paths 1175385 java: refactor out writing paths to the file 9593e16 java: quote arguments 9792dc2 java: add missing java files 118d9b7 python: add the generated files to the list as well 7c6acd1 freetype: update baselines to support freetype 2.5.3 55db776 testing: set PROCESSORS property for MPI tests b5fc340 FindJsonCpp: add version detection ecc6715 ThirdParty: add minimum version support 80f3f3d jsoncpp: mark that 0.7.0 is the minimum version 1b35883 vtkFFMPEGWriter: conditionalize a GCC pragma dae8b1b FindJsonCpp: fix typo in regex e57d5aa JsonCpp: the VERSION_VAR is a separate signature ee83098 QVTKWidget2: call the direct parent class c0ac4f1 QVTKWidget2: use Superclass typedef internally 1cf2f9b doxygen: generate SVG images f3450ca vtkRAdapter: move R_NO_REMAP to the header 36b7d40 mpi4py: strip trailing whitespace from the include dir 5b0f6ab typos: fix 'writting' -> 'writing' ea06eda vtkWin32ProcessOutputWindow: fix string literal a7c2dd7 vtkXMLUnstructuredDataWriter: also check for string output 5ad33c5 qtgraphicsview: remove unused vtkgl.h includes d9ac721 vtkGenericOpenGLRenderWindow: add PushState/PopState methods 6e14fa7 QVTKGraphicsItem: support the OpenGL2 backend bba39d5 vtkOpenGLRenderUtilities: move Render{Quad,Triangle} 1650168 IOXML: add test for outputting to a string a32d553 modules: use the export name for the file 46f1b60 Testing: fix unused variable warnings 2166c06 FiltersStatisticsGnuR: fix R_NO_REMAP juggling Berk Geveci (14): ba37dcd Fixed issue with vtkPointSet::FindCell(). e5b3e47 Impoved check for ascii file in PLOT3D reader. 38fd595 Fixed compiler warning 6c510c6 Initial point data support in AMR base reader 4c3491b Added point array support to vtkAMRBaseReader 34d5b0745 Moved Plot3D reader to IO/Parallel. 2e541e5 Making the Plot3D reader parallel. 1c0cfb9 Improved ghost array generation. 0027efa Do not rexecute based on ghosts for serial execution 9c1667f Do not override DATA_NUMBER_OF_GHOST_LEVELS() unnecesarily. 5f15c59 Cleaned up error handling in plot3d reader. 005e70d Fixed warnings. d91ecf9 BUG: Was using the wrong extent in computation. f4126e3 Fixed bug with loading 2D or ASCII datasets in parallel. Bill Hoffman (1): 56db190 Use Qt5 COMPNENTS in find_package instead of finding each package directly. Bill Lorensen (18): d59d439 COMP: Member template function use on Mac bc10e20 COMP: Member template function use on Mac f7106e4 ENH: Modernize RIBExporter and RIBProperty 26a1b4c COMP: Memory leak in new test d8ae26c ENH: define VTK_MAXPATH bf855f4 COMP: Typo causes compile error 5316177 COMP: Memory leak in vtkOBJImporter 45fe62d STYLE: OBJImporter style cf1d561 COMP: Adjust fuzzy compare tolerance ad0192a COMP: Adjust fuzzy compare tolerance for scalar divide 2663daa BUG: PentagonalPrism bug b052d7b COMP: TestPentagonalPrism mempry leak 8044bf4 ENH: Unit Test for Linear, Quadratic and BiQuadratic Cells 6890ae4 ENH: Remove unused tcl tests 69ff5a0 ENH: Restore Common/DataModel Cxx tests 1531bc3 BUG: Missing data file 1491288 ENH: Removed unused vtkExplicitCell ef927f0 ENH: Remote module capability Brad King (45): b7daff9 setup-stage: Optionally reconfigure topic stage d2d17f5 setup-gerrit: Allow ssh-only repo URLs c950cd6 setup-stage: Allow 'url' without 'pushurl' ac271ab Tell Git how to check GitSetup config files 341043c Add 'git-gerrit-push' script e848bb0 setup-hooks: Create .git hooks directory if necessary 80ace5f Avoid bash history expansion in developer setup scripts ba82ebc ExternalData: Allow local stores without any URL templates 2943e4f ExternalData: Add support for custom download scripts 2acd7ec ExternalData: Add support for custom algorithm-to-URL mapping 71aa0ce ExternalData: Update documentation to match CMake copy cd49e59 git-gerrit-push: Refine topic name validation e7e0682 git-gerrit-push: Append topic to refspecs instead of overwriting 30ff0dc git-gerrit-push: Avoid bash history expansion 40f508c git-gerrit-push: Fetch 'master' before checking refspecs 51a0143 Add 'setup-upstream' script to help users configure preferred upstream a595712 Add 'setup-gitlab' script to configure GitLab access 35e3b8d Add 'git-gitlab-push' script to help users push to their GitLab fork 95495ff git-gitlab-push: Print follow-up instructions and links for user 0f226a5 git-gitlab-push: Keep user fork 'master' up to date if possible 0227465 git-gitlab-push: Document options on multiple lines in usage a687ee2 git-gitlab-push: Require a '--force' option to force-push the topic 370a7eb Teach our 'git-gitlab-push' script to push ExternalData content 98ecd48 Drop mention of Gerrit from instructions in third-party README files ac802c7 Disable gerrit-push and stage aliases b1a0f22 Switch developer setup to use the GitLab workflow 328cb75 Tell Git how to check Markdown (.md) source files 9f088f0 Documentation: Add VTK Git instructions 8c49fc0 CONTRIBUTING: Update for GitLab workflow ef92e52 README.md: Add document introducing VTK and linking to resources 8b49512 README.html: Remove out-dated document 2f89fb5 Documentation: Revise Merge Request creation instructions 0bd3fbd Documentation: Add links to GitLab markdown documentation 7651b7b Documentation: Revise Git development docs to mention fork step cbe8ad6 setup-upstream: Tolerate lack of existing upstream pushurl afeb020 Report developer setup-upstream failure explicitly 49ce42f CONTRIBUTING: Restore link to dev/git/README.md document 6f89705 Documentation: Explain how to keep a GitLab fork `master` in sync 4e066e0 Documentation: Explain to reviewers how to fetch Merge Request changes 8485843 Fix 'git-gitlab-push' ExternalData push for duplicate objects ab5456f Documentation: Update required Git version to 1.7.2 30c437a Documentation: Define reviewer vote shortcuts and meanings 78012ba KWSys: Tell Git not to export .gitattributes 997b34f Add vtkPeriodicDataArray to list of sources in its module 230948e vtkhdf5: Suppress VS 2015 assertion failure popup during try_run Burlen Loring (1): d2582c6 buffering issue in vtkweb Chris Harris (3): 39fedcd Wait for resize notification in SetSize(...) 30eedf0 Revert "Wait for resize notification in SetSize(...)" 2ea3f61 vtkWeb: Ensure that we get the image size requested Chuck Atkins (1): 56454c5 ADIOS: Remove block-index calculations to use new APIs Cory Quammen (14): e0f018c Added vtkPolyLineSource 9ac195f Added vtkPolyLineRepresentation and vtkPolyLineWidget e52e1b4 Added base class for representations of curves eab3e38 Tests for vtkPolyLine{Widget,Source,Representation} 43a9b05 Added checking for NULL pointer in a few locations dac748a BUG 15365: Fixed crash in function called from multiple threads 67122e8 BUG: Fixed error in area-weighted normal e2cd069 Initialized all member variables in vtkCurveRepresentation c673bee Various fixes for vtkPolyLine{Source,Representation} df922af Initialized test values 8cc3d7a BUG: added output points precision for structured grids 882dfbf Added test for vtkDataSetSurfaceFilter 13aa55c BUG: Direct scalar coloring with string arrays caused crash e61a328 Move table resizing out of core mapping routine Dan Lipsa (42): 4b1dbe9 Solve warnings on the ICC compiler. 4dee027 Redesign "vtkGhostLevels" arrays and related ghost functionalties. bc0f56f Fix warnings. 156f895 Solve windows warnings. 66a9834 Remove warning when a array name for labeling is not found. f9b5404 Use previous version for XML files if there is no vtkGhostType array. f0a6f29 BUG #15199: EnSightReader does not crash if you change CaseFileName 46bde59 VTK XML files are saved using previous version if possible. 4834510 Update documentation for save VTK XML using previous version. bbcecbe BUG: Fix valgrind complaint about uninitialised values. 8491ed5 BUG: Blanked cell is marked as a blanked point. 69198ba ENH: Remove legacy code from before vtk-6.1 (2014-01-21) f48e262 ENH: Add GatherV for vtkDataObjects 496947d BUG: Mismatch between # of points and # of tcoords results in segfault 784b5c5 BUG: XMLMultiBlockDataWriter always pointed to vtp files. 1aa9f59 BUG: Add additional baselines to deal # of digits in exponent. 9dff41c BUG: Fix uninitialized values that caused segfault. 5f3f8d0 BUG: Skiped a number when adding a baseline. 741f7c5 BUG: Skipped a number when adding a baseline. 8ff2926 BUG: Test passed because two wrongs made it right. de18c2e ENH: Ghost changes documentation update. 826f7a4 BUG: Fix initialization and typo problems. 76acfea BUG: Enable vtkFiltersSourcesPython-squadViewer only if Module_vtkRenderingTk 1d4eb79 BUG: vtkTestingInteractor cannot create timers which results in errors. 5ddf702 BUG: Fix link warnings for static build on windows. 7d6f8f1 BUG: Teach ImageSlice and ImageSliceMapper to deal with empty slices d12e800 BUG: InteractorEventRecorder bug results warning about passive observer. cdd2e19 BUG: Fix test volume of interest to match data extents 6fad8fe ENH: TestChangeInformation does not print error message. 5693e5f BUG: Fix warning 'Resetting view-up since view plane normal is parallel' 7f7eb20 BUG: Fix warning 'Resetting view-up since view plane normal is parallel' 04fbdbb BUG: This fixes a valgrind complaint. fe7c638 BUG: We need a Renderer for HasTranslucentPolygonalGeometry 2a3dcbd BUG: Fix version for ghost documentation. 96baf8e BUG: Get rid of error printouts from TestRIBExporter 59b354c BUG: Replace deprecated functions. f905347 BUG: vtkProbeFilter stored state which did not work for multi-block data. 50e3767 BUG: Initialize grids before adding them to the AMR dataset. 812cacd BUG: Test basic representation after you setup the object 4e531cd ENH: CanReadFile does not fail for newer file version. 70cb8dd ENH: Move test that discovers inconsistent structured grids in an AMR grid. 2331d5e BUG: Fix uninitialized value. Dave DeMarle (3): 3bec6b5 Increment version to VTK 6.3.0 b8d8b4e fix no newline comp warning 45aaa13 expose texture so manta can intercept David C. Lonie (59): a36b64f Enable freetype tests when matplotlib is not found. 71396ea Use a default text property in the labeled contour mapper. 4287d0f Don't use offscreen FBOs when multisampling is requested. 4b4fee9 Disable multisampling in the OSCone test. 3af3151 Enable MPL tests only if the vtk module is enabled. 4d07c85 Allow vtkTextActor* to handle empty inputs. 094258f Account for actor matrix in vtkLabeledContourMapper. 1d9e3ed Add a debug-only yellow dot at the text alignment point. e498377 Ensure that the background is rendered behind the text. f5ee8c1 Improve appearance of small-sized mathtext. 00ec47a Add missing ReleaseGraphicsResources implementation. 40ee682 Move test file (s/cpp/cxx) 4eb5c9e Remove unimplemented private method. 00d87aa Fix transformed contour label placement on OpenGL backend. 59e5478 Fix kerning on rotated fonts. 3ad3670 Update sources in chart symbol glyphs. e628d29 Add missing ReleaseGraphicsResources implementation. 6563825 Release actor resources in vtkLegendScaleActor. 842ab1d Use vtkTextRenderer in the default label render strategy. fa76112 Do not set vtkProperties on vtkTextMappers. 5711379 Fix vtkBiDimensionalRepresentation2D to work with new text mapper. fbcf24a Use string width, not length, to determine longest labels. 25d7412 Remove tcl [info command "rtExMath"] check from test. 8e045af Print image name on test failure. 9175559 Update vtkTextMapper's alignment to match current conventions. 953d3b7 Align to a fixed-height font bbox, rather than a "tight" one. 4f7460a Remove the RenderingFreeTypeOpenGL module. 0ac3ec4 Exercise the new default vtkTextMapper implementation. 1942a72 Update baselines. e0ea6f3 Add new baselines for dash3's continuous build. 06b656e Number baselines consecutively. 73d88b4 Baselines from nightlies. 5a0f0db Fix typo/platform issues in GLUT test. ca58fe7 Call glewInit() from test to setup GL function pointers. 6c386da Move PreserveColorBuffer to vtkRenderer. e51007d Fix glut header in test. b46206e Fix variable type. 44db5b7 Allow an explicit mapping between tprops and scalars for contour labels. 7247da0 Update make_pair call to work with newer MSVC. 061e56d Clean up Rendering/OpenGL2/vtkGenericOpenGLRenWin. e3d0653 Remind MSVC that NULL is a pointer. Fix tclPrintOtherTest. 9e2ac87 Change comment text to use a gentler tone. 755683e Release shaders after rendering is complete. 4dbf657 Define missing typedefs. db8bf29 Fix typo. c8d6551 Add vtkWindow::DetectDPI. 07e728b Add DPI awareness to text rendering. b08abb6 Apply kerning to bounding box calculations. c0a20f3 Don't glyph hidden points in vtkGlyph2D. 2606ebe Mark ticks as dirty when enabling/disabling log scale. 19736b2 Performance cleanup. 48b5509 Account for TileScale in RenderWindowToImage filter. ef328bc Fix vtkAxis scaling when TileScale is set on the renwin. bdf3b4c Defer matplotlib initialization for text rendering. 784ea23 Update Get macro for paraview parsers. fd6c85f Use max(tdx, tdy) to determine string bound scaling... f387250 Add a warning if there is not a scene set on the vtkAxis instance. 75dd5c6 Ensure that input data is synced. 1118440 Make ScalarBarRepresentation orientation set-able. David E DeMarle (1): 388428d Fix depth peeling with antialiasing David Gobbi (21): bdc156e BUG 15358: Remove inappropriate cast from pointer to long. 1c68b08 Add the vtkBoundingBox type to the Python wrappers. 3ecc5e4 Fix Java build, different extensions for file properties. 88693d2 Allow wrappers to properly support "using" methods. df0ebf0 Apply using declarations that hadn't been "used". 4c490b5 Add missing hints for color conversion methods. a8a773b Add virtual data method CopyInformationToPipeline. cf446e3 Fix vtkParseMerge uninitialized variable warnings. d49c2b3 Allow TestEmptyInput to work with python 2.5. 5dae245 Fix a null deref when wrapping "using" declarations. d3404f4 Enable the "using" declaration in vtkTypedArray.h. 8c665f6 Fix nifti sform, qform when qfac=-1. 2a8225b Fix uninitiazed array warning in vtkBSPlineInterpolator. a5423ee Put back some Visual Studio 2003 compatibility code. a4a1d20 Temporary wrapper fix, pointers to vtkSmartPointer. 6419591 Code style fixes. 90dfa37 Allow NIFTI reader and writer to handle planar RGB files. 3c9d962 Close the DICOM file immediately after reading it. 32f5e6d Fix blank slices that appear in some TIFF volumes. f978e5a Replace the O(n^2) median algorithm with an O(n) one. 85f46e7 Fix the median computation in vtkImageMedian3D. Ethan Brodsky (4): abf0892 ENH: Added edge annotations to vtkCornerAnnotation d4ce834 CMP: Eliminated warnings relating to for loop iterator scoping 6e85be4 BUG: Updated test baseline output for edge annotation be1c168 ENH: Modified vtkCornerAnnotation testing to improve code coverage Jean-Christophe Fillion-Robin (3): 3216198 Maintenance: 'main' function in WhatModulesVTK can now be re-used 5a4c7f9 Maintenance: Update WhatModulesVTK to support rendering backend e6e6737 Do not force manifest selection for vtkhdf5 libraries Joachim Pouderoux (9): d7fbc99 Bug #0015217: Fix tet aspect ratio computation. f8b7962 Fix filter crash when input data is not temporal 73b3d40 Add more support of Quadratic Polygon cells. 6c00664 Fix TessellatorFilter so it does not crash with quadratic polygon cells. 54f52ce Enhance and optimize Xdmf2 reader and writer to support static meshes. 5d3c7d6 code cleaning 7bb9fd4 Fix error with java wrapping a5e481d fix header test 90bd6dc Add test and fix reader John Tourtellott (6): dbd6a64 Apply WRAP_EXCLUDE to the vtkGDAL not vtkGDAL.h 649bf86 Add return value to vtkPythonInterpreter::RunSimpleString() 761a643 Add field data to vtkUniformGrid to save GDALDataset NoDataValue 5e1fc1b Fix indentation and restore empty line 5c97e44 Move variable declaration inside loop to limit its scope bf1cd7e Change iterator from postincrement to preincrement Julien Finet (11): ed30420 Kill TDX timer when using no WindowHandle e230dd6 Add TDX_INCLUDE_DIR CMake variable e2c265e Add multitouch support to QVTKWidget and QVTKWidget2 e8eab5f Add support for drawing multiple line segments 4dcaa29 Add vtkPlot::Selectable f7788b1 Add vtkPlotBag::BagVisible b6947ee Fix crash in vtkPlotHistogram2D 67221cf Exposes vtkHighestDensityRegionStatistics::ComputeHDR() to the public API 90f01a5 Fix unsorted range error in vtkChartSelectionHelper::BuildSelection 3de2198 Fix compilation by adding DrawLines() to OpenGL context devices 8cffe7a Fix unsafe mix of bool and int types Julien Jomier (1): a0a1fda BUG: Internal title box should be initialized KWSys Robot (3): ce26403 KWSys 2015-04-16 (1ea01a46) b27579e KWSys 2015-04-19 (4f39791b) d9dea80 KWSys 2015-05-12 (b1d560a0) Karsten Tausche (2): d482da9 fix copied noise extent in vtkImageDataLIC2D 239fc8e fix memory leak in vtkImageDataLIC2D Karsten Tausche (1): 65364aa Remove vtkFreeTypeUtilities.h from vtkScalarBarActorInternal.h Ken Martin (135): f5f9ecb Fix a couple issues cc429a5 Fix a regression and new failing test e6a31ed Fix interactions of depth peeling with the point gaussian mapper. 5157ca8 Fix a case where glyphic was failing on unlit primitives 4693f39 A couple depth peeling fixes 944ee02 A number of transparency related issues fixed d24fcf9 Forgot to comment out debug statement 4ea5a7c Fix for the case when there is nothing to draw 164ea25 Rename class back to the old name for better compatability 5d7ab89 Add in support for below and above range LUTs 5241388 Remove power of two requirement from image slice mapper e96f816 Remove window size change fec981b Add back in LIC for OpenGL2 aaf7c19 Rebased and merged due to conflicts 586cec4 Fix a compiler warning 4b7bd42 Some lic cleanup for ES 2 and ES 3 59b539a A few dashboard fixes as described below 7c341f6 Fix a few issues with ImageDataLIC2D 2e9ec3c A few more VR fixes I missed the first time fb11ced Fix PV text composite with cell data issues e0e1853 Fix issues with composite dataset luts issues 45591d9 Fixes for composite id when selecting on OpenGL2 8403d05 Fix failing test and add new convenience func 366f859 Add a valid image and a slight change to generated normals ec84991 Convert Context2D to use more modern OpenGL 935a4e0 I should learn to test on intel too before committing 8431029 Some fixes for bigmac b3ee0a4 Fix for draw pixels shows up in PV rubberband selection 3983827 Add some debugging code bf094a5 Minor compile fix for GL ES 20 c05ab35 Fix bad destructor c4ba26d redo how cell data is handled and picking a74d8a2 Add support for picking indirection arrays 1f5f80d Managed to get scale and bias for voluem rendering working b8a4007 Make VTK work with OpenGL 3.2 Core 326eed2 Make X windows default to a 3.2 context 780a38c Convert Cocoa to default to OpenGL 3.2 d2335a5 Some more fixes for apple to make VTK more 3.2 core compliant 2dead9d Even more OSX 3.2 changes eee2075 More 3.2 OpenGL fixes da3f65d Minor compiler warning fix 7b2d837 Minor change to pass line width calls through 8eefde5 Added valid images for cases where line width is over 1.0 e98e460 Add missing ReleasGraphicsResources call 0b9e80d Some exit cleanup fixes for debug mesa ece3886 redo how cell data is handled and picking 3d0c728 Add support for picking indirection arrays 600a014 Convert Cocoa to default to OpenGL 3.2 cbd2272 Even more OSX 3.2 changes fb2314a Minor compiler warning fix bbf6cff Add missing releasegraphicsresources bd18cf2 Rebasing from master 1d77180 Fix compile error b063141 Make sure GL_R32F is available on old 2.1 context 633408b Fix for apple 0d2b34b Some fixes for mesa master runs ac7ea9f Fix some compiler warnings 2e33724 Some compile fixes for OpenGLES af81970 Fix a few issues exposed by PV testing 92f01b8 Fix two compiler warnings. be37a5b A couple more picking fixes these related to processor id ebf82b8 Better Tk support for OpenGL2 e1266ff Instanced arrays require OpenGL 3.3 not 3.2 04a1604 Remove old style rendering check 898f9ee Fix for cell normals to use RGBA32F textures 21aafbb Renamed XOpenGLRenderWindowInteractor back to original name ad3e947 Added valid image for Sphere widget 5558b6a Fix for independent components on mesa 93549a2 Pare down the test to be about 40% faster bc47058 Some X window fixes and make two slow tests faster 4546439 Update the alternate image as well 4a79030 Fix apple ifdef 985cead Fix for some systems 529f482 Type fix a713041 Some fixes for checking framebuffer depths 7e2c26d New valid image due to line widths 06a4ef1 Tiny fix for OpenGL ES 3 a08d678 And whoa I committed a png undo that 86327d1 Add method for external codes 9d7da54 Support use of FieldDataTupleId in scalar coloring opengl2 9387545 Add a geometry shader and some cleanup and fixes f22f6f7 Do not use GeometryShaders on ES 792e805 Test out ogl2 as the default for buildbot systems 268c199 More fixes based on test dashboard e5626d9 Fix a couple more issues a268a76 Duh fix bas cmake code d2d4c4b Always use our glew 937fbaa Update to backend logic bdf999d Fix check for multisample support f10eea0 Newer logic so apps can set a default rendering backend 517c6a9 Set default back to OpenGL1 for commit 37f3940 Clenup some OpenGL2 code f153530 More cleanups 844bdfc Rebased to master 1ea2f37 Maybe fix memory leak 773d834 Fix a compiler issue with PV 37c7078 Fix for compile issue on OpenGLES cf2c8b1 Test fix for applie AMD primitiveID bug b0568e3 Better warning message 2bb9901 Add support for 2D 0ab71c6 Another apple fix 3634071 Fix memory leak 0fd7c34 Another compiler fix caaba79 Another fix due to multiple VBOs 591bfac Make the VAO code bind the bufferobject aa413e1 Remove reference to old header file 143ee02 Trying something 52624db Sticking with basic approach bd8e0ac Fix an atom rendering performance regression aed1b0f Remove a leftover test setting d62e074 Some more code cleanups, this time shader related 7e33a8f Remove some unused ivars eef02a7 Add ability for PointGaussianMapper to also just draw points 2bfd5b8 Fix test that was creating an ill defined camera 6148806 Update test to have more debugging d6a2968 Support wide lines in the polydata mappers on 3.2 3d4cf61 Fix prim id issue on mac 6d16798 More cleanup and fixes for 2D this time 3edf1f1 Fixes for failing tests 1ce4ac6 Fix issue on Apple efc7e9f A couple minor fixes that PV exposed d6da179 More minor fixes 60df241 Some fixes for PV ColorOpacityTableEditing ec9015c Make sure PV texture fix hits the other use cases 58d3c34 Fix for clear depth call on es cc85e52 Thick lines only use a GS when the hardware lacks support 7718bd9 Fix compiler issue on gcc bf98e34 Update to fix failing tests aae43de Better handling of thick lines in a couple places 69a266c Fix some recent compile issues 31cbc69 Some compiler fixes for Android 4de813d Fix missing header d117992 Fix issue with compositepolydatamapper2 with scalar colors 687a1ba Add valid image for non AA systems b0239b2 Apply fix to the generic version as well. Lin Ma (6): 7700895 Tested merge 741a3c5 Added vector for memoizing c9ac988 Modified vtkMath::Factorial ab660b6 Recursive stored intermediate results 4ebe46a Fixed bugs 95d52db Changed map to vector Marcus D. Hanwell (4): dd718a3 Added support for writing TIFF volume stacks 610d6fc Fix compiler warning - unsigned int -> int 10d1db4 Removed unused sstream include, add Windows logic ce110d7 Fix bug with bad TIFF tag on char/short format Mathieu Westphal (20): 042d540 Reimplementing AppendData using vtkDataArrayIteratorMacro and std::copy b117a06 Adding surface streamlines d658e82 VTK Style 80693cb Adding Angular Periodic Filter and Angular Periodic Array to VTK. b975b6d Correcting multiple bugs with periodic data array 35495b5 AngularPeriodicDataArray : Use of sin instead of sinf c5f4437 Correcting bugs in vtkCell implementation 2bfd773 Correcting pcoords in vtkTriangle a7f36eb Add a degenerate Triangle test in IntersectWithLine d4765f8 Correcting degenerate triangle 24a1090 Missing initialization of a member 48752b4 Fixing coincident point in stream tracer output 0189719 Correcting a warning in vtkLargeInteger 998fedf Adding another image for test 41e2929 Checking for Null vtkPoints in Angular Periodic Filter 11929ae Fixing 14897 mantis bug, adding VTKTargets.cmake in install 93e821f fixup python testing 61e11ad Deprecating FrontBuffer member and double passing tests if necesssary e180b45 First bug fix fro periodic filter a94c1c8 Fixing parallel periodic filter MetaIO developers (1): 9db8026 MetaIO 2015-03-18 (ebdd30dd) Nathan Fabian (6): b08448f Fixed possible nulls when FieldData are string arrays. dbf9f28 Detect when we're writing sets and don't write them as blocks. 48f899d NodeSets finally write out. 0aa18f1 Side sets now write out correctly. 4df652b Replaced the missing const b84020d Replaces iterator pointers with SmartPointers to avoid possible leaks. Robert Maynard (7): 7493f03 FindTBB: Updated implementation to version proposed for CMake. 7371346 Get SynchronizedTemplates3D to work with more than 4GB. 40004b2 Get ThreadedSynchronizedTemplates3D to work with more than 4GB. 93a6062 CONTRIBUTING: Add an overview of the development process e43e3a1 You can't close a null tiff pointer. 7ae792f Mark the entire Accelerators Piston module as legacy as of 6.3 9486611 Mark the entire Accelerators Dax module as legacy as of 6.3 Rolf Eike Beer (2): 985e779 ExternalData: Replace MATCHES with STREQUAL where possible a035ef4 ExternalData: Clean up duplicate regex matches with CMAKE_MATCH_ Sankhesh Jhaveri (69): 4183e79 Clipping test with oblique clipping planes 8b074c8 Explicitly set sample distance for timing test 27b1629 Make sure most voxels are rendered for timing test 7beb6cc Make the AMR Volume mapper available for GL2 backend 6497141 Added test with shading 929c87e Fix volume cropping issue 08b9c9e Circumvent crash in volume mapper when context changes c6847d0 Added test for change related to releasing resources 84d9a92 Added ivar for ContextChanged 80dfc56 Laxed restrictions on input data required by OpenGL2 volume mapper c518197 GPU volume mapper test for two independent components 222c7ca Added interaction and baseline to the two independent components test 95d8f88 Fix error in OpenGL2 volume mapper for multiple components 6b846f4 Test for GPU volume mapper with three independent component scalar data 33ab12e Test for two dependent component scalar data 28802b0 Modify test for three components 032bebe Fix two dependent components case for volume mapper 9cbcbb4 Reset scale and bias after loading volume 3b83fb4 Take per component range for setting default transfer functions 8ef7ac7 Use the appropriate components for transfer functions 10026fb Fix crash due to wrong index fetching of tables 8f2af4d Use the right component for opacity functions 48ae50a Added baselines for new tests 364ca40 New baseline for the independent components MinIP test bb59cae Fix lights issue in external render environments e7b5c09 Set spot parameters on the newly created lights c5c0794 Changed GLUT test to remove VTK lights 1fd0e34 Added ability to automatically resize external window 67bfb78 Account for window position when drawing in external context b2106a7 Fix lighting for external rendering environments ceca59d Update the GLUT test baseline 82c7c07 Added Generic OpenGL RenderWindow to OpenGL2 pipeline 58e3414 Enable OpenGL2 support for vtkRenderingExternal module 5c56449 Provide extension manager support to external rendering module 879efa4 Removed redundant tests and fixed crop test 2c6faab Streamlined testing without VolumeOpenGLNew tests e931627 Remove trailing references to VolumeOpenGLNew e030c3b Remove module VolumeOpenGLNew f05c60a Remove context caching from the volume mapper 6ad386c Remove unused variable warning dcd2ee8 Add API for auto-adjust sample distances to smart volume mapper 2a76dc5 Add convenience API to smart volume mapper 841ab6b Fix data trunctation issues with 32 bit int types 807e61e Enforcing GPU breaks old mapper compatibility for test 792b663 Fix AMR volume mapper for recent smartvolume mapper changes 381ebae Remove debug print messages 0eb9b1e PrintSelf newly added variable d9d8f10 Add new external light object ee190de Ability to modify externally created lights in the external renderer 95945ac Modify existing lights each render call 20251e0 Documentation changes 1987cce Change default for vtkExternalLight eb190e6 Performance optimization in external renderer d40aecd Fix external window stereo mode position for OpenGL2 backend aff7eb3 Fix near plane offset clipping when camera inside bb656ed New test for camera inside volume calculations 201f587 Added camera inside test for small spacing cd8ffef Update comment to reflect documentation 3b22e28 Add resolution specification capability to circle glyphs a93ff1d Add test for glyph 2D circle resolution 59c9de7 Fix test failure due to vtkMath::Random 4a8529b Fix constant array size issue c3921c5 Fix crash due to un-set point ID 83bdd85 Fix compile error when compiling vtkRenderingExternal b34cba0 Added test for GPU volume mapper jagged edges issue b4c9fc9 Restore concept of InteractiveUpdateRate for vtkSmartVolumeMapper 1013a56 Compute initial sample distance based on dataset spacing 40ec94e Interactively adjust sample distance for vtkSmartVolumeMapper 9b2883a Improve documentation of new variable in vtkSmartVolumeMapper Scott Wittenburg (8): ca58cc9 Support pvweb color editor widget and use of local storage by apps. 74ca669 Add a completely standalone tool for generating color swatch images. f8ee75a Support retrieving geometry for all timesteps in paraviewweb. a786577 Change framerate stats to show two decimals places. Fix stat table. 81a6eb0 Update autobahn client/server as well as vtkweb connect for longpoll. 6648549 Allow clients to know when a render occurred that was not stale. 566dc51 Fix how we import our argparse fallback implementation. 914dc33 Add synchronous methods to Base64-encode image data as png or jpg. Sean McBride (88): b54bce1 Unified mixed unsigned char/int usage to bool 3e546c7 Unconfused cppcheck by removing unneeded null check a310907 Moved dereference to after null check 4a03ebd Fixed typo: - should be -> 3a95956 Fixed || that should be && ab65dee Fixed contradictory ?if? statements fd6923e Fix division by zero cppcheck warnings af1c03d Fix clang warnings about implicit float->bool 364f7a5 Add asserts to silence clang analyzer warning bf7dbc5 Return upon error, otherwise invalid file reference is used 9557459 Fixed memory leaks found by cppcheck ae942ec Fix incorrectStringCompare cppcheck warning 00834ec Fixed cppcheck signConversion warning 430ca63 Made various float to bool conversions explicit da2c429 Removed unneeded casting c0f818b Fixed stack allocation to be properly aligned b85b5f6 Replace size() with empty() 2f2c9e3 Copy-paste error, duplicate ORing 13ee5b9 Add parens for less ambiguity, fix cppcheck warning dd72b67 Refactor & simplify to avoid cppcheck false positive 5da8067 Reverse order of AND statements 82d3857 Removed simple dead stores/statements found by cppcheck 604952c Refactor old school alignment test to use offsetof() 4753261 Remove the addition of a few inappropriate vtkErrorMacro 18f4050 Fix more include guards to not start with __vtk a283cf6 Removed dead code found by cppcheck 3cf511d Removed unneeded c_str() usage b1d2871 Silence clang analyzer warning c10d56b Fixed minor format string mismatch f1f33bc Fixed possible array overrun found by cppcheck c107164 Move index ?i? check after usage dedac30 Removed _probably_ dead code 87ecf6f Reformulate assert to pacify cppcheck bcba6da Fix null deref, likely due to && vs || typo e0c279f Fixed cppcheck warning about all-const params to strncmp 9cee046 Check ResizeAndExtend error result and bail 43cb029 Fixed division by zero found by cppcheck d8b8c82 Merged private function into destructor bfa040a Removed code dead since 2001. 0793af7 Removed code dead since 2003. 11a25a0 Removed code dead since 2001. 8c9bd60 Removed code dead since 2010. 52178c8 Removed code dead since 2006. 4b6fb46 Added static to many private globals 0fdb9d2 Fixed -Wformat-pedantic warnings 0f0e9a7 Removed dead code 7a30b8d Fixed all -Wswitch-enum warnings 7e18c39 Revert warning fix that caused another warning 5700d2e Fixed mismatch between ivars and get/set macros 418c62c Changed many int to vtkIdType 1a191c9 Fixed implicit float/double to bool conversion a16e53d Added explicit casts to fix Wconversion warnings acf0c22 Fixed memory leak in Cocoa code (regression) acc044c Fixed dead code warning on OS X 6770f4c Fixed unused parameter warning 4b38ce2 Fixed warning caused by warning fixes from other branch b1899a4 Fixed compiler error with div() introduced with Wconversion fixes d9e2b61 Changed vtkWriter::Write()'s return value ea9ebe8 Fixed illegal left shift of negative number 5b5c1f0 Fixed some warnings from PGI compiler dashboard 932c021 Fixed blunder in merge request #51 aca10d2 Added missing #include, causing some bots to not build 1383d57 Fixed -Wextra-semi warnings within VTK macros 2031f57 Fixed -Wextra-semi warnings in ThirdParty/alglib 0894f9a Fixed -Wextra-semi warnings in ThirdParty/ftgl 0fed50d Fixed -Wextra-semi warnings in ThirdParty/utf8 3cc4d9f Fix -Wimplicit-fallthrough warnings; introduce VTK_FALLTHROUGH d9ec645 Modernized Cocoa code to use NSTrackingArea 5678f1c Removed many unneeded null checks before delete 50d22d0 Changed placeholder value from 0.0 to 1.0, fixing undefined behaviour 6bfea2b Disambiguated use of term ?kilobyte? 1e8db01 Fix possible null deref by bailing early a7b7b30 Workaround cppcheck warning by refactoring loop 8525d6f Removed dead store found by cppcheck e385f7d Fix warning about identical comparisons f63ff5b Avoid cppcheck division by 0 warning 47ff51d Fixed null deref found by cppcheck f65f048 Fixed division by zero 4a537d8 Fixed STLReader regression vs VTK 5.10.1 9843c53 Fixed mismatch array new/delete found by clang -Wmismatched-new-delete ac738c6 Removed branches for _MSC_VER <= 1400. 9285a6b Removed branches for gcc 4.0 and lower. 5da4b99 Added #error for known old unsupported compilers c0f64bb Restored support for Apple gcc 4.2 a8dc81f Hopefully suppress ?used uninitialized? warnings 51f1fbe Replace VTKGL2 define with VTK_OPENGL2 668c687 Fixed ?no newline at end of file? warnings 2fc88bb Added VTK_FALLTHROUGH in case without break Sebastien Jourdain (1): 4551c40 Allow GetTuple6 to be preperly Wrapped Shawn Waldon (7): 8bb1cd3 Handle datatypes other than single precision float c8c13dd Add overloads to parallel communication methods 2d448c8 Update the documentation on data array subclasses 8e70864 Make java wrapping give files to javac via a response file f14f271 Add higher timeouts for some long running tests ba6f952 Force tests to run in serial db85b40 Remove "have tcoords" print statement Steven Hahn (1): 655c4cf Change while loop condition for osx. Sujin Philip (19): 95dcf8c Fix for windows warning suppressions not working e83da62 Fix SMP compile warning in VC++ a7d288f vtkThreadedSynchronizedTemplatesCutter3D e5ee5e7 Remove double underscores from header guard. e731f7d Add support tbb in local build dirs, and from composer installs. 78a5fff Improvements to vtkAtomicInt 09c3da0 Fixes for vtkAtomicInt issues from dashboard tests 9b585ed Improve OS X support in FindTBB e6356d8 Fix errors detected on Windows dashboards f12026b Fix usage of CriticalSectionGuard c342a01 Change vtkAtomicInt to vtkAtomic 8b809d5 Re-enable use of long for 64-bit vtkIdType fda6a31 Added Improved FindOpenMP module 4d26636 OpenMP backend for SMP 82eec30 Add vtkAtomic support headers to list of sources a0b05b2 Fix testing of MTime in TestAtomic e2c63d3 Fix cmake error when ${POLICY_VAR} is empty 2a505d9 Fix "#pragma warning" warning in gcc f51d10d Intel compiler 11.1 template typedef issue Utkarsh Ayachit (36): 9892e7f Added fake-stereo mode. 36385b4 Modified Matrix when it changes. 26d178b Make PushImageToScreen() virtual. f814879 Add test to demonstrate TIFF reader issue. 0460b1e Support random access in compressed tiff files. 02c49fb Remove invalid error message. 1093ae9 Avoid modifying vtkAxis unless things changed. 6c877c2 Adding area plot (vtkPlotArea). bdb5b5b Fix leaks in vtkExtractArraysOverTime. 8e079d3 Add alternative baseline for dashlin1. 3b8db8d Add missing 'close' to vtkPythonStdStreamCaptureHelper. 33ba83a BUG #14721: Add support for quadratic pyramid for Exodus reader. ea6f018 Revert "FIX: We don't select 2D annotations." d4b9145 Overcome wrapping issue with client-server wrappings in ParaView. 5c7bb1b Fixed warnings. 5c663b7 Extending API to get information about picked location. 06d553f BUG #15438: Handle NaN when computing array range. bf7967d BUG #0015512: Added ability to hide plots from the legend. 27984c3 BUG #15321: Fix mode_shape array. e66cef8 Remove vtkExodusIIReader::UpdateTimeInformation(). 636fc93 Cleanup initialization of TimeStepRange/ModeShapeRange. ea532fa Expose mode-shape-range meta-data to downstream filters. e4c6f5c BUG #15155: Fix issues with temporal interpolator. e449dfe Use AllGather instead of custom implementation of the same. 1be51c3 BUG #15445: Handle empty input datasets in vtkDistributedDataFilter. 23dff2b BUG #14897: Fix periodic boundary issues with vtkNetCDFCAMReader. 6ccc95c Avoid segfaults for multiblocks of vtkTable. 0e902ee Fixed invalid #ifs in vtkByteSwap. d3dee7d Make vtkMultiBlockPLOT3DReader factory overridable. bc18ac7 Add vtkMPIMultiBlockPLOT3DReader -- MPI-IO enabled reader for Plot3D. 695b481 Adding a basic test to test vtkMPIMultiBlockPLOT3DReader. 44c7f0b Cleaning python testing macros. 0786909 Win64 fixes for vtkMultiBlockPLOT3DReader. d955537 Fix typo in call to superclass method. 557ec61 Error checking: check status of collective call. 1c78797 Fix uninitialized memory reported by valgrind. Vincent Chen (4): 289ba8d Fixing outptr traversal bug in vtkImageResize 7af7f96 Modify Stencil Iterator to work under block mode. 262ac56 vtkVolumeRayCastSpaceLeapingImageFilter, 096c0eb vtkImageBlend row traversal bug Vittorio Parrella (2): 2111954 Fixed crash in PokeMatrix(NULL) if not called before with valid data. 6d4f792 Refactoring of Set/Get filename to model reader classes. Will Schroeder (8): 7542037 Fixed HandleDirection issues. 7f36d44 Performance improvements via templating and SMP 274efff Cleaned up dashboard warnings 2be4261 New Guassian splatter class, added multithreading a623741 Using typename instead of class for templates a6e1420 Work around brain dead compiler d0ee979 Another method made public to work around compiler 19b42e3 Another method made public to work around compiler(2) peter karasev (19): b28b038 add obj importer with test. fetches textured mtl files for test. f88bcf5 re-add test file that was quashed unintentionally 0ee04ed cleanup style issues per comments in gitlab ca1b041 update cmake for external data usage 9328465 update style and remove console output 8547ec8 more robust handling of path to texture files b740219 update test robustness, use freely distributable model files 3a92b7a exclude header so that vtkSmartPointer can be used ... 8973055 update md5 files in repo 3f6e3f0 remove previous md5 refs e782156 touch data files to get dashboard greener ef27b0b remove previous files 010c8b6 dont show warning about comments in MTL file unless debug mode on c71a789 add support for mixing usemtl and vertex definitions, add test for this. 966ccb3 touch files; previous commit encountered gitlab error 3ad923a make a pass at cleaning up warnings on cdash 71a39d3 disable warning in impl file. bc011db add test files 55e2914 fix importing to work for no mtl file + no warnings for empty texture image From david.thompson at kitware.com Sun Jul 26 20:05:44 2015 From: david.thompson at kitware.com (David Thompson) Date: Sun, 26 Jul 2015 20:05:44 -0400 Subject: [vtk-developers] Triangular patch interpolation Message-ID: <2A7813C2-E2FD-42B2-A9B3-A7AF6B3D9E6B@kitware.com> Hi Lin, How is triangular/tetrahedral patch interpolation going? They will be a basic building block of the contouring and cutting algorithms. By identifying points on edges, edges on surfaces, and surfaces in volumes that take on a single value, a single patch can be decomposed into sections that are inside, outside, or on an isosurface. Not all of these pieces can be expressed as brick patches, but they can be expressed as simplicial patches. David From majcjc at gmail.com Mon Jul 27 01:26:31 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 27 Jul 2015 01:26:31 -0400 Subject: [vtk-developers] Triangular patch interpolation In-Reply-To: <2A7813C2-E2FD-42B2-A9B3-A7AF6B3D9E6B@kitware.com> References: <2A7813C2-E2FD-42B2-A9B3-A7AF6B3D9E6B@kitware.com> Message-ID: Hi Dr. Thompson, I have added new method vtkPatachInterpolation::InterpolateOnSimplicialPatch() and pushed to gitlab. I'm now working on the point inversion part. Best, Lin On Sun, Jul 26, 2015 at 8:05 PM, David Thompson wrote: > Hi Lin, > > How is triangular/tetrahedral patch interpolation going? They will be a > basic building block of the contouring and cutting algorithms. By > identifying points on edges, edges on surfaces, and surfaces in volumes > that take on a single value, a single patch can be decomposed into sections > that are inside, outside, or on an isosurface. Not all of these pieces can > be expressed as brick patches, but they can be expressed as simplicial > patches. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Mon Jul 27 08:29:58 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 27 Jul 2015 08:29:58 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> References: <20150724190754.GA29467@megas.kitware.com> <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> Message-ID: On Sun, Jul 26, 2015 at 11:32 AM, Leonid Dulman wrote: > Hi to All > I built VTK 6.3.0 in win32 with Qt 5.5.0,tcl/tk 8.6.3 and Python 2.7 and > test examples. All works > But I don't know how to built vtkRenderingFreeTypeOpenGL-6.3.lib > Thank you. Leonid > The RenderingFreeTypeOpenGL module no longer exists -- it only implemented a single class (vtkFreeTypeOpenGLTextMapper), which has been reimplemented in vtkTextMapper to reuse the same rendering backend as the other text objects. Since the old implementation will not be compatible with the OpenGL2 backend, it has been removed. Best, Dave > *From:* Ben Boeckel > *To:* vtk-developers at vtk.org; vtkusers at vtk.org > *Cc:* Kitware Corporate Communications > *Sent:* Friday, July 24, 2015 10:07 PM > *Subject:* [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready > > The VTK developement team is happy to announce that VTK 6.3 has entered > the release candidate stage! > > You can find the source, data, and new vtkpython binary packages here: > > http://www.vtk.org/VTK/resources/software.html#releasecandidate > > Please try this version of VTK and report any issues to the list or the > bug tracker so that we can try to address them before VTK 6.3.0 final. > > The official release notes will be available when VTK final is released > in the next few weeks. In the meantime here is a preview: > > - new OpenMP backend for vtkSMPTools; > - new MPI-IO backend for PLOT3D reader; > - new vtkPlotArea for rendering area (or range) plots; > - multithreaded Gaussian splatter class; > - multithreading support in the vtkSampleFunction; > - compiler uplifts: gcc-4.1 and Visual Studio 2008 or newer are > required; > - the Piston and Dax accelerator modules are deprecated; > - writing side and node sets in Exodus files; > - skip NaN values in vtkDataArray::GetRange(); > - reading compressed TIFF files with sub-extents; > - support for OpenGL 3.2 in the (still experimental, but much less so) > OpenGL2 backend; > - text rendering now respects the DPI of the vtkWindow; > - vtkAxis respects the TileScale setting of vtkWindow; > > And many bug fixes across the codebase. > > We hope you enjoy this release of VTK! As always, contact Kitware and > the mailing lists for assistance. > > Thanks, > > --Ben > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From EVENDUAN at outlook.com Mon Jul 27 08:55:43 2015 From: EVENDUAN at outlook.com (=?gb2312?B?ts671Lrq?=) Date: Mon, 27 Jul 2015 20:55:43 +0800 Subject: [vtk-developers] Problem of how to get the dimension of a picture Message-ID: My vtk version is 6.2 and I want to get the dimensions of a picture. Following is a part of my code: vtkSmartPointer reader = vtkSmartPointer::New(); reader->SetFileName( argv[1]); reader->Update(); int originalDims[3]; reader->GetOutput()->GetDimensions(originalDims); The last code: ?reader->GetOutput()->GetDimensions(originalDims)? is wrong. Where is the problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Mon Jul 27 09:29:23 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Mon, 27 Jul 2015 15:29:23 +0200 Subject: [vtk-developers] Problem of how to get the dimension of a picture In-Reply-To: References: Message-ID: What do you mean by "is wrong"? Are the returned values in the orignalDims array incorrect or do you have a compilation error? If the returned dimensions are incorrect, please provide an image example, what are expected dimensions and what are the one returned by GetDimensions? *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-27 14:55 GMT+02:00 ??? : > My vtk version is 6.2 and I want to get the dimensions of a picture. > Following is a part of my code: > > > > vtkSmartPointer reader = > > vtkSmartPointer::New(); > > reader->SetFileName( argv[1]); > > reader->Update(); > > int originalDims[3]; > > reader->GetOutput()->GetDimensions(originalDims); > > The last code: ?reader->GetOutput()->GetDimensions(originalDims)? is > wrong. Where is the problem? > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Jul 27 14:31:13 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 27 Jul 2015 14:31:13 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: References: <20150724190754.GA29467@megas.kitware.com> <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150727183113.249732046@mail.rogue-research.com> On Mon, 27 Jul 2015 08:29:58 -0400, David Lonie said: >> Hi to All >> I built VTK 6.3.0 in win32 with Qt 5.5.0,tcl/tk 8.6.3 and Python 2.7 and >> test examples. All works >> But I don't know how to built vtkRenderingFreeTypeOpenGL-6.3.lib >> Thank you. Leonid >> > >The RenderingFreeTypeOpenGL module no longer exists -- it only implemented >a single class (vtkFreeTypeOpenGLTextMapper), which has been reimplemented >in vtkTextMapper to reuse the same rendering backend as the other text >objects. Since the old implementation will not be compatible with the >OpenGL2 backend, it has been removed. This surprised me when I rebuilt a few weeks ago too. It might become a FAQ. I think it should be mentioned in the release notes, as quite a few of us use CMake to build VTK itself, but don't use it to build whatever we're linking VTK into. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.lonie at kitware.com Mon Jul 27 14:34:37 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 27 Jul 2015 14:34:37 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: <20150727183113.249732046@mail.rogue-research.com> References: <20150724190754.GA29467@megas.kitware.com> <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> <20150727183113.249732046@mail.rogue-research.com> Message-ID: On Mon, Jul 27, 2015 at 2:31 PM, Sean McBride wrote: > On Mon, 27 Jul 2015 08:29:58 -0400, David Lonie said: > > >> Hi to All > >> I built VTK 6.3.0 in win32 with Qt 5.5.0,tcl/tk 8.6.3 and Python 2.7 and > >> test examples. All works > >> But I don't know how to built vtkRenderingFreeTypeOpenGL-6.3.lib > >> Thank you. Leonid > >> > > > >The RenderingFreeTypeOpenGL module no longer exists -- it only implemented > >a single class (vtkFreeTypeOpenGLTextMapper), which has been reimplemented > >in vtkTextMapper to reuse the same rendering backend as the other text > >objects. Since the old implementation will not be compatible with the > >OpenGL2 backend, it has been removed. > > This surprised me when I rebuilt a few weeks ago too. It might become a > FAQ. I think it should be mentioned in the release notes Agreed! This is on me, I missed that point when I was summarizing my changes for the release notes. Ben/DaveD, can we add this to the notes? - Removed the deprecated RenderingFreeTypeOpenGL module. The functionality of this module has been replaced by the vtkTextRenderer and vtkTextMapper classes in the RenderingCore module. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Jul 27 14:48:36 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 27 Jul 2015 14:48:36 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: References: <20150724190754.GA29467@megas.kitware.com> <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> <20150727183113.249732046@mail.rogue-research.com> Message-ID: Yep thanks. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Jul 27, 2015 at 2:34 PM, David Lonie wrote: > On Mon, Jul 27, 2015 at 2:31 PM, Sean McBride > wrote: > >> On Mon, 27 Jul 2015 08:29:58 -0400, David Lonie said: >> >> >> Hi to All >> >> I built VTK 6.3.0 in win32 with Qt 5.5.0,tcl/tk 8.6.3 and Python 2.7 >> and >> >> test examples. All works >> >> But I don't know how to built vtkRenderingFreeTypeOpenGL-6.3.lib >> >> Thank you. Leonid >> >> >> > >> >The RenderingFreeTypeOpenGL module no longer exists -- it only >> implemented >> >a single class (vtkFreeTypeOpenGLTextMapper), which has been >> reimplemented >> >in vtkTextMapper to reuse the same rendering backend as the other text >> >objects. Since the old implementation will not be compatible with the >> >OpenGL2 backend, it has been removed. >> >> This surprised me when I rebuilt a few weeks ago too. It might become a >> FAQ. I think it should be mentioned in the release notes > > > Agreed! This is on me, I missed that point when I was summarizing my > changes for the release notes. > > Ben/DaveD, can we add this to the notes? > > - Removed the deprecated RenderingFreeTypeOpenGL module. The functionality > of this module has been replaced by the vtkTextRenderer and vtkTextMapper > classes in the RenderingCore module. > > Dave > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Jul 27 14:51:18 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 27 Jul 2015 14:51:18 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: References: <20150724190754.GA29467@megas.kitware.com> <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> <20150727183113.249732046@mail.rogue-research.com> Message-ID: <20150727185118.1463852919@mail.rogue-research.com> On Mon, 27 Jul 2015 14:34:37 -0400, David Lonie said: >Agreed! This is on me, I missed that point when I was summarizing my >changes for the release notes. > >Ben/DaveD, can we add this to the notes? > >- Removed the deprecated RenderingFreeTypeOpenGL module. The functionality >of this module has been replaced by the vtkTextRenderer and vtkTextMapper >classes in the RenderingCore module. Am I right that this: also needs updating? "vtkRenderingFreeType" should be removed, yes? Also might be good to say that if using the experimental OGL2 stuff, that one must use "vtkRenderingOpenGL2". Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.lonie at kitware.com Mon Jul 27 14:51:27 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 27 Jul 2015 14:51:27 -0400 Subject: [vtk-developers] FYI: TestDataArrayAPI broken on master Message-ID: This new test is broken, as one of the tested functions had a change in behavior between the time I wrote it and when it got merged. There is a fix up here: https://gitlab.kitware.com/vtk/vtk/merge_requests/459 Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Mon Jul 27 14:54:28 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 27 Jul 2015 14:54:28 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: <20150727185118.1463852919@mail.rogue-research.com> References: <20150724190754.GA29467@megas.kitware.com> <2073305583.2810128.1437924749471.JavaMail.yahoo@mail.yahoo.com> <20150727183113.249732046@mail.rogue-research.com> <20150727185118.1463852919@mail.rogue-research.com> Message-ID: On Mon, Jul 27, 2015 at 2:51 PM, Sean McBride wrote: > On Mon, 27 Jul 2015 14:34:37 -0400, David Lonie said: > > >Agreed! This is on me, I missed that point when I was summarizing my > >changes for the release notes. > > > >Ben/DaveD, can we add this to the notes? > > > >- Removed the deprecated RenderingFreeTypeOpenGL module. The functionality > >of this module has been replaced by the vtkTextRenderer and vtkTextMapper > >classes in the RenderingCore module. > > Am I right that this: > > > > also needs updating? "vtkRenderingFreeType" should be removed, yes? Also > might be good to say that if using the experimental OGL2 stuff, that one > must use "vtkRenderingOpenGL2". vtkRenderingFreeType should not be removed -- it is a different module from the one that got taken out (vtkRenderingFreeTypeOpenGL). However, the removed module is in the list, too. It is still needed for earlier 6.x releases. I'll let someone else make that call whether we remove it from that page or not, since it could go either way as I see it. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Jul 27 17:25:55 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 27 Jul 2015 15:25:55 -0600 Subject: [vtk-developers] C++ unit tests Message-ID: Hi All, I've always enjoyed using the python unit testing framework in "vtk.test". It's been brought up on the list before, but it would be nice if VTK included a unit test framework for C++, as well. For my work projects, I've been using a unit test header that I wrote a year and a half ago: https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h It's a single header file that provides a collection of macros for building unit tests, it's meant to be innocuous and easy to use. It could go into VTK as Testing/Core/vtkUnitTest.h and people could use it at their leisure. Any thoughts? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Jul 28 08:53:47 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 28 Jul 2015 08:53:47 -0400 Subject: [vtk-developers] CFP: SC '15 Scientific Visualization Showcase In-Reply-To: References: Message-ID: Update! The deadline for submission of your best scientific visualizations to the Supercomputing 2015 Showcase has been pushed back to August 7. hxxp://sc15.supercomputing.org/program/scientific-visualization-showcase Best, -berk On Tue, May 26, 2015 at 8:18 AM, Berk Geveci wrote: > Hi folks, > > The Call for Participation for the SC '15 Scientific Visualization > Showcase is out. This is a great opportunity for the community to highlight > the wonderful visualization work going on. Please consider submitting an > entry (or more). > > http://sc15.supercomputing.org/program/scientific-visualization-showcase > > SC15?s Visualization and Data Analytics Showcase Program provides a forum > for the year's most instrumental movies in HPC. Six finalists will compete > for the Best Visualization Award, and each finalist will present his or her > movie during a dedicated session at SC15 in a 15-minute presentation. > Movies are judged based on how their movie illuminates science, by the > quality of the movie, and for innovations in the process used for creating > the movie. > > Best, > -berk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jul 28 10:01:27 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 28 Jul 2015 10:01:27 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: A single header file unit testing solution sounds like a good thing. ... but ... seems like we could also take advantage of a well-established generally used unit testing framework (like gtest or CppUnit) just as easily, and not clutter the VTK source with yet-another-custom-thing-to-learn-about-VTKs-infrastructure. Would it be just as easy to add unit testing using an external unit testing package? Or are there things about that scenario that are overly complicated that having our own makes simpler...? David C. On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi wrote: > Hi All, > > I've always enjoyed using the python unit testing framework in "vtk.test". > It's been brought up on the list before, but it would be nice if VTK > included a unit test framework for C++, as well. > > For my work projects, I've been using a unit test header that I wrote a year > and a half ago: > https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > > It's a single header file that provides a collection of macros for building > unit tests, it's meant to be innocuous and easy to use. It could go into > VTK as Testing/Core/vtkUnitTest.h and people could use it at their leisure. > > Any thoughts? > > - David > > > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From david.thompson at kitware.com Tue Jul 28 10:27:49 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 28 Jul 2015 10:27:49 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: Another project I work on has been using Bandit[1] to good effect. David [1]:http://banditcpp.org/reference.html On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers wrote: > A single header file unit testing solution sounds like a good thing. > > ... but ... seems like we could also take advantage of a > well-established generally used unit testing framework (like gtest or > CppUnit) just as easily, and not clutter the VTK source with > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > > Would it be just as easy to add unit testing using an external unit > testing package? Or are there things about that scenario that are > overly complicated that having our own makes simpler...? > > > David C. > > > > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi wrote: >> Hi All, >> >> I've always enjoyed using the python unit testing framework in "vtk.test". >> It's been brought up on the list before, but it would be nice if VTK >> included a unit test framework for C++, as well. >> >> For my work projects, I've been using a unit test header that I wrote a year >> and a half ago: >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >> It's a single header file that provides a collection of macros for building >> unit tests, it's meant to be innocuous and easy to use. It could go into >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their leisure. >> >> Any thoughts? >> >> - David >> >> >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From david.gobbi at gmail.com Tue Jul 28 10:43:00 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 28 Jul 2015 08:43:00 -0600 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: Hi David (and David), The only advantage of my unit test header is that it is a single header (a short one, too) with zero dependencies. So it's easy to add to VTK and it's trivial to maintain. If either of you has a better solution, then go ahead and make a merge request. I'll review it for you ;) - David On Tue, Jul 28, 2015 at 8:27 AM, David Thompson wrote: > Another project I work on has been using Bandit[1] to good effect. > > David > > [1]:http://banditcpp.org/reference.html > > On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers < > vtk-developers at vtk.org> wrote: > > > A single header file unit testing solution sounds like a good thing. > > > > ... but ... seems like we could also take advantage of a > > well-established generally used unit testing framework (like gtest or > > CppUnit) just as easily, and not clutter the VTK source with > > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > > > > Would it be just as easy to add unit testing using an external unit > > testing package? Or are there things about that scenario that are > > overly complicated that having our own makes simpler...? > > > > > > David C. > > > > > > > > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi > wrote: > >> Hi All, > >> > >> I've always enjoyed using the python unit testing framework in > "vtk.test". > >> It's been brought up on the list before, but it would be nice if VTK > >> included a unit test framework for C++, as well. > >> > >> For my work projects, I've been using a unit test header that I wrote a > year > >> and a half ago: > >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > >> > >> It's a single header file that provides a collection of macros for > building > >> unit tests, it's meant to be innocuous and easy to use. It could go > into > >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their > leisure. > >> > >> Any thoughts? > >> > >> - David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Jul 28 11:19:16 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 28 Jul 2015 11:19:16 -0400 Subject: [vtk-developers] Mailing list for buildbot status? Message-ID: Folks, I wonder if we need a spearate mailing list for providing information about dashboard machine status. Currently, information about issues with dashboard machines is not shared with the development teams. We cannot simply use the vtk developers list since these machines are often shared with other projects, like ParaView, VTM-M etc. Any thoughts? Utkarsh From DLRdave at aol.com Tue Jul 28 12:29:40 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 28 Jul 2015 12:29:40 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: Have you tested it on all the typical target VTK platforms already, or is the VTK dashboard going to light up the first time it builds on those ...? Presumably you use it on multiple platforms, but probably not quite all of the ones VTK dashboards get tested on. On Tue, Jul 28, 2015 at 10:43 AM, David Gobbi wrote: > Hi David (and David), > > The only advantage of my unit test header is that it is a single header > (a short one, too) with zero dependencies. So it's easy to add to VTK > and it's trivial to maintain. > > If either of you has a better solution, then go ahead and make a merge > request. I'll review it for you ;) > > - David > > > On Tue, Jul 28, 2015 at 8:27 AM, David Thompson > wrote: >> >> Another project I work on has been using Bandit[1] to good effect. >> >> David >> >> [1]:http://banditcpp.org/reference.html >> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers >> wrote: >> >> > A single header file unit testing solution sounds like a good thing. >> > >> > ... but ... seems like we could also take advantage of a >> > well-established generally used unit testing framework (like gtest or >> > CppUnit) just as easily, and not clutter the VTK source with >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >> > >> > Would it be just as easy to add unit testing using an external unit >> > testing package? Or are there things about that scenario that are >> > overly complicated that having our own makes simpler...? >> > >> > >> > David C. >> > >> > >> > >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi >> > wrote: >> >> Hi All, >> >> >> >> I've always enjoyed using the python unit testing framework in >> >> "vtk.test". >> >> It's been brought up on the list before, but it would be nice if VTK >> >> included a unit test framework for C++, as well. >> >> >> >> For my work projects, I've been using a unit test header that I wrote a >> >> year >> >> and a half ago: >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >> >> >> It's a single header file that provides a collection of macros for >> >> building >> >> unit tests, it's meant to be innocuous and easy to use. It could go >> >> into >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their >> >> leisure. >> >> >> >> Any thoughts? >> >> >> >> - David >> > From david.gobbi at gmail.com Tue Jul 28 12:46:42 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 28 Jul 2015 10:46:42 -0600 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: On Tue, Jul 28, 2015 at 10:29 AM, David Cole wrote: > Have you tested it on all the typical target VTK platforms already, or > is the VTK dashboard going to light up the first time it builds on > those ...? > You're being silly. The dashboards run on merge requests specifically to catch platform-specific issues so that they can be fixed prior to merge. This isn't the old days of VTK where we all pushed directly to master. - David > > Presumably you use it on multiple platforms, but probably not quite > all of the ones VTK dashboards get tested on. > > > On Tue, Jul 28, 2015 at 10:43 AM, David Gobbi > wrote: > > Hi David (and David), > > > > The only advantage of my unit test header is that it is a single header > > (a short one, too) with zero dependencies. So it's easy to add to VTK > > and it's trivial to maintain. > > > > If either of you has a better solution, then go ahead and make a merge > > request. I'll review it for you ;) > > > > - David > > > > > > On Tue, Jul 28, 2015 at 8:27 AM, David Thompson < > david.thompson at kitware.com> > > wrote: > >> > >> Another project I work on has been using Bandit[1] to good effect. > >> > >> David > >> > >> [1]:http://banditcpp.org/reference.html > >> > >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers > >> wrote: > >> > >> > A single header file unit testing solution sounds like a good thing. > >> > > >> > ... but ... seems like we could also take advantage of a > >> > well-established generally used unit testing framework (like gtest or > >> > CppUnit) just as easily, and not clutter the VTK source with > >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > >> > > >> > Would it be just as easy to add unit testing using an external unit > >> > testing package? Or are there things about that scenario that are > >> > overly complicated that having our own makes simpler...? > >> > > >> > > >> > David C. > >> > > >> > > >> > > >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi > >> > wrote: > >> >> Hi All, > >> >> > >> >> I've always enjoyed using the python unit testing framework in > >> >> "vtk.test". > >> >> It's been brought up on the list before, but it would be nice if VTK > >> >> included a unit test framework for C++, as well. > >> >> > >> >> For my work projects, I've been using a unit test header that I > wrote a > >> >> year > >> >> and a half ago: > >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > >> >> > >> >> It's a single header file that provides a collection of macros for > >> >> building > >> >> unit tests, it's meant to be innocuous and easy to use. It could go > >> >> into > >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their > >> >> leisure. > >> >> > >> >> Any thoughts? > >> >> > >> >> - David > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jul 28 13:16:54 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 28 Jul 2015 13:16:54 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: Silly me. So old school. One of these days, I have to get back into active contribution mode here, instead of just being a pesky email thinker... Let's do it, then. Nobody's given us a reason not to yet. Unit testing of tens of thousands of VTK methods, coming right up! :-) D On Tue, Jul 28, 2015 at 12:46 PM, David Gobbi wrote: > On Tue, Jul 28, 2015 at 10:29 AM, David Cole wrote: >> >> Have you tested it on all the typical target VTK platforms already, or >> is the VTK dashboard going to light up the first time it builds on >> those ...? > > > You're being silly. The dashboards run on merge requests specifically to > catch platform-specific issues so that they can be fixed prior to merge. > This isn't the old days of VTK where we all pushed directly to master. > > - David > >> >> >> Presumably you use it on multiple platforms, but probably not quite >> all of the ones VTK dashboards get tested on. >> >> >> On Tue, Jul 28, 2015 at 10:43 AM, David Gobbi >> wrote: >> > Hi David (and David), >> > >> > The only advantage of my unit test header is that it is a single header >> > (a short one, too) with zero dependencies. So it's easy to add to VTK >> > and it's trivial to maintain. >> > >> > If either of you has a better solution, then go ahead and make a merge >> > request. I'll review it for you ;) >> > >> > - David >> > >> > >> > On Tue, Jul 28, 2015 at 8:27 AM, David Thompson >> > >> > wrote: >> >> >> >> Another project I work on has been using Bandit[1] to good effect. >> >> >> >> David >> >> >> >> [1]:http://banditcpp.org/reference.html >> >> >> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers >> >> wrote: >> >> >> >> > A single header file unit testing solution sounds like a good thing. >> >> > >> >> > ... but ... seems like we could also take advantage of a >> >> > well-established generally used unit testing framework (like gtest or >> >> > CppUnit) just as easily, and not clutter the VTK source with >> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >> >> > >> >> > Would it be just as easy to add unit testing using an external unit >> >> > testing package? Or are there things about that scenario that are >> >> > overly complicated that having our own makes simpler...? >> >> > >> >> > >> >> > David C. >> >> > >> >> > >> >> > >> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi >> >> > wrote: >> >> >> Hi All, >> >> >> >> >> >> I've always enjoyed using the python unit testing framework in >> >> >> "vtk.test". >> >> >> It's been brought up on the list before, but it would be nice if VTK >> >> >> included a unit test framework for C++, as well. >> >> >> >> >> >> For my work projects, I've been using a unit test header that I >> >> >> wrote a >> >> >> year >> >> >> and a half ago: >> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >> >> >> >> >> It's a single header file that provides a collection of macros for >> >> >> building >> >> >> unit tests, it's meant to be innocuous and easy to use. It could go >> >> >> into >> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their >> >> >> leisure. >> >> >> >> >> >> Any thoughts? >> >> >> >> >> >> - David >> >> >> > > > From david.thompson at kitware.com Tue Jul 28 13:34:52 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 28 Jul 2015 13:34:52 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: Message-ID: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Hi David(s), I really like the single-header idea, especially the macros for testing whether values match to within a tolerance. My concerns are 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now that we have ExternalData, provided?) access to baseline images doesn't seem to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to extend the vtkTesting class to be more usable by including methods similar to your macros? 2. One thing I dislike about most/all of the C++ test frameworks is that the error messages are assumed to be fixed and the methods often do not present a way to include the incorrect result as part of the failure message. It is nice that your macros include that. However, given that tests often fail on machines I don't have access to, it is really nice to encourage people to write useful messages. Macros like CHECK_CLOSE would be better if they accepted a message as a final argument, especially if the argument was passed to a std::ostream object the way vtkGenericWarningMacro() does so that people can (are forced to) provide more context about where the two numbers being compared come from. David > On Jul 28, 2015, at 10:43 AM, David Gobbi wrote: > > Hi David (and David), > > The only advantage of my unit test header is that it is a single header > (a short one, too) with zero dependencies. So it's easy to add to VTK > and it's trivial to maintain. > > If either of you has a better solution, then go ahead and make a merge > request. I'll review it for you ;) > > - David > > > On Tue, Jul 28, 2015 at 8:27 AM, David Thompson wrote: > Another project I work on has been using Bandit[1] to good effect. > > David > > [1]:http://banditcpp.org/reference.html > > On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers wrote: > > > A single header file unit testing solution sounds like a good thing. > > > > ... but ... seems like we could also take advantage of a > > well-established generally used unit testing framework (like gtest or > > CppUnit) just as easily, and not clutter the VTK source with > > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > > > > Would it be just as easy to add unit testing using an external unit > > testing package? Or are there things about that scenario that are > > overly complicated that having our own makes simpler...? > > > > > > David C. > > > > > > > > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi wrote: > >> Hi All, > >> > >> I've always enjoyed using the python unit testing framework in "vtk.test". > >> It's been brought up on the list before, but it would be nice if VTK > >> included a unit test framework for C++, as well. > >> > >> For my work projects, I've been using a unit test header that I wrote a year > >> and a half ago: > >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > >> > >> It's a single header file that provides a collection of macros for building > >> unit tests, it's meant to be innocuous and easy to use. It could go into > >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their leisure. > >> > >> Any thoughts? > >> > >> - David > > From bill.lorensen at gmail.com Tue Jul 28 14:10:12 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 28 Jul 2015 14:10:12 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: I have been adding unit tests lately using old school vtk testing. I'll be willing to kick the tires on David's framework. My goal in these unit tests to get as close as 100% coverage as possible, verifying results when possible. This includes exercising Error and Warning code and checking the messages themselves. I'll admit that I'm skeptical, but hopeful that adding a new test framework will increase code coverage. On Tue, Jul 28, 2015 at 1:34 PM, David Thompson wrote: > Hi David(s), > > I really like the single-header idea, especially the macros for testing whether values match to within a tolerance. > > My concerns are > > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now that we have ExternalData, provided?) access to baseline images doesn't seem to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to extend the vtkTesting class to be more usable by including methods similar to your macros? > > 2. One thing I dislike about most/all of the C++ test frameworks is that the error messages are assumed to be fixed and the methods often do not present a way to include the incorrect result as part of the failure message. It is nice that your macros include that. However, given that tests often fail on machines I don't have access to, it is really nice to encourage people to write useful messages. Macros like CHECK_CLOSE would be better if they accepted a message as a final argument, especially if the argument was passed to a std::ostream object the way vtkGenericWarningMacro() does so that people can (are forced to) provide more context about where the two numbers being compared come from. > > David > >> On Jul 28, 2015, at 10:43 AM, David Gobbi wrote: >> >> Hi David (and David), >> >> The only advantage of my unit test header is that it is a single header >> (a short one, too) with zero dependencies. So it's easy to add to VTK >> and it's trivial to maintain. >> >> If either of you has a better solution, then go ahead and make a merge >> request. I'll review it for you ;) >> >> - David >> >> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson wrote: >> Another project I work on has been using Bandit[1] to good effect. >> >> David >> >> [1]:http://banditcpp.org/reference.html >> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers wrote: >> >> > A single header file unit testing solution sounds like a good thing. >> > >> > ... but ... seems like we could also take advantage of a >> > well-established generally used unit testing framework (like gtest or >> > CppUnit) just as easily, and not clutter the VTK source with >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >> > >> > Would it be just as easy to add unit testing using an external unit >> > testing package? Or are there things about that scenario that are >> > overly complicated that having our own makes simpler...? >> > >> > >> > David C. >> > >> > >> > >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi wrote: >> >> Hi All, >> >> >> >> I've always enjoyed using the python unit testing framework in "vtk.test". >> >> It's been brought up on the list before, but it would be nice if VTK >> >> included a unit test framework for C++, as well. >> >> >> >> For my work projects, I've been using a unit test header that I wrote a year >> >> and a half ago: >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >> >> >> It's a single header file that provides a collection of macros for building >> >> unit tests, it's meant to be innocuous and easy to use. It could go into >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their leisure. >> >> >> >> Any thoughts? >> >> >> >> - David >> >> > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Tue Jul 28 14:22:18 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 28 Jul 2015 14:22:18 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: We've got years of layers of great but poorly described regression test infrastructure in the code today that makes it harder than it could be to make new tests. If this is yet another layer, I'm not in favor. But if this makes adding tests tractable for newbies and we put together and post an easy but comprehensive recipe for adding tests along with this, then I'm very much in favor. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen wrote: > I have been adding unit tests lately using old school vtk testing. > I'll be willing to kick the tires on David's framework. > > My goal in these unit tests to get as close as 100% coverage as > possible, verifying results when possible. This includes exercising > Error and Warning code and checking the messages themselves. > > I'll admit that I'm skeptical, but hopeful that adding a new test > framework will increase code coverage. > > On Tue, Jul 28, 2015 at 1:34 PM, David Thompson > wrote: > > Hi David(s), > > > > I really like the single-header idea, especially the macros for testing > whether values match to within a tolerance. > > > > My concerns are > > > > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now > that we have ExternalData, provided?) access to baseline images doesn't > seem to fit into the FIXTURE macro. Is there a way to integrate it? Or a > way to extend the vtkTesting class to be more usable by including methods > similar to your macros? > > > > 2. One thing I dislike about most/all of the C++ test frameworks is that > the error messages are assumed to be fixed and the methods often do not > present a way to include the incorrect result as part of the failure > message. It is nice that your macros include that. However, given that > tests often fail on machines I don't have access to, it is really nice to > encourage people to write useful messages. Macros like CHECK_CLOSE would be > better if they accepted a message as a final argument, especially if the > argument was passed to a std::ostream object the way > vtkGenericWarningMacro() does so that people can (are forced to) provide > more context about where the two numbers being compared come from. > > > > David > > > >> On Jul 28, 2015, at 10:43 AM, David Gobbi > wrote: > >> > >> Hi David (and David), > >> > >> The only advantage of my unit test header is that it is a single header > >> (a short one, too) with zero dependencies. So it's easy to add to VTK > >> and it's trivial to maintain. > >> > >> If either of you has a better solution, then go ahead and make a merge > >> request. I'll review it for you ;) > >> > >> - David > >> > >> > >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson < > david.thompson at kitware.com> wrote: > >> Another project I work on has been using Bandit[1] to good effect. > >> > >> David > >> > >> [1]:http://banditcpp.org/reference.html > >> > >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers < > vtk-developers at vtk.org> wrote: > >> > >> > A single header file unit testing solution sounds like a good thing. > >> > > >> > ... but ... seems like we could also take advantage of a > >> > well-established generally used unit testing framework (like gtest or > >> > CppUnit) just as easily, and not clutter the VTK source with > >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > >> > > >> > Would it be just as easy to add unit testing using an external unit > >> > testing package? Or are there things about that scenario that are > >> > overly complicated that having our own makes simpler...? > >> > > >> > > >> > David C. > >> > > >> > > >> > > >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi > wrote: > >> >> Hi All, > >> >> > >> >> I've always enjoyed using the python unit testing framework in > "vtk.test". > >> >> It's been brought up on the list before, but it would be nice if VTK > >> >> included a unit test framework for C++, as well. > >> >> > >> >> For my work projects, I've been using a unit test header that I > wrote a year > >> >> and a half ago: > >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > >> >> > >> >> It's a single header file that provides a collection of macros for > building > >> >> unit tests, it's meant to be innocuous and easy to use. It could go > into > >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their > leisure. > >> >> > >> >> Any thoughts? > >> >> > >> >> - David > >> > >> > > > > _______________________________________________ > > 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: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Jul 28 14:26:11 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 28 Jul 2015 14:26:11 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: +1 On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle wrote: > We've got years of layers of great but poorly described regression test > infrastructure in the code today that makes it harder than it could be to > make new tests. If this is yet another layer, I'm not in favor. > > But if this makes adding tests tractable for newbies and we put together and > post an easy but comprehensive recipe for adding tests along with this, then > I'm very much in favor. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen > wrote: >> >> I have been adding unit tests lately using old school vtk testing. >> I'll be willing to kick the tires on David's framework. >> >> My goal in these unit tests to get as close as 100% coverage as >> possible, verifying results when possible. This includes exercising >> Error and Warning code and checking the messages themselves. >> >> I'll admit that I'm skeptical, but hopeful that adding a new test >> framework will increase code coverage. >> >> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson >> wrote: >> > Hi David(s), >> > >> > I really like the single-header idea, especially the macros for testing >> > whether values match to within a tolerance. >> > >> > My concerns are >> > >> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now >> > that we have ExternalData, provided?) access to baseline images doesn't seem >> > to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to >> > extend the vtkTesting class to be more usable by including methods similar >> > to your macros? >> > >> > 2. One thing I dislike about most/all of the C++ test frameworks is that >> > the error messages are assumed to be fixed and the methods often do not >> > present a way to include the incorrect result as part of the failure >> > message. It is nice that your macros include that. However, given that tests >> > often fail on machines I don't have access to, it is really nice to >> > encourage people to write useful messages. Macros like CHECK_CLOSE would be >> > better if they accepted a message as a final argument, especially if the >> > argument was passed to a std::ostream object the way >> > vtkGenericWarningMacro() does so that people can (are forced to) provide >> > more context about where the two numbers being compared come from. >> > >> > David >> > >> >> On Jul 28, 2015, at 10:43 AM, David Gobbi >> >> wrote: >> >> >> >> Hi David (and David), >> >> >> >> The only advantage of my unit test header is that it is a single header >> >> (a short one, too) with zero dependencies. So it's easy to add to VTK >> >> and it's trivial to maintain. >> >> >> >> If either of you has a better solution, then go ahead and make a merge >> >> request. I'll review it for you ;) >> >> >> >> - David >> >> >> >> >> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson >> >> wrote: >> >> Another project I work on has been using Bandit[1] to good effect. >> >> >> >> David >> >> >> >> [1]:http://banditcpp.org/reference.html >> >> >> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers >> >> wrote: >> >> >> >> > A single header file unit testing solution sounds like a good thing. >> >> > >> >> > ... but ... seems like we could also take advantage of a >> >> > well-established generally used unit testing framework (like gtest or >> >> > CppUnit) just as easily, and not clutter the VTK source with >> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >> >> > >> >> > Would it be just as easy to add unit testing using an external unit >> >> > testing package? Or are there things about that scenario that are >> >> > overly complicated that having our own makes simpler...? >> >> > >> >> > >> >> > David C. >> >> > >> >> > >> >> > >> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi >> >> > wrote: >> >> >> Hi All, >> >> >> >> >> >> I've always enjoyed using the python unit testing framework in >> >> >> "vtk.test". >> >> >> It's been brought up on the list before, but it would be nice if VTK >> >> >> included a unit test framework for C++, as well. >> >> >> >> >> >> For my work projects, I've been using a unit test header that I >> >> >> wrote a year >> >> >> and a half ago: >> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >> >> >> >> >> It's a single header file that provides a collection of macros for >> >> >> building >> >> >> unit tests, it's meant to be innocuous and easy to use. It could go >> >> >> into >> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their >> >> >> leisure. >> >> >> >> >> >> Any thoughts? >> >> >> >> >> >> - David >> >> >> >> >> > >> > _______________________________________________ >> > 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: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From shawn.waldon at kitware.com Tue Jul 28 14:27:20 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 28 Jul 2015 14:27:20 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: +1 to the test recipe. On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle wrote: > We've got years of layers of great but poorly described regression test > infrastructure in the code today that makes it harder than it could be to > make new tests. If this is yet another layer, I'm not in favor. > > But if this makes adding tests tractable for newbies and we put together > and post an easy but comprehensive recipe for adding tests along with this, > then I'm very much in favor. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen > wrote: > >> I have been adding unit tests lately using old school vtk testing. >> I'll be willing to kick the tires on David's framework. >> >> My goal in these unit tests to get as close as 100% coverage as >> possible, verifying results when possible. This includes exercising >> Error and Warning code and checking the messages themselves. >> >> I'll admit that I'm skeptical, but hopeful that adding a new test >> framework will increase code coverage. >> >> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson >> wrote: >> > Hi David(s), >> > >> > I really like the single-header idea, especially the macros for testing >> whether values match to within a tolerance. >> > >> > My concerns are >> > >> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now >> that we have ExternalData, provided?) access to baseline images doesn't >> seem to fit into the FIXTURE macro. Is there a way to integrate it? Or a >> way to extend the vtkTesting class to be more usable by including methods >> similar to your macros? >> > >> > 2. One thing I dislike about most/all of the C++ test frameworks is >> that the error messages are assumed to be fixed and the methods often do >> not present a way to include the incorrect result as part of the failure >> message. It is nice that your macros include that. However, given that >> tests often fail on machines I don't have access to, it is really nice to >> encourage people to write useful messages. Macros like CHECK_CLOSE would be >> better if they accepted a message as a final argument, especially if the >> argument was passed to a std::ostream object the way >> vtkGenericWarningMacro() does so that people can (are forced to) provide >> more context about where the two numbers being compared come from. >> > >> > David >> > >> >> On Jul 28, 2015, at 10:43 AM, David Gobbi >> wrote: >> >> >> >> Hi David (and David), >> >> >> >> The only advantage of my unit test header is that it is a single header >> >> (a short one, too) with zero dependencies. So it's easy to add to VTK >> >> and it's trivial to maintain. >> >> >> >> If either of you has a better solution, then go ahead and make a merge >> >> request. I'll review it for you ;) >> >> >> >> - David >> >> >> >> >> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson < >> david.thompson at kitware.com> wrote: >> >> Another project I work on has been using Bandit[1] to good effect. >> >> >> >> David >> >> >> >> [1]:http://banditcpp.org/reference.html >> >> >> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers < >> vtk-developers at vtk.org> wrote: >> >> >> >> > A single header file unit testing solution sounds like a good thing. >> >> > >> >> > ... but ... seems like we could also take advantage of a >> >> > well-established generally used unit testing framework (like gtest or >> >> > CppUnit) just as easily, and not clutter the VTK source with >> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >> >> > >> >> > Would it be just as easy to add unit testing using an external unit >> >> > testing package? Or are there things about that scenario that are >> >> > overly complicated that having our own makes simpler...? >> >> > >> >> > >> >> > David C. >> >> > >> >> > >> >> > >> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi >> wrote: >> >> >> Hi All, >> >> >> >> >> >> I've always enjoyed using the python unit testing framework in >> "vtk.test". >> >> >> It's been brought up on the list before, but it would be nice if VTK >> >> >> included a unit test framework for C++, as well. >> >> >> >> >> >> For my work projects, I've been using a unit test header that I >> wrote a year >> >> >> and a half ago: >> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >> >> >> >> >> It's a single header file that provides a collection of macros for >> building >> >> >> unit tests, it's meant to be innocuous and easy to use. It could >> go into >> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their >> leisure. >> >> >> >> >> >> Any thoughts? >> >> >> >> >> >> - David >> >> >> >> >> > >> > _______________________________________________ >> > 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: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jul 28 14:32:44 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 28 Jul 2015 14:32:44 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: Sounds like we "just" need a wiki page / blog post / Source article / white-papery-thingy about C++ VTK testing. (And then a follow-on one for python.) Having a way to add a C++ unit test of a newly added VTK class will be great! (Adding them for all the existing classes will certainly be a chore, but it is finite, and will increase code coverage, although perhaps not as easily as any of us would like...) On Tue, Jul 28, 2015 at 2:27 PM, Shawn Waldon wrote: > +1 to the test recipe. > > On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle > wrote: >> >> We've got years of layers of great but poorly described regression test >> infrastructure in the code today that makes it harder than it could be to >> make new tests. If this is yet another layer, I'm not in favor. >> >> But if this makes adding tests tractable for newbies and we put together >> and post an easy but comprehensive recipe for adding tests along with this, >> then I'm very much in favor. >> >> >> >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen >> wrote: >>> >>> I have been adding unit tests lately using old school vtk testing. >>> I'll be willing to kick the tires on David's framework. >>> >>> My goal in these unit tests to get as close as 100% coverage as >>> possible, verifying results when possible. This includes exercising >>> Error and Warning code and checking the messages themselves. >>> >>> I'll admit that I'm skeptical, but hopeful that adding a new test >>> framework will increase code coverage. >>> >>> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson >>> wrote: >>> > Hi David(s), >>> > >>> > I really like the single-header idea, especially the macros for testing >>> > whether values match to within a tolerance. >>> > >>> > My concerns are >>> > >>> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now >>> > that we have ExternalData, provided?) access to baseline images doesn't seem >>> > to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to >>> > extend the vtkTesting class to be more usable by including methods similar >>> > to your macros? >>> > >>> > 2. One thing I dislike about most/all of the C++ test frameworks is >>> > that the error messages are assumed to be fixed and the methods often do not >>> > present a way to include the incorrect result as part of the failure >>> > message. It is nice that your macros include that. However, given that tests >>> > often fail on machines I don't have access to, it is really nice to >>> > encourage people to write useful messages. Macros like CHECK_CLOSE would be >>> > better if they accepted a message as a final argument, especially if the >>> > argument was passed to a std::ostream object the way >>> > vtkGenericWarningMacro() does so that people can (are forced to) provide >>> > more context about where the two numbers being compared come from. >>> > >>> > David >>> > >>> >> On Jul 28, 2015, at 10:43 AM, David Gobbi >>> >> wrote: >>> >> >>> >> Hi David (and David), >>> >> >>> >> The only advantage of my unit test header is that it is a single >>> >> header >>> >> (a short one, too) with zero dependencies. So it's easy to add to VTK >>> >> and it's trivial to maintain. >>> >> >>> >> If either of you has a better solution, then go ahead and make a merge >>> >> request. I'll review it for you ;) >>> >> >>> >> - David >>> >> >>> >> >>> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson >>> >> wrote: >>> >> Another project I work on has been using Bandit[1] to good effect. >>> >> >>> >> David >>> >> >>> >> [1]:http://banditcpp.org/reference.html >>> >> >>> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers >>> >> wrote: >>> >> >>> >> > A single header file unit testing solution sounds like a good thing. >>> >> > >>> >> > ... but ... seems like we could also take advantage of a >>> >> > well-established generally used unit testing framework (like gtest >>> >> > or >>> >> > CppUnit) just as easily, and not clutter the VTK source with >>> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >>> >> > >>> >> > Would it be just as easy to add unit testing using an external unit >>> >> > testing package? Or are there things about that scenario that are >>> >> > overly complicated that having our own makes simpler...? >>> >> > >>> >> > >>> >> > David C. >>> >> > >>> >> > >>> >> > >>> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi >>> >> > wrote: >>> >> >> Hi All, >>> >> >> >>> >> >> I've always enjoyed using the python unit testing framework in >>> >> >> "vtk.test". >>> >> >> It's been brought up on the list before, but it would be nice if >>> >> >> VTK >>> >> >> included a unit test framework for C++, as well. >>> >> >> >>> >> >> For my work projects, I've been using a unit test header that I >>> >> >> wrote a year >>> >> >> and a half ago: >>> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >>> >> >> >>> >> >> It's a single header file that provides a collection of macros for >>> >> >> building >>> >> >> unit tests, it's meant to be innocuous and easy to use. It could >>> >> >> go into >>> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their >>> >> >> leisure. >>> >> >> >>> >> >> Any thoughts? >>> >> >> >>> >> >> - David >>> >> >>> >> >>> > >>> > _______________________________________________ >>> > 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: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From bill.lorensen at gmail.com Tue Jul 28 14:45:40 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 28 Jul 2015 14:45:40 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: DC, I thought about writing a wiki/blog/source/paper on vtk testing (once winter sets in). It would need to focus on best practices, because vtk has many different approaches to testing. I intended to start on non-rendering unit testing. This is a real weakness in vtk. A solid unit testing framework is needed. David G's testing framework might be a good start, but perhaps a more thorough requirements analysis is required. I think a good description of rendering-based testing is possible and might be a short putt. Bill On Tue, Jul 28, 2015 at 2:32 PM, David Cole via vtk-developers wrote: > Sounds like we "just" need a wiki page / blog post / Source article / > white-papery-thingy about C++ VTK testing. > > (And then a follow-on one for python.) > > Having a way to add a C++ unit test of a newly added VTK class will be > great! (Adding them for all the existing classes will certainly be a > chore, but it is finite, and will increase code coverage, although > perhaps not as easily as any of us would like...) > > > > On Tue, Jul 28, 2015 at 2:27 PM, Shawn Waldon wrote: >> +1 to the test recipe. >> >> On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle >> wrote: >>> >>> We've got years of layers of great but poorly described regression test >>> infrastructure in the code today that makes it harder than it could be to >>> make new tests. If this is yet another layer, I'm not in favor. >>> >>> But if this makes adding tests tractable for newbies and we put together >>> and post an easy but comprehensive recipe for adding tests along with this, >>> then I'm very much in favor. >>> >>> >>> >>> >>> David E DeMarle >>> Kitware, Inc. >>> R&D Engineer >>> 21 Corporate Drive >>> Clifton Park, NY 12065-8662 >>> Phone: 518-881-4909 >>> >>> On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen >>> wrote: >>>> >>>> I have been adding unit tests lately using old school vtk testing. >>>> I'll be willing to kick the tires on David's framework. >>>> >>>> My goal in these unit tests to get as close as 100% coverage as >>>> possible, verifying results when possible. This includes exercising >>>> Error and Warning code and checking the messages themselves. >>>> >>>> I'll admit that I'm skeptical, but hopeful that adding a new test >>>> framework will increase code coverage. >>>> >>>> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson >>>> wrote: >>>> > Hi David(s), >>>> > >>>> > I really like the single-header idea, especially the macros for testing >>>> > whether values match to within a tolerance. >>>> > >>>> > My concerns are >>>> > >>>> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now >>>> > that we have ExternalData, provided?) access to baseline images doesn't seem >>>> > to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to >>>> > extend the vtkTesting class to be more usable by including methods similar >>>> > to your macros? >>>> > >>>> > 2. One thing I dislike about most/all of the C++ test frameworks is >>>> > that the error messages are assumed to be fixed and the methods often do not >>>> > present a way to include the incorrect result as part of the failure >>>> > message. It is nice that your macros include that. However, given that tests >>>> > often fail on machines I don't have access to, it is really nice to >>>> > encourage people to write useful messages. Macros like CHECK_CLOSE would be >>>> > better if they accepted a message as a final argument, especially if the >>>> > argument was passed to a std::ostream object the way >>>> > vtkGenericWarningMacro() does so that people can (are forced to) provide >>>> > more context about where the two numbers being compared come from. >>>> > >>>> > David >>>> > >>>> >> On Jul 28, 2015, at 10:43 AM, David Gobbi >>>> >> wrote: >>>> >> >>>> >> Hi David (and David), >>>> >> >>>> >> The only advantage of my unit test header is that it is a single >>>> >> header >>>> >> (a short one, too) with zero dependencies. So it's easy to add to VTK >>>> >> and it's trivial to maintain. >>>> >> >>>> >> If either of you has a better solution, then go ahead and make a merge >>>> >> request. I'll review it for you ;) >>>> >> >>>> >> - David >>>> >> >>>> >> >>>> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson >>>> >> wrote: >>>> >> Another project I work on has been using Bandit[1] to good effect. >>>> >> >>>> >> David >>>> >> >>>> >> [1]:http://banditcpp.org/reference.html >>>> >> >>>> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers >>>> >> wrote: >>>> >> >>>> >> > A single header file unit testing solution sounds like a good thing. >>>> >> > >>>> >> > ... but ... seems like we could also take advantage of a >>>> >> > well-established generally used unit testing framework (like gtest >>>> >> > or >>>> >> > CppUnit) just as easily, and not clutter the VTK source with >>>> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >>>> >> > >>>> >> > Would it be just as easy to add unit testing using an external unit >>>> >> > testing package? Or are there things about that scenario that are >>>> >> > overly complicated that having our own makes simpler...? >>>> >> > >>>> >> > >>>> >> > David C. >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi >>>> >> > wrote: >>>> >> >> Hi All, >>>> >> >> >>>> >> >> I've always enjoyed using the python unit testing framework in >>>> >> >> "vtk.test". >>>> >> >> It's been brought up on the list before, but it would be nice if >>>> >> >> VTK >>>> >> >> included a unit test framework for C++, as well. >>>> >> >> >>>> >> >> For my work projects, I've been using a unit test header that I >>>> >> >> wrote a year >>>> >> >> and a half ago: >>>> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >>>> >> >> >>>> >> >> It's a single header file that provides a collection of macros for >>>> >> >> building >>>> >> >> unit tests, it's meant to be innocuous and easy to use. It could >>>> >> >> go into >>>> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their >>>> >> >> leisure. >>>> >> >> >>>> >> >> Any thoughts? >>>> >> >> >>>> >> >> - David >>>> >> >>>> >> >>>> > >>>> > _______________________________________________ >>>> > 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: >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>> > >>>> >>>> >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From brad.king at kitware.com Tue Jul 28 14:47:23 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 14:47:23 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: <55B7CE3B.6030408@kitware.com> On 07/28/2015 02:32 PM, David Cole via vtk-developers wrote: > Sounds like we "just" need a wiki page / blog post / Source article / > white-papery-thingy about C++ VTK testing. The Documentation/dev directory already houses Git developer instructions. It is a good place to put other such developer-oriented documentation because the .md files are rendered on gitlab.kitware.com and any updates to the documentation goes through the normal review process. -Brad From shawn.waldon at kitware.com Tue Jul 28 14:49:18 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 28 Jul 2015 14:49:18 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: Possibly add a way to avoid some of the duplicated code too. Most of the tests set up some data and then use essentially the same 30 lines of code to create the Renderer, create the Window, create the Interactor, connect it all together, show the window, call Render() and start the interactor. I normally just copy an existing test and modify it, but it would be nice if there were some way to avoid that to make creating a new test easier. On Tue, Jul 28, 2015 at 2:32 PM, David Cole wrote: > Sounds like we "just" need a wiki page / blog post / Source article / > white-papery-thingy about C++ VTK testing. > > (And then a follow-on one for python.) > > Having a way to add a C++ unit test of a newly added VTK class will be > great! (Adding them for all the existing classes will certainly be a > chore, but it is finite, and will increase code coverage, although > perhaps not as easily as any of us would like...) > > > > On Tue, Jul 28, 2015 at 2:27 PM, Shawn Waldon > wrote: > > +1 to the test recipe. > > > > On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle < > dave.demarle at kitware.com> > > wrote: > >> > >> We've got years of layers of great but poorly described regression test > >> infrastructure in the code today that makes it harder than it could be > to > >> make new tests. If this is yet another layer, I'm not in favor. > >> > >> But if this makes adding tests tractable for newbies and we put together > >> and post an easy but comprehensive recipe for adding tests along with > this, > >> then I'm very much in favor. > >> > >> > >> > >> > >> David E DeMarle > >> Kitware, Inc. > >> R&D Engineer > >> 21 Corporate Drive > >> Clifton Park, NY 12065-8662 > >> Phone: 518-881-4909 > >> > >> On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen > > >> wrote: > >>> > >>> I have been adding unit tests lately using old school vtk testing. > >>> I'll be willing to kick the tires on David's framework. > >>> > >>> My goal in these unit tests to get as close as 100% coverage as > >>> possible, verifying results when possible. This includes exercising > >>> Error and Warning code and checking the messages themselves. > >>> > >>> I'll admit that I'm skeptical, but hopeful that adding a new test > >>> framework will increase code coverage. > >>> > >>> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson > >>> wrote: > >>> > Hi David(s), > >>> > > >>> > I really like the single-header idea, especially the macros for > testing > >>> > whether values match to within a tolerance. > >>> > > >>> > My concerns are > >>> > > >>> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or > now > >>> > that we have ExternalData, provided?) access to baseline images > doesn't seem > >>> > to fit into the FIXTURE macro. Is there a way to integrate it? Or a > way to > >>> > extend the vtkTesting class to be more usable by including methods > similar > >>> > to your macros? > >>> > > >>> > 2. One thing I dislike about most/all of the C++ test frameworks is > >>> > that the error messages are assumed to be fixed and the methods > often do not > >>> > present a way to include the incorrect result as part of the failure > >>> > message. It is nice that your macros include that. However, given > that tests > >>> > often fail on machines I don't have access to, it is really nice to > >>> > encourage people to write useful messages. Macros like CHECK_CLOSE > would be > >>> > better if they accepted a message as a final argument, especially if > the > >>> > argument was passed to a std::ostream object the way > >>> > vtkGenericWarningMacro() does so that people can (are forced to) > provide > >>> > more context about where the two numbers being compared come from. > >>> > > >>> > David > >>> > > >>> >> On Jul 28, 2015, at 10:43 AM, David Gobbi > >>> >> wrote: > >>> >> > >>> >> Hi David (and David), > >>> >> > >>> >> The only advantage of my unit test header is that it is a single > >>> >> header > >>> >> (a short one, too) with zero dependencies. So it's easy to add to > VTK > >>> >> and it's trivial to maintain. > >>> >> > >>> >> If either of you has a better solution, then go ahead and make a > merge > >>> >> request. I'll review it for you ;) > >>> >> > >>> >> - David > >>> >> > >>> >> > >>> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson > >>> >> wrote: > >>> >> Another project I work on has been using Bandit[1] to good effect. > >>> >> > >>> >> David > >>> >> > >>> >> [1]:http://banditcpp.org/reference.html > >>> >> > >>> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers > >>> >> wrote: > >>> >> > >>> >> > A single header file unit testing solution sounds like a good > thing. > >>> >> > > >>> >> > ... but ... seems like we could also take advantage of a > >>> >> > well-established generally used unit testing framework (like gtest > >>> >> > or > >>> >> > CppUnit) just as easily, and not clutter the VTK source with > >>> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > >>> >> > > >>> >> > Would it be just as easy to add unit testing using an external > unit > >>> >> > testing package? Or are there things about that scenario that are > >>> >> > overly complicated that having our own makes simpler...? > >>> >> > > >>> >> > > >>> >> > David C. > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi < > david.gobbi at gmail.com> > >>> >> > wrote: > >>> >> >> Hi All, > >>> >> >> > >>> >> >> I've always enjoyed using the python unit testing framework in > >>> >> >> "vtk.test". > >>> >> >> It's been brought up on the list before, but it would be nice if > >>> >> >> VTK > >>> >> >> included a unit test framework for C++, as well. > >>> >> >> > >>> >> >> For my work projects, I've been using a unit test header that I > >>> >> >> wrote a year > >>> >> >> and a half ago: > >>> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > >>> >> >> > >>> >> >> It's a single header file that provides a collection of macros > for > >>> >> >> building > >>> >> >> unit tests, it's meant to be innocuous and easy to use. It could > >>> >> >> go into > >>> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at > their > >>> >> >> leisure. > >>> >> >> > >>> >> >> Any thoughts? > >>> >> >> > >>> >> >> - David > >>> >> > >>> >> > >>> > > >>> > _______________________________________________ > >>> > 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: > >>> > http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > > >>> > >>> > >>> > >>> -- > >>> Unpaid intern in BillsBasement at noware dot com > >>> _______________________________________________ > >>> Powered by www.kitware.com > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >> > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Jul 28 14:57:39 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 28 Jul 2015 14:57:39 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: Since we are in a wishing mood - I wish we had two test modules for each source module. One for the end-to-end tests that do things like render to verify that some piece of code works. The other for proper unit tests that add no dependencies to the code to test it. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Jul 28, 2015 at 2:49 PM, Shawn Waldon wrote: > Possibly add a way to avoid some of the duplicated code too. Most of the > tests set up some data and then use essentially the same 30 lines of code > to create the Renderer, create the Window, create the Interactor, connect > it all together, show the window, call Render() and start the interactor. > I normally just copy an existing test and modify it, but it would be nice > if there were some way to avoid that to make creating a new test easier. > > On Tue, Jul 28, 2015 at 2:32 PM, David Cole wrote: > >> Sounds like we "just" need a wiki page / blog post / Source article / >> white-papery-thingy about C++ VTK testing. >> >> (And then a follow-on one for python.) >> >> Having a way to add a C++ unit test of a newly added VTK class will be >> great! (Adding them for all the existing classes will certainly be a >> chore, but it is finite, and will increase code coverage, although >> perhaps not as easily as any of us would like...) >> >> >> >> On Tue, Jul 28, 2015 at 2:27 PM, Shawn Waldon >> wrote: >> > +1 to the test recipe. >> > >> > On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle < >> dave.demarle at kitware.com> >> > wrote: >> >> >> >> We've got years of layers of great but poorly described regression test >> >> infrastructure in the code today that makes it harder than it could be >> to >> >> make new tests. If this is yet another layer, I'm not in favor. >> >> >> >> But if this makes adding tests tractable for newbies and we put >> together >> >> and post an easy but comprehensive recipe for adding tests along with >> this, >> >> then I'm very much in favor. >> >> >> >> >> >> >> >> >> >> David E DeMarle >> >> Kitware, Inc. >> >> R&D Engineer >> >> 21 Corporate Drive >> >> Clifton Park, NY 12065-8662 >> >> Phone: 518-881-4909 >> >> >> >> On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen < >> bill.lorensen at gmail.com> >> >> wrote: >> >>> >> >>> I have been adding unit tests lately using old school vtk testing. >> >>> I'll be willing to kick the tires on David's framework. >> >>> >> >>> My goal in these unit tests to get as close as 100% coverage as >> >>> possible, verifying results when possible. This includes exercising >> >>> Error and Warning code and checking the messages themselves. >> >>> >> >>> I'll admit that I'm skeptical, but hopeful that adding a new test >> >>> framework will increase code coverage. >> >>> >> >>> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson >> >>> wrote: >> >>> > Hi David(s), >> >>> > >> >>> > I really like the single-header idea, especially the macros for >> testing >> >>> > whether values match to within a tolerance. >> >>> > >> >>> > My concerns are >> >>> > >> >>> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or >> now >> >>> > that we have ExternalData, provided?) access to baseline images >> doesn't seem >> >>> > to fit into the FIXTURE macro. Is there a way to integrate it? Or a >> way to >> >>> > extend the vtkTesting class to be more usable by including methods >> similar >> >>> > to your macros? >> >>> > >> >>> > 2. One thing I dislike about most/all of the C++ test frameworks is >> >>> > that the error messages are assumed to be fixed and the methods >> often do not >> >>> > present a way to include the incorrect result as part of the failure >> >>> > message. It is nice that your macros include that. However, given >> that tests >> >>> > often fail on machines I don't have access to, it is really nice to >> >>> > encourage people to write useful messages. Macros like CHECK_CLOSE >> would be >> >>> > better if they accepted a message as a final argument, especially >> if the >> >>> > argument was passed to a std::ostream object the way >> >>> > vtkGenericWarningMacro() does so that people can (are forced to) >> provide >> >>> > more context about where the two numbers being compared come from. >> >>> > >> >>> > David >> >>> > >> >>> >> On Jul 28, 2015, at 10:43 AM, David Gobbi >> >>> >> wrote: >> >>> >> >> >>> >> Hi David (and David), >> >>> >> >> >>> >> The only advantage of my unit test header is that it is a single >> >>> >> header >> >>> >> (a short one, too) with zero dependencies. So it's easy to add to >> VTK >> >>> >> and it's trivial to maintain. >> >>> >> >> >>> >> If either of you has a better solution, then go ahead and make a >> merge >> >>> >> request. I'll review it for you ;) >> >>> >> >> >>> >> - David >> >>> >> >> >>> >> >> >>> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson >> >>> >> wrote: >> >>> >> Another project I work on has been using Bandit[1] to good effect. >> >>> >> >> >>> >> David >> >>> >> >> >>> >> [1]:http://banditcpp.org/reference.html >> >>> >> >> >>> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers >> >>> >> wrote: >> >>> >> >> >>> >> > A single header file unit testing solution sounds like a good >> thing. >> >>> >> > >> >>> >> > ... but ... seems like we could also take advantage of a >> >>> >> > well-established generally used unit testing framework (like >> gtest >> >>> >> > or >> >>> >> > CppUnit) just as easily, and not clutter the VTK source with >> >>> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. >> >>> >> > >> >>> >> > Would it be just as easy to add unit testing using an external >> unit >> >>> >> > testing package? Or are there things about that scenario that are >> >>> >> > overly complicated that having our own makes simpler...? >> >>> >> > >> >>> >> > >> >>> >> > David C. >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi < >> david.gobbi at gmail.com> >> >>> >> > wrote: >> >>> >> >> Hi All, >> >>> >> >> >> >>> >> >> I've always enjoyed using the python unit testing framework in >> >>> >> >> "vtk.test". >> >>> >> >> It's been brought up on the list before, but it would be nice if >> >>> >> >> VTK >> >>> >> >> included a unit test framework for C++, as well. >> >>> >> >> >> >>> >> >> For my work projects, I've been using a unit test header that I >> >>> >> >> wrote a year >> >>> >> >> and a half ago: >> >>> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h >> >>> >> >> >> >>> >> >> It's a single header file that provides a collection of macros >> for >> >>> >> >> building >> >>> >> >> unit tests, it's meant to be innocuous and easy to use. It >> could >> >>> >> >> go into >> >>> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at >> their >> >>> >> >> leisure. >> >>> >> >> >> >>> >> >> Any thoughts? >> >>> >> >> >> >>> >> >> - David >> >>> >> >> >>> >> >> >>> > >> >>> > _______________________________________________ >> >>> > 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: >> >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Unpaid intern in BillsBasement at noware dot com >> >>> _______________________________________________ >> >>> Powered by www.kitware.com >> >>> >> >>> Visit other Kitware open-source projects at >> >>> http://www.kitware.com/opensource/opensource.html >> >>> >> >>> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> >>> >> >>> Follow this link to subscribe/unsubscribe: >> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Jul 28 14:59:58 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 28 Jul 2015 14:59:58 -0400 Subject: [vtk-developers] VTK Software Quality History part 1 Message-ID: Folks, This August 2001 paper by Jim Miller and me summarizes our early VTK testing: http://marchingcubes.org/images/9/90/VTKExtremeTesting.pdf This 2005 talk by Dan Belzek presents some background on VTK Testing: http://www.na-mic.org/Wiki/images/b/b7/Dart2.ppt It also shows the first vtk dashboards... Bill From dave.demarle at kitware.com Tue Jul 28 15:02:27 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 28 Jul 2015 15:02:27 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: <55B7CE3B.6030408@kitware.com> References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> <55B7CE3B.6030408@kitware.com> Message-ID: We can expand upon this page's https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md Add test section to let the reader know about all the gory details that Bill refers to that the developer is able to make of of in "MyTest.cxx". David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Jul 28, 2015 at 2:47 PM, Brad King wrote: > On 07/28/2015 02:32 PM, David Cole via vtk-developers wrote: > > Sounds like we "just" need a wiki page / blog post / Source article / > > white-papery-thingy about C++ VTK testing. > > The Documentation/dev directory already houses Git developer instructions. > It is a good place to put other such developer-oriented documentation > because the .md files are rendered on gitlab.kitware.com and any > updates to the documentation goes through the normal review process. > > -Brad > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Jul 28 15:13:36 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 28 Jul 2015 15:13:36 -0400 Subject: [vtk-developers] VTK Software Quality History part 1 In-Reply-To: References: Message-ID: Also this more recent (May 2013) blog post by Marcus Hanwell on using VTK's image regression testing within Avogadro: http://www.kitware.com/blog/home/post/484 On Tue, Jul 28, 2015 at 2:59 PM, Bill Lorensen wrote: > Folks, > > This August 2001 paper by Jim Miller and me summarizes our early VTK testing: > http://marchingcubes.org/images/9/90/VTKExtremeTesting.pdf > > This 2005 talk by Dan Belzek presents some background on VTK Testing: > http://www.na-mic.org/Wiki/images/b/b7/Dart2.ppt > > It also shows the first vtk dashboards... > > Bill > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From david.thompson at kitware.com Tue Jul 28 15:24:49 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 28 Jul 2015 15:24:49 -0400 Subject: [vtk-developers] C++ unit tests In-Reply-To: References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: <361FFCBD-BAFE-490F-B987-9ED8708AAE24@kitware.com> If anyone is collecting wishes: 1. Easy handle multiple image baselines in a single test (not just multiple renderings of the same baseline). IIRC, the vtkTesting class assumes that you have a single baseline, but often there is a need to produce an image for each of several settings of a filter. 2. Easy integration of test images into documentation (both reference and user's guide/tutorials). Bill's wiki scraper does an excellent job for some of the examples, but being able to reference an image in doxygen documentation would be useful. David > On Jul 28, 2015, at 2:57 PM, David E DeMarle wrote: > > Since we are in a wishing mood - I wish we had two test modules for each source module. One for the end-to-end tests that do things like render to verify that some piece of code works. The other for proper unit tests that add no dependencies to the code to test it. > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Jul 28, 2015 at 2:49 PM, Shawn Waldon wrote: > Possibly add a way to avoid some of the duplicated code too. Most of the tests set up some data and then use essentially the same 30 lines of code to create the Renderer, create the Window, create the Interactor, connect it all together, show the window, call Render() and start the interactor. I normally just copy an existing test and modify it, but it would be nice if there were some way to avoid that to make creating a new test easier. > > On Tue, Jul 28, 2015 at 2:32 PM, David Cole wrote: > Sounds like we "just" need a wiki page / blog post / Source article / > white-papery-thingy about C++ VTK testing. > > (And then a follow-on one for python.) > > Having a way to add a C++ unit test of a newly added VTK class will be > great! (Adding them for all the existing classes will certainly be a > chore, but it is finite, and will increase code coverage, although > perhaps not as easily as any of us would like...) > > > > On Tue, Jul 28, 2015 at 2:27 PM, Shawn Waldon wrote: > > +1 to the test recipe. > > > > On Tue, Jul 28, 2015 at 2:22 PM, David E DeMarle > > wrote: > >> > >> We've got years of layers of great but poorly described regression test > >> infrastructure in the code today that makes it harder than it could be to > >> make new tests. If this is yet another layer, I'm not in favor. > >> > >> But if this makes adding tests tractable for newbies and we put together > >> and post an easy but comprehensive recipe for adding tests along with this, > >> then I'm very much in favor. > >> > >> > >> > >> > >> David E DeMarle > >> Kitware, Inc. > >> R&D Engineer > >> 21 Corporate Drive > >> Clifton Park, NY 12065-8662 > >> Phone: 518-881-4909 > >> > >> On Tue, Jul 28, 2015 at 2:10 PM, Bill Lorensen > >> wrote: > >>> > >>> I have been adding unit tests lately using old school vtk testing. > >>> I'll be willing to kick the tires on David's framework. > >>> > >>> My goal in these unit tests to get as close as 100% coverage as > >>> possible, verifying results when possible. This includes exercising > >>> Error and Warning code and checking the messages themselves. > >>> > >>> I'll admit that I'm skeptical, but hopeful that adding a new test > >>> framework will increase code coverage. > >>> > >>> On Tue, Jul 28, 2015 at 1:34 PM, David Thompson > >>> wrote: > >>> > Hi David(s), > >>> > > >>> > I really like the single-header idea, especially the macros for testing > >>> > whether values match to within a tolerance. > >>> > > >>> > My concerns are > >>> > > >>> > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now > >>> > that we have ExternalData, provided?) access to baseline images doesn't seem > >>> > to fit into the FIXTURE macro. Is there a way to integrate it? Or a way to > >>> > extend the vtkTesting class to be more usable by including methods similar > >>> > to your macros? > >>> > > >>> > 2. One thing I dislike about most/all of the C++ test frameworks is > >>> > that the error messages are assumed to be fixed and the methods often do not > >>> > present a way to include the incorrect result as part of the failure > >>> > message. It is nice that your macros include that. However, given that tests > >>> > often fail on machines I don't have access to, it is really nice to > >>> > encourage people to write useful messages. Macros like CHECK_CLOSE would be > >>> > better if they accepted a message as a final argument, especially if the > >>> > argument was passed to a std::ostream object the way > >>> > vtkGenericWarningMacro() does so that people can (are forced to) provide > >>> > more context about where the two numbers being compared come from. > >>> > > >>> > David > >>> > > >>> >> On Jul 28, 2015, at 10:43 AM, David Gobbi > >>> >> wrote: > >>> >> > >>> >> Hi David (and David), > >>> >> > >>> >> The only advantage of my unit test header is that it is a single > >>> >> header > >>> >> (a short one, too) with zero dependencies. So it's easy to add to VTK > >>> >> and it's trivial to maintain. > >>> >> > >>> >> If either of you has a better solution, then go ahead and make a merge > >>> >> request. I'll review it for you ;) > >>> >> > >>> >> - David > >>> >> > >>> >> > >>> >> On Tue, Jul 28, 2015 at 8:27 AM, David Thompson > >>> >> wrote: > >>> >> Another project I work on has been using Bandit[1] to good effect. > >>> >> > >>> >> David > >>> >> > >>> >> [1]:http://banditcpp.org/reference.html > >>> >> > >>> >> On Jul 28, 2015, at 10:01 AM, David Cole via vtk-developers > >>> >> wrote: > >>> >> > >>> >> > A single header file unit testing solution sounds like a good thing. > >>> >> > > >>> >> > ... but ... seems like we could also take advantage of a > >>> >> > well-established generally used unit testing framework (like gtest > >>> >> > or > >>> >> > CppUnit) just as easily, and not clutter the VTK source with > >>> >> > yet-another-custom-thing-to-learn-about-VTKs-infrastructure. > >>> >> > > >>> >> > Would it be just as easy to add unit testing using an external unit > >>> >> > testing package? Or are there things about that scenario that are > >>> >> > overly complicated that having our own makes simpler...? > >>> >> > > >>> >> > > >>> >> > David C. > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Mon, Jul 27, 2015 at 5:25 PM, David Gobbi > >>> >> > wrote: > >>> >> >> Hi All, > >>> >> >> > >>> >> >> I've always enjoyed using the python unit testing framework in > >>> >> >> "vtk.test". > >>> >> >> It's been brought up on the list before, but it would be nice if > >>> >> >> VTK > >>> >> >> included a unit test framework for C++, as well. > >>> >> >> > >>> >> >> For my work projects, I've been using a unit test header that I > >>> >> >> wrote a year > >>> >> >> and a half ago: > >>> >> >> https://github.com/dgobbi/UnitTest/blob/master/UnitTest.h > >>> >> >> > >>> >> >> It's a single header file that provides a collection of macros for > >>> >> >> building > >>> >> >> unit tests, it's meant to be innocuous and easy to use. It could > >>> >> >> go into > >>> >> >> VTK as Testing/Core/vtkUnitTest.h and people could use it at their > >>> >> >> leisure. > >>> >> >> > >>> >> >> Any thoughts? > >>> >> >> > >>> >> >> - David > >>> >> > >>> >> > >>> > > >>> > _______________________________________________ > >>> > 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: > >>> > http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > > >>> > >>> > >>> > >>> -- > >>> Unpaid intern in BillsBasement at noware dot com > >>> _______________________________________________ > >>> Powered by www.kitware.com > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >> > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From mina.hrtn at gmail.com Tue Jul 28 15:02:20 2015 From: mina.hrtn at gmail.com (mina.hrtn at gmail.com) Date: Tue, 28 Jul 2015 14:02:20 -0500 Subject: [vtk-developers] mina.hrtn@gmail.com has indicated you're a friend. Accept? Message-ID: <0.0.1C.7C2.1D0C966EF869A42.2DE4@mail8.flipmailer.com> Hi, mina.hrtn at gmail.com wants to follow you. ****** Is mina.hrtn at gmail.com you friend? ****** If Yes please follow the link below: http://invites.flipmailer.com/signup_e.html?fullname=&email=vtk-developers at vtk.org&invitername=Mina.hrtn&inviterid=18718060&userid=0&token=0&emailmasterid=6b9fe4ca-ce76-49f3-9283-0f037a2571ad&from=mina.hrtn at gmail.com&template=invite_reg_b&test=AA&src=txt_yes If No please follow the link below: http://invites.flipmailer.com/signup_e.html?fullname=&email=vtk-developers at vtk.org&invitername=Mina.hrtn&inviterid=18718060&userid=0&token=0&emailmasterid=6b9fe4ca-ce76-49f3-9283-0f037a2571ad&from=mina.hrtn at gmail.com&template=invite_reg_b&test=AA&src=txt_no Follow the link below to remove yourself from all such emails http://invites.flipmailer.com/uns_inviter.jsp?email=vtk-developers at vtk.org&iid=6b9fe4ca-ce76-49f3-9283-0f037a2571ad&from=mina.hrtn at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Jul 28 18:20:25 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 28 Jul 2015 16:20:25 -0600 Subject: [vtk-developers] C++ unit tests In-Reply-To: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> References: <97841F40-39FD-46C5-9059-E7B3FDDC453B@kitware.com> Message-ID: On Tue, Jul 28, 2015 at 11:34 AM, David Thompson wrote: > Hi David(s), > > I really like the single-header idea, especially the macros for testing > whether values match to within a tolerance. > > My concerns are > > 1. The C++ Testing/Rendering/vtkTesting.h class which provides (or now > that we have ExternalData, provided?) access to baseline images doesn't > seem to fit into the FIXTURE macro. Is there a way to integrate it? Or a > way to extend the vtkTesting class to be more usable by including methods > similar to your macros? > The quick answer is, no, as it stands vtkTesting wouldn't fit into a UnitTest.h fixture. Your second suggestion sounds like the better approach: add unit test macros and their associated code to vtkTesting. I'm very fond of using macros, rather than methods, for the unit-test assertions because a macro can easily print out the line number in the test program where an assertion failed. > 2. One thing I dislike about most/all of the C++ test frameworks is that > the error messages are assumed to be fixed and the methods often do not > present a way to include the incorrect result as part of the failure > message. It is nice that your macros include that. However, given that > tests often fail on machines I don't have access to, it is really nice to > encourage people to write useful messages. Macros like CHECK_CLOSE would be > better if they accepted a message as a final argument, especially if the > argument was passed to a std::ostream object the way > vtkGenericWarningMacro() does so that people can (are forced to) provide > more context about where the two numbers being compared come from. > Something like that could be accommodated. I can see about putting together a merge request that makes vtkTesting more amenable to unit tests, rather than introducing yet another way of creating tests for VTK. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From vpindarico at gmail.com Wed Jul 29 06:37:11 2015 From: vpindarico at gmail.com (Pindarico Volo) Date: Wed, 29 Jul 2015 12:37:11 +0200 Subject: [vtk-developers] newbie presentation Message-ID: Hi all, let me introduce myself. I have developed a 3D scanning machine based on pattern projection and binocular acquisition and I have written for it a simple GUI with wxWidgets 3.0, used to set the parameters, start the acquisition sequence and save the point cloud as point-only PLY or XYZ. The GUI and the algorithmic software of the scanner work both with Windows (8.1, MSVC 13) and Linux (Ubuntu 14.04, g++ 4.8.4). I am also using some features of c++11. Now I would like to give my GUI some more functionalities; first of all, displaying and trimming the point cloud before saving it. After some googling, my choice fell onto VTK, due to its rich set of features and to the permissive license. So I downloaded the stable 6.2.0 version and had it built with no particular problem. Totally newbie! Have mercy! :) The problems begun with wxVTK which is not aligned with VTK 6.2.0, but at last I had it working and I know that there is a mailing list devoted to it (even if it doesn't look very alive :) ) so I won't bother you with wxVTK specific questions. Anyway I have a question about one of the wxVTK examples, I mean the vtkImagePlaneWidget example, which does not concern wxVTK but rather the migration to VTK 6. So it is a pure VTK question. Could somebody tell me if it is appropriate to ask it here? I also had a problem with one of the VTK examples, and namely the PLY reader (http://www.vtk.org/Wiki/VTK/Examples/Cxx/IO/ReadPLY). This example built well but cannot read point-only PLY files. After some googling, I reached this bug description: http://www.paraview.org/Bug/view.php?id=9741 containing a patch for vtkPLYReader.cxx The bug ticket dates back to 2009 and so my first question is: is there some good reason why it hasn't been integrated in the distribution, or it has just been forgotten? Anyway I tried and applied the patch, and discovered that, yes, point-only PLY files are now accepted, but not displayed. Trying to understand why, and comparing vtkPLYReader with vtkSimplePointsReader, I devised some more modification to vtkPLYReader and now I am able to display and interact with point-only clouds. In case it could be of interest, I attach here my version of vtkPLYReader.cxx. Of course, being a total newbie, I cannot guarantee that my modifications are correct and don't silently break something else. Best regards, Daniele Lugli aka Volo Pindarico (vpindarico at gmail dot com) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vtkPLYReader-modified.cxx Type: text/x-c++src Size: 13521 bytes Desc: not available URL: From casey.goodlett at kitware.com Wed Jul 29 09:33:01 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Wed, 29 Jul 2015 09:33:01 -0400 Subject: [vtk-developers] newbie presentation In-Reply-To: References: Message-ID: Welcome to VTK! The best process would be to follow the contribution guide[1] and submit your change for review. This will make it easier to review the changes and get integrated into the main distribution. Do you have a .ply that can be shared for testing along with the change? Ideally your contribution would include a test to verify the reader now correctly accepts this additional .ply file. [1] https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md -- Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jul 29 11:49:56 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jul 2015 11:49:56 -0400 Subject: [vtk-developers] [vtkusers] Announce: vtk 6.3.0 release candidate 1 is ready In-Reply-To: <715219225.4272341.1438099459231.JavaMail.yahoo@mail.yahoo.com> References: <20150724190754.GA29467@megas.kitware.com> <715219225.4272341.1438099459231.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150729154956.GA32199@megas.kitware.com> On Tue, Jul 28, 2015 at 16:04:19 +0000, Leonid Dulman wrote: > I tried to add FFMPEG support, but have got compilation errors > How to solve this problems ? Hrm. We test with VS9 (2008) and VS12 (2013), but not VS11. I guess there could be something wrong, but I think the problem is... > Error?? ?21?? ?error C1083: Cannot open include file: 'libavformat/avformat.h': No such file or directory?? ?F:\VTK630\IO\FFMPEG\vtkFFMPEGWriter.cxx?? ?27 ...you're missing FFmpeg (or haven't told VTK where it is). --Ben From sean at rogue-research.com Wed Jul 29 16:47:22 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 29 Jul 2015 16:47:22 -0400 Subject: [vtk-developers] Mailing list for buildbot status? In-Reply-To: References: Message-ID: <20150729204722.1491742899@mail.rogue-research.com> On Tue, 28 Jul 2015 11:19:16 -0400, Utkarsh Ayachit said: >I wonder if we need a spearate mailing list for providing information >about dashboard machine status. Currently, information about issues >with dashboard machines is not shared with the development teams. We >cannot simply use the vtk developers list since these machines are >often shared with other projects, like ParaView, VTM-M etc. Could you elaborate? You mean a list to discuss updates/problems with bots? What kinds of posts would be made to the list and by whom? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From utkarsh.ayachit at kitware.com Wed Jul 29 17:36:55 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 29 Jul 2015 17:36:55 -0400 Subject: [vtk-developers] Mailing list for buildbot status? In-Reply-To: <20150729204722.1491742899@mail.rogue-research.com> References: <20150729204722.1491742899@mail.rogue-research.com> Message-ID: > Could you elaborate? You mean a list to discuss updates/problems with bots? What kinds of posts would be made to the list and by whom? For example, tarvalon died yesterday due to power supply issues. That would be an email. Or some days Kargad just gets stuck and one has to manually restart it, but that's not after a few merge requests have failed on that machine. One could email saying Kargad was stuck and has been restarted so people can judge if the dashboard failures have been because of the machine or because of the merge request. Or simple things like if some developer is debugging code on some dashboard machine and has paused the dashboard, then he can email this list so people know not to expect builds from the paused machine. Utkarsh From mina.hrtn at gmail.com Wed Jul 29 18:02:35 2015 From: mina.hrtn at gmail.com (mina.hrtn at gmail.com) Date: Wed, 29 Jul 2015 17:02:35 -0500 Subject: [vtk-developers] You still haven't accepted mina.hrtn@gmail.com's friend request. Accept? Message-ID: <0.0.C4.790.1D0CA4A4677C068.1E98@mail1.fliporamail.com> An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Thu Jul 30 03:05:58 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Thu, 30 Jul 2015 09:05:58 +0200 Subject: [vtk-developers] Possible fix for vtkImageStencilData::InsertAndMergeExtent Message-ID: Hi, I'm in the process of migrating from 5.10.1 to 6.3 and have found a fix i had in vtkImageStencilData::InsertAndMergeExtent from one year ago. at the end of the method there is this loop: while (r1 < clist[insertIndex-1]) { clist[insertIndex] = clist[insertIndex-2]; clist[insertIndex+1] = clist[insertIndex-1]; insertIndex -= 2; } and i have this line added : if (insertIndex <= 1) break; with the comment: "avoid accessing out of range elements, which produces incorrect stencil that causes a random crash later when used in vtkImageStencilExecute" This random crash occured on Mac, never reproduced on Windows. I was wondering if by looking at the code you think it's a correct fix that can be merged. Thanks Xabi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Jul 30 08:09:47 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Jul 2015 08:09:47 -0400 Subject: [vtk-developers] Mailing list for buildbot status? In-Reply-To: References: <20150729204722.1491742899@mail.rogue-research.com> Message-ID: It seems this list is sufficient for such emails... I don't think anybody here would be bothered to receive emails about dashboard/buildbot status. Is there a reason not to use vtk-developers? David C. On Wednesday, July 29, 2015, Utkarsh Ayachit wrote: > > Could you elaborate? You mean a list to discuss updates/problems with > bots? What kinds of posts would be made to the list and by whom? > > For example, tarvalon died yesterday due to power supply issues. That > would be an email. Or some days Kargad just gets stuck and one has to > manually restart it, but that's not after a few merge requests have > failed on that machine. One could email saying Kargad was stuck and > has been restarted so people can judge if the dashboard failures have > been because of the machine or because of the merge request. > > Or simple things like if some developer is debugging code on some > dashboard machine and has paused the dashboard, then he can email this > list so people know not to expect builds from the paused machine. > > Utkarsh > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Jul 30 08:13:01 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Jul 2015 08:13:01 -0400 Subject: [vtk-developers] Mailing list for buildbot status? In-Reply-To: References: <20150729204722.1491742899@mail.rogue-research.com> Message-ID: Well, I just re-read your original post and now I know the reason... Other projects are also involved. However, I think this list (VTK dev) SHOULD be notified. Seems like the new list should be a "list of lists" with all the projects involved Cc'ed. D On Thursday, July 30, 2015, David Cole wrote: > It seems this list is sufficient for such emails... I don't think anybody > here would be bothered to receive emails about dashboard/buildbot status. > > Is there a reason not to use vtk-developers? > > > David C. > > > On Wednesday, July 29, 2015, Utkarsh Ayachit > wrote: > >> > Could you elaborate? You mean a list to discuss updates/problems with >> bots? What kinds of posts would be made to the list and by whom? >> >> For example, tarvalon died yesterday due to power supply issues. That >> would be an email. Or some days Kargad just gets stuck and one has to >> manually restart it, but that's not after a few merge requests have >> failed on that machine. One could email saying Kargad was stuck and >> has been restarted so people can judge if the dashboard failures have >> been because of the machine or because of the merge request. >> >> Or simple things like if some developer is debugging code on some >> dashboard machine and has paused the dashboard, then he can email this >> list so people know not to expect builds from the paused machine. >> >> Utkarsh >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Jul 30 09:37:57 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 30 Jul 2015 09:37:57 -0400 Subject: [vtk-developers] Mailing list for buildbot status? In-Reply-To: References: <20150729204722.1491742899@mail.rogue-research.com> Message-ID: <20150730133757.GB13778@megas.kitware.com> On Wed, Jul 29, 2015 at 17:36:55 -0400, Utkarsh Ayachit wrote: > Or simple things like if some developer is debugging code on some > dashboard machine and has paused the dashboard, then he can email this > list so people know not to expect builds from the paused machine. For this, there is now the "Pause Slave" button so that we can pause slaves and they'll show up as such on the web as well. Does require auth on the webpage, so let any of Utkarsh, Shawn, or me know and we can pause it. --Ben From utkarsh.ayachit at kitware.com Thu Jul 30 10:32:19 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 30 Jul 2015 10:32:19 -0400 Subject: [vtk-developers] Mailing list for buildbot status? In-Reply-To: <20150730133757.GB13778@megas.kitware.com> References: <20150729204722.1491742899@mail.rogue-research.com> <20150730133757.GB13778@megas.kitware.com> Message-ID: Maybe we just need a twitter feed for buildbot or something where such information can be shared. Mailing lists are bit heavy for such "tweets", so to speak. On Thu, Jul 30, 2015 at 9:37 AM, Ben Boeckel wrote: > On Wed, Jul 29, 2015 at 17:36:55 -0400, Utkarsh Ayachit wrote: > > Or simple things like if some developer is debugging code on some > > dashboard machine and has paused the dashboard, then he can email this > > list so people know not to expect builds from the paused machine. > > For this, there is now the "Pause Slave" button so that we can pause > slaves and they'll show up as such on the web as well. Does require auth > on the webpage, so let any of Utkarsh, Shawn, or me know and we can > pause it. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Jul 30 13:18:06 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 30 Jul 2015 11:18:06 -0600 Subject: [vtk-developers] Possible fix for vtkImageStencilData::InsertAndMergeExtent In-Reply-To: References: Message-ID: Hi Xabi, It doesn't look like the right fix, I suspect that the flaw in the logic is somewhere else in that method. Do you have any test code that I can use to reproduce the bug? - David On Thu, Jul 30, 2015 at 1:05 AM, Xabi Riobe wrote: > Hi, > > I'm in the process of migrating from 5.10.1 to 6.3 and have found a fix i > had in vtkImageStencilData::InsertAndMergeExtent from one year ago. > > at the end of the method there is this loop: > > while (r1 < clist[insertIndex-1]) > { > clist[insertIndex] = clist[insertIndex-2]; > clist[insertIndex+1] = clist[insertIndex-1]; > insertIndex -= 2; > } > > and i have this line added : if (insertIndex <= 1) break; > with the comment: "avoid accessing out of range elements, which produces > incorrect stencil that causes a random crash later when used in > vtkImageStencilExecute" > > This random crash occured on Mac, never reproduced on Windows. > > I was wondering if by looking at the code you think it's a correct fix > that can be merged. > > Thanks > > Xabi. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Fri Jul 31 04:30:29 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Fri, 31 Jul 2015 10:30:29 +0200 Subject: [vtk-developers] Possible fix for vtkImageStencilData::InsertAndMergeExtent In-Reply-To: References: Message-ID: Hi David, Thank you for your answer. For now i don't have a Mac to test anything, but i will try to do something on monday or tuesday. 2015-07-30 19:18 GMT+02:00 David Gobbi : > Hi Xabi, > > It doesn't look like the right fix, I suspect that the flaw in the logic > is somewhere else in that method. Do you have any test code that I can use > to reproduce the bug? > > - David > > > On Thu, Jul 30, 2015 at 1:05 AM, Xabi Riobe wrote: > >> Hi, >> >> I'm in the process of migrating from 5.10.1 to 6.3 and have found a fix i >> had in vtkImageStencilData::InsertAndMergeExtent from one year ago. >> >> at the end of the method there is this loop: >> >> while (r1 < clist[insertIndex-1]) >> { >> clist[insertIndex] = clist[insertIndex-2]; >> clist[insertIndex+1] = clist[insertIndex-1]; >> insertIndex -= 2; >> } >> >> and i have this line added : if (insertIndex <= 1) break; >> with the comment: "avoid accessing out of range elements, which produces >> incorrect stencil that causes a random crash later when used in >> vtkImageStencilExecute" >> >> This random crash occured on Mac, never reproduced on Windows. >> >> I was wondering if by looking at the code you think it's a correct fix >> that can be merged. >> >> Thanks >> >> Xabi. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mina.hrtn at gmail.com Fri Jul 31 15:30:50 2015 From: mina.hrtn at gmail.com (mina.hrtn at gmail.com) Date: Fri, 31 Jul 2015 14:30:50 -0500 Subject: [vtk-developers] Your friend mina.hrtn@gmail.com cannot see your photo Message-ID: <0.0.4.C36.1D0CBC7687CF420.3347@mail3.fliporamail.com> An HTML attachment was scrubbed... URL: From mina.hrtn at gmail.com Fri Jul 31 16:01:37 2015 From: mina.hrtn at gmail.com (mina.hrtn at gmail.com) Date: Fri, 31 Jul 2015 15:01:37 -0500 Subject: [vtk-developers] You have a new notification from mina.hrtn@gmail.com. View?? Message-ID: <0.0.1C.EF3.1D0CBCAB53199BC.2E05@mail1.flipmailer.com> Hi, mina.hrtn at gmail.com wants to follow you. ****** Is mina.hrtn at gmail.com you friend? ****** If Yes please follow the link below: http://invites.flipmailer.com/signup_e.html?fullname=&email=vtk-developers at vtk.org&invitername=Mina.hrtn&inviterid=18718060&userid=0&token=0&emailmasterid=4f215789-74e1-416d-b5d4-aa362a0032b2&from=mina.hrtn at gmail.com&template=invite_reminder_b&test=AA&src=txt_yes If No please follow the link below: http://invites.flipmailer.com/signup_e.html?fullname=&email=vtk-developers at vtk.org&invitername=Mina.hrtn&inviterid=18718060&userid=0&token=0&emailmasterid=4f215789-74e1-416d-b5d4-aa362a0032b2&from=mina.hrtn at gmail.com&template=invite_reminder_b&test=AA&src=txt_no Follow the link below to remove yourself from all such emails http://invites.flipmailer.com/uns_inviter.jsp?email=vtk-developers at vtk.org&iid=4f215789-74e1-416d-b5d4-aa362a0032b2&from=mina.hrtn at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Jul 17 11:48:33 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 17 Jul 2015 15:48:33 -0000 Subject: [vtk-developers] [Paraview] GPU volume rendering failure on Intel HD XXXX/Iris, Windows and recent drivers In-Reply-To: References: Message-ID: Hi Andras, Please find the patchs attached. If you run into issues let me know. I should mention that apply these patches at your discretion as I have not done enough testing to ensure the quality of the patches but the test passed last time I applied them. On Fri, Jul 17, 2015 at 11:40 AM, Andras Lasso wrote: > Please share the patch publicly, we would need it for some of our > projects, too. Thank you! > > > > Andras > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Simon ESNEAULT > *Sent:* Friday, July 17, 2015 11:35 AM > *To:* Aashish Chaudhary > *Cc:* VTK Developers; vtkusers at vtk.org; ParaView list > *Subject:* Re: [vtk-developers] [Paraview] GPU volume rendering failure > on Intel HD XXXX/Iris, Windows and recent drivers > > > > Dear Aashish, > > > > Thank you very much for you answer. > > Yes you are right, we are waiting for a new VTK release that defaults to > the new OpenGL2 backend, for safety and because a change of VTK version > requires a lot of extra work with our current framework... But the green > dashboard indeed looks really promising, and we will probably make the move > as soon as it's ready ! > > Meanwhile, I would be really glad if you could send me the patch that > solves this issue with the old backend, or guide me through the needed > modification to make it work. > > Thanks again > > Simon > > > > 2015-07-17 16:22 GMT+02:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > > Dear Simon, > > > > On Fri, Jul 17, 2015 at 4:43 AM, Simon ESNEAULT > wrote: > > Hi All, > > We're experiencing GPU volume rendering failure on a lot (maybe all ?) > Intel HD windows system with up to date drivers. > > > This is reproducible in Paraview or with the GPURenderDemo example from > VTK, just load a volume and try to render the volume... Here is a result > image from paraview on a Dell Latitude E7450 (Intel HD 5500 inside), with > GPU rendering [1] and the same volume with CPU VR rendering [2]. > Interestingly, the volume rendering used to work with drivers older or > equal to the version 10.18.10.3496 [3]. As a work around, we ask our > customers to downgrade their driver version to this one, and they're > enjoying smooth GPU rendering. But this driver is quite old and does not > support recent chipset... > > I've built and tested the GPURenderDemo with the brand new OpenGL2 backend > on an affected machine and of course it does work out of the box > (congratulations for this amazing work !). > > Great! > > > > But our application is FDA/CE marked and we need to wait that this new > backend is completely ready for prime time. So for now, we have to stick > with VTK 6.1 ... > > > > Most of the tests are passing for OpenGL2 ( > https://open.cdash.org/index.php?project=VTK) on most of the dashboards > (various configurations etc) but it is a moving target just like VTK itself > is a moving target. I guess you are waiting for a VTK release that defaults > to OpenGL2 as oppose to OpenGL? > > > Anyone has any clue ? They're some warning that pop up from paraview > related to the extension "gl_version_1_2" that could not be loaded, not > sure if that could be related ? Following this thread [4] and the fix > proposed, I've tried to replace > > /*****************/ > > extensions->LoadExtension("GL_VERSION_1_2") > > /*****************/ > > by > > /*****************/ > > extensions->LoadExtension("GL_EXT_texture3D"); > extensions->LoadExtension( "GL_ARB_texture_non_power_of_two" ); > > /*****************/ > > in the vtkOpenGLGPUVolumeRayCastMapper.cxx, The warning disappears but > there is still no volume rendering (tested with GPURenderDemo). Maybe it > needs some others extensions ? > > > > Yes, there is a patch and I can send it to you. I have to talk to folks > here if we can fix the old mapper with those changes but as of now it is > not in the plan. > > > > > Should I fill a bug in paraview, vtk ? Are there any plan to maintain and > maybe fix this for the old backend ? > > > > - Aashish > > > > > Thanks, > -- > > ------------------------------------------------------------------ > Simon Esneault > > Rennes, France > ------------------------------------------------------------------ > > > [1] http://picpaste.com/pics/Paraview-4-3-1-GPU-VR_fail.1437122217.PNG > > [2] http://picpaste.com/pics/Paraview-4-3-1-CPU-VR_win.1437122267.PNG > > [3] https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23339 > [4] http://public.kitware.com/pipermail/vtkusers/2014-April/083584.html > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Search the list archives at: http://markmail.org/search/?q=ParaView > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/paraview > > > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. > * > > *| http://www.kitware.com/company/team/chaudhary.html > * > > > > > > -- > > ------------------------------------------------------------------ > Simon Esneault > > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vtkOpenGLVolumeTextureMapper3D.cxx Type: text/x-c++src Size: 70251 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vtkgl.cxx Type: text/x-c++src Size: 573322 bytes Desc: not available URL: