From ken.martin at kitware.com Mon Aug 1 10:50:55 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 1 Aug 2016 10:50:55 -0400 Subject: [vtk-developers] Rendering hangs in viewport In-Reply-To: <579b67ca.0fcd190a.d06aa.cd6b@mx.google.com> References: <577b933d.98012e0a.c47e1.ffffaff2@mx.google.com> <20160705150232.2016783904@mail.rogue-research.com> <577be0e2.ca52190a.58dc5.14ec@mx.google.com> <577bf9b5.d5052e0a.d3d9a.ffffce07@mx.google.com> <579b67ca.0fcd190a.d06aa.cd6b@mx.google.com> Message-ID: I have a topic I'm working on to address this issue, but it is a non-trivial fix so it may take some discussion and time to get it nailed down. My topic is really just to show the basic approach and then I'll have to go and change all of VTK to use it assuming folks agree with it. https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 Ken On Fri, Jul 29, 2016 at 10:27 AM, Taras Shchehelskyi wrote: > Hello, > > > > Just want to check if there are some news about this issue. Maybe somebody > have idea how to fix this bug? > > > > Thanks, > > Taras > > > > > > *From: *Will Schroeder > *Sent: *5 ????? 2016 ?. 21:34 > *To: *Taras Shchehelskyi > *Cc: *vtk-developers > *Subject: *Re: [vtk-developers] Rendering hangs in viewport > > > > Okay we have a VTK hackathon tomorrow, I'll talk with some of the folks > there.... > > > > Best, > W > > > > On Tue, Jul 5, 2016 at 2:17 PM, Taras Shchehelskyi > wrote: > > I did. Out app work only in 64bit mode. I see that VTK really uses > vtkAtomicInt64 for GlobalTimeStamp. But what about next line > > *this->ModifiedTime = (unsigned long)++GlobalTimeStamp;* (in > vtkTimeStamp::Modified()) > > > > Also I checked and everywhere in code timestamp is unsigned long. In > windows x64 unsigned long is 32bit type. So despite 64bit vtkAtomicInt64 we > still have conversion to unsigned long. > > > > Thanks, > > Taras > > > > > > *From: *Will Schroeder > *Sent: *5 ????? 2016 ?. 21:00 > *To: *Taras Shchehelskyi > > > *Subject: *Re: [vtk-developers] Rendering hangs in viewport > > > > Taras why aren't you building 64-bit? That's the easiest solution... > > > > On Tue, Jul 5, 2016 at 1:53 PM, Will Schroeder > wrote: > > Okay Taras, I talked to someone smarter than me and it may be that some > versions of Windows support vtkAtomicInt64 ..... and at one point there > were some versions that did not, I'm not sure what the current status is. > So for a simple fix I would try using vtkAtomicInt64 on your machine and > recompiling. If that doesn't work we'll have to scratch our heads a little > more. > > > > > > On Tue, Jul 5, 2016 at 12:31 PM, Taras Shchehelskyi < > shchegelskij at gmail.com> wrote: > > Hello, > > > > Just checked. Our app does enough vtkTimeStamp::Modified() calls to > wrapping 32 bit unsigned long in about 15-20h (depending on how many > other processes I have on my PC). When enable more features ? less time > necessary. > > > > I am new to VTK. Can you please give me advice how hard (how many changes > necessary) to move this->ModifiedTime to int64 type in windows? > > > > If move to int64 type, from my rough estimate app should work fine for > 400000+ years. And this more than enough for any use case ? > > > > Thanks, > > Taras > > > > *From: *Sean McBride > *Sent: *5 ????? 2016 ?. 18:02 > *To: *Will Schroeder ; Mathieu Malaterre > > *Cc: *vtk-developers at vtk.org > *Subject: *Re: [vtk-developers] Rendering hangs in viewport > > > > On Tue, 5 Jul 2016 08:16:46 -0400, Will Schroeder said: > > > > >I like this theory! It's hard to imagine an unsigned long wrapping around, > > > > Not on Windows, where unsigned long is only 32 bits. :( > > > > 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 > > > > > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > > > _______________________________________________ > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 shchegelskij at gmail.com Mon Aug 1 11:04:02 2016 From: shchegelskij at gmail.com (Taras Shchehelskyi) Date: Mon, 1 Aug 2016 18:04:02 +0300 Subject: [vtk-developers] Rendering hangs in viewport In-Reply-To: References: <577b933d.98012e0a.c47e1.ffffaff2@mx.google.com> <20160705150232.2016783904@mail.rogue-research.com> <577be0e2.ca52190a.58dc5.14ec@mx.google.com> <577bf9b5.d5052e0a.d3d9a.ffffce07@mx.google.com> <579b67ca.0fcd190a.d06aa.cd6b@mx.google.com> Message-ID: Hello, Thank you for reply. Great to hear that this issue is in progress. Thanks, Taras 1 ????. 2016 17:50 "Ken Martin" ????: I have a topic I'm working on to address this issue, but it is a non-trivial fix so it may take some discussion and time to get it nailed down. My topic is really just to show the basic approach and then I'll have to go and change all of VTK to use it assuming folks agree with it. https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 Ken On Fri, Jul 29, 2016 at 10:27 AM, Taras Shchehelskyi wrote: > Hello, > > > > Just want to check if there are some news about this issue. Maybe somebody > have idea how to fix this bug? > > > > Thanks, > > Taras > > > > > > *From: *Will Schroeder > *Sent: *5 ????? 2016 ?. 21:34 > *To: *Taras Shchehelskyi > *Cc: *vtk-developers > *Subject: *Re: [vtk-developers] Rendering hangs in viewport > > > > Okay we have a VTK hackathon tomorrow, I'll talk with some of the folks > there.... > > > > Best, > W > > > > On Tue, Jul 5, 2016 at 2:17 PM, Taras Shchehelskyi > wrote: > > I did. Out app work only in 64bit mode. I see that VTK really uses > vtkAtomicInt64 for GlobalTimeStamp. But what about next line > > *this->ModifiedTime = (unsigned long)++GlobalTimeStamp;* (in > vtkTimeStamp::Modified()) > > > > Also I checked and everywhere in code timestamp is unsigned long. In > windows x64 unsigned long is 32bit type. So despite 64bit vtkAtomicInt64 we > still have conversion to unsigned long. > > > > Thanks, > > Taras > > > > > > *From: *Will Schroeder > *Sent: *5 ????? 2016 ?. 21:00 > *To: *Taras Shchehelskyi > > > *Subject: *Re: [vtk-developers] Rendering hangs in viewport > > > > Taras why aren't you building 64-bit? That's the easiest solution... > > > > On Tue, Jul 5, 2016 at 1:53 PM, Will Schroeder > wrote: > > Okay Taras, I talked to someone smarter than me and it may be that some > versions of Windows support vtkAtomicInt64 ..... and at one point there > were some versions that did not, I'm not sure what the current status is. > So for a simple fix I would try using vtkAtomicInt64 on your machine and > recompiling. If that doesn't work we'll have to scratch our heads a little > more. > > > > > > On Tue, Jul 5, 2016 at 12:31 PM, Taras Shchehelskyi < > shchegelskij at gmail.com> wrote: > > Hello, > > > > Just checked. Our app does enough vtkTimeStamp::Modified() calls to > wrapping 32 bit unsigned long in about 15-20h (depending on how many > other processes I have on my PC). When enable more features ? less time > necessary. > > > > I am new to VTK. Can you please give me advice how hard (how many changes > necessary) to move this->ModifiedTime to int64 type in windows? > > > > If move to int64 type, from my rough estimate app should work fine for > 400000+ years. And this more than enough for any use case ? > > > > Thanks, > > Taras > > > > *From: *Sean McBride > *Sent: *5 ????? 2016 ?. 18:02 > *To: *Will Schroeder ; Mathieu Malaterre > > *Cc: *vtk-developers at vtk.org > *Subject: *Re: [vtk-developers] Rendering hangs in viewport > > > > On Tue, 5 Jul 2016 08:16:46 -0400, Will Schroeder said: > > > > >I like this theory! It's hard to imagine an unsigned long wrapping around, > > > > Not on Windows, where unsigned long is only 32 bits. :( > > > > 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 > > > > > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > > > _______________________________________________ > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 Mon Aug 1 12:49:34 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 1 Aug 2016 12:49:34 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime Message-ID: I am looking for some feedback here. We have a problem in VTK that on Windows unsigned long GetMTime is limited to 32 bits due to the type of unsigned long (even on 64 bit builds). This problem creeps up for any VTK application that runs for a long time (say 4 hours or more depending on what the application is doing). I feel like we need to fix this but from what I can see there is no trivially easy fix. Changing the signature of GetMTime would break external code that overrides GetMTime. So my thought is to add a new method called GetModifiedTime that returns a 64 bit unsigned int. Convert VTK to use this method and provide backwards compatibility support for external code to still compile/link/and work. I have created a sample topic here https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 that shows the basic idea. In that topic I have not converted over all the other GetMTime calls in the VTK tree which I would want to do, rather it is just a topic to show the idea behind the change. I believe it handles the common cases properly with only one failure case I know of so far (documented in the comments for that topic). If we went with such a change I believe existing code would still work unchanged (aside from a warning) This change would allow external code to have both GetMTime and GetModifiedTime so that the external code would work with both old and new versions of VTK. This change will cause some performance issues if VTK_LEGACY_GETMTIME is left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost but require external codes to be updated to GetModifiedTime. It would be nice if I was missing some easy pain free solution here so please holler if you see something, have thoughts, etc. Thanks Ken -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 julien.finet at kitware.com Tue Aug 2 04:55:18 2016 From: julien.finet at kitware.com (Julien Finet) Date: Tue, 2 Aug 2016 10:55:18 +0200 Subject: [vtk-developers] Are mappers Update()'d before actors are rendered ? Message-ID: Hi David and all, According to your comment in vtkImageActor::HasTranslucentPolygonalGeometry(), mappers are updated before their actors are rendered. It does not seem to be the case in my workflow. Where is this Update() supposed to happen ? My problem is that when vtkImageSlice::RenderOpaqueGeometry() is called the first time, the mapper has never been updated, the image data has no scalars array, and vtkImageSlice::Render() is called within vtkImageSlice::RenderOpaqueGeometry(). It updates the mapper, so next time RenderTranslucentPolygonalGeometry() is called, Render() is called a second time (because this time I have a scalars array). Did I miss something ? Please note that I'm using a custom vtkFollower with my image actor. Thanks, Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Tue Aug 2 05:08:51 2016 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 2 Aug 2016 11:08:51 +0200 Subject: [vtk-developers] Changing include directories order Message-ID: Hi All On an unrelated topic on paraview-dev ml, we found the VTK module include directories are added after all other directories, and that can causes problems in some cases. Please feel free to review this MR that fix the problem by using BEFORE options in moduleMacros.cmake. https://gitlab.kitware.com/vtk/vtk/merge_requests/1763 Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Aug 2 11:35:31 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 2 Aug 2016 11:35:31 -0400 Subject: [vtk-developers] Deadline Extended: SC16 Visualization Showcase submission deadline - August 15, 2016 Message-ID: Due to multiple requests, we have extended the deadline to August 15, 2016Visualization Showcase ------------------------------ Important Dates: February 16, 2016: *Submissions open* August 15, 2016: *Submissions deadline* September 1, 2016: *Notifications sent* ------------------------------ *A new format for 2016!* SC16?s Visualization and Data Analytics Showcase Program provides a forum for the year?s most instrumental movies in HPC. This year, there will be both a live display throughout the conference so that attendees can experience and enjoy the latest in science and engineering HPC results expressed through state-of-the-art visualization technologies, and a session at SC16 dedicated to the best of the submissions. Selected entries will be displayed live in a museum/art gallery format and six finalists will compete for the Best Visualization Award, with each finalist presenting his or her movie 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. The six finalist submissions will appear as short papers on the SC16 webpage and archive. *Review and selection process:* Submissions need to include a movie (up to 250MB in size) and a short paper (up to 4 pages including references). The short paper should describe the scientific story conveyed by the movie, how the visualization helps scientific discovery, and the ?state-of-the-practice? information ( ieeevis.org)information behind making the movie. Each submission will be peer reviewed by the Visualization and Data Analytics Showcase Committee. Criteria for review include: - How effective is the visual communication of the data? - How relevant to the HPC community is the visualization? - What is the impact of the science story and how well is it told? - What visualization techniques were necessary to create the movie? Finally, submissions should support SC16?s overall theme ?HPC matters.? http://sc16.supercomputing.org/submitters/showcases/scientific-visualization-showcase/ *Web Submissions:* https://submissions.supercomputing.org/ *Email Contact:* vis_showcase at info.supercomputing.org SC16 Visualization Showcase Chair Chris Johnson, University of Utah SC16 Visualization Showcase Vice Chair Kristin Potter, University of Oregon -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Aug 2 14:05:01 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 2 Aug 2016 12:05:01 -0600 Subject: [vtk-developers] Are mappers Update()'d before actors are rendered ? In-Reply-To: References: Message-ID: Hi Julien, The comment in the code is currently just wishful thinking. HasTranslucentPolygonalGeometry() is called before vtkImageSlice::Render(), which is where the mapper gets updated. It's possible that before the VTK 6 pipeline changes, there was an UpdateInformation call that updated the info that HasTranslucentPolygonalGeometry() needs. But I'm not 100% sure. IHMO the "Translucency" flag is something that should be set by the app developer, rather than something that VTK tries to figure out on its own. Translucency of vtkImageActor has been problematic in one way or another ever since the class was introduced. If you submit a bug report and assign it to me, then I'll look into this and see if there is a reasonable fix that maintains backwards compatibility. For now, one way to avoid this issue is to use vtkImageSliceMapper and vtkImageSlice, instead of using vtkImageActor. The vtkImageSlice::HasTranslucentPolygonalGeometry() method doesn't try to access the image data. - David On Tue, Aug 2, 2016 at 2:55 AM, Julien Finet wrote: > Hi David and all, > > According to your comment in > vtkImageActor::HasTranslucentPolygonalGeometry(), > mappers are updated before their actors are rendered. > > It does not seem to be the case in my workflow. Where is this Update() > supposed to happen ? > > My problem is that when vtkImageSlice::RenderOpaqueGeometry() is called > the first time, the mapper has never been updated, the image data has no > scalars array, and vtkImageSlice::Render() is called within > vtkImageSlice::RenderOpaqueGeometry(). It updates the mapper, so next time > RenderTranslucentPolygonalGeometry() is called, Render() is called a second > time (because this time I have a scalars array). > > Did I miss something ? Please note that I'm using a custom vtkFollower > with my image actor. > > Thanks, > Julien. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Wed Aug 3 11:41:12 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 3 Aug 2016 11:41:12 -0400 Subject: [vtk-developers] Test failures on megas Message-ID: Hi all, Has any one looked into the test failures on megas lately? There are six tests failing on master (the only continuous build failures right now). Are these real failures or do they need to be excluded? I don't know enough about those parts of VTK to tell, though I suspect several are real errors. Thanks, Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Aug 3 12:10:57 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 3 Aug 2016 12:10:57 -0400 Subject: [vtk-developers] Test failures on megas In-Reply-To: References: Message-ID: The last message I have is below. I recall something about floating point textures not working or a bug in Mesa, unless something has changed I think there are still a lot of tests suppressed currently -- Ken ------ old message follows Feel free to ask Ben to suppress that test on megas, they are already suppressing like 30 tests on that system. - Ken On Fri, Apr 15, 2016 at 10:04 AM, David Lonie wrote: > On Thu, Apr 14, 2016 at 7:30 PM, Ken Martin > wrote: > >> I'm guessing you are past this issue, if not let me know. WRT shader4 >> mesa does not and probably never will support that extension. We only need >> it when the OpenGL version is 2.1 and for mesa we really require a mesa >> that is compatible with 3.2. If someone wants to use a mesa that is not 3.2 >> compatible I believe they are on their own as it is easy to download mesa >> and build a working llvmpipe version (or even SWR) that we know works well >> with VTK. >> > > Sounds good, I'll let megas fail until its mesa is updated. > > The issue I was having looks like a bug in upstream mesa. Brad tracked > this down: > > $ ls mesa-master-install/lib/libMesaGL.so* -lh > > mesa-master-install/lib/libMesaGL.so -> libMesaGL.so.1.5.0 > > mesa-master-install/lib/libMesaGL.so.1 -> libMesaGL.so.1.6.0 > mesa-master-install/lib/libMesaGL.so.1.5.0 > mesa-master-install/lib/libMesaGL.so.1.6.0 > > The build produces libGL with two different versions, and the linker / > loader weren't consistently using the same one. The solution was to run > 'make install-data' in the top level, and 'make install-exec' in > src/gallium so that only one would generated. > > Excellent news about apitrace, that will make this much easier. Thanks for > the info! I'll submit a bug report today. > > On Wed, Aug 3, 2016 at 11:41 AM, Shawn Waldon wrote: > Hi all, > > Has any one looked into the test failures on megas lately? There are six > tests failing on master (the only continuous build failures right now). > Are these real failures or do they need to be excluded? I don't know > enough about those parts of VTK to tell, though I suspect several are real > errors. > > Thanks, > Shawn > > _______________________________________________ > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 berk.geveci at kitware.com Wed Aug 3 14:58:01 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 3 Aug 2016 14:58:01 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: Message-ID: Wouldn't it be better to just change the signature of GetMTime() to return a 64 bit int? Only subclasses would fail to compile. They should be very easy to fix. Any user of the GetMTime() method would cause a warning that can be safely ignored by the users of VTK. My personal preference would be to do that than to cause all users to switch to a new method (over time). Not a strong preference though. On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin wrote: > > I am looking for some feedback here. We have a problem in VTK that on > Windows unsigned long GetMTime is limited to 32 bits due to the type of > unsigned long (even on 64 bit builds). This problem creeps up for any VTK > application that runs for a long time (say 4 hours or more depending on > what the application is doing). I feel like we need to fix this but from > what I can see there is no trivially easy fix. Changing the signature of > GetMTime would break external code that overrides GetMTime. So my thought > is to add a new method called GetModifiedTime that returns a 64 bit > unsigned int. Convert VTK to use this method and provide backwards > compatibility support for external code to still compile/link/and work. > > I have created a sample topic here > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 that shows the > basic idea. In that topic I have not converted over all the other GetMTime > calls in the VTK tree which I would want to do, rather it is just a topic > to show the idea behind the change. I believe it handles the common cases > properly with only one failure case I know of so far (documented in the > comments for that topic). > > If we went with such a change I believe existing code would still work > unchanged (aside from a warning) > > This change would allow external code to have both GetMTime and > GetModifiedTime so that the external code would work with both old and new > versions of VTK. > > This change will cause some performance issues if VTK_LEGACY_GETMTIME is > left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost > but require external codes to be updated to GetModifiedTime. > > It would be nice if I was missing some easy pain free solution here so > please holler if you see something, have thoughts, etc. > > Thanks > Ken > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Aug 3 20:13:28 2016 From: DLRdave at aol.com (David Cole) Date: Wed, 3 Aug 2016 20:13:28 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: Message-ID: I agree with Berk: personally, I would prefer a simple change to the signature of GetMTime. Dealing with a documented method signature change when upgrading to a new version of VTK is less annoying than learning a new method name, even a similar one, and partially invalidating years of mailing list discussions about GetMTime (by changing its name)... Again: not a strong preference, though, and will GLADLY use whatever is put into VTK. We have an app that can hit the overflow condition within about 45 minutes when running at full speed, and having a solution where we don't have to have a heavily patched VTK will be awesome. Thanks, Ken, for working on this. David C. On Wednesday, August 3, 2016, Berk Geveci wrote: > Wouldn't it be better to just change the signature of GetMTime() to return > a 64 bit int? Only subclasses would fail to compile. They should be very > easy to fix. Any user of the GetMTime() method would cause a warning that > can be safely ignored by the users of VTK. My personal preference would be > to do that than to cause all users to switch to a new method (over time). > Not a strong preference though. > > On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin > wrote: > >> >> I am looking for some feedback here. We have a problem in VTK that on >> Windows unsigned long GetMTime is limited to 32 bits due to the type of >> unsigned long (even on 64 bit builds). This problem creeps up for any VTK >> application that runs for a long time (say 4 hours or more depending on >> what the application is doing). I feel like we need to fix this but from >> what I can see there is no trivially easy fix. Changing the signature of >> GetMTime would break external code that overrides GetMTime. So my thought >> is to add a new method called GetModifiedTime that returns a 64 bit >> unsigned int. Convert VTK to use this method and provide backwards >> compatibility support for external code to still compile/link/and work. >> >> I have created a sample topic here >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 that shows the >> basic idea. In that topic I have not converted over all the other GetMTime >> calls in the VTK tree which I would want to do, rather it is just a topic >> to show the idea behind the change. I believe it handles the common cases >> properly with only one failure case I know of so far (documented in the >> comments for that topic). >> >> If we went with such a change I believe existing code would still work >> unchanged (aside from a warning) >> >> This change would allow external code to have both GetMTime and >> GetModifiedTime so that the external code would work with both old and new >> versions of VTK. >> >> This change will cause some performance issues if VTK_LEGACY_GETMTIME is >> left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost >> but require external codes to be updated to GetModifiedTime. >> >> It would be nice if I was missing some easy pain free solution here so >> please holler if you see something, have thoughts, etc. >> >> Thanks >> Ken >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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 >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Aug 4 08:00:08 2016 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 4 Aug 2016 08:00:08 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: Message-ID: I tend to like that simpler solution as well. The change is easy to explain, the compiler identifies the issues, and fixing them is easy. Should the user want to support multiple versions of VTK on Windows (the change is a noop on Linux OSX IIRC), an ifdef can be used in the places where they override GetMTime to provide the old signature. Ken On Wed, Aug 3, 2016 at 8:13 PM, David Cole wrote: > I agree with Berk: personally, I would prefer a simple change to the > signature of GetMTime. Dealing with a documented method signature change > when upgrading to a new version of VTK is less annoying than learning a new > method name, even a similar one, and partially invalidating years of > mailing list discussions about GetMTime (by changing its name)... > > Again: not a strong preference, though, and will GLADLY use whatever is > put into VTK. We have an app that can hit the overflow condition within > about 45 minutes when running at full speed, and having a solution where we > don't have to have a heavily patched VTK will be awesome. > > Thanks, Ken, for working on this. > > > David C. > > > > > On Wednesday, August 3, 2016, Berk Geveci wrote: > >> Wouldn't it be better to just change the signature of GetMTime() to >> return a 64 bit int? Only subclasses would fail to compile. They should be >> very easy to fix. Any user of the GetMTime() method would cause a warning >> that can be safely ignored by the users of VTK. My personal preference >> would be to do that than to cause all users to switch to a new method (over >> time). Not a strong preference though. >> >> On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin >> wrote: >> >>> >>> I am looking for some feedback here. We have a problem in VTK that on >>> Windows unsigned long GetMTime is limited to 32 bits due to the type of >>> unsigned long (even on 64 bit builds). This problem creeps up for any VTK >>> application that runs for a long time (say 4 hours or more depending on >>> what the application is doing). I feel like we need to fix this but from >>> what I can see there is no trivially easy fix. Changing the signature of >>> GetMTime would break external code that overrides GetMTime. So my thought >>> is to add a new method called GetModifiedTime that returns a 64 bit >>> unsigned int. Convert VTK to use this method and provide backwards >>> compatibility support for external code to still compile/link/and work. >>> >>> I have created a sample topic here https://gitlab.kitware. >>> com/vtk/vtk/merge_requests/1724 that shows the basic idea. In that >>> topic I have not converted over all the other GetMTime calls in the VTK >>> tree which I would want to do, rather it is just a topic to show the idea >>> behind the change. I believe it handles the common cases properly with only >>> one failure case I know of so far (documented in the comments for that >>> topic). >>> >>> If we went with such a change I believe existing code would still work >>> unchanged (aside from a warning) >>> >>> This change would allow external code to have both GetMTime and >>> GetModifiedTime so that the external code would work with both old and new >>> versions of VTK. >>> >>> This change will cause some performance issues if VTK_LEGACY_GETMTIME is >>> left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost >>> but require external codes to be updated to GetModifiedTime. >>> >>> It would be nice if I was missing some easy pain free solution here so >>> please holler if you see something, have thoughts, etc. >>> >>> Thanks >>> Ken >>> >>> >>> -- >>> Ken Martin PhD >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 >>> >>> 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 >>> >>> >>> >> -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 DLRdave at aol.com Thu Aug 4 10:32:23 2016 From: DLRdave at aol.com (David Cole) Date: Thu, 4 Aug 2016 10:32:23 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: Message-ID: A nice-to-the-user-who-needs-that capability would be to typedef a type for the return value of GetMTime, and then allow for user definition of that type. Default to uint64_t, but allow for user definition. David C. On Thu, Aug 4, 2016 at 8:00 AM, Ken Martin wrote: > I tend to like that simpler solution as well. The change is easy to > explain, the compiler identifies the issues, and fixing them is easy. > Should the user want to support multiple versions of VTK on Windows (the > change is a noop on Linux OSX IIRC), an ifdef can be used in the places > where they override GetMTime to provide the old signature. > > Ken > > > On Wed, Aug 3, 2016 at 8:13 PM, David Cole wrote: >> >> I agree with Berk: personally, I would prefer a simple change to the >> signature of GetMTime. Dealing with a documented method signature change >> when upgrading to a new version of VTK is less annoying than learning a new >> method name, even a similar one, and partially invalidating years of mailing >> list discussions about GetMTime (by changing its name)... >> >> Again: not a strong preference, though, and will GLADLY use whatever is >> put into VTK. We have an app that can hit the overflow condition within >> about 45 minutes when running at full speed, and having a solution where we >> don't have to have a heavily patched VTK will be awesome. >> >> Thanks, Ken, for working on this. >> >> >> David C. >> >> >> >> >> On Wednesday, August 3, 2016, Berk Geveci wrote: >>> >>> Wouldn't it be better to just change the signature of GetMTime() to >>> return a 64 bit int? Only subclasses would fail to compile. They should be >>> very easy to fix. Any user of the GetMTime() method would cause a warning >>> that can be safely ignored by the users of VTK. My personal preference would >>> be to do that than to cause all users to switch to a new method (over time). >>> Not a strong preference though. >>> >>> On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin >>> wrote: >>>> >>>> >>>> I am looking for some feedback here. We have a problem in VTK that on >>>> Windows unsigned long GetMTime is limited to 32 bits due to the type of >>>> unsigned long (even on 64 bit builds). This problem creeps up for any VTK >>>> application that runs for a long time (say 4 hours or more depending on what >>>> the application is doing). I feel like we need to fix this but from what I >>>> can see there is no trivially easy fix. Changing the signature of GetMTime >>>> would break external code that overrides GetMTime. So my thought is to add a >>>> new method called GetModifiedTime that returns a 64 bit unsigned int. >>>> Convert VTK to use this method and provide backwards compatibility support >>>> for external code to still compile/link/and work. >>>> >>>> I have created a sample topic here >>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 that shows the basic >>>> idea. In that topic I have not converted over all the other GetMTime calls >>>> in the VTK tree which I would want to do, rather it is just a topic to show >>>> the idea behind the change. I believe it handles the common cases properly >>>> with only one failure case I know of so far (documented in the comments for >>>> that topic). >>>> >>>> If we went with such a change I believe existing code would still work >>>> unchanged (aside from a warning) >>>> >>>> This change would allow external code to have both GetMTime and >>>> GetModifiedTime so that the external code would work with both old and new >>>> versions of VTK. >>>> >>>> This change will cause some performance issues if VTK_LEGACY_GETMTIME is >>>> left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost >>>> but require external codes to be updated to GetModifiedTime. >>>> >>>> It would be nice if I was missing some easy pain free solution here so >>>> please holler if you see something, have thoughts, etc. >>>> >>>> Thanks >>>> Ken >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Chairman & CFO >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Clifton Park NY 12065 >>>> 518 371 3971 >>>> >>>> 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 >>>> >>>> >>> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 sean at rogue-research.com Thu Aug 4 11:27:35 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 4 Aug 2016 11:27:35 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: Message-ID: <20160804152735.578746537@mail.rogue-research.com> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: >A nice-to-the-user-who-needs-that capability would be to typedef a >type for the return value of GetMTime, and then allow for user >definition of that type. Default to uint64_t, but allow for user >definition. Was just going to suggest that. It could be typedefed to exactly what it is today, giving full source compatibility; and then if you build with VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. 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 DLRdave at aol.com Thu Aug 4 12:53:37 2016 From: DLRdave at aol.com (David Cole) Date: Thu, 4 Aug 2016 12:53:37 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <20160804152735.578746537@mail.rogue-research.com> References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: Except.... I think fixing the overflow bug on Windows is more important than full source compatibility. A default build (no need to set anything in CMake) of the new version of VTK on Windows with this capability should result in 64-bit MTime values and avoid the overflow condition. I prefer correctness to full/100% backwards compatibility. On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride wrote: > On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: > >>A nice-to-the-user-who-needs-that capability would be to typedef a >>type for the return value of GetMTime, and then allow for user >>definition of that type. Default to uint64_t, but allow for user >>definition. > > Was just going to suggest that. It could be typedefed to exactly what it is today, giving full source compatibility; and then if you build with VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. > > 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 robert.maynard at kitware.com Thu Aug 4 13:28:32 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 4 Aug 2016 13:28:32 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: I agree with David. I prefer correctness to full backwards compatibility, especially so with something like consistently having 64bit MTimes on all platforms. Personally I don't see the value in having the return type as a typedef compared to having the caller do a static cast ( which is what MTime would have to do internally ). On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers wrote: > Except.... I think fixing the overflow bug on Windows is more > important than full source compatibility. A default build (no need to > set anything in CMake) of the new version of VTK on Windows with this > capability should result in 64-bit MTime values and avoid the overflow > condition. > > I prefer correctness to full/100% backwards compatibility. > > > > > On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride wrote: >> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: >> >>>A nice-to-the-user-who-needs-that capability would be to typedef a >>>type for the return value of GetMTime, and then allow for user >>>definition of that type. Default to uint64_t, but allow for user >>>definition. >> >> Was just going to suggest that. It could be typedefed to exactly what it is today, giving full source compatibility; and then if you build with VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. >> >> 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 > From seun at rogue-research.com Thu Aug 4 15:21:31 2016 From: seun at rogue-research.com (Seun Odutola) Date: Thu, 4 Aug 2016 15:21:31 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. Message-ID: Hello everyone, I have a crash that occurs in my application when running vtk with the GL2 rendered enabled but not with GL1. So here is the situation, in my program when I change the shape of my poly data mapper, basically setting the mapper of an actor in my scene to a new poly data mapper it results in a crash. The crash is situated in vtkOpenGLBufferObject?s destructor, specifically the deletion of the Internal?s handle. I have tried to verify if the handle is valid prior to reaching the destructor which it seems to be, my main concern is if the handle is filled with garbage (a non-zero value) it might effectively pass the test condition and try to invoke glDeleteBuffer. Has anyone experienced anything similar to this? Regards, Seun -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Aug 5 11:57:25 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Aug 2016 11:57:25 -0400 Subject: [vtk-developers] vtkExodusIIWriter memory leak Message-ID: Folks, vtkExodusIIWriter has been leaking for awhile. https://open.cdash.org/viewDynamicAnalysisFile.php?id=4009906 Bill From bill.lorensen at gmail.com Fri Aug 5 11:59:03 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Aug 2016 11:59:03 -0400 Subject: [vtk-developers] vtkGDALRasterReader memory leak Message-ID: vtkGDALRasterReader has been leaking for awhile. https://open.cdash.org/viewDynamicAnalysisFile.php?id=4009905 Bill From bill.lorensen at gmail.com Fri Aug 5 15:45:48 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Aug 2016 15:45:48 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: Why not in vtkType.h #if defined(WIN32) typedef vtkTypeUInt64 vtkTypeMTime; #else typedef unsigned long vtkTypeMTime; #endif In vtkObject.h and other GetMTimes' virtual vtkTypeMTime GetMTime(); Windows apps will have to change their GetMTimes' in their VTK derived subclasses. On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard wrote: > I agree with David. I prefer correctness to full backwards > compatibility, especially so with something like consistently having > 64bit MTimes on all platforms. > > Personally I don't see the value in having the return type as a > typedef compared to having the caller do a static cast ( which is what > MTime would have to do internally ). > > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers > wrote: >> Except.... I think fixing the overflow bug on Windows is more >> important than full source compatibility. A default build (no need to >> set anything in CMake) of the new version of VTK on Windows with this >> capability should result in 64-bit MTime values and avoid the overflow >> condition. >> >> I prefer correctness to full/100% backwards compatibility. >> >> >> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride wrote: >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: >>> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a >>>>type for the return value of GetMTime, and then allow for user >>>>definition of that type. Default to uint64_t, but allow for user >>>>definition. >>> >>> Was just going to suggest that. It could be typedefed to exactly what it is today, giving full source compatibility; and then if you build with VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. >>> >>> 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 >> > _______________________________________________ > 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 Fri Aug 5 15:52:44 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Aug 2016 15:52:44 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> On 08/05/16 15:45, Bill Lorensen wrote: > Why not in vtkType.h > #if defined(WIN32) > typedef vtkTypeUInt64 vtkTypeMTime; > #else > typedef unsigned long vtkTypeMTime; > #endif > > In vtkObject.h and other GetMTimes' > virtual vtkTypeMTime GetMTime(); > > Windows apps will have to change their GetMTimes' in their VTK derived > subclasses. With a trivial re-ordering in `Common/Core/vtkType.h` to prefer `long` over `long long` when the former is 64-bit then `vtkTypeUInt64` will be selected as above automatically and can serve this role without a separate typedef. This would make vtkType.h more consistent anyway. -Brad From bill.lorensen at gmail.com Fri Aug 5 15:54:12 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Aug 2016 15:54:12 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> Message-ID: +2 On Fri, Aug 5, 2016 at 3:52 PM, Brad King wrote: > On 08/05/16 15:45, Bill Lorensen wrote: >> >> Why not in vtkType.h >> #if defined(WIN32) >> typedef vtkTypeUInt64 vtkTypeMTime; >> #else >> typedef unsigned long vtkTypeMTime; >> #endif >> >> In vtkObject.h and other GetMTimes' >> virtual vtkTypeMTime GetMTime(); >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> subclasses. > > > With a trivial re-ordering in `Common/Core/vtkType.h` to > prefer `long` over `long long` when the former is 64-bit > then `vtkTypeUInt64` will be selected as above automatically > and can serve this role without a separate typedef. This > would make vtkType.h more consistent anyway. > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From robert.maynard at kitware.com Fri Aug 5 15:57:01 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 5 Aug 2016 15:57:01 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> Message-ID: +2 to the reorder of vtkTypeUInt64/vtkTypeInt64 On Fri, Aug 5, 2016 at 3:52 PM, Brad King wrote: > On 08/05/16 15:45, Bill Lorensen wrote: >> >> Why not in vtkType.h >> #if defined(WIN32) >> typedef vtkTypeUInt64 vtkTypeMTime; >> #else >> typedef unsigned long vtkTypeMTime; >> #endif >> >> In vtkObject.h and other GetMTimes' >> virtual vtkTypeMTime GetMTime(); >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> subclasses. > > > With a trivial re-ordering in `Common/Core/vtkType.h` to > prefer `long` over `long long` when the former is 64-bit > then `vtkTypeUInt64` will be selected as above automatically > and can serve this role without a separate typedef. This > would make vtkType.h more consistent anyway. > > -Brad > From bill.lorensen at gmail.com Fri Aug 5 16:03:22 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 5 Aug 2016 16:03:22 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> Message-ID: Brad, This order? /* Select a 64-bit integer type. */ #if VTK_SIZEOF_LONG == 8 typedef unsigned long vtkTypeUInt64; typedef signed long vtkTypeInt64; # define VTK_TYPE_UINT64 VTK_UNSIGNED_LONG # define VTK_TYPE_INT64 VTK_LONG #elif VTK_SIZEOF_LONG_LONG == 8 typedef unsigned long long vtkTypeUInt64; typedef signed long long vtkTypeInt64; # define VTK_TYPE_UINT64 VTK_UNSIGNED_LONG_LONG # define VTK_TYPE_INT64 VTK_LONG_LONG #else # error "No native data type can represent a 64-bit integer." #endif On Fri, Aug 5, 2016 at 3:57 PM, Robert Maynard wrote: > +2 to the reorder of vtkTypeUInt64/vtkTypeInt64 > > On Fri, Aug 5, 2016 at 3:52 PM, Brad King wrote: >> On 08/05/16 15:45, Bill Lorensen wrote: >>> >>> Why not in vtkType.h >>> #if defined(WIN32) >>> typedef vtkTypeUInt64 vtkTypeMTime; >>> #else >>> typedef unsigned long vtkTypeMTime; >>> #endif >>> >>> In vtkObject.h and other GetMTimes' >>> virtual vtkTypeMTime GetMTime(); >>> >>> Windows apps will have to change their GetMTimes' in their VTK derived >>> subclasses. >> >> >> With a trivial re-ordering in `Common/Core/vtkType.h` to >> prefer `long` over `long long` when the former is 64-bit >> then `vtkTypeUInt64` will be selected as above automatically >> and can serve this role without a separate typedef. This >> would make vtkType.h more consistent anyway. >> >> -Brad >> -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Fri Aug 5 16:10:47 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 5 Aug 2016 16:10:47 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> Message-ID: <20160805201047.344607384@mail.rogue-research.com> On Fri, 5 Aug 2016 15:52:44 -0400, Brad King said: >On 08/05/16 15:45, Bill Lorensen wrote: >> Why not in vtkType.h >> #if defined(WIN32) >> typedef vtkTypeUInt64 vtkTypeMTime; >> #else >> typedef unsigned long vtkTypeMTime; >> #endif >> >> In vtkObject.h and other GetMTimes' >> virtual vtkTypeMTime GetMTime(); >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> subclasses. > >With a trivial re-ordering in `Common/Core/vtkType.h` to >prefer `long` over `long long` when the former is 64-bit >then `vtkTypeUInt64` will be selected as above automatically >and can serve this role without a separate typedef. This >would make vtkType.h more consistent anyway. You mean to change vtkTypeUInt64 to become 'unsigned long' instead of 'unsigned long long' (in the case where they are both 64 bit, that is, on UNIX)? Isn't that risky too? Isn't C++ very picky about types? Can't one have function/method overload differing only by type, ie: int foo(long a); int foo(long long a); so someone might have; int foo(long a); int foo(vtkTypeInt64 a); then your change would break that. Not all that likely, but, I dunno... I wouldn't change vtkTypeUInt64 like that... (what I would do (one day) is redefine all those in terms of the C++11 fixed sized types, but that's another topic). 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 brad.king at kitware.com Fri Aug 5 16:12:51 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Aug 2016 16:12:51 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> Message-ID: On 08/05/16 16:03, Bill Lorensen wrote: > This order? Yes, but we need to do it for vtkIdType too. Here is a MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/1778 -Brad From brad.king at kitware.com Fri Aug 5 16:16:09 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Aug 2016 16:16:09 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <20160805201047.344607384@mail.rogue-research.com> References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> <20160805201047.344607384@mail.rogue-research.com> Message-ID: <58a58419-23e9-79bf-6abb-417485ea18be@kitware.com> On 08/05/16 16:10, Sean McBride wrote: > You mean to change vtkTypeUInt64 to become 'unsigned long' instead > of 'unsigned long long' (in the case where they are both 64 bit, > that is, on UNIX)? Isn't that risky too? Isn't C++ very picky > about types? Can't one have function/method overload differing > only by type, ie: > > int foo(long a); > int foo(long long a); > > so someone might have; > > int foo(long a); > int foo(vtkTypeInt64 a); > > then your change would break that. Not all that likely, but, > I dunno... I wouldn't change vtkTypeUInt64 like that... > (what I would do (one day) is redefine all those in terms of > the C++11 fixed sized types, but that's another topic). Yes, and IO/SQL/vtkSQLQuery.h has such a case. All such overloading cases are buggy. When trying to enumerate all supported types one should use only the fundamental type names. Using the typedefs is buggy because we make no guarantee about what type will be selected. Such cases in VTK itself will have to be fixed along with this change. See the MR I posted in another response. -Brad From sean at rogue-research.com Fri Aug 5 16:40:55 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 5 Aug 2016 16:40:55 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <58a58419-23e9-79bf-6abb-417485ea18be@kitware.com> References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> <20160805201047.344607384@mail.rogue-research.com> <58a58419-23e9-79bf-6abb-417485ea18be@kitware.com> Message-ID: <20160805204055.1339951538@mail.rogue-research.com> On Fri, 5 Aug 2016 16:16:09 -0400, Brad King said: >On 08/05/16 16:10, Sean McBride wrote: >> You mean to change vtkTypeUInt64 to become 'unsigned long' instead >> of 'unsigned long long' (in the case where they are both 64 bit, >> that is, on UNIX)? Isn't that risky too? Isn't C++ very picky >> about types? Can't one have function/method overload differing >> only by type, ie: >> >> int foo(long a); >> int foo(long long a); >> >> so someone might have; >> >> int foo(long a); >> int foo(vtkTypeInt64 a); >> >> then your change would break that. Not all that likely, but, >> I dunno... I wouldn't change vtkTypeUInt64 like that... >> (what I would do (one day) is redefine all those in terms of >> the C++11 fixed sized types, but that's another topic). > >Yes, and IO/SQL/vtkSQLQuery.h has such a case. If VTK itself made this mistake, then so could other code. >All such overloading >cases are buggy. When trying to enumerate all supported types one >should use only the fundamental type names. Using the typedefs is >buggy because we make no guarantee about what type will be selected. Agreed, but still. I'm not convinced it's a good tradeoff. But if it's decided to change the definition of vtkTypeUInt64, then maybe now is the time to have a case like: #if __cplusplus >= c++11 typedef std::uint64_t vtkTypeUInt64; 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 brad.king at kitware.com Fri Aug 5 16:48:54 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Aug 2016 16:48:54 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: <20160805204055.1339951538@mail.rogue-research.com> References: <20160804152735.578746537@mail.rogue-research.com> <616b4800-2ae9-92be-55c9-082c1b7e3740@kitware.com> <20160805201047.344607384@mail.rogue-research.com> <58a58419-23e9-79bf-6abb-417485ea18be@kitware.com> <20160805204055.1339951538@mail.rogue-research.com> Message-ID: <27e4dbc3-29a8-0eef-0aa1-57214fd0798a@kitware.com> On 08/05/16 16:40, Sean McBride wrote: > If VTK itself made this mistake, then so could other code. Yes, but fixing such overload combinations will be a bug fix for the other code too. Once fixed, it will work with any VTK version without any conditions. >> All such overloading >> cases are buggy. When trying to enumerate all supported types one >> should use only the fundamental type names. Using the typedefs is >> buggy because we make no guarantee about what type will be selected. > > Agreed, but still. I'm not convinced it's a good tradeoff. I'm trudging through the overload fixes within VTK because they are worthwhile either way. We can always use the vtkTypeMTime approach instead. > But if it's decided to change the definition of vtkTypeUInt64, > then maybe now is the time to have a case like: > > #if __cplusplus >= c++11 > typedef std::uint64_t vtkTypeUInt64; Once overloading cases are fixed then this is certainly a possibility. -Brad From bill.lorensen at gmail.com Sun Aug 7 11:37:09 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 7 Aug 2016 11:37:09 -0400 Subject: [vtk-developers] OSMesa regression Message-ID: The commit at the end of thie email causes my Offscreen build to fail with errors like these: [100%] Linking C shared library ../../../lib/libvtkgl2ps-7.1.so CMakeFiles/vtkgl2ps.dir/gl2ps.c.o: In function `gl2psAddText': /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:885: undefined reference to `glGetBooleanv' /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:887: undefined reference to `glGetFloatv' /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:916: undefined reference to `glGetFloatv' /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:936: undefined reference to `glPassThrough' ... commit 561c9b6403f4562d91e4fe36e55713747fa22d39 Author: Utkarsh Ayachit Date: Wed Jul 6 15:26:57 2016 -0400 Add support for on and off screen Mesa in same build. On and Off scrreen Mesa can now be enabled in the same version of VTK. Tested with Mesa 12.0.0-rc2, but has been reported to work with 11.2 as well. From bill.lorensen at gmail.com Sun Aug 7 11:50:49 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 7 Aug 2016 11:50:49 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: I added //The OpenGL library being used supports off screen Mesa calls VTK_OPENGL_HAS_OSMESA:BOOL=ON to my cache and all is well. Are these changes documented somewhere on the Wiki? Bill On Sun, Aug 7, 2016 at 11:37 AM, Bill Lorensen wrote: > The commit at the end of thie email causes my Offscreen build to fail > with errors like these: > [100%] Linking C shared library ../../../lib/libvtkgl2ps-7.1.so > CMakeFiles/vtkgl2ps.dir/gl2ps.c.o: In function `gl2psAddText': > /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:885: > undefined reference to `glGetBooleanv' > /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:887: > undefined reference to `glGetFloatv' > /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:916: > undefined reference to `glGetFloatv' > /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:936: > undefined reference to `glPassThrough' > ... > > commit 561c9b6403f4562d91e4fe36e55713747fa22d39 > Author: Utkarsh Ayachit > Date: Wed Jul 6 15:26:57 2016 -0400 > > Add support for on and off screen Mesa in same build. > > On and Off scrreen Mesa can now be enabled in the same version of VTK. > Tested with Mesa 12.0.0-rc2, but has been reported to work with 11.2 as > well. -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Mon Aug 8 10:10:08 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 8 Aug 2016 10:10:08 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: Bill, There was nothing that was changed by this commit as far as flags needed is concerned. VTK_OPENGL_HAS_OSMESA was always needed to use OSMesa. What are the flags you were using before? Utkarsh On Sun, Aug 7, 2016 at 11:50 AM, Bill Lorensen wrote: > I added > //The OpenGL library being used supports off screen Mesa calls > VTK_OPENGL_HAS_OSMESA:BOOL=ON > > to my cache and all is well. > > Are these changes documented somewhere on the Wiki? > > Bill > > On Sun, Aug 7, 2016 at 11:37 AM, Bill Lorensen wrote: >> The commit at the end of thie email causes my Offscreen build to fail >> with errors like these: >> [100%] Linking C shared library ../../../lib/libvtkgl2ps-7.1.so >> CMakeFiles/vtkgl2ps.dir/gl2ps.c.o: In function `gl2psAddText': >> /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:885: >> undefined reference to `glGetBooleanv' >> /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:887: >> undefined reference to `glGetFloatv' >> /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:916: >> undefined reference to `glGetFloatv' >> /home/lorensen/ProjectsGIT/VTKGitlab/ThirdParty/gl2ps/vtkgl2ps/gl2ps.c:936: >> undefined reference to `glPassThrough' >> ... >> >> commit 561c9b6403f4562d91e4fe36e55713747fa22d39 >> Author: Utkarsh Ayachit >> Date: Wed Jul 6 15:26:57 2016 -0400 >> >> Add support for on and off screen Mesa in same build. >> >> On and Off scrreen Mesa can now be enabled in the same version of VTK. >> Tested with Mesa 12.0.0-rc2, but has been reported to work with 11.2 as >> well. > > > > -- > Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Mon Aug 8 13:00:13 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 8 Aug 2016 13:00:13 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: References: Message-ID: How do you change the mapper? Do you immediately destroy the old mapper or leave it around for later? I suspect the old mapper is getting destroyed later than it should. One thing you can try as a quick fix is actor->SetMapper(shiny new mapper); oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have the window handy) ... On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola wrote: > Hello everyone, > > I have a crash that occurs in my application when running vtk with > the GL2 rendered enabled but not with GL1. So here is the situation, in my > program when I change the shape of my poly data mapper, basically setting > the mapper of an actor in my scene to a new poly data mapper it results in > a crash. The crash is situated in vtkOpenGLBufferObject?s destructor, > specifically the deletion of the Internal?s handle. I have tried to verify > if the handle is valid prior to reaching the destructor which it seems to > be, my main concern is if the handle is filled with garbage (a non-zero > value) it might effectively pass the test condition and try to invoke > glDeleteBuffer. Has anyone experienced anything similar to this? > Regards, > Seun > > > _______________________________________________ > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 miao at cg.tuwien.ac.at Tue Aug 9 04:27:52 2016 From: miao at cg.tuwien.ac.at (Haichao Miao) Date: Tue, 9 Aug 2016 10:27:52 +0200 Subject: [vtk-developers] 3D texture mapping VTK7 with OpenGL2 Message-ID: <9eacdd0d-f602-445d-9777-f6a250af8d77@cg.tuwien.ac.at> Hi, I am using VTK7 with OpenGL2, is there a way for me to do 3D texture mapping? Basically, I have two vtkImageData, a data image and a mask image. From the mask I extracted polydata using marching cubes. Now I want to use the data image as texture and map it on the polydata. Unfortunately, I saw that the vtkTexture is not supporting 3D texture. It is necessary, that I use texture mapping, as I need the texture coordinates for later computations. Would there be a elegant way to do this? Alternatively, I could switch to an older version. Cheers, Hai From ken.martin at kitware.com Tue Aug 9 08:44:19 2016 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 9 Aug 2016 08:44:19 -0400 Subject: [vtk-developers] 3D texture mapping VTK7 with OpenGL2 In-Reply-To: <9eacdd0d-f602-445d-9777-f6a250af8d77@cg.tuwien.ac.at> References: <9eacdd0d-f602-445d-9777-f6a250af8d77@cg.tuwien.ac.at> Message-ID: The 3D texture support is a bit limited/low level in VTK. Rendering/OpenGL2/vtkTextureObject supports 3D textures but it is a bit lower level. That is the class we use within VTK for 3D texture operations. You can though, create a TextureObject and assign it to a vtkOpenGLTexture which you then assign to an actor but the texture coordinates are by default 2D so you would need some custom shader code to handle it. Thanks Ken On Tue, Aug 9, 2016 at 4:27 AM, Haichao Miao wrote: > Hi, > > I am using VTK7 with OpenGL2, is there a way for me to do 3D texture > mapping? > > Basically, I have two vtkImageData, a data image and a mask image. From > the mask I extracted polydata using marching cubes. Now I want to use the > data image as texture and map it on the polydata. Unfortunately, I saw that > the vtkTexture is not supporting 3D texture. > > It is necessary, that I use texture mapping, as I need the texture > coordinates for later computations. > > Would there be a elegant way to do this? Alternatively, I could switch to > an older version. > > Cheers, > Hai > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 utkarsh.ayachit at kitware.com Tue Aug 9 10:10:56 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 9 Aug 2016 10:10:56 -0400 Subject: [vtk-developers] Dashboards Message-ID: Folks, The dashboards have gotten to a bit of a messy state in the past few days. Can we focus our efforts on cleaning things up on the dashboards before adding new features please. Thanks! From bill.lorensen at gmail.com Tue Aug 9 11:08:57 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Aug 2016 11:08:57 -0400 Subject: [vtk-developers] Dashboards In-Reply-To: References: Message-ID: And do not forget the valgrind defects... On Tue, Aug 9, 2016 at 10:10 AM, Utkarsh Ayachit wrote: > Folks, > > The dashboards have gotten to a bit of a messy state in the past few > days. Can we focus our efforts on cleaning things up on the dashboards > before adding new features please. > > Thanks! > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From mathieu.westphal at kitware.com Tue Aug 9 11:10:25 2016 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 9 Aug 2016 17:10:25 +0200 Subject: [vtk-developers] Dashboards In-Reply-To: References: Message-ID: As far as i know, valgrind defect are not tracked by the dashboards, only vtk leaks, is it not ? Mathieu Westphal On Tue, Aug 9, 2016 at 5:08 PM, Bill Lorensen wrote: > And do not forget the valgrind defects... > > > On Tue, Aug 9, 2016 at 10:10 AM, Utkarsh Ayachit > wrote: > > Folks, > > > > The dashboards have gotten to a bit of a messy state in the past few > > days. Can we focus our efforts on cleaning things up on the dashboards > > before adding new features please. > > > > Thanks! > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q= > vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > 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 Aug 9 11:11:40 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Aug 2016 11:11:40 -0400 Subject: [vtk-developers] Dashboards In-Reply-To: References: Message-ID: It is listed as Dynamic Analysis at the bottom of the dashboard. On Tue, Aug 9, 2016 at 11:10 AM, Mathieu Westphal wrote: > As far as i know, valgrind defect are not tracked by the dashboards, only > vtk leaks, is it not ? > > Mathieu Westphal > > On Tue, Aug 9, 2016 at 5:08 PM, Bill Lorensen > wrote: >> >> And do not forget the valgrind defects... >> >> >> On Tue, Aug 9, 2016 at 10:10 AM, Utkarsh Ayachit >> wrote: >> > Folks, >> > >> > The dashboards have gotten to a bit of a messy state in the past few >> > days. Can we focus our efforts on cleaning things up on the dashboards >> > before adding new features please. >> > >> > Thanks! >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> > http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > 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 ken.martin at kitware.com Tue Aug 9 12:39:32 2016 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 9 Aug 2016 12:39:32 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: I feel the additional typedef makes it more confusing as you do not know what the type is. vtkTypeUInt64 I can understand from its name. If everyone wants a new typedef I can certainly live with it though but I would still rather it be consistent on unix and windows, so that people can fix the issue on Unix and have some confidence it will work/compile on Windows. I have an updated topic here https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen wrote: > Why not in vtkType.h > #if defined(WIN32) > typedef vtkTypeUInt64 vtkTypeMTime; > #else > typedef unsigned long vtkTypeMTime; > #endif > > In vtkObject.h and other GetMTimes' > virtual vtkTypeMTime GetMTime(); > > Windows apps will have to change their GetMTimes' in their VTK derived > subclasses. > > > > On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard > wrote: > > I agree with David. I prefer correctness to full backwards > > compatibility, especially so with something like consistently having > > 64bit MTimes on all platforms. > > > > Personally I don't see the value in having the return type as a > > typedef compared to having the caller do a static cast ( which is what > > MTime would have to do internally ). > > > > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers > > wrote: > >> Except.... I think fixing the overflow bug on Windows is more > >> important than full source compatibility. A default build (no need to > >> set anything in CMake) of the new version of VTK on Windows with this > >> capability should result in 64-bit MTime values and avoid the overflow > >> condition. > >> > >> I prefer correctness to full/100% backwards compatibility. > >> > >> > >> > >> > >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride > wrote: > >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: > >>> > >>>>A nice-to-the-user-who-needs-that capability would be to typedef a > >>>>type for the return value of GetMTime, and then allow for user > >>>>definition of that type. Default to uint64_t, but allow for user > >>>>definition. > >>> > >>> Was just going to suggest that. It could be typedefed to exactly what > it is today, giving full source compatibility; and then if you build with > VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. > >>> > >>> 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 > >> > > _______________________________________________ > > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 robert.maynard at kitware.com Tue Aug 9 13:07:31 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 9 Aug 2016 13:07:31 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: I prefer using vtkTypeUInt64. On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin wrote: > I feel the additional typedef makes it more confusing as you do not know > what the type is. vtkTypeUInt64 I can understand from its name. If everyone > wants a new typedef I can certainly live with it though but I would still > rather it be consistent on unix and windows, so that people can fix the > issue on Unix and have some confidence it will work/compile on Windows. > > I have an updated topic here > > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 > > > > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen > wrote: >> >> Why not in vtkType.h >> #if defined(WIN32) >> typedef vtkTypeUInt64 vtkTypeMTime; >> #else >> typedef unsigned long vtkTypeMTime; >> #endif >> >> In vtkObject.h and other GetMTimes' >> virtual vtkTypeMTime GetMTime(); >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> subclasses. >> >> >> >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard >> wrote: >> > I agree with David. I prefer correctness to full backwards >> > compatibility, especially so with something like consistently having >> > 64bit MTimes on all platforms. >> > >> > Personally I don't see the value in having the return type as a >> > typedef compared to having the caller do a static cast ( which is what >> > MTime would have to do internally ). >> > >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers >> > wrote: >> >> Except.... I think fixing the overflow bug on Windows is more >> >> important than full source compatibility. A default build (no need to >> >> set anything in CMake) of the new version of VTK on Windows with this >> >> capability should result in 64-bit MTime values and avoid the overflow >> >> condition. >> >> >> >> I prefer correctness to full/100% backwards compatibility. >> >> >> >> >> >> >> >> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride >> >> wrote: >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: >> >>> >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a >> >>>>type for the return value of GetMTime, and then allow for user >> >>>>definition of that type. Default to uint64_t, but allow for user >> >>>>definition. >> >>> >> >>> Was just going to suggest that. It could be typedefed to exactly what >> >>> it is today, giving full source compatibility; and then if you build with >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. >> >>> >> >>> 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 >> >> >> > _______________________________________________ >> > 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 >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 DLRdave at aol.com Tue Aug 9 13:13:28 2016 From: DLRdave at aol.com (David Cole) Date: Tue, 9 Aug 2016 13:13:28 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: This is fantastic. I'm fine with just using vtkTypeUInt64: my main app doesn't even have any overrides of GetMTime, so I can just rebuild VTK and go after this is in. Thank you, thank you, thank you... David C. On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin wrote: > I feel the additional typedef makes it more confusing as you do not know > what the type is. vtkTypeUInt64 I can understand from its name. If everyone > wants a new typedef I can certainly live with it though but I would still > rather it be consistent on unix and windows, so that people can fix the > issue on Unix and have some confidence it will work/compile on Windows. > > I have an updated topic here > > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 > > > > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen > wrote: >> >> Why not in vtkType.h >> #if defined(WIN32) >> typedef vtkTypeUInt64 vtkTypeMTime; >> #else >> typedef unsigned long vtkTypeMTime; >> #endif >> >> In vtkObject.h and other GetMTimes' >> virtual vtkTypeMTime GetMTime(); >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> subclasses. >> >> >> >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard >> wrote: >> > I agree with David. I prefer correctness to full backwards >> > compatibility, especially so with something like consistently having >> > 64bit MTimes on all platforms. >> > >> > Personally I don't see the value in having the return type as a >> > typedef compared to having the caller do a static cast ( which is what >> > MTime would have to do internally ). >> > >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers >> > wrote: >> >> Except.... I think fixing the overflow bug on Windows is more >> >> important than full source compatibility. A default build (no need to >> >> set anything in CMake) of the new version of VTK on Windows with this >> >> capability should result in 64-bit MTime values and avoid the overflow >> >> condition. >> >> >> >> I prefer correctness to full/100% backwards compatibility. >> >> >> >> >> >> >> >> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride >> >> wrote: >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: >> >>> >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a >> >>>>type for the return value of GetMTime, and then allow for user >> >>>>definition of that type. Default to uint64_t, but allow for user >> >>>>definition. >> >>> >> >>> Was just going to suggest that. It could be typedefed to exactly what >> >>> it is today, giving full source compatibility; and then if you build with >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. >> >>> >> >>> 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 >> >> >> > _______________________________________________ >> > 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 >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 > > From bill.lorensen at gmail.com Tue Aug 9 13:47:35 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Aug 2016 13:47:35 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: There are some advantages to a new typedef. 1) In the future, a more sophisticated type might be needed. 2) To see if all unsigned long's have been changed, the typedef can be changed to something like "double" and detect missing conversions. I'll post a topic soon that defines a new typedef and we can see which topic make sense. Since I've used 2), I can always change vtkTypeMTime to vtkTypeUInt64... On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin wrote: > I feel the additional typedef makes it more confusing as you do not know > what the type is. vtkTypeUInt64 I can understand from its name. If everyone > wants a new typedef I can certainly live with it though but I would still > rather it be consistent on unix and windows, so that people can fix the > issue on Unix and have some confidence it will work/compile on Windows. > > I have an updated topic here > > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 > > > > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen > wrote: >> >> Why not in vtkType.h >> #if defined(WIN32) >> typedef vtkTypeUInt64 vtkTypeMTime; >> #else >> typedef unsigned long vtkTypeMTime; >> #endif >> >> In vtkObject.h and other GetMTimes' >> virtual vtkTypeMTime GetMTime(); >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> subclasses. >> >> >> >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard >> wrote: >> > I agree with David. I prefer correctness to full backwards >> > compatibility, especially so with something like consistently having >> > 64bit MTimes on all platforms. >> > >> > Personally I don't see the value in having the return type as a >> > typedef compared to having the caller do a static cast ( which is what >> > MTime would have to do internally ). >> > >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers >> > wrote: >> >> Except.... I think fixing the overflow bug on Windows is more >> >> important than full source compatibility. A default build (no need to >> >> set anything in CMake) of the new version of VTK on Windows with this >> >> capability should result in 64-bit MTime values and avoid the overflow >> >> condition. >> >> >> >> I prefer correctness to full/100% backwards compatibility. >> >> >> >> >> >> >> >> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride >> >> wrote: >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers said: >> >>> >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a >> >>>>type for the return value of GetMTime, and then allow for user >> >>>>definition of that type. Default to uint64_t, but allow for user >> >>>>definition. >> >>> >> >>> Was just going to suggest that. It could be typedefed to exactly what >> >>> it is today, giving full source compatibility; and then if you build with >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 bit type. >> >>> >> >>> 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 >> >> >> > _______________________________________________ >> > 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 >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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. -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Tue Aug 9 14:18:42 2016 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 9 Aug 2016 14:18:42 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: Sounds good, my topic is missing one or two (hundred) changes :-) Have to force the compiler to error on possible overflow. On Tue, Aug 9, 2016 at 1:47 PM, Bill Lorensen wrote: > There are some advantages to a new typedef. > > 1) In the future, a more sophisticated type might be needed. > 2) To see if all unsigned long's have been changed, the typedef can be > changed to something like "double" and detect missing conversions. > > I'll post a topic soon that defines a new typedef and we can see which > topic make sense. Since I've used 2), I can always change vtkTypeMTime > to vtkTypeUInt64... > > > On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin > wrote: > > I feel the additional typedef makes it more confusing as you do not know > > what the type is. vtkTypeUInt64 I can understand from its name. If > everyone > > wants a new typedef I can certainly live with it though but I would still > > rather it be consistent on unix and windows, so that people can fix the > > issue on Unix and have some confidence it will work/compile on Windows. > > > > I have an updated topic here > > > > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 > > > > > > > > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen > > wrote: > >> > >> Why not in vtkType.h > >> #if defined(WIN32) > >> typedef vtkTypeUInt64 vtkTypeMTime; > >> #else > >> typedef unsigned long vtkTypeMTime; > >> #endif > >> > >> In vtkObject.h and other GetMTimes' > >> virtual vtkTypeMTime GetMTime(); > >> > >> Windows apps will have to change their GetMTimes' in their VTK derived > >> subclasses. > >> > >> > >> > >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard > >> wrote: > >> > I agree with David. I prefer correctness to full backwards > >> > compatibility, especially so with something like consistently having > >> > 64bit MTimes on all platforms. > >> > > >> > Personally I don't see the value in having the return type as a > >> > typedef compared to having the caller do a static cast ( which is what > >> > MTime would have to do internally ). > >> > > >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers > >> > wrote: > >> >> Except.... I think fixing the overflow bug on Windows is more > >> >> important than full source compatibility. A default build (no need to > >> >> set anything in CMake) of the new version of VTK on Windows with this > >> >> capability should result in 64-bit MTime values and avoid the > overflow > >> >> condition. > >> >> > >> >> I prefer correctness to full/100% backwards compatibility. > >> >> > >> >> > >> >> > >> >> > >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride < > sean at rogue-research.com> > >> >> wrote: > >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers > said: > >> >>> > >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a > >> >>>>type for the return value of GetMTime, and then allow for user > >> >>>>definition of that type. Default to uint64_t, but allow for user > >> >>>>definition. > >> >>> > >> >>> Was just going to suggest that. It could be typedefed to exactly > what > >> >>> it is today, giving full source compatibility; and then if you > build with > >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 > bit type. > >> >>> > >> >>> 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 > >> >> > >> > _______________________________________________ > >> > 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 > >> > > > > > > > > -- > > Ken Martin PhD > > Chairman & CFO > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > 518 371 3971 > > > > 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. > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 bill.lorensen at gmail.com Tue Aug 9 14:20:19 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Aug 2016 14:20:19 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: My topic has 447 changed files. I'll be pushing it soon... On Tue, Aug 9, 2016 at 2:18 PM, Ken Martin wrote: > Sounds good, my topic is missing one or two (hundred) changes :-) Have to > force the compiler to error on possible overflow. > > > On Tue, Aug 9, 2016 at 1:47 PM, Bill Lorensen > wrote: >> >> There are some advantages to a new typedef. >> >> 1) In the future, a more sophisticated type might be needed. >> 2) To see if all unsigned long's have been changed, the typedef can be >> changed to something like "double" and detect missing conversions. >> >> I'll post a topic soon that defines a new typedef and we can see which >> topic make sense. Since I've used 2), I can always change vtkTypeMTime >> to vtkTypeUInt64... >> >> >> On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin >> wrote: >> > I feel the additional typedef makes it more confusing as you do not know >> > what the type is. vtkTypeUInt64 I can understand from its name. If >> > everyone >> > wants a new typedef I can certainly live with it though but I would >> > still >> > rather it be consistent on unix and windows, so that people can fix the >> > issue on Unix and have some confidence it will work/compile on Windows. >> > >> > I have an updated topic here >> > >> > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >> > >> > >> > >> > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen >> > wrote: >> >> >> >> Why not in vtkType.h >> >> #if defined(WIN32) >> >> typedef vtkTypeUInt64 vtkTypeMTime; >> >> #else >> >> typedef unsigned long vtkTypeMTime; >> >> #endif >> >> >> >> In vtkObject.h and other GetMTimes' >> >> virtual vtkTypeMTime GetMTime(); >> >> >> >> Windows apps will have to change their GetMTimes' in their VTK derived >> >> subclasses. >> >> >> >> >> >> >> >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard >> >> wrote: >> >> > I agree with David. I prefer correctness to full backwards >> >> > compatibility, especially so with something like consistently having >> >> > 64bit MTimes on all platforms. >> >> > >> >> > Personally I don't see the value in having the return type as a >> >> > typedef compared to having the caller do a static cast ( which is >> >> > what >> >> > MTime would have to do internally ). >> >> > >> >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers >> >> > wrote: >> >> >> Except.... I think fixing the overflow bug on Windows is more >> >> >> important than full source compatibility. A default build (no need >> >> >> to >> >> >> set anything in CMake) of the new version of VTK on Windows with >> >> >> this >> >> >> capability should result in 64-bit MTime values and avoid the >> >> >> overflow >> >> >> condition. >> >> >> >> >> >> I prefer correctness to full/100% backwards compatibility. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride >> >> >> >> >> >> wrote: >> >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers >> >> >>> said: >> >> >>> >> >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a >> >> >>>>type for the return value of GetMTime, and then allow for user >> >> >>>>definition of that type. Default to uint64_t, but allow for user >> >> >>>>definition. >> >> >>> >> >> >>> Was just going to suggest that. It could be typedefed to exactly >> >> >>> what >> >> >>> it is today, giving full source compatibility; and then if you >> >> >>> build with >> >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 >> >> >>> bit type. >> >> >>> >> >> >>> 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 >> >> >> >> >> > _______________________________________________ >> >> > 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 >> >> >> > >> > >> > >> > -- >> > Ken Martin PhD >> > Chairman & CFO >> > Kitware Inc. >> > 28 Corporate Drive >> > Clifton Park NY 12065 >> > 518 371 3971 >> > >> > 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. >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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. -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Tue Aug 9 14:38:47 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Aug 2016 14:38:47 -0400 Subject: [vtk-developers] Add GetModifiedTime deprecate GetMTime In-Reply-To: References: <20160804152735.578746537@mail.rogue-research.com> Message-ID: I just pushed the topic... https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 On Tue, Aug 9, 2016 at 2:20 PM, Bill Lorensen wrote: > My topic has 447 changed files. I'll be pushing it soon... > > > On Tue, Aug 9, 2016 at 2:18 PM, Ken Martin wrote: >> Sounds good, my topic is missing one or two (hundred) changes :-) Have to >> force the compiler to error on possible overflow. >> >> >> On Tue, Aug 9, 2016 at 1:47 PM, Bill Lorensen >> wrote: >>> >>> There are some advantages to a new typedef. >>> >>> 1) In the future, a more sophisticated type might be needed. >>> 2) To see if all unsigned long's have been changed, the typedef can be >>> changed to something like "double" and detect missing conversions. >>> >>> I'll post a topic soon that defines a new typedef and we can see which >>> topic make sense. Since I've used 2), I can always change vtkTypeMTime >>> to vtkTypeUInt64... >>> >>> >>> On Tue, Aug 9, 2016 at 12:39 PM, Ken Martin >>> wrote: >>> > I feel the additional typedef makes it more confusing as you do not know >>> > what the type is. vtkTypeUInt64 I can understand from its name. If >>> > everyone >>> > wants a new typedef I can certainly live with it though but I would >>> > still >>> > rather it be consistent on unix and windows, so that people can fix the >>> > issue on Unix and have some confidence it will work/compile on Windows. >>> > >>> > I have an updated topic here >>> > >>> > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >>> > >>> > >>> > >>> > On Fri, Aug 5, 2016 at 3:45 PM, Bill Lorensen >>> > wrote: >>> >> >>> >> Why not in vtkType.h >>> >> #if defined(WIN32) >>> >> typedef vtkTypeUInt64 vtkTypeMTime; >>> >> #else >>> >> typedef unsigned long vtkTypeMTime; >>> >> #endif >>> >> >>> >> In vtkObject.h and other GetMTimes' >>> >> virtual vtkTypeMTime GetMTime(); >>> >> >>> >> Windows apps will have to change their GetMTimes' in their VTK derived >>> >> subclasses. >>> >> >>> >> >>> >> >>> >> On Thu, Aug 4, 2016 at 1:28 PM, Robert Maynard >>> >> wrote: >>> >> > I agree with David. I prefer correctness to full backwards >>> >> > compatibility, especially so with something like consistently having >>> >> > 64bit MTimes on all platforms. >>> >> > >>> >> > Personally I don't see the value in having the return type as a >>> >> > typedef compared to having the caller do a static cast ( which is >>> >> > what >>> >> > MTime would have to do internally ). >>> >> > >>> >> > On Thu, Aug 4, 2016 at 12:53 PM, David Cole via vtk-developers >>> >> > wrote: >>> >> >> Except.... I think fixing the overflow bug on Windows is more >>> >> >> important than full source compatibility. A default build (no need >>> >> >> to >>> >> >> set anything in CMake) of the new version of VTK on Windows with >>> >> >> this >>> >> >> capability should result in 64-bit MTime values and avoid the >>> >> >> overflow >>> >> >> condition. >>> >> >> >>> >> >> I prefer correctness to full/100% backwards compatibility. >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Thu, Aug 4, 2016 at 11:27 AM, Sean McBride >>> >> >> >>> >> >> wrote: >>> >> >>> On Thu, 4 Aug 2016 10:32:23 -0400, David Cole via vtk-developers >>> >> >>> said: >>> >> >>> >>> >> >>>>A nice-to-the-user-who-needs-that capability would be to typedef a >>> >> >>>>type for the return value of GetMTime, and then allow for user >>> >> >>>>definition of that type. Default to uint64_t, but allow for user >>> >> >>>>definition. >>> >> >>> >>> >> >>> Was just going to suggest that. It could be typedefed to exactly >>> >> >>> what >>> >> >>> it is today, giving full source compatibility; and then if you >>> >> >>> build with >>> >> >>> VTK_LEGACY_REMOVE (or similar) it could be typedefed to the new 64 >>> >> >>> bit type. >>> >> >>> >>> >> >>> 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 >>> >> >> >>> >> > _______________________________________________ >>> >> > 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 >>> >> >>> > >>> > >>> > >>> > -- >>> > Ken Martin PhD >>> > Chairman & CFO >>> > Kitware Inc. >>> > 28 Corporate Drive >>> > Clifton Park NY 12065 >>> > 518 371 3971 >>> > >>> > 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. >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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. > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From shawn.waldon at kitware.com Tue Aug 9 16:06:12 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 9 Aug 2016 16:06:12 -0400 Subject: [vtk-developers] Test failures on megas In-Reply-To: References: Message-ID: There are still many tests suppressed on that machine. But these failures don't mention an OpenGL extension in the error message and it is the image test that is failing. So I was hoping someone who knows better than I do could look at them and see what is going on. You can ignore the OffAxisStereo test, a fix for that is already in the works. Shawn [1]: https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=06088bad-build236-%5Blinux-shared-release%2Bjava%2Bpython%2Bpython3%2Bqt%2Bqt5%2Btbb%5D-master&compare3=61&showfeed=0&value2=20160809T093002 [2]: https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=b0b8e49a-build1967-%5Blinux-shared-release%2Bextdeps%2Bmpi%2Bopengl1%2Bopenmp%2Bpython%2Bqt%2Bqt5%5D-master&compare3=61&showfeed=0&value2=20160808T104138 On Wed, Aug 3, 2016 at 12:10 PM, Ken Martin wrote: > The last message I have is below. I recall something about floating point > textures not working or a bug in Mesa, unless something has changed I think > there are still a lot of tests suppressed currently -- Ken > > > ------ old message follows > > > Feel free to ask Ben to suppress that test on megas, they are already > suppressing like 30 tests on that system. - Ken > > On Fri, Apr 15, 2016 at 10:04 AM, David Lonie > wrote: > >> On Thu, Apr 14, 2016 at 7:30 PM, Ken Martin >> wrote: >> >>> I'm guessing you are past this issue, if not let me know. WRT shader4 >>> mesa does not and probably never will support that extension. We only need >>> it when the OpenGL version is 2.1 and for mesa we really require a mesa >>> that is compatible with 3.2. If someone wants to use a mesa that is not 3.2 >>> compatible I believe they are on their own as it is easy to download mesa >>> and build a working llvmpipe version (or even SWR) that we know works well >>> with VTK. >>> >> >> Sounds good, I'll let megas fail until its mesa is updated. >> >> The issue I was having looks like a bug in upstream mesa. Brad tracked >> this down: >> >> $ ls mesa-master-install/lib/libMesaGL.so* -lh >> >> mesa-master-install/lib/libMesaGL.so -> libMesaGL.so.1.5.0 >> >> mesa-master-install/lib/libMesaGL.so.1 -> libMesaGL.so.1.6.0 >> mesa-master-install/lib/libMesaGL.so.1.5.0 >> mesa-master-install/lib/libMesaGL.so.1.6.0 >> >> The build produces libGL with two different versions, and the linker / >> loader weren't consistently using the same one. The solution was to run >> 'make install-data' in the top level, and 'make install-exec' in >> src/gallium so that only one would generated. >> >> Excellent news about apitrace, that will make this much easier. Thanks >> for the info! I'll submit a bug report today. >> >> > On Wed, Aug 3, 2016 at 11:41 AM, Shawn Waldon > wrote: > >> Hi all, >> >> Has any one looked into the test failures on megas lately? There are six >> tests failing on master (the only continuous build failures right now). >> Are these real failures or do they need to be excluded? I don't know >> enough about those parts of VTK to tell, though I suspect several are real >> errors. >> >> Thanks, >> Shawn >> >> _______________________________________________ >> 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 >> >> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 badshah400 at aim.com Wed Aug 10 09:55:45 2016 From: badshah400 at aim.com (Atri Bhattacharya) Date: Wed, 10 Aug 2016 15:55:45 +0200 Subject: [vtk-developers] uintptr_t redefinition issues when building vtkFiltersStatisticsGnuR Message-ID: <1470837345.4538.21.camel@aim.com> Hi! I am trying to build and provide VTK 7.0 packages for openSUSE [1]. Unfortunately, the builds for non-x86_64 architectures fail because of the following reason: The file?Filters/StatisticsGnuR/vtkRInterface.cxx #includes stdint.h for the data type uintptr_t before it includes the Rinterface.h header. The latter also defines the uintptr_t data type (line#105): #if !defined(HAVE_UINTPTR_T) && !defined(uintptr_t) ?typedef unsigned long uintptr_t; #endif Unfortunately, since nothing sets the HAVE_UINTPTR_T macro (and uintptr_t is a data type not a macro) before compilation, Rinterface.h ends up redefining the data type, leading to compile errors when there is a mismatch in the redefinition (e.g., on i386, stdint.h defines uintptr_t as unsigned int). The attached patch here defines the macro HAVE_UINTPTR_T in the Filters/StatisticsGnuR/vtkFiltersStatisticsGnuRConfigure.h file, which prevents Rinterface.h from redefining the data type in the scenario that uintptr_t symbol already exists. Please consider using this patch to fix the problem. I am willing to make modifications to the patch if you have any suggestions, or if you have a suggestion to fix this in a better way, please let me know too. Thanks a lot for your consideration and in general for VTK. [1]?https://build.opensuse.org/package/show/science/vtk ? ? The x86_64 build failure for openSUSE_Tumbleweed is due to a ? ? cmake issue that we have already fixed separately. --? Atri Bhattacharya Wed 10 Aug 15:24:57 CEST 2016 Patch follows: Index: VTK-7.0.0/Filters/StatisticsGnuR/CMakeLists.txt =================================================================== --- VTK-7.0.0.orig/Filters/StatisticsGnuR/CMakeLists.txt +++ VTK-7.0.0/Filters/StatisticsGnuR/CMakeLists.txt @@ -16,6 +16,10 @@ include_directories(${R_INCLUDE_DIR}) ? ?add_definitions(-DVTK_BUILDING_FILTERS_STATISTICSGNUR) ? +# Check for the existance of uintptr_t type and set the HAVE_UINTPTR_T macro +include(CheckTypeSize) +CHECK_TYPE_SIZE(uintptr_t UINTPTR_T) + ?# Configure the module specific settings into a module configured header. ?configure_file(${CMAKE_CURRENT_SOURCE_DIR}/vtkFiltersStatisticsGnuRConfigure.h.in ???${CMAKE_CURRENT_BINARY_DIR}/vtkFiltersStatisticsGnuRConfigure.h) Index: VTK-7.0.0/Filters/StatisticsGnuR/vtkFiltersStatisticsGnuRConfigure.h.in =================================================================== --- VTK-7.0.0.orig/Filters/StatisticsGnuR/vtkFiltersStatisticsGnuRConfigure.h.in +++ VTK-7.0.0/Filters/StatisticsGnuR/vtkFiltersStatisticsGnuRConfigure.h.in @@ -17,5 +17,6 @@ ?#define vtkFiltersStatisticsGnuRConfigure_h ? ?#define VTK_R_HOME "@R_HOME@" +#cmakedefine HAVE_UINTPTR_T ? ?#endif -------------- next part -------------- A non-text attachment was scrubbed... Name: vtk-Rinterface-uintptr_t.patch Type: text/x-patch Size: 658 bytes Desc: not available URL: From ben.boeckel at kitware.com Wed Aug 10 10:39:23 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Aug 2016 10:39:23 -0400 Subject: [vtk-developers] [ANN] Buildbot updates In-Reply-To: <20151119192947.GA11791@megas.khq.kitware.com> References: <20151119192947.GA11791@megas.khq.kitware.com> Message-ID: <20160810143923.GB14268@megas.kitware.com> On Thu, Nov 19, 2015 at 14:29:47 -0500, Ben Boeckel wrote: > A more disruptive change that has been discussed a bit would be to make > the --oneshot argument the default and instead switching around to using > --continuous instead to have "rebuild on push" behavior. So by default, > every push would need another "Do: test" to trigger a build. This would > help reduce the amount of clutter on the buildbots. I've made this change and would plan on deploying it this week. Commands already given are still using the old behavior. --Ben From ben.boeckel at kitware.com Wed Aug 10 11:37:25 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 Aug 2016 11:37:25 -0400 Subject: [vtk-developers] Mantis -> Gitlab issue migration Message-ID: <20160810153725.GA12991@megas.kitware.com> Hi, I'm planning on doing the Mantis -> Gitlab issue migration on Friday morning. In order to do this, it is planned to take down Gitlab for about 2 hours to prevent any issues from being created which would cause off-by-one problems with the issue number preservation. Mantis will be made read-only tomorrow so that a snapshot of the existing issue state can be properly made. The plan is to have it complete by 9 AM EDT (13:00 UTC). Thanks, --Ben From sean at rogue-research.com Wed Aug 10 12:32:30 2016 From: sean at rogue-research.com (Sean McBride) Date: Wed, 10 Aug 2016 12:32:30 -0400 Subject: [vtk-developers] HiDPI / Retina display support Message-ID: <20160810163230.2044410374@mail.rogue-research.com> Hi all, I'd like to start a bit of discussion/brainstorming on supporting HiDPI (aka "retina" in Apple world) displays. To do it right I think needs some significant change and forethought. While I'm familiar with the Mac case, it'd be nice to support this on other OSes properly too. OpenGL is a pixel-based API, and the Cocoa view/window system no longer is. They've abstracted a "point" to be defined as either 1x1 or 2x2 or whatever size, depending on the display. So the OS gives view/window/event sizes/locations in points, and you must scale to get pixels, or vice versa. Implications for OpenGL are summarized here: Some thoughts/questions: - anyone know how other OSes deal with HiDPI displays? - for OpenGL views on Mac, retina is opt-in (because it uses more memory and can be slower). I guess we need to expose a new API to opt-in. I would argue for it being opt-in also. - which VTK API should be pixel-based, which should be point-based? Presumably everything is pixel based today, do we want to change any? If so, some API would need to change from int to double. - tests that compare images... I guess new baselines at various scaling factors are needed? Or the test system will need to learn to scale images? or? - we'll need some dashboards with HiDPI enabled... anyone have hardware, like an iMac, with an actual Retina display that could be used? - we'll need to observe for the window moving from a display that supports retina to/from one that doesn't, ex: laptop with external monitor. (PS: I had been drafting this email for a while, but I understand Mike Jackson is at kitware this week and working on this, so figured I'd send it off not fully baked... :) ) 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 marcus.hanwell at kitware.com Wed Aug 10 14:19:42 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 10 Aug 2016 14:19:42 -0400 Subject: [vtk-developers] HiDPI / Retina display support In-Reply-To: <20160810163230.2044410374@mail.rogue-research.com> References: <20160810163230.2044410374@mail.rogue-research.com> Message-ID: On Wed, Aug 10, 2016 at 12:32 PM, Sean McBride wrote: > Hi all, > > I'd like to start a bit of discussion/brainstorming on supporting HiDPI (aka "retina" in Apple world) displays. > > To do it right I think needs some significant change and forethought. While I'm familiar with the Mac case, it'd be nice to support this on other OSes properly too. > > OpenGL is a pixel-based API, and the Cocoa view/window system no longer is. They've abstracted a "point" to be defined as either 1x1 or 2x2 or whatever size, depending on the display. So the OS gives view/window/event sizes/locations in points, and you must scale to get pixels, or vice versa. Implications for OpenGL are summarized here: > > > > Some thoughts/questions: > > - anyone know how other OSes deal with HiDPI displays? There is a summary of Qt's view of HiDPI here, http://doc.qt.io/qt-5/highdpi.html > > - for OpenGL views on Mac, retina is opt-in (because it uses more memory and can be slower). I guess we need to expose a new API to opt-in. I would argue for it being opt-in also. Sounds reasonable, but Qt applications can already enable this but QVTKWidget does not render to the full context. I would argue that letting us test this in Tomviz and other applications would help iron out kinks (and these code paths only do anything different when you opt-in). > > - which VTK API should be pixel-based, which should be point-based? Presumably everything is pixel based today, do we want to change any? If so, some API would need to change from int to double. I think everything should be pixel-based, and Qt has a similar view for OpenGL. > > - tests that compare images... I guess new baselines at various scaling factors are needed? Or the test system will need to learn to scale images? or? I think we would want some 2x images. > > - we'll need some dashboards with HiDPI enabled... anyone have hardware, like an iMac, with an actual Retina display that could be used? Not right now, can it be emulated though? The bigmac machine is on a standard monitor. > > - we'll need to observe for the window moving from a display that supports retina to/from one that doesn't, ex: laptop with external monitor. We have done that, and it works surprisingly well. You can observe the doubling in resolution. > > (PS: I had been drafting this email for a while, but I understand Mike Jackson is at kitware this week and working on this, so figured I'd send it off not fully baked... :) ) > Thanks for the input. As this doesn't appear to affect any existing applications until they turn retinal support on I would think even phasing in pieces that we get working would be useful. There have been quite a few posts asking about this on the list. We verified our changes didn't break any existing dashboards for example. Marcus From david.gobbi at gmail.com Wed Aug 10 14:40:34 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Aug 2016 12:40:34 -0600 Subject: [vtk-developers] HiDPI / Retina display support In-Reply-To: References: <20160810163230.2044410374@mail.rogue-research.com> Message-ID: On Wed, Aug 10, 2016 at 12:19 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Wed, Aug 10, 2016 at 12:32 PM, Sean McBride > wrote: > > > - we'll need some dashboards with HiDPI enabled... anyone have hardware, > like an iMac, with an actual Retina display that could be used? > > Not right now, can it be emulated though? The bigmac machine is on a > standard monitor. Depending on the machine/display combination, you might be able to select a HiDPI display mode on a standard monitor. Hold down "Alt" while selecting the resolution in the Display control panel, if HiDPI modes are available then they will be shown. For example, this allows me to emulate a retina display on my TV set at home (over HDMI/DVI) but not on my monitor at work (DisplayPort). So YMMV. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 11 10:32:40 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 11 Aug 2016 10:32:40 -0400 Subject: [vtk-developers] vtkFixedPointVolumeRayCastMapperComputeGradients odd thread check Message-ID: <20160811143240.312811852@mail.rogue-research.com> Hi all, git blame doesn't suggest anyone specific to ask, so... this cppcheck warning: Rendering/Volume/vtkFixedPointVolumeRayCastMapper.cxx:401: style: Condition 'thread_id==0' is always true anyone know that code? line 398 forcing 0 is suspiciously different vs line 307. I figure it's copy-paste and deliberate, or should be like 307, but am not in a position to decide. :) 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 seun at rogue-research.com Thu Aug 11 11:33:05 2016 From: seun at rogue-research.com (Seun Odutola) Date: Thu, 11 Aug 2016 11:33:05 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: References: Message-ID: Hi Ken, Thanks for the suggestion. I do have a little question though, is it a necessary convention to call release graphics resources on the old mapper prior to setting a new one? I was wondering judging from your statement (quick fix) if this was just a hack. Regards, Seun > On Aug 8, 2016, at 1:00 PM, Ken Martin wrote: > > How do you change the mapper? Do you immediately destroy the old mapper or leave it around for later? I suspect the old mapper is getting destroyed later than it should. One thing you can try as a quick fix is > > actor->SetMapper(shiny new mapper); > oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have the window handy) > ... > > > > On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola > wrote: > Hello everyone, > > I have a crash that occurs in my application when running vtk with the GL2 rendered enabled but not with GL1. So here is the situation, in my program when I change the shape of my poly data mapper, basically setting the mapper of an actor in my scene to a new poly data mapper it results in a crash. The crash is situated in vtkOpenGLBufferObject?s destructor, specifically the deletion of the Internal?s handle. I have tried to verify if the handle is valid prior to reaching the destructor which it seems to be, my main concern is if the handle is filled with garbage (a non-zero value) it might effectively pass the test condition and try to invoke glDeleteBuffer. Has anyone experienced anything similar to this? > > Regards, > Seun > > > _______________________________________________ > 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 > > > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 Aug 11 11:44:28 2016 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 11 Aug 2016 11:44:28 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: References: Message-ID: Yes you definitely want to call ReleaseGraphicsResources when you are done using a graphics object, but are not done using its window. Normally VTK handles this for you so you do not have to worry about it. Many classes in VTK create and hold onto OpenGL resources. At some point those resources need to be freed. Normally before an OpenGL context/window is destroyed it will call ReleaseGraphicsResources on everything connected to it so that they are all freed before it releases the context. But if you have detached a mapper from the RenderWindow/Renderer/Actor (but not yet deleted it) then that does not happen. Then at some other point that mapper tries to free its resources but the context that owned them is already gone causing an error. Thanks Ken On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola wrote: > Hi Ken, > > Thanks for the suggestion. I do have a little question though, is it a > necessary convention to call release graphics resources on the old mapper > prior to setting a new one? I was wondering judging from your statement > (quick fix) if this was just a hack. > > Regards, > Seun > > On Aug 8, 2016, at 1:00 PM, Ken Martin wrote: > > How do you change the mapper? Do you immediately destroy the old mapper or > leave it around for later? I suspect the old mapper is getting destroyed > later than it should. One thing you can try as a quick fix is > > actor->SetMapper(shiny new mapper); > oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have the > window handy) > ... > > > > On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola > wrote: > >> Hello everyone, >> >> I have a crash that occurs in my application when running vtk with >> the GL2 rendered enabled but not with GL1. So here is the situation, in my >> program when I change the shape of my poly data mapper, basically setting >> the mapper of an actor in my scene to a new poly data mapper it results in >> a crash. The crash is situated in vtkOpenGLBufferObject?s destructor, >> specifically the deletion of the Internal?s handle. I have tried to verify >> if the handle is valid prior to reaching the destructor which it seems to >> be, my main concern is if the handle is filled with garbage (a non-zero >> value) it might effectively pass the test condition and try to invoke >> glDeleteBuffer. Has anyone experienced anything similar to this? >> Regards, >> Seun >> >> >> _______________________________________________ >> 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 >> >> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 seun at rogue-research.com Thu Aug 11 11:52:05 2016 From: seun at rogue-research.com (Seun Odutola) Date: Thu, 11 Aug 2016 11:52:05 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: References: Message-ID: <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com> Thanks for the expeditious and detailed response Ken, I truly appreciate it. Perfect, this is exactly what I thought but needed the opinion of someone more experienced. I had a closer look at vtkActor and noticed how it checks the validity of it?s Mapper prior to releasing it (in its release graphics resource function) proof that it indeed needs to be released via calling ReleaseGraphicsResources sometime down the line. Thanks Regards, Seun. > On Aug 11, 2016, at 11:44 AM, Ken Martin wrote: > > Yes you definitely want to call ReleaseGraphicsResources when you are done using a graphics object, but are not done using its window. Normally VTK handles this for you so you do not have to worry about it. > > Many classes in VTK create and hold onto OpenGL resources. At some point those resources need to be freed. Normally before an OpenGL context/window is destroyed it will call ReleaseGraphicsResources on everything connected to it so that they are all freed before it releases the context. But if you have detached a mapper from the RenderWindow/Renderer/Actor (but not yet deleted it) then that does not happen. Then at some other point that mapper tries to free its resources but the context that owned them is already gone causing an error. > > Thanks > Ken > > > > On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola > wrote: > Hi Ken, > > Thanks for the suggestion. I do have a little question though, is it a necessary convention to call release graphics resources on the old mapper prior to setting a new one? I was wondering judging from your statement (quick fix) if this was just a hack. > > Regards, > Seun >> On Aug 8, 2016, at 1:00 PM, Ken Martin > wrote: >> >> How do you change the mapper? Do you immediately destroy the old mapper or leave it around for later? I suspect the old mapper is getting destroyed later than it should. One thing you can try as a quick fix is >> >> actor->SetMapper(shiny new mapper); >> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have the window handy) >> ... >> >> >> >> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola > wrote: >> Hello everyone, >> >> I have a crash that occurs in my application when running vtk with the GL2 rendered enabled but not with GL1. So here is the situation, in my program when I change the shape of my poly data mapper, basically setting the mapper of an actor in my scene to a new poly data mapper it results in a crash. The crash is situated in vtkOpenGLBufferObject?s destructor, specifically the deletion of the Internal?s handle. I have tried to verify if the handle is valid prior to reaching the destructor which it seems to be, my main concern is if the handle is filled with garbage (a non-zero value) it might effectively pass the test condition and try to invoke glDeleteBuffer. Has anyone experienced anything similar to this? >> >> Regards, >> Seun >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. > > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 bill.lorensen at gmail.com Thu Aug 11 14:11:20 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 11 Aug 2016 14:11:20 -0400 Subject: [vtk-developers] MTime patch for Windows Message-ID: Folks, Please review this patch: https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 The goal is to fix the modified time overflow issue that affects long running apps on Windows machines. This topic introduces a new type: vtkTypeMTime. I think a new type is justified, but thos can be easily changed to an existing vtk type. The type is introduced in: vtkType.h // Provide this define to facilitate apps that need to support older // versions that do not have vtkTypeMtime // #ifndef VTK_HAS_TYPE_MTIME // #if VTK_SIZEOF_LONG == 8 // typedef unsigned long vtkTypeMTime; // #else // typedef vtkTypeUInt64 vtkTypeMTime; // #endif // #endif #define VTK_HAS_TYPE_MTIME // Select an unsigned 64-bit integer type for use in MTime values. // If possible, use 'unsigned long' as we have historically. #if VTK_SIZEOF_LONG == 8 typedef unsigned long vtkTypeMTime; #else typedef vtkTypeUInt64 vtkTypeMTime; #endif From seun at rogue-research.com Thu Aug 11 14:31:31 2016 From: seun at rogue-research.com (Seun Odutola) Date: Thu, 11 Aug 2016 14:31:31 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com> References: <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com> Message-ID: <8A3D6FC5-66B2-4EE6-BC75-B9190F6A0BDB@rogue-research.com> Hi Ken, I have a scenario where I have an actor and a mapper connected to it (so in the application window it renders i.e: a sphere). The user has the ability to change the shape (to cube for example) via the UI, so internally this is what I?m doing: I have an actor that I keep around, when the user changes the shape, I just create a new mapper and set the actor?s mapper directly to the new one (not calling the ReleaseGraphicsResources). First, is this reasonable? Or every time I need to create a new mapper is it best to also create a new actor to connect it to? or does it suffice to just swap the actor?s mapper by calling SetMapper()? In the latter case, then one needs to call ReleaseGraphicsResources on the previous mapper prior to setting up a new one, right? Relatedly, I would like to know for the sake of clarity if mappers can be shared between actors; that is, is the relationship of an actor and its mapper a 1 to 1 relationship? Regards, Seun > On Aug 11, 2016, at 11:52 AM, Seun Odutola wrote: > > Thanks for the expeditious and detailed response Ken, I truly appreciate it. Perfect, this is exactly what I thought but needed the opinion of someone more experienced. I had a closer look at vtkActor and noticed how it checks the validity of it?s Mapper prior to releasing it (in its release graphics resource function) proof that it indeed needs to be released via calling ReleaseGraphicsResources sometime down the line. Thanks > > Regards, > Seun. > >> On Aug 11, 2016, at 11:44 AM, Ken Martin > wrote: >> >> Yes you definitely want to call ReleaseGraphicsResources when you are done using a graphics object, but are not done using its window. Normally VTK handles this for you so you do not have to worry about it. >> >> Many classes in VTK create and hold onto OpenGL resources. At some point those resources need to be freed. Normally before an OpenGL context/window is destroyed it will call ReleaseGraphicsResources on everything connected to it so that they are all freed before it releases the context. But if you have detached a mapper from the RenderWindow/Renderer/Actor (but not yet deleted it) then that does not happen. Then at some other point that mapper tries to free its resources but the context that owned them is already gone causing an error. >> >> Thanks >> Ken >> >> >> >> On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola > wrote: >> Hi Ken, >> >> Thanks for the suggestion. I do have a little question though, is it a necessary convention to call release graphics resources on the old mapper prior to setting a new one? I was wondering judging from your statement (quick fix) if this was just a hack. >> >> Regards, >> Seun >>> On Aug 8, 2016, at 1:00 PM, Ken Martin > wrote: >>> >>> How do you change the mapper? Do you immediately destroy the old mapper or leave it around for later? I suspect the old mapper is getting destroyed later than it should. One thing you can try as a quick fix is >>> >>> actor->SetMapper(shiny new mapper); >>> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have the window handy) >>> ... >>> >>> >>> >>> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola > wrote: >>> Hello everyone, >>> >>> I have a crash that occurs in my application when running vtk with the GL2 rendered enabled but not with GL1. So here is the situation, in my program when I change the shape of my poly data mapper, basically setting the mapper of an actor in my scene to a new poly data mapper it results in a crash. The crash is situated in vtkOpenGLBufferObject?s destructor, specifically the deletion of the Internal?s handle. I have tried to verify if the handle is valid prior to reaching the destructor which it seems to be, my main concern is if the handle is filled with garbage (a non-zero value) it might effectively pass the test condition and try to invoke glDeleteBuffer. Has anyone experienced anything similar to this? >>> >>> Regards, >>> Seun >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> >>> -- >>> Ken Martin PhD >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 >>> >>> This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. >> >> >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Aug 12 07:58:29 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 12 Aug 2016 07:58:29 -0400 Subject: [vtk-developers] Mantis -> Gitlab issue migration In-Reply-To: <20160810153725.GA12991@megas.kitware.com> References: <20160810153725.GA12991@megas.kitware.com> Message-ID: <20160812115829.GC10731@megas.kitware.com> On Wed, Aug 10, 2016 at 11:37:25 -0400, Ben Boeckel wrote: > I'm planning on doing the Mantis -> Gitlab issue migration on Friday > morning. In order to do this, it is planned to take down Gitlab for > about 2 hours to prevent any issues from being created which would cause > off-by-one problems with the issue number preservation. Mantis will be > made read-only tomorrow so that a snapshot of the existing issue state > can be properly made. The plan is to have it complete by 9 AM EDT (13:00 > UTC). The import is complete; gitlab.kitware.com should be accessible again soon. --Ben From sean at rogue-research.com Fri Aug 12 10:04:26 2016 From: sean at rogue-research.com (Sean McBride) Date: Fri, 12 Aug 2016 10:04:26 -0400 Subject: [vtk-developers] Rogue7 vtktiff dashboard build failure In-Reply-To: <20160726144235.GB14126@rotor> References: <20160726011546.2016066190@mail.rogue-research.com> <20160726140545.GA14126@rotor> <20160726142252.GA10822@rotor.kitware.com> <20160726144235.GB14126@rotor> Message-ID: <20160812140426.1347855963@mail.rogue-research.com> On Tue, 26 Jul 2016 10:42:35 -0400, Ben Boeckel said: >On Tue, Jul 26, 2016 at 10:22:52 -0400, Ben Boeckel wrote: >> Now to figure out why the difference happens? > >tiff MR up: > > https://gitlab.kitware.com/third-party/tiff/merge_requests/1/commits Ben, So that's all merged now, right? It seems however to have not actually fixed the Xcode build: 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 aashish.chaudhary at kitware.com Fri Aug 12 11:47:40 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 12 Aug 2016 15:47:40 +0000 Subject: [vtk-developers] vtkFixedPointVolumeRayCastMapperComputeGradients odd thread check In-Reply-To: <20160811143240.312811852@mail.rogue-research.com> References: <20160811143240.312811852@mail.rogue-research.com> Message-ID: Alvaro, Can you look into this please? Thanks, On Thu, Aug 11, 2016 at 10:33 AM Sean McBride wrote: > Hi all, > > git blame doesn't suggest anyone specific to ask, so... this cppcheck > warning: > > Rendering/Volume/vtkFixedPointVolumeRayCastMapper.cxx:401: style: > Condition 'thread_id==0' is always true > > anyone know that code? line 398 forcing 0 is suspiciously different vs > line 307. I figure it's copy-paste and deliberate, or should be like 307, > but am not in a position to decide. :) > > 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 r.gori at cineca.it Fri Aug 12 12:21:33 2016 From: r.gori at cineca.it (Roberto Gori) Date: Fri, 12 Aug 2016 18:21:33 +0200 Subject: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 Message-ID: <74823200C67847C5ADC1E814BECF3674@int.cineca.it> Hi, sorry for cross-posting but no one is answering to my question on the vtkusers list. As you can see running this code the plane is visualized without texture. I think the problem is in rendering a texture on a vtkFollower. Can someone open a bug on Mantis? #include #include #include #include #include #include #include #include #include #include #include #include #include int main ( int argc, char *argv[] ) { // Parse command line arguments if ( argc != 2 ) { std::cerr << "Usage: " << argv[0] << " Filename" << std::endl; return EXIT_FAILURE; } std::cout << "VTK version:" << vtkVersion::GetVTKVersion() << std::endl; std::string inputFilename = argv[1]; // Read the image which will be the texture vtkSmartPointer jPEGReader = vtkSmartPointer::New(); jPEGReader->SetFileName ( inputFilename.c_str() ); // Create a plane vtkSmartPointer plane = vtkSmartPointer::New(); plane->SetCenter(0.0, 0.0, 0.0); plane->SetNormal(0.0, 0.0, 1.0); // Apply the texture vtkSmartPointer texture = vtkSmartPointer::New(); texture->SetInputConnection(jPEGReader->GetOutputPort()); vtkSmartPointer texturePlane = vtkSmartPointer::New(); texturePlane->SetInputConnection(plane->GetOutputPort()); vtkSmartPointer planeMapper = vtkSmartPointer::New(); planeMapper->SetInputConnection(texturePlane->GetOutputPort()); vtkSmartPointer texturedPlane = vtkSmartPointer::New(); texturedPlane->SetMapper(planeMapper); texturedPlane->SetTexture(texture); // Visualize the textured plane vtkSmartPointer renderer = vtkSmartPointer::New(); renderer->AddActor(texturedPlane); renderer->SetBackground(.1, .2, .3); // Background color dark blue renderer->ResetCamera(); texturedPlane->SetCamera(renderer->GetActiveCamera()); vtkSmartPointer renderWindow = vtkSmartPointer::New(); renderWindow->AddRenderer(renderer); vtkSmartPointer renderWindowInteractor = vtkSmartPointer::New(); renderWindowInteractor->SetRenderWindow(renderWindow); renderWindow->Render(); renderWindowInteractor->Start(); return EXIT_SUCCESS; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Aug 12 13:02:25 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 12 Aug 2016 13:02:25 -0400 Subject: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 In-Reply-To: <74823200C67847C5ADC1E814BECF3674@int.cineca.it> References: <74823200C67847C5ADC1E814BECF3674@int.cineca.it> Message-ID: What happens if you remove the TextureMapToPlane? PlaneSource generates texture coordinate by default. So connect that directly to the mapper and what happens? On Fri, Aug 12, 2016 at 12:21 PM, Roberto Gori wrote: > Hi, > > sorry for cross-posting but no one is answering to my question on the > vtkusers list. > > As you can see running this code the plane is visualized without texture. > > I think the problem is in rendering a texture on a vtkFollower. > Can someone open a bug on Mantis? > > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > int main ( int argc, char *argv[] ) > { > // Parse command line arguments > if ( argc != 2 ) > { > std::cerr << "Usage: " << argv[0] << " Filename" << std::endl; > return EXIT_FAILURE; > } > > std::cout << "VTK version:" << vtkVersion::GetVTKVersion() << std::endl; > > std::string inputFilename = argv[1]; > > // Read the image which will be the texture > vtkSmartPointer jPEGReader = > vtkSmartPointer::New(); > jPEGReader->SetFileName ( inputFilename.c_str() ); > > // Create a plane > vtkSmartPointer plane = > vtkSmartPointer::New(); > plane->SetCenter(0.0, 0.0, 0.0); > plane->SetNormal(0.0, 0.0, 1.0); > > // Apply the texture > vtkSmartPointer texture = > vtkSmartPointer::New(); > texture->SetInputConnection(jPEGReader->GetOutputPort()); > > vtkSmartPointer texturePlane = > vtkSmartPointer::New(); > texturePlane->SetInputConnection(plane->GetOutputPort()); > > vtkSmartPointer planeMapper = > vtkSmartPointer::New(); > planeMapper->SetInputConnection(texturePlane->GetOutputPort()); > > vtkSmartPointer texturedPlane = > vtkSmartPointer::New(); > texturedPlane->SetMapper(planeMapper); > texturedPlane->SetTexture(texture); > > > // Visualize the textured plane > vtkSmartPointer renderer = > vtkSmartPointer::New(); > renderer->AddActor(texturedPlane); > > renderer->SetBackground(.1, .2, .3); // Background color dark blue > renderer->ResetCamera(); > > texturedPlane->SetCamera(renderer->GetActiveCamera()); > > > vtkSmartPointer renderWindow = > vtkSmartPointer::New(); > renderWindow->AddRenderer(renderer); > > vtkSmartPointer renderWindowInteractor = > vtkSmartPointer::New(); > renderWindowInteractor->SetRenderWindow(renderWindow); > > renderWindow->Render(); > > renderWindowInteractor->Start(); > > return EXIT_SUCCESS; > } > > > > _______________________________________________ > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 pmattern at arcor.de Fri Aug 12 13:15:38 2016 From: pmattern at arcor.de (Peter Mattern) Date: Fri, 12 Aug 2016 19:15:38 +0200 Subject: [vtk-developers] Mantis -> Gitlab issue migration In-Reply-To: <20160812115829.GC10731@megas.kitware.com> References: <20160810153725.GA12991@megas.kitware.com> <20160812115829.GC10731@megas.kitware.com> Message-ID: <56643b7a8df6768a4d3cd6e71fb8535a@arcor.de> So far only the initial "Descriptions" in terms of the Mantis system were imported to GitLab while the following "Notes" weren't. Are there any plans to migrate the latter to GitLab as well? From r.gori at cineca.it Fri Aug 12 13:37:03 2016 From: r.gori at cineca.it (Roberto Gori) Date: Fri, 12 Aug 2016 19:37:03 +0200 Subject: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 In-Reply-To: References: <74823200C67847C5ADC1E814BECF3674@int.cineca.it> Message-ID: <40436A0710C24B4DA6CF4F9EEE6E6B58@int.cineca.it> Hi, thx for your answer you are right but the result is the same. it works using a vtkActor instead of a vtkFollower. From: Ken Martin Sent: Friday, August 12, 2016 7:02 PM To: Roberto Gori Cc: VTK Developers Subject: Re: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 What happens if you remove the TextureMapToPlane? PlaneSource generates texture coordinate by default. So connect that directly to the mapper and what happens? On Fri, Aug 12, 2016 at 12:21 PM, Roberto Gori wrote: Hi, sorry for cross-posting but no one is answering to my question on the vtkusers list. As you can see running this code the plane is visualized without texture. I think the problem is in rendering a texture on a vtkFollower. Can someone open a bug on Mantis? #include #include #include #include #include #include #include #include #include #include #include #include #include int main ( int argc, char *argv[] ) { // Parse command line arguments if ( argc != 2 ) { std::cerr << "Usage: " << argv[0] << " Filename" << std::endl; return EXIT_FAILURE; } std::cout << "VTK version:" << vtkVersion::GetVTKVersion() << std::endl; std::string inputFilename = argv[1]; // Read the image which will be the texture vtkSmartPointer jPEGReader = vtkSmartPointer::New(); jPEGReader->SetFileName ( inputFilename.c_str() ); // Create a plane vtkSmartPointer plane = vtkSmartPointer::New(); plane->SetCenter(0.0, 0.0, 0.0); plane->SetNormal(0.0, 0.0, 1.0); // Apply the texture vtkSmartPointer texture = vtkSmartPointer::New(); texture->SetInputConnection(jPEGReader->GetOutputPort()); vtkSmartPointer texturePlane = vtkSmartPointer::New(); texturePlane->SetInputConnection(plane->GetOutputPort()); vtkSmartPointer planeMapper = vtkSmartPointer::New(); planeMapper->SetInputConnection(texturePlane->GetOutputPort()); vtkSmartPointer texturedPlane = vtkSmartPointer::New(); texturedPlane->SetMapper(planeMapper); texturedPlane->SetTexture(texture); // Visualize the textured plane vtkSmartPointer renderer = vtkSmartPointer::New(); renderer->AddActor(texturedPlane); renderer->SetBackground(.1, .2, .3); // Background color dark blue renderer->ResetCamera(); texturedPlane->SetCamera(renderer->GetActiveCamera()); vtkSmartPointer renderWindow = vtkSmartPointer::New(); renderWindow->AddRenderer(renderer); vtkSmartPointer renderWindowInteractor = vtkSmartPointer::New(); renderWindowInteractor->SetRenderWindow(renderWindow); renderWindow->Render(); renderWindowInteractor->Start(); return EXIT_SUCCESS; } _______________________________________________ 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 -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: not available URL: From ken.martin at kitware.com Fri Aug 12 13:50:26 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 12 Aug 2016 13:50:26 -0400 Subject: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 In-Reply-To: <40436A0710C24B4DA6CF4F9EEE6E6B58@int.cineca.it> References: <74823200C67847C5ADC1E814BECF3674@int.cineca.it> <40436A0710C24B4DA6CF4F9EEE6E6B58@int.cineca.it> Message-ID: Yes, I suspect the class needs to be fixed. If you have a VTK build you can try editing vtkFollower.cxx to include the following line this->Device->SetTexture(this->GetTexture()); around line number 272 (right before the ComputeMatrix call) if that works I can put in a fix Ken On Fri, Aug 12, 2016 at 1:37 PM, Roberto Gori wrote: > Hi, > > thx for your answer [image: Sorriso] > > you are right but the result is the same. > > it works using a vtkActor instead of a vtkFollower. > > *From:* Ken Martin > *Sent:* Friday, August 12, 2016 7:02 PM > *To:* Roberto Gori > *Cc:* VTK Developers > *Subject:* Re: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 > > What happens if you remove the TextureMapToPlane? PlaneSource generates > texture coordinate by default. So connect that directly to the mapper and > what happens? > > On Fri, Aug 12, 2016 at 12:21 PM, Roberto Gori wrote: > >> Hi, >> >> sorry for cross-posting but no one is answering to my question on the >> vtkusers list. >> >> As you can see running this code the plane is visualized without texture. >> >> I think the problem is in rendering a texture on a vtkFollower. >> Can someone open a bug on Mantis? >> >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> int main ( int argc, char *argv[] ) >> { >> // Parse command line arguments >> if ( argc != 2 ) >> { >> std::cerr << "Usage: " << argv[0] << " Filename" << std::endl; >> return EXIT_FAILURE; >> } >> >> std::cout << "VTK version:" << vtkVersion::GetVTKVersion() << std::endl; >> >> std::string inputFilename = argv[1]; >> >> // Read the image which will be the texture >> vtkSmartPointer jPEGReader = >> vtkSmartPointer::New(); >> jPEGReader->SetFileName ( inputFilename.c_str() ); >> >> // Create a plane >> vtkSmartPointer plane = >> vtkSmartPointer::New(); >> plane->SetCenter(0.0, 0.0, 0.0); >> plane->SetNormal(0.0, 0.0, 1.0); >> >> // Apply the texture >> vtkSmartPointer texture = >> vtkSmartPointer::New(); >> texture->SetInputConnection(jPEGReader->GetOutputPort()); >> >> vtkSmartPointer texturePlane = >> vtkSmartPointer::New(); >> texturePlane->SetInputConnection(plane->GetOutputPort()); >> >> vtkSmartPointer planeMapper = >> vtkSmartPointer::New(); >> planeMapper->SetInputConnection(texturePlane->GetOutputPort()); >> >> vtkSmartPointer texturedPlane = >> vtkSmartPointer::New(); >> texturedPlane->SetMapper(planeMapper); >> texturedPlane->SetTexture(texture); >> >> >> // Visualize the textured plane >> vtkSmartPointer renderer = >> vtkSmartPointer::New(); >> renderer->AddActor(texturedPlane); >> >> renderer->SetBackground(.1, .2, .3); // Background color dark blue >> renderer->ResetCamera(); >> >> texturedPlane->SetCamera(renderer->GetActiveCamera()); >> >> >> vtkSmartPointer renderWindow = >> vtkSmartPointer::New(); >> renderWindow->AddRenderer(renderer); >> >> vtkSmartPointer renderWindowInteractor = >> vtkSmartPointer::New(); >> renderWindowInteractor->SetRenderWindow(renderWindow); >> >> renderWindow->Render(); >> >> renderWindowInteractor->Start(); >> >> return EXIT_SUCCESS; >> } >> >> >> >> _______________________________________________ >> 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 >> >> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: not available URL: From r.gori at cineca.it Fri Aug 12 14:02:09 2016 From: r.gori at cineca.it (Roberto Gori) Date: Fri, 12 Aug 2016 20:02:09 +0200 Subject: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 In-Reply-To: References: <74823200C67847C5ADC1E814BECF3674@int.cineca.it> <40436A0710C24B4DA6CF4F9EEE6E6B58@int.cineca.it> Message-ID: wow! it works! thank you so much! From: Ken Martin Sent: Friday, August 12, 2016 7:50 PM To: Roberto Gori Cc: VTK Developers Subject: Re: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 Yes, I suspect the class needs to be fixed. If you have a VTK build you can try editing vtkFollower.cxx to include the following line this->Device->SetTexture(this->GetTexture()); around line number 272 (right before the ComputeMatrix call) if that works I can put in a fix Ken On Fri, Aug 12, 2016 at 1:37 PM, Roberto Gori wrote: Hi, thx for your answer you are right but the result is the same. it works using a vtkActor instead of a vtkFollower. From: Ken Martin Sent: Friday, August 12, 2016 7:02 PM To: Roberto Gori Cc: VTK Developers Subject: Re: [vtk-developers] possible bug in vtk 7.1 - OpenGL2 What happens if you remove the TextureMapToPlane? PlaneSource generates texture coordinate by default. So connect that directly to the mapper and what happens? On Fri, Aug 12, 2016 at 12:21 PM, Roberto Gori wrote: Hi, sorry for cross-posting but no one is answering to my question on the vtkusers list. As you can see running this code the plane is visualized without texture. I think the problem is in rendering a texture on a vtkFollower. Can someone open a bug on Mantis? #include #include #include #include #include #include #include #include #include #include #include #include #include int main ( int argc, char *argv[] ) { // Parse command line arguments if ( argc != 2 ) { std::cerr << "Usage: " << argv[0] << " Filename" << std::endl; return EXIT_FAILURE; } std::cout << "VTK version:" << vtkVersion::GetVTKVersion() << std::endl; std::string inputFilename = argv[1]; // Read the image which will be the texture vtkSmartPointer jPEGReader = vtkSmartPointer::New(); jPEGReader->SetFileName ( inputFilename.c_str() ); // Create a plane vtkSmartPointer plane = vtkSmartPointer::New(); plane->SetCenter(0.0, 0.0, 0.0); plane->SetNormal(0.0, 0.0, 1.0); // Apply the texture vtkSmartPointer texture = vtkSmartPointer::New(); texture->SetInputConnection(jPEGReader->GetOutputPort()); vtkSmartPointer texturePlane = vtkSmartPointer::New(); texturePlane->SetInputConnection(plane->GetOutputPort()); vtkSmartPointer planeMapper = vtkSmartPointer::New(); planeMapper->SetInputConnection(texturePlane->GetOutputPort()); vtkSmartPointer texturedPlane = vtkSmartPointer::New(); texturedPlane->SetMapper(planeMapper); texturedPlane->SetTexture(texture); // Visualize the textured plane vtkSmartPointer renderer = vtkSmartPointer::New(); renderer->AddActor(texturedPlane); renderer->SetBackground(.1, .2, .3); // Background color dark blue renderer->ResetCamera(); texturedPlane->SetCamera(renderer->GetActiveCamera()); vtkSmartPointer renderWindow = vtkSmartPointer::New(); renderWindow->AddRenderer(renderer); vtkSmartPointer renderWindowInteractor = vtkSmartPointer::New(); renderWindowInteractor->SetRenderWindow(renderWindow); renderWindow->Render(); renderWindowInteractor->Start(); return EXIT_SUCCESS; } _______________________________________________ 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 -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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: wlEmoticon-partysmile[1].png Type: image/png Size: 935 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: not available URL: From berk.geveci at kitware.com Fri Aug 12 14:37:13 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 12 Aug 2016 14:37:13 -0400 Subject: [vtk-developers] TestRemoveVolumeNonCurrentContext Message-ID: Who knows anything about TestRemoveVolumeNonCurrentContext? It seems to be failing on some dashboards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Aug 12 15:12:57 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 12 Aug 2016 15:12:57 -0400 Subject: [vtk-developers] MTime Olympics Message-ID: Folks, We have two topics that fix the Windows mtime overflow issue for Windows. This seems like a critical issue for Windows apps that run for a long time (e.g. surgical applications). Topic 1: https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 Files changed: 376 Topic 2: https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 Files changed: 471 The major difference is that topic 1 defines MTime as an unsigned long and topic 2 introduces a new type vtkTypeMTime. Topic 2 could be easily changed to use unsigned long for the mtime. Please take some time to review these topics. I suspect that some combination of the two will help solve the problem. Bill From sankhesh.jhaveri at kitware.com Fri Aug 12 15:12:53 2016 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Fri, 12 Aug 2016 15:12:53 -0400 Subject: [vtk-developers] TestRemoveVolumeNonCurrentContext In-Reply-To: References: Message-ID: I've added that test based on the example provided in this issue: http://www.vtk.org/Bug/view.php?id=15869 I'd say the test should be suppressed on megas and trey. ?Seems like there is a valid issue on tanaab for the EGL backend?. Sankhesh On Fri, Aug 12, 2016 at 2:37 PM, Berk Geveci wrote: > Who knows anything about TestRemoveVolumeNonCurrentContext? It seems to > be failing on some dashboards. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Aug 12 15:20:45 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 12 Aug 2016 15:20:45 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: Oh, I am fine with the approach you took Bill and so haven't pushed the other changes I have locally. I just want the 32bit issue fixed as I think that is really important. I am flexible on how it gets fixed. I am not a fan of introducing another typedef as I feel it makes the code harder to understand, but that is a really small issue and I can definitely live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So once your topic is baked let's get it committed. Ken On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen wrote: > Folks, > > We have two topics that fix the Windows mtime overflow issue for > Windows. This seems like a critical issue for Windows apps that run > for a long time (e.g. surgical applications). > > Topic 1: > https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 > Files changed: 376 > > Topic 2: > https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 > Files changed: 471 > > The major difference is that topic 1 defines MTime as an unsigned long > and topic 2 introduces a new type vtkTypeMTime. > > Topic 2 could be easily changed to use unsigned long for the mtime. > > Please take some time to review these topics. I suspect that some > combination of the two will help solve the problem. > > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 berk.geveci at kitware.com Fri Aug 12 15:22:26 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 12 Aug 2016 15:22:26 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: I also prefer vtkTypeUInt64 but not a strong preference. Both look good to me. On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin wrote: > Oh, I am fine with the approach you took Bill and so haven't pushed the > other changes I have locally. I just want the 32bit issue fixed as I think > that is really important. I am flexible on how it gets fixed. > > I am not a fan of introducing another typedef as I feel it makes the code > harder to understand, but that is a really small issue and I can definitely > live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So once > your topic is baked let's get it committed. > > Ken > > > > > On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen > wrote: > >> Folks, >> >> We have two topics that fix the Windows mtime overflow issue for >> Windows. This seems like a critical issue for Windows apps that run >> for a long time (e.g. surgical applications). >> >> Topic 1: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >> Files changed: 376 >> >> Topic 2: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 >> Files changed: 471 >> >> The major difference is that topic 1 defines MTime as an unsigned long >> and topic 2 introduces a new type vtkTypeMTime. >> >> Topic 2 could be easily changed to use unsigned long for the mtime. >> >> Please take some time to review these topics. I suspect that some >> combination of the two will help solve the problem. >> >> 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 >> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Aug 12 15:43:48 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 12 Aug 2016 15:43:48 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: One advantage of naming a type is for backward compatibility: // Select an unsigned 64-bit integer type for use in MTime values. // If possible, use 'unsigned long' as we have historically. #if VTK_SIZEOF_LONG == 8 typedef unsigned long vtkTypeMTime; #else typedef vtkTypeUInt64 vtkTypeMTime; #endif also for apps that need to support old and new versions of VTK: // Provide this define to facilitate apps that need to support older // versions that do not have vtkTypeMTime #ifndef VTK_HAS_TYPE_MTIME #if VTK_SIZEOF_LONG == 8 typedef unsigned long vtkTypeMTime; #else typedef vtkTypeUInt64 vtkTypeMTime; #endif #endif On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci wrote: > I also prefer vtkTypeUInt64 but not a strong preference. Both look good to > me. > > On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin wrote: >> >> Oh, I am fine with the approach you took Bill and so haven't pushed the >> other changes I have locally. I just want the 32bit issue fixed as I think >> that is really important. I am flexible on how it gets fixed. >> >> I am not a fan of introducing another typedef as I feel it makes the code >> harder to understand, but that is a really small issue and I can definitely >> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So once >> your topic is baked let's get it committed. >> >> Ken >> >> >> >> >> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen >> wrote: >>> >>> Folks, >>> >>> We have two topics that fix the Windows mtime overflow issue for >>> Windows. This seems like a critical issue for Windows apps that run >>> for a long time (e.g. surgical applications). >>> >>> Topic 1: >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >>> Files changed: 376 >>> >>> Topic 2: >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 >>> Files changed: 471 >>> >>> The major difference is that topic 1 defines MTime as an unsigned long >>> and topic 2 introduces a new type vtkTypeMTime. >>> >>> Topic 2 could be easily changed to use unsigned long for the mtime. >>> >>> Please take some time to review these topics. I suspect that some >>> combination of the two will help solve the problem. >>> >>> 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 >>> >> >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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 >> >> > -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Fri Aug 12 15:49:17 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 12 Aug 2016 15:49:17 -0400 Subject: [vtk-developers] Mantis -> Gitlab issue migration In-Reply-To: <56643b7a8df6768a4d3cd6e71fb8535a@arcor.de> References: <20160810153725.GA12991@megas.kitware.com> <20160812115829.GC10731@megas.kitware.com> <56643b7a8df6768a4d3cd6e71fb8535a@arcor.de> Message-ID: <20160812194917.GA1790@megas.kitware.com> On Fri, Aug 12, 2016 at 19:15:38 +0200, Peter Mattern wrote: > So far only the initial "Descriptions" in terms of the Mantis system > were imported to GitLab while the following "Notes" weren't. > Are there any plans to migrate the latter to GitLab as well? We haven't found a way to export them from Mantis, so not as of right now. I also don't think there are any plans to remove Mantis either. If there are important notes or clarifications for issues which are either open, feel free to import them. --Ben From DLRdave at aol.com Fri Aug 12 15:50:04 2016 From: DLRdave at aol.com (David Cole) Date: Fri, 12 Aug 2016 15:50:04 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: Think of how easy this fix would have been if vtkTypeMTime had already existed ..... On Fri, Aug 12, 2016 at 3:43 PM, Bill Lorensen wrote: > One advantage of naming a type is for backward compatibility: > // Select an unsigned 64-bit integer type for use in MTime values. > // If possible, use 'unsigned long' as we have historically. > #if VTK_SIZEOF_LONG == 8 > typedef unsigned long vtkTypeMTime; > #else > typedef vtkTypeUInt64 vtkTypeMTime; > #endif > > also for apps that need to support old and new versions of VTK: > // Provide this define to facilitate apps that need to support older > // versions that do not have vtkTypeMTime > #ifndef VTK_HAS_TYPE_MTIME > #if VTK_SIZEOF_LONG == 8 > typedef unsigned long vtkTypeMTime; > #else > typedef vtkTypeUInt64 vtkTypeMTime; > #endif > #endif > > > On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci wrote: >> I also prefer vtkTypeUInt64 but not a strong preference. Both look good to >> me. >> >> On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin wrote: >>> >>> Oh, I am fine with the approach you took Bill and so haven't pushed the >>> other changes I have locally. I just want the 32bit issue fixed as I think >>> that is really important. I am flexible on how it gets fixed. >>> >>> I am not a fan of introducing another typedef as I feel it makes the code >>> harder to understand, but that is a really small issue and I can definitely >>> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So once >>> your topic is baked let's get it committed. >>> >>> Ken >>> >>> >>> >>> >>> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen >>> wrote: >>>> >>>> Folks, >>>> >>>> We have two topics that fix the Windows mtime overflow issue for >>>> Windows. This seems like a critical issue for Windows apps that run >>>> for a long time (e.g. surgical applications). >>>> >>>> Topic 1: >>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >>>> Files changed: 376 >>>> >>>> Topic 2: >>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 >>>> Files changed: 471 >>>> >>>> The major difference is that topic 1 defines MTime as an unsigned long >>>> and topic 2 introduces a new type vtkTypeMTime. >>>> >>>> Topic 2 could be easily changed to use unsigned long for the mtime. >>>> >>>> Please take some time to review these topics. I suspect that some >>>> combination of the two will help solve the problem. >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Ken Martin PhD >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 >>> >>> 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 >>> >>> >> > > > > -- > 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 ben.boeckel at kitware.com Fri Aug 12 15:51:18 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 12 Aug 2016 15:51:18 -0400 Subject: [vtk-developers] Rogue7 vtktiff dashboard build failure In-Reply-To: <20160812140426.1347855963@mail.rogue-research.com> References: <20160726011546.2016066190@mail.rogue-research.com> <20160726140545.GA14126@rotor> <20160726142252.GA10822@rotor.kitware.com> <20160726144235.GB14126@rotor> <20160812140426.1347855963@mail.rogue-research.com> Message-ID: <20160812195118.GB1790@megas.kitware.com> On Fri, Aug 12, 2016 at 10:04:26 -0400, Sean McBride wrote: > So that's all merged now, right? It seems however to have not > actually fixed the Xcode build: > > Can you have CMake error right after it does the checks for the flag and configure with --debug-trycompile and send the CMakeFiles/CMakeTmp/ (I think it lives there at least) output? Is -Werror not applying for newer Xcode compilers? --Ben From bill.lorensen at gmail.com Fri Aug 12 16:03:16 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 12 Aug 2016 16:03:16 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: +2 Dave I wonder if we will need to change in the future... On Fri, Aug 12, 2016 at 3:50 PM, David Cole wrote: > Think of how easy this fix would have been if vtkTypeMTime had already > existed ..... > > > > On Fri, Aug 12, 2016 at 3:43 PM, Bill Lorensen wrote: >> One advantage of naming a type is for backward compatibility: >> // Select an unsigned 64-bit integer type for use in MTime values. >> // If possible, use 'unsigned long' as we have historically. >> #if VTK_SIZEOF_LONG == 8 >> typedef unsigned long vtkTypeMTime; >> #else >> typedef vtkTypeUInt64 vtkTypeMTime; >> #endif >> >> also for apps that need to support old and new versions of VTK: >> // Provide this define to facilitate apps that need to support older >> // versions that do not have vtkTypeMTime >> #ifndef VTK_HAS_TYPE_MTIME >> #if VTK_SIZEOF_LONG == 8 >> typedef unsigned long vtkTypeMTime; >> #else >> typedef vtkTypeUInt64 vtkTypeMTime; >> #endif >> #endif >> >> >> On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci wrote: >>> I also prefer vtkTypeUInt64 but not a strong preference. Both look good to >>> me. >>> >>> On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin wrote: >>>> >>>> Oh, I am fine with the approach you took Bill and so haven't pushed the >>>> other changes I have locally. I just want the 32bit issue fixed as I think >>>> that is really important. I am flexible on how it gets fixed. >>>> >>>> I am not a fan of introducing another typedef as I feel it makes the code >>>> harder to understand, but that is a really small issue and I can definitely >>>> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So once >>>> your topic is baked let's get it committed. >>>> >>>> Ken >>>> >>>> >>>> >>>> >>>> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen >>>> wrote: >>>>> >>>>> Folks, >>>>> >>>>> We have two topics that fix the Windows mtime overflow issue for >>>>> Windows. This seems like a critical issue for Windows apps that run >>>>> for a long time (e.g. surgical applications). >>>>> >>>>> Topic 1: >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >>>>> Files changed: 376 >>>>> >>>>> Topic 2: >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 >>>>> Files changed: 471 >>>>> >>>>> The major difference is that topic 1 defines MTime as an unsigned long >>>>> and topic 2 introduces a new type vtkTypeMTime. >>>>> >>>>> Topic 2 could be easily changed to use unsigned long for the mtime. >>>>> >>>>> Please take some time to review these topics. I suspect that some >>>>> combination of the two will help solve the problem. >>>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Chairman & CFO >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Clifton Park NY 12065 >>>> 518 371 3971 >>>> >>>> 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 >>>> >>>> >>> >> >> >> >> -- >> 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 Fri Aug 12 16:06:47 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Fri, 12 Aug 2016 16:06:47 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: On Fri, Aug 12, 2016 at 4:03 PM, Bill Lorensen wrote: > +2 Dave > > I wonder if we will need to change in the future... > When we drop support for pre-C++11 compilers, we should probably change to use the new uint64_t everywhere regardless of the size of long. > > > On Fri, Aug 12, 2016 at 3:50 PM, David Cole wrote: > > Think of how easy this fix would have been if vtkTypeMTime had already > > existed ..... > > > > > > > > On Fri, Aug 12, 2016 at 3:43 PM, Bill Lorensen > wrote: > >> One advantage of naming a type is for backward compatibility: > >> // Select an unsigned 64-bit integer type for use in MTime values. > >> // If possible, use 'unsigned long' as we have historically. > >> #if VTK_SIZEOF_LONG == 8 > >> typedef unsigned long vtkTypeMTime; > >> #else > >> typedef vtkTypeUInt64 vtkTypeMTime; > >> #endif > >> > >> also for apps that need to support old and new versions of VTK: > >> // Provide this define to facilitate apps that need to support older > >> // versions that do not have vtkTypeMTime > >> #ifndef VTK_HAS_TYPE_MTIME > >> #if VTK_SIZEOF_LONG == 8 > >> typedef unsigned long vtkTypeMTime; > >> #else > >> typedef vtkTypeUInt64 vtkTypeMTime; > >> #endif > >> #endif > >> > >> > >> On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci > wrote: > >>> I also prefer vtkTypeUInt64 but not a strong preference. Both look > good to > >>> me. > >>> > >>> On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin > wrote: > >>>> > >>>> Oh, I am fine with the approach you took Bill and so haven't pushed > the > >>>> other changes I have locally. I just want the 32bit issue fixed as I > think > >>>> that is really important. I am flexible on how it gets fixed. > >>>> > >>>> I am not a fan of introducing another typedef as I feel it makes the > code > >>>> harder to understand, but that is a really small issue and I can > definitely > >>>> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So > once > >>>> your topic is baked let's get it committed. > >>>> > >>>> Ken > >>>> > >>>> > >>>> > >>>> > >>>> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen < > bill.lorensen at gmail.com> > >>>> wrote: > >>>>> > >>>>> Folks, > >>>>> > >>>>> We have two topics that fix the Windows mtime overflow issue for > >>>>> Windows. This seems like a critical issue for Windows apps that run > >>>>> for a long time (e.g. surgical applications). > >>>>> > >>>>> Topic 1: > >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 > >>>>> Files changed: 376 > >>>>> > >>>>> Topic 2: > >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 > >>>>> Files changed: 471 > >>>>> > >>>>> The major difference is that topic 1 defines MTime as an unsigned > long > >>>>> and topic 2 introduces a new type vtkTypeMTime. > >>>>> > >>>>> Topic 2 could be easily changed to use unsigned long for the mtime. > >>>>> > >>>>> Please take some time to review these topics. I suspect that some > >>>>> combination of the two will help solve the problem. > >>>>> > >>>>> 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 > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Ken Martin PhD > >>>> Chairman & CFO > >>>> Kitware Inc. > >>>> 28 Corporate Drive > >>>> Clifton Park NY 12065 > >>>> 518 371 3971 > >>>> > >>>> 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 > >>>> > >>>> > >>> > >> > >> > >> > >> -- > >> 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 > _______________________________________________ > 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 Fri Aug 12 16:14:24 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 12 Aug 2016 16:14:24 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: +2 good point. Using a typedef is probably a good idea. On Fri, Aug 12, 2016 at 4:06 PM, Shawn Waldon wrote: > On Fri, Aug 12, 2016 at 4:03 PM, Bill Lorensen > wrote: >> >> +2 Dave >> >> I wonder if we will need to change in the future... > > > When we drop support for pre-C++11 compilers, we should probably change to > use the new uint64_t everywhere regardless of the size of long. >> >> >> >> On Fri, Aug 12, 2016 at 3:50 PM, David Cole wrote: >> > Think of how easy this fix would have been if vtkTypeMTime had already >> > existed ..... >> > >> > >> > >> > On Fri, Aug 12, 2016 at 3:43 PM, Bill Lorensen >> > wrote: >> >> One advantage of naming a type is for backward compatibility: >> >> // Select an unsigned 64-bit integer type for use in MTime values. >> >> // If possible, use 'unsigned long' as we have historically. >> >> #if VTK_SIZEOF_LONG == 8 >> >> typedef unsigned long vtkTypeMTime; >> >> #else >> >> typedef vtkTypeUInt64 vtkTypeMTime; >> >> #endif >> >> >> >> also for apps that need to support old and new versions of VTK: >> >> // Provide this define to facilitate apps that need to support older >> >> // versions that do not have vtkTypeMTime >> >> #ifndef VTK_HAS_TYPE_MTIME >> >> #if VTK_SIZEOF_LONG == 8 >> >> typedef unsigned long vtkTypeMTime; >> >> #else >> >> typedef vtkTypeUInt64 vtkTypeMTime; >> >> #endif >> >> #endif >> >> >> >> >> >> On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci >> >> wrote: >> >>> I also prefer vtkTypeUInt64 but not a strong preference. Both look >> >>> good to >> >>> me. >> >>> >> >>> On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin >> >>> wrote: >> >>>> >> >>>> Oh, I am fine with the approach you took Bill and so haven't pushed >> >>>> the >> >>>> other changes I have locally. I just want the 32bit issue fixed as I >> >>>> think >> >>>> that is really important. I am flexible on how it gets fixed. >> >>>> >> >>>> I am not a fan of introducing another typedef as I feel it makes the >> >>>> code >> >>>> harder to understand, but that is a really small issue and I can >> >>>> definitely >> >>>> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So >> >>>> once >> >>>> your topic is baked let's get it committed. >> >>>> >> >>>> Ken >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen >> >>>> >> >>>> wrote: >> >>>>> >> >>>>> Folks, >> >>>>> >> >>>>> We have two topics that fix the Windows mtime overflow issue for >> >>>>> Windows. This seems like a critical issue for Windows apps that run >> >>>>> for a long time (e.g. surgical applications). >> >>>>> >> >>>>> Topic 1: >> >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >> >>>>> Files changed: 376 >> >>>>> >> >>>>> Topic 2: >> >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 >> >>>>> Files changed: 471 >> >>>>> >> >>>>> The major difference is that topic 1 defines MTime as an unsigned >> >>>>> long >> >>>>> and topic 2 introduces a new type vtkTypeMTime. >> >>>>> >> >>>>> Topic 2 could be easily changed to use unsigned long for the mtime. >> >>>>> >> >>>>> Please take some time to review these topics. I suspect that some >> >>>>> combination of the two will help solve the problem. >> >>>>> >> >>>>> 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 >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Ken Martin PhD >> >>>> Chairman & CFO >> >>>> Kitware Inc. >> >>>> 28 Corporate Drive >> >>>> Clifton Park NY 12065 >> >>>> 518 371 3971 >> >>>> >> >>>> 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 >> >>>> >> >>>> >> >>> >> >> >> >> >> >> >> >> -- >> >> 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 >> _______________________________________________ >> 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 pmattern at arcor.de Sat Aug 13 08:29:57 2016 From: pmattern at arcor.de (Peter Mattern) Date: Sat, 13 Aug 2016 14:29:57 +0200 Subject: [vtk-developers] Mantis -> Gitlab issue migration In-Reply-To: <20160812194917.GA1790@megas.kitware.com> References: <20160810153725.GA12991@megas.kitware.com> <20160812115829.GC10731@megas.kitware.com> <56643b7a8df6768a4d3cd6e71fb8535a@arcor.de> <20160812194917.GA1790@megas.kitware.com> Message-ID: <6a3457cc41476ca34250fe4f3cbfde14@arcor.de> Thanks for clarifying. I've transferred some notes I deemed good to have. On a side note link "Bug Tracker" in drop-down "Developer Tools" at www.vtk.org is still pointing to the Mantis tracker while link "Bug Tracker" (and corresponding icon) at http://www.vtk.org/developer-tools/ is just faulty. From shawn.waldon at kitware.com Mon Aug 15 11:59:58 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 15 Aug 2016 11:59:58 -0400 Subject: [vtk-developers] Marking data modified Message-ID: Hi all, I have been tracking down a bug in the vtkBoxRepresentation where the selected face never updated. The issue was that the widget was calling ReplaceCell on the vtkCellArray for the selected face polydata, but never calling Modified() on the cell array (though it did call Modified() on the polydata). With the new OpenGL backend this matters. The documentation for ReplaceCell doesn't say that you have to do this afterward and the writer of vtkBoxRepresentation used that documentation. So my question is this: why doesn't ReplaceCell mark the cell array as modified? Is this a bug or on purpose for performance reasons? I will update the docs or fix ReplaceCell once I know which is wrong. Thank you, Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From joaolsvieira at gmail.com Mon Aug 15 12:09:36 2016 From: joaolsvieira at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Luis?=) Date: Mon, 15 Aug 2016 12:09:36 -0400 Subject: [vtk-developers] Fwd: vtkArcSource vs vtkEllipseArcSource Message-ID: Hello vtkusers, I have VTK 7.0 and I am drawing an Arc against a plane surface. This Arc is a representation of a Geometry(e.g. Plane). I have an algorithm that by user information of Azimuth/Strike and Plunge/Dip returns a set of vtkPoints. With these points, I am building a line using vtkLineSource to represent my Plane/Arc as well as expected (attached pictures PlaneArc1 and PlaneArc2) and worked smoothly. Snapshot Code: vtkSmartPointer PointViewGC = MyFunction(235/*Azimuth*/, 225/*Plunge*/); vtkSmartPointer lineDataGCO = vtkSmartPointer::New(); lineDataGCO->SetPoints(PointViewGC); However, I am trying do the same with vtk ArcSource using the same set of Points, but the result is not the correct.(Attached picture ArcSource1) Snapshot Code: vtkSmartPointer arcSource = vtkSmartPointer: :New(); arcSource->SetAngle(225); arcSource->SetResolution(40); vtkIdType numPts = PointViewGC->GetNumberOfPoints()-1; double point1[3]; PointViewGC->GetPoint(1,point1); double point2[3]; PointViewGC->GetPoint(numPts, point2); arcSource->SetPoint1(point1); arcSource->SetPoint1(point2); arcSource->NegativeOff(); arcSource->UseNormalAndAngleOn(); After some research I found out that VTK 7 doesn't released vtkEllipseArcSource classes, then I decided download from ( https://github.com/Kitware/VTK). The point is there anybody knows what's wrong in my code? If vtkArcSource could handle itself my goals to draw this geometry? And/or if vtkEllipseArcSource could solve my problem to justify I do again a compilation of VTK just to integrate this class? Many thanks for any help. Regards, Luis. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ArcSource1.png Type: image/png Size: 18753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PlaneArc1.png Type: image/png Size: 20637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PlaneArc2.png Type: image/png Size: 25041 bytes Desc: not available URL: From DLRdave at aol.com Mon Aug 15 12:54:47 2016 From: DLRdave at aol.com (David Cole) Date: Mon, 15 Aug 2016 12:54:47 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: I don't specifically know the answer to this one, but in general, these sorts of things are on purpose for performance in VTK. If you want to replace 100 (or even more) cells, you'd want ReplaceCell NOT to call Modified, and just do it once at the end of your bulk replacement. I'd be surprised if somebody chimed in and contradicted this... so I would think just fixing the docs is the right way to go here. HTH, David C. On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon wrote: > Hi all, > > I have been tracking down a bug in the vtkBoxRepresentation where the > selected face never updated. The issue was that the widget was calling > ReplaceCell on the vtkCellArray for the selected face polydata, but never > calling Modified() on the cell array (though it did call Modified() on the > polydata). With the new OpenGL backend this matters. The documentation for > ReplaceCell doesn't say that you have to do this afterward and the writer of > vtkBoxRepresentation used that documentation. > > So my question is this: why doesn't ReplaceCell mark the cell array as > modified? Is this a bug or on purpose for performance reasons? I will > update the docs or fix ReplaceCell once I know which is wrong. > > Thank you, > Shawn > > _______________________________________________ > 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 berk.geveci at kitware.com Mon Aug 15 12:55:41 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 15 Aug 2016 12:55:41 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: I agree with David. On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < vtk-developers at vtk.org> wrote: > I don't specifically know the answer to this one, but in general, > these sorts of things are on purpose for performance in VTK. > > If you want to replace 100 (or even more) cells, you'd want > ReplaceCell NOT to call Modified, and just do it once at the end of > your bulk replacement. I'd be surprised if somebody chimed in and > contradicted this... so I would think just fixing the docs is the > right way to go here. > > > HTH, > David C. > > > On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon > wrote: > > Hi all, > > > > I have been tracking down a bug in the vtkBoxRepresentation where the > > selected face never updated. The issue was that the widget was calling > > ReplaceCell on the vtkCellArray for the selected face polydata, but never > > calling Modified() on the cell array (though it did call Modified() on > the > > polydata). With the new OpenGL backend this matters. The documentation > for > > ReplaceCell doesn't say that you have to do this afterward and the > writer of > > vtkBoxRepresentation used that documentation. > > > > So my question is this: why doesn't ReplaceCell mark the cell array as > > modified? Is this a bug or on purpose for performance reasons? I will > > update the docs or fix ReplaceCell once I know which is wrong. > > > > Thank you, > > Shawn > > > > _______________________________________________ > > 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 shawn.waldon at kitware.com Mon Aug 15 13:25:57 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 15 Aug 2016 13:25:57 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Thanks David & Berk, Ok, I'll add a commit to my branch to update the docs and add you as reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. This function figures out which cell array the cell is in and then calls ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So the caller may not know which cell array to call Modified on. What should we do in this case? Shawn On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci wrote: > I agree with David. > > On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < > vtk-developers at vtk.org> wrote: > >> I don't specifically know the answer to this one, but in general, >> these sorts of things are on purpose for performance in VTK. >> >> If you want to replace 100 (or even more) cells, you'd want >> ReplaceCell NOT to call Modified, and just do it once at the end of >> your bulk replacement. I'd be surprised if somebody chimed in and >> contradicted this... so I would think just fixing the docs is the >> right way to go here. >> >> >> HTH, >> David C. >> >> >> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon >> wrote: >> > Hi all, >> > >> > I have been tracking down a bug in the vtkBoxRepresentation where the >> > selected face never updated. The issue was that the widget was calling >> > ReplaceCell on the vtkCellArray for the selected face polydata, but >> never >> > calling Modified() on the cell array (though it did call Modified() on >> the >> > polydata). With the new OpenGL backend this matters. The >> documentation for >> > ReplaceCell doesn't say that you have to do this afterward and the >> writer of >> > vtkBoxRepresentation used that documentation. >> > >> > So my question is this: why doesn't ReplaceCell mark the cell array as >> > modified? Is this a bug or on purpose for performance reasons? I will >> > update the docs or fix ReplaceCell once I know which is wrong. >> > >> > Thank you, >> > Shawn >> > >> > _______________________________________________ >> > 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 berk.geveci at kitware.com Mon Aug 15 14:36:24 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 15 Aug 2016 14:36:24 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Can you provide a bit more detail? Who's MTime is important in this case? Note that vtkPolyData does not take into account the MTime of the underlying vtkCellArrays when computing its own MTime. So if the MTime of the polydata is becoming stale, simply calling Modified() on it should be sufficient. As far as I can tell, vtkCellArray does nothing with MTime. On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon wrote: > Thanks David & Berk, > > Ok, I'll add a commit to my branch to update the docs and add you as > reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. > This function figures out which cell array the cell is in and then calls > ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So > the caller may not know which cell array to call Modified on. What should > we do in this case? > > Shawn > > On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci > wrote: > >> I agree with David. >> >> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >> vtk-developers at vtk.org> wrote: >> >>> I don't specifically know the answer to this one, but in general, >>> these sorts of things are on purpose for performance in VTK. >>> >>> If you want to replace 100 (or even more) cells, you'd want >>> ReplaceCell NOT to call Modified, and just do it once at the end of >>> your bulk replacement. I'd be surprised if somebody chimed in and >>> contradicted this... so I would think just fixing the docs is the >>> right way to go here. >>> >>> >>> HTH, >>> David C. >>> >>> >>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon >>> wrote: >>> > Hi all, >>> > >>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>> > selected face never updated. The issue was that the widget was calling >>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>> never >>> > calling Modified() on the cell array (though it did call Modified() on >>> the >>> > polydata). With the new OpenGL backend this matters. The >>> documentation for >>> > ReplaceCell doesn't say that you have to do this afterward and the >>> writer of >>> > vtkBoxRepresentation used that documentation. >>> > >>> > So my question is this: why doesn't ReplaceCell mark the cell array as >>> > modified? Is this a bug or on purpose for performance reasons? I will >>> > update the docs or fix ReplaceCell once I know which is wrong. >>> > >>> > Thank you, >>> > Shawn >>> > >>> > _______________________________________________ >>> > 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 ken.martin at kitware.com Mon Aug 15 14:47:18 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 15 Aug 2016 14:47:18 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: It is that someone is changing the data in the cell array but not marking them modified. In OpenGL2 I look at the mtime of a cell array to determine if I need to rebuild and re-upload that array. If points change I rebuild the VBO, if a cell array changes I rebuild the the relavent IBO. The result of that is that if someone changes the points or cells without marking the array as modified they do not get rebuilt/uploaded. So polydata->GetPoints()->SetTuple(0,0,0,0); ren->Render(); will not work. Nor will polydata->GetPoints()->SetTuple(0,0,0,0); polydata->Modified(); ren->Render(); you actually need to mark as modified the VTK object you modified for it to work. In this case polydata->GetPoints()->SetTuple(0,0,0,0); polydata->GetPoints()->Modified(); ren->Render(); On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci wrote: > Can you provide a bit more detail? Who's MTime is important in this case? > Note that vtkPolyData does not take into account the MTime of the > underlying vtkCellArrays when computing its own MTime. So if the MTime of > the polydata is becoming stale, simply calling Modified() on it should be > sufficient. As far as I can tell, vtkCellArray does nothing with MTime. > > On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon > wrote: > >> Thanks David & Berk, >> >> Ok, I'll add a commit to my branch to update the docs and add you as >> reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. >> This function figures out which cell array the cell is in and then calls >> ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So >> the caller may not know which cell array to call Modified on. What should >> we do in this case? >> >> Shawn >> >> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci >> wrote: >> >>> I agree with David. >>> >>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>> vtk-developers at vtk.org> wrote: >>> >>>> I don't specifically know the answer to this one, but in general, >>>> these sorts of things are on purpose for performance in VTK. >>>> >>>> If you want to replace 100 (or even more) cells, you'd want >>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>> contradicted this... so I would think just fixing the docs is the >>>> right way to go here. >>>> >>>> >>>> HTH, >>>> David C. >>>> >>>> >>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>> shawn.waldon at kitware.com> wrote: >>>> > Hi all, >>>> > >>>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>>> > selected face never updated. The issue was that the widget was >>>> calling >>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>>> never >>>> > calling Modified() on the cell array (though it did call Modified() >>>> on the >>>> > polydata). With the new OpenGL backend this matters. The >>>> documentation for >>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>> writer of >>>> > vtkBoxRepresentation used that documentation. >>>> > >>>> > So my question is this: why doesn't ReplaceCell mark the cell array as >>>> > modified? Is this a bug or on purpose for performance reasons? I will >>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>> > >>>> > Thank you, >>>> > Shawn >>>> > >>>> > _______________________________________________ >>>> > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 shawn.waldon at kitware.com Mon Aug 15 14:48:42 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 15 Aug 2016 14:48:42 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: See the example script on this bug report: https://gitlab.kitware.com/vtk/vtk/issues/16812. It is calling Modified() on the polydata, but to actually see the updated geometry, you have to add pdata.GetPolys().Modified(). And I can only say that for sure because I know the cell in question is polygonal. ReplaceCell doesn't tell the caller which cell array needs to be updated. Shawn On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci wrote: > Can you provide a bit more detail? Who's MTime is important in this case? > Note that vtkPolyData does not take into account the MTime of the > underlying vtkCellArrays when computing its own MTime. So if the MTime of > the polydata is becoming stale, simply calling Modified() on it should be > sufficient. As far as I can tell, vtkCellArray does nothing with MTime. > > On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon > wrote: > >> Thanks David & Berk, >> >> Ok, I'll add a commit to my branch to update the docs and add you as >> reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. >> This function figures out which cell array the cell is in and then calls >> ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So >> the caller may not know which cell array to call Modified on. What should >> we do in this case? >> >> Shawn >> >> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci >> wrote: >> >>> I agree with David. >>> >>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>> vtk-developers at vtk.org> wrote: >>> >>>> I don't specifically know the answer to this one, but in general, >>>> these sorts of things are on purpose for performance in VTK. >>>> >>>> If you want to replace 100 (or even more) cells, you'd want >>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>> contradicted this... so I would think just fixing the docs is the >>>> right way to go here. >>>> >>>> >>>> HTH, >>>> David C. >>>> >>>> >>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>> shawn.waldon at kitware.com> wrote: >>>> > Hi all, >>>> > >>>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>>> > selected face never updated. The issue was that the widget was >>>> calling >>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>>> never >>>> > calling Modified() on the cell array (though it did call Modified() >>>> on the >>>> > polydata). With the new OpenGL backend this matters. The >>>> documentation for >>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>> writer of >>>> > vtkBoxRepresentation used that documentation. >>>> > >>>> > So my question is this: why doesn't ReplaceCell mark the cell array as >>>> > modified? Is this a bug or on purpose for performance reasons? I will >>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>> > >>>> > Thank you, >>>> > Shawn >>>> > >>>> > _______________________________________________ >>>> > 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 will.schroeder at kitware.com Mon Aug 15 14:53:37 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 15 Aug 2016 14:53:37 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Why can't you instead of: this->HexFacePolyData->Modified(); cells->ReplaceCell(0,npts,pts) do: cells->Modified(); cells->ReplaceCell(0,npts,pts) Best, W On Mon, Aug 15, 2016 at 2:48 PM, Shawn Waldon wrote: > See the example script on this bug report: https://gitlab.kitware.com/ > vtk/vtk/issues/16812. It is calling Modified() on the polydata, but to > actually see the updated geometry, you have to add > pdata.GetPolys().Modified(). And I can only say that for sure because I > know the cell in question is polygonal. ReplaceCell doesn't tell the > caller which cell array needs to be updated. > > Shawn > > On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci > wrote: > >> Can you provide a bit more detail? Who's MTime is important in this case? >> Note that vtkPolyData does not take into account the MTime of the >> underlying vtkCellArrays when computing its own MTime. So if the MTime of >> the polydata is becoming stale, simply calling Modified() on it should be >> sufficient. As far as I can tell, vtkCellArray does nothing with MTime. >> >> On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon >> wrote: >> >>> Thanks David & Berk, >>> >>> Ok, I'll add a commit to my branch to update the docs and add you as >>> reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. >>> This function figures out which cell array the cell is in and then calls >>> ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So >>> the caller may not know which cell array to call Modified on. What should >>> we do in this case? >>> >>> Shawn >>> >>> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci >>> wrote: >>> >>>> I agree with David. >>>> >>>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>>> vtk-developers at vtk.org> wrote: >>>> >>>>> I don't specifically know the answer to this one, but in general, >>>>> these sorts of things are on purpose for performance in VTK. >>>>> >>>>> If you want to replace 100 (or even more) cells, you'd want >>>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>>> contradicted this... so I would think just fixing the docs is the >>>>> right way to go here. >>>>> >>>>> >>>>> HTH, >>>>> David C. >>>>> >>>>> >>>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>>> shawn.waldon at kitware.com> wrote: >>>>> > Hi all, >>>>> > >>>>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>>>> > selected face never updated. The issue was that the widget was >>>>> calling >>>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>>>> never >>>>> > calling Modified() on the cell array (though it did call Modified() >>>>> on the >>>>> > polydata). With the new OpenGL backend this matters. The >>>>> documentation for >>>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>>> writer of >>>>> > vtkBoxRepresentation used that documentation. >>>>> > >>>>> > So my question is this: why doesn't ReplaceCell mark the cell array >>>>> as >>>>> > modified? Is this a bug or on purpose for performance reasons? I >>>>> will >>>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>>> > >>>>> > Thank you, >>>>> > Shawn >>>>> > >>>>> > _______________________________________________ >>>>> > 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 > > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Mon Aug 15 14:57:41 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 15 Aug 2016 14:57:41 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Will, See my merge request here: https://gitlab.kitware.com/vtk/vtk/merge_requests/1818 for that change. I didn't get rid of the line that marks the polydata as updated because I think the old rendering backend needs it. I was planning to add these docs changes to the same branch as soon as I figure out what else needs changing. Shawn On Mon, Aug 15, 2016 at 2:53 PM, Will Schroeder wrote: > Why can't you instead of: > > this->HexFacePolyData->Modified(); > cells->ReplaceCell(0,npts,pts) > > do: > > cells->Modified(); > cells->ReplaceCell(0,npts,pts) > > Best, > W > > > > On Mon, Aug 15, 2016 at 2:48 PM, Shawn Waldon > wrote: > >> See the example script on this bug report: https://gitlab.kitware.com/vtk >> /vtk/issues/16812. It is calling Modified() on the polydata, but to >> actually see the updated geometry, you have to add >> pdata.GetPolys().Modified(). And I can only say that for sure because I >> know the cell in question is polygonal. ReplaceCell doesn't tell the >> caller which cell array needs to be updated. >> >> Shawn >> >> On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci >> wrote: >> >>> Can you provide a bit more detail? Who's MTime is important in this >>> case? Note that vtkPolyData does not take into account the MTime of the >>> underlying vtkCellArrays when computing its own MTime. So if the MTime of >>> the polydata is becoming stale, simply calling Modified() on it should be >>> sufficient. As far as I can tell, vtkCellArray does nothing with MTime. >>> >>> On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon >>> wrote: >>> >>>> Thanks David & Berk, >>>> >>>> Ok, I'll add a commit to my branch to update the docs and add you as >>>> reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. >>>> This function figures out which cell array the cell is in and then calls >>>> ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So >>>> the caller may not know which cell array to call Modified on. What should >>>> we do in this case? >>>> >>>> Shawn >>>> >>>> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci >>>> wrote: >>>> >>>>> I agree with David. >>>>> >>>>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>>>> vtk-developers at vtk.org> wrote: >>>>> >>>>>> I don't specifically know the answer to this one, but in general, >>>>>> these sorts of things are on purpose for performance in VTK. >>>>>> >>>>>> If you want to replace 100 (or even more) cells, you'd want >>>>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>>>> contradicted this... so I would think just fixing the docs is the >>>>>> right way to go here. >>>>>> >>>>>> >>>>>> HTH, >>>>>> David C. >>>>>> >>>>>> >>>>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>>>> shawn.waldon at kitware.com> wrote: >>>>>> > Hi all, >>>>>> > >>>>>> > I have been tracking down a bug in the vtkBoxRepresentation where >>>>>> the >>>>>> > selected face never updated. The issue was that the widget was >>>>>> calling >>>>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>>>>> never >>>>>> > calling Modified() on the cell array (though it did call Modified() >>>>>> on the >>>>>> > polydata). With the new OpenGL backend this matters. The >>>>>> documentation for >>>>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>>>> writer of >>>>>> > vtkBoxRepresentation used that documentation. >>>>>> > >>>>>> > So my question is this: why doesn't ReplaceCell mark the cell array >>>>>> as >>>>>> > modified? Is this a bug or on purpose for performance reasons? I >>>>>> will >>>>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>>>> > >>>>>> > Thank you, >>>>>> > Shawn >>>>>> > >>>>>> > _______________________________________________ >>>>>> > 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 >> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Aug 15 15:07:34 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 15 Aug 2016 15:07:34 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Argh I hate vtkPolyData. Yeah, if the rendering code is looking at the MTime of the cell arrays, the caller has to know which one got modified and call Modified() on it. Hopefully, sometime not too long in the future, we can find a way of separating the various cell arrays into their own data objects and not have this mess. On Mon, Aug 15, 2016 at 2:57 PM, Shawn Waldon wrote: > Will, > > See my merge request here: https://gitlab.kitware.com/ > vtk/vtk/merge_requests/1818 for that change. I didn't get rid of the > line that marks the polydata as updated because I think the old rendering > backend needs it. I was planning to add these docs changes to the same > branch as soon as I figure out what else needs changing. > > Shawn > > On Mon, Aug 15, 2016 at 2:53 PM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Why can't you instead of: >> >> this->HexFacePolyData->Modified(); >> cells->ReplaceCell(0,npts,pts) >> >> do: >> >> cells->Modified(); >> cells->ReplaceCell(0,npts,pts) >> >> Best, >> W >> >> >> >> On Mon, Aug 15, 2016 at 2:48 PM, Shawn Waldon >> wrote: >> >>> See the example script on this bug report: >>> https://gitlab.kitware.com/vtk/vtk/issues/16812. It is calling >>> Modified() on the polydata, but to actually see the updated geometry, you >>> have to add pdata.GetPolys().Modified(). And I can only say that for sure >>> because I know the cell in question is polygonal. ReplaceCell doesn't tell >>> the caller which cell array needs to be updated. >>> >>> Shawn >>> >>> On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci >>> wrote: >>> >>>> Can you provide a bit more detail? Who's MTime is important in this >>>> case? Note that vtkPolyData does not take into account the MTime of the >>>> underlying vtkCellArrays when computing its own MTime. So if the MTime of >>>> the polydata is becoming stale, simply calling Modified() on it should be >>>> sufficient. As far as I can tell, vtkCellArray does nothing with MTime. >>>> >>>> On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon >>> > wrote: >>>> >>>>> Thanks David & Berk, >>>>> >>>>> Ok, I'll add a commit to my branch to update the docs and add you as >>>>> reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. >>>>> This function figures out which cell array the cell is in and then calls >>>>> ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So >>>>> the caller may not know which cell array to call Modified on. What should >>>>> we do in this case? >>>>> >>>>> Shawn >>>>> >>>>> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci >>>> > wrote: >>>>> >>>>>> I agree with David. >>>>>> >>>>>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>>>>> vtk-developers at vtk.org> wrote: >>>>>> >>>>>>> I don't specifically know the answer to this one, but in general, >>>>>>> these sorts of things are on purpose for performance in VTK. >>>>>>> >>>>>>> If you want to replace 100 (or even more) cells, you'd want >>>>>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>>>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>>>>> contradicted this... so I would think just fixing the docs is the >>>>>>> right way to go here. >>>>>>> >>>>>>> >>>>>>> HTH, >>>>>>> David C. >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>>>>> shawn.waldon at kitware.com> wrote: >>>>>>> > Hi all, >>>>>>> > >>>>>>> > I have been tracking down a bug in the vtkBoxRepresentation where >>>>>>> the >>>>>>> > selected face never updated. The issue was that the widget was >>>>>>> calling >>>>>>> > ReplaceCell on the vtkCellArray for the selected face polydata, >>>>>>> but never >>>>>>> > calling Modified() on the cell array (though it did call >>>>>>> Modified() on the >>>>>>> > polydata). With the new OpenGL backend this matters. The >>>>>>> documentation for >>>>>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>>>>> writer of >>>>>>> > vtkBoxRepresentation used that documentation. >>>>>>> > >>>>>>> > So my question is this: why doesn't ReplaceCell mark the cell >>>>>>> array as >>>>>>> > modified? Is this a bug or on purpose for performance reasons? I >>>>>>> will >>>>>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>>>>> > >>>>>>> > Thank you, >>>>>>> > Shawn >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > 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 >>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Aug 15 15:16:40 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 15 Aug 2016 15:16:40 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: There are lots of possible solutions, another is to build a next generation unstructured grid data structure that supports adaptive, on-demand construction of topology (sort of like polydata does now with cell links, etc.) including explicit, adaptive representation of edges and faces. It could support both polygonal (i.e., graphics representations) and meshes (combinations of 0-3D cells). We've experimented with this and shown good early results. The original polydata structure was designed probably 25 years ago and was targeted at the graphics systems of the time; we initially thought that if it lasted 10 years it would be an achievement. It's time to begin the great migration IMO, we need to think bigger :-) Best, W On Mon, Aug 15, 2016 at 3:07 PM, Berk Geveci wrote: > Argh I hate vtkPolyData. Yeah, if the rendering code is looking at the > MTime of the cell arrays, the caller has to know which one got modified and > call Modified() on it. Hopefully, sometime not too long in the future, we > can find a way of separating the various cell arrays into their own data > objects and not have this mess. > > On Mon, Aug 15, 2016 at 2:57 PM, Shawn Waldon > wrote: > >> Will, >> >> See my merge request here: https://gitlab.kitware.com/vtk >> /vtk/merge_requests/1818 for that change. I didn't get rid of the line >> that marks the polydata as updated because I think the old rendering >> backend needs it. I was planning to add these docs changes to the same >> branch as soon as I figure out what else needs changing. >> >> Shawn >> >> On Mon, Aug 15, 2016 at 2:53 PM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Why can't you instead of: >>> >>> this->HexFacePolyData->Modified(); >>> cells->ReplaceCell(0,npts,pts) >>> >>> do: >>> >>> cells->Modified(); >>> cells->ReplaceCell(0,npts,pts) >>> >>> Best, >>> W >>> >>> >>> >>> On Mon, Aug 15, 2016 at 2:48 PM, Shawn Waldon >>> wrote: >>> >>>> See the example script on this bug report: >>>> https://gitlab.kitware.com/vtk/vtk/issues/16812. It is calling >>>> Modified() on the polydata, but to actually see the updated geometry, you >>>> have to add pdata.GetPolys().Modified(). And I can only say that for sure >>>> because I know the cell in question is polygonal. ReplaceCell doesn't tell >>>> the caller which cell array needs to be updated. >>>> >>>> Shawn >>>> >>>> On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci >>>> wrote: >>>> >>>>> Can you provide a bit more detail? Who's MTime is important in this >>>>> case? Note that vtkPolyData does not take into account the MTime of the >>>>> underlying vtkCellArrays when computing its own MTime. So if the MTime of >>>>> the polydata is becoming stale, simply calling Modified() on it should be >>>>> sufficient. As far as I can tell, vtkCellArray does nothing with MTime. >>>>> >>>>> On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon < >>>>> shawn.waldon at kitware.com> wrote: >>>>> >>>>>> Thanks David & Berk, >>>>>> >>>>>> Ok, I'll add a commit to my branch to update the docs and add you as >>>>>> reviewers. I have a follow-up question though: vtkPolyData::ReplaceCell. >>>>>> This function figures out which cell array the cell is in and then calls >>>>>> ReplaceCell on that one. It can be in Verts, Lines, Polys, or Strips. So >>>>>> the caller may not know which cell array to call Modified on. What should >>>>>> we do in this case? >>>>>> >>>>>> Shawn >>>>>> >>>>>> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci < >>>>>> berk.geveci at kitware.com> wrote: >>>>>> >>>>>>> I agree with David. >>>>>>> >>>>>>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>>>>>> vtk-developers at vtk.org> wrote: >>>>>>> >>>>>>>> I don't specifically know the answer to this one, but in general, >>>>>>>> these sorts of things are on purpose for performance in VTK. >>>>>>>> >>>>>>>> If you want to replace 100 (or even more) cells, you'd want >>>>>>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>>>>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>>>>>> contradicted this... so I would think just fixing the docs is the >>>>>>>> right way to go here. >>>>>>>> >>>>>>>> >>>>>>>> HTH, >>>>>>>> David C. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>>>>>> shawn.waldon at kitware.com> wrote: >>>>>>>> > Hi all, >>>>>>>> > >>>>>>>> > I have been tracking down a bug in the vtkBoxRepresentation where >>>>>>>> the >>>>>>>> > selected face never updated. The issue was that the widget was >>>>>>>> calling >>>>>>>> > ReplaceCell on the vtkCellArray for the selected face polydata, >>>>>>>> but never >>>>>>>> > calling Modified() on the cell array (though it did call >>>>>>>> Modified() on the >>>>>>>> > polydata). With the new OpenGL backend this matters. The >>>>>>>> documentation for >>>>>>>> > ReplaceCell doesn't say that you have to do this afterward and >>>>>>>> the writer of >>>>>>>> > vtkBoxRepresentation used that documentation. >>>>>>>> > >>>>>>>> > So my question is this: why doesn't ReplaceCell mark the cell >>>>>>>> array as >>>>>>>> > modified? Is this a bug or on purpose for performance reasons? I >>>>>>>> will >>>>>>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>>>>>> > >>>>>>>> > Thank you, >>>>>>>> > Shawn >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > 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 >>>> >>>> >>>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. - Building the World's Technical Computing Software >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >>> >> >> > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Aug 15 15:17:17 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 15 Aug 2016 15:17:17 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: FYI- Just to provide more background context: there are several triangulation classes like vtkDelaunay2D, vtkQuadricDecimation, and vtkGreedyTerrainDecimation that routinely swap the diagonal of the quadrilateral consisting of two adjacent triangles (sharing an edge). The edge swap is done to improve the triangulation quality. As Dave and Berk indicated, this is considered an atomic operation performed in tight loops so it is expected that Modified() is called at the end. Best, W On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < vtk-developers at vtk.org> wrote: > I don't specifically know the answer to this one, but in general, > these sorts of things are on purpose for performance in VTK. > > If you want to replace 100 (or even more) cells, you'd want > ReplaceCell NOT to call Modified, and just do it once at the end of > your bulk replacement. I'd be surprised if somebody chimed in and > contradicted this... so I would think just fixing the docs is the > right way to go here. > > > HTH, > David C. > > > On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon > wrote: > > Hi all, > > > > I have been tracking down a bug in the vtkBoxRepresentation where the > > selected face never updated. The issue was that the widget was calling > > ReplaceCell on the vtkCellArray for the selected face polydata, but never > > calling Modified() on the cell array (though it did call Modified() on > the > > polydata). With the new OpenGL backend this matters. The documentation > for > > ReplaceCell doesn't say that you have to do this afterward and the > writer of > > vtkBoxRepresentation used that documentation. > > > > So my question is this: why doesn't ReplaceCell mark the cell array as > > modified? Is this a bug or on purpose for performance reasons? I will > > update the docs or fix ReplaceCell once I know which is wrong. > > > > Thank you, > > Shawn > > > > _______________________________________________ > > 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 > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Mon Aug 15 15:39:55 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 15 Aug 2016 15:39:55 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Ok, so what should be added to the documentation on vtkPolyData::ReplaceCell? // This operation modifies one of the vtkCellArrays contained in this vtkPolyData. In order for this change to be picked up by the rendering system, Modified() must be called on that vtkCellArray. (What goes here to help them figure out which cell array to call Modified() on????) I think that at least for now we have to change vtkPolyData::ReplaceCell to either call Modified() on the correct vtkCellArray or return something to indicate to the user which cell array they need to modify. I lean toward the first, and just add a line in the method's documentation saying that this is not recommended for tight loops and to use ReplaceCell on the vtkCellArrays if you need to change many cells in tight loops. This method is already doing lookups to determine which cell array to modify and a switch to do it, which is not something you really want in tight loops. Shawn On Mon, Aug 15, 2016 at 3:17 PM, Will Schroeder wrote: > FYI- Just to provide more background context: there are several > triangulation classes like vtkDelaunay2D, vtkQuadricDecimation, and > vtkGreedyTerrainDecimation that routinely swap the diagonal of the > quadrilateral consisting of two adjacent triangles (sharing an edge). The > edge swap is done to improve the triangulation quality. As Dave and Berk > indicated, this is considered an atomic operation performed in tight loops > so it is expected that Modified() is called at the end. > > Best, > W > > On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < > vtk-developers at vtk.org> wrote: > >> I don't specifically know the answer to this one, but in general, >> these sorts of things are on purpose for performance in VTK. >> >> If you want to replace 100 (or even more) cells, you'd want >> ReplaceCell NOT to call Modified, and just do it once at the end of >> your bulk replacement. I'd be surprised if somebody chimed in and >> contradicted this... so I would think just fixing the docs is the >> right way to go here. >> >> >> HTH, >> David C. >> >> >> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon >> wrote: >> > Hi all, >> > >> > I have been tracking down a bug in the vtkBoxRepresentation where the >> > selected face never updated. The issue was that the widget was calling >> > ReplaceCell on the vtkCellArray for the selected face polydata, but >> never >> > calling Modified() on the cell array (though it did call Modified() on >> the >> > polydata). With the new OpenGL backend this matters. The >> documentation for >> > ReplaceCell doesn't say that you have to do this afterward and the >> writer of >> > vtkBoxRepresentation used that documentation. >> > >> > So my question is this: why doesn't ReplaceCell mark the cell array as >> > modified? Is this a bug or on purpose for performance reasons? I will >> > update the docs or fix ReplaceCell once I know which is wrong. >> > >> > Thank you, >> > Shawn >> > >> > _______________________________________________ >> > 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 >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Aug 15 16:03:39 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 15 Aug 2016 16:03:39 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Shawn I'm curious do you know how many places is vtkPolyData::ReplaceCell used? If the method, rather than returning "void" returned a pointer to the cell array, then it'd be easy to invoke Modified() on it. Best, W On Mon, Aug 15, 2016 at 3:39 PM, Shawn Waldon wrote: > Ok, so what should be added to the documentation on > vtkPolyData::ReplaceCell? > > // This operation modifies one of the vtkCellArrays contained in this > vtkPolyData. In order for this change to be picked up by the rendering > system, Modified() must be called on that vtkCellArray. (What goes here to > help them figure out which cell array to call Modified() on????) > > I think that at least for now we have to change vtkPolyData::ReplaceCell > to either call Modified() on the correct vtkCellArray or return something > to indicate to the user which cell array they need to modify. I lean > toward the first, and just add a line in the method's documentation saying > that this is not recommended for tight loops and to use ReplaceCell on the > vtkCellArrays if you need to change many cells in tight loops. This method > is already doing lookups to determine which cell array to modify and a > switch to do it, which is not something you really want in tight loops. > > Shawn > > On Mon, Aug 15, 2016 at 3:17 PM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> FYI- Just to provide more background context: there are several >> triangulation classes like vtkDelaunay2D, vtkQuadricDecimation, and >> vtkGreedyTerrainDecimation that routinely swap the diagonal of the >> quadrilateral consisting of two adjacent triangles (sharing an edge). The >> edge swap is done to improve the triangulation quality. As Dave and Berk >> indicated, this is considered an atomic operation performed in tight loops >> so it is expected that Modified() is called at the end. >> >> Best, >> W >> >> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >> vtk-developers at vtk.org> wrote: >> >>> I don't specifically know the answer to this one, but in general, >>> these sorts of things are on purpose for performance in VTK. >>> >>> If you want to replace 100 (or even more) cells, you'd want >>> ReplaceCell NOT to call Modified, and just do it once at the end of >>> your bulk replacement. I'd be surprised if somebody chimed in and >>> contradicted this... so I would think just fixing the docs is the >>> right way to go here. >>> >>> >>> HTH, >>> David C. >>> >>> >>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon >>> wrote: >>> > Hi all, >>> > >>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>> > selected face never updated. The issue was that the widget was calling >>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>> never >>> > calling Modified() on the cell array (though it did call Modified() on >>> the >>> > polydata). With the new OpenGL backend this matters. The >>> documentation for >>> > ReplaceCell doesn't say that you have to do this afterward and the >>> writer of >>> > vtkBoxRepresentation used that documentation. >>> > >>> > So my question is this: why doesn't ReplaceCell mark the cell array as >>> > modified? Is this a bug or on purpose for performance reasons? I will >>> > update the docs or fix ReplaceCell once I know which is wrong. >>> > >>> > Thank you, >>> > Shawn >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Aug 15 16:14:10 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 Aug 2016 16:14:10 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: Will raised an interesting point regarding the typedef name. vtkTypeMTime versus vtkMTimeType. Most of vtk uses vtkFooType except in vtkType.h where vtkTypeFoo is preferred. for example in vtkTypes.h typedef unsigned char vtkTypeUInt8; typedef signed char vtkTypeInt8; typedef unsigned short vtkTypeUInt16; typedef signed short vtkTypeInt16; typedef unsigned int vtkTypeUInt16; typedef signed int vtkTypeInt16; typedef unsigned int vtkTypeUInt32; typedef signed int vtkTypeInt32; typedef unsigned long vtkTypeUInt32; typedef signed long vtkTypeInt32; typedef unsigned long long vtkTypeUInt64; typedef signed long long vtkTypeInt64; typedef unsigned long vtkTypeUInt64; typedef signed long vtkTypeInt64; typedef float vtkTypeFloat32; typedef double vtkTypeFloat64; typedef int vtkTypeBool; typedef bool vtkTypeBool; but typedef long long vtkIdType; typedef long vtkIdType; typedef int vtkIdType; And in the rest of VTK + DataSetType + LineType + DataType + PlotType + ComponentsType + MapType Also, in ITK almost all typedefs are FooType, not TypeFoo. I can easily change vtkTypeMTime to vtkMTimeType. On Fri, Aug 12, 2016 at 4:14 PM, Bill Lorensen wrote: > +2 good point. Using a typedef is probably a good idea. > > > On Fri, Aug 12, 2016 at 4:06 PM, Shawn Waldon wrote: >> On Fri, Aug 12, 2016 at 4:03 PM, Bill Lorensen >> wrote: >>> >>> +2 Dave >>> >>> I wonder if we will need to change in the future... >> >> >> When we drop support for pre-C++11 compilers, we should probably change to >> use the new uint64_t everywhere regardless of the size of long. >>> >>> >>> >>> On Fri, Aug 12, 2016 at 3:50 PM, David Cole wrote: >>> > Think of how easy this fix would have been if vtkTypeMTime had already >>> > existed ..... >>> > >>> > >>> > >>> > On Fri, Aug 12, 2016 at 3:43 PM, Bill Lorensen >>> > wrote: >>> >> One advantage of naming a type is for backward compatibility: >>> >> // Select an unsigned 64-bit integer type for use in MTime values. >>> >> // If possible, use 'unsigned long' as we have historically. >>> >> #if VTK_SIZEOF_LONG == 8 >>> >> typedef unsigned long vtkTypeMTime; >>> >> #else >>> >> typedef vtkTypeUInt64 vtkTypeMTime; >>> >> #endif >>> >> >>> >> also for apps that need to support old and new versions of VTK: >>> >> // Provide this define to facilitate apps that need to support older >>> >> // versions that do not have vtkTypeMTime >>> >> #ifndef VTK_HAS_TYPE_MTIME >>> >> #if VTK_SIZEOF_LONG == 8 >>> >> typedef unsigned long vtkTypeMTime; >>> >> #else >>> >> typedef vtkTypeUInt64 vtkTypeMTime; >>> >> #endif >>> >> #endif >>> >> >>> >> >>> >> On Fri, Aug 12, 2016 at 3:22 PM, Berk Geveci >>> >> wrote: >>> >>> I also prefer vtkTypeUInt64 but not a strong preference. Both look >>> >>> good to >>> >>> me. >>> >>> >>> >>> On Fri, Aug 12, 2016 at 3:20 PM, Ken Martin >>> >>> wrote: >>> >>>> >>> >>>> Oh, I am fine with the approach you took Bill and so haven't pushed >>> >>>> the >>> >>>> other changes I have locally. I just want the 32bit issue fixed as I >>> >>>> think >>> >>>> that is really important. I am flexible on how it gets fixed. >>> >>>> >>> >>>> I am not a fan of introducing another typedef as I feel it makes the >>> >>>> code >>> >>>> harder to understand, but that is a really small issue and I can >>> >>>> definitely >>> >>>> live with the typedef. vtkTypeUInt64 is a typedef as well so, meh. So >>> >>>> once >>> >>>> your topic is baked let's get it committed. >>> >>>> >>> >>>> Ken >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Aug 12, 2016 at 3:12 PM, Bill Lorensen >>> >>>> >>> >>>> wrote: >>> >>>>> >>> >>>>> Folks, >>> >>>>> >>> >>>>> We have two topics that fix the Windows mtime overflow issue for >>> >>>>> Windows. This seems like a critical issue for Windows apps that run >>> >>>>> for a long time (e.g. surgical applications). >>> >>>>> >>> >>>>> Topic 1: >>> >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 >>> >>>>> Files changed: 376 >>> >>>>> >>> >>>>> Topic 2: >>> >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 >>> >>>>> Files changed: 471 >>> >>>>> >>> >>>>> The major difference is that topic 1 defines MTime as an unsigned >>> >>>>> long >>> >>>>> and topic 2 introduces a new type vtkTypeMTime. >>> >>>>> >>> >>>>> Topic 2 could be easily changed to use unsigned long for the mtime. >>> >>>>> >>> >>>>> Please take some time to review these topics. I suspect that some >>> >>>>> combination of the two will help solve the problem. >>> >>>>> >>> >>>>> 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 >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Ken Martin PhD >>> >>>> Chairman & CFO >>> >>>> Kitware Inc. >>> >>>> 28 Corporate Drive >>> >>>> Clifton Park NY 12065 >>> >>>> 518 371 3971 >>> >>>> >>> >>>> 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 >>> >>>> >>> >>>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> 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 >>> _______________________________________________ >>> 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 -- Unpaid intern in BillsBasement at noware dot com From brad.king at kitware.com Mon Aug 15 16:34:45 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 15 Aug 2016 16:34:45 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: On 08/15/2016 04:14 PM, Bill Lorensen wrote: > vtkTypeMTime versus vtkMTimeType. I have no strong preference but can add some info here. > Most of vtk uses vtkFooType except in vtkType.h where > vtkTypeFoo is preferred. The naming in "vtkType.h" can be interpreted as a "vtkType" prefix (much like vtkSomeClass) followed by the type name of interest. This reads well only when the type name obviously corresponds to a primitive type (e.g. Int64). The only reason vtkIdType appears there is it was a natural place to adopt the definition. For types naming abstract concepts it may not read as well (e.g. vtkTypeId v. vtkIdType). The name vtkTypeMTime sounds like it is somehow a modification time on types. The name vtkMTimeType sounds like it is the type of a modification time. -Brad From bill.lorensen at gmail.com Mon Aug 15 17:04:34 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 Aug 2016 17:04:34 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: +1 Brad that makes sense. If there are no objections raised, I'll change vtkTypeMTime to vtkMTimeType. Bill On Mon, Aug 15, 2016 at 4:34 PM, Brad King wrote: > On 08/15/2016 04:14 PM, Bill Lorensen wrote: >> vtkTypeMTime versus vtkMTimeType. > > I have no strong preference but can add some info here. > >> Most of vtk uses vtkFooType except in vtkType.h where >> vtkTypeFoo is preferred. > > The naming in "vtkType.h" can be interpreted as a "vtkType" prefix > (much like vtkSomeClass) followed by the type name of interest. > This reads well only when the type name obviously corresponds to > a primitive type (e.g. Int64). The only reason vtkIdType appears > there is it was a natural place to adopt the definition. > > For types naming abstract concepts it may not read as well > (e.g. vtkTypeId v. vtkIdType). The name vtkTypeMTime sounds > like it is somehow a modification time on types. The name > vtkMTimeType sounds like it is the type of a modification time. > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From shawn.waldon at kitware.com Mon Aug 15 17:32:50 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 15 Aug 2016 17:32:50 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: Will, According to QtCreator's find usages option, it is used 7 times in vtkDelaunay2D and 6 times in vtkGreedyTerrainDecimation. And that is all. Of course this is only including the things in a default build of VTK in its search. But I think it is safe to say there are not very many places this is used. Shawn On Mon, Aug 15, 2016 at 4:03 PM, Will Schroeder wrote: > Shawn I'm curious do you know how many places is vtkPolyData::ReplaceCell > used? > > If the method, rather than returning "void" returned a pointer to the cell > array, then it'd be easy to invoke Modified() on it. > > Best, > W > > On Mon, Aug 15, 2016 at 3:39 PM, Shawn Waldon > wrote: > >> Ok, so what should be added to the documentation on >> vtkPolyData::ReplaceCell? >> >> // This operation modifies one of the vtkCellArrays contained in this >> vtkPolyData. In order for this change to be picked up by the rendering >> system, Modified() must be called on that vtkCellArray. (What goes here to >> help them figure out which cell array to call Modified() on????) >> >> I think that at least for now we have to change vtkPolyData::ReplaceCell >> to either call Modified() on the correct vtkCellArray or return something >> to indicate to the user which cell array they need to modify. I lean >> toward the first, and just add a line in the method's documentation saying >> that this is not recommended for tight loops and to use ReplaceCell on the >> vtkCellArrays if you need to change many cells in tight loops. This method >> is already doing lookups to determine which cell array to modify and a >> switch to do it, which is not something you really want in tight loops. >> >> Shawn >> >> On Mon, Aug 15, 2016 at 3:17 PM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> FYI- Just to provide more background context: there are several >>> triangulation classes like vtkDelaunay2D, vtkQuadricDecimation, and >>> vtkGreedyTerrainDecimation that routinely swap the diagonal of the >>> quadrilateral consisting of two adjacent triangles (sharing an edge). The >>> edge swap is done to improve the triangulation quality. As Dave and Berk >>> indicated, this is considered an atomic operation performed in tight loops >>> so it is expected that Modified() is called at the end. >>> >>> Best, >>> W >>> >>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>> vtk-developers at vtk.org> wrote: >>> >>>> I don't specifically know the answer to this one, but in general, >>>> these sorts of things are on purpose for performance in VTK. >>>> >>>> If you want to replace 100 (or even more) cells, you'd want >>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>> contradicted this... so I would think just fixing the docs is the >>>> right way to go here. >>>> >>>> >>>> HTH, >>>> David C. >>>> >>>> >>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>> shawn.waldon at kitware.com> wrote: >>>> > Hi all, >>>> > >>>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>>> > selected face never updated. The issue was that the widget was >>>> calling >>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>>> never >>>> > calling Modified() on the cell array (though it did call Modified() >>>> on the >>>> > polydata). With the new OpenGL backend this matters. The >>>> documentation for >>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>> writer of >>>> > vtkBoxRepresentation used that documentation. >>>> > >>>> > So my question is this: why doesn't ReplaceCell mark the cell array as >>>> > modified? Is this a bug or on purpose for performance reasons? I will >>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>> > >>>> > Thank you, >>>> > Shawn >>>> > >>>> > _______________________________________________ >>>> > 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 >>>> >>>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. - Building the World's Technical Computing Software >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >>> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. - Building the World's Technical Computing Software > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Tue Aug 16 09:09:10 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 16 Aug 2016 09:09:10 -0400 Subject: [vtk-developers] Marking data modified In-Reply-To: References: Message-ID: I suspect we could rewrite this code to avoid vtkPolyData::ReplaceCell() and then mark the method deprecated for long-term removal. It would likely improve performance too as it would avoid extra switch statements. Best, W On Mon, Aug 15, 2016 at 5:32 PM, Shawn Waldon wrote: > Will, > > According to QtCreator's find usages option, it is used 7 times in > vtkDelaunay2D and 6 times in vtkGreedyTerrainDecimation. And that is all. > Of course this is only including the things in a default build of VTK in > its search. But I think it is safe to say there are not very many places > this is used. > > Shawn > > On Mon, Aug 15, 2016 at 4:03 PM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Shawn I'm curious do you know how many places is vtkPolyData::ReplaceCell >> used? >> >> If the method, rather than returning "void" returned a pointer to the >> cell array, then it'd be easy to invoke Modified() on it. >> >> Best, >> W >> >> On Mon, Aug 15, 2016 at 3:39 PM, Shawn Waldon >> wrote: >> >>> Ok, so what should be added to the documentation on >>> vtkPolyData::ReplaceCell? >>> >>> // This operation modifies one of the vtkCellArrays contained in this >>> vtkPolyData. In order for this change to be picked up by the rendering >>> system, Modified() must be called on that vtkCellArray. (What goes here to >>> help them figure out which cell array to call Modified() on????) >>> >>> I think that at least for now we have to change vtkPolyData::ReplaceCell >>> to either call Modified() on the correct vtkCellArray or return something >>> to indicate to the user which cell array they need to modify. I lean >>> toward the first, and just add a line in the method's documentation saying >>> that this is not recommended for tight loops and to use ReplaceCell on the >>> vtkCellArrays if you need to change many cells in tight loops. This method >>> is already doing lookups to determine which cell array to modify and a >>> switch to do it, which is not something you really want in tight loops. >>> >>> Shawn >>> >>> On Mon, Aug 15, 2016 at 3:17 PM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> FYI- Just to provide more background context: there are several >>>> triangulation classes like vtkDelaunay2D, vtkQuadricDecimation, and >>>> vtkGreedyTerrainDecimation that routinely swap the diagonal of the >>>> quadrilateral consisting of two adjacent triangles (sharing an edge). The >>>> edge swap is done to improve the triangulation quality. As Dave and Berk >>>> indicated, this is considered an atomic operation performed in tight loops >>>> so it is expected that Modified() is called at the end. >>>> >>>> Best, >>>> W >>>> >>>> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers < >>>> vtk-developers at vtk.org> wrote: >>>> >>>>> I don't specifically know the answer to this one, but in general, >>>>> these sorts of things are on purpose for performance in VTK. >>>>> >>>>> If you want to replace 100 (or even more) cells, you'd want >>>>> ReplaceCell NOT to call Modified, and just do it once at the end of >>>>> your bulk replacement. I'd be surprised if somebody chimed in and >>>>> contradicted this... so I would think just fixing the docs is the >>>>> right way to go here. >>>>> >>>>> >>>>> HTH, >>>>> David C. >>>>> >>>>> >>>>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon < >>>>> shawn.waldon at kitware.com> wrote: >>>>> > Hi all, >>>>> > >>>>> > I have been tracking down a bug in the vtkBoxRepresentation where the >>>>> > selected face never updated. The issue was that the widget was >>>>> calling >>>>> > ReplaceCell on the vtkCellArray for the selected face polydata, but >>>>> never >>>>> > calling Modified() on the cell array (though it did call Modified() >>>>> on the >>>>> > polydata). With the new OpenGL backend this matters. The >>>>> documentation for >>>>> > ReplaceCell doesn't say that you have to do this afterward and the >>>>> writer of >>>>> > vtkBoxRepresentation used that documentation. >>>>> > >>>>> > So my question is this: why doesn't ReplaceCell mark the cell array >>>>> as >>>>> > modified? Is this a bug or on purpose for performance reasons? I >>>>> will >>>>> > update the docs or fix ReplaceCell once I know which is wrong. >>>>> > >>>>> > Thank you, >>>>> > Shawn >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> William J. Schroeder, PhD >>>> Kitware, Inc. - Building the World's Technical Computing Software >>>> 28 Corporate Drive >>>> Clifton Park, NY 12065 >>>> will.schroeder at kitware.com >>>> http://www.kitware.com >>>> (518) 881-4902 >>>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. - Building the World's Technical Computing Software >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Aug 16 10:57:56 2016 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 16 Aug 2016 10:57:56 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: /agree vtkMTimeType makes more sense. On Mon, Aug 15, 2016 at 5:04 PM, Bill Lorensen wrote: > +1 Brad that makes sense. If there are no objections raised, I'll > change vtkTypeMTime to vtkMTimeType. > > Bill > > > On Mon, Aug 15, 2016 at 4:34 PM, Brad King wrote: > > On 08/15/2016 04:14 PM, Bill Lorensen wrote: > >> vtkTypeMTime versus vtkMTimeType. > > > > I have no strong preference but can add some info here. > > > >> Most of vtk uses vtkFooType except in vtkType.h where > >> vtkTypeFoo is preferred. > > > > The naming in "vtkType.h" can be interpreted as a "vtkType" prefix > > (much like vtkSomeClass) followed by the type name of interest. > > This reads well only when the type name obviously corresponds to > > a primitive type (e.g. Int64). The only reason vtkIdType appears > > there is it was a natural place to adopt the definition. > > > > For types naming abstract concepts it may not read as well > > (e.g. vtkTypeId v. vtkIdType). The name vtkTypeMTime sounds > > like it is somehow a modification time on types. The name > > vtkMTimeType sounds like it is the type of a modification time. > > > > -Brad > > > > > > -- > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 bill.lorensen at gmail.com Tue Aug 16 11:01:31 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 16 Aug 2016 11:01:31 -0400 Subject: [vtk-developers] MTime Olympics In-Reply-To: References: Message-ID: I just changed to vtkMTimeType and pushed the changes. On Tue, Aug 16, 2016 at 10:57 AM, Ken Martin wrote: > /agree vtkMTimeType makes more sense. > > On Mon, Aug 15, 2016 at 5:04 PM, Bill Lorensen > wrote: >> >> +1 Brad that makes sense. If there are no objections raised, I'll >> change vtkTypeMTime to vtkMTimeType. >> >> Bill >> >> >> On Mon, Aug 15, 2016 at 4:34 PM, Brad King wrote: >> > On 08/15/2016 04:14 PM, Bill Lorensen wrote: >> >> vtkTypeMTime versus vtkMTimeType. >> > >> > I have no strong preference but can add some info here. >> > >> >> Most of vtk uses vtkFooType except in vtkType.h where >> >> vtkTypeFoo is preferred. >> > >> > The naming in "vtkType.h" can be interpreted as a "vtkType" prefix >> > (much like vtkSomeClass) followed by the type name of interest. >> > This reads well only when the type name obviously corresponds to >> > a primitive type (e.g. Int64). The only reason vtkIdType appears >> > there is it was a natural place to adopt the definition. >> > >> > For types naming abstract concepts it may not read as well >> > (e.g. vtkTypeId v. vtkIdType). The name vtkTypeMTime sounds >> > like it is somehow a modification time on types. The name >> > vtkMTimeType sounds like it is the type of a modification time. >> > >> > -Brad >> > >> >> >> >> -- >> 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 >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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. -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 16 15:36:11 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 16 Aug 2016 15:36:11 -0400 Subject: [vtk-developers] Next VTK hackathon Message-ID: Hi folks, I am thinking that September 8 would be a good date for our next hackathon. I suggest that we primarily focus on the dashboards but also work on the issue tracker. What do you think? Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Aug 16 16:44:57 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 16 Aug 2016 16:44:57 -0400 Subject: [vtk-developers] Next VTK hackathon In-Reply-To: References: Message-ID: +1 On Tue, Aug 16, 2016 at 3:36 PM, Berk Geveci wrote: > Hi folks, > > I am thinking that September 8 would be a good date for our next hackathon. > I suggest that we primarily focus on the dashboards but also work on the > issue tracker. What do you think? > > Best, > -berk > > _______________________________________________ > 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 Aug 16 16:51:41 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 16 Aug 2016 16:51:41 -0400 Subject: [vtk-developers] Next VTK hackathon In-Reply-To: References: Message-ID: +1 On Tue, Aug 16, 2016 at 4:44 PM, Utkarsh Ayachit wrote: > +1 > > On Tue, Aug 16, 2016 at 3:36 PM, Berk Geveci wrote: >> Hi folks, >> >> I am thinking that September 8 would be a good date for our next hackathon. >> I suggest that we primarily focus on the dashboards but also work on the >> issue tracker. What do you think? >> >> Best, >> -berk >> >> _______________________________________________ >> 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 shawn.waldon at kitware.com Tue Aug 16 17:14:47 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 16 Aug 2016 17:14:47 -0400 Subject: [vtk-developers] Non-reproducable test failure Message-ID: Hi all, One of the VTK tests ( vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext ) has been failing on the build machine trey for a few weeks, but only on builds of master. Merge request builds are fine and I have no idea why. Alvaro, Sankhesh and I have all looked at this test and it passes when we run it locally even for a build of the master branch. We're pretty much out of ideas for what is going wrong. Here is the failure on the laster master build [1]. Does anyone have any ideas? If not I'm just going to call it a flaky test and disable it for that machine. Thanks, Shawn [1]: https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=deb05542-build1930-%5Bosx-shared-release%2Bpython%2Bpython3%2Bqt%5D-master&compare3=61&showfeed=0&value2=20160816T102150 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Aug 16 19:07:54 2016 From: sean at rogue-research.com (Sean McBride) Date: Tue, 16 Aug 2016 19:07:54 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: Message-ID: <20160816230754.469891299@mail.rogue-research.com> On Tue, 16 Aug 2016 17:14:47 -0400, Shawn Waldon said: >One of the VTK tests ( >vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext ) has been failing >on the build machine trey for a few weeks, but only on builds of master. The name rang a bell, indeed it's failing on my address sanitizer bot: but alas it's not some memory error that ASan finds, it's an image compare failure. Oddly, when I run the test by hand on that bot, it passes. So WTF indeed. 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 Wed Aug 17 08:31:05 2016 From: david.lonie at kitware.com (David Lonie) Date: Wed, 17 Aug 2016 08:31:05 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: Message-ID: Is the ctest setup script changing anything in the environment? That's all I can think of....strange. On Tue, Aug 16, 2016 at 5:14 PM, Shawn Waldon wrote: > Hi all, > > One of the VTK tests ( > vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext ) has been failing > on the build machine trey for a few weeks, but only on builds of master. > Merge request builds are fine and I have no idea why. Alvaro, Sankhesh and > I have all looked at this test and it passes when we run it locally even for > a build of the master branch. We're pretty much out of ideas for what is > going wrong. Here is the failure on the laster master build [1]. Does > anyone have any ideas? If not I'm just going to call it a flaky test and > disable it for that machine. > > Thanks, > Shawn > > [1]: > https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=deb05542-build1930-%5Bosx-shared-release%2Bpython%2Bpython3%2Bqt%5D-master&compare3=61&showfeed=0&value2=20160816T102150 > > _______________________________________________ > 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 ken.martin at kitware.com Wed Aug 17 10:23:17 2016 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 17 Aug 2016 10:23:17 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: <20160816230754.469891299@mail.rogue-research.com> References: <20160816230754.469891299@mail.rogue-research.com> Message-ID: Ahh, now I get it, WTF stands for Why The Failure. Been wondering what that stood for ;-) On Tue, Aug 16, 2016 at 7:07 PM, Sean McBride wrote: > On Tue, 16 Aug 2016 17:14:47 -0400, Shawn Waldon said: > > the test by hand on that bot, it passes. So WTF indeed. > > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 sean at rogue-research.com Wed Aug 17 10:26:41 2016 From: sean at rogue-research.com (Sean McBride) Date: Wed, 17 Aug 2016 10:26:41 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: Message-ID: <20160817142641.1353232412@mail.rogue-research.com> On Wed, 17 Aug 2016 08:31:05 -0400, David Lonie said: >Is the ctest setup script changing anything in the environment? That's >all I can think of....strange. Most of my scripts do set debug vars in the env, but this one doesn't since ASan is already torture enough. The only other difference I can think of is that if I run by hand it's the only thing happening, where the script runs the tests with -j7. 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 dan.lipsa at kitware.com Wed Aug 17 10:34:21 2016 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 17 Aug 2016 10:34:21 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: Message-ID: I've seen test failures on buildbot that passed on command line because of memory issues. That would not explain why they pass on branches though. It's worth looking at a valgrind output though. Dan On Tue, Aug 16, 2016 at 5:14 PM, Shawn Waldon wrote: > Hi all, > > One of the VTK tests ( vtkRenderingVolumeCxx- > TestRemoveVolumeNonCurrentContext ) has been failing on the build machine > trey for a few weeks, but only on builds of master. Merge request builds > are fine and I have no idea why. Alvaro, Sankhesh and I have all looked at > this test and it passes when we run it locally even for a build of the > master branch. We're pretty much out of ideas for what is going wrong. > Here is the failure on the laster master build [1]. Does anyone have any > ideas? If not I'm just going to call it a flaky test and disable it for > that machine. > > Thanks, > Shawn > > [1]: https://open.cdash.org/queryTests.php?compare1=65& > value3=Failed&filtercount=3&field3=status%2Fstring&field1= > buildname%2Fstring&project=VTK&field2=buildstarttime% > 2Fdate&showfilters=0&limit=100&compare2=83&value1= > deb05542-build1930-%5Bosx-shared-release%2Bpython% > 2Bpython3%2Bqt%5D-master&compare3=61&showfeed=0&value2=20160816T102150 > > _______________________________________________ > 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 shawn.waldon at kitware.com Wed Aug 17 10:35:05 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 17 Aug 2016 10:35:05 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: <20160817142641.1353232412@mail.rogue-research.com> References: <20160817142641.1353232412@mail.rogue-research.com> Message-ID: On Wed, Aug 17, 2016 at 10:26 AM, Sean McBride wrote: > On Wed, 17 Aug 2016 08:31:05 -0400, David Lonie said: > > >Is the ctest setup script changing anything in the environment? That's > >all I can think of....strange. > > Most of my scripts do set debug vars in the env, but this one doesn't > since ASan is already torture enough. The only other difference I can > think of is that if I run by hand it's the only thing happening, where the > script runs the tests with -j7. > One of the things I tried was running the tests with -j5. I still couldn't get it to fail. Shawn > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Aug 17 11:05:20 2016 From: sean at rogue-research.com (Sean McBride) Date: Wed, 17 Aug 2016 11:05:20 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> Message-ID: <20160817150520.1544123482@mail.rogue-research.com> On Wed, 17 Aug 2016 10:35:05 -0400, Shawn Waldon said: >One of the things I tried was running the tests with -j5. I still couldn't >get it to fail. So I just tried this shell script: for run in {1..30} do ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & done and now it repros fairly often. Maybe that'll work on your machine too... 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 DLRdave at aol.com Wed Aug 17 11:19:35 2016 From: DLRdave at aol.com (David Cole) Date: Wed, 17 Aug 2016 11:19:35 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: <20160817150520.1544123482@mail.rogue-research.com> References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: Does this test access some resource that is also accessed by another test which is likely to be running at the same time? Does it only fail when that resource is held/blocked by the other test...? Should it have the RUN_SERIAL flag? (or a test dependency...?) On Wed, Aug 17, 2016 at 11:05 AM, Sean McBride wrote: > On Wed, 17 Aug 2016 10:35:05 -0400, Shawn Waldon said: > >>One of the things I tried was running the tests with -j5. I still couldn't >>get it to fail. > > So I just tried this shell script: > > for run in {1..30} > do > ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & > done > > and now it repros fairly often. Maybe that'll work on your machine too... > > 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 > From bill.lorensen at gmail.com Wed Aug 17 11:23:53 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 17 Aug 2016 11:23:53 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: As David suggested, I would try RUN_SERIAL On Wed, Aug 17, 2016 at 11:19 AM, David Cole via vtk-developers wrote: > Does this test access some resource that is also accessed by another > test which is likely to be running at the same time? Does it only fail > when that resource is held/blocked by the other test...? > > Should it have the RUN_SERIAL flag? (or a test dependency...?) > > > > On Wed, Aug 17, 2016 at 11:05 AM, Sean McBride wrote: >> On Wed, 17 Aug 2016 10:35:05 -0400, Shawn Waldon said: >> >>>One of the things I tried was running the tests with -j5. I still couldn't >>>get it to fail. >> >> So I just tried this shell script: >> >> for run in {1..30} >> do >> ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & >> done >> >> and now it repros fairly often. Maybe that'll work on your machine too... >> >> 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 >> > _______________________________________________ > 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 sean at rogue-research.com Wed Aug 17 11:28:36 2016 From: sean at rogue-research.com (Sean McBride) Date: Wed, 17 Aug 2016 11:28:36 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: <20160817152836.804612646@mail.rogue-research.com> On Wed, 17 Aug 2016 11:19:35 -0400, David Cole said: >Does this test access some resource that is also accessed by another >test which is likely to be running at the same time? Does it only fail >when that resource is held/blocked by the other test...? Note that I'm only running 1 test, that is, the *same* test in parallel with itself. So if it's a contention issue, it's with itself. Sean >Should it have the RUN_SERIAL flag? (or a test dependency...?) > > > >On Wed, Aug 17, 2016 at 11:05 AM, Sean McBride >wrote: >> On Wed, 17 Aug 2016 10:35:05 -0400, Shawn Waldon said: >> >>>One of the things I tried was running the tests with -j5. I still couldn't >>>get it to fail. >> >> So I just tried this shell script: >> >> for run in {1..30} >> do >> ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & >> done >> >> and now it repros fairly often. Maybe that'll work on your machine too... From david.lonie at kitware.com Wed Aug 17 11:36:50 2016 From: david.lonie at kitware.com (David Lonie) Date: Wed, 17 Aug 2016 11:36:50 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: <20160817152836.804612646@mail.rogue-research.com> References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> <20160817152836.804612646@mail.rogue-research.com> Message-ID: On Wed, Aug 17, 2016 at 11:28 AM, Sean McBride wrote: > On Wed, 17 Aug 2016 11:19:35 -0400, David Cole said: > >>Does this test access some resource that is also accessed by another >>test which is likely to be running at the same time? Does it only fail >>when that resource is held/blocked by the other test...? > > Note that I'm only running 1 test, that is, the *same* test in parallel with itself. So if it's a contention issue, it's with itself. I'm sorta curious if the volume in question is large enough to deplete graphics memory on these machines. That may explain some of this. From zack.galbreath at kitware.com Wed Aug 17 11:37:27 2016 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Wed, 17 Aug 2016 11:37:27 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: <20160817150520.1544123482@mail.rogue-research.com> References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: On Wed, Aug 17, 2016 at 11:05 AM, Sean McBride wrote: > So I just tried this shell script: > > for run in {1..30} > do > ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & > done > > and now it repros fairly often. Maybe that'll work on your machine too... > ctest now has a command-line argument to help shake out flaky tests like this. No shell script needed: --repeat-until-fail Require each test to run times without failing in order to pass -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Aug 17 11:47:28 2016 From: david.lonie at kitware.com (David Lonie) Date: Wed, 17 Aug 2016 11:47:28 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: On Wed, Aug 17, 2016 at 11:37 AM, Zack Galbreath wrote: > On Wed, Aug 17, 2016 at 11:05 AM, Sean McBride > wrote: >> >> So I just tried this shell script: >> >> for run in {1..30} >> do >> ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & >> done >> >> and now it repros fairly often. Maybe that'll work on your machine too... > > > ctest now has a command-line argument to help shake out flaky tests like > this. No shell script needed: > > --repeat-until-fail > Require each test to run times without failing in order to pass Is that compatible with -j? (e.g. will it run the same test concurrently with itself?) From sankhesh.jhaveri at kitware.com Wed Aug 17 11:51:14 2016 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Wed, 17 Aug 2016 11:51:14 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: Unfortunately, I can't make it fail on Trey with the test script that Sean posted. I'll give RUN_SERIAL a try. At the very least it would prevent its competition with other tests. The test uses the ironProt dataset (64x64x64) which is comparably very tiny as compared to other datasets used by other `passing` volume tests on Trey. Sankhesh On Wed, Aug 17, 2016 at 11:37 AM, Zack Galbreath wrote: > On Wed, Aug 17, 2016 at 11:05 AM, Sean McBride > wrote: > >> So I just tried this shell script: >> >> for run in {1..30} >> do >> ctest -R vtkRenderingVolumeCxx-TestRemoveVolumeNonCurrentContext & >> done >> >> and now it repros fairly often. Maybe that'll work on your machine too... >> > > ctest now has a command-line argument to help shake out flaky tests like > this. No shell script needed: > > --repeat-until-fail > Require each test to run times without failing in order to pass > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.malaterre at gmail.com Thu Aug 18 06:06:28 2016 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Thu, 18 Aug 2016 12:06:28 +0200 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? Message-ID: Hi there, Does anyone knows what happen to this file: $ HEAD http://www.vtk.org/files/nightly/vtkNightlyDoc.tag.gz 403 Forbidden Date: Thu, 18 Aug 2016 10:03:39 GMT Via: HTTP/1.1 proxy10228 Server: Apache Vary: Accept-Encoding Content-Length: 4151 Content-Type: text/html Client-Date: Thu, 18 Aug 2016 10:03:35 GMT Client-Peer: 66.194.253.19:80 Client-Response-Num: 1 Keep-Alive: 60 Thanks much, -- Mathieu From sean at rogue-research.com Thu Aug 18 09:49:43 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Aug 2016 09:49:43 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> Message-ID: <20160818134943.340614871@mail.rogue-research.com> All, Not sure what it tells us, but it failed on Rogue14 today: same invalid image. This machine has Intel Iris & OS X 10.12b6 & no ASan. Rogue7 has nvidia geforce GT 120 and OS X 10.11.6. Sean From sankhesh.jhaveri at kitware.com Thu Aug 18 09:57:20 2016 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Thu, 18 Aug 2016 09:57:20 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: <20160818134943.340614871@mail.rogue-research.com> References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> <20160818134943.340614871@mail.rogue-research.com> Message-ID: Hi Sean, Could you please try the latest master (SHA: a8572a7) with your script? I am hoping these changes would have fixed any possible issues with this test. ?Sankhesh? On Thu, Aug 18, 2016 at 9:49 AM, Sean McBride wrote: > All, > > Not sure what it tells us, but it failed on Rogue14 today: > > > > same invalid image. This machine has Intel Iris & OS X 10.12b6 & no > ASan. Rogue7 has nvidia geforce GT 120 and OS X 10.11.6. > > Sean > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 18 11:05:39 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Aug 2016 11:05:39 -0400 Subject: [vtk-developers] Non-reproducable test failure In-Reply-To: References: <20160817142641.1353232412@mail.rogue-research.com> <20160817150520.1544123482@mail.rogue-research.com> <20160818134943.340614871@mail.rogue-research.com> Message-ID: <20160818150539.640479693@mail.rogue-research.com> On Thu, 18 Aug 2016 09:57:20 -0400, Sankhesh Jhaveri said: >Could you please try the latest master (SHA: a8572a7) with your script? > >I am hoping these changes would have fixed any possible issues with this >test. Yup, seems fixed! Nice! Sean From cory.quammen at kitware.com Thu Aug 18 12:17:15 2016 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 18 Aug 2016 12:17:15 -0400 Subject: [vtk-developers] Initializing Python VTK object from existing VTK object Message-ID: One can create a Python object from an existing VTK object if the address of the VTK object is known, e.g., address = "0xbeefbeef" sphereSource = vtk.vtkSphereSource(address) My question is about the address string. Can the address string keep the prefix "0x" or must it be removed? I've looked around the Python wrapping code, but haven't concluded one way or the other. Some code in ParaView unintentionally uses the full address with "0x" and seems to work, so I'm guessing either is fine. Thanks, Cory -- Cory Quammen R&D Engineer Kitware, Inc. From david.gobbi at gmail.com Thu Aug 18 12:51:01 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 18 Aug 2016 10:51:01 -0600 Subject: [vtk-developers] Initializing Python VTK object from existing VTK object In-Reply-To: References: Message-ID: Hi Cory, The code that deals with this is vtkPythonUtil::GetObjectFromObject(), which tries to decode the address with these three format string: "_%llx_%s" "Addr=0x%llx" "%p" The first of these is a "SWIG-style" pointer string, the second is legacy, and the third is what is catching your address. I believe that whether it accepts "0x" is platform specific. - David On Thu, Aug 18, 2016 at 10:17 AM, Cory Quammen wrote: > One can create a Python object from an existing VTK object if the > address of the VTK object is known, e.g., > > address = "0xbeefbeef" > sphereSource = vtk.vtkSphereSource(address) > > My question is about the address string. Can the address string keep > the prefix "0x" or must it be removed? I've looked around the Python > wrapping code, but haven't concluded one way or the other. Some code > in ParaView unintentionally uses the full address with "0x" and seems > to work, so I'm guessing either is fine. > > Thanks, > Cory > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Aug 18 13:53:38 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 18 Aug 2016 13:53:38 -0400 Subject: [vtk-developers] Rogue7 vtktiff dashboard build failure In-Reply-To: <20160812195118.GB1790@megas.kitware.com> References: <20160726011546.2016066190@mail.rogue-research.com> <20160726140545.GA14126@rotor> <20160726142252.GA10822@rotor.kitware.com> <20160726144235.GB14126@rotor> <20160812140426.1347855963@mail.rogue-research.com> <20160812195118.GB1790@megas.kitware.com> Message-ID: Sean & Ben, Any progress on this? Sean, last I heard, Ben was still waiting on as response from you. Shawn On Fri, Aug 12, 2016 at 3:51 PM, Ben Boeckel wrote: > On Fri, Aug 12, 2016 at 10:04:26 -0400, Sean McBride wrote: > > So that's all merged now, right? It seems however to have not > > actually fixed the Xcode build: > > > > > > Can you have CMake error right after it does the checks for the flag and > configure with --debug-trycompile and send the CMakeFiles/CMakeTmp/ (I > think it lives there at least) output? Is -Werror not applying for newer > Xcode compilers? > > --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 bill.lorensen at gmail.com Thu Aug 18 16:04:56 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 18 Aug 2016 16:04:56 -0400 Subject: [vtk-developers] MTime topic Message-ID: Folks, I'd like to refine/resolve this topic: https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 The key changes are to: Common/Core/vtkType.h and Common/Core/vtkTimeStamp.cxx Please review and provide feedback. ENH: Introduce vtkMTimeType Windows applications that run for a long time report that rendered objects do not change. This is because the modified time on a Windows system is 32 bits. This causes overflows that defeat the modified time mechanism. This patch defines a new type, vtkMTimeType that is 64 unsigned integer regardless of the architecture. A mechanism to provide backward compatibility is introduced. The preprocessor define "VTK_HAS_MTIME_TYPE" can be used in applications that must build against VTK versions that use the "unsigned long" type for MTime's. Methodology used to find MTime occurences: 1) Identify files as follows: git grep "unsigned long" | grep ime | cut -d":" -f1,1 | sort | uniq 2) Hand edit each of those files replacing "unsigned long" with "vtkMTimeType" where appropriate. 3) Temporarily change typedef for vtkMTimeType to "double" to detect missing conversions Thanks, Bill From ziganshinshagit at hotmail.com Thu Aug 18 16:04:28 2016 From: ziganshinshagit at hotmail.com (=?utf-8?B?0KjQsNCz0LjRgiDQl9C40LPQsNC90YjQuNC9?=) Date: Thu, 18 Aug 2016 23:04:28 +0300 Subject: [vtk-developers] vtkTextSource vtkfont_bits generation Message-ID: Hi, I have the task of using Cyrillic characters in vtk/paraview and faced with the problem that vtkVectorText does not accept characters other than English. The solution of this problem I believe lies in the Filters/Sources/vtkTextSource.cxx in array vtkfont_bits. Prompt what function it performs an array and how it is generated? Thanks, Shagit Ziganshin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 18 16:15:02 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Aug 2016 16:15:02 -0400 Subject: [vtk-developers] Rogue7 vtktiff dashboard build failure In-Reply-To: References: <20160726011546.2016066190@mail.rogue-research.com> <20160726140545.GA14126@rotor> <20160726142252.GA10822@rotor.kitware.com> <20160726144235.GB14126@rotor> <20160812140426.1347855963@mail.rogue-research.com> <20160812195118.GB1790@megas.kitware.com> Message-ID: <20160818201502.30813858@mail.rogue-research.com> I haven't had time to understand Ben's request exactly... 1) how do I make "CMake error right after it does the checks for the flag"? 2) where do I pass --debug-trycompile? Is that a CXXFLAG or param to cmake? Sean On Thu, 18 Aug 2016 13:53:38 -0400, Shawn Waldon said: >Sean & Ben, > >Any progress on this? Sean, last I heard, Ben was still waiting on as >response from you. > >Shawn > >On Fri, Aug 12, 2016 at 3:51 PM, Ben Boeckel >wrote: > >> On Fri, Aug 12, 2016 at 10:04:26 -0400, Sean McBride wrote: >> > So that's all merged now, right? It seems however to have not >> > actually fixed the Xcode build: >> > >> > >> >> Can you have CMake error right after it does the checks for the flag and >> configure with --debug-trycompile and send the CMakeFiles/CMakeTmp/ (I >> think it lives there at least) output? Is -Werror not applying for newer >> Xcode compilers? >> >> --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 >> >> From david.lonie at kitware.com Thu Aug 18 16:29:28 2016 From: david.lonie at kitware.com (David Lonie) Date: Thu, 18 Aug 2016 16:29:28 -0400 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: vtkVectorText only supports a very limited set of fonts and characters. I'm not sure how the polydata it uses was generated. I'd recommend using vtkTextActor3D in place of vtkVectorText, unless the polydata representations is actually needed for some reason. On Thu, Aug 18, 2016 at 4:04 PM, ????? ???????? wrote: > Hi, > > I have the task of using Cyrillic characters in vtk/paraview and faced with > the problem that vtkVectorText does not accept characters other than > English. The solution of this problem I believe lies in the > Filters/Sources/vtkTextSource.cxx in array vtkfont_bits. Prompt what > function it performs an array and how it is generated? > > > > Thanks, > > Shagit Ziganshin > > > _______________________________________________ > 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 david.lonie at kitware.com Thu Aug 18 16:34:06 2016 From: david.lonie at kitware.com (David Lonie) Date: Thu, 18 Aug 2016 16:34:06 -0400 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: On Thu, Aug 18, 2016 at 4:29 PM, David Lonie wrote: > vtkVectorText only supports a very limited set of fonts and > characters. I'm not sure how the polydata it uses was generated. To elaborate a bit: vtkVectorText does not use the vtkfont_bits, as far as I'm aware. See vtkVectorText.cxx -- it contains a large number of static arrays containing polygon descriptions of the glyphs. If you wish to extend it, you'll need to add more glyphs to this file. From ziganshinshagit at hotmail.com Thu Aug 18 16:43:22 2016 From: ziganshinshagit at hotmail.com (=?UTF-8?B?0KjQsNCz0LjRgiDQl9C40LPQsNC90YjQuNC9?=) Date: Thu, 18 Aug 2016 23:43:22 +0300 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: And how to use no english characters in vtkVectorText? I'm not sure that vtkVectorText3D can use them. 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" ???????: > So, do you or someone knows how to vtkfont_bits? > > 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" > ???????: > >> On Thu, Aug 18, 2016 at 4:29 PM, David Lonie >> wrote: >> > vtkVectorText only supports a very limited set of fonts and >> > characters. I'm not sure how the polydata it uses was generated. >> >> To elaborate a bit: vtkVectorText does not use the vtkfont_bits, as >> far as I'm aware. See vtkVectorText.cxx -- it contains a large number >> of static arrays containing polygon descriptions of the glyphs. If you >> wish to extend it, you'll need to add more glyphs to this file. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziganshinshagit at hotmail.com Thu Aug 18 16:40:52 2016 From: ziganshinshagit at hotmail.com (=?UTF-8?B?0KjQsNCz0LjRgiDQl9C40LPQsNC90YjQuNC9?=) Date: Thu, 18 Aug 2016 23:40:52 +0300 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: So, do you or someone knows how to vtkfont_bits? 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" ???????: > On Thu, Aug 18, 2016 at 4:29 PM, David Lonie > wrote: > > vtkVectorText only supports a very limited set of fonts and > > characters. I'm not sure how the polydata it uses was generated. > > To elaborate a bit: vtkVectorText does not use the vtkfont_bits, as > far as I'm aware. See vtkVectorText.cxx -- it contains a large number > of static arrays containing polygon descriptions of the glyphs. If you > wish to extend it, you'll need to add more glyphs to this file. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hu.ds.abel at icloud.com Thu Aug 18 21:39:14 2016 From: hu.ds.abel at icloud.com (huabel) Date: Fri, 19 Aug 2016 09:39:14 +0800 Subject: [vtk-developers] package require vtk, unsafe use of relative rpath Message-ID: Hi All, I am working in Mac OS X EI Capitan 10.11.5, and VTK 7.0 wrap with TCL, when execuate "package require vtk" get unsafe use of relative rpath % package require vtk dlopen(/Users/focus/opt/vtk700/lib/libvtkCommonCoreTCL-7.0.dylib, 10): Library not loaded: libvtkCommonCore-7.0.1.dylib Referenced from: /Users/focus/opt/vtk700/lib/libvtkCommonCoreTCL-7.0.dylib Reason: unsafe use of relative rpath libvtkCommonCore-7.0.1.dylib in /Users/focus/opt/vtk700/lib/libvtkCommonCoreTCL-7.0.dylib with restricted binary attempt to provide package vtkCommonCoreTCL 7.0 failed: no version of package vtkCommonCoreTCL provided attempt to provide package vtkcommoncore 7.0 failed: no version of package vtkcommoncore provided attempt to provide package vtk 7.0 failed: no version of package vtk provided Many thanks for any help. Best Regards, Abel From david.lonie at kitware.com Fri Aug 19 08:53:24 2016 From: david.lonie at kitware.com (David Lonie) Date: Fri, 19 Aug 2016 08:53:24 -0400 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: I'm not sure about vtkfont_bits, I've never had to use it before. And no, vtkVectorText cannot use characters outside of ASCII codepoints 33-126. vtkTextActor3D can use any characters desired when supplied with a vtkTextProperty that has FontFamily=VTK_FONT_FILE and FontFile set to a font file with the desired characters. See Rendering/FreeType/TestFreeTypeTextMapperNoMath.cxx: // UTF-8 freetype handling: vtkNew mapper10; vtkNew actor10; actor10->SetMapper(mapper10.GetPointer()); mapper10->GetTextProperty()->SetFontFile(uncodeFontFile.c_str()); mapper10->GetTextProperty()->SetFontFamily(VTK_FONT_FILE); mapper10->GetTextProperty()->SetJustificationToCentered(); mapper10->GetTextProperty()->SetVerticalJustificationToCentered(); mapper10->GetTextProperty()->SetFontSize(18); mapper10->GetTextProperty()->SetColor(0.0, 1.0, 0.7); mapper10->SetInput("UTF-8 FreeType: \xce\xa8\xd2\x94\xd2\x96\xd1\x84\xd2\xbe"); actor10->SetPosition(300, 110); That uses a vtkTextMapper, but the underlying font rendering uses the same backend as vtkTextActor3D, and renders the non-english characters in the UTF-8 string set via SetInput (see attached). Dave On Thu, Aug 18, 2016 at 4:43 PM, ????? ???????? wrote: > And how to use no english characters in vtkVectorText? I'm not sure that > vtkVectorText3D can use them. > > > 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" > ???????: >> >> So, do you or someone knows how to vtkfont_bits? >> >> >> 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" >> ???????: >>> >>> On Thu, Aug 18, 2016 at 4:29 PM, David Lonie >>> wrote: >>> > vtkVectorText only supports a very limited set of fonts and >>> > characters. I'm not sure how the polydata it uses was generated. >>> >>> To elaborate a bit: vtkVectorText does not use the vtkfont_bits, as >>> far as I'm aware. See vtkVectorText.cxx -- it contains a large number >>> of static arrays containing polygon descriptions of the glyphs. If you >>> wish to extend it, you'll need to add more glyphs to this file. -------------- next part -------------- A non-text attachment was scrubbed... Name: TestFreeTypeTextMapperNoMath.png Type: image/png Size: 3185 bytes Desc: not available URL: From david.lonie at kitware.com Fri Aug 19 08:56:29 2016 From: david.lonie at kitware.com (David Lonie) Date: Fri, 19 Aug 2016 08:56:29 -0400 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: To add: vtkTextMapper, vtkTextActor, and vtkTextActor3D all share the same rendering engine, and support the most functionality (including non-english characters when supplied with an appropriate font file). Any other text objects likely do not. On Fri, Aug 19, 2016 at 8:53 AM, David Lonie wrote: > I'm not sure about vtkfont_bits, I've never had to use it before. > > And no, vtkVectorText cannot use characters outside of ASCII codepoints 33-126. > > vtkTextActor3D can use any characters desired when supplied with a > vtkTextProperty that has FontFamily=VTK_FONT_FILE and FontFile set to > a font file with the desired characters. See > Rendering/FreeType/TestFreeTypeTextMapperNoMath.cxx: > > // UTF-8 freetype handling: > vtkNew mapper10; > vtkNew actor10; > actor10->SetMapper(mapper10.GetPointer()); > mapper10->GetTextProperty()->SetFontFile(uncodeFontFile.c_str()); > mapper10->GetTextProperty()->SetFontFamily(VTK_FONT_FILE); > mapper10->GetTextProperty()->SetJustificationToCentered(); > mapper10->GetTextProperty()->SetVerticalJustificationToCentered(); > mapper10->GetTextProperty()->SetFontSize(18); > mapper10->GetTextProperty()->SetColor(0.0, 1.0, 0.7); > mapper10->SetInput("UTF-8 FreeType: > \xce\xa8\xd2\x94\xd2\x96\xd1\x84\xd2\xbe"); > actor10->SetPosition(300, 110); > > That uses a vtkTextMapper, but the underlying font rendering uses the > same backend as vtkTextActor3D, and renders the non-english characters > in the UTF-8 string set via SetInput (see attached). > > Dave > > On Thu, Aug 18, 2016 at 4:43 PM, ????? ???????? > wrote: >> And how to use no english characters in vtkVectorText? I'm not sure that >> vtkVectorText3D can use them. >> >> >> 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" >> ???????: >>> >>> So, do you or someone knows how to vtkfont_bits? >>> >>> >>> 18 ???. 2016 ?. 23:34 ???????????? "David Lonie" >>> ???????: >>>> >>>> On Thu, Aug 18, 2016 at 4:29 PM, David Lonie >>>> wrote: >>>> > vtkVectorText only supports a very limited set of fonts and >>>> > characters. I'm not sure how the polydata it uses was generated. >>>> >>>> To elaborate a bit: vtkVectorText does not use the vtkfont_bits, as >>>> far as I'm aware. See vtkVectorText.cxx -- it contains a large number >>>> of static arrays containing polygon descriptions of the glyphs. If you >>>> wish to extend it, you'll need to add more glyphs to this file. From utkarsh.ayachit at kitware.com Fri Aug 19 10:53:19 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 19 Aug 2016 10:53:19 -0400 Subject: [vtk-developers] Commit log guidelines In-Reply-To: <20160601123922.GB16753@megas.kitware.com> References: <20160517212133.956938156@mail.rogue-research.com> <20160531215910.GB26286@megas.kitware.com> <20160601123922.GB16753@megas.kitware.com> Message-ID: To resurrect this topic, I've created this MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/1846 I'm also including excellent comments from Will about comments for merge-requests. Thoughts? Utkarsh On Wed, Jun 1, 2016 at 8:39 AM, Ben Boeckel wrote: > On Tue, May 31, 2016 at 16:23:25 -0600, David Gobbi wrote: >> These are very nice sentences that express complete ideas. Perhaps >> they are compacted somewhat by removal of articles "the", "a", etc. >> but that's no reason to deprive them of their sentence-ness by removing >> the capitalization. > > Well, the removal of the period at the end makes it look weirder to me. > But I guess the base feeling is that: > > vtkCore: fix linking > > looks better than: > > vtkCore: Fix linking > > to me. *shrug* > > I'm not too worried about commit style as much as just good commit > messages. > > --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 > From bill.lorensen at gmail.com Fri Aug 19 12:25:56 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Aug 2016 12:25:56 -0400 Subject: [vtk-developers] Bug Tracker link on VTK Dashboard Message-ID: Folks, The Bug Tracker link on the dashboard still points to mantis. Bill -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Fri Aug 19 12:55:04 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 19 Aug 2016 12:55:04 -0400 Subject: [vtk-developers] MTime overflow resolved, possible API changes Message-ID: Folks, This issue, https://gitlab.kitware.com/vtk/vtk/issues/14310 has been resolved with this topic: https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 Some WIndows apps may notice an API change for app classes that define MTime as an unsigned long. This topic introduces a new type defined in Common/Core/vtkType.h: vtkMTimeType. Please try your long running apps with the latest vtk master. This was an extensive changed (over 400 files) and we may have missed something. I expect this will be part of vtk7.1. If your apps have their own vtk classes you will need to change the unsigned long mtime's to vtkMTimeType. If your app needs to support earlier VTK releases, this topic #define's VTK_HAS_MTIME_TYPE so you can make conditional compiles. Bill From utkarsh.ayachit at kitware.com Fri Aug 19 13:07:53 2016 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 19 Aug 2016 13:07:53 -0400 Subject: [vtk-developers] Bug Tracker link on VTK Dashboard In-Reply-To: References: Message-ID: Fixed. On Fri, Aug 19, 2016 at 12:25 PM, Bill Lorensen wrote: > Folks, > > The Bug Tracker link on the dashboard still points to mantis. > > Bill > > -- > 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 berk.geveci at kitware.com Mon Aug 22 08:12:54 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 22 Aug 2016 08:12:54 -0400 Subject: [vtk-developers] Next VTK hackathon In-Reply-To: References: Message-ID: Hi folks, We are good to go for September 8. We are happy to host people in our Clifton Park, NY and Carrboro, NC offfices (please let me know in advance) and we will have a Google Hangout open. The link is: https://hangouts.google.com/hangouts/_/kitware.com/vtk-hackathon We will start at 10am and will go until 5pm (all EDT). The focus will be on cleaning up the VTK dashboard and the issue tracker. Best, -berk On Tue, Aug 16, 2016 at 3:36 PM, Berk Geveci wrote: > Hi folks, > > I am thinking that September 8 would be a good date for our next > hackathon. I suggest that we primarily focus on the dashboards but also > work on the issue tracker. What do you think? > > Best, > -berk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Aug 22 10:34:17 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 22 Aug 2016 10:34:17 -0400 Subject: [vtk-developers] Rogue7 vtktiff dashboard build failure In-Reply-To: <20160818201502.30813858@mail.rogue-research.com> References: <20160726011546.2016066190@mail.rogue-research.com> <20160726140545.GA14126@rotor> <20160726142252.GA10822@rotor.kitware.com> <20160726144235.GB14126@rotor> <20160812140426.1347855963@mail.rogue-research.com> <20160812195118.GB1790@megas.kitware.com> <20160818201502.30813858@mail.rogue-research.com> Message-ID: <20160822143417.GA21586@megas.kitware.com> On Thu, Aug 18, 2016 at 16:15:02 -0400, Sean McBride wrote: > I haven't had time to understand Ben's request exactly... Ah, sorry. > 1) how do I make "CMake error right after it does the checks for the flag"? message(FATAL_ERROR) > 2) where do I pass --debug-trycompile? Is that a CXXFLAG or param to cmake? It's a flag to CMake itself. --Ben From ken.martin at kitware.com Mon Aug 22 14:21:53 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 22 Aug 2016 14:21:53 -0400 Subject: [vtk-developers] MTime overflow resolved, possible API changes In-Reply-To: References: Message-ID: Very nice job pushing this through Bill! This is a great fix for folks who deploy on Windows! On Fri, Aug 19, 2016 at 12:55 PM, Bill Lorensen wrote: > Folks, > > This issue, https://gitlab.kitware.com/vtk/vtk/issues/14310 has been > resolved with this topic: > https://gitlab.kitware.com/vtk/vtk/merge_requests/1790 > > Some WIndows apps may notice an API change for app classes that define > MTime as an unsigned long. This topic introduces a new type defined in > Common/Core/vtkType.h: vtkMTimeType. > > Please try your long running apps with the latest vtk master. > > This was an extensive changed (over 400 files) and we may have missed > something. > > I expect this will be part of vtk7.1. If your apps have their own vtk > classes you will need to change the unsigned long mtime's to > vtkMTimeType. > > If your app needs to support earlier VTK releases, this topic > #define's VTK_HAS_MTIME_TYPE so you can make conditional compiles. > > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 sean at rogue-research.com Mon Aug 22 17:49:40 2016 From: sean at rogue-research.com (Sean McBride) Date: Mon, 22 Aug 2016 17:49:40 -0400 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: References: Message-ID: <20160822214940.1544596496@mail.rogue-research.com> On Fri, 19 Aug 2016 08:53:24 -0400, David Lonie said: >And no, vtkVectorText cannot use characters outside of ASCII codepoints >33-126. Shouldn't we deprecate this class then? As I understand it, newer classes replace it, correct? 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 milefn at rpi.edu Mon Aug 22 20:01:29 2016 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Tue, 23 Aug 2016 00:01:29 +0000 Subject: [vtk-developers] Update Custom Uniforms for Shaders Message-ID: I need to update a custom uniform for a vtkOpenGLPolyDataMapper object. Where would be the best place for me to do this? I need to update it every render frame. I assume this would be similar to updating one of the color uniforms, but I can't find where those uniforms are updated. Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerald.Lodron at joanneum.at Tue Aug 23 09:22:25 2016 From: Gerald.Lodron at joanneum.at (Lodron, Gerald) Date: Tue, 23 Aug 2016 13:22:25 +0000 Subject: [vtk-developers] vtkCornerAnnotation crashes Message-ID: <45f2e51574df48da97ad8aa5362bf9ee@RZJMBX2.jr1.local> Hi I found out that the vtkCornerAnnotation::SetText leads to a crash if text has signs like "?". Issnt that supported? That sign is in normal character set below 255 Best regards, ------------------------------------------------------------------------------------ Gerald Lodron ? Researcher of Machine Vision Applications Group DIGITAL - Institute for Information and Communication Technologies ? JOANNEUM RESEARCH Forschungsgesellschaft mbH Steyrergasse 17, 8010 Graz, AUSTRIA ? phone:?? +43-316-876-1751??? general fax: +43-316-876-1751 web: http://www.joanneum.at/digital e-mail: gerald.lodron at joanneum.at From Gerald.Lodron at joanneum.at Tue Aug 23 09:33:21 2016 From: Gerald.Lodron at joanneum.at (Lodron, Gerald) Date: Tue, 23 Aug 2016 13:33:21 +0000 Subject: [vtk-developers] vtkCornerAnnotation crashes Message-ID: Sorry, was something different, ignore this -----Urspr?ngliche Nachricht----- Von: Lodron, Gerald Gesendet: Dienstag, 23. August 2016 15:22 An: VTK Developer (vtk-developers at vtk.org); (vtkusers at vtk.org) Betreff: vtkCornerAnnotation crashes Hi I found out that the vtkCornerAnnotation::SetText leads to a crash if text has signs like "?". Issnt that supported? That sign is in normal character set below 255 Best regards, ------------------------------------------------------------------------------------ Gerald Lodron ? Researcher of Machine Vision Applications Group DIGITAL - Institute for Information and Communication Technologies ? JOANNEUM RESEARCH Forschungsgesellschaft mbH Steyrergasse 17, 8010 Graz, AUSTRIA ? phone:?? +43-316-876-1751 general fax: +43-316-876-1751 web: http://www.joanneum.at/digital e-mail: gerald.lodron at joanneum.at From ken.martin at kitware.com Tue Aug 23 09:38:34 2016 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 23 Aug 2016 09:38:34 -0400 Subject: [vtk-developers] Update Custom Uniforms for Shaders In-Reply-To: References: Message-ID: See this example https://gitlab.kitware.com/vtk/vtk/blob/v7.0.0.rc2/Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx referenced from http://www.vtk.org/Wiki/Shader_In_VTK that should get you going. - Ken On Mon, Aug 22, 2016 at 8:01 PM, Milef, Nicholas Boris wrote: > I need to update a custom uniform for a vtkOpenGLPolyDataMapper object. > Where would be the best place for me to do this? > > I need to update it every render frame. I assume this would be similar to > updating one of the color uniforms, but I can't find where those uniforms > are updated. > > Thanks, > Nick > > _______________________________________________ > 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 > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 david.lonie at kitware.com Tue Aug 23 09:52:09 2016 From: david.lonie at kitware.com (David Lonie) Date: Tue, 23 Aug 2016 09:52:09 -0400 Subject: [vtk-developers] [vtkusers] vtkTextSource vtkfont_bits generation In-Reply-To: <20160822214940.1544596496@mail.rogue-research.com> References: <20160822214940.1544596496@mail.rogue-research.com> Message-ID: On Mon, Aug 22, 2016 at 5:49 PM, Sean McBride wrote: > On Fri, 19 Aug 2016 08:53:24 -0400, David Lonie said: > >>And no, vtkVectorText cannot use characters outside of ASCII codepoints >>33-126. > > Shouldn't we deprecate this class then? As I understand it, newer classes replace it, correct? Yes and no. There are better ways to render text, but vtkVectorText produces a polydata representation of the text (each glyph is actually drawn), while the others render a textured quad with a image of the rendered string. This may be useful if there's a need to transform the polydata somehow for some reason or something, so there is some unique functionality there. Plus the usual anti-deprecation arguments about legacy client code and customers, etc. Dave From s.kitlu at gmail.com Wed Aug 24 04:48:14 2016 From: s.kitlu at gmail.com (s.kitlu) Date: Wed, 24 Aug 2016 01:48:14 -0700 (MST) Subject: [vtk-developers] vtkCenterOfMass() is not working in ubuntu 14.0 Message-ID: <1472028493735-5739912.post@n5.nabble.com> Hello, I am using python2.7 & pythonvtk. I tried to use vtk.vtkCenterOfMass() to get the center of stl/vtk file, But it is throwing Error: AttributeError: 'module' object has no attribute 'vtkCenterOfMass' in Ubunut14.04. But this is working in Ubunut 16 release. I did update and upgrade to pythonvtk but still is not working in Ubunut14.0 . How to make vtkCenterOfMass work in Ubunut14.0? Thanks, Kitlu -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkCenterOfMass-is-not-working-in-ubuntu-14-0-tp5739912.html Sent from the VTK - Dev mailing list archive at Nabble.com. From dave.demarle at kitware.com Wed Aug 24 09:56:38 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 24 Aug 2016 09:56:38 -0400 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: We moved to rsync'ing the directory from the dashboard machine to the web server. If you ask nice I'll make the dashboard machine tar it up and send that over too. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Aug 18, 2016 at 6:06 AM, Mathieu Malaterre < mathieu.malaterre at gmail.com> wrote: > Hi there, > > Does anyone knows what happen to this file: > > $ HEAD http://www.vtk.org/files/nightly/vtkNightlyDoc.tag.gz > 403 Forbidden > Date: Thu, 18 Aug 2016 10:03:39 GMT > Via: HTTP/1.1 proxy10228 > Server: Apache > Vary: Accept-Encoding > Content-Length: 4151 > Content-Type: text/html > Client-Date: Thu, 18 Aug 2016 10:03:35 GMT > Client-Peer: 66.194.253.19:80 > Client-Response-Num: 1 > Keep-Alive: 60 > > Thanks much, > -- > Mathieu > _______________________________________________ > 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.malaterre at gmail.com Wed Aug 24 10:00:20 2016 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Wed, 24 Aug 2016 16:00:20 +0200 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: Hi Dave ! On Wed, Aug 24, 2016 at 3:56 PM, David E DeMarle wrote: > We moved to rsync'ing the directory from the dashboard machine to the web > server. > > If you ask nice I'll make the dashboard machine tar it up and send that over > too. s'il vous plait monsieur :) From dave.demarle at kitware.com Wed Aug 24 10:07:49 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 24 Aug 2016 10:07:49 -0400 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: Works for me. Check tomorrow please. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Aug 24, 2016 at 10:00 AM, Mathieu Malaterre < mathieu.malaterre at gmail.com> wrote: > Hi Dave ! > > On Wed, Aug 24, 2016 at 3:56 PM, David E DeMarle > wrote: > > We moved to rsync'ing the directory from the dashboard machine to the web > > server. > > > > If you ask nice I'll make the dashboard machine tar it up and send that > over > > too. > > s'il vous plait monsieur :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Aug 24 10:29:49 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 24 Aug 2016 10:29:49 -0400 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: New URL is: http://www.vtk.org/doc/nightly/vtkNightlyDoc.tar.gz David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Aug 24, 2016 at 10:07 AM, David E DeMarle wrote: > Works for me. > > Check tomorrow please. > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Aug 24, 2016 at 10:00 AM, Mathieu Malaterre < > mathieu.malaterre at gmail.com> wrote: > >> Hi Dave ! >> >> On Wed, Aug 24, 2016 at 3:56 PM, David E DeMarle >> wrote: >> > We moved to rsync'ing the directory from the dashboard machine to the >> web >> > server. >> > >> > If you ask nice I'll make the dashboard machine tar it up and send that >> over >> > too. >> >> s'il vous plait monsieur :) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.malaterre at gmail.com Wed Aug 24 10:56:33 2016 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Wed, 24 Aug 2016 16:56:33 +0200 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: Dave, On Wed, Aug 24, 2016 at 4:29 PM, David E DeMarle wrote: > New URL is: > http://www.vtk.org/doc/nightly/vtkNightlyDoc.tar.gz I really meant 'vtkNightlyDoc.tag.gz' (tag!=tar). This is the compressed tag file generating during doxygen + S. Barr? scripts. -M From dave.demarle at kitware.com Wed Aug 24 11:01:35 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 24 Aug 2016 11:01:35 -0400 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: I just put what I _think_ you want next to the tar.gz. Please try it. What is that used for? I can put that up too if you tell me why and ask plus nicely. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Aug 24, 2016 at 10:56 AM, Mathieu Malaterre < mathieu.malaterre at gmail.com> wrote: > Dave, > > On Wed, Aug 24, 2016 at 4:29 PM, David E DeMarle > wrote: > > New URL is: > > http://www.vtk.org/doc/nightly/vtkNightlyDoc.tar.gz > > I really meant 'vtkNightlyDoc.tag.gz' (tag!=tar). This is the > compressed tag file generating during doxygen + S. Barr? scripts. > > -M > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.malaterre at gmail.com Thu Aug 25 01:39:17 2016 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Thu, 25 Aug 2016 07:39:17 +0200 Subject: [vtk-developers] Where is vtkNightlyDoc.tag.gz ? In-Reply-To: References: Message-ID: Hi, On Wed, Aug 24, 2016 at 5:01 PM, David E DeMarle wrote: > I just put what I _think_ you want next to the tar.gz. Please try it. Great ! that's the file I was looking for. > What is that used for? I can put that up too if you tell me why and ask plus > nicely. Back in GDCM 2.4 series, the tag file was present (check inheritance diag): http://gdcm.sourceforge.net/2.4/html/classvtkGDCMImageReader.html But during the 2.6 series the file disapear: http://gdcm.sourceforge.net/2.6/html/classvtkGDCMImageReader.html Thanks much for your help, I'll re-run the documentation on next GDCM release. -M From david.gobbi at gmail.com Thu Aug 25 10:08:51 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 25 Aug 2016 08:08:51 -0600 Subject: [vtk-developers] Dropping Python 2.6 and Python 3.2 Message-ID: Hi All, The VTK master now emits a cmake warning if VTK is configured with Python 2.6 or Python 3.2. These older versions of Python will still work with VTK for now (as long as you don't enable WebPython), but VTK 8 is likely to require Python 2.7 or Python 3.3+. Of course VTK can still be built without Python. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 25 11:09:59 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 25 Aug 2016 11:09:59 -0400 Subject: [vtk-developers] HiDPI / Retina display support In-Reply-To: References: <20160810163230.2044410374@mail.rogue-research.com> Message-ID: <20160825150959.1143808803@mail.rogue-research.com> On Wed, 10 Aug 2016 14:19:42 -0400, Marcus D. Hanwell said: >> - which VTK API should be pixel-based, which should be point-based? >Presumably everything is pixel based today, do we want to change any? >If so, some API would need to change from int to double. > >I think everything should be pixel-based, and Qt has a similar view for >OpenGL. So the current implementation of vtkCocoaRenderWindow::GetScreenSize() returns points, not pixels. But, after searching VTK for GetScreenSize: 1- I see that all implementations are broken with respect to multi-monitor setups. 2- its docs say "Get the current size of the screen in pixels". Which is *the* screen? 3- implementations (dangerously) return an inner pointer 4- it's hardly used within VTK itself, only in: (a) internal calculations to decide full screen window size (b) vtkParallelRenderManager::SetRenderWindowSize() What's the use case of this API anyway? For the 4a use above, for Cocoa at least, returning points is actually preferable, because the Cocoa window-creation APIs take points. My current inclination is to deprecate this API (point 3 is enough IMHO). Thoughts? 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 cory.quammen at kitware.com Thu Aug 25 14:29:10 2016 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 25 Aug 2016 14:29:10 -0400 Subject: [vtk-developers] GitLab upgrade today, August 25, at 5:15PM EST Message-ID: Dear developers, gitlab.kitware.com will be upgraded this evening at 5:15pm to enable new features. Access may be briefly limited. Sorry for the short notice. Thanks, Cory -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 25 16:09:53 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 25 Aug 2016 16:09:53 -0400 Subject: [vtk-developers] MTime overflow resolved, possible API changes In-Reply-To: References: Message-ID: <20160825200953.2108188582@mail.rogue-research.com> On Fri, 19 Aug 2016 12:55:04 -0400, Bill Lorensen said: >This was an extensive changed (over 400 files) and we may have missed >something. Bill, One followup perhaps is things like this: vtkMTimeType vtkOpenGLPolyDataMapper::GetRenderPassStageMTime(vtkActor *actor) { vtkMTimeType renderPassMTime = 0; ... renderPassMTime = VTK_UNSIGNED_LONG_MAX; ... We should probably introduce a VTK_MTIME_MAX. A search of "MTime.*MAX" found a couple of similar places. 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 Thu Aug 25 16:17:14 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 25 Aug 2016 16:17:14 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: <8A3D6FC5-66B2-4EE6-BC75-B9190F6A0BDB@rogue-research.com> References: <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com> <8A3D6FC5-66B2-4EE6-BC75-B9190F6A0BDB@rogue-research.com> Message-ID: <20160825201714.405989593@mail.rogue-research.com> Hi Ken, We are still trying to fully understand our bug, but wondered if you (or anyone :)) could clarify a couple of things, all in the form of true/false :) - actors are tied to a particular render window - thus they can't be added to two render windows, or moved between two, etc. - mappers are likewise tied to a particular render window - it is permitted to change an actor's mapper - a single mapper can be shared by multiple actors Is that all correct? Thanks, Sean On Thu, 11 Aug 2016 14:31:31 -0400, Seun Odutola said: >Hi Ken, > >I have a scenario where I have an actor and a mapper connected to it (so >in the application window it renders i.e: a sphere). The user has the >ability to change the shape (to cube for example) via the UI, so >internally this is what I?m doing: I have an actor that I keep around, >when the user changes the shape, I just create a new mapper and set the >actor?s mapper directly to the new one (not calling the >ReleaseGraphicsResources). > >First, is this reasonable? Or every time I need to create a new mapper >is it best to also create a new actor to connect it to? or does it >suffice to just swap the actor?s mapper by calling SetMapper()? In the >latter case, then one needs to call ReleaseGraphicsResources on the >previous mapper prior to setting up a new one, right? > >Relatedly, I would like to know for the sake of clarity if mappers can >be shared between actors; that is, is the relationship of an actor and >its mapper a 1 to 1 relationship? > >Regards, > Seun > >> On Aug 11, 2016, at 11:52 AM, Seun Odutola wrote: >> >> Thanks for the expeditious and detailed response Ken, I truly >appreciate it. Perfect, this is exactly what I thought but needed the >opinion of someone more experienced. I had a closer look at vtkActor and >noticed how it checks the validity of it?s Mapper prior to releasing it >(in its release graphics resource function) proof that it indeed needs >to be released via calling ReleaseGraphicsResources sometime down the >line. Thanks >> >> Regards, >> Seun. >> >>> On Aug 11, 2016, at 11:44 AM, Ken Martin > wrote: >>> >>> Yes you definitely want to call ReleaseGraphicsResources when you are >done using a graphics object, but are not done using its window. >Normally VTK handles this for you so you do not have to worry about it. >>> >>> Many classes in VTK create and hold onto OpenGL resources. At some >point those resources need to be freed. Normally before an OpenGL >context/window is destroyed it will call ReleaseGraphicsResources on >everything connected to it so that they are all freed before it releases >the context. But if you have detached a mapper from the RenderWindow/ >Renderer/Actor (but not yet deleted it) then that does not happen. Then >at some other point that mapper tries to free its resources but the >context that owned them is already gone causing an error. >>> >>> Thanks >>> Ken >>> >>> >>> >>> On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola research.com > wrote: >>> Hi Ken, >>> >>> Thanks for the suggestion. I do have a little question though, is >it a necessary convention to call release graphics resources on the old >mapper prior to setting a new one? I was wondering judging from your >statement (quick fix) if this was just a hack. >>> >>> Regards, >>> Seun >>>> On Aug 8, 2016, at 1:00 PM, Ken Martin > wrote: >>>> >>>> How do you change the mapper? Do you immediately destroy the old >mapper or leave it around for later? I suspect the old mapper is >getting destroyed later than it should. One thing you can try as a quick >fix is >>>> >>>> actor->SetMapper(shiny new mapper); >>>> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have >the window handy) >>>> ... >>>> >>>> >>>> >>>> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola research.com > wrote: >>>> Hello everyone, >>>> >>>> I have a crash that occurs in my application when running vtk >with the GL2 rendered enabled but not with GL1. So here is the >situation, in my program when I change the shape of my poly data mapper, >basically setting the mapper of an actor in my scene to a new poly data >mapper it results in a crash. The crash is situated in >vtkOpenGLBufferObject?s destructor, specifically the deletion of the >Internal?s handle. I have tried to verify if the handle is valid prior >to reaching the destructor which it seems to be, my main concern is if >the handle is filled with garbage (a non-zero value) it might >effectively pass the test condition and try to invoke glDeleteBuffer. >Has anyone experienced anything similar to this? >>>> >>>> Regards, >>>> Seun From ken.martin at kitware.com Thu Aug 25 19:12:34 2016 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 25 Aug 2016 19:12:34 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: <20160825201714.405989593@mail.rogue-research.com> References: <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com> <8A3D6FC5-66B2-4EE6-BC75-B9190F6A0BDB@rogue-research.com> <20160825201714.405989593@mail.rogue-research.com> Message-ID: > > - actors are tied to a particular render window > - thus they can't be added to two render windows, or moved between two, > etc. > Essentially yes, mainly because an actor has a mapper and mappers should not be shared between windows. > - mappers are likewise tied to a particular render window > Yes. Mappers create buffer objects that are tied to a window's OpenGL context. Right now we do not support sharing buffers between contexts (it could be added) so having the same mapper in two windows would either cause the buffers to be rebuilt and sent down every frame or an OpenGL error. You could share an actor/mapper between two windows if you knew only one would active at a time. You would need to call release graphics resources every time you switch which window is active to make sure the buffers etc all rebuilt. But the general answer is they are not designed to be shared. > - it is permitted to change an actor's mapper > Yes, to a new mapper it should be fine. If reusing an existing mapper from another window you must call ReleaseGraphicsResources before using it in a different window. > - a single mapper can be shared by multiple actors > > Uh. Maybe :-) So a single mapper, shared by multiple actors in the same window (they can be in different renderers) should not crash. My concern is that the rendering process keeps track of a lot of modified times to know when to rebuild or change "things". With multiple actors sharing the same mapper you may either end up with changes not being reflected or the mapper rebuilding every time. For example if you had two actors, two properties, one mapper. One property is set to wireframe, the other to surface. It might well work, but the mapper would be rebuilding the IBOs every single frame because it uses different IBOs for wireframe versus surface. Is that all correct? > > Let me try to add some meta comments here that may help. Actors are light weight, feel free to make two if you need two. Making thousands is a different story but generally there is no performance advantage to sharing them. Same with lights, and properties. Mappers hold and build a lot of buffers and those buffers are heavily dependent on the properties/etc. Mappers can consume a lot of memory if their data is large so I can see the desire to share them if you want the same geometry in multiple windows or viewports. The mapper is not really coded to be shared. If you have a use case where sharing a mapper would be good then the right solution would be to add some sort of buffer sharing cache in VTK. I would like to see that at some point as it has value and doesn't seem crazy hard. If you are creating/rendering thousands of separate items, then the right solution depends on the specifics our your situation. For example, glyph3dmapper is great at drawing thousands of the same geometry in different places, with different colors, and even different orientations/scales. It can do it very quickly and with a low memory footprint. Creating actors for all of those would be far more costly. Thousands of spheres/cylinders, the OpenGLSphereMapper or OpenGLCylinderMapper etc. Lots of different geometry with different visibility/color vtkCompositePolyDataMapper2 is the best choice. Hope that Helps Ken > Thanks, > > Sean > > > On Thu, 11 Aug 2016 14:31:31 -0400, Seun Odutola said: > > >Hi Ken, > > > >I have a scenario where I have an actor and a mapper connected to it (so > >in the application window it renders i.e: a sphere). The user has the > >ability to change the shape (to cube for example) via the UI, so > >internally this is what I?m doing: I have an actor that I keep around, > >when the user changes the shape, I just create a new mapper and set the > >actor?s mapper directly to the new one (not calling the > >ReleaseGraphicsResources). > > > >First, is this reasonable? Or every time I need to create a new mapper > >is it best to also create a new actor to connect it to? or does it > >suffice to just swap the actor?s mapper by calling SetMapper()? In the > >latter case, then one needs to call ReleaseGraphicsResources on the > >previous mapper prior to setting up a new one, right? > > > >Relatedly, I would like to know for the sake of clarity if mappers can > >be shared between actors; that is, is the relationship of an actor and > >its mapper a 1 to 1 relationship? > > > >Regards, > > Seun > > > >> On Aug 11, 2016, at 11:52 AM, Seun Odutola > wrote: > >> > >> Thanks for the expeditious and detailed response Ken, I truly > >appreciate it. Perfect, this is exactly what I thought but needed the > >opinion of someone more experienced. I had a closer look at vtkActor and > >noticed how it checks the validity of it?s Mapper prior to releasing it > >(in its release graphics resource function) proof that it indeed needs > >to be released via calling ReleaseGraphicsResources sometime down the > >line. Thanks > >> > >> Regards, > >> Seun. > >> > >>> On Aug 11, 2016, at 11:44 AM, Ken Martin >> wrote: > >>> > >>> Yes you definitely want to call ReleaseGraphicsResources when you are > >done using a graphics object, but are not done using its window. > >Normally VTK handles this for you so you do not have to worry about it. > >>> > >>> Many classes in VTK create and hold onto OpenGL resources. At some > >point those resources need to be freed. Normally before an OpenGL > >context/window is destroyed it will call ReleaseGraphicsResources on > >everything connected to it so that they are all freed before it releases > >the context. But if you have detached a mapper from the RenderWindow/ > >Renderer/Actor (but not yet deleted it) then that does not happen. Then > >at some other point that mapper tries to free its resources but the > >context that owned them is already gone causing an error. > >>> > >>> Thanks > >>> Ken > >>> > >>> > >>> > >>> On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola >research.com > wrote: > >>> Hi Ken, > >>> > >>> Thanks for the suggestion. I do have a little question though, is > >it a necessary convention to call release graphics resources on the old > >mapper prior to setting a new one? I was wondering judging from your > >statement (quick fix) if this was just a hack. > >>> > >>> Regards, > >>> Seun > >>>> On Aug 8, 2016, at 1:00 PM, Ken Martin >> wrote: > >>>> > >>>> How do you change the mapper? Do you immediately destroy the old > >mapper or leave it around for later? I suspect the old mapper is > >getting destroyed later than it should. One thing you can try as a quick > >fix is > >>>> > >>>> actor->SetMapper(shiny new mapper); > >>>> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have > >the window handy) > >>>> ... > >>>> > >>>> > >>>> > >>>> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola >research.com > wrote: > >>>> Hello everyone, > >>>> > >>>> I have a crash that occurs in my application when running vtk > >with the GL2 rendered enabled but not with GL1. So here is the > >situation, in my program when I change the shape of my poly data mapper, > >basically setting the mapper of an actor in my scene to a new poly data > >mapper it results in a crash. The crash is situated in > >vtkOpenGLBufferObject?s destructor, specifically the deletion of the > >Internal?s handle. I have tried to verify if the handle is valid prior > >to reaching the destructor which it seems to be, my main concern is if > >the handle is filled with garbage (a non-zero value) it might > >effectively pass the test condition and try to invoke glDeleteBuffer. > >Has anyone experienced anything similar to this? > >>>> > >>>> Regards, > >>>> Seun > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 pandia005 at gmail.com Fri Aug 26 04:29:09 2016 From: pandia005 at gmail.com (Pandia raja) Date: Fri, 26 Aug 2016 13:59:09 +0530 Subject: [vtk-developers] Reg:Equivalent Java class for vtkSmartPointer Message-ID: Hi, Am trying to convert C++ code to java. Kindly provide me the equivalent Java class for vtkSmartPointer . vtkSmartPointer gf2 =vtkSmartPointer::New(); Thanks in advance. Regards, Pandiyan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Fri Aug 26 10:58:58 2016 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Fri, 26 Aug 2016 08:58:58 -0600 Subject: [vtk-developers] Reg:Equivalent Java class for vtkSmartPointer In-Reply-To: References: Message-ID: vtkGeometryFilter gf2 = new vtkGeometryFilter(); Since you are in Java everything is a smart pointer. On Fri, Aug 26, 2016 at 2:29 AM, Pandia raja wrote: > Hi, > > Am trying to convert C++ code to java. Kindly provide me the equivalent > Java class for vtkSmartPointer . > > vtkSmartPointer gf2 =vtkSmartPointer::New(); > > > Thanks in advance. > > Regards, > > Pandiyan > > > _______________________________________________ > 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 Mon Aug 29 09:44:29 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 29 Aug 2016 09:44:29 -0400 Subject: [vtk-developers] gitlab error? Message-ID: OK this one is new to me - gitlab error writing to Redis: ring a bell with anyone? ken.martin at smurf /C/Users/ken.martin/Documents/vtk/vtk (add_vr_support) $ git gitlab-push -f Fetching gitlab master Fetching origin master Pushing to gitlab Enter passphrase for key '/home/ken.martin/.ssh/id_rsa': Counting objects: 80, done. Delta compression using up to 8 threads. Compressing objects: 100% (75/75), done. Writing objects: 100% (80/80), 51.88 KiB | 0 bytes/s, done. Total 80 (delta 44), reused 13 (delta 3) remote: GitLab: An unexpected error occurred in writing to Redis: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error. error: failed to push some refs to 'git at gitlab.kitware.com: ken-martin/vtk.git' To git at gitlab.kitware.com:ken-martin/vtk.git ! HEAD:refs/heads/add_vr_support [remote rejected] (pre-receive hook declined) ! 62ab108947a7de7f3c63cefdaf21fb87fd3f1879:refs/heads/master [remote rejected] (pre-receive hook declined) -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 shawn.waldon at kitware.com Mon Aug 29 09:47:51 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 29 Aug 2016 09:47:51 -0400 Subject: [vtk-developers] gitlab error? In-Reply-To: References: Message-ID: I'm getting a 500 Internal Server Error when I try to get to gitlab.kitware.com via a browser. It's probably related. Shawn On Mon, Aug 29, 2016 at 9:44 AM, Ken Martin wrote: > > OK this one is new to me - gitlab error writing to Redis: ring a bell > with anyone? > > > ken.martin at smurf /C/Users/ken.martin/Documents/vtk/vtk (add_vr_support) > $ git gitlab-push -f > Fetching gitlab master > Fetching origin master > Pushing to gitlab > Enter passphrase for key '/home/ken.martin/.ssh/id_rsa': > Counting objects: 80, done. > Delta compression using up to 8 threads. > Compressing objects: 100% (75/75), done. > Writing objects: 100% (80/80), 51.88 KiB | 0 bytes/s, done. > Total 80 (delta 44), reused 13 (delta 3) > remote: GitLab: An unexpected error occurred in writing to Redis: MISCONF > Redis is configured to save RDB snapshots, but is currently not able to > persist on disk. Commands that may modify the data set are disabled. Please > check Redis logs for details about the error. > error: failed to push some refs to 'git at gitlab.kitware.com:ken- > martin/vtk.git' > To git at gitlab.kitware.com:ken-martin/vtk.git > ! HEAD:refs/heads/add_vr_support [remote rejected] (pre-receive > hook declined) > ! 62ab108947a7de7f3c63cefdaf21fb87fd3f1879:refs/heads/master > [remote rejected] (pre-receive hook declined) > > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Aug 29 10:12:07 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 29 Aug 2016 10:12:07 -0400 Subject: [vtk-developers] gitlab error? In-Reply-To: References: Message-ID: Yes site is doen. sys admin is investigating. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Aug 29, 2016 at 9:47 AM, Shawn Waldon wrote: > I'm getting a 500 Internal Server Error when I try to get to > gitlab.kitware.com via a browser. It's probably related. > > Shawn > > On Mon, Aug 29, 2016 at 9:44 AM, Ken Martin > wrote: > >> >> OK this one is new to me - gitlab error writing to Redis: ring a bell >> with anyone? >> >> >> ken.martin at smurf /C/Users/ken.martin/Documents/vtk/vtk (add_vr_support) >> $ git gitlab-push -f >> Fetching gitlab master >> Fetching origin master >> Pushing to gitlab >> Enter passphrase for key '/home/ken.martin/.ssh/id_rsa': >> Counting objects: 80, done. >> Delta compression using up to 8 threads. >> Compressing objects: 100% (75/75), done. >> Writing objects: 100% (80/80), 51.88 KiB | 0 bytes/s, done. >> Total 80 (delta 44), reused 13 (delta 3) >> remote: GitLab: An unexpected error occurred in writing to Redis: MISCONF >> Redis is configured to save RDB snapshots, but is currently not able to >> persist on disk. Commands that may modify the data set are disabled. Please >> check Redis logs for details about the error. >> error: failed to push some refs to 'git at gitlab.kitware.com:ken-ma >> rtin/vtk.git' >> To git at gitlab.kitware.com:ken-martin/vtk.git >> ! HEAD:refs/heads/add_vr_support [remote rejected] (pre-receive >> hook declined) >> ! 62ab108947a7de7f3c63cefdaf21fb87fd3f1879:refs/heads/master >> [remote rejected] (pre-receive hook declined) >> >> >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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 >> >> >> > > _______________________________________________ > 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 joaolsvieira at gmail.com Tue Aug 30 10:47:39 2016 From: joaolsvieira at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Luis?=) Date: Tue, 30 Aug 2016 10:47:39 -0400 Subject: [vtk-developers] vtkInteractorStyleTrackballActor and vtkInteractorStyleTrackballCamera Message-ID: Hello vtkdevelopers, There are ways to apply two different vtkInteractorStyle against same actor? I have an actor that I used vtkInteractorStyleTrackballCamera to pick some points by mouse leftclick (OnLeftButtonDown()) that works smoothly , then I have two actors with same vtkInteractorStyleTrackballCamera and I need pick/select distinctly one between these to start some process independently with vtkInteractorStyleTrackballActor. However, once applied TrackballCamera style and I am applying TrackballActor to same actors one of the actors that is using LeftButton event from TrackballCamera doesn?t respond the new style. My actors (two independent cylinders source) I am following this example to TrackballActor: http://www.vtk.org/Wiki/VTK/ Examples/Cxx/Interaction/SelectAnActor I am following this example to TrackballCamera:http://www. vtk.org/Wiki/VTK/Examples/Cxx/Interaction/DoubleClick Thank you very much for any help, *Joao* -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Wed Aug 31 11:34:57 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 31 Aug 2016 11:34:57 -0400 Subject: [vtk-developers] Rogue7 vtktiff dashboard build failure In-Reply-To: <20160822143417.GA21586@megas.kitware.com> References: <20160726011546.2016066190@mail.rogue-research.com> <20160726140545.GA14126@rotor> <20160726142252.GA10822@rotor.kitware.com> <20160726144235.GB14126@rotor> <20160812140426.1347855963@mail.rogue-research.com> <20160812195118.GB1790@megas.kitware.com> <20160818201502.30813858@mail.rogue-research.com> <20160822143417.GA21586@megas.kitware.com> Message-ID: Sean & Ben, ping? --Shawn On Mon, Aug 22, 2016 at 10:34 AM, Ben Boeckel wrote: > On Thu, Aug 18, 2016 at 16:15:02 -0400, Sean McBride wrote: > > I haven't had time to understand Ben's request exactly... > > Ah, sorry. > > > 1) how do I make "CMake error right after it does the checks for the > flag"? > > message(FATAL_ERROR) > > > 2) where do I pass --debug-trycompile? Is that a CXXFLAG or param to > cmake? > > It's a flag to CMake itself. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun at rogue-research.com Wed Aug 31 15:57:36 2016 From: seun at rogue-research.com (Seun Odutola) Date: Wed, 31 Aug 2016 15:57:36 -0400 Subject: [vtk-developers] Crash with OpenGL2 Renderer only in vtkOpenGLBufferObject destructor. In-Reply-To: References: <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com> <8A3D6FC5-66B2-4EE6-BC75-B9190F6A0BDB@rogue-research.com> <20160825201714.405989593@mail.rogue-research.com> Message-ID: <6917D6CD-4DA5-4C4F-9C38-6B19C2846DBA@rogue-research.com> Thanks for the detailed response. We have created a simple test app that mimics our main app in order to simplify the task of debugging and still the crash reproduces itself. On reviewing our test app alongside your response I can say that we are not violating any of the warnings / points stated. No actors are being shared between render windows, nor mappers. Each window has its actor and mappers separated (thus they act as standalone). Recall that our crash occurs when setting the mapper of an actor (changing its previous mapper). Our application is Mac-based and there are two main ways to draw on OS X: via NSView or via CALayer. It seems the crash only occurs when we draw via CAOpenGLLayer and not when using NSView. This is mysterious to us. Our test app is based on the VTK/Examples/GUI/Cocoa sample. Do you think you could take a look? We annotated the interesting bits with "Ken" comments. It's here: https://www.rogue-research.com/Foo.zip To reproduce the crash: - launch the app - click ?create actor" next to one vtk renderwindow - click "X" next to the other vtk renderwindow - click ?swap mapper" next to the first vtk render window p.s: I would also like to know from your previous response ?You would need to call release graphics resources every time you switch which window is active to make sure the buffers etc all rebuilt? - does this also mean for instance if we have 2 render windows and we close our which in turns makes the last one active do we need to call release graphics resources on the one just terminated? Just wondering. > On Aug 25, 2016, at 7:12 PM, Ken Martin wrote: > > - actors are tied to a particular render window > - thus they can't be added to two render windows, or moved between two, etc. > > Essentially yes, mainly because an actor has a mapper and mappers should not be shared between windows. > > - mappers are likewise tied to a particular render window > > Yes. Mappers create buffer objects that are tied to a window's OpenGL context. Right now we do not support sharing buffers between contexts (it could be added) so having the same mapper in two windows would either cause the buffers to be rebuilt and sent down every frame or an OpenGL error. You could share an actor/mapper between two windows if you knew only one would active at a time. You would need to call release graphics resources every time you switch which window is active to make sure the buffers etc all rebuilt. But the general answer is they are not designed to be shared. > > - it is permitted to change an actor's mapper > > Yes, to a new mapper it should be fine. If reusing an existing mapper from another window you must call ReleaseGraphicsResources before using it in a different window. > > - a single mapper can be shared by multiple actors > > > Uh. Maybe :-) So a single mapper, shared by multiple actors in the same window (they can be in different renderers) should not crash. My concern is that the rendering process keeps track of a lot of modified times to know when to rebuild or change "things". With multiple actors sharing the same mapper you may either end up with changes not being reflected or the mapper rebuilding every time. For example if you had two actors, two properties, one mapper. One property is set to wireframe, the other to surface. It might well work, but the mapper would be rebuilding the IBOs every single frame because it uses different IBOs for wireframe versus surface. > > Is that all correct? > > > Let me try to add some meta comments here that may help. Actors are light weight, feel free to make two if you need two. Making thousands is a different story but generally there is no performance advantage to sharing them. Same with lights, and properties. > > Mappers hold and build a lot of buffers and those buffers are heavily dependent on the properties/etc. Mappers can consume a lot of memory if their data is large so I can see the desire to share them if you want the same geometry in multiple windows or viewports. The mapper is not really coded to be shared. If you have a use case where sharing a mapper would be good then the right solution would be to add some sort of buffer sharing cache in VTK. I would like to see that at some point as it has value and doesn't seem crazy hard. > > If you are creating/rendering thousands of separate items, then the right solution depends on the specifics our your situation. For example, glyph3dmapper is great at drawing thousands of the same geometry in different places, with different colors, and even different orientations/scales. It can do it very quickly and with a low memory footprint. Creating actors for all of those would be far more costly. Thousands of spheres/cylinders, the OpenGLSphereMapper or OpenGLCylinderMapper etc. Lots of different geometry with different visibility/color vtkCompositePolyDataMapper2 is the best choice. > > Hope that Helps > Ken > > > > Thanks, > > Sean > > > On Thu, 11 Aug 2016 14:31:31 -0400, Seun Odutola said: > > >Hi Ken, > > > >I have a scenario where I have an actor and a mapper connected to it (so > >in the application window it renders i.e: a sphere). The user has the > >ability to change the shape (to cube for example) via the UI, so > >internally this is what I?m doing: I have an actor that I keep around, > >when the user changes the shape, I just create a new mapper and set the > >actor?s mapper directly to the new one (not calling the > >ReleaseGraphicsResources). > > > >First, is this reasonable? Or every time I need to create a new mapper > >is it best to also create a new actor to connect it to? or does it > >suffice to just swap the actor?s mapper by calling SetMapper()? In the > >latter case, then one needs to call ReleaseGraphicsResources on the > >previous mapper prior to setting up a new one, right? > > > >Relatedly, I would like to know for the sake of clarity if mappers can > >be shared between actors; that is, is the relationship of an actor and > >its mapper a 1 to 1 relationship? > > > >Regards, > > Seun > > > >> On Aug 11, 2016, at 11:52 AM, Seun Odutola > wrote: > >> > >> Thanks for the expeditious and detailed response Ken, I truly > >appreciate it. Perfect, this is exactly what I thought but needed the > >opinion of someone more experienced. I had a closer look at vtkActor and > >noticed how it checks the validity of it?s Mapper prior to releasing it > >(in its release graphics resource function) proof that it indeed needs > >to be released via calling ReleaseGraphicsResources sometime down the > >line. Thanks > >> > >> Regards, > >> Seun. > >> > >>> On Aug 11, 2016, at 11:44 AM, Ken Martin > >>> wrote: > >>> > >>> Yes you definitely want to call ReleaseGraphicsResources when you are > >done using a graphics object, but are not done using its window. > >Normally VTK handles this for you so you do not have to worry about it. > >>> > >>> Many classes in VTK create and hold onto OpenGL resources. At some > >point those resources need to be freed. Normally before an OpenGL > >context/window is destroyed it will call ReleaseGraphicsResources on > >everything connected to it so that they are all freed before it releases > >the context. But if you have detached a mapper from the RenderWindow/ > >Renderer/Actor (but not yet deleted it) then that does not happen. Then > >at some other point that mapper tries to free its resources but the > >context that owned them is already gone causing an error. > >>> > >>> Thanks > >>> Ken > >>> > >>> > >>> > >>> On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola >research.com >> wrote: > >>> Hi Ken, > >>> > >>> Thanks for the suggestion. I do have a little question though, is > >it a necessary convention to call release graphics resources on the old > >mapper prior to setting a new one? I was wondering judging from your > >statement (quick fix) if this was just a hack. > >>> > >>> Regards, > >>> Seun > >>>> On Aug 8, 2016, at 1:00 PM, Ken Martin > >>> wrote: > >>>> > >>>> How do you change the mapper? Do you immediately destroy the old > >mapper or leave it around for later? I suspect the old mapper is > >getting destroyed later than it should. One thing you can try as a quick > >fix is > >>>> > >>>> actor->SetMapper(shiny new mapper); > >>>> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have > >the window handy) > >>>> ... > >>>> > >>>> > >>>> > >>>> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola >research.com >> wrote: > >>>> Hello everyone, > >>>> > >>>> I have a crash that occurs in my application when running vtk > >with the GL2 rendered enabled but not with GL1. So here is the > >situation, in my program when I change the shape of my poly data mapper, > >basically setting the mapper of an actor in my scene to a new poly data > >mapper it results in a crash. The crash is situated in > >vtkOpenGLBufferObject?s destructor, specifically the deletion of the > >Internal?s handle. I have tried to verify if the handle is valid prior > >to reaching the destructor which it seems to be, my main concern is if > >the handle is filled with garbage (a non-zero value) it might > >effectively pass the test condition and try to invoke glDeleteBuffer. > >Has anyone experienced anything similar to this? > >>>> > >>>> Regards, > >>>> Seun > > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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: