From akash.basabhat at gmail.com Fri Jan 1 11:32:00 2016 From: akash.basabhat at gmail.com (Akash B) Date: Fri, 1 Jan 2016 22:02:00 +0530 Subject: [vtk-developers] Contributing to Vtk Message-ID: Hi all, I'm interested in contribution to Vtk. I'm comfortable with C++, C++11, Python and Java. I'd like some guidance as to how to contribute to Vtk. Regards, Akash PB -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Sat Jan 2 16:30:27 2016 From: andy.bauer at kitware.com (Andy Bauer) Date: Sat, 2 Jan 2016 16:30:27 -0500 Subject: [vtk-developers] Contributing to Vtk In-Reply-To: References: Message-ID: Hi Akash, Welcome to the VTK community! Is there a specific functionality you're looking to get into VTK? If you describe what you're hoping to do I'm sure you'll get helpful hints on how to do it. If you're just looking to get some experience with VTK I'd suggest starting out with either participating in code reviews (see https://gitlab.kitware.com/vtk/vtk/merge_requests for pending merge requests) or look at fixing a bug or two (some are listed at http://www.paraview.org/Bug/view_all_bug_page.php). There is information at http://www.vtk.org/contributing-code/ on how to contribute to VTK. Feel free to seek out help on the mailing list -- VTK is big enough that no one is an expert in all parts of it but the community is very responsive and certainly someone will know parts of the code that you're looking at. Best regards, Andy On Fri, Jan 1, 2016 at 11:32 AM, Akash B wrote: > Hi all, > I'm interested in contribution to Vtk. I'm comfortable with C++, > C++11, Python and Java. I'd like some guidance as to how to contribute to > Vtk. > > Regards, > Akash PB > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://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 Jan 4 08:12:05 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 4 Jan 2016 08:12:05 -0500 Subject: [vtk-developers] osmesa status In-Reply-To: References: Message-ID: I think I heard that OS Mesa does not currently support MSAA or it is implemented in an odd way for some reason. That could be part of it. Also, unless you are using the recent patches to OS Mesa to support getting a 3.2 context along with a very recent VTK, then OSMesa is really returning an older context, not a 3.2 context. Brian Paul had to make some recent changes in OSMesa to really return a 3.2 context. We have updated VTK to use those changes but I'm pretty sure they will not be in Mesa until version 11.1 or maybe 11.2. Thanks Ken On Wed, Dec 30, 2015 at 10:11 AM, Geoff Wright wrote: > Hi Bill, > > I don't think it is specifically OpenGL2. I have been using OpenGL2 for 6 > months and the test are all passing on OpenGL2 when I'm using a machine > with an Nvidia graphics card. The problem happens when switching to OS > mesa. > > The errors I'm seeing are single pixel or possibly subpixel offsets in the > image generated by OS-mesa vs images generated by a hardware backed > driver. Is this a known issue with OS mesa? I was wondering whether maybe > the tests are running by default with MSAA and its not supported on the OS > mesa back end. > > Anyway I will most likely just add some physical machines in my office as > bamboo agents for the VTK test jobs. > > Thanks, > Geoff > > > > On Tue, Dec 29, 2015 at 3:30 PM Bill Lorensen > wrote: > >> I think the errors are because the Rendering backend is set to OpenGL2 >> (which recently became the default). If you set your rendering backend >> to OpenG you should be OK. >> >> >> On Tue, Dec 29, 2015 at 10:34 AM, Geoff Wright >> wrote: >> > Hello, >> > >> > I'm using VTK in an internal project and wanted to add some extra >> regression >> > tests to support my own use cases. I setup a new job to build VTK and >> run >> > all existing ctest on my CI server (aws ec2 Ubuntu 14.04, no graphics >> > hardware). >> > >> > I noticed that a substantial portion of the tests are currently failing >> when >> > using os mesa, due to what looks like sub pixel alignment issues. Is >> this a >> > known problem? I see that there are a couple of servers on the public >> VTK >> > dashboard configured for OS mesa that are also failing approximately 400 >> > tests e.g. https://open.cdash.org/buildSummary.php?buildid=4167821 >> > >> > I'm wondering if there is any quick fix to get these working, or is it a >> > known issue with osmesa? Are the baseline images generated using >> MSAA? Is >> > there an option to change the image comparison to be more generous with >> > single pixel misalignment? Should I give up on testing VTK in a VM and >> set >> > it up on a physical agent? I would rather avoid this... any advice is >> much >> > appreciated. I'm using Mesa 11.0.4 which reports OpenGL information as >> > follows: >> > >> > OpenGL vendor string: VMware, Inc. >> > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits) >> > OpenGL core profile version string: 3.2 (Core Profile) Mesa 11.0.4 >> > OpenGL core profile shading language version string: 1.50 >> > OpenGL core profile context flags: (none) >> > OpenGL core profile profile mask: core profile >> > OpenGL core profile extensions: >> > OpenGL version string: 3.2 (Core Profile) Mesa 11.0.4 >> > OpenGL shading language version string: 1.50 >> > OpenGL context flags: (none) >> > OpenGL profile mask: core profile >> > OpenGL extensions: >> > >> > Many thanks, >> > >> > Geoff >> > >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://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 gpwright at gmail.com Mon Jan 4 09:36:56 2016 From: gpwright at gmail.com (Geoff Wright) Date: Mon, 04 Jan 2016 14:36:56 +0000 Subject: [vtk-developers] osmesa status In-Reply-To: References: Message-ID: I was using the environment variables MESA_GL_VERSION_OVERRIDE=3.2 and MESA_GLSL_VERSION_OVERRIDE=150, along with latest VTK master. This appears to make os mesa return a 3.2 context but maybe its not sufficient. I'm not sure why a lower context version would cause sub pixel offsets though I would expect that it would just segfault on one of the unimplemented OpenGL calls. It's not a big deal, I will try again later in the year but for now I'm using physical machine. Thanks for the info, Geoff On Mon, Jan 4, 2016 at 8:12 AM Ken Martin wrote: > I think I heard that OS Mesa does not currently support MSAA or it is > implemented in an odd way for some reason. That could be part of it. Also, > unless you are using the recent patches to OS Mesa to support getting a 3.2 > context along with a very recent VTK, then OSMesa is really returning an > older context, not a 3.2 context. Brian Paul had to make some recent > changes in OSMesa to really return a 3.2 context. We have updated VTK to > use those changes but I'm pretty sure they will not be in Mesa until > version 11.1 or maybe 11.2. > > Thanks > Ken > > > > > On Wed, Dec 30, 2015 at 10:11 AM, Geoff Wright wrote: > >> Hi Bill, >> >> I don't think it is specifically OpenGL2. I have been using OpenGL2 for >> 6 months and the test are all passing on OpenGL2 when I'm using a machine >> with an Nvidia graphics card. The problem happens when switching to OS >> mesa. >> >> The errors I'm seeing are single pixel or possibly subpixel offsets in >> the image generated by OS-mesa vs images generated by a hardware backed >> driver. Is this a known issue with OS mesa? I was wondering whether maybe >> the tests are running by default with MSAA and its not supported on the OS >> mesa back end. >> >> Anyway I will most likely just add some physical machines in my office as >> bamboo agents for the VTK test jobs. >> >> Thanks, >> Geoff >> >> >> >> On Tue, Dec 29, 2015 at 3:30 PM Bill Lorensen >> wrote: >> >>> I think the errors are because the Rendering backend is set to OpenGL2 >>> (which recently became the default). If you set your rendering backend >>> to OpenG you should be OK. >>> >>> >>> On Tue, Dec 29, 2015 at 10:34 AM, Geoff Wright >>> wrote: >>> > Hello, >>> > >>> > I'm using VTK in an internal project and wanted to add some extra >>> regression >>> > tests to support my own use cases. I setup a new job to build VTK and >>> run >>> > all existing ctest on my CI server (aws ec2 Ubuntu 14.04, no graphics >>> > hardware). >>> > >>> > I noticed that a substantial portion of the tests are currently >>> failing when >>> > using os mesa, due to what looks like sub pixel alignment issues. Is >>> this a >>> > known problem? I see that there are a couple of servers on the public >>> VTK >>> > dashboard configured for OS mesa that are also failing approximately >>> 400 >>> > tests e.g. https://open.cdash.org/buildSummary.php?buildid=4167821 >>> > >>> > I'm wondering if there is any quick fix to get these working, or is it >>> a >>> > known issue with osmesa? Are the baseline images generated using >>> MSAA? Is >>> > there an option to change the image comparison to be more generous with >>> > single pixel misalignment? Should I give up on testing VTK in a VM >>> and set >>> > it up on a physical agent? I would rather avoid this... any advice is >>> much >>> > appreciated. I'm using Mesa 11.0.4 which reports OpenGL information >>> as >>> > follows: >>> > >>> > OpenGL vendor string: VMware, Inc. >>> > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits) >>> > OpenGL core profile version string: 3.2 (Core Profile) Mesa 11.0.4 >>> > OpenGL core profile shading language version string: 1.50 >>> > OpenGL core profile context flags: (none) >>> > OpenGL core profile profile mask: core profile >>> > OpenGL core profile extensions: >>> > OpenGL version string: 3.2 (Core Profile) Mesa 11.0.4 >>> > OpenGL shading language version string: 1.50 >>> > OpenGL context flags: (none) >>> > OpenGL profile mask: core profile >>> > OpenGL extensions: >>> > >>> > Many thanks, >>> > >>> > Geoff >>> > >>> > >>> > >>> > _______________________________________________ >>> > Powered by www.kitware.com >>> > >>> > Visit other Kitware open-source projects at >>> > http://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 ken.martin at kitware.com Mon Jan 4 11:06:30 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 4 Jan 2016 11:06:30 -0500 Subject: [vtk-developers] [vtkusers] Announce: vtk 7.0.0 release candidate 1 is ready In-Reply-To: References: Message-ID: I was unable to duplicate this. I modified a test to use layers and it seemed to work. Specifically I updated Rendering/OpenGL2/Testing/CXX/TestVBOPLY.cxx to be the following, rebuilts, and then ran it ala .\bin\vtkRenderingOpenGL2CxxTests.exe TestVBOPLYMapper -D "C:/Users/ken.martin/Documents/vtk/vtkbin/ExternalData/Testing" -I and it seemed to work fine. Does that work for you? If so , can you modify the example to show the problem? Thanks Ken #include "vtkCamera.h" #include "vtkRenderer.h" #include "vtkOpenGLRenderWindow.h" #include "vtkActor.h" #include "vtkCellArray.h" #include "vtkPointData.h" #include "vtkPolyDataMapper.h" #include "vtkPLYReader.h" #include "vtkNew.h" #include "vtkProperty.h" #include "vtkLightKit.h" #include "vtkPolyDataNormals.h" #include "vtkTimerLog.h" #include "vtkRegressionTestImage.h" #include "vtkTestUtilities.h" #include "vtkRenderWindowInteractor.h" //---------------------------------------------------------------------------- int TestVBOPLYMapper(int argc, char *argv[]) { vtkNew actor; vtkNew renderer; vtkNew mapper; renderer->SetBackground(0.0, 0.0, 0.0); vtkNew renderWindow; renderWindow->SetSize(300, 300); renderWindow->AddRenderer(renderer.Get()); renderer->AddActor(actor.Get()); vtkNew iren; iren->SetRenderWindow(renderWindow.Get()); vtkNew lightKit; lightKit->AddLightsToRenderer(renderer.Get()); if (!renderWindow->SupportsOpenGL()) { cerr << "The platform does not support OpenGL as required\n"; cerr << vtkOpenGLRenderWindow::SafeDownCast(renderWindow.Get())->GetOpenGLSupportMessage(); cerr << renderWindow->ReportCapabilities(); return 1; } const char* fileName = vtkTestUtilities::ExpandDataFileName(argc, argv, "Data/dragon.ply"); vtkNew reader; reader->SetFileName(fileName); reader->Update(); // vtkNew norms; // norms->SetInputConnection(reader->GetOutputPort()); // norms->Update(); mapper->SetInputConnection(reader->GetOutputPort()); //mapper->SetInputConnection(norms->GetOutputPort()); actor->SetMapper(mapper.Get()); actor->GetProperty()->SetAmbientColor(0.2, 0.2, 1.0); actor->GetProperty()->SetDiffuseColor(1.0, 0.65, 0.7); actor->GetProperty()->SetSpecularColor(1.0, 1.0, 1.0); actor->GetProperty()->SetSpecular(0.5); actor->GetProperty()->SetDiffuse(0.7); actor->GetProperty()->SetAmbient(0.5); actor->GetProperty()->SetSpecularPower(20.0); actor->GetProperty()->SetOpacity(1.0); //actor->GetProperty()->SetRepresentationToWireframe(); vtkNew actor2; vtkNew renderer2; vtkNew mapper2; mapper2->SetInputConnection(reader->GetOutputPort()); actor2->SetMapper(mapper2.Get()); actor2->GetProperty()->SetOpacity(1.0); renderer2->SetLayer(1); renderer2->AddActor(actor2.Get()); renderWindow->SetNumberOfLayers(2); renderWindow->AddRenderer(renderer2.Get()); renderWindow->SetMultiSamples(0); vtkNew timer; timer->StartTimer(); renderWindow->Render(); timer->StopTimer(); double firstRender = timer->GetElapsedTime(); cerr << "first render time: " << firstRender << endl; timer->StartTimer(); int numRenders = 8; for (int i = 0; i < numRenders; ++i) { renderer->GetActiveCamera()->Azimuth(10); renderer->GetActiveCamera()->Elevation(10); renderWindow->Render(); } timer->StopTimer(); double elapsed = timer->GetElapsedTime(); cerr << "interactive render time: " << elapsed / numRenders << endl; unsigned int numTris = reader->GetOutput()->GetPolys()->GetNumberOfCells(); cerr << "number of triangles: " << numTris << endl; cerr << "triangles per second: " << numTris*(numRenders/elapsed) << endl; renderer->GetActiveCamera()->SetPosition(0,0,1); renderer->GetActiveCamera()->SetFocalPoint(0,0,0); renderer->GetActiveCamera()->SetViewUp(0,1,0); renderer->ResetCamera(); renderWindow->Render(); renderWindow->Render(); int retVal = vtkRegressionTestImage( renderWindow.Get() ); if ( retVal == vtkRegressionTester::DO_INTERACTOR) { iren->Start(); } return !retVal; } On Fri, Dec 18, 2015 at 12:31 PM, Michael Redmond < michael.j.redmond at gmail.com> wrote: > I reported a bug issue id 0015892. It's a bug for opengl2. Extra cells > are shown in 2nd/3rd renderer layers. I've seen the bug in 6.3 and > 7.0rc1. I've checked with the official 64 bit python release and my own > 6.3 builds. > On Dec 17, 2015 2:39 PM, "David E DeMarle" > wrote: > >> The VTK developement team is happy to announce that VTK 7.0 has entered >> the release candidate stage! >> >> You can find the source, data, and vtkpython binary packages here: >> >> http://www.vtk.org/download/#candidate >> >> Please try this version of VTK and report any issues to the list or the >> bug tracker so that we can try to address them before VTK 7.0.0 final. >> >> The official release notes will be available when VTK final is released >> in the next few weeks. In the meantime here is a preview: >> >> The big news is that the OpenGL"new" backend is now the default and that >> VTK is for the first time compatible with Python 3. >> >> Other new functionality includes: >> - the introduction of the Flying Edges SMP optimized (very fast) >> isocontour filter >> - a new and improved vtkPUnstructuredGridGhostCells filter that >> efficiently creates ghost cells in DMP parallel contexts. >> - allow the Python Global Interpreter Lock (GIL) for multithreaded Python >> routines >> - offscreen rendering through EGL now supported >> - remove vtkFreeTypeUtilities >> >> Improvements to existing functionality includes: >> - optimizations to the Contingency Statistics class which provides a >> significant performance boost when using only integer or floating point >> data >> - improved MPAS file handling including including arbitrary vertical >> dimensions and more general attribute reading >> - modernize depth sorting code. In tests the improved depth sort is 2 to >> 3x faster than before. >> - fixes to the ExodusWriter, especially when handling side sets and node set >> data. >> - updates to the PLY Writer >> >> Some of the changes that affect building and using VTK in applications >> include: >> - the OpenGL2 backend requires newer rendering capabilities than its >> predecessor >> - QtWebKit is no longer part of the Qt build group and thus easier to do >> without >> - vtkStreamer and related classes are deprecated; use vtkStreamTracer >> instead. >> - a new option (when building with newer CMake) to build with C++11 >> support >> - add support for Visual Studio 2015 >> - Java 1.6 is now the minimum version that is tested; 1.5 may not work >> - remove support for OSX10.5 Leopard and the Carbon (OSX9 compatibility >> layer) API >> - remove support for gcc 4.1 >> >> And many bug fixes across the codebase. >> >> We hope you enjoy this release of VTK! As always, contact Kitware and >> the mailing lists for assistance. >> >> Thanks, >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Search the list archives at: http://markmail.org/search/?q=vtkusers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -- 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 Mon Jan 4 11:08:43 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 4 Jan 2016 11:08:43 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: <56843D74.1070702@aerosoftinc.com> References: <56843D74.1070702@aerosoftinc.com> Message-ID: Hey Bill, The very short (and annoying) answer is that VTK does not currently support varying WHOLE_EXTENT(). However, there are ways of getting around this. But before I get into those, can you describe how/where you change the whole extent? As part of a time update? By setting some data member on the reader? Best, -berk On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory wrote: > I am having difficulty porting some code from VTK 5 to 6. > > I have a custom algorithm for creating a vtkStructuredGrid as the source > for my pipeline, so my class inherits vtkStructuredGridAlgorithm > > my pipeline simply connects the vtkStructuredGridAlgorithm to a > vtkGeometryFilter which is mapped with a vtkPolyDataMapper > > I want my source to correctly render a structured grid which changes > dimensions dynamically within my application. > > My problem is that if I originally set up the grid with say extents of 0 > --99, 0-->99, 0-->99, and then change the extents to 0--49, 0-49,0-49 > through a call to Update, then I get a VTK error message from > > > ERROR: In > VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line > 860 > vtkCompositeDataPipeline (0xb4561f0): The update extent specified in the > information for output port 0 on algorithm SurfaceSNodeSource(0xb455750) is > 0 80 0 32 0 0, which is outside the whole extent 0 40 0 16 0 0. > (This is in VerifyOutputInformation) called before the RequestUpdateExtent > for my algorithm. > > I don't quite understand the propagation of the UPDATE_EXTENT information > up the pipeline, but if I set the UPDATE_EXTENT to WHOLE_EXTENT > > in vtkGeometryFilter::RequestUpdateExtent > > then the error goes away. > Also, at the time of calling vtkGeometryFilter::RequestUpdateExtent, the > UPDATE_EXTENT is still set at the old value, while the WHOLE_EXTENT has > been correctly updated/propagated from upstream. > > Is this a bug, or do I need to change something in my > vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be reset at the > origin downstream? > > Thanks > > Bill > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcgrory at aerosoftinc.com Mon Jan 4 11:39:37 2016 From: mcgrory at aerosoftinc.com (Bill McGrory) Date: Mon, 4 Jan 2016 11:39:37 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: References: <56843D74.1070702@aerosoftinc.com> Message-ID: <568AA049.3080803@aerosoftinc.com> I have a pipeline for displaying structured zones within a GUI. These zone's have multiple grid refinement levels or sequences. The beginning of the pipeline is a source which creates a vtkStructuredGrid. When I interactively change the sequence level the source gets a call to update the pipeline where I need to change the vtkStructuredGrid to represent a different sequence level (so my grid grid dimensions will double or halve, for example) This process worked (by accident perhaps) in versions of VTK prior to 6. Thanks Bill On 01/04/2016 11:08 AM, Berk Geveci wrote: > Hey Bill, > > The very short (and annoying) answer is that VTK does not currently > support varying WHOLE_EXTENT(). > > However, there are ways of getting around this. But before I get into > those, can you describe how/where you change the whole extent? As part > of a time update? By setting some data member on the reader? > > Best, > -berk > > On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory > wrote: > > I am having difficulty porting some code from VTK 5 to 6. > > I have a custom algorithm for creating a vtkStructuredGrid as the > source for my pipeline, so my class inherits > vtkStructuredGridAlgorithm > > my pipeline simply connects the vtkStructuredGridAlgorithm to a > vtkGeometryFilter which is mapped with a vtkPolyDataMapper > > I want my source to correctly render a structured grid which > changes dimensions dynamically within my application. > > My problem is that if I originally set up the grid with say > extents of 0 --99, 0-->99, 0-->99, and then change the extents to > 0--49, 0-49,0-49 through a call to Update, then I get a VTK error > message from > > > ERROR: In > VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, > line 860 > vtkCompositeDataPipeline (0xb4561f0): The update extent specified > in the information for output port 0 on algorithm > SurfaceSNodeSource(0xb455750) is 0 80 0 32 0 0, which is outside > the whole extent 0 40 0 16 0 0. > (This is in VerifyOutputInformation) called before the > RequestUpdateExtent for my algorithm. > > I don't quite understand the propagation of the UPDATE_EXTENT > information up the pipeline, but if I set the UPDATE_EXTENT to > WHOLE_EXTENT > > in vtkGeometryFilter::RequestUpdateExtent > > then the error goes away. > Also, at the time of calling > vtkGeometryFilter::RequestUpdateExtent, the UPDATE_EXTENT is still > set at the old value, while the WHOLE_EXTENT has been correctly > updated/propagated from upstream. > > Is this a bug, or do I need to change something in my > vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be reset > at the origin downstream? > > Thanks > > 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 > > -- Dr. William D. McGrory AeroSoft, Inc. mcgrory at aerosoftinc.com Suite 1400 (540) 557-1904 2000 Kraft Drive (540) 557-1919 (FAX) Blacksburg, VA 24060 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Jan 4 11:46:58 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 4 Jan 2016 11:46:58 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: <568AA049.3080803@aerosoftinc.com> References: <56843D74.1070702@aerosoftinc.com> <568AA049.3080803@aerosoftinc.com> Message-ID: So when the WHOLE_EXTENT() changes, you tell the source/reader by modifying it somehow? What I am trying to get to is whether or not this works: someSource->SetNewData(); someSource->Modified() someFilterDownstream->Update(); someSource->SetNewData(); someSource->Modified() someFilterDownstream->Update(); I believe that as long as the source is modified after the WHOLE_EXTENT() changes, update should work fine. Because this would lead to RequestInformation() being called again, which is what propagates the new WHOLE_EXTENT() downstream. Best, -berk On Mon, Jan 4, 2016 at 11:39 AM, Bill McGrory wrote: > I have a pipeline for displaying structured zones within a GUI. These > zone's have multiple grid refinement levels or sequences. The beginning of > the pipeline is a source which creates a vtkStructuredGrid. > > When I interactively change the sequence level the source gets a call to > update the pipeline where I need to change the vtkStructuredGrid to > represent a different sequence level (so my grid grid dimensions will > double or halve, for example) > > This process worked (by accident perhaps) in versions of VTK prior to 6. > > Thanks > Bill > > > > On 01/04/2016 11:08 AM, Berk Geveci wrote: > > Hey Bill, > > The very short (and annoying) answer is that VTK does not currently > support varying WHOLE_EXTENT(). > > However, there are ways of getting around this. But before I get into > those, can you describe how/where you change the whole extent? As part of a > time update? By setting some data member on the reader? > > Best, > -berk > > On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory > wrote: > >> I am having difficulty porting some code from VTK 5 to 6. >> >> I have a custom algorithm for creating a vtkStructuredGrid as the source >> for my pipeline, so my class inherits vtkStructuredGridAlgorithm >> >> my pipeline simply connects the vtkStructuredGridAlgorithm to a >> vtkGeometryFilter which is mapped with a vtkPolyDataMapper >> >> I want my source to correctly render a structured grid which changes >> dimensions dynamically within my application. >> >> My problem is that if I originally set up the grid with say extents of 0 >> --99, 0-->99, 0-->99, and then change the extents to 0--49, 0-49,0-49 >> through a call to Update, then I get a VTK error message from >> >> >> ERROR: In >> VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line >> 860 >> vtkCompositeDataPipeline (0xb4561f0): The update extent specified in the >> information for output port 0 on algorithm SurfaceSNodeSource(0xb455750) is >> 0 80 0 32 0 0, which is outside the whole extent 0 40 0 16 0 0. >> (This is in VerifyOutputInformation) called before the >> RequestUpdateExtent for my algorithm. >> >> I don't quite understand the propagation of the UPDATE_EXTENT information >> up the pipeline, but if I set the UPDATE_EXTENT to WHOLE_EXTENT >> >> in vtkGeometryFilter::RequestUpdateExtent >> >> then the error goes away. >> Also, at the time of calling vtkGeometryFilter::RequestUpdateExtent, the >> UPDATE_EXTENT is still set at the old value, while the WHOLE_EXTENT has >> been correctly updated/propagated from upstream. >> >> Is this a bug, or do I need to change something in my >> vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be reset at the >> origin downstream? >> >> Thanks >> >> 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 >> >> > > -- > Dr. William D. McGrory AeroSoft, Inc.mcgrory at aerosoftinc.com Suite 1400(540) 557-1904 2000 Kraft Drive(540) 557-1919 (FAX) Blacksburg, VA 24060 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcgrory at aerosoftinc.com Mon Jan 4 12:25:12 2016 From: mcgrory at aerosoftinc.com (Bill McGrory) Date: Mon, 4 Jan 2016 12:25:12 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: References: <56843D74.1070702@aerosoftinc.com> <568AA049.3080803@aerosoftinc.com> Message-ID: <568AAAF8.8000800@aerosoftinc.com> I think I am doing what you say should work. My personal data outside of VTK changes as a result of a user requested change from say the fine representation to the coarse. That change triggers a someSource->Modified(). that seems to correctly trigger a call to RequestInformation on someSource, which is when I modify WHOLE_EXTENT(). What I see is that WHOLE_EXTENT correctly propagates downstream, however, there is no change to the UPDATE_EXTENT as a result of the WHOLE_EXTENT being reduced. So when RequestUpdateExtent propagates back upstream, I get the error for it being out of range, with the WHOLE_EXTENT value being the new correct value. and UPDATE_EXTENT being the old value. Note my error is triggered at someSource->RequestUpdateExtent() Note the someFilterDownstream is a vtkGeometryFilter, and if I make a call to correct the UPDATE_EXTENT in the geometry filter to be in range WHOLE_EXTENT from vtkGeometryFilter::RequestUpdateExtent() then that fixes my bug, but this is only for vtkGeometryFilter, not a generic downstream filter. On 01/04/2016 11:46 AM, Berk Geveci wrote: > So when the WHOLE_EXTENT() changes, you tell the source/reader by > modifying it somehow? What I am trying to get to is whether or not > this works: > > someSource->SetNewData(); > someSource->Modified() > someFilterDownstream->Update(); > > someSource->SetNewData(); > someSource->Modified() > someFilterDownstream->Update(); > > I believe that as long as the source is modified after the > WHOLE_EXTENT() changes, update should work fine. Because this would > lead to RequestInformation() being called again, which is what > propagates the new WHOLE_EXTENT() downstream. > > Best, > -berk > > On Mon, Jan 4, 2016 at 11:39 AM, Bill McGrory > wrote: > > I have a pipeline for displaying structured zones within a GUI. > These zone's have multiple grid refinement levels or sequences. > The beginning of the pipeline is a source which creates a > vtkStructuredGrid. > > When I interactively change the sequence level the source gets a > call to update the pipeline where I need to change the > vtkStructuredGrid to represent a different sequence level (so my > grid grid dimensions will double or halve, for example) > > This process worked (by accident perhaps) in versions of VTK prior > to 6. > > Thanks > Bill > > > > On 01/04/2016 11:08 AM, Berk Geveci wrote: >> Hey Bill, >> >> The very short (and annoying) answer is that VTK does not >> currently support varying WHOLE_EXTENT(). >> >> However, there are ways of getting around this. But before I get >> into those, can you describe how/where you change the whole >> extent? As part of a time update? By setting some data member on >> the reader? >> >> Best, >> -berk >> >> On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory >> > wrote: >> >> I am having difficulty porting some code from VTK 5 to 6. >> >> I have a custom algorithm for creating a vtkStructuredGrid >> as the source for my pipeline, so my class inherits >> vtkStructuredGridAlgorithm >> >> my pipeline simply connects the vtkStructuredGridAlgorithm to >> a vtkGeometryFilter which is mapped with a vtkPolyDataMapper >> >> I want my source to correctly render a structured grid which >> changes dimensions dynamically within my application. >> >> My problem is that if I originally set up the grid with say >> extents of 0 --99, 0-->99, 0-->99, and then change the >> extents to 0--49, 0-49,0-49 through a call to Update, then I >> get a VTK error message from >> >> >> ERROR: In >> VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, >> line 860 >> vtkCompositeDataPipeline (0xb4561f0): The update extent >> specified in the information for output port 0 on algorithm >> SurfaceSNodeSource(0xb455750) is 0 80 0 32 0 0, which is >> outside the whole extent 0 40 0 16 0 0. >> (This is in VerifyOutputInformation) called before the >> RequestUpdateExtent for my algorithm. >> >> I don't quite understand the propagation of the UPDATE_EXTENT >> information up the pipeline, but if I set the UPDATE_EXTENT >> to WHOLE_EXTENT >> >> in vtkGeometryFilter::RequestUpdateExtent >> >> then the error goes away. >> Also, at the time of calling >> vtkGeometryFilter::RequestUpdateExtent, the UPDATE_EXTENT is >> still set at the old value, while the WHOLE_EXTENT has been >> correctly updated/propagated from upstream. >> >> Is this a bug, or do I need to change something in my >> vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be >> reset at the origin downstream? >> >> Thanks >> >> 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 >> >> > > -- > Dr. William D. McGrory AeroSoft, Inc. > mcgrory at aerosoftinc.com Suite 1400 > (540) 557-1904 2000 Kraft Drive > (540) 557-1919 (FAX) Blacksburg, VA 24060 > > -- Dr. William D. McGrory AeroSoft, Inc. mcgrory at aerosoftinc.com Suite 1400 (540) 557-1904 2000 Kraft Drive (540) 557-1919 (FAX) Blacksburg, VA 24060 -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Jan 4 12:57:39 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 4 Jan 2016 12:57:39 -0500 Subject: [vtk-developers] vtkSortDataArray Message-ID: A quick note on a potentially powerful but likely overlooked capability relative to sorting data in VTK. This is available from a recent merge. vtkSortDataArray has been revamped, a lot of what you'd expect: removed a static variable so it's thread-safe, significant code cleanup; new tests; uses std::sort instead of older C-based homegrown stuff; uses vtkSMPTools::Sort(), so when the build is configured appropriately you'll see faster performance, etc. The interesting bit is that sorting has been broken out into separate steps. An initial sort creates a permutation / sort index of vtkIdType that indicates where the data ends up (after the sort). This sorting index can then be used to shuffle any associated data around, or the sort index can be queried to perform additional analysis on the data. Practically this means you can use any component of a tuple in a data array to generate a sort index. So for example, if you want to find the top N points with lowest/greatest scalar value; or the cells with largest z-velocity component; etc. it is quite easy to do. Look at Common/Core/Testing/Cxx/TestSortDataArray.cxx. I also thought about creating an extraction filter to sort, extract, and/or reorder cells/points based on data value; this is down on my todo list.... There is also a new, related class vtkSortFieldData that enables you to simultaneously sort all the arrays contained in subclasses of vtkFieldData (e.g., vtkPointData and vtkCellData). Have fun and as always let me know if there are issues, concerns, or improvements to be made. Best, W -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Jan 4 15:11:44 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 4 Jan 2016 15:11:44 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: <568AAAF8.8000800@aerosoftinc.com> References: <56843D74.1070702@aerosoftinc.com> <568AA049.3080803@aerosoftinc.com> <568AAAF8.8000800@aerosoftinc.com> Message-ID: OK this sounds like a bug. Is your pipeline only source -> vtkGeometryFilter or is there something in between? I'll try to reproduce this with a Python source once I know what the pipeline is. Best, -berk On Mon, Jan 4, 2016 at 12:25 PM, Bill McGrory wrote: > I think I am doing what you say should work. > > My personal data outside of VTK changes as a result of a user requested > change from say the fine representation to the coarse. That change triggers > a someSource->Modified(). that seems to correctly trigger a call to > RequestInformation on someSource, which is when I modify WHOLE_EXTENT(). > > What I see is that WHOLE_EXTENT correctly propagates downstream, however, > there is no change to the UPDATE_EXTENT as a result of the WHOLE_EXTENT > being reduced. So when RequestUpdateExtent propagates back upstream, I get > the error for it being out of range, with the WHOLE_EXTENT value being the > new correct value. and UPDATE_EXTENT being the old value. > > Note my error is triggered at someSource->RequestUpdateExtent() > > Note the someFilterDownstream is a vtkGeometryFilter, and if I make a call > to correct the UPDATE_EXTENT in the geometry filter to be in range > WHOLE_EXTENT from vtkGeometryFilter::RequestUpdateExtent() then that fixes > my bug, but this is only for vtkGeometryFilter, not a generic downstream > filter. > > > > > > > On 01/04/2016 11:46 AM, Berk Geveci wrote: > > So when the WHOLE_EXTENT() changes, you tell the source/reader by > modifying it somehow? What I am trying to get to is whether or not this > works: > > someSource->SetNewData(); > someSource->Modified() > someFilterDownstream->Update(); > > someSource->SetNewData(); > someSource->Modified() > someFilterDownstream->Update(); > > I believe that as long as the source is modified after the WHOLE_EXTENT() > changes, update should work fine. Because this would lead to > RequestInformation() being called again, which is what propagates the new > WHOLE_EXTENT() downstream. > > Best, > -berk > > On Mon, Jan 4, 2016 at 11:39 AM, Bill McGrory > wrote: > >> I have a pipeline for displaying structured zones within a GUI. These >> zone's have multiple grid refinement levels or sequences. The beginning of >> the pipeline is a source which creates a vtkStructuredGrid. >> >> When I interactively change the sequence level the source gets a call to >> update the pipeline where I need to change the vtkStructuredGrid to >> represent a different sequence level (so my grid grid dimensions will >> double or halve, for example) >> >> This process worked (by accident perhaps) in versions of VTK prior to 6. >> >> Thanks >> Bill >> >> >> >> On 01/04/2016 11:08 AM, Berk Geveci wrote: >> >> Hey Bill, >> >> The very short (and annoying) answer is that VTK does not currently >> support varying WHOLE_EXTENT(). >> >> However, there are ways of getting around this. But before I get into >> those, can you describe how/where you change the whole extent? As part of a >> time update? By setting some data member on the reader? >> >> Best, >> -berk >> >> On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory < >> mcgrory at aerosoftinc.com> wrote: >> >>> I am having difficulty porting some code from VTK 5 to 6. >>> >>> I have a custom algorithm for creating a vtkStructuredGrid as the >>> source for my pipeline, so my class inherits vtkStructuredGridAlgorithm >>> >>> my pipeline simply connects the vtkStructuredGridAlgorithm to a >>> vtkGeometryFilter which is mapped with a vtkPolyDataMapper >>> >>> I want my source to correctly render a structured grid which changes >>> dimensions dynamically within my application. >>> >>> My problem is that if I originally set up the grid with say extents of >>> 0 --99, 0-->99, 0-->99, and then change the extents to 0--49, 0-49,0-49 >>> through a call to Update, then I get a VTK error message from >>> >>> >>> ERROR: In >>> VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line >>> 860 >>> vtkCompositeDataPipeline (0xb4561f0): The update extent specified in the >>> information for output port 0 on algorithm SurfaceSNodeSource(0xb455750) is >>> 0 80 0 32 0 0, which is outside the whole extent 0 40 0 16 0 0. >>> (This is in VerifyOutputInformation) called before the >>> RequestUpdateExtent for my algorithm. >>> >>> I don't quite understand the propagation of the UPDATE_EXTENT >>> information up the pipeline, but if I set the UPDATE_EXTENT to WHOLE_EXTENT >>> >>> in vtkGeometryFilter::RequestUpdateExtent >>> >>> then the error goes away. >>> Also, at the time of calling vtkGeometryFilter::RequestUpdateExtent, the >>> UPDATE_EXTENT is still set at the old value, while the WHOLE_EXTENT has >>> been correctly updated/propagated from upstream. >>> >>> Is this a bug, or do I need to change something in my >>> vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be reset at the >>> origin downstream? >>> >>> Thanks >>> >>> 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 >>> >>> >> >> -- >> Dr. William D. McGrory AeroSoft, Inc.mcgrory at aerosoftinc.com Suite 1400(540) 557-1904 2000 Kraft Drive(540) 557-1919 (FAX) Blacksburg, VA 24060 >> >> > > -- > Dr. William D. McGrory AeroSoft, Inc.mcgrory at aerosoftinc.com Suite 1400(540) 557-1904 2000 Kraft Drive(540) 557-1919 (FAX) Blacksburg, VA 24060 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcgrory at aerosoftinc.com Mon Jan 4 15:20:19 2016 From: mcgrory at aerosoftinc.com (Bill McGrory) Date: Mon, 4 Jan 2016 15:20:19 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: References: <56843D74.1070702@aerosoftinc.com> <568AA049.3080803@aerosoftinc.com> <568AAAF8.8000800@aerosoftinc.com> Message-ID: <568AD403.7080208@aerosoftinc.com> yes, vtkGeometryFilter goes straight to a vtkPolyDataMapper If that fails, I will try to strip my code down to something more manageable and get it to you. Thank you On 01/04/2016 03:11 PM, Berk Geveci wrote: > OK this sounds like a bug. Is your pipeline only source -> > vtkGeometryFilter or is there something in between? I'll try to > reproduce this with a Python source once I know what the pipeline is. > > Best, > -berk > > On Mon, Jan 4, 2016 at 12:25 PM, Bill McGrory > wrote: > > I think I am doing what you say should work. > > My personal data outside of VTK changes as a result of a user > requested change from say the fine representation to the coarse. > That change triggers a someSource->Modified(). that seems to > correctly trigger a call to RequestInformation on someSource, > which is when I modify WHOLE_EXTENT(). > > What I see is that WHOLE_EXTENT correctly propagates downstream, > however, there is no change to the UPDATE_EXTENT as a result of > the WHOLE_EXTENT being reduced. So when RequestUpdateExtent > propagates back upstream, I get the error for it being out of > range, with the WHOLE_EXTENT value being the new correct value. > and UPDATE_EXTENT being the old value. > > Note my error is triggered at someSource->RequestUpdateExtent() > > Note the someFilterDownstream is a vtkGeometryFilter, and if I > make a call to correct the UPDATE_EXTENT in the geometry filter to > be in range WHOLE_EXTENT from > vtkGeometryFilter::RequestUpdateExtent() then that fixes my bug, > but this is only for vtkGeometryFilter, not a generic downstream > filter. > > > > > > > On 01/04/2016 11:46 AM, Berk Geveci wrote: >> So when the WHOLE_EXTENT() changes, you tell the source/reader by >> modifying it somehow? What I am trying to get to is whether or >> not this works: >> >> someSource->SetNewData(); >> someSource->Modified() >> someFilterDownstream->Update(); >> >> someSource->SetNewData(); >> someSource->Modified() >> someFilterDownstream->Update(); >> >> I believe that as long as the source is modified after the >> WHOLE_EXTENT() changes, update should work fine. Because this >> would lead to RequestInformation() being called again, which is >> what propagates the new WHOLE_EXTENT() downstream. >> >> Best, >> -berk >> >> On Mon, Jan 4, 2016 at 11:39 AM, Bill McGrory >> > wrote: >> >> I have a pipeline for displaying structured zones within a >> GUI. These zone's have multiple grid refinement levels or >> sequences. The beginning of the pipeline is a source which >> creates a vtkStructuredGrid. >> >> When I interactively change the sequence level the source >> gets a call to update the pipeline where I need to change the >> vtkStructuredGrid to represent a different sequence level (so >> my grid grid dimensions will double or halve, for example) >> >> This process worked (by accident perhaps) in versions of VTK >> prior to 6. >> >> Thanks >> Bill >> >> >> >> On 01/04/2016 11:08 AM, Berk Geveci wrote: >>> Hey Bill, >>> >>> The very short (and annoying) answer is that VTK does not >>> currently support varying WHOLE_EXTENT(). >>> >>> However, there are ways of getting around this. But before I >>> get into those, can you describe how/where you change the >>> whole extent? As part of a time update? By setting some data >>> member on the reader? >>> >>> Best, >>> -berk >>> >>> On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory >>> > >>> wrote: >>> >>> I am having difficulty porting some code from VTK 5 to 6. >>> >>> I have a custom algorithm for creating a >>> vtkStructuredGrid as the source for my pipeline, so my >>> class inherits vtkStructuredGridAlgorithm >>> >>> my pipeline simply connects the >>> vtkStructuredGridAlgorithm to a vtkGeometryFilter which >>> is mapped with a vtkPolyDataMapper >>> >>> I want my source to correctly render a structured grid >>> which changes dimensions dynamically within my application. >>> >>> My problem is that if I originally set up the grid with >>> say extents of 0 --99, 0-->99, 0-->99, and then change >>> the extents to 0--49, 0-49,0-49 through a call to >>> Update, then I get a VTK error message from >>> >>> >>> ERROR: In >>> VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, >>> line 860 >>> vtkCompositeDataPipeline (0xb4561f0): The update extent >>> specified in the information for output port 0 on >>> algorithm SurfaceSNodeSource(0xb455750) is 0 80 0 32 0 >>> 0, which is outside the whole extent 0 40 0 16 0 0. >>> (This is in VerifyOutputInformation) called before the >>> RequestUpdateExtent for my algorithm. >>> >>> I don't quite understand the propagation of the >>> UPDATE_EXTENT information up the pipeline, but if I set >>> the UPDATE_EXTENT to WHOLE_EXTENT >>> >>> in vtkGeometryFilter::RequestUpdateExtent >>> >>> then the error goes away. >>> Also, at the time of calling >>> vtkGeometryFilter::RequestUpdateExtent, the >>> UPDATE_EXTENT is still set at the old value, while the >>> WHOLE_EXTENT has been correctly updated/propagated from >>> upstream. >>> >>> Is this a bug, or do I need to change something in my >>> vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to >>> be reset at the origin downstream? >>> >>> Thanks >>> >>> 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 >>> >>> >> >> -- >> Dr. William D. McGrory AeroSoft, Inc. >> mcgrory at aerosoftinc.com Suite 1400 >> (540) 557-1904 2000 Kraft Drive >> (540) 557-1919 (FAX) Blacksburg, VA 24060 >> >> > > -- > Dr. William D. McGrory AeroSoft, Inc. > mcgrory at aerosoftinc.com Suite 1400 > (540) 557-1904 2000 Kraft Drive > (540) 557-1919 (FAX) Blacksburg, VA 24060 > > -- Dr. William D. McGrory AeroSoft, Inc. mcgrory at aerosoftinc.com Suite 1400 (540) 557-1904 2000 Kraft Drive (540) 557-1919 (FAX) Blacksburg, VA 24060 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Jan 4 15:25:57 2016 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 5 Jan 2016 07:25:57 +1100 Subject: [vtk-developers] vtkSortDataArray (Will Schroeder) Message-ID: +1 This is going to be so useful. It's great to see the older code being modernised. Andrew On Tue, Jan 5, 2016 at 7:12 AM, wrote: > ---------- Forwarded message ---------- > From: Will Schroeder > To: vtk-developers > Cc: > Date: Mon, 4 Jan 2016 12:57:39 -0500 > Subject: [vtk-developers] vtkSortDataArray > A quick note on a potentially powerful but likely overlooked capability > relative to sorting data in VTK. This is available from a recent merge. > > vtkSortDataArray has been revamped, a lot of what you'd expect: removed a > static variable so it's thread-safe, significant code cleanup; new tests; > uses std::sort instead of older C-based homegrown stuff; uses > vtkSMPTools::Sort(), so when the build is configured appropriately you'll > see faster performance, etc. > > The interesting bit is that sorting has been broken out into separate > steps. An initial sort creates a permutation / sort index of vtkIdType that > indicates where the data ends up (after the sort). This sorting index can > then be used to shuffle any associated data around, or the sort index can > be queried to perform additional analysis on the data. > > Practically this means you can use any component of a tuple in a data > array to generate a sort index. So for example, if you want to find the top > N points with lowest/greatest scalar value; or the cells with largest > z-velocity component; etc. it is quite easy to do. Look at > Common/Core/Testing/Cxx/TestSortDataArray.cxx. I also thought about > creating an extraction filter to sort, extract, and/or reorder cells/points > based on data value; this is down on my todo list.... > > There is also a new, related class vtkSortFieldData that enables you to > simultaneously sort all the arrays contained in subclasses of vtkFieldData > (e.g., vtkPointData and vtkCellData). > > Have fun and as always let me know if there are issues, concerns, or > improvements to be made. > > Best, > W > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbsk at ohio.edu Tue Jan 5 11:04:54 2016 From: hobbsk at ohio.edu (Kevin H. Hobbs) Date: Tue, 5 Jan 2016 11:04:54 -0500 Subject: [vtk-developers] Retire expected builds Message-ID: <568BE9A6.4020303@ohio.edu> I'm moving to a new job, and will no longer be able to maintain my nightly builds (even in their neglected state.) Please expect the expected builds from bubbles, murron, and k450e to dissapear. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: OpenPGP digital signature URL: From tim.thirion at kitware.com Tue Jan 5 11:51:45 2016 From: tim.thirion at kitware.com (Tim Thirion) Date: Tue, 5 Jan 2016 11:51:45 -0500 Subject: [vtk-developers] Adding vtkWidgets to android project In-Reply-To: <418DED6D-3A0C-4272-832B-BD2C9D8C1508@gmail.com> References: <1450198514422-5735527.post@n5.nabble.com> <1450349239982-5735564.post@n5.nabble.com> <1450812856819-5735636.post@n5.nabble.com> <418DED6D-3A0C-4272-832B-BD2C9D8C1508@gmail.com> Message-ID: Hey Lonni, Happy New Year! In /CMake there is vtkAndroid.cmake. This file controls the overall config for building VTK for Android. Starting around line 100 (I'm looking at today's VTK master) you'll see a bunch of CMake flags set via a macro. These include the enabled modules as well. Like the line "-DModule_vtkInteractionStyle:BOOL=ON" you can add "-DModule_vtkInteractionWidgets:BOOL=ON" right below that to enable it. The high-level CMake config that you run only really sets things like the Android API level, NDK, etc. If you want to add/remove modules you need to edit vtkAndroid.cmake. Make sense? (Not pretty, I know but it works for now.) TT On Tue, Dec 22, 2015 at 3:16 PM, Lonni Besan?on wrote: > Alright thanks a lot Tim. > > Wishing you some rest during these holidays anyway :) > > > *Best / Cordialement,* > > > *Lonni Besan?on* > *PhD Student with the *AVIZ * team at Inria and with > the *HAPCO > * team at Limsi/CNRS* > *Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud* > *Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041* > > *Email: [hidden email] > * > > *Phone: target="_blank" style="color: rgb(17, 85, 204);" class="">+33689902815 > <%2B33689902815>* > WebPage: http://lonni.besancon.pagesperso-orange.fr > *LinkedIn: *fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > > > > > > > > > On 22 Dec 2015, at 20:43, Tim Thirion [via VTK] <[hidden email] > > wrote: > > Hey Lonni, > > I'm hoping to investigate this in the coming week once things quiet down > for the holidays. Will let you know what I find. > > TT > > On Tue, Dec 22, 2015 at 2:34 PM, Lonni Besan?on < href="x-msg://4/user/SendEmail.jtp?type=node&node=5735637&i=0" > target="_top" rel="nofollow" link="external" class="">[hidden email]> > wrote: > >> Still stuck there, any info? >> >> >> >> -- >> View this message in context: >> http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735636.html >> Sent from the VTK - Dev mailing list archive at Nabble.com >> . >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://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 > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735637.html > To unsubscribe from Adding vtkWidgets to android project, click here. > NAML > > > > > ------------------------------ > View this message in context: Re: Adding vtkWidgets to android project > > > Sent from the VTK - Dev mailing list archive > at Nabble.com. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Jan 6 11:41:26 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 6 Jan 2016 09:41:26 -0700 (MST) Subject: [vtk-developers] Adding vtkWidgets to android project In-Reply-To: References: <1450198514422-5735527.post@n5.nabble.com> <1450349239982-5735564.post@n5.nabble.com> <1450812856819-5735636.post@n5.nabble.com> <418DED6D-3A0C-4272-832B-BD2C9D8C1508@gmail.com> Message-ID: <0B5CA0C0-2D17-499D-9BDB-7A566C9709D5@gmail.com> Hello Tim Happy New Year to you as well. Wishing all the best for 2016! Thanks for the tip, I will try that tomorrow morning (I?m on a laptop without VTK for now, will get back to my lab tomorrow). Is there a way to get a list of all the modules available? I know a bunch of them now, but unsure about the case or things like that. And don?t worry about the solution being pretty, as long as it works, it is more than fine by me. Before the holidays I was actually looking into something similar, this kind of workaround is definitely fine for me. Have a very nice day. I?ll get back to you tomorrow then. Best / Cordialement, Lonni Besan?on PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 Email: lonni.besancon at gmail.com Phone: +33689902815 WebPage: http://lonni.besancon.pagesperso-orange.fr LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > On 05 Jan 2016, at 17:52, Tim Thirion [via VTK] wrote: > > Hey Lonni, > > Happy New Year! > > In /CMake there is vtkAndroid.cmake. This file controls the overall config for building VTK for Android. Starting around line 100 (I'm looking at today's VTK master) you'll see a bunch of CMake flags set via a macro. These include the enabled modules as well. > > Like the line "-DModule_vtkInteractionStyle:BOOL=ON" you can add "-DModule_vtkInteractionWidgets:BOOL=ON" right below that to enable it. > > The high-level CMake config that you run only really sets things like the Android API level, NDK, etc. If you want to add/remove modules you need to edit vtkAndroid.cmake. Make sense? (Not pretty, I know but it works for now.) > > TT > > On Tue, Dec 22, 2015 at 3:16 PM, Lonni Besan?on <[hidden email] > wrote: > Alright thanks a lot Tim. > > Wishing you some rest during these holidays anyway :) > > Best / Cordialement, > > Lonni Besan?on > PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS > Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud > Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 > Email: [hidden email] > Phone: " value="+33689902815" target="_blank">+33689902815" target="_blank" style="color: rgb(17, 85, 204);" class="">+33689902815 > WebPage: http://lonni.besancon.pagesperso-orange.fr > LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > > > > > > > >> On 22 Dec 2015, at 20:43, Tim Thirion [via VTK] <[hidden email] > wrote: >> >> Hey Lonni, >> >> I'm hoping to investigate this in the coming week once things quiet down for the holidays. Will let you know what I find. >> >> TT >> >> On Tue, Dec 22, 2015 at 2:34 PM, Lonni Besan?on <[hidden email]> wrote: >> Still stuck there, any info? >> >> >> >> -- >> View this message in context: http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735636.html >> Sent from the VTK - Dev mailing list archive at Nabble.com . >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://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 >> >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735637.html >> To unsubscribe from Adding vtkWidgets to android project, click here <>. >> NAML > > View this message in context: Re: Adding vtkWidgets to android project > > Sent from the VTK - Dev mailing list archive at Nabble.com . > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://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 > > > > If you reply to this email, your message will be added to the discussion below: > http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735791.html > To unsubscribe from Adding vtkWidgets to android project, click here . > NAML -- View this message in context: http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735820.html Sent from the VTK - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Thu Jan 7 08:47:09 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 7 Jan 2016 06:47:09 -0700 (MST) Subject: [vtk-developers] Adding vtkWidgets to android project In-Reply-To: References: <1450198514422-5735527.post@n5.nabble.com> <1450349239982-5735564.post@n5.nabble.com> <1450812856819-5735636.post@n5.nabble.com> <418DED6D-3A0C-4272-832B-BD2C9D8C1508@gmail.com> Message-ID: <0E297267-5F72-4914-8BC1-81194EFDB5A2@gmail.com> Works like a charm. Thanks Best / Cordialement, Lonni Besan?on PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 Email: lonni.besancon at gmail.com Phone: +33689902815 WebPage: http://lonni.besancon.pagesperso-orange.fr LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > On 06 Jan 2016, at 17:41, Lonni Besan?on wrote: > > Hello Tim > > Happy New Year to you as well. Wishing all the best for 2016! > > Thanks for the tip, I will try that tomorrow morning (I?m on a laptop without VTK for now, will get back to my lab tomorrow). > Is there a way to get a list of all the modules available? I know a bunch of them now, but unsure about the case or things like that. > > And don?t worry about the solution being pretty, as long as it works, it is more than fine by me. > Before the holidays I was actually looking into something similar, this kind of workaround is definitely fine for me. > > Have a very nice day. > > I?ll get back to you tomorrow then. > > Best / Cordialement, > > Lonni Besan?on > PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS > Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud > Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 > Email: lonni.besancon at gmail.com > Phone: +33689902815 > WebPage: http://lonni.besancon.pagesperso-orange.fr > LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > > > > > > > >> On 05 Jan 2016, at 17:52, Tim Thirion [via VTK] > wrote: >> >> Hey Lonni, >> >> Happy New Year! >> >> In /CMake there is vtkAndroid.cmake. This file controls the overall config for building VTK for Android. Starting around line 100 (I'm looking at today's VTK master) you'll see a bunch of CMake flags set via a macro. These include the enabled modules as well. >> >> Like the line "-DModule_vtkInteractionStyle:BOOL=ON" you can add "-DModule_vtkInteractionWidgets:BOOL=ON" right below that to enable it. >> >> The high-level CMake config that you run only really sets things like the Android API level, NDK, etc. If you want to add/remove modules you need to edit vtkAndroid.cmake. Make sense? (Not pretty, I know but it works for now.) >> >> TT >> >> On Tue, Dec 22, 2015 at 3:16 PM, Lonni Besan?on <[hidden email] > wrote: >> Alright thanks a lot Tim. >> >> Wishing you some rest during these holidays anyway :) >> >> Best / Cordialement, >> >> Lonni Besan?on >> PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS >> Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud >> Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 >> Email: [hidden email] >> Phone: " value="+33689902815" target="_blank">+33689902815" target="_blank" style="color: rgb(17, 85, 204);" class="">+33689902815 >> WebPage: http://lonni.besancon.pagesperso-orange.fr >> LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en >> >> >> >> >> >> >> >>> On 22 Dec 2015, at 20:43, Tim Thirion [via VTK] <[hidden email] > wrote: >>> >>> Hey Lonni, >>> >>> I'm hoping to investigate this in the coming week once things quiet down for the holidays. Will let you know what I find. >>> >>> TT >>> >>> On Tue, Dec 22, 2015 at 2:34 PM, Lonni Besan?on <[hidden email]> wrote: >>> Still stuck there, any info? >>> >>> >>> >>> -- >>> View this message in context: http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735636.html >>> Sent from the VTK - Dev mailing list archive at Nabble.com . >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at http://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 >>> >>> >>> >>> If you reply to this email, your message will be added to the discussion below: >>> http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735637.html >>> To unsubscribe from Adding vtkWidgets to android project, click here <>. >>> NAML >> >> View this message in context: Re: Adding vtkWidgets to android project >> >> Sent from the VTK - Dev mailing list archive at Nabble.com . >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://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 >> >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735791.html >> To unsubscribe from Adding vtkWidgets to android project, click here . >> NAML -- View this message in context: http://vtk.1045678.n5.nabble.com/Adding-vtkWidgets-to-android-project-tp5735527p5735842.html Sent from the VTK - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennisnguy at yahoo.com Thu Jan 7 18:08:36 2016 From: dennisnguy at yahoo.com (dieutan) Date: Thu, 7 Jan 2016 16:08:36 -0700 (MST) Subject: [vtk-developers] void vtkCamera::SetPosition crashed Message-ID: <1452208116821-5735862.post@n5.nabble.com> Hi Everyone, My application crashed when calling vtkCamera::SetPosition Here is some of my code: float cpos[3]; vtkRenderer *ren1; ren1 = vtkRenderer::New(); vtkCamera *cam1 = ren1->GetActiveCamera(); cam1->GetPosition(reinterpret_cast(cpos)); cam1->SetPosition(0.000000,0.000000,7.453844); Here is the error message: Unhandled exception at 0x019661e1 in Sersim.exe: 0xC0000005: Access violation reading location 0x00000050. I'm using w1ndows 7, visual studio 2010, VTK version 5.10.1. Please advice to fix the issue. Thanks in advance, Dennis -- View this message in context: http://vtk.1045678.n5.nabble.com/void-vtkCamera-SetPosition-crashed-tp5735862.html Sent from the VTK - Dev mailing list archive at Nabble.com. From joachim.pouderoux at kitware.com Thu Jan 7 18:56:41 2016 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 8 Jan 2016 00:56:41 +0100 Subject: [vtk-developers] void vtkCamera::SetPosition crashed In-Reply-To: <1452208116821-5735862.post@n5.nabble.com> References: <1452208116821-5735862.post@n5.nabble.com> Message-ID: Dennis, GetPosition() writes 3 double at the provided pointer. Here you pass it a pointer sized for 3 floats (2 times smaller), so it crashes (you misunderstand the meaning of reinterpret_cast). Declare cpos as a double array instead of a float array and it will work (double cpos[3];). Best, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2016-01-08 0:08 GMT+01:00 dieutan via vtk-developers : > Hi Everyone, > > My application crashed when calling vtkCamera::SetPosition > > Here is some of my code: > float cpos[3]; > vtkRenderer *ren1; > ren1 = vtkRenderer::New(); > vtkCamera *cam1 = ren1->GetActiveCamera(); > > cam1->GetPosition(reinterpret_cast(cpos)); > cam1->SetPosition(0.000000,0.000000,7.453844); > > Here is the error message: > Unhandled exception at 0x019661e1 in Sersim.exe: 0xC0000005: Access > violation reading location 0x00000050. > > I'm using w1ndows 7, visual studio 2010, VTK version 5.10.1. > > Please advice to fix the issue. > > Thanks in advance, > Dennis > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/void-vtkCamera-SetPosition-crashed-tp5735862.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Jan 8 10:10:50 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 8 Jan 2016 10:10:50 -0500 Subject: [vtk-developers] Qt/VTK Starting Point Message-ID: Is VTK/Examples/SimpleView the best starting point for a simple Qt based VTK program? I want to try something with a simple GUI and wasn't sure if that was still a good starting point. 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 sankhesh.jhaveri at kitware.com Fri Jan 8 11:36:56 2016 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Fri, 8 Jan 2016 11:36:56 -0500 Subject: [vtk-developers] Qt/VTK Starting Point In-Reply-To: References: Message-ID: ?I'd say the simplest example of putting a VTK render window in a Qt MainWindow is http://www.vtk.org/Wiki/VTK/Examples/Cxx/Qt/RenderWindowUISingleInheritance The SimpleView example has other Qt elements too. Warm regards, Sankhesh On Fri, Jan 8, 2016 at 10:10 AM, Ken Martin wrote: > Is VTK/Examples/SimpleView the best starting point for a simple Qt based > VTK program? I want to try something with a simple GUI and wasn't sure if > that was still a good starting point. > > 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 dennisnguy at yahoo.com Fri Jan 8 12:00:24 2016 From: dennisnguy at yahoo.com (dieutan) Date: Fri, 8 Jan 2016 10:00:24 -0700 (MST) Subject: [vtk-developers] void vtkCamera::SetPosition crashed In-Reply-To: References: <1452208116821-5735862.post@n5.nabble.com> Message-ID: <1452272424204-5735886.post@n5.nabble.com> Joachim, Thanks for the solution. It works. I inherited an application code using VTK version 4.2. I'm updating the application and VTK version 5.10.1. Best, Dennis -- View this message in context: http://vtk.1045678.n5.nabble.com/void-vtkCamera-SetPosition-crashed-tp5735862p5735886.html Sent from the VTK - Dev mailing list archive at Nabble.com. From berk.geveci at kitware.com Fri Jan 8 13:21:06 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 8 Jan 2016 13:21:06 -0500 Subject: [vtk-developers] UPDATE_EXTENT not updating after change to WHOLE_EXTENT In-Reply-To: <568AD403.7080208@aerosoftinc.com> References: <56843D74.1070702@aerosoftinc.com> <568AA049.3080803@aerosoftinc.com> <568AAAF8.8000800@aerosoftinc.com> <568AD403.7080208@aerosoftinc.com> Message-ID: Bill, I can't tell you how much trouble you caused me :-) Kidding aside, this issue (which is indeed a bug) lead me into some deep rabbit holes in the pipeline. My least favorites ones at that. I am working on fixing and cleaning up. I should have a fix sometime next week. Best, -berk On Mon, Jan 4, 2016 at 3:20 PM, Bill McGrory wrote: > yes, vtkGeometryFilter goes straight to a vtkPolyDataMapper > > If that fails, I will try to strip my code down to something more > manageable and get it to you. > > Thank you > > > > > On 01/04/2016 03:11 PM, Berk Geveci wrote: > > OK this sounds like a bug. Is your pipeline only source -> > vtkGeometryFilter or is there something in between? I'll try to reproduce > this with a Python source once I know what the pipeline is. > > Best, > -berk > > On Mon, Jan 4, 2016 at 12:25 PM, Bill McGrory > wrote: > >> I think I am doing what you say should work. >> >> My personal data outside of VTK changes as a result of a user requested >> change from say the fine representation to the coarse. That change triggers >> a someSource->Modified(). that seems to correctly trigger a call to >> RequestInformation on someSource, which is when I modify WHOLE_EXTENT(). >> >> What I see is that WHOLE_EXTENT correctly propagates downstream, however, >> there is no change to the UPDATE_EXTENT as a result of the WHOLE_EXTENT >> being reduced. So when RequestUpdateExtent propagates back upstream, I get >> the error for it being out of range, with the WHOLE_EXTENT value being the >> new correct value. and UPDATE_EXTENT being the old value. >> >> Note my error is triggered at someSource->RequestUpdateExtent() >> >> Note the someFilterDownstream is a vtkGeometryFilter, and if I make a >> call to correct the UPDATE_EXTENT in the geometry filter to be in range >> WHOLE_EXTENT from vtkGeometryFilter::RequestUpdateExtent() then that fixes >> my bug, but this is only for vtkGeometryFilter, not a generic downstream >> filter. >> >> >> >> >> >> >> On 01/04/2016 11:46 AM, Berk Geveci wrote: >> >> So when the WHOLE_EXTENT() changes, you tell the source/reader by >> modifying it somehow? What I am trying to get to is whether or not this >> works: >> >> someSource->SetNewData(); >> someSource->Modified() >> someFilterDownstream->Update(); >> >> someSource->SetNewData(); >> someSource->Modified() >> someFilterDownstream->Update(); >> >> I believe that as long as the source is modified after the WHOLE_EXTENT() >> changes, update should work fine. Because this would lead to >> RequestInformation() being called again, which is what propagates the new >> WHOLE_EXTENT() downstream. >> >> Best, >> -berk >> >> On Mon, Jan 4, 2016 at 11:39 AM, Bill McGrory < >> mcgrory at aerosoftinc.com> wrote: >> >>> I have a pipeline for displaying structured zones within a GUI. These >>> zone's have multiple grid refinement levels or sequences. The beginning of >>> the pipeline is a source which creates a vtkStructuredGrid. >>> >>> When I interactively change the sequence level the source gets a call to >>> update the pipeline where I need to change the vtkStructuredGrid to >>> represent a different sequence level (so my grid grid dimensions will >>> double or halve, for example) >>> >>> This process worked (by accident perhaps) in versions of VTK prior to 6. >>> >>> Thanks >>> Bill >>> >>> >>> >>> On 01/04/2016 11:08 AM, Berk Geveci wrote: >>> >>> Hey Bill, >>> >>> The very short (and annoying) answer is that VTK does not currently >>> support varying WHOLE_EXTENT(). >>> >>> However, there are ways of getting around this. But before I get into >>> those, can you describe how/where you change the whole extent? As part of a >>> time update? By setting some data member on the reader? >>> >>> Best, >>> -berk >>> >>> On Wed, Dec 30, 2015 at 3:24 PM, Bill McGrory < >>> mcgrory at aerosoftinc.com> wrote: >>> >>>> I am having difficulty porting some code from VTK 5 to 6. >>>> >>>> I have a custom algorithm for creating a vtkStructuredGrid as the >>>> source for my pipeline, so my class inherits vtkStructuredGridAlgorithm >>>> >>>> my pipeline simply connects the vtkStructuredGridAlgorithm to a >>>> vtkGeometryFilter which is mapped with a vtkPolyDataMapper >>>> >>>> I want my source to correctly render a structured grid which changes >>>> dimensions dynamically within my application. >>>> >>>> My problem is that if I originally set up the grid with say extents of >>>> 0 --99, 0-->99, 0-->99, and then change the extents to 0--49, 0-49,0-49 >>>> through a call to Update, then I get a VTK error message from >>>> >>>> >>>> ERROR: In >>>> VTK-6.2.0/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx, line >>>> 860 >>>> vtkCompositeDataPipeline (0xb4561f0): The update extent specified in >>>> the information for output port 0 on algorithm >>>> SurfaceSNodeSource(0xb455750) is 0 80 0 32 0 0, which is outside the whole >>>> extent 0 40 0 16 0 0. >>>> (This is in VerifyOutputInformation) called before the >>>> RequestUpdateExtent for my algorithm. >>>> >>>> I don't quite understand the propagation of the UPDATE_EXTENT >>>> information up the pipeline, but if I set the UPDATE_EXTENT to WHOLE_EXTENT >>>> >>>> in vtkGeometryFilter::RequestUpdateExtent >>>> >>>> then the error goes away. >>>> Also, at the time of calling vtkGeometryFilter::RequestUpdateExtent, >>>> the UPDATE_EXTENT is still set at the old value, while the WHOLE_EXTENT has >>>> been correctly updated/propagated from upstream. >>>> >>>> Is this a bug, or do I need to change something in my >>>> vtkStructuredGridAlgorithm to cause the UPDATE_EXTENT to be reset at the >>>> origin downstream? >>>> >>>> Thanks >>>> >>>> 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 >>>> >>>> >>> >>> -- >>> Dr. William D. McGrory AeroSoft, Inc.mcgrory at aerosoftinc.com Suite 1400(540) 557-1904 2000 Kraft Drive(540) 557-1919 (FAX) Blacksburg, VA 24060 >>> >>> >> >> -- >> Dr. William D. McGrory AeroSoft, Inc.mcgrory at aerosoftinc.com Suite 1400(540) 557-1904 2000 Kraft Drive(540) 557-1919 (FAX) Blacksburg, VA 24060 >> >> > > -- > Dr. William D. McGrory AeroSoft, Inc.mcgrory at aerosoftinc.com Suite 1400(540) 557-1904 2000 Kraft Drive(540) 557-1919 (FAX) Blacksburg, VA 24060 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joaorobertojr88 at gmail.com Sun Jan 10 22:05:20 2016 From: joaorobertojr88 at gmail.com (joaoroberto88) Date: Sun, 10 Jan 2016 20:05:20 -0700 (MST) Subject: [vtk-developers] vtkAxis class considerations Message-ID: <1452481520675-5735904.post@n5.nabble.com> Hi Devs, Last week I was coding an application that uses vtkAxis class. Since I faced an issue about tick labels overlapping, I decided to investigate its source code. I would like do contribute to the project, so I share below some points about my investigation and we can discuss what can be done to fix/implement them or just leave as they are. 1. X-axis tick labels overlapping: when I use a custom list of labels (relatively big) via vtkAxis::SetCustomTickPositions method they appear overlapped (shown here http://vtk.1045678.n5.nabble.com/Issue-when-setting-number-of-ticks-on-a-vtkAxis-td5735645.html). As mentioned, the number of ticks isn't respected. Is it correct? Should that list of ticks be managed outside of the class or is it a requirement that the implementation adjusts them automatically? 2. Neither vtkAxis::Shift or vtkAxis::ScalingFactor private attributes are used. Additionally, there are documented get and set methods for them. Is it proposital? In negative case, what should be exactly the requirements? Thanks, Joao Roberto. -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkAxis-class-considerations-tp5735904.html Sent from the VTK - Dev mailing list archive at Nabble.com. From hweng52 at gmail.com Mon Jan 11 19:38:07 2016 From: hweng52 at gmail.com (Hanlin Weng) Date: Mon, 11 Jan 2016 19:38:07 -0500 Subject: [vtk-developers] Contributing to Vtk In-Reply-To: References: Message-ID: <053EF158-3141-4418-9A9D-5CDD4BD8A7BB@gmail.com> Happy new year every one! I tried to run the vtk samples found under the vtk6.3.0 download. Could any one tell where to find vtk.jar and native libraries? They can not be found in the download! Thanks Hanlin Sent from my iPhone > On Jan 2, 2016, at 4:30 PM, Andy Bauer wrote: > > Hi Akash, > > Welcome to the VTK community! > > Is there a specific functionality you're looking to get into VTK? If you describe what you're hoping to do I'm sure you'll get helpful hints on how to do it. If you're just looking to get some experience with VTK I'd suggest starting out with either participating in code reviews (see https://gitlab.kitware.com/vtk/vtk/merge_requests for pending merge requests) or look at fixing a bug or two (some are listed at http://www.paraview.org/Bug/view_all_bug_page.php). > > There is information at http://www.vtk.org/contributing-code/ on how to contribute to VTK. Feel free to seek out help on the mailing list -- VTK is big enough that no one is an expert in all parts of it but the community is very responsive and certainly someone will know parts of the code that you're looking at. > > Best regards, > Andy > >> On Fri, Jan 1, 2016 at 11:32 AM, Akash B wrote: >> Hi all, >> I'm interested in contribution to Vtk. I'm comfortable with C++, C++11, Python and Java. I'd like some guidance as to how to contribute to Vtk. >> >> Regards, >> Akash PB >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://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 Tue Jan 12 10:46:35 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 12 Jan 2016 10:46:35 -0500 Subject: [vtk-developers] Fwd: [hpdav-pc] extended submission deadline: IPDPS workshop High Performance Data Analysis and Visualization 2016 In-Reply-To: <56942E39.1040907@lbl.gov> References: <56942E39.1040907@lbl.gov> Message-ID: ---------- Forwarded message ---------- From: Wes Bethel Date: Mon, Jan 11, 2016 at 5:35 PM Subject: [hpdav-pc] extended submission deadline: IPDPS workshop High Performance Data Analysis and Visualization 2016 To: hpdav-pc at lists.lbl.gov Apologies if you receive multiple copies of this notice, it is being cross-posted to multiple lists. Summary: the submission date for papers is being extended two weeks, to 25 Jan 2016, 23:59AOE. See below for more information. ____________________________________________________________________________________ HPDAV 2016 Call for papers ____________________________________________________________________________________ The workshop on High Performance Data Analysis and Visualization (HPDAV) 2016 http://vis.lbl.gov/Events/HPDAV-IPDPS-2016/ May 23, 2016 To be held in conjunction with 30th IEEE International Parallel and Distributed Processing Symposium http://www.ipdps.org/ May 23-26, 2016 Chicago Hyatt Regency, Chicago, Illinois, USA Important Dates ____________________________________________________________________________________ Paper Submission: (new date) 25 Jan 2016, 23:59 AOE Author Notification: (new date) 12 Feb 2016 Camera-Ready: 21 Feb 2016, 23:59 AOE Workshop Scope and Goals ____________________________________________________________________________________ While the purpose of visualization and analysis is insight, realizing that objective requires solving complex problems related to crafting or adapting algorithms and applications to take advantage of evolving architectures, and to solve increasingly complex data understanding problems for ever larger and more complex data. These architectures, and the systems from which they are built, have increasingly deep memory hierarchies, increasing concurrency, decreasing relative per-core/per-node I/O capacity, lessening memory per core, are increasingly prone to failures, and face power limitations. The purpose of this workshop is to bring together researchers, engineers, and architects of data-intensive computing technologies, which span visualization, analysis, and data management, to present and discuss research topics germane to high performance data analysis and visualization. Specifically, this workshop focuses on research topics related to adapting/creating algorithms, technologies, and applications for use on emerging computational architectures and platforms. The workshop format includes traditional research papers (8-10 pages) for in-depth topics, short papers (4 pages) for works in progress, and a panel discussion. Proceedings of the workshops are distributed at the conference and are submitted for inclusion in the IEEE Xplore Digital Library after the conference. We invite papers on original, unpublished research in the following topic areas under the general umbrella of high performance visualization and analysis: - Increasing concurrency at the node level, and at the systemwide level. - Optimizations for improving performance, e.g., decreasing runtime, leveraging a deepening memory hierarchy, reducing data movement, reducing power consumption. - Applications of visualization and analysis, where there is a strong thematic element related to being able to solve a larger or more complex problem because of algorithmic or design advances that take advantage of increasing concurrency, architectural features, etc. - Data analysis and/or visualization systems/designs/architectures having an emphasis upon scalability, resilience, high-throughput/high-capacity, and that are able to take advantage of emerging architectures. Paper submission guidelines: see http://vis.lbl.gov/Events/HPDAV-IPDPS-2016 Program Committee ____________________________________________________________________________________ Jeff Baumes, Kitware Janine Bennett, Sandia National Laboratory Wes Bethel, Lawrence Berkeley National Laboratory Randall Frank, Applied Research Associates Kelly Gaither, Texas Advanced Computing Center Christoph Garth, University of Kaiserslautern Berk Geveci, Kitware Pat McCormick, Los Alamos National Laboratory Vijay Natarajan, Indian Institute of Science Paul Navratil, Texas Advanced Computing Center Sang-Yun Oh, University of California -- Santa Barbara Rob Ross, Argonne National Laboratory Yogesh Simmhan, Indian Institute of Science Venkat Vishwanath, Argonne National Laboratory Johann Won, Seoul National University John Wu, Lawrence Berkeley National Laboratory -- Wes Bethel -- voice (510) 486-7353 -- fax (510) 486-5812 -- vis.lbl.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From hahnse at ornl.gov Tue Jan 12 21:02:21 2016 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Wed, 13 Jan 2016 02:02:21 +0000 Subject: [vtk-developers] Error building VTK with VTK_USE_SYSTEM_HDF5=ON Message-ID: <1452650603715.86889@ornl.gov> When building VTK with VTK_USE_SYSTEM_HDF5=ON, I get the following warning: Disabling NETCDF4 support since HDF5_HL or HDF5_hdf5_hl is missing. This recently became a problem since the ParaView CDIReader plugin adds the definition -DHAVE_NETCDF4 and when building ParaView v5.0.0 from source with VTK_USE_SYSTEM_HDF5=ON, one gets an undefined symbols error on OS X. Neither CMake variables HDF5_HL_LIBRARY and HDF5_hdf5_hl_LIBRARY are defined, but (depending on the build type) HDF5_hdf5_hl_LIBRARY_DEBUG or HDF5_hdf5_hl_LIBRARY_RELEASE are and the library is included in HDF5_LIBRARIES. I created a merge request (https://gitlab.kitware.com/vtk/vtk/merge_requests/1078) adding these two variables to the if statement checking if the HDF5 HL library is installed. Best, Steven Hahn From dave.demarle at kitware.com Thu Jan 14 16:07:48 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 14 Jan 2016 16:07:48 -0500 Subject: [vtk-developers] announce: vtk 7.0.0 release candidate 2 is ready Message-ID: I'm happy to let you know that next release candidate in the VTK 7.0 release cycle is ready for you to try. Thank you everyone who tried and provided feedback and updates based on rc1. As usual you can find the source, data, and vtkpython binary packages here: http://www.vtk.org/download/#candidate Please try this version of VTK and report any issues to the list or the bug tracker so that we can try to address them before VTK 7.0.0 final in a few weeks time. The changes from rc1 are as follows: commit bc6c71ea79dc7bd7523b81aa1d1b5e6a98d57daf Author: T.J. Corona Deprecating vtkVolumeRaycastMapper and vtkVolumeTextureMapper2D/3D. commit 6b7e888a2c2d91956af0bf8dcd8a48c9717b9d76 Author: Ken Martin update for newer versions of iOS commit a849580122154f99ab343e8ab2eb40b49c05f89d Author: Boris Nagaev Fix CMake error if in directory with ++ in name. commit 46a54e5ab8e77d817fd6bfa0816c9e987673c896 Author: David Gobbi BUG 15914: Fix corrupt image from vtkImageResliceMapper commit 69bafcd8bada56f7b307740f53635e8adc980408 Author: Ken Martin Fix some coverity issues commit fff730946a7c779fe5cb34d199a3028388e57e6f Author: Ken Martin Free up memory in the point gaussian commit 5146150ed9d33345fe7d2d606a230a86c738dc91 Author: Fabian Wenzel Fixes QTVTKRenderWindowInteractor for python3 commit 9d952e9283c66ed8c86fd92d54216504e9fe50ed Author: T.J. Corona Fix memory leak in vtkMath::SolveLeastSquares. commit e7e71c4e513b93d9879a797708cf362e3cc5bf66 Author: Ken Martin get a 3.2 context from OS mesa using new funcs commit 1cbd9fde716101d363aba9d34d96feb8ecbdd856 Author: Zlib Upstream zlib 2015-12-14 (751703ae) commit ea74dd0bfcd2ab93c8b668648693f6393d8cc93c Author: David Gobbi zlib: remove zlib1.rc from the list of used files. commit 1cb28ce76d1480efe6b11d76dd83fafc038f197e Author: David Gobbi Change deprecation warning to "VTK 7.0". commit 4a1fbefe00db0184aa088eaacdd08a023c666f9f Author: David Gobbi Remove AGL.framework from OS X OPENGL_LIBRARIES. commit 88dfac4a47cf8cdf0aca82e649753a5f5e85fe42 Author: David Gobbi Synchronize vtkMatrix3x3 with vtkMatrix4x4. commit 986d4c8b75c9a2cf85e0dc5564e652d6bd48c735 Author: David Gobbi Remove warning about deprecated method usage. commit b5af8d4bbd5d348623c2c7451a417e07e3010c9a Author: Zlib Upstream zlib 2015-12-09 (acc12639) commit 1ddf7372bd7ce3329033beea21dc0cc638e6e136 Author: David Gobbi Eliminate C-style casts from vtkMatrix4x4. commit a16e1843cf92f5159d6b002b12f0a045e9d2c161 Author: David Gobbi Rename Element parameter to element. commit d9c5ca00826dafabd8ddd87e409e1611f42ec621 Author: David Gobbi Mark legacy methods as "legacy". commit 8af584db104054a9350bb4107ada0cb1dbbb06cc Author: Brad King ThirdParty: Improve update script default merge message behavior commit d0ecfc35705267e22213297a49b23550b74ded24 Author: David Gobbi Remove the legacy BTX/ETX markers. commit 7afac239c92064750ed9bfab24a120dc26915a57 Author: David Gobbi Move some comments so they become visible to doxygen. commit 3eda5f89ae77d218ba854201fa1d02f803055f48 Author: Brad King ThirdParty: Teach update script to find upstream hash in commit message commit d8fb062a7bc89b52b40ccfc71eaca7246f19022e Author: Brad King ThirdParty: Teach update script to store upstream hash in commit message commit 51a19f27c5a03dedb35507823b0467fddf160f29 Author: MetaIO Upstream metaio 2015-11-23 (4c85a18e) commit bf1a55acb8277231d47582a756bef5b66e52f2e4 Author: JsonCpp Upstream jsoncpp 2015-10-01 (eb1ddde0) commit 0531c5612667097dc0d4244389eb2fa3ecd695d9 Author: Libpng Upstream png 2015-12-07 (63adbb10) commit 4032eee18eda3415766af236cfc5756e80bec3a6 Author: Zlib Upstream zlib 2015-11-18 (0abb295c) commit 60d6c9acdf09b7d24c456759b267ac524b2f0962 Author: Ben Boeckel ios: fix newline-at-end-of-file commit 0a5666757d84b3ad62e3fda4032dafe60d3f21f5 Author: Dave DeMarle fix a cmake warning for users of VTK thanks! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Jan 14 17:03:32 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 14 Jan 2016 14:03:32 -0800 Subject: [vtk-developers] announce: vtk 7.0.0 release candidate 2 is ready In-Reply-To: References: Message-ID: Hi, On Thu, Jan 14, 2016 at 1:07 PM, David E DeMarle wrote: > I'm happy to let you know that next release candidate in the VTK 7.0 release > cycle is ready for you to try. Thank you everyone who tried and provided > feedback and updates based on rc1. > > As usual you can find the source, data, and vtkpython binary packages here: > > http://www.vtk.org/download/#candidate > > Please try this version of VTK and report any issues to the list or the > bug tracker so that we can try to address them before VTK 7.0.0 final in a > few weeks time. > > The changes from rc1 are as follows: > commit bc6c71ea79dc7bd7523b81aa1d1b5e6a98d57daf > Author: T.J. Corona > > Deprecating vtkVolumeRaycastMapper and vtkVolumeTextureMapper2D/3D. > > commit 6b7e888a2c2d91956af0bf8dcd8a48c9717b9d76 > Author: Ken Martin > > update for newer versions of iOS > > commit a849580122154f99ab343e8ab2eb40b49c05f89d > Author: Boris Nagaev > > Fix CMake error if in directory with ++ in name. > > commit 46a54e5ab8e77d817fd6bfa0816c9e987673c896 > Author: David Gobbi > > BUG 15914: Fix corrupt image from vtkImageResliceMapper > > commit 69bafcd8bada56f7b307740f53635e8adc980408 > Author: Ken Martin > > Fix some coverity issues > > commit fff730946a7c779fe5cb34d199a3028388e57e6f > Author: Ken Martin > > Free up memory in the point gaussian > > commit 5146150ed9d33345fe7d2d606a230a86c738dc91 > Author: Fabian Wenzel > > Fixes QTVTKRenderWindowInteractor for python3 > > commit 9d952e9283c66ed8c86fd92d54216504e9fe50ed > Author: T.J. Corona > > Fix memory leak in vtkMath::SolveLeastSquares. > > commit e7e71c4e513b93d9879a797708cf362e3cc5bf66 > Author: Ken Martin > > get a 3.2 context from OS mesa using new funcs > > commit 1cbd9fde716101d363aba9d34d96feb8ecbdd856 > Author: Zlib Upstream > > zlib 2015-12-14 (751703ae) > > commit ea74dd0bfcd2ab93c8b668648693f6393d8cc93c > Author: David Gobbi > > zlib: remove zlib1.rc from the list of used files. > > commit 1cb28ce76d1480efe6b11d76dd83fafc038f197e > Author: David Gobbi > > Change deprecation warning to "VTK 7.0". > > commit 4a1fbefe00db0184aa088eaacdd08a023c666f9f > Author: David Gobbi > > Remove AGL.framework from OS X OPENGL_LIBRARIES. > > commit 88dfac4a47cf8cdf0aca82e649753a5f5e85fe42 > Author: David Gobbi > > Synchronize vtkMatrix3x3 with vtkMatrix4x4. > > commit 986d4c8b75c9a2cf85e0dc5564e652d6bd48c735 > Author: David Gobbi > > Remove warning about deprecated method usage. > > commit b5af8d4bbd5d348623c2c7451a417e07e3010c9a > Author: Zlib Upstream > > zlib 2015-12-09 (acc12639) > > commit 1ddf7372bd7ce3329033beea21dc0cc638e6e136 > Author: David Gobbi > > Eliminate C-style casts from vtkMatrix4x4. > > commit a16e1843cf92f5159d6b002b12f0a045e9d2c161 > Author: David Gobbi > > Rename Element parameter to element. > > commit d9c5ca00826dafabd8ddd87e409e1611f42ec621 > Author: David Gobbi > > Mark legacy methods as "legacy". > > commit 8af584db104054a9350bb4107ada0cb1dbbb06cc > Author: Brad King > > ThirdParty: Improve update script default merge message behavior > > commit d0ecfc35705267e22213297a49b23550b74ded24 > Author: David Gobbi > > Remove the legacy BTX/ETX markers. > > commit 7afac239c92064750ed9bfab24a120dc26915a57 > Author: David Gobbi > > Move some comments so they become visible to doxygen. > > commit 3eda5f89ae77d218ba854201fa1d02f803055f48 > Author: Brad King > > ThirdParty: Teach update script to find upstream hash in commit message > > commit d8fb062a7bc89b52b40ccfc71eaca7246f19022e > Author: Brad King > > ThirdParty: Teach update script to store upstream hash in commit message > > commit 51a19f27c5a03dedb35507823b0467fddf160f29 > Author: MetaIO Upstream > > metaio 2015-11-23 (4c85a18e) > > commit bf1a55acb8277231d47582a756bef5b66e52f2e4 > Author: JsonCpp Upstream > > jsoncpp 2015-10-01 (eb1ddde0) > > commit 0531c5612667097dc0d4244389eb2fa3ecd695d9 > Author: Libpng Upstream > > png 2015-12-07 (63adbb10) > > commit 4032eee18eda3415766af236cfc5756e80bec3a6 > Author: Zlib Upstream > > zlib 2015-11-18 (0abb295c) > > commit 60d6c9acdf09b7d24c456759b267ac524b2f0962 > Author: Ben Boeckel > > ios: fix newline-at-end-of-file > > commit 0a5666757d84b3ad62e3fda4032dafe60d3f21f5 > Author: Dave DeMarle > > fix a cmake warning for users of VTK I noticed y'all are still using the standalone vtkpython as your binary distribution method for OSX. Do you have any plans for making a Python wheel for VTK? It would make it much easier to install VTK into an existing Python installation, and therefore to use VTK with lots of other scientific / technical Python packages. I'm very happy to help with this, if you can give me some pointers as to how to proceed. Cheers, Matthew From dave.demarle at kitware.com Thu Jan 14 17:17:50 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 14 Jan 2016 17:17:50 -0500 Subject: [vtk-developers] announce: vtk 7.0.0 release candidate 2 is ready In-Reply-To: References: Message-ID: I very much agree. The only thing holding it back on the Kitware side is that we've not found a chunk of time to sit down, think about it, and do it. Same thing goes for putting out SDKs for the major platforms. :( David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Jan 14, 2016 at 5:03 PM, Matthew Brett wrote: > Hi, > > On Thu, Jan 14, 2016 at 1:07 PM, David E DeMarle > wrote: > > I'm happy to let you know that next release candidate in the VTK 7.0 > release > > cycle is ready for you to try. Thank you everyone who tried and provided > > feedback and updates based on rc1. > > > > As usual you can find the source, data, and vtkpython binary packages > here: > > > > http://www.vtk.org/download/#candidate > > > > Please try this version of VTK and report any issues to the list or the > > bug tracker so that we can try to address them before VTK 7.0.0 final in > a > > few weeks time. > > > > The changes from rc1 are as follows: > > commit bc6c71ea79dc7bd7523b81aa1d1b5e6a98d57daf > > Author: T.J. Corona > > > > Deprecating vtkVolumeRaycastMapper and vtkVolumeTextureMapper2D/3D. > > > > commit 6b7e888a2c2d91956af0bf8dcd8a48c9717b9d76 > > Author: Ken Martin > > > > update for newer versions of iOS > > > > commit a849580122154f99ab343e8ab2eb40b49c05f89d > > Author: Boris Nagaev > > > > Fix CMake error if in directory with ++ in name. > > > > commit 46a54e5ab8e77d817fd6bfa0816c9e987673c896 > > Author: David Gobbi > > > > BUG 15914: Fix corrupt image from vtkImageResliceMapper > > > > commit 69bafcd8bada56f7b307740f53635e8adc980408 > > Author: Ken Martin > > > > Fix some coverity issues > > > > commit fff730946a7c779fe5cb34d199a3028388e57e6f > > Author: Ken Martin > > > > Free up memory in the point gaussian > > > > commit 5146150ed9d33345fe7d2d606a230a86c738dc91 > > Author: Fabian Wenzel > > > > Fixes QTVTKRenderWindowInteractor for python3 > > > > commit 9d952e9283c66ed8c86fd92d54216504e9fe50ed > > Author: T.J. Corona > > > > Fix memory leak in vtkMath::SolveLeastSquares. > > > > commit e7e71c4e513b93d9879a797708cf362e3cc5bf66 > > Author: Ken Martin > > > > get a 3.2 context from OS mesa using new funcs > > > > commit 1cbd9fde716101d363aba9d34d96feb8ecbdd856 > > Author: Zlib Upstream > > > > zlib 2015-12-14 (751703ae) > > > > commit ea74dd0bfcd2ab93c8b668648693f6393d8cc93c > > Author: David Gobbi > > > > zlib: remove zlib1.rc from the list of used files. > > > > commit 1cb28ce76d1480efe6b11d76dd83fafc038f197e > > Author: David Gobbi > > > > Change deprecation warning to "VTK 7.0". > > > > commit 4a1fbefe00db0184aa088eaacdd08a023c666f9f > > Author: David Gobbi > > > > Remove AGL.framework from OS X OPENGL_LIBRARIES. > > > > commit 88dfac4a47cf8cdf0aca82e649753a5f5e85fe42 > > Author: David Gobbi > > > > Synchronize vtkMatrix3x3 with vtkMatrix4x4. > > > > commit 986d4c8b75c9a2cf85e0dc5564e652d6bd48c735 > > Author: David Gobbi > > > > Remove warning about deprecated method usage. > > > > commit b5af8d4bbd5d348623c2c7451a417e07e3010c9a > > Author: Zlib Upstream > > > > zlib 2015-12-09 (acc12639) > > > > commit 1ddf7372bd7ce3329033beea21dc0cc638e6e136 > > Author: David Gobbi > > > > Eliminate C-style casts from vtkMatrix4x4. > > > > commit a16e1843cf92f5159d6b002b12f0a045e9d2c161 > > Author: David Gobbi > > > > Rename Element parameter to element. > > > > commit d9c5ca00826dafabd8ddd87e409e1611f42ec621 > > Author: David Gobbi > > > > Mark legacy methods as "legacy". > > > > commit 8af584db104054a9350bb4107ada0cb1dbbb06cc > > Author: Brad King > > > > ThirdParty: Improve update script default merge message behavior > > > > commit d0ecfc35705267e22213297a49b23550b74ded24 > > Author: David Gobbi > > > > Remove the legacy BTX/ETX markers. > > > > commit 7afac239c92064750ed9bfab24a120dc26915a57 > > Author: David Gobbi > > > > Move some comments so they become visible to doxygen. > > > > commit 3eda5f89ae77d218ba854201fa1d02f803055f48 > > Author: Brad King > > > > ThirdParty: Teach update script to find upstream hash in commit > message > > > > commit d8fb062a7bc89b52b40ccfc71eaca7246f19022e > > Author: Brad King > > > > ThirdParty: Teach update script to store upstream hash in commit > message > > > > commit 51a19f27c5a03dedb35507823b0467fddf160f29 > > Author: MetaIO Upstream > > > > metaio 2015-11-23 (4c85a18e) > > > > commit bf1a55acb8277231d47582a756bef5b66e52f2e4 > > Author: JsonCpp Upstream > > > > jsoncpp 2015-10-01 (eb1ddde0) > > > > commit 0531c5612667097dc0d4244389eb2fa3ecd695d9 > > Author: Libpng Upstream > > > > png 2015-12-07 (63adbb10) > > > > commit 4032eee18eda3415766af236cfc5756e80bec3a6 > > Author: Zlib Upstream > > > > zlib 2015-11-18 (0abb295c) > > > > commit 60d6c9acdf09b7d24c456759b267ac524b2f0962 > > Author: Ben Boeckel > > > > ios: fix newline-at-end-of-file > > > > commit 0a5666757d84b3ad62e3fda4032dafe60d3f21f5 > > Author: Dave DeMarle > > > > fix a cmake warning for users of VTK > > I noticed y'all are still using the standalone vtkpython as your > binary distribution method for OSX. > > Do you have any plans for making a Python wheel for VTK? It would > make it much easier to install VTK into an existing Python > installation, and therefore to use VTK with lots of other scientific / > technical Python packages. > > I'm very happy to help with this, if you can give me some pointers as > to how to proceed. > > Cheers, > > Matthew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Jan 14 19:47:38 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 14 Jan 2016 16:47:38 -0800 Subject: [vtk-developers] announce: vtk 7.0.0 release candidate 2 is ready In-Reply-To: References: Message-ID: Hi, On Thu, Jan 14, 2016 at 2:17 PM, David E DeMarle wrote: > I very much agree. > > The only thing holding it back on the Kitware side is that we've not found a > chunk of time to sit down, think about it, and do it. Same thing goes for > putting out SDKs for the major platforms. > > :( If you do manage to solve the pip install problem, it could have a big impact on the use of VTK on OSX. At the moment, users can do: pip install numpy scipy matplotlib etc to get the standard Python scientific packages. If they could also do: pip install vtk into the same environment, this would make it very easy to get started with using VTK. I previously pointed to an approach to building Python wheels without using the (somewhat obscure) standard Python distutils mechanism : http://vtk.1045678.n5.nabble.com/Help-building-Python-wheels-for-VTK-td5728074.html#a5733760 I wonder whether something like that could work within cmake? Cheers, Matthew From berk.geveci at kitware.com Fri Jan 15 10:57:36 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 15 Jan 2016 10:57:36 -0500 Subject: [vtk-developers] Changes to the way the pipeline is updated Message-ID: Hi folks, In an effort to address a bug reported on the mailing list, I ended up making a change to the way the pipeline is updated. I made a minor change to the way update behaves but more importantly, I'd like to make an API change that is biggish. Here is how an algorithm is updated currently. anAlgorithm->Update(); If you want the algorithm to produce a particular subset in space or time, you need to do this: anAlgorithm->UpdateInformation(); anAlgorithm->SetUpdateExtent(0, 2, 0); anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1); anAlgorithm->SetUpdateTimeStep(0.5); anAlgorithm->Update(); If you forget the UpdateInformation() part, this does not work. This is a problem because there are a bunch of disparate methods that need to be documented with information about the order of the method calls. Currently, this is tribal knowledge. The change I need to make to fix the bug reported makes things even more complicated. After the change, this will not work: anAlgorithm->UpdateInformation(); anAlgorithm->SetUpdateExtent(0, 2, 0); anAlgorithm->Modified(); anAlgorithm->Update(); The Modified() call causes the Information pass to execute again, which after my changes initializes the requests to default values (such as (0, 1, 0) for the piece stuff and WHOLE_EXTENT() for the extents). Without this change, there are subtle bugs that come up in filters and mappers. So now, we also need to document that you cannot modify the object after UpdateInformation() (including calling any Set methods) for this to work. Here is the change I'd like to make: * Deprecate all of the SetUpdateXXX() methods. * Add arguments to Update() that allows passing of requests So the first example would look like: int updateExtent[6] = {0, 10, 0, 10, 1, 1}; anAlgorithm->UpdateTimeStep(0.5, 0, 2, 0, updateExtent); There are signatures for: Update(int piece, int numPieces, int ghostLevel); Update(int piece, int numPieces, int ghostLevel, int* updateExtent); UpdateTimeStep(double time); UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel); UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel, int* updateExtent); There is also a more flexible method with this signature: Update(vtkInformation* requests); This allows assigning any arbitrary number of requests for the update pass. For example: vtkNew info; info->Set(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP(), 0.5); anAlgorithm->Update(info.GetPointer()); Finally, it is still possible to do the "updateInfo -> set request -> update" thing like this: int updateExtent[6] = {0, 10, 0, 10, 1, 1}; anAlgorithm->UpdateInformation(); vtkInformation* outInfo = anAlgorithm->GetOutputInformation(0); outInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(), updateExtent); // Don't modify the object after this anAlgorithm->Update(); This is the advanced use case. Here is the branch that passes all of the tests: https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change It is WIP because I need to add some better documentation. What do you think? -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Jan 15 11:47:27 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 15 Jan 2016 09:47:27 -0700 Subject: [vtk-developers] Changes to the way the pipeline is updated In-Reply-To: References: Message-ID: Hi Berk, I'll take a look. Proper initialization, validation, and (in the case diamond-shaped pipelines and multiple downstream requests) proper combination of update extents is a real headache. I don't envy you. Making the behavior more explicit sounds good. By the way, I started planning the integration of the SMP image filters a couple weeks ago. It'll hopefully be ready in a couple months. - David On Fri, Jan 15, 2016 at 8:57 AM, Berk Geveci wrote: > Hi folks, > > In an effort to address a bug reported on the mailing list, I ended up > making a change to the way the pipeline is updated. I made a minor change > to the way update behaves but more importantly, I'd like to make an API > change that is biggish. > > Here is how an algorithm is updated currently. > > anAlgorithm->Update(); > > If you want the algorithm to produce a particular subset in space or time, > you need to do this: > > anAlgorithm->UpdateInformation(); > anAlgorithm->SetUpdateExtent(0, 2, 0); > anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1); > anAlgorithm->SetUpdateTimeStep(0.5); > anAlgorithm->Update(); > > If you forget the UpdateInformation() part, this does not work. This is a > problem because there are a bunch of disparate methods that need to be > documented with information about the order of the method calls. Currently, > this is tribal knowledge. The change I need to make to fix the bug reported > makes things even more complicated. After the change, this will not work: > > anAlgorithm->UpdateInformation(); > anAlgorithm->SetUpdateExtent(0, 2, 0); > anAlgorithm->Modified(); > anAlgorithm->Update(); > > The Modified() call causes the Information pass to execute again, which > after my changes initializes the requests to default values (such as (0, 1, > 0) for the piece stuff and WHOLE_EXTENT() for the extents). Without this > change, there are subtle bugs that come up in filters and mappers. So now, > we also need to document that you cannot modify the object after > UpdateInformation() (including calling any Set methods) for this to work. > > Here is the change I'd like to make: > > * Deprecate all of the SetUpdateXXX() methods. > * Add arguments to Update() that allows passing of requests > > So the first example would look like: > > int updateExtent[6] = {0, 10, 0, 10, 1, 1}; > anAlgorithm->UpdateTimeStep(0.5, 0, 2, 0, updateExtent); > > There are signatures for: > > Update(int piece, int numPieces, int ghostLevel); > Update(int piece, int numPieces, int ghostLevel, int* updateExtent); > UpdateTimeStep(double time); > UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel); > UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel, int* > updateExtent); > > There is also a more flexible method with this signature: > > Update(vtkInformation* requests); > > This allows assigning any arbitrary number of requests for the update > pass. For example: > > vtkNew info; > info->Set(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP(), 0.5); > anAlgorithm->Update(info.GetPointer()); > > Finally, it is still possible to do the "updateInfo -> set request -> > update" thing like this: > > int updateExtent[6] = {0, 10, 0, 10, 1, 1}; > anAlgorithm->UpdateInformation(); > vtkInformation* outInfo = anAlgorithm->GetOutputInformation(0); > outInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(), > updateExtent); > // Don't modify the object after this > anAlgorithm->Update(); > > This is the advanced use case. > > Here is the branch that passes all of the tests: > > https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change > > It is WIP because I need to add some better documentation. > > What do you think? > -berk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Jan 15 12:47:28 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 15 Jan 2016 12:47:28 -0500 Subject: [vtk-developers] Changes to the way the pipeline is updated In-Reply-To: References: Message-ID: Hi David, Thanks :-) I plan on tackling the diamond shaped pipelines in the medium-future. My plan for that is much more ambitious. I want to make each pass have an upstream and downstream part. There would be 3 passes: Static meta-data (same as current Request Information) Dynamic meta-data (requests go up and dynamic meta-data comes down) Data (requests go up and data comes down) So we can do something like this: * Static meta-data : get time steps * Dynamic meta-data : request for time step, get whole extent back * Data : request for sub-extent, get data back. Currently, this would require whole lot more passes. Plus this would fix any issues with diamond pipelines because each execution path would happen with the appropriate update request - so branch-outs in a diamond pipeline could execute multiple times if each branch asked for different extent. Cheers, -berk On Fri, Jan 15, 2016 at 11:47 AM, David Gobbi wrote: > Hi Berk, I'll take a look. Proper initialization, validation, and (in > the case diamond-shaped pipelines and multiple downstream requests) proper > combination of update extents is a real headache. I don't envy you. > Making the behavior more explicit sounds good. > > By the way, I started planning the integration of the SMP image filters a > couple weeks ago. It'll hopefully be ready in a couple months. > > - David > > > On Fri, Jan 15, 2016 at 8:57 AM, Berk Geveci > wrote: > >> Hi folks, >> >> In an effort to address a bug reported on the mailing list, I ended up >> making a change to the way the pipeline is updated. I made a minor change >> to the way update behaves but more importantly, I'd like to make an API >> change that is biggish. >> >> Here is how an algorithm is updated currently. >> >> anAlgorithm->Update(); >> >> If you want the algorithm to produce a particular subset in space or >> time, you need to do this: >> >> anAlgorithm->UpdateInformation(); >> anAlgorithm->SetUpdateExtent(0, 2, 0); >> anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1); >> anAlgorithm->SetUpdateTimeStep(0.5); >> anAlgorithm->Update(); >> >> If you forget the UpdateInformation() part, this does not work. This is a >> problem because there are a bunch of disparate methods that need to be >> documented with information about the order of the method calls. Currently, >> this is tribal knowledge. The change I need to make to fix the bug reported >> makes things even more complicated. After the change, this will not work: >> >> anAlgorithm->UpdateInformation(); >> anAlgorithm->SetUpdateExtent(0, 2, 0); >> anAlgorithm->Modified(); >> anAlgorithm->Update(); >> >> The Modified() call causes the Information pass to execute again, which >> after my changes initializes the requests to default values (such as (0, 1, >> 0) for the piece stuff and WHOLE_EXTENT() for the extents). Without this >> change, there are subtle bugs that come up in filters and mappers. So now, >> we also need to document that you cannot modify the object after >> UpdateInformation() (including calling any Set methods) for this to work. >> >> Here is the change I'd like to make: >> >> * Deprecate all of the SetUpdateXXX() methods. >> * Add arguments to Update() that allows passing of requests >> >> So the first example would look like: >> >> int updateExtent[6] = {0, 10, 0, 10, 1, 1}; >> anAlgorithm->UpdateTimeStep(0.5, 0, 2, 0, updateExtent); >> >> There are signatures for: >> >> Update(int piece, int numPieces, int ghostLevel); >> Update(int piece, int numPieces, int ghostLevel, int* updateExtent); >> UpdateTimeStep(double time); >> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel); >> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel, >> int* updateExtent); >> >> There is also a more flexible method with this signature: >> >> Update(vtkInformation* requests); >> >> This allows assigning any arbitrary number of requests for the update >> pass. For example: >> >> vtkNew info; >> info->Set(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP(), 0.5); >> anAlgorithm->Update(info.GetPointer()); >> >> Finally, it is still possible to do the "updateInfo -> set request -> >> update" thing like this: >> >> int updateExtent[6] = {0, 10, 0, 10, 1, 1}; >> anAlgorithm->UpdateInformation(); >> vtkInformation* outInfo = anAlgorithm->GetOutputInformation(0); >> outInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(), >> updateExtent); >> // Don't modify the object after this >> anAlgorithm->Update(); >> >> This is the advanced use case. >> >> Here is the branch that passes all of the tests: >> >> https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change >> >> It is WIP because I need to add some better documentation. >> >> What do you think? >> -berk >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Jan 16 13:36:41 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 16 Jan 2016 13:36:41 -0500 Subject: [vtk-developers] New Defects reported by Coverity Scan for VTK Message-ID: These covertity defects have been fixed in cmake 3 by this commit: https://cmake.org/gitweb?p=cmake.git;a=commit;h=7eddefd8f1375c5c6f2fbe6e0e51f14bdc1f8886 Could someone doing the coverity runs, please use cmake3? ---------- Forwarded message ---------- From: Date: Fri, Jan 15, 2016 at 3:20 AM Subject: New Defects reported by Coverity Scan for VTK To: bill.lorensen at gmail.com Hi, Please find the latest report on new defect(s) introduced to VTK found with Coverity Scan. 80 new defect(s) introduced to VTK found with Coverity Scan. 8 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 80 defect(s) ** CID 1347735: Insecure data handling (TAINTED_SCALAR) /Filters/Modeling/Testing/Cxx/vtkFiltersModelingCxxTests.cxx: 177 in main() ________________________________________________________________________________________________________ *** CID 1347735: Insecure data handling (TAINTED_SCALAR) /Filters/Modeling/Testing/Cxx/vtkFiltersModelingCxxTests.cxx: 177 in main() 171 } 172 if(testToRun != -1) 173 { 174 int result; 175 vtksys::SystemInformation::SetStackTraceOnError(1); 176 >>> CID 1347735: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 177 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 178 179 return result; 180 } 181 182 ** CID 1347734: Insecure data handling (TAINTED_SCALAR) /Imaging/Morphological/Testing/Cxx/vtkImagingMorphologicalCxxTests.cxx: 198 in main() ________________________________________________________________________________________________________ *** CID 1347734: Insecure data handling (TAINTED_SCALAR) /Imaging/Morphological/Testing/Cxx/vtkImagingMorphologicalCxxTests.cxx: 198 in main() 192 f->Disable("vtkRenderWindowInteractor"); 193 f = collection->GetNextItem(); 194 } 195 vtkObjectFactory::RegisterFactory(factory); 196 } 197 >>> CID 1347734: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 198 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 199 200 if (!interactive) 201 { 202 if (vtkTestingInteractor::TestReturnStatus != -1) 203 { ** CID 1347733: Insecure data handling (TAINTED_SCALAR) /Filters/FlowPaths/Testing/Cxx/vtkFiltersFlowPathsCxxTests.cxx: 218 in main() ________________________________________________________________________________________________________ *** CID 1347733: Insecure data handling (TAINTED_SCALAR) /Filters/FlowPaths/Testing/Cxx/vtkFiltersFlowPathsCxxTests.cxx: 218 in main() 212 f->Disable("vtkRenderWindowInteractor"); 213 f = collection->GetNextItem(); 214 } 215 vtkObjectFactory::RegisterFactory(factory); 216 } 217 >>> CID 1347733: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 218 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 219 220 if (!interactive) 221 { 222 if (vtkTestingInteractor::TestReturnStatus != -1) 223 { ** CID 1347732: Insecure data handling (TAINTED_SCALAR) /IO/AMR/Testing/Cxx/vtkIOAMRCxxTests.cxx: 147 in main() ________________________________________________________________________________________________________ *** CID 1347732: Insecure data handling (TAINTED_SCALAR) /IO/AMR/Testing/Cxx/vtkIOAMRCxxTests.cxx: 147 in main() 141 } 142 if(testToRun != -1) 143 { 144 int result; 145 vtksys::SystemInformation::SetStackTraceOnError(1); 146 >>> CID 1347732: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 147 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 148 149 return result; 150 } 151 152 ** CID 1347731: Insecure data handling (TAINTED_SCALAR) /Rendering/Context2D/Testing/Cxx/vtkRenderingContext2DCxxTests.cxx: 147 in main() ________________________________________________________________________________________________________ *** CID 1347731: Insecure data handling (TAINTED_SCALAR) /Rendering/Context2D/Testing/Cxx/vtkRenderingContext2DCxxTests.cxx: 147 in main() 141 } 142 if(testToRun != -1) 143 { 144 int result; 145 vtksys::SystemInformation::SetStackTraceOnError(1); 146 >>> CID 1347731: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 147 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 148 149 return result; 150 } 151 152 ** CID 1347730: Insecure data handling (TAINTED_SCALAR) /Common/ExecutionModel/Testing/Cxx/vtkCommonExecutionModelCxxTests.cxx: 177 in main() ________________________________________________________________________________________________________ *** CID 1347730: Insecure data handling (TAINTED_SCALAR) /Common/ExecutionModel/Testing/Cxx/vtkCommonExecutionModelCxxTests.cxx: 177 in main() 171 } 172 if(testToRun != -1) 173 { 174 int result; 175 vtksys::SystemInformation::SetStackTraceOnError(1); 176 >>> CID 1347730: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 177 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 178 179 return result; 180 } 181 182 ** CID 1347729: Insecure data handling (TAINTED_SCALAR) /Common/System/Testing/Cxx/vtkCommonSystemCxxTests.cxx: 152 in main() ________________________________________________________________________________________________________ *** CID 1347729: Insecure data handling (TAINTED_SCALAR) /Common/System/Testing/Cxx/vtkCommonSystemCxxTests.cxx: 152 in main() 146 } 147 if(testToRun != -1) 148 { 149 int result; 150 vtksys::SystemInformation::SetStackTraceOnError(1); 151 >>> CID 1347729: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 152 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 153 154 return result; 155 } 156 157 ** CID 1347728: Insecure data handling (TAINTED_SCALAR) /IO/PLY/Testing/Cxx/vtkIOPLYCxxTests.cxx: 157 in main() ________________________________________________________________________________________________________ *** CID 1347728: Insecure data handling (TAINTED_SCALAR) /IO/PLY/Testing/Cxx/vtkIOPLYCxxTests.cxx: 157 in main() 151 } 152 if(testToRun != -1) 153 { 154 int result; 155 vtksys::SystemInformation::SetStackTraceOnError(1); 156 >>> CID 1347728: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 157 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 158 159 return result; 160 } 161 162 ** CID 1347727: Insecure data handling (TAINTED_SCALAR) /Rendering/LOD/Testing/Cxx/vtkRenderingLODCxxTests.cxx: 147 in main() ________________________________________________________________________________________________________ *** CID 1347727: Insecure data handling (TAINTED_SCALAR) /Rendering/LOD/Testing/Cxx/vtkRenderingLODCxxTests.cxx: 147 in main() 141 } 142 if(testToRun != -1) 143 { 144 int result; 145 vtksys::SystemInformation::SetStackTraceOnError(1); 146 >>> CID 1347727: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 147 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 148 149 return result; 150 } 151 152 ** CID 1347726: Insecure data handling (TAINTED_SCALAR) /Rendering/FreeType/Testing/Cxx/vtkRenderingFreeTypeCxxTests.cxx: 253 in main() ________________________________________________________________________________________________________ *** CID 1347726: Insecure data handling (TAINTED_SCALAR) /Rendering/FreeType/Testing/Cxx/vtkRenderingFreeTypeCxxTests.cxx: 253 in main() 247 f->Disable("vtkRenderWindowInteractor"); 248 f = collection->GetNextItem(); 249 } 250 vtkObjectFactory::RegisterFactory(factory); 251 } 252 >>> CID 1347726: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 253 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 254 255 if (!interactive) 256 { 257 if (vtkTestingInteractor::TestReturnStatus != -1) 258 { ** CID 1347725: Insecure data handling (TAINTED_SCALAR) /Rendering/OpenGL2/Testing/Cxx/vtkRenderingOpenGL2CxxTests.cxx: 303 in main() ________________________________________________________________________________________________________ *** CID 1347725: Insecure data handling (TAINTED_SCALAR) /Rendering/OpenGL2/Testing/Cxx/vtkRenderingOpenGL2CxxTests.cxx: 303 in main() 297 f->Disable("vtkRenderWindowInteractor"); 298 f = collection->GetNextItem(); 299 } 300 vtkObjectFactory::RegisterFactory(factory); 301 } 302 >>> CID 1347725: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 303 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 304 305 if (!interactive) 306 { 307 if (vtkTestingInteractor::TestReturnStatus != -1) 308 { ** CID 1347724: Insecure data handling (TAINTED_SCALAR) /Filters/Verdict/Testing/Cxx/vtkFiltersVerdictCxxTests.cxx: 147 in main() ________________________________________________________________________________________________________ *** CID 1347724: Insecure data handling (TAINTED_SCALAR) /Filters/Verdict/Testing/Cxx/vtkFiltersVerdictCxxTests.cxx: 147 in main() 141 } 142 if(testToRun != -1) 143 { 144 int result; 145 vtksys::SystemInformation::SetStackTraceOnError(1); 146 >>> CID 1347724: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 147 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 148 149 return result; 150 } 151 152 ** CID 1347723: Insecure data handling (TAINTED_SCALAR) /Rendering/Annotation/Testing/Cxx/vtkRenderingAnnotationCxxTests.cxx: 353 in main() ________________________________________________________________________________________________________ *** CID 1347723: Insecure data handling (TAINTED_SCALAR) /Rendering/Annotation/Testing/Cxx/vtkRenderingAnnotationCxxTests.cxx: 353 in main() 347 f->Disable("vtkRenderWindowInteractor"); 348 f = collection->GetNextItem(); 349 } 350 vtkObjectFactory::RegisterFactory(factory); 351 } 352 >>> CID 1347723: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 353 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 354 355 if (!interactive) 356 { 357 if (vtkTestingInteractor::TestReturnStatus != -1) 358 { ** CID 1347722: Insecure data handling (TAINTED_SCALAR) /Filters/Extraction/Testing/Cxx/vtkFiltersExtractionCxxTests.cxx: 162 in main() ________________________________________________________________________________________________________ *** CID 1347722: Insecure data handling (TAINTED_SCALAR) /Filters/Extraction/Testing/Cxx/vtkFiltersExtractionCxxTests.cxx: 162 in main() 156 } 157 if(testToRun != -1) 158 { 159 int result; 160 vtksys::SystemInformation::SetStackTraceOnError(1); 161 >>> CID 1347722: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 162 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 163 164 return result; 165 } 166 167 ** CID 1347721: Insecure data handling (TAINTED_SCALAR) /Filters/Geometry/Testing/Cxx/vtkFiltersGeometryCxxTests.cxx: 197 in main() ________________________________________________________________________________________________________ *** CID 1347721: Insecure data handling (TAINTED_SCALAR) /Filters/Geometry/Testing/Cxx/vtkFiltersGeometryCxxTests.cxx: 197 in main() 191 } 192 if(testToRun != -1) 193 { 194 int result; 195 vtksys::SystemInformation::SetStackTraceOnError(1); 196 >>> CID 1347721: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 197 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 198 199 return result; 200 } 201 202 ** CID 1347720: Insecure data handling (TAINTED_SCALAR) /Parallel/Core/Testing/Cxx/vtkParallelCoreCxxTests.cxx: 147 in main() ________________________________________________________________________________________________________ *** CID 1347720: Insecure data handling (TAINTED_SCALAR) /Parallel/Core/Testing/Cxx/vtkParallelCoreCxxTests.cxx: 147 in main() 141 } 142 if(testToRun != -1) 143 { 144 int result; 145 vtksys::SystemInformation::SetStackTraceOnError(1); 146 >>> CID 1347720: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 147 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 148 149 return result; 150 } 151 152 ** CID 1347719: Insecure data handling (TAINTED_SCALAR) /Filters/Sources/Testing/Cxx/vtkFiltersSourcesCxxTests.cxx: 267 in main() ________________________________________________________________________________________________________ *** CID 1347719: Insecure data handling (TAINTED_SCALAR) /Filters/Sources/Testing/Cxx/vtkFiltersSourcesCxxTests.cxx: 267 in main() 261 } 262 if(testToRun != -1) 263 { 264 int result; 265 vtksys::SystemInformation::SetStackTraceOnError(1); 266 >>> CID 1347719: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 267 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 268 269 return result; 270 } 271 272 ** CID 1347718: Insecure data handling (TAINTED_SCALAR) /IO/SQL/Testing/Cxx/vtkIOSQLCxxTests.cxx: 157 in main() ________________________________________________________________________________________________________ *** CID 1347718: Insecure data handling (TAINTED_SCALAR) /IO/SQL/Testing/Cxx/vtkIOSQLCxxTests.cxx: 157 in main() 151 } 152 if(testToRun != -1) 153 { 154 int result; 155 vtksys::SystemInformation::SetStackTraceOnError(1); 156 >>> CID 1347718: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 157 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 158 159 return result; 160 } 161 162 ** CID 1347717: Insecure data handling (TAINTED_SCALAR) /Filters/AMR/Testing/Cxx/vtkFiltersAMRCxxTests.cxx: 162 in main() ________________________________________________________________________________________________________ *** CID 1347717: Insecure data handling (TAINTED_SCALAR) /Filters/AMR/Testing/Cxx/vtkFiltersAMRCxxTests.cxx: 162 in main() 156 } 157 if(testToRun != -1) 158 { 159 int result; 160 vtksys::SystemInformation::SetStackTraceOnError(1); 161 >>> CID 1347717: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 162 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 163 164 return result; 165 } 166 167 ** CID 1347716: Insecure data handling (TAINTED_SCALAR) /Filters/Statistics/Testing/Cxx/vtkFiltersStatisticsCxxTests.cxx: 197 in main() ________________________________________________________________________________________________________ *** CID 1347716: Insecure data handling (TAINTED_SCALAR) /Filters/Statistics/Testing/Cxx/vtkFiltersStatisticsCxxTests.cxx: 197 in main() 191 } 192 if(testToRun != -1) 193 { 194 int result; 195 vtksys::SystemInformation::SetStackTraceOnError(1); 196 >>> CID 1347716: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "testToRun" as an index into an array "cmakeGeneratedFunctionMapEntries". 197 result = (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); 198 199 return result; 200 } 201 202 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/vtk?tab=overview To manage Coverity Scan email notifications for "bill.lorensen at gmail.com", click https://scan.coverity.com/subscriptions/edit?email=bill.lorensen%40gmail.com&token=b58f4f57369f044961872c7f33d48117 -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Mon Jan 18 09:56:41 2016 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 18 Jan 2016 09:56:41 -0500 Subject: [vtk-developers] New Defects reported by Coverity Scan for VTK In-Reply-To: References: Message-ID: Oops, that's me. I'll upgrade the cmake on that system :-) On Sat, Jan 16, 2016 at 1:36 PM, Bill Lorensen wrote: > These covertity defects have been fixed in cmake 3 by this commit: > > https://cmake.org/gitweb?p=cmake.git;a=commit;h=7eddefd8f1375c5c6f2fbe6e0e51f14bdc1f8886 > > Could someone doing the coverity runs, please use cmake3? > > > ---------- Forwarded message ---------- > From: > Date: Fri, Jan 15, 2016 at 3:20 AM > Subject: New Defects reported by Coverity Scan for VTK > To: bill.lorensen at gmail.com > > > > Hi, > > Please find the latest report on new defect(s) introduced to VTK found > with Coverity Scan. > > 80 new defect(s) introduced to VTK found with Coverity Scan. > 8 defect(s), reported by Coverity Scan earlier, were marked fixed in > the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 20 of 80 defect(s) > > > ** CID 1347735: Insecure data handling (TAINTED_SCALAR) > /Filters/Modeling/Testing/Cxx/vtkFiltersModelingCxxTests.cxx: 177 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347735: Insecure data handling (TAINTED_SCALAR) > /Filters/Modeling/Testing/Cxx/vtkFiltersModelingCxxTests.cxx: 177 in main() > 171 } > 172 if(testToRun != -1) > 173 { > 174 int result; > 175 vtksys::SystemInformation::SetStackTraceOnError(1); > 176 > >>> CID 1347735: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 177 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 178 > 179 return result; > 180 } > 181 > 182 > > ** CID 1347734: Insecure data handling (TAINTED_SCALAR) > /Imaging/Morphological/Testing/Cxx/vtkImagingMorphologicalCxxTests.cxx: > 198 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347734: Insecure data handling (TAINTED_SCALAR) > /Imaging/Morphological/Testing/Cxx/vtkImagingMorphologicalCxxTests.cxx: > 198 in main() > 192 f->Disable("vtkRenderWindowInteractor"); > 193 f = collection->GetNextItem(); > 194 } > 195 vtkObjectFactory::RegisterFactory(factory); > 196 } > 197 > >>> CID 1347734: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 198 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 199 > 200 if (!interactive) > 201 { > 202 if (vtkTestingInteractor::TestReturnStatus != -1) > 203 { > > ** CID 1347733: Insecure data handling (TAINTED_SCALAR) > /Filters/FlowPaths/Testing/Cxx/vtkFiltersFlowPathsCxxTests.cxx: 218 in > main() > > > > ________________________________________________________________________________________________________ > *** CID 1347733: Insecure data handling (TAINTED_SCALAR) > /Filters/FlowPaths/Testing/Cxx/vtkFiltersFlowPathsCxxTests.cxx: 218 in > main() > 212 f->Disable("vtkRenderWindowInteractor"); > 213 f = collection->GetNextItem(); > 214 } > 215 vtkObjectFactory::RegisterFactory(factory); > 216 } > 217 > >>> CID 1347733: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 218 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 219 > 220 if (!interactive) > 221 { > 222 if (vtkTestingInteractor::TestReturnStatus != -1) > 223 { > > ** CID 1347732: Insecure data handling (TAINTED_SCALAR) > /IO/AMR/Testing/Cxx/vtkIOAMRCxxTests.cxx: 147 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347732: Insecure data handling (TAINTED_SCALAR) > /IO/AMR/Testing/Cxx/vtkIOAMRCxxTests.cxx: 147 in main() > 141 } > 142 if(testToRun != -1) > 143 { > 144 int result; > 145 vtksys::SystemInformation::SetStackTraceOnError(1); > 146 > >>> CID 1347732: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 147 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 148 > 149 return result; > 150 } > 151 > 152 > > ** CID 1347731: Insecure data handling (TAINTED_SCALAR) > /Rendering/Context2D/Testing/Cxx/vtkRenderingContext2DCxxTests.cxx: > 147 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347731: Insecure data handling (TAINTED_SCALAR) > /Rendering/Context2D/Testing/Cxx/vtkRenderingContext2DCxxTests.cxx: > 147 in main() > 141 } > 142 if(testToRun != -1) > 143 { > 144 int result; > 145 vtksys::SystemInformation::SetStackTraceOnError(1); > 146 > >>> CID 1347731: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 147 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 148 > 149 return result; > 150 } > 151 > 152 > > ** CID 1347730: Insecure data handling (TAINTED_SCALAR) > /Common/ExecutionModel/Testing/Cxx/vtkCommonExecutionModelCxxTests.cxx: > 177 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347730: Insecure data handling (TAINTED_SCALAR) > /Common/ExecutionModel/Testing/Cxx/vtkCommonExecutionModelCxxTests.cxx: > 177 in main() > 171 } > 172 if(testToRun != -1) > 173 { > 174 int result; > 175 vtksys::SystemInformation::SetStackTraceOnError(1); > 176 > >>> CID 1347730: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 177 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 178 > 179 return result; > 180 } > 181 > 182 > > ** CID 1347729: Insecure data handling (TAINTED_SCALAR) > /Common/System/Testing/Cxx/vtkCommonSystemCxxTests.cxx: 152 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347729: Insecure data handling (TAINTED_SCALAR) > /Common/System/Testing/Cxx/vtkCommonSystemCxxTests.cxx: 152 in main() > 146 } > 147 if(testToRun != -1) > 148 { > 149 int result; > 150 vtksys::SystemInformation::SetStackTraceOnError(1); > 151 > >>> CID 1347729: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 152 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 153 > 154 return result; > 155 } > 156 > 157 > > ** CID 1347728: Insecure data handling (TAINTED_SCALAR) > /IO/PLY/Testing/Cxx/vtkIOPLYCxxTests.cxx: 157 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347728: Insecure data handling (TAINTED_SCALAR) > /IO/PLY/Testing/Cxx/vtkIOPLYCxxTests.cxx: 157 in main() > 151 } > 152 if(testToRun != -1) > 153 { > 154 int result; > 155 vtksys::SystemInformation::SetStackTraceOnError(1); > 156 > >>> CID 1347728: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 157 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 158 > 159 return result; > 160 } > 161 > 162 > > ** CID 1347727: Insecure data handling (TAINTED_SCALAR) > /Rendering/LOD/Testing/Cxx/vtkRenderingLODCxxTests.cxx: 147 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347727: Insecure data handling (TAINTED_SCALAR) > /Rendering/LOD/Testing/Cxx/vtkRenderingLODCxxTests.cxx: 147 in main() > 141 } > 142 if(testToRun != -1) > 143 { > 144 int result; > 145 vtksys::SystemInformation::SetStackTraceOnError(1); > 146 > >>> CID 1347727: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 147 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 148 > 149 return result; > 150 } > 151 > 152 > > ** CID 1347726: Insecure data handling (TAINTED_SCALAR) > /Rendering/FreeType/Testing/Cxx/vtkRenderingFreeTypeCxxTests.cxx: 253 in > main() > > > > ________________________________________________________________________________________________________ > *** CID 1347726: Insecure data handling (TAINTED_SCALAR) > /Rendering/FreeType/Testing/Cxx/vtkRenderingFreeTypeCxxTests.cxx: 253 in > main() > 247 f->Disable("vtkRenderWindowInteractor"); > 248 f = collection->GetNextItem(); > 249 } > 250 vtkObjectFactory::RegisterFactory(factory); > 251 } > 252 > >>> CID 1347726: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 253 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 254 > 255 if (!interactive) > 256 { > 257 if (vtkTestingInteractor::TestReturnStatus != -1) > 258 { > > ** CID 1347725: Insecure data handling (TAINTED_SCALAR) > /Rendering/OpenGL2/Testing/Cxx/vtkRenderingOpenGL2CxxTests.cxx: 303 in > main() > > > > ________________________________________________________________________________________________________ > *** CID 1347725: Insecure data handling (TAINTED_SCALAR) > /Rendering/OpenGL2/Testing/Cxx/vtkRenderingOpenGL2CxxTests.cxx: 303 in > main() > 297 f->Disable("vtkRenderWindowInteractor"); > 298 f = collection->GetNextItem(); > 299 } > 300 vtkObjectFactory::RegisterFactory(factory); > 301 } > 302 > >>> CID 1347725: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 303 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 304 > 305 if (!interactive) > 306 { > 307 if (vtkTestingInteractor::TestReturnStatus != -1) > 308 { > > ** CID 1347724: Insecure data handling (TAINTED_SCALAR) > /Filters/Verdict/Testing/Cxx/vtkFiltersVerdictCxxTests.cxx: 147 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347724: Insecure data handling (TAINTED_SCALAR) > /Filters/Verdict/Testing/Cxx/vtkFiltersVerdictCxxTests.cxx: 147 in main() > 141 } > 142 if(testToRun != -1) > 143 { > 144 int result; > 145 vtksys::SystemInformation::SetStackTraceOnError(1); > 146 > >>> CID 1347724: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 147 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 148 > 149 return result; > 150 } > 151 > 152 > > ** CID 1347723: Insecure data handling (TAINTED_SCALAR) > /Rendering/Annotation/Testing/Cxx/vtkRenderingAnnotationCxxTests.cxx: > 353 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347723: Insecure data handling (TAINTED_SCALAR) > /Rendering/Annotation/Testing/Cxx/vtkRenderingAnnotationCxxTests.cxx: > 353 in main() > 347 f->Disable("vtkRenderWindowInteractor"); > 348 f = collection->GetNextItem(); > 349 } > 350 vtkObjectFactory::RegisterFactory(factory); > 351 } > 352 > >>> CID 1347723: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 353 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 354 > 355 if (!interactive) > 356 { > 357 if (vtkTestingInteractor::TestReturnStatus != -1) > 358 { > > ** CID 1347722: Insecure data handling (TAINTED_SCALAR) > /Filters/Extraction/Testing/Cxx/vtkFiltersExtractionCxxTests.cxx: 162 in > main() > > > > ________________________________________________________________________________________________________ > *** CID 1347722: Insecure data handling (TAINTED_SCALAR) > /Filters/Extraction/Testing/Cxx/vtkFiltersExtractionCxxTests.cxx: 162 in > main() > 156 } > 157 if(testToRun != -1) > 158 { > 159 int result; > 160 vtksys::SystemInformation::SetStackTraceOnError(1); > 161 > >>> CID 1347722: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 162 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 163 > 164 return result; > 165 } > 166 > 167 > > ** CID 1347721: Insecure data handling (TAINTED_SCALAR) > /Filters/Geometry/Testing/Cxx/vtkFiltersGeometryCxxTests.cxx: 197 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347721: Insecure data handling (TAINTED_SCALAR) > /Filters/Geometry/Testing/Cxx/vtkFiltersGeometryCxxTests.cxx: 197 in main() > 191 } > 192 if(testToRun != -1) > 193 { > 194 int result; > 195 vtksys::SystemInformation::SetStackTraceOnError(1); > 196 > >>> CID 1347721: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 197 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 198 > 199 return result; > 200 } > 201 > 202 > > ** CID 1347720: Insecure data handling (TAINTED_SCALAR) > /Parallel/Core/Testing/Cxx/vtkParallelCoreCxxTests.cxx: 147 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347720: Insecure data handling (TAINTED_SCALAR) > /Parallel/Core/Testing/Cxx/vtkParallelCoreCxxTests.cxx: 147 in main() > 141 } > 142 if(testToRun != -1) > 143 { > 144 int result; > 145 vtksys::SystemInformation::SetStackTraceOnError(1); > 146 > >>> CID 1347720: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 147 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 148 > 149 return result; > 150 } > 151 > 152 > > ** CID 1347719: Insecure data handling (TAINTED_SCALAR) > /Filters/Sources/Testing/Cxx/vtkFiltersSourcesCxxTests.cxx: 267 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347719: Insecure data handling (TAINTED_SCALAR) > /Filters/Sources/Testing/Cxx/vtkFiltersSourcesCxxTests.cxx: 267 in main() > 261 } > 262 if(testToRun != -1) > 263 { > 264 int result; > 265 vtksys::SystemInformation::SetStackTraceOnError(1); > 266 > >>> CID 1347719: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 267 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 268 > 269 return result; > 270 } > 271 > 272 > > ** CID 1347718: Insecure data handling (TAINTED_SCALAR) > /IO/SQL/Testing/Cxx/vtkIOSQLCxxTests.cxx: 157 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347718: Insecure data handling (TAINTED_SCALAR) > /IO/SQL/Testing/Cxx/vtkIOSQLCxxTests.cxx: 157 in main() > 151 } > 152 if(testToRun != -1) > 153 { > 154 int result; > 155 vtksys::SystemInformation::SetStackTraceOnError(1); > 156 > >>> CID 1347718: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 157 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 158 > 159 return result; > 160 } > 161 > 162 > > ** CID 1347717: Insecure data handling (TAINTED_SCALAR) > /Filters/AMR/Testing/Cxx/vtkFiltersAMRCxxTests.cxx: 162 in main() > > > > ________________________________________________________________________________________________________ > *** CID 1347717: Insecure data handling (TAINTED_SCALAR) > /Filters/AMR/Testing/Cxx/vtkFiltersAMRCxxTests.cxx: 162 in main() > 156 } > 157 if(testToRun != -1) > 158 { > 159 int result; > 160 vtksys::SystemInformation::SetStackTraceOnError(1); > 161 > >>> CID 1347717: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 162 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 163 > 164 return result; > 165 } > 166 > 167 > > ** CID 1347716: Insecure data handling (TAINTED_SCALAR) > /Filters/Statistics/Testing/Cxx/vtkFiltersStatisticsCxxTests.cxx: 197 in > main() > > > > ________________________________________________________________________________________________________ > *** CID 1347716: Insecure data handling (TAINTED_SCALAR) > /Filters/Statistics/Testing/Cxx/vtkFiltersStatisticsCxxTests.cxx: 197 in > main() > 191 } > 192 if(testToRun != -1) > 193 { > 194 int result; > 195 vtksys::SystemInformation::SetStackTraceOnError(1); > 196 > >>> CID 1347716: Insecure data handling (TAINTED_SCALAR) > >>> Using tainted variable "testToRun" as an index into an array > "cmakeGeneratedFunctionMapEntries". > 197 result = > (*cmakeGeneratedFunctionMapEntries[testToRun].func)(ac, av); > 198 > 199 return result; > 200 } > 201 > 202 > > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, > https://scan.coverity.com/projects/vtk?tab=overview > > To manage Coverity Scan email notifications for > "bill.lorensen at gmail.com", click > > https://scan.coverity.com/subscriptions/edit?email=bill.lorensen%40gmail.com&token=b58f4f57369f044961872c7f33d48117 > > > > -- > 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 david.gobbi at gmail.com Wed Jan 20 08:15:53 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 20 Jan 2016 06:15:53 -0700 Subject: [vtk-developers] Third-party zlib Message-ID: Hi Ben, There is a symbol leakage bug in zlib that I want to fix for vtk 7.0.0: http://www.vtk.org/Bug/view.php?id=15935 However, there was a zlib third-party merge past the vtk 7 branch point: https://gitlab.kitware.com/vtk/vtk/merge_requests/1066 What's the best solution here? Should I do the fix via the usual third-party method (which will place it after the merge mentioned above, and therefore after the vtk 7 branch point), and then backport it to the release branch? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jan 20 09:25:03 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 20 Jan 2016 09:25:03 -0500 Subject: [vtk-developers] Third-party zlib In-Reply-To: References: Message-ID: <20160120142503.GC6005@megas.kitware.com> On Wed, Jan 20, 2016 at 06:15:53 -0700, David Gobbi wrote: > There is a symbol leakage bug in zlib that I want to fix for vtk 7.0.0: > > http://www.vtk.org/Bug/view.php?id=15935 > > However, there was a zlib third-party merge past the vtk 7 branch point: > > https://gitlab.kitware.com/vtk/vtk/merge_requests/1066 > > What's the best solution here? Should I do the fix via the usual > third-party method (which will place it after the merge mentioned above, > and therefore after the vtk 7 branch point), and then backport it to the > release branch? On release, this appears to work to sync it up with master's update: git cherry-pick -m1 71cdee4827de30075d8942a178aa32ab7f692470 Since it's a merge, we only need to do this for the last update done on master to get all relevant changes. See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1101 --Ben From schuyler.kylstra at kitware.com Wed Jan 20 14:42:50 2016 From: schuyler.kylstra at kitware.com (Schuyler Kylstra) Date: Wed, 20 Jan 2016 14:42:50 -0500 Subject: [vtk-developers] bounding box issue Message-ID: Hi all, I'm currently working on a migration from vtk 5.10 to vtk 6.3 and I'm running into a weird bounding box issue. Has anyone run into an issue with vtkOBBTree or was the functionality of vtkOBBTree::ComputeOBB() changed intentionally? Thanks for the help. -- Schuyler Kylstra -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.dean at decisionsciencescorp.com Wed Jan 20 19:11:56 2016 From: kevin.dean at decisionsciencescorp.com (Dean, Kevin) Date: Wed, 20 Jan 2016 16:11:56 -0800 Subject: [vtk-developers] Redefining Image Data Voxel Size Message-ID: I want to combine the volume of voxel spacings (3,3,3) into (15,15,15). Is there a way to merge voxel data together to form larger voxels? Thanks. Kevin E. Dean -- This email and its contents are confidential. If you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please report the error to the sender by return email and delete this communication from your records. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Wed Jan 20 20:46:36 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Wed, 20 Jan 2016 20:46:36 -0500 Subject: [vtk-developers] Redefining Image Data Voxel Size In-Reply-To: References: Message-ID: I am not aware of any but I have cc'd vtk-users mailing list. May be someone else knows it. Thanks, On Wed, Jan 20, 2016 at 7:11 PM, Dean, Kevin < kevin.dean at decisionsciencescorp.com> wrote: > I want to combine the volume of voxel spacings (3,3,3) into (15,15,15). Is > there a way to merge voxel data together to form larger voxels? Thanks. > > Kevin E. Dean > > This email and its contents are confidential. If you are not the intended > recipient, please do not disclose or use the information within this email > or its attachments. If you have received this email in error, please report > the error to the sender by return email and delete this communication from > your records. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From akash.basabhat at gmail.com Thu Jan 21 08:55:30 2016 From: akash.basabhat at gmail.com (Akash B) Date: Thu, 21 Jan 2016 19:25:30 +0530 Subject: [vtk-developers] Redefining Image Data Voxel Size In-Reply-To: References: Message-ID: Hi all, I'm interested in contributing to VTK. I'm comfortable with C++, C++11, Python and Java. I'd like some guidance as to how to contribute to VTK. Regards, Akash PB On Thu, Jan 21, 2016 at 5:41 AM, Dean, Kevin < kevin.dean at decisionsciencescorp.com> wrote: > I want to combine the volume of voxel spacings (3,3,3) into (15,15,15). Is > there a way to merge voxel data together to form larger voxels? Thanks. > > Kevin E. Dean > > This email and its contents are confidential. If you are not the intended > recipient, please do not disclose or use the information within this email > or its attachments. If you have received this email in error, please report > the error to the sender by return email and delete this communication from > your records. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Jan 21 12:29:34 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 21 Jan 2016 10:29:34 -0700 Subject: [vtk-developers] Interesting imaging pipeline information bug Message-ID: Hi All, I was looking through the bugtracker this morning (I know, I shouldn't do that :-) and found an interesting one: http://www.vtk.org/Bug/view.php?id=15901 Basic issue is that most VTK image algorithms do this: double spacing[3], origin[3]; inputInfo->Get(vtkDataObject::ORIGIN(), origin); inputInfo->Get(vtkDataObject::SPACING(), spacing); This seems to have worked fine in VTK 5, but in VTK 6, is there any guarantee that the pipeline will have ORIGIN and SPACING for vtkImageData? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Jan 21 12:50:34 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 21 Jan 2016 12:50:34 -0500 Subject: [vtk-developers] Interesting imaging pipeline information bug In-Reply-To: References: Message-ID: Interesting. This probably sort-of worked previously because the pipeline called vtkImageData::CopyInformationToPipeline() at some point. I am saying sort-of because the pipeline could still have the wrong information at certain stages. In theory, these keys are supposed to be available during RequestInformation(). Otherwise, one can simply used origin and spacing from vtkImageData. The only way for these to be there during RequestInformation() is if the source/filters provided it. So if the source didn't provide it, you would end up with default values during RequestInformation and correct but redundant data during RequestData. Since the pipeline only very partially supports these, I would like to get rid of them OR make them optional. Optional being that filters should check for their existence and not assume they will be always available. Best, -berk On Thu, Jan 21, 2016 at 12:29 PM, David Gobbi wrote: > Hi All, > > I was looking through the bugtracker this morning (I know, I shouldn't do > that :-) > and found an interesting one: > > http://www.vtk.org/Bug/view.php?id=15901 > > Basic issue is that most VTK image algorithms do this: > > double spacing[3], origin[3]; > inputInfo->Get(vtkDataObject::ORIGIN(), origin); > inputInfo->Get(vtkDataObject::SPACING(), spacing); > > This seems to have worked fine in VTK 5, but in VTK 6, is there any > guarantee > that the pipeline will have ORIGIN and SPACING for vtkImageData? > > - David > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Jan 21 13:42:31 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 21 Jan 2016 11:42:31 -0700 Subject: [vtk-developers] Interesting imaging pipeline information bug In-Reply-To: References: Message-ID: Some of the imaging filters (e.g. vtkImageReslice) need the origin and spacing in order to compute the UpdateExtent. Without this information, these filters would always have to set the UpdateExtent to the whole extent. For vtkImageReslice, for example, the ResliceTransform is expressed in spatial units (e.g millimeters) so figuring out the relationship between the output extent and the input extent requires that the origin and spacing are known. So it seems that the solution is as follows, at least for vtkImageReslice: 1) if SPACING and ORIGIN are not available, then they are not passed downstream (pretty obvious that injecting bogus information into the pipeline is bad). 2) also, if they are not available, then the UPDATE_EXTENT required for proper streaming cannot be computed, so the input update extent would have to be set to the whole extent. Also, for some filters, the origin and spacing are used to compute the output extent if the caller doesn't set the output extent explicitly. Long story short: these filters can be modified so that they don't crap out when ORIGIN and SPACING are missing, but we cannot remove ORIGIN and SPACING from the pipeline completely without removing some nice features and seriously breaking backwards compatibility. Cheers, - David On Thu, Jan 21, 2016 at 10:50 AM, Berk Geveci wrote: > Interesting. This probably sort-of worked previously because the pipeline > called vtkImageData::CopyInformationToPipeline() at some point. I am saying > sort-of because the pipeline could still have the wrong information at > certain stages. In theory, these keys are supposed to be available during > RequestInformation(). Otherwise, one can simply used origin and spacing > from vtkImageData. The only way for these to be there during > RequestInformation() is if the source/filters provided it. So if the source > didn't provide it, you would end up with default values during > RequestInformation and correct but redundant data during RequestData. > > Since the pipeline only very partially supports these, I would like to get > rid of them OR make them optional. Optional being that filters should check > for their existence and not assume they will be always available. > > Best, > -berk > > > On Thu, Jan 21, 2016 at 12:29 PM, David Gobbi > wrote: > >> Hi All, >> >> I was looking through the bugtracker this morning (I know, I shouldn't do >> that :-) >> and found an interesting one: >> >> http://www.vtk.org/Bug/view.php?id=15901 >> >> Basic issue is that most VTK image algorithms do this: >> >> double spacing[3], origin[3]; >> inputInfo->Get(vtkDataObject::ORIGIN(), origin); >> inputInfo->Get(vtkDataObject::SPACING(), spacing); >> >> This seems to have worked fine in VTK 5, but in VTK 6, is there any >> guarantee >> that the pipeline will have ORIGIN and SPACING for vtkImageData? >> >> - David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Jan 21 14:41:16 2016 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 21 Jan 2016 14:41:16 -0500 Subject: [vtk-developers] Interesting imaging pipeline information bug In-Reply-To: References: Message-ID: Great. I agree with this approach. I would actually love to see this approach for all meta-data - request pairs. It would be a lot of work to extend it to WHOLE_EXTENT() / UPDATE_EXTENT() though. -berk On Thu, Jan 21, 2016 at 1:42 PM, David Gobbi wrote: > Some of the imaging filters (e.g. vtkImageReslice) need the origin and > spacing in order to compute the UpdateExtent. Without this information, > these filters would always have to set the UpdateExtent to the whole extent. > > For vtkImageReslice, for example, the ResliceTransform is expressed in > spatial units (e.g millimeters) so figuring out the relationship between > the output extent and the input extent requires that the origin and spacing > are known. > > So it seems that the solution is as follows, at least for vtkImageReslice: > 1) if SPACING and ORIGIN are not available, then they are not passed > downstream (pretty obvious that injecting bogus information into the > pipeline is bad). > 2) also, if they are not available, then the UPDATE_EXTENT required for > proper streaming cannot be computed, so the input update extent would have > to be set to the whole extent. > > Also, for some filters, the origin and spacing are used to compute the > output extent if the caller doesn't set the output extent explicitly. > > Long story short: these filters can be modified so that they don't crap > out when ORIGIN and SPACING are missing, but we cannot remove ORIGIN and > SPACING from the pipeline completely without removing some nice features > and seriously breaking backwards compatibility. > > Cheers, > - David > > On Thu, Jan 21, 2016 at 10:50 AM, Berk Geveci > wrote: > >> Interesting. This probably sort-of worked previously because the pipeline >> called vtkImageData::CopyInformationToPipeline() at some point. I am saying >> sort-of because the pipeline could still have the wrong information at >> certain stages. In theory, these keys are supposed to be available during >> RequestInformation(). Otherwise, one can simply used origin and spacing >> from vtkImageData. The only way for these to be there during >> RequestInformation() is if the source/filters provided it. So if the source >> didn't provide it, you would end up with default values during >> RequestInformation and correct but redundant data during RequestData. >> >> Since the pipeline only very partially supports these, I would like to >> get rid of them OR make them optional. Optional being that filters should >> check for their existence and not assume they will be always available. >> >> Best, >> -berk >> >> >> On Thu, Jan 21, 2016 at 12:29 PM, David Gobbi >> wrote: >> >>> Hi All, >>> >>> I was looking through the bugtracker this morning (I know, I shouldn't >>> do that :-) >>> and found an interesting one: >>> >>> http://www.vtk.org/Bug/view.php?id=15901 >>> >>> Basic issue is that most VTK image algorithms do this: >>> >>> double spacing[3], origin[3]; >>> inputInfo->Get(vtkDataObject::ORIGIN(), origin); >>> inputInfo->Get(vtkDataObject::SPACING(), spacing); >>> >>> This seems to have worked fine in VTK 5, but in VTK 6, is there any >>> guarantee >>> that the pipeline will have ORIGIN and SPACING for vtkImageData? >>> >>> - David >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Jan 21 16:07:26 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 21 Jan 2016 14:07:26 -0700 Subject: [vtk-developers] [vtkusers] interaction problem after timer added In-Reply-To: References: <1453390163252-5736076.post@n5.nabble.com> Message-ID: I looked into this a bit more, and here's what I discovered about this bug. 1) the vtkInteractorStyle::OnTimer() method is calling Rotate(). 2) the Rotate() method checks the most recent mouse delta: int dx = rwi->GetEventPosition()[0] - rwi->GetLastEventPosition()[0]; int dy = rwi->GetEventPosition()[1] - rwi->GetLastEventPosition()[1]; 3) this delta is used to rotate the camera Even if the mouse is no longer moving, the last "delta" is nonzero, and therefore the camera is rotated whenever OnTimer() is called, even in trackball mode. Do any of the other VTK developers who are more familiar with vtkInteractorStyle want to look into this? - David On Thu, Jan 21, 2016 at 9:10 AM, David Gobbi wrote: > Hi Gary, > > I downloaded your program and confirmed your findings: if the timer > is running, then the trackball-mode rotation does not stop when the > mouse stops. > > This definitely looks like a bug in VTK itself, so I don't think there > is any way for you to fix it inside your program. > > Can you report it on the VTK bugtracker? (http://www.vtk.org/Bug) > > - David > > > On Thu, Jan 21, 2016 at 8:29 AM, gary_jia wrote: > >> Hi everyone, >> When I use the vtkInteractorStyleTrackballCamera, the object movement >> will stop when the mouse freezes ( with mouse button still down). After I >> added a timer, the object keep moving even when the mouse stop moving. >> Only >> after I release the mouse button, the movement stops. >> Could you help to tell me how to stop the movement immediately after >> the >> mouse stop even with any mouse button still down when with a timer >> running? >> >> Thank you! >> >> my code: >> >> #!/usr/bin/env python >> import vtk >> >> class vtkTimerCallback(): >> def __init__(self): >> self.timer_count = 0 >> >> def execute(self,obj,event): >> print(self.timer_count) >> self.timer_count += 1 >> >> src = vtk.vtkCubeSource() >> >> mapper = vtk.vtkPolyDataMapper() >> mapper.SetInputConnection(src.GetOutputPort()) >> >> actor = vtk.vtkActor() >> actor.SetMapper(mapper) >> >> main_render = vtk.vtkRenderer() >> main_render.AddActor(actor) >> >> renWin = vtk.vtkRenderWindow() >> renWin.AddRenderer(main_render) >> >> iren = vtk.vtkRenderWindowInteractor() >> iren.SetRenderWindow(renWin) >> iren.SetInteractorStyle(vtk.vtkInteractorStyleTrackballCamera()) >> iren.Initialize() >> >> cb = vtkTimerCallback() >> cb.actor = actor >> iren.AddObserver('TimerEvent', cb.execute) >> timerId = iren.CreateRepeatingTimer(50); >> iren.Start() >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Fri Jan 22 03:57:25 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Fri, 22 Jan 2016 01:57:25 -0700 (MST) Subject: [vtk-developers] VTK Android and integration with Android Studio In-Reply-To: <1453452924457-5736096.post@n5.nabble.com> References: <1444820224509-5734398.post@n5.nabble.com> <1453452924457-5736096.post@n5.nabble.com> Message-ID: <1453453045451-5736097.post@n5.nabble.com> Nope, not on my side. Did not manage to get it to work with android studio. I build with Cmake and ant for now. -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-Android-and-integration-with-Android-Studio-tp5734398p5736097.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Fri Jan 22 04:04:50 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Fri, 22 Jan 2016 02:04:50 -0700 (MST) Subject: [vtk-developers] VTK Android and integration with Android Studio In-Reply-To: References: <1444820224509-5734398.post@n5.nabble.com> <1453452924457-5736096.post@n5.nabble.com> <1453453045451-5736097.post@n5.nabble.com> Message-ID: <1453453490110-5736099.post@n5.nabble.com> I am not using eclipse, like I said I use CMake and make. What is your OS anyway? -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-Android-and-integration-with-Android-Studio-tp5734398p5736099.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Fri Jan 22 04:07:13 2016 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Fri, 22 Jan 2016 02:07:13 -0700 (MST) Subject: [vtk-developers] VTK Android and integration with Android Studio In-Reply-To: <1453453543192-5736100.post@n5.nabble.com> References: <1444820224509-5734398.post@n5.nabble.com> <1453452924457-5736096.post@n5.nabble.com> <1453453045451-5736097.post@n5.nabble.com> <1453453490110-5736099.post@n5.nabble.com> <1453453543192-5736100.post@n5.nabble.com> Message-ID: <3DE396EB-718A-4BED-9EE6-3B5E432F2794@gmail.com> I?m afraid I cannot help then as I?m using MacOS. Have you seen the blog post on how to build for android on windows? Best / Cordialement, Lonni Besan?on PhD Student with the AVIZ team at Inria and with the HAPCO team at Limsi/CNRS Teaching Assistant at Polytech Paris Sud and Universit? Paris Sud Address: University Paris-Saclay, Bat 660 (Digiteo) ? Office 1041 Email: lonni.besancon at gmail.com Phone: +33689902815 WebPage: http://lonni.besancon.pagesperso-orange.fr LinkedIn: fr.linkedin.com/pub/lonni-besan?on/77/552/a38/en > On 22 Jan 2016, at 10:05, Simon [via VTK] wrote: > > win7 64bit > > If you reply to this email, your message will be added to the discussion below: > http://vtk.1045678.n5.nabble.com/VTK-Android-and-integration-with-Android-Studio-tp5734398p5736100.html > To unsubscribe from VTK Android and integration with Android Studio, click here . > NAML -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-Android-and-integration-with-Android-Studio-tp5734398p5736101.html Sent from the VTK - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Fri Jan 22 07:31:15 2016 From: josp.jorge at gmail.com (Jorge Perez) Date: Fri, 22 Jan 2016 13:31:15 +0100 Subject: [vtk-developers] undefined vtkRenderingVolumeOpenGL2_AutoInit_Construct at runtime Message-ID: Hello, I'm building some libs depending on VTK. The building is based on CMake. And for one of the libs I'm getting an "undefined symbol" couldn't load file "/usr/local/vtk-gitlab/lib/tcltk/vtkTclAddOn1.0/libvtkTclAddon.so": /usr/local/vtk-gitlab/lib/tcltk/vtkTclAddOn1.0/libvtkTclAddon.so: undefined symbol: _Z44vtkRenderingVolumeOpenGL2_AutoInit_Constructv The falgs used to compile the source code (generated by cmake) are attached to this email. CMakeCache.txt is also attached. Any Idea about how to solve this problem? best regards, Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /home/jsperez/Sources/CIMNE/Builds/PCMR_ITKVTK_GIT # It was generated by CMake: /usr/local/cmake-3.4.0-Linux-x86_64/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## //No help, variable specified on the command line. BUILD_SHARED_LIBS:UNINITIALIZED=ON //The directory containing a CMake configuration file for Boost. Boost_DIR:PATH=Boost_DIR-NOTFOUND //Boost filesystem library (debug) Boost_FILESYSTEM_LIBRARY_DEBUG:FILEPATH=/usr/lib64/libboost_filesystem.so //Boost filesystem library (release) Boost_FILESYSTEM_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libboost_filesystem.so //Path to a file. Boost_INCLUDE_DIR:PATH=/usr/include //Boost library directory Boost_LIBRARY_DIR:PATH=/usr/lib64 //Boost library directory DEBUG Boost_LIBRARY_DIR_DEBUG:PATH=/usr/lib64 //Boost library directory RELEASE Boost_LIBRARY_DIR_RELEASE:PATH=/usr/lib64 //Boost system library (debug) Boost_SYSTEM_LIBRARY_DEBUG:FILEPATH=/usr/lib64/libboost_system.so //Boost system library (release) Boost_SYSTEM_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libboost_system.so //Boost thread library (debug) Boost_THREAD_LIBRARY_DEBUG:FILEPATH=/usr/lib64/libboost_thread.so //Boost thread library (release) Boost_THREAD_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libboost_thread.so //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //No help, variable specified on the command line. CMAKE_BUILD_SHARED:UNINITIALIZED=ON //No help, variable specified on the command line. CMAKE_BUILD_SHARED_LIBS:UNINITIALIZED=ON //Choose the type of build, options are: None(CMAKE_CXX_FLAGS or // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_BUILD_TYPE:STRING=Release //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //C compiler. CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Enable/Disable output of compile commands during generation. CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local //Path to a program. CMAKE_LINKER:FILEPATH=/usr/bin/ld //Path to a program. CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/gmake //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_NM:FILEPATH=/usr/bin/nm //Path to a program. CMAKE_OBJCOPY:FILEPATH=/usr/bin/objcopy //Path to a program. CMAKE_OBJDUMP:FILEPATH=/usr/bin/objdump //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=PCMR //Path to a program. CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when installing shared libraries, // but are added when building. CMAKE_SKIP_INSTALL_RPATH:BOOL=NO //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=NO //Flags used by the linker during the creation of static libraries. CMAKE_STATIC_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_STRIP:FILEPATH=/usr/bin/strip //If true, cmake will use relative paths in makefiles and projects. CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE //Path to a library. GSLCBLAS_LIBRARY:FILEPATH=/usr/lib64/libgslcblas.so //Path to a library. GSL_LIBRARY:FILEPATH=/usr/lib64/libgsl.so //No help, variable specified on the command line. INSTALL_WITH_VTK:UNINITIALIZED=1 //No help, variable specified on the command line. ITK_DIR:UNINITIALIZED=/usr/local/itk-git/lib/cmake/ITK-4.9 //Executable for running MPI programs. MPIEXEC:FILEPATH=/usr/lib64/mpich/bin/mpiexec //Maximum number of processors available to run MPI applications. MPIEXEC_MAX_NUMPROCS:STRING=2 //Flag used by MPI to specify the number of processes for MPIEXEC; // the next option will be the number of processes. MPIEXEC_NUMPROC_FLAG:STRING=-np //These flags will come after all flags given to MPIEXEC. MPIEXEC_POSTFLAGS:STRING= //These flags will be directly before the executable that is being // run by MPIEXEC. MPIEXEC_PREFLAGS:STRING= //Cleared MPI_CXX_COMPILER:FILEPATH=/usr/lib64/mpich/bin/mpicxx //MPI CXX compilation flags MPI_CXX_COMPILE_FLAGS:STRING= -fPIC //MPI CXX include path MPI_CXX_INCLUDE_PATH:STRING=/usr/include/mpich-x86_64 //MPI CXX libraries to link against MPI_CXX_LIBRARIES:STRING=/usr/lib64/mpich/lib/libmpichcxx.so;/usr/lib64/mpich/lib/libmpich.so;/usr/lib64/mpich/lib/libopa.so;/usr/lib64/mpich/lib/libmpl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so //MPI CXX linking flags MPI_CXX_LINK_FLAGS:STRING= -Wl,-z,noexecstack -Wl,-rpath -Wl,/usr/lib64/mpich/lib //Cleared MPI_C_COMPILER:FILEPATH=/usr/lib64/mpich/bin/mpicc //MPI C compilation flags MPI_C_COMPILE_FLAGS:STRING= -fPIC //MPI C include path MPI_C_INCLUDE_PATH:STRING=/usr/include/mpich-x86_64 //MPI C libraries to link against MPI_C_LIBRARIES:STRING=/usr/lib64/mpich/lib/libmpich.so;/usr/lib64/mpich/lib/libopa.so;/usr/lib64/mpich/lib/libmpl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so //MPI C linking flags MPI_C_LINK_FLAGS:STRING= -Wl,-z,noexecstack -Wl,-rpath -Wl,/usr/lib64/mpich/lib //Extra MPI libraries to link against MPI_EXTRA_LIBRARY:STRING=/usr/lib64/mpich/lib/libmpich.so;/usr/lib64/mpich/lib/libopa.so;/usr/lib64/mpich/lib/libmpl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so //MPI library to link against MPI_LIBRARY:FILEPATH=/usr/lib64/mpich/lib/libmpichcxx.so //Value Computed by CMake PCMR_BINARY_DIR:STATIC=/home/jsperez/Sources/CIMNE/Builds/PCMR_ITKVTK_GIT //Value Computed by CMake PCMR_SOURCE_DIR:STATIC=/home/jsperez/Sources/CIMNE/pcmr/trunk //subversion command line client Subversion_SVN_EXECUTABLE:FILEPATH=/usr/bin/svn //Path to a file. TCL_INCLUDE_PATH:PATH=/usr/local/tcl8.6.1/include //Path to a library. TCL_LIBRARY:FILEPATH=/usr/local/tcl8.6.1/lib/libtcl8.6.so //Path to a library. TCL_STUB_LIBRARY:FILEPATH=/usr/local/tcl8.6.1/lib/libtclstub8.6.a //Path to a program. TCL_TCLSH:FILEPATH=/usr/local/tcl8.6.1/bin/tclsh8.6 //Path to a file. TK_INCLUDE_PATH:PATH=/usr/local/tcl8.6.1/include //Path to a library. TK_LIBRARY:FILEPATH=/usr/local/tcl8.6.1/lib/libtk8.6.so //Path to a library. TK_STUB_LIBRARY:FILEPATH=/usr/local/tcl8.6.1/lib/libtkstub8.6.a //Path to a library. TTK_STUB_LIBRARY:FILEPATH=TTK_STUB_LIBRARY-NOTFOUND //study path to be used during the tests Test_Sample_Study:FILEPATH= //Use HIDDEN visibility support if available. USE_COMPILER_HIDDEN_VISIBILITY:BOOL=ON //No help, variable specified on the command line. VTK_BUILD_SHARED_LIBS:UNINITIALIZED=ON //No help, variable specified on the command line. VTK_DIR:UNINITIALIZED=/usr/local/vtk-gitlab/lib/cmake/vtk-7.1 //Path to a program. file_cmd:FILEPATH=/usr/bin/file //Dependencies for the target pcmr4DImporter_LIB_DEPENDS:STATIC=general;pcmrCommon;general;/usr/lib64/libboost_filesystem.so;general;/usr/lib64/libboost_thread.so;general;/usr/lib64/libboost_system.so; //Dependencies for the target pcmr4dtcl_LIB_DEPENDS:STATIC=general;pcmrCommon;general;pcmr4DImporter;general;pcmrDataSetReader;general;pcmrFlowComputation;general;/usr/local/tcl8.6.1/lib/libtclstub8.6.a;general;vtkCommonCoreTCL; //Dependencies for the target pcmrCommon_LIB_DEPENDS:STATIC=general;itkdouble-conversion;general;itksys;general;itkvnl_algo;general;itkvnl;general;itkv3p_netlib;general;ITKCommon;general;itkNetlibSlatec;general;ITKStatistics;general;ITKTransform;general;ITKMesh;general;itkzlib;general;ITKMetaIO;general;ITKSpatialObjects;general;ITKPath;general;ITKLabelMap;general;ITKQuadEdgeMesh;general;ITKIOImageBase;general;ITKOptimizers;general;ITKPolynomials;general;ITKBiasCorrection;general;ITKBioCell;general;ITKDICOMParser;general;ITKEXPAT;general;ITKIOXML;general;ITKIOSpatialObjects;general;ITKFEM;general;gdcmDICT;general;gdcmMSFF;general;ITKznz;general;ITKniftiio;general;ITKgiftiio;general;itkhdf5_cpp;general;itkhdf5;general;ITKIOBMP;general;ITKIOBioRad;general;ITKIOCSV;general;ITKIOGDCM;general;ITKIOIPL;general;ITKIOGE;general;ITKIOGIPL;general;ITKIOHDF5;general;itkjpeg;general;ITKIOJPEG;general;itktiff;general;ITKIOTIFF;general;ITKIOLSM;general;ITKIOMRC;general;ITKIOMesh;general;ITKIOMeta;general;ITKIONIFTI;general;ITKNrrdIO;general;ITKIONRRD;general;itkpng;general;ITKIOPNG;general;ITKIOPhilipsREC;general;ITKIOSiemens;general;ITKIOStimulate;general;ITKIOTransformBase;general;ITKIOTransformHDF5;general;ITKIOTransformInsightLegacy;general;ITKIOTransformMatlab;general;ITKIOVTK;general;ITKKLMRegionGrowing;general;ITKOptimizersv4;general;itkopenjpeg;general;ITKVTK;general;ITKWatersheds;general;ITKReview;general;ITKVideoCore;general;ITKVideoIO;general;ITKVtkGlue;general;MinimalPathExtraction; //Dependencies for the target pcmrDataSetReader_LIB_DEPENDS:STATIC=general;pcmrCommon;general;/usr/lib64/libboost_filesystem.so;general;/usr/lib64/libboost_system.so;general;vtkImagingMath;general;vtkIOMPIImage;general;/usr/lib64/mpich/lib/libmpich.so;general;/usr/lib64/mpich/lib/libopa.so;general;/usr/lib64/mpich/lib/libmpl.so;general;/usr/lib64/librt.so;general;/usr/lib64/libpthread.so;general;/usr/lib64/mpich/lib/libmpichcxx.so;general;/usr/lib64/mpich/lib/libmpich.so;general;/usr/lib64/mpich/lib/libopa.so;general;/usr/lib64/mpich/lib/libmpl.so;general;/usr/lib64/librt.so;general;/usr/lib64/libpthread.so; //Dependencies for the target pcmrFlowComputation_LIB_DEPENDS:STATIC=general;pcmrCommon;general;pcmrDataSetReader;general;pcmrNumeric;general;vtkFiltersFlowPaths;general;vtkFiltersParallelFlowPaths; //Dependencies for target pcmrGeometry_LIB_DEPENDS:STATIC= //Dependencies for the target pcmrNumeric_LIB_DEPENDS:STATIC=general;itkdouble-conversion;general;itksys;general;itkvnl_algo;general;itkvnl;general;itkv3p_netlib;general;ITKCommon;general;itkNetlibSlatec;general;ITKStatistics;general;ITKTransform;general;ITKMesh;general;itkzlib;general;ITKMetaIO;general;ITKSpatialObjects;general;ITKPath;general;ITKLabelMap;general;ITKQuadEdgeMesh;general;ITKIOImageBase;general;ITKOptimizers;general;ITKPolynomials;general;ITKBiasCorrection;general;ITKBioCell;general;ITKDICOMParser;general;ITKEXPAT;general;ITKIOXML;general;ITKIOSpatialObjects;general;ITKFEM;general;gdcmDICT;general;gdcmMSFF;general;ITKznz;general;ITKniftiio;general;ITKgiftiio;general;itkhdf5_cpp;general;itkhdf5;general;ITKIOBMP;general;ITKIOBioRad;general;ITKIOCSV;general;ITKIOGDCM;general;ITKIOIPL;general;ITKIOGE;general;ITKIOGIPL;general;ITKIOHDF5;general;itkjpeg;general;ITKIOJPEG;general;itktiff;general;ITKIOTIFF;general;ITKIOLSM;general;ITKIOMRC;general;ITKIOMesh;general;ITKIOMeta;general;ITKIONIFTI;general;ITKNrrdIO;general;ITKIONRRD;general;itkpng;general;ITKIOPNG;general;ITKIOPhilipsREC;general;ITKIOSiemens;general;ITKIOStimulate;general;ITKIOTransformBase;general;ITKIOTransformHDF5;general;ITKIOTransformInsightLegacy;general;ITKIOTransformMatlab;general;ITKIOVTK;general;ITKKLMRegionGrowing;general;ITKOptimizersv4;general;itkopenjpeg;general;ITKVTK;general;ITKWatersheds;general;ITKReview;general;ITKVideoCore;general;ITKVideoIO;general;ITKVtkGlue;general;MinimalPathExtraction; //Dependencies for the target pcmrProfileData_LIB_DEPENDS:STATIC=general;/usr/lib64/libboost_filesystem.so;general;/usr/lib64/libboost_system.so; //Dependencies for the target vtkPcmrExtTCL_LIB_DEPENDS:STATIC=general;vtkPcmrExt;general;vtkCommonCoreTCL;general;/usr/local/tcl8.6.1/lib/libtcl8.6.so;general;m;general;vtkInteractionWidgetsTCL; //Dependencies for the target vtkPcmrExt_LIB_DEPENDS:STATIC=general;vtkIOMPIImage;general;vtkInteractionWidgets;general;vtkRenderingVolumeOpenGL2; //Dependencies for the target vtkTclAddon_LIB_DEPENDS:STATIC=general;/usr/local/tcl8.6.1/lib/libtclstub8.6.a;general;vtkRenderingFreeType;general;vtkRenderingCore;general;vtkCommonColor;general;vtkCommonDataModel;general;vtkCommonMath;general;vtkCommonCore;general;vtksys;general;vtkCommonMisc;general;vtkCommonSystem;general;vtkCommonTransforms;general;vtkCommonExecutionModel;general;vtkFiltersExtraction;general;vtkFiltersCore;general;vtkFiltersGeneral;general;vtkCommonComputationalGeometry;general;vtkFiltersStatistics;general;vtkImagingFourier;general;vtkImagingCore;general;vtkalglib;general;vtkFiltersGeometry;general;vtkFiltersSources;general;vtkfreetype;general;vtkzlib;general;vtkIOImport;general;vtkIOImage;general;vtkDICOMParser;general;vtkIOCore;general;vtkmetaio;general;vtkjpeg;general;vtkpng;general;vtktiff;general;vtkInteractionImage;general;vtkInteractionStyle;general;vtkRenderingOpenGL2;general;vtkImagingColor;general;vtkInteractionWidgets;general;vtkFiltersHybrid;general;vtkImagingSources;general;vtkFiltersModeling;general;vtkImagingGeneral;general;vtkImagingHybrid;general;vtkRenderingAnnotation;general;vtkRenderingVolume;general;vtkglew;general;vtkImagingMorphological;general;vtkFiltersParallelGeometry;general;vtkParallelMPI;general;vtkParallelCore;general;vtkIOLegacy;general;vtkIOLSDyna;general;vtkIOXML;general;vtkIOGeometry;general;vtkIOXMLParser;general;vtkexpat;general;vtkImagingStencil;general;vtkFiltersParallelImaging;general;vtkFiltersImaging;general;vtkFiltersParallel;general;vtkImagingMath;general;vtkFiltersSMP;general;vtkIOExport;general;vtkRenderingContext2D;general;vtkRenderingLabel;general;vtkIONetCDF;general;vtkNetCDF;general;vtkNetCDF_cxx;general;vtkhdf5_hl;general;vtkhdf5;general;vtkViewsInfovis;general;vtkChartsCore;general;vtkInfovisCore;general;vtkInfovisLayout;general;vtkViewsCore;general;vtkIOEnSight;general;vtkIOParallel;general;vtkexoIIc;general;vtkjsoncpp;general;vtkIOVideo;general;vtkViewsContext2D;general;vtkWrappingTools;general;vtkIOSQL;general;vtksqlite;general;vtkDomainsChemistry;general;vtkIOPLY;general;vtkoggtheora;general;vtkIOParallelXML;general;vtkImagingStatistics;general;vtkIOMovie;general;vtkFiltersParallelFlowPaths;general;vtkFiltersAMR;general;vtkFiltersFlowPaths;general;vtkFiltersVerdict;general;verdict;general;vtkPcmrExt;general;vtkIOMPIImage;general;vtkRenderingVolumeOpenGL2;general;vtkFiltersParallelMPI;general;vtkFiltersSelection;general;vtkFiltersGeneric;general;vtkRenderingContextOpenGL2;general;vtkIOParallelNetCDF;general;vtkGeovisCore;general;vtkproj4;general;vtkFiltersProgrammable;general;vtkRenderingParallel;general;vtkRenderingImage;general;vtkFiltersTexture;general;vtkIOAMR;general;vtkIOInfovis;general;vtklibxml2;general;vtkDomainsChemistryOpenGL2;general;vtkIOExodus;general;vtkIOMINC;general;vtkRenderingLOD;general;vtkFiltersHyperTree;general;vtkIOMPIParallel; ######################## # INTERNAL cache entries ######################## //ADVANCED property for variable: Boost_DIR Boost_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_FILESYSTEM_LIBRARY_DEBUG Boost_FILESYSTEM_LIBRARY_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_FILESYSTEM_LIBRARY_RELEASE Boost_FILESYSTEM_LIBRARY_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_INCLUDE_DIR Boost_INCLUDE_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_LIBRARY_DIR Boost_LIBRARY_DIR-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_LIBRARY_DIR_DEBUG Boost_LIBRARY_DIR_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_LIBRARY_DIR_RELEASE Boost_LIBRARY_DIR_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_SYSTEM_LIBRARY_DEBUG Boost_SYSTEM_LIBRARY_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_SYSTEM_LIBRARY_RELEASE Boost_SYSTEM_LIBRARY_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_THREAD_LIBRARY_DEBUG Boost_THREAD_LIBRARY_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Boost_THREAD_LIBRARY_RELEASE Boost_THREAD_LIBRARY_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_AR CMAKE_AR-ADVANCED:INTERNAL=1 //What is the target build tool cmake is generating for. CMAKE_BUILD_TOOL:INTERNAL=/usr/bin/gmake //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/home/jsperez/Sources/CIMNE/Builds/PCMR_ITKVTK_GIT //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=4 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=0 //ADVANCED property for variable: CMAKE_COLOR_MAKEFILE CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/usr/local/cmake-3.4.0-Linux-x86_64/bin/cmake //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=/usr/local/cmake-3.4.0-Linux-x86_64/bin/cpack //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/usr/local/cmake-3.4.0-Linux-x86_64/bin/ctest //ADVANCED property for variable: CMAKE_CXX_COMPILER CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_COMPILER CMAKE_C_COMPILER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=/usr/local/cmake-3.4.0-Linux-x86_64/bin/ccmake //Executable file format CMAKE_EXECUTABLE_FORMAT:INTERNAL=ELF //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_EXPORT_COMPILE_COMMANDS CMAKE_EXPORT_COMPILE_COMMANDS-ADVANCED:INTERNAL=1 //Name of external makefile project generator. CMAKE_EXTRA_GENERATOR:INTERNAL= //Name of generator. CMAKE_GENERATOR:INTERNAL=Unix Makefiles //Name of generator platform. CMAKE_GENERATOR_PLATFORM:INTERNAL= //Name of generator toolset. CMAKE_GENERATOR_TOOLSET:INTERNAL= //Source directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=/home/jsperez/Sources/CIMNE/pcmr/trunk //Install .so files without execute permission. CMAKE_INSTALL_SO_NO_EXE:INTERNAL=0 //ADVANCED property for variable: CMAKE_LINKER CMAKE_LINKER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MAKE_PROGRAM CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_NM CMAKE_NM-ADVANCED:INTERNAL=1 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=22 //number of local generators CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=22 //ADVANCED property for variable: CMAKE_OBJCOPY CMAKE_OBJCOPY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_OBJDUMP CMAKE_OBJDUMP-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_RANLIB CMAKE_RANLIB-ADVANCED:INTERNAL=1 //Path to CMake installation. CMAKE_ROOT:INTERNAL=/usr/local/cmake-3.4.0-Linux-x86_64/share/cmake-3.4 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SKIP_INSTALL_RPATH CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_STRIP CMAKE_STRIP-ADVANCED:INTERNAL=1 //uname command CMAKE_UNAME:INTERNAL=/usr/bin/uname //ADVANCED property for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Compiler support for a deprecated attribute COMPILER_HAS_DEPRECATED:INTERNAL=1 //Test COMPILER_HAS_DEPRECATED_ATTR COMPILER_HAS_DEPRECATED_ATTR:INTERNAL=1 //Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY COMPILER_HAS_HIDDEN_INLINE_VISIBILITY:INTERNAL=1 //Test COMPILER_HAS_HIDDEN_VISIBILITY COMPILER_HAS_HIDDEN_VISIBILITY:INTERNAL=1 //Details about finding MPI_C FIND_PACKAGE_MESSAGE_DETAILS_MPI_C:INTERNAL=[/usr/lib64/mpich/lib/libmpich.so;/usr/lib64/mpich/lib/libopa.so;/usr/lib64/mpich/lib/libmpl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so][/usr/include/mpich-x86_64][v()] //Details about finding MPI_CXX FIND_PACKAGE_MESSAGE_DETAILS_MPI_CXX:INTERNAL=[/usr/lib64/mpich/lib/libmpichcxx.so;/usr/lib64/mpich/lib/libmpich.so;/usr/lib64/mpich/lib/libopa.so;/usr/lib64/mpich/lib/libmpl.so;/usr/lib64/librt.so;/usr/lib64/libpthread.so][/usr/include/mpich-x86_64][v()] //Details about finding Subversion FIND_PACKAGE_MESSAGE_DETAILS_Subversion:INTERNAL=[/usr/bin/svn][v1.8.11()] //Details about finding TCL FIND_PACKAGE_MESSAGE_DETAILS_TCL:INTERNAL=[/usr/local/tcl8.6.1/lib/libtcl8.6.so][/usr/local/tcl8.6.1/include][v()] //Details about finding TCLTK FIND_PACKAGE_MESSAGE_DETAILS_TCLTK:INTERNAL=[/usr/local/tcl8.6.1/lib/libtcl8.6.so][/usr/local/tcl8.6.1/include][/usr/local/tcl8.6.1/lib/libtk8.6.so][/usr/local/tcl8.6.1/include][v()] //Details about finding TK FIND_PACKAGE_MESSAGE_DETAILS_TK:INTERNAL=[/usr/local/tcl8.6.1/lib/libtk8.6.so][/usr/local/tcl8.6.1/include][v()] //Details about finding Tclsh FIND_PACKAGE_MESSAGE_DETAILS_Tclsh:INTERNAL=[/usr/local/tcl8.6.1/bin/tclsh8.6][v8.6()] //ADVANCED property for variable: MPIEXEC MPIEXEC-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPIEXEC_MAX_NUMPROCS MPIEXEC_MAX_NUMPROCS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPIEXEC_NUMPROC_FLAG MPIEXEC_NUMPROC_FLAG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPIEXEC_POSTFLAGS MPIEXEC_POSTFLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPIEXEC_PREFLAGS MPIEXEC_PREFLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_CXX_COMPILER MPI_CXX_COMPILER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_CXX_COMPILE_FLAGS MPI_CXX_COMPILE_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_CXX_INCLUDE_PATH MPI_CXX_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_CXX_LIBRARIES MPI_CXX_LIBRARIES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_CXX_LINK_FLAGS MPI_CXX_LINK_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_C_COMPILER MPI_C_COMPILER-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_C_COMPILE_FLAGS MPI_C_COMPILE_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_C_INCLUDE_PATH MPI_C_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_C_LIBRARIES MPI_C_LIBRARIES-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_C_LINK_FLAGS MPI_C_LINK_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: MPI_EXTRA_LIBRARY MPI_EXTRA_LIBRARY-ADVANCED:INTERNAL=1 //Scratch variable for MPI header detection MPI_HEADER_PATH:INTERNAL=MPI_HEADER_PATH-NOTFOUND //Scratch variable for MPI lib detection MPI_LIB:INTERNAL=MPI_LIB-NOTFOUND //ADVANCED property for variable: MPI_LIBRARY MPI_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: Subversion_SVN_EXECUTABLE Subversion_SVN_EXECUTABLE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TCL_INCLUDE_PATH TCL_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TCL_LIBRARY TCL_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TCL_STUB_LIBRARY TCL_STUB_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TCL_TCLSH TCL_TCLSH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TK_INCLUDE_PATH TK_INCLUDE_PATH-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TK_LIBRARY TK_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TK_STUB_LIBRARY TK_STUB_LIBRARY-ADVANCED:INTERNAL=1 //ADVANCED property for variable: TK_WISH TK_WISH-ADVANCED:INTERNAL=1 //This value is not used by VTK. TK_WISH:INTERNAL=/usr/local/tcl8.6.1/bin/wish8.6 //ADVANCED property for variable: USE_COMPILER_HIDDEN_VISIBILITY USE_COMPILER_HIDDEN_VISIBILITY-ADVANCED:INTERNAL=1 //Components requested for this build tree. _Boost_COMPONENTS_SEARCHED:INTERNAL=filesystem;system;thread //Last used Boost_INCLUDE_DIR value. _Boost_INCLUDE_DIR_LAST:INTERNAL=/usr/include //Last used Boost_LIBRARY_DIR_DEBUG value. _Boost_LIBRARY_DIR_DEBUG_LAST:INTERNAL=/usr/lib64 //Last used Boost_LIBRARY_DIR value. _Boost_LIBRARY_DIR_LAST:INTERNAL=/usr/lib64 //Last used Boost_LIBRARY_DIR_RELEASE value. _Boost_LIBRARY_DIR_RELEASE_LAST:INTERNAL=/usr/lib64 //Last used Boost_NAMESPACE value. _Boost_NAMESPACE_LAST:INTERNAL=boost //Last used Boost_USE_MULTITHREADED value. _Boost_USE_MULTITHREADED_LAST:INTERNAL=ON //Last used Boost_USE_STATIC_LIBS value. _Boost_USE_STATIC_LIBS_LAST:INTERNAL=OFF //Last used Boost_USE_STATIC_RUNTIME value. _Boost_USE_STATIC_RUNTIME_LAST:INTERNAL=OFF //ADVANCED property for variable: file_cmd file_cmd-ADVANCED:INTERNAL=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: flags.make Type: application/octet-stream Size: 1271 bytes Desc: not available URL: From aashish.chaudhary at kitware.com Fri Jan 22 10:17:05 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 22 Jan 2016 10:17:05 -0500 Subject: [vtk-developers] undefined vtkRenderingVolumeOpenGL2_AutoInit_Construct at runtime In-Reply-To: References: Message-ID: I have seen this problem on mobile platforms where we have to forcefully initialize this library. I will have a look. What platform is this? Please provide as much detail as possible. - Aashish On Fri, Jan 22, 2016 at 7:31 AM, Jorge Perez wrote: > Hello, I'm building some libs depending on VTK. The building is based on > CMake. > And for one of the libs I'm getting an "undefined symbol" > > couldn't load file > "/usr/local/vtk-gitlab/lib/tcltk/vtkTclAddOn1.0/libvtkTclAddon.so": > /usr/local/vtk-gitlab/lib/tcltk/vtkTclAddOn1.0/libvtkTclAddon.so: undefined > symbol: _Z44vtkRenderingVolumeOpenGL2_AutoInit_Constructv > > The falgs used to compile the source code (generated by cmake) are > attached to this email. CMakeCache.txt is also attached. > > Any Idea about how to solve this problem? > > best regards, > > Jorge > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Fri Jan 22 10:32:47 2016 From: josp.jorge at gmail.com (Jorge Perez) Date: Fri, 22 Jan 2016 16:32:47 +0100 Subject: [vtk-developers] undefined vtkRenderingVolumeOpenGL2_AutoInit_Construct at runtime In-Reply-To: References: Message-ID: Hi, attached to the first email is the CMakeCache.txt for my project. Below is information about the system set(CMAKE_HOST_SYSTEM "Linux-3.19.8-100.fc20.x86_64") set(CMAKE_HOST_SYSTEM_NAME "Linux") set(CMAKE_HOST_SYSTEM_VERSION "3.19.8-100.fc20.x86_64") set(CMAKE_HOST_SYSTEM_PROCESSOR "x86_64") set(CMAKE_SYSTEM "Linux-3.19.8-100.fc20.x86_64") set(CMAKE_SYSTEM_NAME "Linux") set(CMAKE_SYSTEM_VERSION "3.19.8-100.fc20.x86_64") set(CMAKE_SYSTEM_PROCESSOR "x86_64") set(CMAKE_CROSSCOMPILING "FALSE") set(CMAKE_SYSTEM_LOADED 1) thanks, Jorge 2016-01-22 16:17 GMT+01:00 Aashish Chaudhary : > I have seen this problem on mobile platforms where we have to forcefully > initialize this library. I will have a look. > > What platform is this? Please provide as much detail as possible. > > - Aashish > > On Fri, Jan 22, 2016 at 7:31 AM, Jorge Perez wrote: > >> Hello, I'm building some libs depending on VTK. The building is based on >> CMake. >> And for one of the libs I'm getting an "undefined symbol" >> >> couldn't load file >> "/usr/local/vtk-gitlab/lib/tcltk/vtkTclAddOn1.0/libvtkTclAddon.so": >> /usr/local/vtk-gitlab/lib/tcltk/vtkTclAddOn1.0/libvtkTclAddon.so: undefined >> symbol: _Z44vtkRenderingVolumeOpenGL2_AutoInit_Constructv >> >> The falgs used to compile the source code (generated by cmake) are >> attached to this email. CMakeCache.txt is also attached. >> >> Any Idea about how to solve this problem? >> >> best regards, >> >> Jorge >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Jan 25 06:00:18 2016 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 25 Jan 2016 12:00:18 +0100 Subject: [vtk-developers] OpenGL2/vtkOpenGLTexture.cxx signal SIGSEGV, Segmentation fault Message-ID: Hello, I have an application which is reaching a SIGSEGV when opengl backend is OpenGL2 (master branch). I have traced the error and it seems to be related to this kind of warning: Warning: Kitware/vtk.gitlab/Common/ExecutionModel/vtkAlgorithm.cxx, line 1421 vtkOpenGLTexture (0x17e1620): Attempt to get connection index 0 for input port 0, which has 0 connections. The warning appears with both OpenGL and OpenGL2 backends but with the OpenGL2 a SIGSEGV is reached. The SIGSEGV is because the member vtkOpenGLTexture::TextureObject is NULL and it can be used in: - OpenGL2/vtkOpenGLPolyDataMapper if (texture) { tNumComp = vtkOpenGLTexture::SafeDownCast(texture)-> *GetTextureObject()->*GetComponents(); } - OpenGL2/vtkOpenGL2Texture.cxx void vtkOpenGLTexture::CopyTexImage(int x, int y, int width, int height) { this->*TextureObject->*CopyFromFrameBuffer(x, y, x, y, width, height); } void vtkOpenGLTexture::PostRender(vtkRenderer *vtkNotUsed(ren)) { this->*TextureObject->*Deactivate(); } I see that within there are some pice of code which test for TextureObject and uses it if it is not NULL, but there are others which do not do the test for NULL. In order to have a quick fix I have initialized the member TextureObject to vtkTextureObject::New() instead of the value 0 (at the constructor vtkOpenGLTexture::vtkOpenGLTexture). That solved the SIGSEGV for my application but I'm not sure if this could be a the correct solution. I can submit a merge request if the change make sense. this->TextureObject = vtkTextureObject::New(); best regards, Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: From thakkar.aadi1 at gmail.com Mon Jan 25 09:29:41 2016 From: thakkar.aadi1 at gmail.com (Aaditya Thakkar) Date: Mon, 25 Jan 2016 19:59:41 +0530 Subject: [vtk-developers] seeking guidance for getting started Message-ID: Hi, I am Aaditya Thakkar. I am 2nd year undergrad Btech(ICT) student at Dhirubhai Ambani Institute for Information and Communication Technology, India. I want to contribute in VTK and also preparing for GSOC 2016. I have knowledge of C, JAVA, HTML, CSS, Javascript, PHP and Database It will be very helpful if you guide me how to get started. Please let me know about the projects in which I can contribute, it will be very helpful to me. Thanks, Aaditya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Jan 25 09:50:37 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 25 Jan 2016 09:50:37 -0500 Subject: [vtk-developers] Redefining Image Data Voxel Size In-Reply-To: References: Message-ID: Thanks Akash! Under vtk.org, find this page http://www.vtk.org/contributing-code/ which links to the current and previous contribution guides. They lay out the mechanics and reasoning behind how to get code into VTK. A one sentence summary is: make and test your changes locally, then submit a merge request so that experienced developers can review, test, and eventually merge it into VTK master. If you've got questions, ask in a different thread please. If you happen to be a student and the idea of working on a challenging problem with an experienced VTK mentor sounds fun, consider applying through the google summer of code program. cheers! On Thursday, January 21, 2016, Akash B wrote: > Hi all, > I'm interested in contributing to VTK. I'm comfortable with C++, > C++11, Python and Java. I'd like some guidance as to how to contribute to > VTK. > > Regards, > Akash PB > > On Thu, Jan 21, 2016 at 5:41 AM, Dean, Kevin < > kevin.dean at decisionsciencescorp.com> wrote: > >> I want to combine the volume of voxel spacings (3,3,3) into (15,15,15). >> Is there a way to merge voxel data together to form larger voxels? Thanks. >> >> Kevin E. Dean >> >> This email and its contents are confidential. If you are not the intended >> recipient, please do not disclose or use the information within this email >> or its attachments. If you have received this email in error, please report >> the error to the sender by return email and delete this communication from >> your records. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://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 Jan 25 10:02:58 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 25 Jan 2016 10:02:58 -0500 Subject: [vtk-developers] seeking guidance for getting started In-Reply-To: References: Message-ID: Hello Aaditya, You can find the mechanics of contributing code to VTK described under this page. http://www.vtk.org/contributing-code/ We have yet to come up with our GSOC 2016 project ideas. These ideas were not taken up by any students last year and will likely be open again. - 2.3 Computational Biology (Molecular Dynamics) In Situ Visualization - 2.4 Templated Input Generator for VTK - 2.7 Supporting Solid Model Geometry in VTK - 2.8 KiwiViewer on VTK - 2.9 OpenFOAM Catalyst adaptor - 2.12 Direct mapped Polyhedral input cells from OpenFOAM - http://www.vtk.org/Wiki/VTK/GSoC_2015#Half_Baked_Ideas thanks and good luck! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Jan 25, 2016 at 9:29 AM, Aaditya Thakkar wrote: > Hi, > I am Aaditya Thakkar. I am 2nd year undergrad Btech(ICT) student > at Dhirubhai Ambani Institute for Information and Communication Technology, > India. I want to contribute in VTK and also preparing for GSOC 2016. I > have knowledge of C, JAVA, HTML, CSS, Javascript, PHP and Database It > will be very helpful if you guide me how to get started. > Please let me know about the projects in which I can contribute, > it will be very helpful to me. > > Thanks, > Aaditya. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Jan 25 11:59:18 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 25 Jan 2016 11:59:18 -0500 Subject: [vtk-developers] [vtkusers] OpenGL2/vtkOpenGLTexture.cxx signal SIGSEGV, Segmentation fault In-Reply-To: References: Message-ID: Are you sure that the pipeline that creates the texture is not broken as said in the warning? Looks like whatever filter / pipeline you are using is not producing the data as it should. And it seems to me that we could be check for null texture object in other methods. If no one else look at it, I will push a fix. - Aashish On Mon, Jan 25, 2016 at 6:00 AM, Jorge Perez wrote: > Hello, I have an application which is reaching a SIGSEGV when opengl > backend is OpenGL2 (master branch). I have traced the error and it seems to > be related to this kind of warning: > > Warning: Kitware/vtk.gitlab/Common/ExecutionModel/vtkAlgorithm.cxx, line > 1421 > vtkOpenGLTexture (0x17e1620): Attempt to get connection index 0 for input > port 0, which has 0 connections. > > The warning appears with both OpenGL and OpenGL2 backends but with the > OpenGL2 a SIGSEGV is reached. > > The SIGSEGV is because the member vtkOpenGLTexture::TextureObject is NULL > and it can be used in: > > > - OpenGL2/vtkOpenGLPolyDataMapper > > if (texture) > { > tNumComp = > vtkOpenGLTexture::SafeDownCast(texture)-> > *GetTextureObject()->*GetComponents(); > } > > - OpenGL2/vtkOpenGL2Texture.cxx > > void vtkOpenGLTexture::CopyTexImage(int x, int y, int width, int height) > { > this->*TextureObject->*CopyFromFrameBuffer(x, y, x, y, width, height); > } > > void vtkOpenGLTexture::PostRender(vtkRenderer *vtkNotUsed(ren)) > { > this->*TextureObject->*Deactivate(); > } > > I see that within there are some pice of code which test for TextureObject > and uses it if it is not NULL, but there are others which do not do the > test for NULL. > > In order to have a quick fix I have initialized the member TextureObject > to vtkTextureObject::New() instead of the value 0 (at the constructor > vtkOpenGLTexture::vtkOpenGLTexture). That solved the SIGSEGV for my > application but I'm not sure if this could be a the correct solution. > > I can submit a merge request if the change make sense. > > this->TextureObject = vtkTextureObject::New(); > > best regards, > > Jorge > > _______________________________________________ > 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 > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From josp.jorge at gmail.com Mon Jan 25 12:38:08 2016 From: josp.jorge at gmail.com (Jorge Perez) Date: Mon, 25 Jan 2016 18:38:08 +0100 Subject: [vtk-developers] [vtkusers] OpenGL2/vtkOpenGLTexture.cxx signal SIGSEGV, Segmentation fault In-Reply-To: References: Message-ID: Hello, after investigating the pipeline (the SEGFAULT pushed me to do it) I found how to remove the warning. The pipeline which is creating the texture is internal to vtkImagePlaneWidget. I could remove the Warning by disabling the TextureVisibility until a valid ImageData is set to the vtkImagePlaneWidget. But my concern is related to the SEGFAULT, and I wonder if vtk need to check for the NULL value that I mentioned in this thread. best regards, Jorge 2016-01-25 17:59 GMT+01:00 Aashish Chaudhary : > Are you sure that the pipeline that creates the texture is not broken as > said in the warning? Looks like whatever filter / pipeline you are using is > not producing the data as it should. And it seems to me that we could be > check for null texture object in other methods. If no one else look at it, > I will push a fix. > > - Aashish > > On Mon, Jan 25, 2016 at 6:00 AM, Jorge Perez wrote: > >> Hello, I have an application which is reaching a SIGSEGV when opengl >> backend is OpenGL2 (master branch). I have traced the error and it seems to >> be related to this kind of warning: >> >> Warning: Kitware/vtk.gitlab/Common/ExecutionModel/vtkAlgorithm.cxx, line >> 1421 >> vtkOpenGLTexture (0x17e1620): Attempt to get connection index 0 for input >> port 0, which has 0 connections. >> >> The warning appears with both OpenGL and OpenGL2 backends but with the >> OpenGL2 a SIGSEGV is reached. >> >> The SIGSEGV is because the member vtkOpenGLTexture::TextureObject is NULL >> and it can be used in: >> >> >> - OpenGL2/vtkOpenGLPolyDataMapper >> >> if (texture) >> { >> tNumComp = >> vtkOpenGLTexture::SafeDownCast(texture)-> >> *GetTextureObject()->*GetComponents(); >> } >> >> - OpenGL2/vtkOpenGL2Texture.cxx >> >> void vtkOpenGLTexture::CopyTexImage(int x, int y, int width, int height) >> { >> this->*TextureObject->*CopyFromFrameBuffer(x, y, x, y, width, height); >> } >> >> void vtkOpenGLTexture::PostRender(vtkRenderer *vtkNotUsed(ren)) >> { >> this->*TextureObject->*Deactivate(); >> } >> >> I see that within there are some pice of code which test for >> TextureObject and uses it if it is not NULL, but there are others which do >> not do the test for NULL. >> >> In order to have a quick fix I have initialized the member TextureObject >> to vtkTextureObject::New() instead of the value 0 (at the constructor >> vtkOpenGLTexture::vtkOpenGLTexture). That solved the SIGSEGV for my >> application but I'm not sure if this could be a the correct solution. >> >> I can submit a merge request if the change make sense. >> >> this->TextureObject = vtkTextureObject::New(); >> >> best regards, >> >> Jorge >> >> _______________________________________________ >> 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 >> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Jan 25 12:42:20 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 25 Jan 2016 12:42:20 -0500 Subject: [vtk-developers] [vtkusers] OpenGL2/vtkOpenGLTexture.cxx signal SIGSEGV, Segmentation fault In-Reply-To: References: Message-ID: On Mon, Jan 25, 2016 at 12:38 PM, Jorge Perez wrote: > Hello, after investigating the pipeline (the SEGFAULT pushed me to do it) > I found how to remove the warning. The pipeline which is creating the > texture is internal to vtkImagePlaneWidget. I could remove the Warning by > disabling the TextureVisibility until a valid ImageData is set to the > vtkImagePlaneWidget. > > But my concern is related to the SEGFAULT, and I wonder if vtk need to > check for the NULL value that I mentioned in this thread > Yes, that's the fix I was talking about. We can add a check at places to prevent seg-fault and provide a clear message. - aashish > . > > best regards, > > Jorge > > 2016-01-25 17:59 GMT+01:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> Are you sure that the pipeline that creates the texture is not broken as >> said in the warning? Looks like whatever filter / pipeline you are using is >> not producing the data as it should. And it seems to me that we could be >> check for null texture object in other methods. If no one else look at it, >> I will push a fix. >> >> - Aashish >> >> On Mon, Jan 25, 2016 at 6:00 AM, Jorge Perez >> wrote: >> >>> Hello, I have an application which is reaching a SIGSEGV when opengl >>> backend is OpenGL2 (master branch). I have traced the error and it seems to >>> be related to this kind of warning: >>> >>> Warning: Kitware/vtk.gitlab/Common/ExecutionModel/vtkAlgorithm.cxx, line >>> 1421 >>> vtkOpenGLTexture (0x17e1620): Attempt to get connection index 0 for >>> input port 0, which has 0 connections. >>> >>> The warning appears with both OpenGL and OpenGL2 backends but with the >>> OpenGL2 a SIGSEGV is reached. >>> >>> The SIGSEGV is because the member vtkOpenGLTexture::TextureObject is >>> NULL and it can be used in: >>> >>> >>> - OpenGL2/vtkOpenGLPolyDataMapper >>> >>> if (texture) >>> { >>> tNumComp = >>> vtkOpenGLTexture::SafeDownCast(texture)-> >>> *GetTextureObject()->*GetComponents(); >>> } >>> >>> - OpenGL2/vtkOpenGL2Texture.cxx >>> >>> void vtkOpenGLTexture::CopyTexImage(int x, int y, int width, int height) >>> { >>> this->*TextureObject->*CopyFromFrameBuffer(x, y, x, y, width, height); >>> } >>> >>> void vtkOpenGLTexture::PostRender(vtkRenderer *vtkNotUsed(ren)) >>> { >>> this->*TextureObject->*Deactivate(); >>> } >>> >>> I see that within there are some pice of code which test for >>> TextureObject and uses it if it is not NULL, but there are others which do >>> not do the test for NULL. >>> >>> In order to have a quick fix I have initialized the member >>> TextureObject to vtkTextureObject::New() instead of the value 0 (at the >>> constructor vtkOpenGLTexture::vtkOpenGLTexture). That solved the SIGSEGV >>> for my application but I'm not sure if this could be a the correct solution. >>> >>> I can submit a merge request if the change make sense. >>> >>> this->TextureObject = vtkTextureObject::New(); >>> >>> best regards, >>> >>> Jorge >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuaxo2 at yahoo.com Tue Jan 26 09:51:25 2016 From: stuaxo2 at yahoo.com (Stuart Axon) Date: Tue, 26 Jan 2016 14:51:25 +0000 (UTC) Subject: [vtk-developers] Easy way of using VTK in virtualenv References: <1660902019.307874.1453819885173.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1660902019.307874.1453819885173.JavaMail.yahoo@mail.yahoo.com> Hi VTKers? ? I was trying VTK in python and couldn't work make it work with virtualenv easily, so I've added it to 'vext'. Once VTK is installed in the system python, you can do use it in a virtualenv by installing vext.vtk there: $ pip install vext.vtk It's not super tested, but the hello world example works for me (TM). Eventually I'm hoping that VTK and the other things* I've added to vext will "just work" with pip and virtualenv and so vext can go away (it is a bit of a hack). https://github.com/stuaxo/vext ?S++ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Jan 26 10:21:35 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 26 Jan 2016 10:21:35 -0500 Subject: [vtk-developers] VTK's google summer of code 2016 application Message-ID: Hey Folks, Google summer of code project applications are coming up soon (Feb 8 to 19). If you have a VTK related project in mind that you would like a student to work on, and especially if you would like to mentor said student over the summer and train them in the way of the source please add your project to the ideas list page at: * http://www.vtk.org/Wiki/VTK/GSoC_2016 I've seeded the ideas list with the leftovers from last year. @Paul and @Takuya - if you are not available to mentor this time around please let me know (or remove the project from the list). If VTK is accepted again, students applicants will riff off of our ideas to make up their own project proposals. We'll pick the best of those and then over the summer the student and mentor(s) will work hard to bring the idea to life. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Jan 27 11:04:43 2016 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Jan 2016 09:04:43 -0700 Subject: [vtk-developers] Dashboard error (clang bug?) Message-ID: Hi Sean, Did you see the error on the Rogue13/14 dashboards this morning? fatal error: error in backend: unsupported relocation of undefined symbol 'LBB57_4' I was trying to puzzle out what change might have caused the error, but it doesn't occur on my 10.9 system. On the dashboard the error occurs during compilation of vtkImageReslice.cxx, which hasn't changed in ages. The changes to vtkMath.h might have something to do with it... it's hard to know what might trigger a compiler bug. Any ideas? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jan 27 13:08:07 2016 From: sean at rogue-research.com (Sean McBride) Date: Wed, 27 Jan 2016 13:08:07 -0500 Subject: [vtk-developers] Dashboard error (clang bug?) In-Reply-To: References: Message-ID: <20160127180807.1327537136@mail.rogue-research.com> On Wed, 27 Jan 2016 09:04:43 -0700, David Gobbi said: >Did you see the error on the Rogue13/14 dashboards this morning? > > fatal error: error in backend: unsupported relocation of undefined symbol >'LBB57_4' > >I was trying to puzzle out what change might have caused the error, but it >doesn't occur on my 10.9 system. > >On the dashboard the error occurs during compilation of >vtkImageReslice.cxx, which hasn't changed in ages. The changes to >vtkMath.h might have something to do with it... it's hard to know what >might trigger a compiler bug. Any ideas? Sorry about that. It's probably a clang bug. I updated clang on those machines (needed to rebuild it to get clang-tidy, for which we'll set up a new dashboard soon) but I must have hit a bum svn revision, which happens sometimes when I rebuild clang from svn trunk. I'm rebuilding clang now, if it's still broken, I'll restore the previous version, which I keep for this reason. 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 s.kitlu at gmail.com Thu Jan 28 00:16:41 2016 From: s.kitlu at gmail.com (kitlu s) Date: Thu, 28 Jan 2016 10:46:41 +0530 Subject: [vtk-developers] structured to unstructured vtk or polydata vtk Message-ID: Hello everyone , I want to convert nrrd file into vtk file., i am doing this by python script using itk and vtk library but vtk what is generated is structured vtk but i want polydata or unstructured vtk. So is there any script using which we convert nrrd into unstructured vtk or polydata vtk ??? Please guide. Thanks in advance Regards, S.kitlu -------------- next part -------------- An HTML attachment was scrubbed... URL: From oshima at eng.niigata-u.ac.jp Thu Jan 28 06:39:04 2016 From: oshima at eng.niigata-u.ac.jp (Takuya OSHIMA) Date: Thu, 28 Jan 2016 20:39:04 +0900 (JST) Subject: [vtk-developers] VTK's google summer of code 2016 application In-Reply-To: References: Message-ID: <20160128.203904.113541113.oshima@eng.niigata-u.ac.jp> No problem. Glad to hear that the Catalyst-OpenFOAM project is listed again. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David E DeMarle Subject: VTK's google summer of code 2016 application Date: Tue, 26 Jan 2016 10:21:35 -0500 > Hey Folks, > > > Google summer of code project applications are coming up soon (Feb 8 to 19). > > If you have a VTK related project in mind that you would like a student to > work on, and especially if you would like to mentor said student over the > summer and train them in the way of the source please add your project to > the ideas list page at: > > * http://www.vtk.org/Wiki/VTK/GSoC_2016 > > I've seeded the ideas list with the leftovers from last year. > > @Paul and @Takuya - if you are not available to mentor this time around > please let me know (or remove the project from the list). > > If VTK is accepted again, students applicants will riff off of our ideas to > make up their own project proposals. We'll pick the best of those and then > over the summer the student and mentor(s) will work hard to bring the idea > to life. > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 From will.schroeder at kitware.com Thu Jan 28 09:12:30 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 28 Jan 2016 09:12:30 -0500 Subject: [vtk-developers] vtkPointCloud remote module Message-ID: FYI- I have committed an initial set of filters for performing point cloud processing. Any feedback or suggestions are welcome as this is an initial prototype. The work is currently available as a remote module to VTK (vtkPointCloud) via this repository: https://gitlab.kitware.com/vtk/point-cloud.git A couple of notes: + Right now I am using vtkPolyData to represent the point cloud via a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to save on memory. + The classes will process as input any vtkPointSet dataset + There is a general framework for filtering point clouds via the class vtkPointCloudFilter. Besides their filtered cloud output, these filters also have an optional, second output which contains any points removed from the input. + Current filters include vtkRadiusOutlierRemoval, vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an implicit function). Some of these names are inspired by PCL names. + All filters are threaded using vtkSMPTools using a threaded locator (vtkStaticPointLocator) so I believe that this is relatively fast, although I have not done much testing. + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote that is very fast. As usual comments and suggestions are requested. In particular any suggestions for other filters to write are welcome (to round out some of the core functionality). The repository is in flux as I try crazy ideas and try to educate myself, so be forewarned. Best, W -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Jan 28 09:14:24 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 28 Jan 2016 09:14:24 -0500 Subject: [vtk-developers] structured to unstructured vtk or polydata vtk In-Reply-To: References: Message-ID: Please don't cross post "how to use VTK questions" from vtkusers to vtk-developers. thanks David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Jan 28, 2016 at 12:16 AM, kitlu s wrote: > Hello everyone , > > I want to convert nrrd file into vtk file., i am doing this by python > script > using itk and vtk library but vtk what is generated is structured vtk but > i > want polydata or unstructured vtk. > > So is there any script using which we convert nrrd into unstructured vtk > or > polydata vtk ??? > > Please guide. > > Thanks in advance > > Regards, > S.kitlu > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://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 gpwright at gmail.com Thu Jan 28 09:56:41 2016 From: gpwright at gmail.com (Geoff Wright) Date: Thu, 28 Jan 2016 14:56:41 +0000 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Hi Will, This is good to see. I'm currently using VTK to generate surfaces from some point cloud data. I have some initial pre processing steps that I use PCL (point cloud library) for, and then a vtk stage that converts PCL point cloud into vtkPolyData/vtkPoints. It would be great to eliminate the PCL dependency and use exclusively vtk. My point cloud data grows very large over time with a lot of redundant points so its very important to downsample them onto uniform spacing ( http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before processing them in vtk. Would it make sense to add something like this to your library? Geoff On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder wrote: > FYI- I have committed an initial set of filters for performing point cloud > processing. Any feedback or suggestions are welcome as this is an initial > prototype. The work is currently available as a remote module to VTK > (vtkPointCloud) via this repository: > https://gitlab.kitware.com/vtk/point-cloud.git > > A couple of notes: > + Right now I am using vtkPolyData to represent the point cloud via a > vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to > save on memory. > + The classes will process as input any vtkPointSet dataset > + There is a general framework for filtering point clouds via the class > vtkPointCloudFilter. Besides their filtered cloud output, these filters > also have an optional, second output which contains any points removed from > the input. > + Current filters include vtkRadiusOutlierRemoval, > vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an > implicit function). Some of these names are inspired by PCL > names. > + All filters are threaded using vtkSMPTools using a threaded locator > (vtkStaticPointLocator) so I believe that this is relatively fast, although > I have not done much testing. > + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote > that is very fast. > > As usual comments and suggestions are requested. In particular any > suggestions for other filters to write are welcome (to round out some of > the core functionality). The repository is in flux as I try crazy ideas and > try to educate myself, so be forewarned. > > Best, > W > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Thu Jan 28 10:03:20 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 28 Jan 2016 10:03:20 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Thanks for the feedback. I have some downsampling filters in the works now, I'll let you know when I have something ready. BTW we are on a similar path. PCL is awesome, but we have some common workflows that would be better served with more compact software environments, and with minimal IO and/or data transfer. So we're trying to knock of a small kernel of capability to achieve this. Best, W On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright wrote: > Hi Will, > > This is good to see. I'm currently using VTK to generate surfaces from > some point cloud data. I have some initial pre processing steps that I use > PCL (point cloud library) for, and then a vtk stage that converts PCL point > cloud into vtkPolyData/vtkPoints. It would be great to eliminate the PCL > dependency and use exclusively vtk. My point cloud data grows very large > over time with a lot of redundant points so its very important to > downsample them onto uniform spacing ( > http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before > processing them in vtk. Would it make sense to add something like this to > your library? > > Geoff > > > > > > > > On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder > wrote: > >> FYI- I have committed an initial set of filters for performing point >> cloud processing. Any feedback or suggestions are welcome as this is an >> initial prototype. The work is currently available as a remote module to >> VTK (vtkPointCloud) via this repository: >> https://gitlab.kitware.com/vtk/point-cloud.git >> >> A couple of notes: >> + Right now I am using vtkPolyData to represent the point cloud via a >> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >> save on memory. >> + The classes will process as input any vtkPointSet dataset >> + There is a general framework for filtering point clouds via the class >> vtkPointCloudFilter. Besides their filtered cloud output, these filters >> also have an optional, second output which contains any points removed from >> the input. >> + Current filters include vtkRadiusOutlierRemoval, >> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >> implicit function). Some of these names are inspired by PCL >> names. >> + All filters are threaded using vtkSMPTools using a threaded locator >> (vtkStaticPointLocator) so I believe that this is relatively fast, although >> I have not done much testing. >> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >> that is very fast. >> >> As usual comments and suggestions are requested. In particular any >> suggestions for other filters to write are welcome (to round out some of >> the core functionality). The repository is in flux as I try crazy ideas and >> try to educate myself, so be forewarned. >> >> Best, >> W >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://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 bill.lorensen at gmail.com Thu Jan 28 11:43:11 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 28 Jan 2016 11:43:11 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Will, To build as a remote module, users should place the attached file in vtk_source_directory/Remote Then 1) cd vtk_build_directory 2) cmake -DModule_vtkPointCloud:BOOL=ON ../VTK 2) make I just tried it and it built great on my mac. It is missing a baseline image. Bill On Thu, Jan 28, 2016 at 9:12 AM, Will Schroeder wrote: > FYI- I have committed an initial set of filters for performing point cloud > processing. Any feedback or suggestions are welcome as this is an initial > prototype. The work is currently available as a remote module to VTK > (vtkPointCloud) via this repository: > https://gitlab.kitware.com/vtk/point-cloud.git > > A couple of notes: > + Right now I am using vtkPolyData to represent the point cloud via a > vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to > save on memory. > + The classes will process as input any vtkPointSet dataset > + There is a general framework for filtering point clouds via the class > vtkPointCloudFilter. Besides their filtered cloud output, these filters also > have an optional, second output which contains any points removed from the > input. > + Current filters include vtkRadiusOutlierRemoval, > vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an > implicit function). Some of these names are inspired by PCL names. > + All filters are threaded using vtkSMPTools using a threaded locator > (vtkStaticPointLocator) so I believe that this is relatively fast, although > I have not done much testing. > + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote that > is very fast. > > As usual comments and suggestions are requested. In particular any > suggestions for other filters to write are welcome (to round out some of the > core functionality). The repository is in flux as I try crazy ideas and try > to educate myself, so be forewarned. > > Best, > W > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://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 -------------- next part -------------- A non-text attachment was scrubbed... Name: vtkPointCloud.remote.cmake Type: application/octet-stream Size: 316 bytes Desc: not available URL: From will.schroeder at kitware.com Thu Jan 28 11:49:16 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 28 Jan 2016 11:49:16 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: I've actually got several baseline images to push in. I'll try and do this tonight when I have more time. BTW thanks for your help Bill, the remote module stuff you added is very nice and I see there are some nice modules starting to appear like DICOM (David Gobbi ?), Poisson reconstruction and some Slicer code. Best, W On Thu, Jan 28, 2016 at 11:43 AM, Bill Lorensen wrote: > Will, > > To build as a remote module, users should place the attached file in > vtk_source_directory/Remote > > Then > 1) cd vtk_build_directory > 2) cmake -DModule_vtkPointCloud:BOOL=ON ../VTK > 2) make > > > I just tried it and it built great on my mac. It is missing a baseline > image. > > Bill > > On Thu, Jan 28, 2016 at 9:12 AM, Will Schroeder > wrote: > > FYI- I have committed an initial set of filters for performing point > cloud > > processing. Any feedback or suggestions are welcome as this is an initial > > prototype. The work is currently available as a remote module to VTK > > (vtkPointCloud) via this repository: > > https://gitlab.kitware.com/vtk/point-cloud.git > > > > A couple of notes: > > + Right now I am using vtkPolyData to represent the point cloud via a > > vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created > to > > save on memory. > > + The classes will process as input any vtkPointSet dataset > > + There is a general framework for filtering point clouds via the class > > vtkPointCloudFilter. Besides their filtered cloud output, these filters > also > > have an optional, second output which contains any points removed from > the > > input. > > + Current filters include vtkRadiusOutlierRemoval, > > vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an > > implicit function). Some of these names are inspired by PCL names. > > + All filters are threaded using vtkSMPTools using a threaded locator > > (vtkStaticPointLocator) so I believe that this is relatively fast, > although > > I have not done much testing. > > + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote > that > > is very fast. > > > > As usual comments and suggestions are requested. In particular any > > suggestions for other filters to write are welcome (to round out some of > the > > core functionality). The repository is in flux as I try crazy ideas and > try > > to educate myself, so be forewarned. > > > > Best, > > W > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://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 > -- 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 joachim.pouderoux at kitware.com Fri Jan 29 04:55:06 2016 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 29 Jan 2016 10:55:06 +0100 Subject: [vtk-developers] ANN: VTK & ParaView Training Course in Lyon, France, March 15-16, 2016 Message-ID: Kitware will be holding 2 days of courses on VTK and ParaView on March 15-16, 2016 in Lyon, France. Please visit our web site for more information and registration details at either: VTK: http://training.kitware.fr/browse/122 (in English) or http://formations.kitware.fr/browse/122 (in French) ParaView: http://training.kitware.fr/browse/121 (in English) or http://formations.kitware.fr/browse/121 (in French) Note that the courses will be taught in English. If you have any question, please contact us at formations at http://www.kitware.fr Thank you, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Jan 29 10:06:56 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 29 Jan 2016 10:06:56 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Geoff- I knocked out a vtkVoxelGrid last night, it seems to work great. It's threaded and seems to be fast. Question for you before I push the work to the repository: averaging points in each bin provides a nice subsampled point position. But what do you think we should do for attributes (e.g., scalars, vector, etc.)? These could be averaged too. There are however other options like finding the closest point to the subsampled point and using those attribute values, or if you want to get really fancy, using an interpolation kernel to interpolate to the subsampled point. Thoughts? W On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder wrote: > Thanks for the feedback. I have some downsampling filters in the works > now, I'll let you know when I have something ready. > > BTW we are on a similar path. PCL is awesome, but we have some common > workflows that would be better served with more compact software > environments, and with minimal IO and/or data transfer. So we're trying to > knock of a small kernel of capability to achieve this. > > Best, > W > > On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright wrote: > >> Hi Will, >> >> This is good to see. I'm currently using VTK to generate surfaces from >> some point cloud data. I have some initial pre processing steps that I use >> PCL (point cloud library) for, and then a vtk stage that converts PCL point >> cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >> PCL dependency and use exclusively vtk. My point cloud data grows very >> large over time with a lot of redundant points so its very important to >> downsample them onto uniform spacing ( >> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before >> processing them in vtk. Would it make sense to add something like this to >> your library? >> >> Geoff >> >> >> >> >> >> >> >> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> FYI- I have committed an initial set of filters for performing point >>> cloud processing. Any feedback or suggestions are welcome as this is an >>> initial prototype. The work is currently available as a remote module to >>> VTK (vtkPointCloud) via this repository: >>> https://gitlab.kitware.com/vtk/point-cloud.git >>> >>> A couple of notes: >>> + Right now I am using vtkPolyData to represent the point cloud via a >>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>> save on memory. >>> + The classes will process as input any vtkPointSet dataset >>> + There is a general framework for filtering point clouds via the class >>> vtkPointCloudFilter. Besides their filtered cloud output, these filters >>> also have an optional, second output which contains any points removed from >>> the input. >>> + Current filters include vtkRadiusOutlierRemoval, >>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>> implicit function). Some of these names are inspired by PCL >>> names. >>> + All filters are threaded using vtkSMPTools using a threaded locator >>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>> I have not done much testing. >>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >>> that is very fast. >>> >>> As usual comments and suggestions are requested. In particular any >>> suggestions for other filters to write are welcome (to round out some of >>> the core functionality). The repository is in flux as I try crazy ideas and >>> try to educate myself, so be forewarned. >>> >>> Best, >>> W >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://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 gpwright at gmail.com Fri Jan 29 10:26:19 2016 From: gpwright at gmail.com (Geoff Wright) Date: Fri, 29 Jan 2016 15:26:19 +0000 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Hi Will, That sounds good. For my use case I do have a couple of scalar quantities associated with each point, in PCL terminology I use pcl::PointXYZHSV. For interpolation of scalar values I think the ideal would be a parameter on voxel grid that can accept either VTK_NEAREST_INTERPOLATION, VTK_LINEAR_INTERPOLATION or VTK_CUBIC_INTERPOLATION a la vtkVolumeProperty.h. However, if this is too much work I think a linear interpolation implementation would be fine for most use cases. Let me know when you push the changes, I'll try it out. Just checked your gitlab repo and didn't seem them there yet. G On Fri, Jan 29, 2016 at 10:07 AM Will Schroeder wrote: > Geoff- > > I knocked out a vtkVoxelGrid last night, it seems to work great. It's > threaded and seems to be fast. > > Question for you before I push the work to the repository: averaging > points in each bin provides a nice subsampled point position. But what do > you think we should do for attributes (e.g., scalars, vector, etc.)? These > could be averaged too. There are however other options like finding the > closest point to the subsampled point and using those attribute values, or > if you want to get really fancy, using an interpolation kernel to > interpolate to the subsampled point. > > Thoughts? > W > > On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Thanks for the feedback. I have some downsampling filters in the works >> now, I'll let you know when I have something ready. >> >> BTW we are on a similar path. PCL is awesome, but we have some common >> workflows that would be better served with more compact software >> environments, and with minimal IO and/or data transfer. So we're trying to >> knock of a small kernel of capability to achieve this. >> >> Best, >> W >> >> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright wrote: >> >>> Hi Will, >>> >>> This is good to see. I'm currently using VTK to generate surfaces from >>> some point cloud data. I have some initial pre processing steps that I use >>> PCL (point cloud library) for, and then a vtk stage that converts PCL point >>> cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >>> PCL dependency and use exclusively vtk. My point cloud data grows very >>> large over time with a lot of redundant points so its very important to >>> downsample them onto uniform spacing ( >>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before >>> processing them in vtk. Would it make sense to add something like this to >>> your library? >>> >>> Geoff >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> FYI- I have committed an initial set of filters for performing point >>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>> initial prototype. The work is currently available as a remote module to >>>> VTK (vtkPointCloud) via this repository: >>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>> >>>> A couple of notes: >>>> + Right now I am using vtkPolyData to represent the point cloud via a >>>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>>> save on memory. >>>> + The classes will process as input any vtkPointSet dataset >>>> + There is a general framework for filtering point clouds via the class >>>> vtkPointCloudFilter. Besides their filtered cloud output, these filters >>>> also have an optional, second output which contains any points removed from >>>> the input. >>>> + Current filters include vtkRadiusOutlierRemoval, >>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>> implicit function). Some of these names are inspired by PCL >>>> names. >>>> + All filters are threaded using vtkSMPTools using a threaded locator >>>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>>> I have not done much testing. >>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >>>> that is very fast. >>>> >>>> As usual comments and suggestions are requested. In particular any >>>> suggestions for other filters to write are welcome (to round out some of >>>> the core functionality). The repository is in flux as I try crazy ideas and >>>> try to educate myself, so be forewarned. >>>> >>>> Best, >>>> W >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://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 ken.martin at kitware.com Fri Jan 29 10:42:10 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 29 Jan 2016 10:42:10 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Nice, can I make a specific request Will? :-) Part of what I want to do for large point clouds is something like the following: 1) Open a VTK multipiece file and read in the bounding boxes of the pieces (but not the data) 2) Read in the first piece and use it for rendering 3) In the background read in more pieces, as they are loaded make them available to the mapper 4) The mapper based on the current camera parameters and bounding boxes of the pieces intelligently selects what pieces to render. This provides a happy fast interactive experience leading to world peace. For this to work well my thought was to have the pieces be broken up in a special way sort of like an octree but a spatial hash etc would be just as good as long as it is hierarchical and structured. Think of breaking up the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the data covering the entire bounding box. The next eight pieces also each contain about 1/73 of the data each constrained by their octant of the bounding box. Same idea for the next 64 boxes, they are just one level further down. This would work really well for a smart mapper providing fast first render plus fast LOD/subsequent renders. I can implement 1-4 pretty quickly. But .... for it to work I need someone to create the 73 piece file the right way. (it does not have to be 73, and clearly some of those 73 will be empty, it just needs to be hierarchical and structured so that a group of pieces can be represented at a lower level of detail by some other piece) My gut feeling was to have the LOD pieces use actual points of the dataset (not centroids or similar) that way as more pieces are loaded we are just providing more detail, not replacing fake data (centroids) with real data. But really either approach is pretty easy to implement in the mapper. The latter approach just means the entire dataset footprint is larger because some of the points are not part of the full res dataset because you generated them. I could be totally off base but that was my gut feeling on rendering > 2GB point clouds in a nice zippy manner. TLDR: I want someone to write a filter/writer subclass to create a special 73 piece vtk file :-) Ken On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder wrote: > Geoff- > > I knocked out a vtkVoxelGrid last night, it seems to work great. It's > threaded and seems to be fast. > > Question for you before I push the work to the repository: averaging > points in each bin provides a nice subsampled point position. But what do > you think we should do for attributes (e.g., scalars, vector, etc.)? These > could be averaged too. There are however other options like finding the > closest point to the subsampled point and using those attribute values, or > if you want to get really fancy, using an interpolation kernel to > interpolate to the subsampled point. > > Thoughts? > W > > On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Thanks for the feedback. I have some downsampling filters in the works >> now, I'll let you know when I have something ready. >> >> BTW we are on a similar path. PCL is awesome, but we have some common >> workflows that would be better served with more compact software >> environments, and with minimal IO and/or data transfer. So we're trying to >> knock of a small kernel of capability to achieve this. >> >> Best, >> W >> >> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright wrote: >> >>> Hi Will, >>> >>> This is good to see. I'm currently using VTK to generate surfaces from >>> some point cloud data. I have some initial pre processing steps that I use >>> PCL (point cloud library) for, and then a vtk stage that converts PCL point >>> cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >>> PCL dependency and use exclusively vtk. My point cloud data grows very >>> large over time with a lot of redundant points so its very important to >>> downsample them onto uniform spacing ( >>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before >>> processing them in vtk. Would it make sense to add something like this to >>> your library? >>> >>> Geoff >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> FYI- I have committed an initial set of filters for performing point >>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>> initial prototype. The work is currently available as a remote module to >>>> VTK (vtkPointCloud) via this repository: >>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>> >>>> A couple of notes: >>>> + Right now I am using vtkPolyData to represent the point cloud via a >>>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>>> save on memory. >>>> + The classes will process as input any vtkPointSet dataset >>>> + There is a general framework for filtering point clouds via the class >>>> vtkPointCloudFilter. Besides their filtered cloud output, these filters >>>> also have an optional, second output which contains any points removed from >>>> the input. >>>> + Current filters include vtkRadiusOutlierRemoval, >>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>> implicit function). Some of these names are inspired by PCL >>>> names. >>>> + All filters are threaded using vtkSMPTools using a threaded locator >>>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>>> I have not done much testing. >>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >>>> that is very fast. >>>> >>>> As usual comments and suggestions are requested. In particular any >>>> suggestions for other filters to write are welcome (to round out some of >>>> the core functionality). The repository is in flux as I try crazy ideas and >>>> try to educate myself, so be forewarned. >>>> >>>> Best, >>>> W >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://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 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://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 will.schroeder at kitware.com Fri Jan 29 11:08:11 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 29 Jan 2016 11:08:11 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Ken- I am totally with you. I am writing some simple stuff at the moment like VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to get my head around the challenges and serve as a stop gap until our better stuff comes along. I really like your idea and I do plan to implement this; it's really not too hard to do from what I understand and given the pieces available in VTK. So I'll wrap up this simple VoxelGrid and then take a crack at the beast you've envisioned. The two major pieces seems to be 1) create a class that builds the hierarchical structure, and 2) write a reader/writer pair that can perform associated IO. In an earlier email you mentioned a PTS reader that you made improvement to; is this a good exemplar data format or do you have a better starting point? It seems I have a homework assignment for the weekend :-) Best, W On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin wrote: > Nice, can I make a specific request Will? :-) Part of what I want to do > for large point clouds is something like the following: > > 1) Open a VTK multipiece file and read in the bounding boxes of the pieces > (but not the data) > > 2) Read in the first piece and use it for rendering > > 3) In the background read in more pieces, as they are loaded make them > available to the mapper > > 4) The mapper based on the current camera parameters and bounding boxes of > the pieces intelligently selects what pieces to render. This provides a > happy fast interactive experience leading to world peace. > > For this to work well my thought was to have the pieces be broken up in a > special way sort of like an octree but a spatial hash etc would be just as > good as long as it is hierarchical and structured. Think of breaking up the > volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the data > covering the entire bounding box. The next eight pieces also each contain > about 1/73 of the data each constrained by their octant of the bounding > box. Same idea for the next 64 boxes, they are just one level further > down. This would work really well for a smart mapper providing fast first > render plus fast LOD/subsequent renders. I can implement 1-4 pretty > quickly. > > But .... for it to work I need someone to create the 73 piece file the > right way. (it does not have to be 73, and clearly some of those 73 will be > empty, it just needs to be hierarchical and structured so that a group of > pieces can be represented at a lower level of detail by some other piece) > My gut feeling was to have the LOD pieces use actual points of the dataset > (not centroids or similar) that way as more pieces are loaded we are just > providing more detail, not replacing fake data (centroids) with real data. > But really either approach is pretty easy to implement in the mapper. The > latter approach just means the entire dataset footprint is larger because > some of the points are not part of the full res dataset because you > generated them. > > I could be totally off base but that was my gut feeling on rendering > 2GB > point clouds in a nice zippy manner. > > TLDR: I want someone to write a filter/writer subclass to create a special > 73 piece vtk file :-) > > Ken > > > > > > On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Geoff- >> >> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >> threaded and seems to be fast. >> >> Question for you before I push the work to the repository: averaging >> points in each bin provides a nice subsampled point position. But what do >> you think we should do for attributes (e.g., scalars, vector, etc.)? These >> could be averaged too. There are however other options like finding the >> closest point to the subsampled point and using those attribute values, or >> if you want to get really fancy, using an interpolation kernel to >> interpolate to the subsampled point. >> >> Thoughts? >> W >> >> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Thanks for the feedback. I have some downsampling filters in the works >>> now, I'll let you know when I have something ready. >>> >>> BTW we are on a similar path. PCL is awesome, but we have some common >>> workflows that would be better served with more compact software >>> environments, and with minimal IO and/or data transfer. So we're trying to >>> knock of a small kernel of capability to achieve this. >>> >>> Best, >>> W >>> >>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>> wrote: >>> >>>> Hi Will, >>>> >>>> This is good to see. I'm currently using VTK to generate surfaces from >>>> some point cloud data. I have some initial pre processing steps that I use >>>> PCL (point cloud library) for, and then a vtk stage that converts PCL point >>>> cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >>>> PCL dependency and use exclusively vtk. My point cloud data grows >>>> very large over time with a lot of redundant points so its very important >>>> to downsample them onto uniform spacing ( >>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>> before processing them in vtk. Would it make sense to add something like >>>> this to your library? >>>> >>>> Geoff >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> FYI- I have committed an initial set of filters for performing point >>>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>>> initial prototype. The work is currently available as a remote module to >>>>> VTK (vtkPointCloud) via this repository: >>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>> >>>>> A couple of notes: >>>>> + Right now I am using vtkPolyData to represent the point cloud via a >>>>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>>>> save on memory. >>>>> + The classes will process as input any vtkPointSet dataset >>>>> + There is a general framework for filtering point clouds via the >>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>> filters also have an optional, second output which contains any points >>>>> removed from the input. >>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>> implicit function). Some of these names are inspired by PCL >>>>> names. >>>>> + All filters are threaded using vtkSMPTools using a threaded locator >>>>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>>>> I have not done much testing. >>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>> wrote that is very fast. >>>>> >>>>> As usual comments and suggestions are requested. In particular any >>>>> suggestions for other filters to write are welcome (to round out some of >>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>> try to educate myself, so be forewarned. >>>>> >>>>> Best, >>>>> W >>>>> >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://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 >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://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. > -- 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 Fri Jan 29 12:15:03 2016 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 29 Jan 2016 12:15:03 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Thanks Will. I promise I'll write the mapper :-) The PTS reader is a simple ascii X Y Z R G B type format that I usually immediately convert to VTK XML format as that is far faster and more compact. So unfortunately PTS is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some bounding box metadata. Ken On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder wrote: > Ken- > > I am totally with you. I am writing some simple stuff at the moment like > VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to > get my head around the challenges and serve as a stop gap until our better > stuff comes along. I really like your idea and I do plan to implement this; > it's really not too hard to do from what I understand and given the pieces > available in VTK. > > So I'll wrap up this simple VoxelGrid and then take a crack at the beast > you've envisioned. The two major pieces seems to be 1) create a class that > builds the hierarchical structure, and 2) write a reader/writer pair that > can perform associated IO. In an earlier email you mentioned a PTS reader > that you made improvement to; is this a good exemplar data format or do you > have a better starting point? > > It seems I have a homework assignment for the weekend :-) > > Best, > W > > On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin > wrote: > >> Nice, can I make a specific request Will? :-) Part of what I want to do >> for large point clouds is something like the following: >> >> 1) Open a VTK multipiece file and read in the bounding boxes of the >> pieces (but not the data) >> >> 2) Read in the first piece and use it for rendering >> >> 3) In the background read in more pieces, as they are loaded make them >> available to the mapper >> >> 4) The mapper based on the current camera parameters and bounding boxes >> of the pieces intelligently selects what pieces to render. This provides a >> happy fast interactive experience leading to world peace. >> >> For this to work well my thought was to have the pieces be broken up in a >> special way sort of like an octree but a spatial hash etc would be just as >> good as long as it is hierarchical and structured. Think of breaking up the >> volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the data >> covering the entire bounding box. The next eight pieces also each contain >> about 1/73 of the data each constrained by their octant of the bounding >> box. Same idea for the next 64 boxes, they are just one level further >> down. This would work really well for a smart mapper providing fast first >> render plus fast LOD/subsequent renders. I can implement 1-4 pretty >> quickly. >> >> But .... for it to work I need someone to create the 73 piece file the >> right way. (it does not have to be 73, and clearly some of those 73 will be >> empty, it just needs to be hierarchical and structured so that a group of >> pieces can be represented at a lower level of detail by some other piece) >> My gut feeling was to have the LOD pieces use actual points of the dataset >> (not centroids or similar) that way as more pieces are loaded we are just >> providing more detail, not replacing fake data (centroids) with real data. >> But really either approach is pretty easy to implement in the mapper. The >> latter approach just means the entire dataset footprint is larger because >> some of the points are not part of the full res dataset because you >> generated them. >> >> I could be totally off base but that was my gut feeling on rendering > >> 2GB point clouds in a nice zippy manner. >> >> TLDR: I want someone to write a filter/writer subclass to create a >> special 73 piece vtk file :-) >> >> Ken >> >> >> >> >> >> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Geoff- >>> >>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>> threaded and seems to be fast. >>> >>> Question for you before I push the work to the repository: averaging >>> points in each bin provides a nice subsampled point position. But what do >>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>> could be averaged too. There are however other options like finding the >>> closest point to the subsampled point and using those attribute values, or >>> if you want to get really fancy, using an interpolation kernel to >>> interpolate to the subsampled point. >>> >>> Thoughts? >>> W >>> >>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> Thanks for the feedback. I have some downsampling filters in the works >>>> now, I'll let you know when I have something ready. >>>> >>>> BTW we are on a similar path. PCL is awesome, but we have some common >>>> workflows that would be better served with more compact software >>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>> knock of a small kernel of capability to achieve this. >>>> >>>> Best, >>>> W >>>> >>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>> wrote: >>>> >>>>> Hi Will, >>>>> >>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>> from some point cloud data. I have some initial pre processing steps that >>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>> eliminate the PCL dependency and use exclusively vtk. My point cloud >>>>> data grows very large over time with a lot of redundant points so its very >>>>> important to downsample them onto uniform spacing ( >>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>> before processing them in vtk. Would it make sense to add something like >>>>> this to your library? >>>>> >>>>> Geoff >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> FYI- I have committed an initial set of filters for performing point >>>>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>>>> initial prototype. The work is currently available as a remote module to >>>>>> VTK (vtkPointCloud) via this repository: >>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>> >>>>>> A couple of notes: >>>>>> + Right now I am using vtkPolyData to represent the point cloud via a >>>>>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>>>>> save on memory. >>>>>> + The classes will process as input any vtkPointSet dataset >>>>>> + There is a general framework for filtering point clouds via the >>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>> filters also have an optional, second output which contains any points >>>>>> removed from the input. >>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>> implicit function). Some of these names are inspired by PCL >>>>>> names. >>>>>> + All filters are threaded using vtkSMPTools using a threaded locator >>>>>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>>>>> I have not done much testing. >>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>> wrote that is very fast. >>>>>> >>>>>> As usual comments and suggestions are requested. In particular any >>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>> try to educate myself, so be forewarned. >>>>>> >>>>>> Best, >>>>>> W >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://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 >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://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. >> > > > > -- > 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 > -- 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 Fri Jan 29 12:23:27 2016 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Fri, 29 Jan 2016 12:23:27 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Ken, What you are wanting sounds very similar to how the streaming particles plugin in ParaView works. In this case it is the representation that is deciding what data to request from the upstream pipeline. I have an example source in there [1] that randomly generates an octree-like structure that it expects (of vtkMultiBlockDataset). Either you or Will may want to look at how that is working while you are tackling this. Shawn [1]: ParaView-src/Plugins/StreamingParticles/vtkPVRandomPointsStreamingSource.{h,cxx}. On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin wrote: > Thanks Will. I promise I'll write the mapper :-) The PTS reader is a > simple ascii X Y Z R G B type format that I usually immediately convert to > VTK XML format as that is far faster and more compact. So unfortunately PTS > is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some > bounding box metadata. > > Ken > > On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Ken- >> >> I am totally with you. I am writing some simple stuff at the moment like >> VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to >> get my head around the challenges and serve as a stop gap until our better >> stuff comes along. I really like your idea and I do plan to implement this; >> it's really not too hard to do from what I understand and given the pieces >> available in VTK. >> >> So I'll wrap up this simple VoxelGrid and then take a crack at the beast >> you've envisioned. The two major pieces seems to be 1) create a class that >> builds the hierarchical structure, and 2) write a reader/writer pair that >> can perform associated IO. In an earlier email you mentioned a PTS reader >> that you made improvement to; is this a good exemplar data format or do you >> have a better starting point? >> >> It seems I have a homework assignment for the weekend :-) >> >> Best, >> W >> >> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >> wrote: >> >>> Nice, can I make a specific request Will? :-) Part of what I want to do >>> for large point clouds is something like the following: >>> >>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>> pieces (but not the data) >>> >>> 2) Read in the first piece and use it for rendering >>> >>> 3) In the background read in more pieces, as they are loaded make them >>> available to the mapper >>> >>> 4) The mapper based on the current camera parameters and bounding boxes >>> of the pieces intelligently selects what pieces to render. This provides a >>> happy fast interactive experience leading to world peace. >>> >>> For this to work well my thought was to have the pieces be broken up in >>> a special way sort of like an octree but a spatial hash etc would be just >>> as good as long as it is hierarchical and structured. Think of breaking up >>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the >>> data covering the entire bounding box. The next eight pieces also each >>> contain about 1/73 of the data each constrained by their octant of the >>> bounding box. Same idea for the next 64 boxes, they are just one level >>> further down. This would work really well for a smart mapper providing >>> fast first render plus fast LOD/subsequent renders. I can implement 1-4 >>> pretty quickly. >>> >>> But .... for it to work I need someone to create the 73 piece file the >>> right way. (it does not have to be 73, and clearly some of those 73 will be >>> empty, it just needs to be hierarchical and structured so that a group of >>> pieces can be represented at a lower level of detail by some other piece) >>> My gut feeling was to have the LOD pieces use actual points of the dataset >>> (not centroids or similar) that way as more pieces are loaded we are just >>> providing more detail, not replacing fake data (centroids) with real data. >>> But really either approach is pretty easy to implement in the mapper. The >>> latter approach just means the entire dataset footprint is larger because >>> some of the points are not part of the full res dataset because you >>> generated them. >>> >>> I could be totally off base but that was my gut feeling on rendering > >>> 2GB point clouds in a nice zippy manner. >>> >>> TLDR: I want someone to write a filter/writer subclass to create a >>> special 73 piece vtk file :-) >>> >>> Ken >>> >>> >>> >>> >>> >>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> Geoff- >>>> >>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>> threaded and seems to be fast. >>>> >>>> Question for you before I push the work to the repository: averaging >>>> points in each bin provides a nice subsampled point position. But what do >>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>> could be averaged too. There are however other options like finding the >>>> closest point to the subsampled point and using those attribute values, or >>>> if you want to get really fancy, using an interpolation kernel to >>>> interpolate to the subsampled point. >>>> >>>> Thoughts? >>>> W >>>> >>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> Thanks for the feedback. I have some downsampling filters in the works >>>>> now, I'll let you know when I have something ready. >>>>> >>>>> BTW we are on a similar path. PCL is awesome, but we have some common >>>>> workflows that would be better served with more compact software >>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>> knock of a small kernel of capability to achieve this. >>>>> >>>>> Best, >>>>> W >>>>> >>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>> wrote: >>>>> >>>>>> Hi Will, >>>>>> >>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>> from some point cloud data. I have some initial pre processing steps that >>>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>>> eliminate the PCL dependency and use exclusively vtk. My point >>>>>> cloud data grows very large over time with a lot of redundant points so its >>>>>> very important to downsample them onto uniform spacing ( >>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>>> before processing them in vtk. Would it make sense to add something like >>>>>> this to your library? >>>>>> >>>>>> Geoff >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>>> will.schroeder at kitware.com> wrote: >>>>>> >>>>>>> FYI- I have committed an initial set of filters for performing point >>>>>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>>>>> initial prototype. The work is currently available as a remote module to >>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>> >>>>>>> A couple of notes: >>>>>>> + Right now I am using vtkPolyData to represent the point cloud via >>>>>>> a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created >>>>>>> to save on memory. >>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>> + There is a general framework for filtering point clouds via the >>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>> filters also have an optional, second output which contains any points >>>>>>> removed from the input. >>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>> implicit function). Some of these names are inspired by PCL >>>>>>> names. >>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>> although I have not done much testing. >>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>> wrote that is very fast. >>>>>>> >>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>>> try to educate myself, so be forewarned. >>>>>>> >>>>>>> Best, >>>>>>> W >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://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 >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://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. >>> >> >> >> >> -- >> 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 >> > > > > -- > 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 aashish.chaudhary at kitware.com Fri Jan 29 12:34:26 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 29 Jan 2016 12:34:26 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Will, This works sounds like a great addition to VTK (via remote module)!! Thanks, On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder wrote: > Thanks for the feedback. I have some downsampling filters in the works > now, I'll let you know when I have something ready. > > BTW we are on a similar path. PCL is awesome, but we have some common > workflows that would be better served with more compact software > environments, and with minimal IO and/or data transfer. So we're trying to > knock of a small kernel of capability to achieve this. > > Best, > W > > On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright wrote: > >> Hi Will, >> >> This is good to see. I'm currently using VTK to generate surfaces from >> some point cloud data. I have some initial pre processing steps that I use >> PCL (point cloud library) for, and then a vtk stage that converts PCL point >> cloud into vtkPolyData/vtkPoints. It would be great to eliminate the >> PCL dependency and use exclusively vtk. My point cloud data grows very >> large over time with a lot of redundant points so its very important to >> downsample them onto uniform spacing ( >> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) before >> processing them in vtk. Would it make sense to add something like this to >> your library? >> >> Geoff >> >> >> >> >> >> >> >> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> FYI- I have committed an initial set of filters for performing point >>> cloud processing. Any feedback or suggestions are welcome as this is an >>> initial prototype. The work is currently available as a remote module to >>> VTK (vtkPointCloud) via this repository: >>> https://gitlab.kitware.com/vtk/point-cloud.git >>> >>> A couple of notes: >>> + Right now I am using vtkPolyData to represent the point cloud via a >>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to >>> save on memory. >>> + The classes will process as input any vtkPointSet dataset >>> + There is a general framework for filtering point clouds via the class >>> vtkPointCloudFilter. Besides their filtered cloud output, these filters >>> also have an optional, second output which contains any points removed from >>> the input. >>> + Current filters include vtkRadiusOutlierRemoval, >>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>> implicit function). Some of these names are inspired by PCL >>> names. >>> + All filters are threaded using vtkSMPTools using a threaded locator >>> (vtkStaticPointLocator) so I believe that this is relatively fast, although >>> I have not done much testing. >>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote >>> that is very fast. >>> >>> As usual comments and suggestions are requested. In particular any >>> suggestions for other filters to write are welcome (to round out some of >>> the core functionality). The repository is in flux as I try crazy ideas and >>> try to educate myself, so be forewarned. >>> >>> Best, >>> W >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://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 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Jan 29 13:37:00 2016 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 29 Jan 2016 13:37:00 -0500 Subject: [vtk-developers] Ubuntu 14.04 OpenGL Message-ID: Folks, I am setting up a new Ubuntu 14.04 system. I've have the compilers, git, cmake, but what to I need to do to install opengl. This is the first of many dumb questions I'll be asking. Especially since I am an Ubuntu newbie. Thanks, Bill From aashish.chaudhary at kitware.com Fri Jan 29 13:51:49 2016 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 29 Jan 2016 13:51:49 -0500 Subject: [vtk-developers] Ubuntu 14.04 OpenGL In-Reply-To: References: Message-ID: You can install proprietary drivers (which will perform faster) or MESA GL. For MESA you can pretty much follow this article: https://nextdime.wordpress.com/2014/06/29/setting-up-an-opengl-mesa-development-environment-ubuntu-14-04/ On Fri, Jan 29, 2016 at 1:37 PM, Bill Lorensen wrote: > Folks, > > I am setting up a new Ubuntu 14.04 system. I've have the compilers, > git, cmake, but what to I need to do to install opengl. > > This is the first of many dumb questions I'll be asking. Especially > since I am an Ubuntu newbie. > > Thanks, > > 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 > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Fri Jan 29 14:38:38 2016 From: cory.quammen at kitware.com (Cory Quammen) Date: Fri, 29 Jan 2016 14:38:38 -0500 Subject: [vtk-developers] http support disabled on midas3.kitware.com Message-ID: Hi folks, The server that hosts VTK data -- midas3.kitware.com now supports only https, and does not support downloading via the http protocol. This may result in build errors when the test data is being downloaded. To address this error, the CMake client you used to configure VTK needs OpenSSL support. Newer binaries from cmake.org have this support. When building from source, this is not enabled by default -- enable the configuration option CMAKE_USE_OPENSSL. Cory -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerrick.Bivins at halliburton.com Fri Jan 29 15:59:04 2016 From: Gerrick.Bivins at halliburton.com (Gerrick Bivins) Date: Fri, 29 Jan 2016 20:59:04 +0000 Subject: [vtk-developers] [EXTERNAL] Ubuntu 14.04 OpenGL In-Reply-To: References: Message-ID: When I set mine up at home, I ended up going to ATI's site (I know , I know). I assume Nvidia has something similar. In general it worked. I did have minor trouble getting some of the advanced driver features enabled (I was trying to use aparapi) but a quick google search on the error got me going. Gerrick -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Bill Lorensen Sent: Friday, January 29, 2016 12:37 PM To: VTK Developers Subject: [EXTERNAL] [vtk-developers] Ubuntu 14.04 OpenGL Folks, I am setting up a new Ubuntu 14.04 system. I've have the compilers, git, cmake, but what to I need to do to install opengl. This is the first of many dumb questions I'll be asking. Especially since I am an Ubuntu newbie. Thanks, Bill _______________________________________________ Powered by https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=xW_rpkvdx3Px6lm5zMvoAuvrqQDmaVUjMcqcrfKesqA&e= Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=TOnxb19Nozpg_gh3teZpKcTjYFGBt5-MmYbFgHD39rg&e= Search the list archives at: https://urldefense.proofpoint.com/v2/url?u=http-3A__markmail.org_search_-3Fq-3Dvtk-2Ddevelopers&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=tAdqtJmgDHrI37MbE-jkUbzlJuXNSXKPxv9_OH4hAxo&e= Follow this link to subscribe/unsubscribe: https://urldefense.proofpoint.com/v2/url?u=http-3A__public.kitware.com_mailman_listinfo_vtk-2Ddevelopers&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=gs9-ss5drawH2VPWO_RYnvxJDcZEOLVCN8kUGQaiVeU&e= From gpwright at gmail.com Fri Jan 29 16:24:55 2016 From: gpwright at gmail.com (Geoff Wright) Date: Fri, 29 Jan 2016 21:24:55 +0000 Subject: [vtk-developers] [EXTERNAL] Ubuntu 14.04 OpenGL In-Reply-To: References: Message-ID: Hi Bill, If you have an nvidia graphics card then I would recommend using the graphics-drivers ppa. You can install the latest nvidia-3## package from here, e.g. sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt-get update sudo apt-get install nvidia-355 G On Fri, Jan 29, 2016 at 4:16 PM Gerrick Bivins < Gerrick.Bivins at halliburton.com> wrote: > When I set mine up at home, I ended up going to ATI's site (I know , I > know). > I assume Nvidia has something similar. > > In general it worked. I did have minor trouble getting some of the > advanced driver features enabled (I was trying to use aparapi) > but a quick google search on the error got me going. > > Gerrick > > -----Original Message----- > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of > Bill Lorensen > Sent: Friday, January 29, 2016 12:37 PM > To: VTK Developers > Subject: [EXTERNAL] [vtk-developers] Ubuntu 14.04 OpenGL > > Folks, > > I am setting up a new Ubuntu 14.04 system. I've have the compilers, git, > cmake, but what to I need to do to install opengl. > > This is the first of many dumb questions I'll be asking. Especially since > I am an Ubuntu newbie. > > Thanks, > > Bill > _______________________________________________ > Powered by > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=xW_rpkvdx3Px6lm5zMvoAuvrqQDmaVUjMcqcrfKesqA&e= > > Visit other Kitware open-source projects at > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=TOnxb19Nozpg_gh3teZpKcTjYFGBt5-MmYbFgHD39rg&e= > > Search the list archives at: > https://urldefense.proofpoint.com/v2/url?u=http-3A__markmail.org_search_-3Fq-3Dvtk-2Ddevelopers&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=tAdqtJmgDHrI37MbE-jkUbzlJuXNSXKPxv9_OH4hAxo&e= > > Follow this link to subscribe/unsubscribe: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__public.kitware.com_mailman_listinfo_vtk-2Ddevelopers&d=CwICAg&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dYPoPShFc1EqLn33Mo4Py4WqeXt1iYFFH8LtrXQrL0g&m=V1vVlN_BUzLWZRUtpCk9iOMUP_jlsBz8q7gdoLTQaOo&s=gs9-ss5drawH2VPWO_RYnvxJDcZEOLVCN8kUGQaiVeU&e= > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://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 Sat Jan 30 03:30:32 2016 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Sat, 30 Jan 2016 09:30:32 +0100 Subject: [vtk-developers] Ubuntu 14.04 OpenGL In-Reply-To: References: Message-ID: On Fri, Jan 29, 2016 at 7:37 PM, Bill Lorensen wrote: > Folks, > > I am setting up a new Ubuntu 14.04 system. I've have the compilers, > git, cmake, but what to I need to do to install opengl. On new machine(s), I generally do: $ sudo apt-get build-dep vtk or $ sudo apt-get build-dep vtk6 This will make sure to pull in any required dependencies in order to build vtk (as is done by upstream debian/ubuntu). As said also, this may not pull in hardware specific opengl implementation, you should be able to change that anytime you want. -M From will.schroeder at kitware.com Sat Jan 30 08:48:05 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Sat, 30 Jan 2016 08:48:05 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Okay I have a quick and dirty design for "file" format and algorithmic approach that I'll start implementing shortly. We'll clean it up with time. Any feedback is welcome. The data file format has three basic logical parts, which could be written into separate files or one file, whatever. 1) metadata, 2) offsets, and 3) sorted points. The key idea is that the points are in sorted order, beginning with level 0 root node, followed by level 1 bins (8 bins) and their points, and level 2 bins (64 bins) and their points, and so on. The points are just a contiguous array of x-y-z, x-y-z, of type float or double (user specified), etc. Data attributes could be stored in similar fashion (all easily changeable depending on what you prefer). Since the number of points in each bin is variable and may even be zero, this is where the offsets come into play. (Note that points are not repeated, and statistically sampled as you suggest ~1/(total number of bins)*NumberOfPoints points in each bin.) The offsets are integral values that simply refer to a position in the sorted points array corresponding to the beginning of each bin. So (level 0, bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), (1,7), (2,0), (2,1), ... you get the idea. For your example of a 3-level octree, there would be 73 offset values (or T=73 total bins). Note that if offset_i == offset_(i+1) then there are zero points in the bin referred to by offset_i. We can also represent the offsets with different integral types depending on the number of points (to save memory). The metadata contains something like (assuming multiple separate files, which of course can be memory mapped, etc): NumberOfPoints #npts NumberOfLevels #numLevels Divisions 2 2 2 Bounds (xmin,xmax,ymin,ymax,zmin,zmax) Points type "points.file" Offsets type "offsets.file" Array type numComp "scalars.file" Array type numComp "vectors.file" Note that the Divisions are variable, the structure does not have to be an octree. This is useful to produce bins that are closer to uniform shape, or even create a 2.5D, sorta flat binning tree (e.g. z-divisions always == 1). Algorithmic approach: (this can easily be threaded): For every point p_i in the input point cloud, generate a random number r (0<=r<1). Assume that there are T total bins. The probability (assuming an octree) that p_i is in level 0: is 1/T; in level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into proportional subranges that r maps into. Thus r will randomly select which level of the tree a point belongs in. Once p_i is assigned a level, compute a hash index h_i which consists of the (i,j,k) bin index added to T_l, there T_l is the total number of bins at the beginning of level l. This hash index is the key to get the sort in the right order; using the level information is a way to segment the bins from different levels into contiguous runs. Now sort the points based on this hash index. The sort is where most of the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted points list. Next create the offsets array by running through the sorted hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's easy to do, and can even be done in parallel.) >From the mapper point of view: knowing the bounds, divisions, current level, and (i,j,k) bin index it is possible to construct a local bounding box for each bin. Then there is direct access to the list of points in each bin (through the offsets). And of course since this is a hierarchy of uniform bins, you can easily perform view culling etc. and choose the appropriate level for LODs. That's it in a nutshell. Unfortunately I've got lots of pointy-haired boss stuff to do so this might take a bit to complete, but I'd really like to get a prototype class written this week (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) Initially I'll have this class build the data structures, with a special back-door method to write the data out. Later on we'll decide if we need to separate this backdoor IO into a separate class, etc. Best, W On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin wrote: > Thanks Will. I promise I'll write the mapper :-) The PTS reader is a > simple ascii X Y Z R G B type format that I usually immediately convert to > VTK XML format as that is far faster and more compact. So unfortunately PTS > is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some > bounding box metadata. > > Ken > > On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Ken- >> >> I am totally with you. I am writing some simple stuff at the moment like >> VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to >> get my head around the challenges and serve as a stop gap until our better >> stuff comes along. I really like your idea and I do plan to implement this; >> it's really not too hard to do from what I understand and given the pieces >> available in VTK. >> >> So I'll wrap up this simple VoxelGrid and then take a crack at the beast >> you've envisioned. The two major pieces seems to be 1) create a class that >> builds the hierarchical structure, and 2) write a reader/writer pair that >> can perform associated IO. In an earlier email you mentioned a PTS reader >> that you made improvement to; is this a good exemplar data format or do you >> have a better starting point? >> >> It seems I have a homework assignment for the weekend :-) >> >> Best, >> W >> >> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >> wrote: >> >>> Nice, can I make a specific request Will? :-) Part of what I want to do >>> for large point clouds is something like the following: >>> >>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>> pieces (but not the data) >>> >>> 2) Read in the first piece and use it for rendering >>> >>> 3) In the background read in more pieces, as they are loaded make them >>> available to the mapper >>> >>> 4) The mapper based on the current camera parameters and bounding boxes >>> of the pieces intelligently selects what pieces to render. This provides a >>> happy fast interactive experience leading to world peace. >>> >>> For this to work well my thought was to have the pieces be broken up in >>> a special way sort of like an octree but a spatial hash etc would be just >>> as good as long as it is hierarchical and structured. Think of breaking up >>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the >>> data covering the entire bounding box. The next eight pieces also each >>> contain about 1/73 of the data each constrained by their octant of the >>> bounding box. Same idea for the next 64 boxes, they are just one level >>> further down. This would work really well for a smart mapper providing >>> fast first render plus fast LOD/subsequent renders. I can implement 1-4 >>> pretty quickly. >>> >>> But .... for it to work I need someone to create the 73 piece file the >>> right way. (it does not have to be 73, and clearly some of those 73 will be >>> empty, it just needs to be hierarchical and structured so that a group of >>> pieces can be represented at a lower level of detail by some other piece) >>> My gut feeling was to have the LOD pieces use actual points of the dataset >>> (not centroids or similar) that way as more pieces are loaded we are just >>> providing more detail, not replacing fake data (centroids) with real data. >>> But really either approach is pretty easy to implement in the mapper. The >>> latter approach just means the entire dataset footprint is larger because >>> some of the points are not part of the full res dataset because you >>> generated them. >>> >>> I could be totally off base but that was my gut feeling on rendering > >>> 2GB point clouds in a nice zippy manner. >>> >>> TLDR: I want someone to write a filter/writer subclass to create a >>> special 73 piece vtk file :-) >>> >>> Ken >>> >>> >>> >>> >>> >>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> Geoff- >>>> >>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>> threaded and seems to be fast. >>>> >>>> Question for you before I push the work to the repository: averaging >>>> points in each bin provides a nice subsampled point position. But what do >>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>> could be averaged too. There are however other options like finding the >>>> closest point to the subsampled point and using those attribute values, or >>>> if you want to get really fancy, using an interpolation kernel to >>>> interpolate to the subsampled point. >>>> >>>> Thoughts? >>>> W >>>> >>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> Thanks for the feedback. I have some downsampling filters in the works >>>>> now, I'll let you know when I have something ready. >>>>> >>>>> BTW we are on a similar path. PCL is awesome, but we have some common >>>>> workflows that would be better served with more compact software >>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>> knock of a small kernel of capability to achieve this. >>>>> >>>>> Best, >>>>> W >>>>> >>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>> wrote: >>>>> >>>>>> Hi Will, >>>>>> >>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>> from some point cloud data. I have some initial pre processing steps that >>>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>>> eliminate the PCL dependency and use exclusively vtk. My point >>>>>> cloud data grows very large over time with a lot of redundant points so its >>>>>> very important to downsample them onto uniform spacing ( >>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>>> before processing them in vtk. Would it make sense to add something like >>>>>> this to your library? >>>>>> >>>>>> Geoff >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>>> will.schroeder at kitware.com> wrote: >>>>>> >>>>>>> FYI- I have committed an initial set of filters for performing point >>>>>>> cloud processing. Any feedback or suggestions are welcome as this is an >>>>>>> initial prototype. The work is currently available as a remote module to >>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>> >>>>>>> A couple of notes: >>>>>>> + Right now I am using vtkPolyData to represent the point cloud via >>>>>>> a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created >>>>>>> to save on memory. >>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>> + There is a general framework for filtering point clouds via the >>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>> filters also have an optional, second output which contains any points >>>>>>> removed from the input. >>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>> implicit function). Some of these names are inspired by PCL >>>>>>> names. >>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>> although I have not done much testing. >>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>> wrote that is very fast. >>>>>>> >>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>>> try to educate myself, so be forewarned. >>>>>>> >>>>>>> Best, >>>>>>> W >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://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 >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://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. >>> >> >> >> >> -- >> 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 >> > > > > -- > 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. > -- 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 Sat Jan 30 11:26:09 2016 From: ken.martin at kitware.com (Ken Martin) Date: Sat, 30 Jan 2016 11:26:09 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Cool. I was thinking you would piggyback on an existing vtkXML*Writer as they have a ton of functionality already built in. I'm not a XML*Writer expert but they definitely support a lot of cool features including zlib compression, pieces, multiple files. Ken On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder wrote: > Okay I have a quick and dirty design for "file" format and algorithmic > approach that I'll start implementing shortly. We'll clean it up with time. > Any feedback is welcome. > > The data file format has three basic logical parts, which could be written > into separate files or one file, whatever. 1) metadata, 2) offsets, and 3) > sorted points. > > The key idea is that the points are in sorted order, beginning with level > 0 root node, followed by level 1 bins (8 bins) and their points, and level > 2 bins (64 bins) and their points, and so on. The points are just a > contiguous array of x-y-z, x-y-z, of type float or double (user specified), > etc. Data attributes could be stored in similar fashion (all easily > changeable depending on what you prefer). Since the number of points in > each bin is variable and may even be zero, this is where the offsets come > into play. (Note that points are not repeated, and statistically sampled as > you suggest ~1/(total number of bins)*NumberOfPoints points in each bin.) > > The offsets are integral values that simply refer to a position in the > sorted points array corresponding to the beginning of each bin. So (level > 0, bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), > (1,7), (2,0), (2,1), ... you get the idea. For your example of a 3-level > octree, there would be 73 offset values (or T=73 total bins). Note that if > offset_i == offset_(i+1) then there are zero points in the bin referred to > by offset_i. We can also represent the offsets with different integral > types depending on the number of points (to save memory). > > The metadata contains something like (assuming multiple separate files, > which of course can be memory mapped, etc): > NumberOfPoints #npts > NumberOfLevels #numLevels > Divisions 2 2 2 > Bounds (xmin,xmax,ymin,ymax,zmin,zmax) > Points type "points.file" > Offsets type "offsets.file" > Array type numComp "scalars.file" > Array type numComp "vectors.file" > > Note that the Divisions are variable, the structure does not have to be an > octree. This is useful to produce bins that are closer to uniform shape, or > even create a 2.5D, sorta flat binning tree (e.g. z-divisions always == 1). > > Algorithmic approach: (this can easily be threaded): > For every point p_i in the input point cloud, generate a random number r > (0<=r<1). Assume that there are T total bins. > The probability (assuming an octree) that p_i is in level 0: is 1/T; in > level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into > proportional subranges that r maps into. Thus r will randomly select which > level of the tree a point belongs in. > > Once p_i is assigned a level, compute a hash index h_i which consists of > the (i,j,k) bin index added to T_l, there T_l is the total number of bins > at the beginning of level l. This hash index is the key to get the sort in > the right order; using the level information is a way to segment the bins > from different levels into contiguous runs. > > Now sort the points based on this hash index. The sort is where most of > the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted > points list. Next create the offsets array by running through the sorted > hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's > easy to do, and can even be done in parallel.) > > From the mapper point of view: knowing the bounds, divisions, current > level, and (i,j,k) bin index it is possible to construct a local bounding > box for each bin. Then there is direct access to the list of points in each > bin (through the offsets). And of course since this is a hierarchy of > uniform bins, you can easily perform view culling etc. and choose the > appropriate level for LODs. > > That's it in a nutshell. Unfortunately I've got lots of pointy-haired boss > stuff to do so this might take a bit to complete, but I'd really like to > get a prototype class written this week > (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) > Initially I'll have this class build the data structures, with a special > back-door method to write the data out. Later on we'll decide if we need to > separate this backdoor IO into a separate class, etc. > > Best, > W > > > On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin > wrote: > >> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a >> simple ascii X Y Z R G B type format that I usually immediately convert to >> VTK XML format as that is far faster and more compact. So unfortunately PTS >> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some >> bounding box metadata. >> >> Ken >> >> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Ken- >>> >>> I am totally with you. I am writing some simple stuff at the moment like >>> VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to >>> get my head around the challenges and serve as a stop gap until our better >>> stuff comes along. I really like your idea and I do plan to implement this; >>> it's really not too hard to do from what I understand and given the pieces >>> available in VTK. >>> >>> So I'll wrap up this simple VoxelGrid and then take a crack at the beast >>> you've envisioned. The two major pieces seems to be 1) create a class that >>> builds the hierarchical structure, and 2) write a reader/writer pair that >>> can perform associated IO. In an earlier email you mentioned a PTS reader >>> that you made improvement to; is this a good exemplar data format or do you >>> have a better starting point? >>> >>> It seems I have a homework assignment for the weekend :-) >>> >>> Best, >>> W >>> >>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >>> wrote: >>> >>>> Nice, can I make a specific request Will? :-) Part of what I want to do >>>> for large point clouds is something like the following: >>>> >>>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>>> pieces (but not the data) >>>> >>>> 2) Read in the first piece and use it for rendering >>>> >>>> 3) In the background read in more pieces, as they are loaded make them >>>> available to the mapper >>>> >>>> 4) The mapper based on the current camera parameters and bounding boxes >>>> of the pieces intelligently selects what pieces to render. This provides a >>>> happy fast interactive experience leading to world peace. >>>> >>>> For this to work well my thought was to have the pieces be broken up in >>>> a special way sort of like an octree but a spatial hash etc would be just >>>> as good as long as it is hierarchical and structured. Think of breaking up >>>> the volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the >>>> data covering the entire bounding box. The next eight pieces also each >>>> contain about 1/73 of the data each constrained by their octant of the >>>> bounding box. Same idea for the next 64 boxes, they are just one level >>>> further down. This would work really well for a smart mapper providing >>>> fast first render plus fast LOD/subsequent renders. I can implement 1-4 >>>> pretty quickly. >>>> >>>> But .... for it to work I need someone to create the 73 piece file the >>>> right way. (it does not have to be 73, and clearly some of those 73 will be >>>> empty, it just needs to be hierarchical and structured so that a group of >>>> pieces can be represented at a lower level of detail by some other piece) >>>> My gut feeling was to have the LOD pieces use actual points of the dataset >>>> (not centroids or similar) that way as more pieces are loaded we are just >>>> providing more detail, not replacing fake data (centroids) with real data. >>>> But really either approach is pretty easy to implement in the mapper. The >>>> latter approach just means the entire dataset footprint is larger because >>>> some of the points are not part of the full res dataset because you >>>> generated them. >>>> >>>> I could be totally off base but that was my gut feeling on rendering > >>>> 2GB point clouds in a nice zippy manner. >>>> >>>> TLDR: I want someone to write a filter/writer subclass to create a >>>> special 73 piece vtk file :-) >>>> >>>> Ken >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> Geoff- >>>>> >>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>>> threaded and seems to be fast. >>>>> >>>>> Question for you before I push the work to the repository: averaging >>>>> points in each bin provides a nice subsampled point position. But what do >>>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>>> could be averaged too. There are however other options like finding the >>>>> closest point to the subsampled point and using those attribute values, or >>>>> if you want to get really fancy, using an interpolation kernel to >>>>> interpolate to the subsampled point. >>>>> >>>>> Thoughts? >>>>> W >>>>> >>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> Thanks for the feedback. I have some downsampling filters in the >>>>>> works now, I'll let you know when I have something ready. >>>>>> >>>>>> BTW we are on a similar path. PCL is awesome, but we have some common >>>>>> workflows that would be better served with more compact software >>>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>>> knock of a small kernel of capability to achieve this. >>>>>> >>>>>> Best, >>>>>> W >>>>>> >>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>>> wrote: >>>>>> >>>>>>> Hi Will, >>>>>>> >>>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>>> from some point cloud data. I have some initial pre processing steps that >>>>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>>>> eliminate the PCL dependency and use exclusively vtk. My point >>>>>>> cloud data grows very large over time with a lot of redundant points so its >>>>>>> very important to downsample them onto uniform spacing ( >>>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>>>> before processing them in vtk. Would it make sense to add something like >>>>>>> this to your library? >>>>>>> >>>>>>> Geoff >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>>>> will.schroeder at kitware.com> wrote: >>>>>>> >>>>>>>> FYI- I have committed an initial set of filters for performing >>>>>>>> point cloud processing. Any feedback or suggestions are welcome as this is >>>>>>>> an initial prototype. The work is currently available as a remote module to >>>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>>> >>>>>>>> A couple of notes: >>>>>>>> + Right now I am using vtkPolyData to represent the point cloud via >>>>>>>> a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created >>>>>>>> to save on memory. >>>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>>> + There is a general framework for filtering point clouds via the >>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>>> filters also have an optional, second output which contains any points >>>>>>>> removed from the input. >>>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>>> implicit function). Some of these names are inspired by PCL >>>>>>>> names. >>>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>>> although I have not done much testing. >>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>>> wrote that is very fast. >>>>>>>> >>>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>>>> try to educate myself, so be forewarned. >>>>>>>> >>>>>>>> Best, >>>>>>>> W >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://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 >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://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. >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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. >> > > > > -- > 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 > -- 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 will.schroeder at kitware.com Sat Jan 30 11:49:24 2016 From: will.schroeder at kitware.com (Will Schroeder) Date: Sat, 30 Jan 2016 11:49:24 -0500 Subject: [vtk-developers] vtkPointCloud remote module In-Reply-To: References: Message-ID: Exactly right. I'll generate the data and then figure out the IO. -- Sent from mobile phone please excuse typos and terseness On Jan 30, 2016 11:26 AM, "Ken Martin" wrote: > Cool. I was thinking you would piggyback on an existing vtkXML*Writer as > they have a ton of functionality already built in. I'm not a XML*Writer > expert but they definitely support a lot of cool features including zlib > compression, pieces, multiple files. > > Ken > > > On Sat, Jan 30, 2016 at 8:48 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Okay I have a quick and dirty design for "file" format and algorithmic >> approach that I'll start implementing shortly. We'll clean it up with time. >> Any feedback is welcome. >> >> The data file format has three basic logical parts, which could be >> written into separate files or one file, whatever. 1) metadata, 2) offsets, >> and 3) sorted points. >> >> The key idea is that the points are in sorted order, beginning with level >> 0 root node, followed by level 1 bins (8 bins) and their points, and level >> 2 bins (64 bins) and their points, and so on. The points are just a >> contiguous array of x-y-z, x-y-z, of type float or double (user specified), >> etc. Data attributes could be stored in similar fashion (all easily >> changeable depending on what you prefer). Since the number of points in >> each bin is variable and may even be zero, this is where the offsets come >> into play. (Note that points are not repeated, and statistically sampled as >> you suggest ~1/(total number of bins)*NumberOfPoints points in each bin.) >> >> The offsets are integral values that simply refer to a position in the >> sorted points array corresponding to the beginning of each bin. So (level >> 0, bin 0), (level 1, bin 0), (1,1), (1,2), (1,3), (1,4), (1,5), (1,6), >> (1,7), (2,0), (2,1), ... you get the idea. For your example of a 3-level >> octree, there would be 73 offset values (or T=73 total bins). Note that if >> offset_i == offset_(i+1) then there are zero points in the bin referred to >> by offset_i. We can also represent the offsets with different integral >> types depending on the number of points (to save memory). >> >> The metadata contains something like (assuming multiple separate files, >> which of course can be memory mapped, etc): >> NumberOfPoints #npts >> NumberOfLevels #numLevels >> Divisions 2 2 2 >> Bounds (xmin,xmax,ymin,ymax,zmin,zmax) >> Points type "points.file" >> Offsets type "offsets.file" >> Array type numComp "scalars.file" >> Array type numComp "vectors.file" >> >> Note that the Divisions are variable, the structure does not have to be >> an octree. This is useful to produce bins that are closer to uniform shape, >> or even create a 2.5D, sorta flat binning tree (e.g. z-divisions always == >> 1). >> >> Algorithmic approach: (this can easily be threaded): >> For every point p_i in the input point cloud, generate a random number r >> (0<=r<1). Assume that there are T total bins. >> The probability (assuming an octree) that p_i is in level 0: is 1/T; in >> level 1: 8/T; in level 2: 64/T and so on. Segment the range [0,1) into >> proportional subranges that r maps into. Thus r will randomly select which >> level of the tree a point belongs in. >> >> Once p_i is assigned a level, compute a hash index h_i which consists of >> the (i,j,k) bin index added to T_l, there T_l is the total number of bins >> at the beginning of level l. This hash index is the key to get the sort in >> the right order; using the level information is a way to segment the bins >> from different levels into contiguous runs. >> >> Now sort the points based on this hash index. The sort is where most of >> the work is done and we'll use vtkSMPTools::Sort(). This produces a sorted >> points list. Next create the offsets array by running through the sorted >> hash indices, etc. (I've done this before in vtkStaticPointsLocator, it's >> easy to do, and can even be done in parallel.) >> >> From the mapper point of view: knowing the bounds, divisions, current >> level, and (i,j,k) bin index it is possible to construct a local bounding >> box for each bin. Then there is direct access to the list of points in each >> bin (through the offsets). And of course since this is a hierarchy of >> uniform bins, you can easily perform view culling etc. and choose the >> appropriate level for LODs. >> >> That's it in a nutshell. Unfortunately I've got lots of pointy-haired >> boss stuff to do so this might take a bit to complete, but I'd really like >> to get a prototype class written this week >> (vtkPointCloud/vtkHierarchicalBinningFilter), it's got me revved up :-) >> Initially I'll have this class build the data structures, with a special >> back-door method to write the data out. Later on we'll decide if we need to >> separate this backdoor IO into a separate class, etc. >> >> Best, >> W >> >> >> On Fri, Jan 29, 2016 at 12:15 PM, Ken Martin >> wrote: >> >>> Thanks Will. I promise I'll write the mapper :-) The PTS reader is a >>> simple ascii X Y Z R G B type format that I usually immediately convert to >>> VTK XML format as that is far faster and more compact. So unfortunately PTS >>> is not it. I am thinking a vtkXMLPolyDataWriter subclass that adds some >>> bounding box metadata. >>> >>> Ken >>> >>> On Fri, Jan 29, 2016 at 11:08 AM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> Ken- >>>> >>>> I am totally with you. I am writing some simple stuff at the moment >>>> like VoxelGrid as sort of a "drop-in" replacements for PCL workflows; >>>> mostly to get my head around the challenges and serve as a stop gap until >>>> our better stuff comes along. I really like your idea and I do plan to >>>> implement this; it's really not too hard to do from what I understand and >>>> given the pieces available in VTK. >>>> >>>> So I'll wrap up this simple VoxelGrid and then take a crack at the >>>> beast you've envisioned. The two major pieces seems to be 1) create a class >>>> that builds the hierarchical structure, and 2) write a reader/writer pair >>>> that can perform associated IO. In an earlier email you mentioned a PTS >>>> reader that you made improvement to; is this a good exemplar data format or >>>> do you have a better starting point? >>>> >>>> It seems I have a homework assignment for the weekend :-) >>>> >>>> Best, >>>> W >>>> >>>> On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin >>>> wrote: >>>> >>>>> Nice, can I make a specific request Will? :-) Part of what I want to >>>>> do for large point clouds is something like the following: >>>>> >>>>> 1) Open a VTK multipiece file and read in the bounding boxes of the >>>>> pieces (but not the data) >>>>> >>>>> 2) Read in the first piece and use it for rendering >>>>> >>>>> 3) In the background read in more pieces, as they are loaded make them >>>>> available to the mapper >>>>> >>>>> 4) The mapper based on the current camera parameters and bounding >>>>> boxes of the pieces intelligently selects what pieces to render. This >>>>> provides a happy fast interactive experience leading to world peace. >>>>> >>>>> For this to work well my thought was to have the pieces be broken up >>>>> in a special way sort of like an octree but a spatial hash etc would be >>>>> just as good as long as it is hierarchical and structured. Think of >>>>> breaking up the volume into 1 + 8 + 64 pieces. The first piece contains >>>>> ~1/73 of the data covering the entire bounding box. The next eight pieces >>>>> also each contain about 1/73 of the data each constrained by their octant >>>>> of the bounding box. Same idea for the next 64 boxes, they are just one >>>>> level further down. This would work really well for a smart mapper >>>>> providing fast first render plus fast LOD/subsequent renders. I can >>>>> implement 1-4 pretty quickly. >>>>> >>>>> But .... for it to work I need someone to create the 73 piece file the >>>>> right way. (it does not have to be 73, and clearly some of those 73 will be >>>>> empty, it just needs to be hierarchical and structured so that a group of >>>>> pieces can be represented at a lower level of detail by some other piece) >>>>> My gut feeling was to have the LOD pieces use actual points of the dataset >>>>> (not centroids or similar) that way as more pieces are loaded we are just >>>>> providing more detail, not replacing fake data (centroids) with real data. >>>>> But really either approach is pretty easy to implement in the mapper. The >>>>> latter approach just means the entire dataset footprint is larger because >>>>> some of the points are not part of the full res dataset because you >>>>> generated them. >>>>> >>>>> I could be totally off base but that was my gut feeling on rendering > >>>>> 2GB point clouds in a nice zippy manner. >>>>> >>>>> TLDR: I want someone to write a filter/writer subclass to create a >>>>> special 73 piece vtk file :-) >>>>> >>>>> Ken >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> Geoff- >>>>>> >>>>>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's >>>>>> threaded and seems to be fast. >>>>>> >>>>>> Question for you before I push the work to the repository: averaging >>>>>> points in each bin provides a nice subsampled point position. But what do >>>>>> you think we should do for attributes (e.g., scalars, vector, etc.)? These >>>>>> could be averaged too. There are however other options like finding the >>>>>> closest point to the subsampled point and using those attribute values, or >>>>>> if you want to get really fancy, using an interpolation kernel to >>>>>> interpolate to the subsampled point. >>>>>> >>>>>> Thoughts? >>>>>> W >>>>>> >>>>>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder < >>>>>> will.schroeder at kitware.com> wrote: >>>>>> >>>>>>> Thanks for the feedback. I have some downsampling filters in the >>>>>>> works now, I'll let you know when I have something ready. >>>>>>> >>>>>>> BTW we are on a similar path. PCL is awesome, but we have some >>>>>>> common workflows that would be better served with more compact software >>>>>>> environments, and with minimal IO and/or data transfer. So we're trying to >>>>>>> knock of a small kernel of capability to achieve this. >>>>>>> >>>>>>> Best, >>>>>>> W >>>>>>> >>>>>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Will, >>>>>>>> >>>>>>>> This is good to see. I'm currently using VTK to generate surfaces >>>>>>>> from some point cloud data. I have some initial pre processing steps that >>>>>>>> I use PCL (point cloud library) for, and then a vtk stage that converts PCL >>>>>>>> point cloud into vtkPolyData/vtkPoints. It would be great to >>>>>>>> eliminate the PCL dependency and use exclusively vtk. My point >>>>>>>> cloud data grows very large over time with a lot of redundant points so its >>>>>>>> very important to downsample them onto uniform spacing ( >>>>>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html ) >>>>>>>> before processing them in vtk. Would it make sense to add something like >>>>>>>> this to your library? >>>>>>>> >>>>>>>> Geoff >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder < >>>>>>>> will.schroeder at kitware.com> wrote: >>>>>>>> >>>>>>>>> FYI- I have committed an initial set of filters for performing >>>>>>>>> point cloud processing. Any feedback or suggestions are welcome as this is >>>>>>>>> an initial prototype. The work is currently available as a remote module to >>>>>>>>> VTK (vtkPointCloud) via this repository: >>>>>>>>> https://gitlab.kitware.com/vtk/point-cloud.git >>>>>>>>> >>>>>>>>> A couple of notes: >>>>>>>>> + Right now I am using vtkPolyData to represent the point cloud >>>>>>>>> via a vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells >>>>>>>>> created to save on memory. >>>>>>>>> + The classes will process as input any vtkPointSet dataset >>>>>>>>> + There is a general framework for filtering point clouds via the >>>>>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these >>>>>>>>> filters also have an optional, second output which contains any points >>>>>>>>> removed from the input. >>>>>>>>> + Current filters include vtkRadiusOutlierRemoval, >>>>>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an >>>>>>>>> implicit function). Some of these names are inspired by PCL >>>>>>>>> names. >>>>>>>>> + All filters are threaded using vtkSMPTools using a threaded >>>>>>>>> locator (vtkStaticPointLocator) so I believe that this is relatively fast, >>>>>>>>> although I have not done much testing. >>>>>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken >>>>>>>>> wrote that is very fast. >>>>>>>>> >>>>>>>>> As usual comments and suggestions are requested. In particular any >>>>>>>>> suggestions for other filters to write are welcome (to round out some of >>>>>>>>> the core functionality). The repository is in flux as I try crazy ideas and >>>>>>>>> try to educate myself, so be forewarned. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> W >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://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 >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://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. >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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. >>> >> >> >> >> -- >> 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 >> > > > > -- > 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: