From stas.truhan at gmail.com Thu Nov 1 05:34:06 2018 From: stas.truhan at gmail.com (take5v) Date: Thu, 1 Nov 2018 02:34:06 -0700 (MST) Subject: [vtk-developers] QVTKRenderWindowInteractor bug in Mac OS In-Reply-To: References: <1540992073353-0.post@n5.nabble.com> <20181031133801.572991736@mail.rogue-research.com> <1540993325645-0.post@n5.nabble.com> <1540998905857-0.post@n5.nabble.com> <1541002553335-0.post@n5.nabble.com> <1541005045046-0.post@n5.nabble.com> <1541026668499-0.post@n5.nabble.com> Message-ID: <1541064846514-0.post@n5.nabble.com> Hi all, I uploaded a video of my screen to confirm the inconsistent performance behavior during window/level changing, please have a look. I tested completely the same script and on the same environment. https://www.dropbox.com/s/jresoj5tf2fumpt/vtk_window_level_performance_inconsistency.mp4?dl=0 Environment: Windows 10 Python 3.6.4 PyQt5 5.10.1 vtk-python 8.1.1 CPU Intel i7-3770K GPU GeForce GTX 680 Nvidia driver 411.31 Display LG IPS277L Best regards, Stas ----- Best regards, Stanislau Trukhan -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From dave.demarle at kitware.com Thu Nov 1 12:36:31 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 1 Nov 2018 12:36:31 -0400 Subject: [vtk-developers] VTK 8.2 and deprecation of visual studio 2013 Message-ID: Hi folks, A couple of items for the group. 1. I am going to branch for VTK 8.2 on Monday. We'll do release candidates so you can expect 8.2.0 to be out in about a month. I will also put out a VTK 8.1.2 on Monday. This is what is now in the release branch. It has just a couple of fixes in it over 8.1.1. 2. We are going to deprecate Visual Studio 2013 support in 8.2. The reason being that we need the more complete C++11 feature set in VS 2015. 8.2 will still work with VS 2013, you will just get a warning when you configure it with CMake. At some point after the 8.2 branch, VTK master will no longer build with 2013. You feedback on either item is appreciated. thanks David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jl at jluk.de Thu Nov 1 12:53:47 2018 From: jl at jluk.de (Jonas Lukasczyk) Date: Thu, 01 Nov 2018 17:53:47 +0100 Subject: [vtk-developers] VTK Dynamic Streaming In-Reply-To: <1175210737.371846.1541089748845@webmail.strato.de> References: <1175210737.371846.1541089748845@webmail.strato.de> Message-ID: <3A6557A3-F230-4315-9659-1702AB28FDD1@jluk.de> Hi everyone, I got the vtkStreamingExample (https://blog.kitware.com/streaming-in-vtk-time/) to work, but I'm not able to set the number of timesteps dynamically. This is the logic I have so far: * I have a temporal streaming source and consumer. * The source sets the number of timesteps in RequestInformation * The consumer asks for a timestep in RequestUpdateExtent * The source produces the requested timestep in RequestData * The consumer processes the timestep * The consumer requests another timestep if we did not reach the number of timesteps yet My problem is that I can not determine the number of timesteps during the RequestInformation calls as this is a dynamic variable that is computed during the RequestData execution of the source. Is there a way I can force an update of "vtk.vtkStreamingDemandDrivenPipeline.TIME_STEPS()" so the consumer knows when to stop requesting data? I know there exist workarounds with field data / multiple outputs and so on, but I wanted to know if there is a cleaner pipeline-based mechanism. Best Jonas Lukasczyk From elvis.stansvik at orexplore.com Thu Nov 1 13:04:19 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 1 Nov 2018 18:04:19 +0100 Subject: [vtk-developers] VTK 8.2 and deprecation of visual studio 2013 In-Reply-To: References: Message-ID: Den tors 1 nov. 2018 17:36David E DeMarle skrev: > Hi folks, > > A couple of items for the group. > > 1. I am going to branch for VTK 8.2 on Monday. We'll do release candidates > so you can expect 8.2.0 to be out in about a month. I will also put out a > VTK 8.1.2 on Monday. This is what is now in the release branch. It has just > a couple of fixes in it over 8.1.1. > > 2. We are going to deprecate Visual Studio 2013 support in 8.2. The reason > being that we need the more complete C++11 feature set in VS 2015. 8.2 will > still work with VS 2013, you will just get a warning when you configure it > with CMake. At some point after the 8.2 branch, VTK master will no longer > build with 2013. > > You feedback on either item is appreciated. > All sounds sensible, so only positive feedback here. We're on VS 2015, planning to move to 2017 soon. Elvis > thanks > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Nov 2 06:34:38 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 2 Nov 2018 06:34:38 -0400 Subject: [vtk-developers] New class for contouring unstructured grids Message-ID: If you are interested in a new class for fast contouring of 3D unstructured grids, read on. The class VTK/Filters/Core/vtkContour3DLinearGrid is a threaded, high-performance filter for generating isocontours from unstructured grids. It is specialized for 3D linear cells: any combination of tetrahedra, hexahedra, voxels, pyramids, and/or wedges. (Other cell types are skipped.) In practice we routinely see 10-20x speed ups. In an extreme case we saw a 1000x speedup (a customer's tetrahedral mesh with over 500millions tets). Of course this depends on the number of threads and the particulars of the data so YMMV. By default the class has a fast path where it just generates output triangles and points, and the points are not merged (i.e., coincident points exist in the output). Other available features, at the cost of some speed, are point merging, attribute interpolation, and/or point normal generation. (Note that for dense input meshes the fast path often produces acceptable results; other options can be enabled as needed or in a progressive rendering approach.) The speed comes from 1) threading, 2) a new edge locator (vtkStaticEdgeLocatorTemplate.h/.txx) which identifies coincident points by sorting edge tuples (v0,v1), 3) templating, and 4) better and more efficient algorithm design. In particular,#2) above: contouring in VTK typically relies on point locators to merge coincident points. This is not only a parallel computing bottleneck, but the locator binning can execute very slowly when lots of points fall into the same locator bin. (For example: an unstructured mesh that resolves tiny flow features like a boundary layer etc.) The edge locator eliminates this behavior. Furthermore, duplicate points are identified by using a parallel sort of edge tuples using vtkSMPTools:Sort() - much faster than the point locator's InsertUniquePoint(). The effect of threading on performance is modest - it doesn't scale all that well on the tests we've tried. My guess is that the data bus is saturated as the algorithm does a small amount of computation which can produce a large amount of output. (Set the CMake variable VTK_SMP_IMPLEMENTATION_TYPE to something other than Sequential- I use TBB - to enable threading. See this blog for more information.) Like any new algorithm I'm sure there are issues. If you are so inclined, please try the filter and provide feedback. At some point we'll integrate the algorithm into ParaView but it may be awhile as we are swamped :-) Best, -- 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 mathieu.westphal at kitware.com Mon Nov 5 08:22:27 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 5 Nov 2018 14:22:27 +0100 Subject: [vtk-developers] VTK/ParaView beginner course in March 2019 Message-ID: Hello list, Kitware will be holding a 2-day VTK and ParaView course on May 19th and 20th 2017 in Lyon, France. Please visit our web site for more information and registration details at VTK : https://training.kitware.fr/browse/205 ParaView : https://training.kitware.fr/browse/206 Note that the course will be taught in English. If you have any question, please contact us at formations at kitware.fr Thank you, Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Nov 5 08:36:41 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 5 Nov 2018 08:36:41 -0500 Subject: [vtk-developers] [vtkusers] New class for contouring unstructured grids In-Reply-To: References: Message-ID: Jeff- This would be easily done and could be added as an option to the filter. What happens now is that the "t" is computed for each edge tuple (v0,v1) and then used to interpolate attributes and points (the points where the contour intersects each edge). So the t value and edge tuple array (I suppose a 2-component vtkIdArray) could just be output. It's probably best if a new filter were created to do the interpolation from t and (v0,v1) arrays. Does that make sense / is that what you had in mind? Best, W On Fri, Nov 2, 2018 at 8:39 AM Jeff Lee wrote: > Nice work Will, > I was thinking that there should be a vtk way to associate edges/weights > with their input mesh for faster attribute interpolation (when contour > value is not changing). The times where it is useful depends on the > workflow, but its cheap enough to store intersected edges and the weights > somewhere (as field data in the contour). I haven't looked at the code yet > so you may have already done this. I did this in my prior work but could > (probably will) repeat but contribute to vtk. > Best, > Jeff > > On Fri, Nov 2, 2018 at 6:34 AM Will Schroeder > wrote: > >> If you are interested in a new class for fast contouring of 3D >> unstructured grids, read on. >> >> The class VTK/Filters/Core/vtkContour3DLinearGrid is a threaded, >> high-performance filter for generating isocontours from unstructured grids. >> It is specialized for 3D linear cells: any combination of tetrahedra, >> hexahedra, voxels, pyramids, and/or wedges. (Other cell types are skipped.) >> >> In practice we routinely see 10-20x speed ups. In an extreme case we saw >> a 1000x speedup (a customer's tetrahedral mesh with over 500millions tets). >> Of course this depends on the number of threads and the particulars of the >> data so YMMV. >> >> By default the class has a fast path where it just generates output >> triangles and points, and the points are not merged (i.e., coincident >> points exist in the output). Other available features, at the cost of some >> speed, are point merging, attribute interpolation, and/or point normal >> generation. (Note that for dense input meshes the fast path often produces >> acceptable results; other options can be enabled as needed or in a >> progressive rendering approach.) >> >> The speed comes from 1) threading, 2) a new edge locator >> (vtkStaticEdgeLocatorTemplate.h/.txx) which identifies coincident points by >> sorting edge tuples (v0,v1), 3) templating, and 4) better and more >> efficient algorithm design. >> >> In particular,#2) above: contouring in VTK typically relies on point >> locators to merge coincident points. This is not only a parallel computing >> bottleneck, but the locator binning can execute very slowly when lots of >> points fall into the same locator bin. (For example: an unstructured mesh >> that resolves tiny flow features like a boundary layer etc.) The edge >> locator eliminates this behavior. Furthermore, duplicate points are >> identified by using a parallel sort of edge tuples using vtkSMPTools:Sort() >> - much faster than the point locator's InsertUniquePoint(). >> >> The effect of threading on performance is modest - it doesn't scale all >> that well on the tests we've tried. My guess is that the data bus is >> saturated as the algorithm does a small amount of computation which can >> produce a large amount of output. (Set the CMake variable >> VTK_SMP_IMPLEMENTATION_TYPE to something other than Sequential- I use TBB - >> to enable threading. See this blog >> for >> more information.) >> >> Like any new algorithm I'm sure there are issues. If you are so inclined, >> please try the filter and provide feedback. At some point we'll integrate >> the algorithm into ParaView but it may be awhile as we are swamped :-) >> >> Best, >> >> -- >> 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 >> >> 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: >> https://public.kitware.com/mailman/listinfo/vtkusers >> > -- 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 mathieu.westphal at kitware.com Mon Nov 5 09:32:39 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 5 Nov 2018 15:32:39 +0100 Subject: [vtk-developers] VTK/ParaView beginner course in March 2019 In-Reply-To: References: Message-ID: The courses will take place on *March* 19th and 20th *2019,* Best Regards, Mathieu Westphal On Mon, Nov 5, 2018 at 2:22 PM Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hello list, > > Kitware will be holding a 2-day VTK and ParaView course on May 19th and > 20th 2017 in Lyon, France. > > Please visit our web site for more information and registration details at > VTK : https://training.kitware.fr/browse/205 > ParaView : https://training.kitware.fr/browse/206 > > Note that the course will be taught in English. If you have any question, > please contact us at formations at kitware.fr > > Thank you, > > Mathieu Westphal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Nov 5 16:22:45 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 5 Nov 2018 16:22:45 -0500 Subject: [vtk-developers] announce: VTK 8.2.0.rc1 is ready to try Message-ID: Hi folks, VTK 8.2.0 release candidate 1 is out^1. Please give the release candidate a try and report any problems that you find to us via the gitlab issue tracker with an "8.2.0" milestone. Developers, use the milestone to let us know of any fixes that you want integrated to the release branch in time for 8.2.0 final in a few weeks time. Ideally your branches will start at or above the 8.2.0 tag. We are still gathering feedback from the 108 committers to make up the official release notes but in the meantime here is my summary of some of the bigger changes. * Tcl, OpenGL"1" and Qt4 are no longer supported in this release. * Visual Studio 2013 is deprecated as are the GeoVis modules. * There is a new infrastructure for selection that supports boolean combinations of difference selection types. The original selection infrastructure has not yet been deprecated. * There is a new reader foundation class that makes it more straightforward to add new file formats. * There is a brand new high performance algorithm for extracting isosurfaces from unstructured grids which generally performs 15x faster than its predecessor. * The vtkMolecule classes gained distributed memory parallel features and an ability to derive bonds from nuclei. * Users can now customize volume rendering with their own shaders in the same way that polydatamappers can be customized. * Volume rendering now has a direct isosuface mode. * A number of VTK-m's accelerated filters were exposed inside VTK filters. * QVTKOpenGLWidget has been refactored and once again supports quad buffer (active) stereo. As usual the API difference report is on the wiki. Thank you for all the great effort VTK community! p.s. If you look carefully you may notice that there are actually two new releases on the download page today. The 8.1.2 patch release is just a few bug fix commits beyond the former 8.1.1. 8.1.2 should be a drop in replacement for any codes out there that are using 8.1.1 and we recommend it at least until 8.2.0 is finalized. ^1 Well nearly out, I haven't pushed the signed tag on commit 6aa7b028 yet, nor have I published the data tarballs on the download page, but those will be up shortly. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Nov 5 16:56:27 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 5 Nov 2018 16:56:27 -0500 Subject: [vtk-developers] [vtkusers] announce: VTK 8.2.0.rc1 is ready to try In-Reply-To: References: Message-ID: Yes they appear to be there. See David Gobbi's commit. This is the full set of new changes in 8.1.2. David E. DeMarle (1): Increment version to VTK 8.1.2 David Gobbi (1): Fix compilation issue due to Python3.7 API change Sankhesh Jhaveri (4): Fix bug where re-enabling seed widget wouldn't move existing seeds Invoke DeletePointEvent before deleting vtkSeedWidget seed Make some orientation marker widget methods virtual Issue error if vtkAlgorithm::GetInputConnection called on wrong port Sean McBride (1): Added explicit cast to pacify UBSan?s ?implicit-integer-truncation? Shreeraj Jadhav (1): vtkImageBlend bug fix for compound mode Will Schroeder (1): vtkFlyingEdges2D: Properly color multiple isocontour values David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Nov 5, 2018 at 4:47 PM Fahlgren, Eric < eric.fahlgren at smith-nephew.com> wrote: > > p.s. If you look carefully you may notice that there are actually two > new releases on the download page today. The 8.1.2 patch release is just a > few bug fix commits beyond the former 8.1.1. 8.1.2 should be a drop in > replacement for any codes out there that are using 8.1.1 and we recommend > it at least until 8.2.0 is finalized. > > > > David, > > > > Do you know off the top of your head if the Python 3.7 (const char * in Py > headers) bug fixes are in 8.1.2? > > > Thanks, > > Eric > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed Nov 7 14:48:17 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 7 Nov 2018 20:48:17 +0100 Subject: [vtk-developers] Up-to-date vtk-master debs? Message-ID: Hi all, The blog series about the Debian packaging back in July [1] mentioned that a nightly builds of VTK would be packaged as vtk-master, but the package currently in the APT repo (https://apt.kitware.com/) seems to be to be from July 6. Anyone if nightly builds will become available at some point, or if the initiative was cancelled? Would be absolutely fantastic if nightly packages were available, for testing purposes ahead of releases. Cheers, Elvis [1] https://blog.kitware.com/rethinking-debian-packaging-for-vtk-and-other-cmake-projects-part-1/ From jcfr at kitware.com Thu Nov 8 11:32:59 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 8 Nov 2018 11:32:59 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> Message-ID: Hi Ben, Thanks for the update. This look very promising. Also glad to see the "UseVTK.cmake" disappear, the use of directory properties to handle VTK_DEFINITIONS has been the source of a lot of trouble. Will the new system support the following: * Creating a VTK SDK installed in a read-only location and support building multiple interdependent VTK external modules against it ? * Building any VTK module either externally or along with the VTK project ? (e.g this will be useful for creating python wheels) * Re-using the VTK python wrapping facility without having to buy in the VTK internal build system. These are the limitations of the current infrastructure that I would also like to see addressed by such a drastic change. > build against VTK Will the way to use find_package(VTK ...) and to specify required module change ? I also think updating VTK example to work with the new build system would be a good test case, this will provide an path forward for project that need to support both. > `vtk.module` / `vtk.kit` files While this is an implementation details, would it be more sensible to standardize on friendly for human, readable by machine and declarative by nature format ? E.g json, toml, .. Or may be something like the "Common Package Specification" (see https://mwoehlke.github.io/cps/) ? > rename OpenGL2 back to OpenGL as was the original intent? I would prefer we do NOT to that for the next release, it's gonna make work of user of VTK even more difficult. We are still working our way to handle the switch of VTK major version from 9 to 8 ... Also in the future, I anticipate we will have new version of backend. Should the module be named after the minimum version of OpenGL it support ? (e.g OpenGL3.2) Or since one backend can be built at a time, should alias target be created instead ? Thanks Jc On Tue, Oct 30, 2018 at 2:16 PM David E DeMarle wrote: > +1 for rename > > On Tue, Oct 30, 2018, 2:09 PM Ken Martin wrote: > >> So.... if we are significantly changing the modules shoudl we also take >> the time to rename OpenGL2 back to OpenGL as was the original intent? >> >> On Mon, Oct 29, 2018 at 5:42 PM, Ben Boeckel >> wrote: >> >>> On Mon, Oct 29, 2018 at 22:31:38 +0100, Elvis Stansvik wrote: >>> > Let me just jump in and say that while it sounds neat to embed it >>> > comments, it might make it slightly harder to make an updated version >>> > of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). >>> >>> Thanks for the reminder that this file needs updated. >>> >>> CMake supports long-form comments now, so I'd think it'd be in blocks >>> like this: >>> >>> ```cmake >>> #[==[vtk.kit >>> ... >>> #]==] >>> #[==[vtk.module >>> ... >>> #]==] >>> ``` >>> >>> with a limit of one `vtk.module` per file. Easy to slice out with a >>> simple `sed` call. Not so easy in CMake, but also not ridiculous. >>> >>> This is similar to the way the new module system is documented: >>> >>> ```cmake >>> #[==[.md >>> ... >>> #]==] >>> ``` >>> >>> which will make it possible to extract out these blocks and feed them to >>> Doxygen and get the module system API docs on the web with the rest of >>> VTK. >>> >>> There's also `#[==[.md INTERNAL` for internal function documentation as >>> well. >>> >>> --Ben >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 101 East Weaver Street >> Carrboro, North Carolina >> 27510 USA >> >> This communication, including all attachments, contains confidential and >> legally privileged information, and it is intended only for the use of the >> addressee. Access to this email by anyone else is unauthorized. If you are >> not the intended recipient, any disclosure, copying, distribution or any >> action taken in reliance on it is prohibited and may be unlawful. If you >> received this communication in error please notify us immediately and >> destroy the original message. Thank you. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Nov 8 11:46:55 2018 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 8 Nov 2018 11:46:55 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029160720.GA3379@rotor.localdomain> <24DE5508-9376-42B1-9D7D-F1425776A8C4@kitware.com> <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> Message-ID: I figured with 9.0 people have to rewrite their CMakeLists files calls to use vtk so it was a good time to rename OpenGL2 back to OpenGL. To wait until the next release means we would break their builds two releases in a row which seems worse to me. OpenGL requires 3.2 or ES3 so you could name it vtkRenderingOpenGL3.2orES3 but I would recommend against it. I doubt we will have another C++ OpenGL backend. The first lasted over 20 years. On Thu, Nov 8, 2018 at 11:32 AM, Jean-Christophe Fillion-Robin < jcfr at kitware.com> wrote: > Hi Ben, > > Thanks for the update. This look very promising. > > Also glad to see the "UseVTK.cmake" disappear, the use of directory > properties to handle VTK_DEFINITIONS has been the source of a lot of > trouble. > > > Will the new system support the following: > * Creating a VTK SDK installed in a read-only location and support > building multiple interdependent VTK external modules against it ? > * Building any VTK module either externally or along with the VTK project > ? (e.g this will be useful for creating python wheels) > * Re-using the VTK python wrapping facility without having to buy in the > VTK internal build system. > > These are the limitations of the current infrastructure that I would also > like to see addressed by such a drastic change. > > > > build against VTK > > Will the way to use find_package(VTK ...) and to specify required module > change ? > > I also think updating VTK example to work with the new build system would > be a good test case, this will provide an path forward for project that > need to support both. > > > > `vtk.module` / `vtk.kit` files > > While this is an implementation details, would it be more sensible to > standardize on friendly for human, readable by machine and declarative by > nature format ? E.g json, toml, .. > Or may be something like the "Common Package Specification" (see > https://mwoehlke.github.io/cps/) ? > > > > > rename OpenGL2 back to OpenGL as was the original intent? > > I would prefer we do NOT to that for the next release, it's gonna make > work of user of VTK even more difficult. We are still working our way to > handle the switch of VTK major version from 9 to 8 ... > > Also in the future, I anticipate we will have new version of backend. > Should the module be named after the minimum version of OpenGL it support > ? (e.g OpenGL3.2) > Or since one backend can be built at a time, should alias target be > created instead ? > > > > Thanks > Jc > > > > On Tue, Oct 30, 2018 at 2:16 PM David E DeMarle > wrote: > >> +1 for rename >> >> On Tue, Oct 30, 2018, 2:09 PM Ken Martin wrote: >> >>> So.... if we are significantly changing the modules shoudl we also take >>> the time to rename OpenGL2 back to OpenGL as was the original intent? >>> >>> On Mon, Oct 29, 2018 at 5:42 PM, Ben Boeckel >>> wrote: >>> >>>> On Mon, Oct 29, 2018 at 22:31:38 +0100, Elvis Stansvik wrote: >>>> > Let me just jump in and say that while it sounds neat to embed it >>>> > comments, it might make it slightly harder to make an updated version >>>> > of Utilities/Maintenance/WhatModulesVTK.py script (which I love!). >>>> >>>> Thanks for the reminder that this file needs updated. >>>> >>>> CMake supports long-form comments now, so I'd think it'd be in blocks >>>> like this: >>>> >>>> ```cmake >>>> #[==[vtk.kit >>>> ... >>>> #]==] >>>> #[==[vtk.module >>>> ... >>>> #]==] >>>> ``` >>>> >>>> with a limit of one `vtk.module` per file. Easy to slice out with a >>>> simple `sed` call. Not so easy in CMake, but also not ridiculous. >>>> >>>> This is similar to the way the new module system is documented: >>>> >>>> ```cmake >>>> #[==[.md >>>> ... >>>> #]==] >>>> ``` >>>> >>>> which will make it possible to extract out these blocks and feed them to >>>> Doxygen and get the module system API docs on the web with the rest of >>>> VTK. >>>> >>>> There's also `#[==[.md INTERNAL` for internal function documentation as >>>> well. >>>> >>>> --Ben >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/ >>>> opensource/opensource.html >>>> >>>> Search the list archives at: http://markmail.org/search/?q= >>>> vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 101 East Weaver Street >>> >>> Carrboro, North Carolina >>> >>> 27510 USA >>> >>> This communication, including all attachments, contains confidential and >>> legally privileged information, and it is intended only for the use of the >>> addressee. Access to this email by anyone else is unauthorized. If you are >>> not the intended recipient, any disclosure, copying, distribution or any >>> action taken in reliance on it is prohibited and may be unlawful. If you >>> received this communication in error please notify us immediately and >>> destroy the original message. Thank you. >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/ >>> opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q= >>> vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/ >> opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Nov 8 14:17:57 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 8 Nov 2018 14:17:57 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> Message-ID: <20181108191757.GA7191@rotor.localdomain> On Thu, Nov 08, 2018 at 11:32:59 -0500, Jean-Christophe Fillion-Robin wrote: > Thanks for the update. This look very promising. > > Also glad to see the "UseVTK.cmake" disappear, the use of directory > properties to handle VTK_DEFINITIONS has been the source of a lot of > trouble. > > Will the new system support the following: > * Creating a VTK SDK installed in a read-only location and support building > multiple interdependent VTK external modules against it ? This should work with the current branch. > * Building any VTK module either externally or along with the VTK project > ? (e.g this will be useful for creating python wheels) I'm not sure the use case is clear to me. How are Python wheels related to remote modules? Remote modules have not been ported (neither has its VTK-side infrastructure) yet. ParaView is a use case of how it would work since ParaView won't be doing `add_subdirectory(VTK)` at all, but instead use the module system to scan VTK itself (or, if using an external VTK, `find_package(VTK)`). As for the Python wheel part, in the future, I'd like to have `vtk-superbuild` creating Python wheel packages. > * Re-using the VTK python wrapping facility without having to buy in the > VTK internal build system. It has been tied tighter, if anything, than before. Python wrapping is given a list of modules from which it extracts the information it needs. It assumes that hierarchy files have already been made (this is a private function in `vtkModule.cmake` right now). But, if the hierarchy file is made outside the module system itself, making the wrapping work is a matter of writing some target properties: - `INTERFACE_vtk_module_depends` - `INTERFACE_vtk_module_implements` (though if you're doing this without the module system?) - `INTERFACE_vtk_module_hierarchy` - `INTERFACE_vtk_module_headers` But, not using the module system to run the wrapping isn't something I designed for (it's complicated enough as-is). Note that it should be possible to wrap VTK from outside the project building VTK using the properties the module system exports. For example, ActiViz for C# and ClientServer for ParaView with an external VTK. > These are the limitations of the current infrastructure that I would also > like to see addressed by such a drastic change. > > > build against VTK > > Will the way to use find_package(VTK ...) and to specify required module > change ? The component names might be different now: find_package(VTK COMPONENTS CommonCore OPTIONAL_COMPONENTS ParallelMPI) > I also think updating VTK example to work with the new build system would > be a good test case, this will provide an path forward for project that > need to support both. Updating Bill Lorensen's repository is on the list. Updating ParaView is more urgent though since it needs to be updated before VTK can land. We can land the updated examples after the initial merge though. > > `vtk.module` / `vtk.kit` files > > While this is an implementation details, would it be more sensible to > standardize on friendly for human, readable by machine and declarative by > nature format ? E.g json, toml, .. > Or may be something like the "Common Package Specification" (see > https://mwoehlke.github.io/cps/) ? It has to be read in CMake code?so something that is CMake-like is easier. If CMake were to add JSON support to the CMake language, then we could also look for `vtk.module.json` files. Until that happens, I'm not writing a JSON or TOML parser in CMake. > > rename OpenGL2 back to OpenGL as was the original intent? > > I would prefer we do NOT to that for the next release, it's gonna make work > of user of VTK even more difficult. We are still working our way to handle > the switch of VTK major version from 9 to 8 ... I agree with Ken. CMake code already needs a rework. I think we should only do this once. However, it will be renamed after the initial landing. The branch is big enough already: 300+ commits and diffstat below. This is because renaming modules requires touching *every* header in the module (for the export macro) whereas the module system is largely just CMake changes (there are minor code updates, mainly in testing code to fix some data paths). 3736 files changed, 343695 insertions(+), 466352 deletions(-) > Also in the future, I anticipate we will have new version of backend. > Should the module be named after the minimum version of OpenGL it support > ? (e.g OpenGL3.2) Ken already addressed this. > Or since one backend can be built at a time, should alias target be created > instead ? Only building a single backend should no longer be a thing. Backend selection should be done through `vtkObjectFactory` and applications only use the base classes implemented by backends (unless they need the specific implementations in which case they just use the subclasses directly). See this issue: https://gitlab.kitware.com/vtk/vtk/issues/17218 --Ben From david.gobbi at gmail.com Thu Nov 8 15:15:32 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 8 Nov 2018 13:15:32 -0700 Subject: [vtk-developers] New module system preview In-Reply-To: <20181108191757.GA7191@rotor.localdomain> References: <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> Message-ID: On Thu, Nov 8, 2018 at 12:18 PM Ben Boeckel wrote: > > > * Building any VTK module either externally or along with the VTK project > > ? (e.g this will be useful for creating python wheels) > > I'm not sure the use case is clear to me. How are Python wheels related > to remote modules? > Package managers like to be able to subdivide VTK into multiple packages. Being able to modularize the build itself, so that VTK can be built kit-by-kit instead of all at once, is a logical extension of the multiple package idea. If I recall correctly, the CI system for pypi was failing to build VTK due to timeouts (I'm not sure what the workaround was, I suspect that Prabhu built the wheels manually). On a related note, we definitely want to be able to build remote modules against an installed VTK. Currently my vtk-dicom remote module has two parallel sets of cmake logic: one for when it builds as a remote module, and another for when it builds against VTK binaries. It would be nice if building a remote module externally "just worked". David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Nov 8 15:20:32 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 8 Nov 2018 15:20:32 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> Message-ID: Timeouts were a problem with conda too. On Thu, Nov 8, 2018 at 3:15 PM David Gobbi wrote: > On Thu, Nov 8, 2018 at 12:18 PM Ben Boeckel > wrote: > >> >> > * Building any VTK module either externally or along with the VTK >> project >> > ? (e.g this will be useful for creating python wheels) >> >> I'm not sure the use case is clear to me. How are Python wheels related >> to remote modules? >> > > Package managers like to be able to subdivide VTK into multiple packages. > Being able to modularize the build itself, so that VTK can be built > kit-by-kit > instead of all at once, is a logical extension of the multiple package > idea. > If I recall correctly, the CI system for pypi was failing to build VTK due > to > timeouts (I'm not sure what the workaround was, I suspect that Prabhu > built the wheels manually). > > On a related note, we definitely want to be able to build remote modules > against an installed VTK. Currently my vtk-dicom remote module has two > parallel sets of cmake logic: one for when it builds as a remote module, > and > another for when it builds against VTK binaries. It would be nice if > building > a remote module externally "just worked". > > 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Nov 8 15:53:48 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 8 Nov 2018 15:53:48 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> Message-ID: <20181108205348.GA23392@rotor.localdomain> On Thu, Nov 08, 2018 at 13:15:32 -0700, David Gobbi wrote: > Package managers like to be able to subdivide VTK into multiple packages. > Being able to modularize the build itself, so that VTK can be built > kit-by-kit > instead of all at once, is a logical extension of the multiple package idea. > If I recall correctly, the CI system for pypi was failing to build VTK due > to > timeouts (I'm not sure what the workaround was, I suspect that Prabhu > built the wheels manually). We could support that via another top-level `CMakeLists.txt` which only builds specific modules. The main problem would be getting the installed CMake files to all work together. In particular, `find_package(VTK-prev-stage)` would need to be done in later stages since multiple packages wouldn't be able to install to the same CMake package. The installed VTK CMake package would be?not the same for consumers of the package. The best thing to do is probably to trim down what constitutes VTK itself and move modules to external repositories. > On a related note, we definitely want to be able to build remote modules > against an installed VTK. Currently my vtk-dicom remote module has two > parallel sets of cmake logic: one for when it builds as a remote module, and > another for when it builds against VTK binaries. It would be nice if > building > a remote module externally "just worked". The way I'd see this working best is: vtkdicom/CMakeLists.txt - standalone build vtkdicom/module/ - directory for the module vtkdicom/module/vtk.module vtkdicom/module/CMakeLists.txt VTK wouldn't care about the top-level `CMakeLists.txt` at all. It would find the module via the `vtk.module` file and module logic would just build it as any other module (this is what ParaView does for its VTK submodule). --Ben From david.gobbi at gmail.com Thu Nov 8 16:25:09 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 8 Nov 2018 14:25:09 -0700 Subject: [vtk-developers] New module system preview In-Reply-To: <20181108205348.GA23392@rotor.localdomain> References: <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <20181108205348.GA23392@rotor.localdomain> Message-ID: On Thu, Nov 8, 2018 at 1:53 PM Ben Boeckel wrote: > > `find_package(VTK-prev-stage)` would need to be done in later stages > since multiple packages wouldn't be able to install to the same CMake > package. The installed VTK CMake package would be?not the same for > consumers of the package. > Maybe the VTK build could always divide itself into multiple installed cmake packages, to keep things consistent? I haven't thought this through, however, and it might be a very bad idea... > The best thing to do is probably to trim down what constitutes VTK > itself and move modules to external repositories. > Agreed. > VTK wouldn't care about the top-level `CMakeLists.txt` at all. It would > find the module via the `vtk.module` file and module logic would just > build it as any other module (this is what ParaView does for its > VTK submodule). > That sounds better than VTK current modules. I'll have to grab the new branch and do some experiments. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison.vacanti at kitware.com Thu Nov 8 17:21:13 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Thu, 8 Nov 2018 17:21:13 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays Message-ID: Hi folks, I've written a set of STL-compatible utilities that allow vtkDataArrays to be efficiently used with STL algorithms as well as with C++11 for-range syntax. This consists of TupleRanges, which iterate through an array tuple-by-tuple and component-by-component, and ValueRanges, which iterate element-by-element using AOS-ordering. I've linked a blog post describing them in more detail, and a merge request available to play with / review / nitpick for anyone interested in doing so =) https://blog.kitware.com/c11-for-range-support-in-vtk/ https://gitlab.kitware.com/vtk/vtk/merge_requests/4826 Allie -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Nov 8 17:27:16 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 8 Nov 2018 17:27:16 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <20181108205348.GA23392@rotor.localdomain> Message-ID: <20181108222715.GA14603@rotor.localdomain> On Thu, Nov 08, 2018 at 14:25:09 -0700, David Gobbi wrote: > Maybe the VTK build could always divide itself into multiple installed > cmake packages, to keep things consistent? I haven't thought this > through, however, and it might be a very bad idea... It could. If we do this though, it should be before we tag 9.0. I don't want to bikeshed which modules go where on this thread however. I would note that the kits are probably a good place to start as to the chunking at least. > That sounds better than VTK current modules. I'll have to grab the > new branch and do some experiments. Note that there are some things which are likely missing in the current implementation for VTK remote modules. One is that they may need different namespaces. For example, VTK's modules are all exported in the `VTK::` namespace. Remote modules may want to be in a different namespace and that requires a separate `vtk_module_build` call. However, this makes me think that these projects are best just left on their own and not care about being part of VTK's main build. This should be easier now that using VTK from outside of VTK itself is better. --Ben From bill.lorensen at gmail.com Thu Nov 8 23:57:20 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 8 Nov 2018 20:57:20 -0800 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <20181108205348.GA23392@rotor.localdomain> Message-ID: I agree with David regarding Remote Modules. On Thu, Nov 8, 2018, 1:25 PM David Gobbi On Thu, Nov 8, 2018 at 1:53 PM Ben Boeckel > wrote: > >> >> `find_package(VTK-prev-stage)` would need to be done in later stages >> since multiple packages wouldn't be able to install to the same CMake >> package. The installed VTK CMake package would be?not the same for >> consumers of the package. >> > > Maybe the VTK build could always divide itself into multiple installed > cmake packages, to keep things consistent? I haven't thought this > through, however, and it might be a very bad idea... > > >> The best thing to do is probably to trim down what constitutes VTK >> itself and move modules to external repositories. >> > > Agreed. > > >> VTK wouldn't care about the top-level `CMakeLists.txt` at all. It would >> find the module via the `vtk.module` file and module logic would just >> build it as any other module (this is what ParaView does for its >> VTK submodule). >> > > That sounds better than VTK current modules. I'll have to grab the > new branch and do some experiments. > > 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Fri Nov 9 02:07:38 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 9 Nov 2018 08:07:38 +0100 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: Den tors 8 nov. 2018 kl 23:21 skrev Allie Vacanti : > > Hi folks, > > I've written a set of STL-compatible utilities that allow vtkDataArrays to be efficiently used with STL algorithms as well as with C++11 for-range syntax. This consists of TupleRanges, which iterate through an array tuple-by-tuple and component-by-component, and ValueRanges, which iterate element-by-element using AOS-ordering. > > I've linked a blog post describing them in more detail, and a merge request available to play with / review / nitpick for anyone interested in doing so =) > > https://blog.kitware.com/c11-for-range-support-in-vtk/ > https://gitlab.kitware.com/vtk/vtk/merge_requests/4826 > This is awesome Allie. Any plans for something similar for vtkCollection*? Elvis > Allie > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From allison.vacanti at kitware.com Fri Nov 9 06:00:37 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Fri, 9 Nov 2018 06:00:37 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik Any plans for something similar for vtkCollection*? > Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK. It'd have a similarly usage as the array iterators: vtk[...]Collection *myCollection = ...; for (auto item : vtk::Range(myCollection)) { ... } I'll put this on my list to look at in my spare cycles. Good suggestion! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nztoddler at yahoo.com Fri Nov 9 06:39:28 2018 From: nztoddler at yahoo.com (Todd) Date: Sat, 10 Nov 2018 00:39:28 +1300 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: Message-ID: <9be6acf8-a1e1-4e0f-bf61-2ffde98c8152@email.android.com> An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Nov 9 08:45:44 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 9 Nov 2018 08:45:44 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: <9be6acf8-a1e1-4e0f-bf61-2ffde98c8152@email.android.com> References: <9be6acf8-a1e1-4e0f-bf61-2ffde98c8152@email.android.com> Message-ID: +1 for the idea of converting vtk collections into stl conventions. On Fri, Nov 9, 2018, 6:49 AM Todd via vtk-developers < vtk-developers at public.kitware.com> wrote: > Nice blog. > > On 10 Nov 2018 12:00 a.m., Allie Vacanti > wrote: > > On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik wrote: > > Any plans for something similar for vtkCollection*? > > > Not currently, but that would be a very useful feature indeed. I think > it'd be more than worthwhile to add a template that just translates the VTK > iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to > a set of STL iterators/range objects. This would allow it to work with > quite a few different iterables in VTK. > > It'd have a similarly usage as the array iterators: > > vtk[...]Collection *myCollection = ...; > for (auto item : vtk::Range(myCollection)) { ... } > > I'll put this on my list to look at in my spare cycles. Good suggestion! > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Nov 9 08:53:04 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 9 Nov 2018 08:53:04 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <20181108205348.GA23392@rotor.localdomain> Message-ID: I love the ***idea*** of remote modules but sort of hate them in practice. I'm not sure if there is a way to make them work. Maybe someone knows a way. Right now a change in VTK is as simple as one commit to one repo. With remote modules it could explode into a commit per module, each with it's own repo, maintainer, etc. Ten remote modules could mean ten commits instead of one. That would be painful. If there is a way to do remote modules where one commit can still hit all of them (or at least the central ones) then it becomes more manageable to me. Maybe using remote module semantics but with the cores ones from within the same source tree/repo or something like that. On Thu, Nov 8, 2018 at 11:57 PM, Bill Lorensen wrote: > I agree with David regarding Remote Modules. > > On Thu, Nov 8, 2018, 1:25 PM David Gobbi >> On Thu, Nov 8, 2018 at 1:53 PM Ben Boeckel >> wrote: >> >>> >>> `find_package(VTK-prev-stage)` would need to be done in later stages >>> since multiple packages wouldn't be able to install to the same CMake >>> package. The installed VTK CMake package would be?not the same for >>> consumers of the package. >>> >> >> Maybe the VTK build could always divide itself into multiple installed >> cmake packages, to keep things consistent? I haven't thought this >> through, however, and it might be a very bad idea... >> >> >>> The best thing to do is probably to trim down what constitutes VTK >>> itself and move modules to external repositories. >>> >> >> Agreed. >> >> >>> VTK wouldn't care about the top-level `CMakeLists.txt` at all. It would >>> find the module via the `vtk.module` file and module logic would just >>> build it as any other module (this is what ParaView does for its >>> VTK submodule). >>> >> >> That sounds better than VTK current modules. I'll have to grab the >> new branch and do some experiments. >> >> 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: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Nov 9 10:19:37 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 9 Nov 2018 10:19:37 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK. As the blog hints at, one concern which is readily apparent when perusing VTK source code is the number of options available to do the same thing. I'd really like to see consolidation at some point. Many of our *core* algorithms like contouring (whether you are looking at marching cubes, synchronized templates or flying edges) use the old template macro dispatch, while classes like vtkContourGrid use virtual methods etc. and so on. If you are a budding visualization enthusiast or algorithm writer/developer this can be quite confusing, as the code is increasingly peppered with complexity -- a potential barrier to new developers and community growth. Finally, the examples used in the blog to demonstrate the different iterators are necessarily simple. However I'd like to see how these various approaches work in more complex algorithms when data flies in many simultaneous directions :-) But maybe the reality is that we need multiple options for good reasons e.g., to address increasing computing complexity.... but I'd like to explicitly agree this is the case rather than leaving a trail of alternate implementations. So is there a roadmap for consolidation etc? Best, On Thu, Nov 8, 2018 at 5:21 PM Allie Vacanti wrote: > Hi folks, > > I've written a set of STL-compatible utilities that allow vtkDataArrays to > be efficiently used with STL algorithms as well as with C++11 for-range > syntax. This consists of TupleRanges, which iterate through an array > tuple-by-tuple and component-by-component, and ValueRanges, which iterate > element-by-element using AOS-ordering. > > I've linked a blog post describing them in more detail, and a merge > request available to play with / review / nitpick for anyone interested in > doing so =) > > https://blog.kitware.com/c11-for-range-support-in-vtk/ > https://gitlab.kitware.com/vtk/vtk/merge_requests/4826 > > Allie > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison.vacanti at kitware.com Fri Nov 9 10:51:24 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Fri, 9 Nov 2018 10:51:24 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder wrote: > Great blog, thanks for the clear explanations and evaluations. It's a > great resource for folks trying to keep up with VTK. > > As the blog hints at, one concern which is readily apparent when perusing > VTK source code is the number of options available to do the same thing. > I'd really like to see consolidation at some point. Many of our *core* > algorithms like contouring (whether you are looking at marching cubes, > synchronized templates or flying edges) use the old template macro > dispatch, while classes like vtkContourGrid use virtual methods etc. and so > on. If you are a budding visualization enthusiast or algorithm > writer/developer this can be quite confusing, as the code is increasingly > peppered with complexity -- a potential barrier to new developers and > community growth. > > Finally, the examples used in the blog to demonstrate the different > iterators are necessarily simple. However I'd like to see how these various > approaches work in more complex algorithms when data flies in many > simultaneous directions :-) > > But maybe the reality is that we need multiple options for good reasons > e.g., to address increasing computing complexity.... but I'd like to > explicitly agree this is the case rather than leaving a trail of alternate > implementations. So is there a roadmap for consolidation etc? > There is not a plan to deprecate the older methods at this point. In the past, changes to the vtkDataArray API have been frowned upon as they can force external (and internal!) code to require significant and expensive refactoring effort to use the new methods. My goal with this post is to provide education and insight into the various ways to access array data, and compare their good and bad traits as fairly as possible. A lot of the current preferred techniques build upon the older APIs and use them under the covers -- they just package them up in ways that are easier to use. For instance, the new iterators use vtkDataArrayAccessor, GetPointer, and VTK_ASSUME internally. The Accessors internally use both the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily view the newer techniques as full-on replacements for the old APIs, but rather layers on top of them that simplify the usage of the older techniques, especially in performance-critical and generic contexts. The older APIs still have merit, IMO: vtkDataArray APIs are slow, but easy to write. They're just fine for fast prototyping and proof of concepts, and situations where a fast execution path is not as important as having broad support for any array that comes in. It's also critical to have for the fall-back pattern when a dispatch fails. vtkGenericDataArray API is the cornerstone of all of modern fast-path code. Accessors can and probably should be discouraged once the iterators are in. They still may be more convenient, however, when dealing with more complex traversals and access patterns that would be cumbersome using iterators. AOS::GetPointer and SOA::GetComponentArray are still extremely useful for writing very low-level optimized code in the rare cases where having separately tuned implementations for SOA vs. AOS would pay off. However....vtkDataArray::GetVoidPointer() should be chucked in the bin, IMO. It made sense when it was added, but it relies on the AOS assumption, which is no longer guaranteed. There would be significant internal and external development cost to move away from it, so idk what to do about that one. Maybe just permanent deprecation, or hide it behind a compatibility layer? We'd need a decent sized chunk of funding to migrate VTK itself away from it first. So, rather than deprecating and removing old methods, creating simpler layers on top of them and providing reference / educational resources seems like the better option to me. As for more complex examples, there are absolutely cases where iterator APIs are not going to be the best choice. For complicated code doing multiple lookups and random accesses, using a more verbose / explicit API will lead to much more maintainable, readable, and debuggable code. The array APIs or Accessors would still be preferred in those cases. But for simple traversals, or work that could be accomplished by leveraging the STL? Iterators are the way to go :-) Allie > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Nov 9 10:59:07 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 9 Nov 2018 10:59:07 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <20181108205348.GA23392@rotor.localdomain> Message-ID: <20181109155907.GA21280@rotor.localdomain> On Fri, Nov 09, 2018 at 08:53:04 -0500, Ken Martin wrote: > I love the ***idea*** of remote modules but sort of hate them in practice. > I'm not sure if there is a way to make them work. Maybe someone knows a way. Maybe the best way is to not treat them as part of VTK at all, but instead something more like CMake's contract tests. Instead of being part of VTK's *build* step, they are run as *tests* of VTK to ensure that VTK is not breaking API (we should be *deprecating* and *adding* rather than *deleting* or *changing* functions). This means that the "remote" modules never have to deal with "are we inside VTK?" and are always doing `find_package(VTK)`. --Ben From will.schroeder at kitware.com Fri Nov 9 11:39:32 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 9 Nov 2018 11:39:32 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten using the preferred approach of your choosing :-) (or alternatively point us to good, non-trivial examples). Along with benchmarking to see what the impacts are... IMO code examples like this can go a long way to helping others do the right thing. On Fri, Nov 9, 2018 at 10:51 AM Allie Vacanti wrote: > On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder > wrote: > >> Great blog, thanks for the clear explanations and evaluations. It's a >> great resource for folks trying to keep up with VTK. >> >> As the blog hints at, one concern which is readily apparent when perusing >> VTK source code is the number of options available to do the same thing. >> I'd really like to see consolidation at some point. Many of our *core* >> algorithms like contouring (whether you are looking at marching cubes, >> synchronized templates or flying edges) use the old template macro >> dispatch, while classes like vtkContourGrid use virtual methods etc. and so >> on. If you are a budding visualization enthusiast or algorithm >> writer/developer this can be quite confusing, as the code is increasingly >> peppered with complexity -- a potential barrier to new developers and >> community growth. >> >> Finally, the examples used in the blog to demonstrate the different >> iterators are necessarily simple. However I'd like to see how these various >> approaches work in more complex algorithms when data flies in many >> simultaneous directions :-) >> >> But maybe the reality is that we need multiple options for good reasons >> e.g., to address increasing computing complexity.... but I'd like to >> explicitly agree this is the case rather than leaving a trail of alternate >> implementations. So is there a roadmap for consolidation etc? >> > > There is not a plan to deprecate the older methods at this point. In the > past, changes to the vtkDataArray API have been frowned upon as they can > force external (and internal!) code to require significant and expensive > refactoring effort to use the new methods. My goal with this post is to > provide education and insight into the various ways to access array data, > and compare their good and bad traits as fairly as possible. > > A lot of the current preferred techniques build upon the older APIs and > use them under the covers -- they just package them up in ways that are > easier to use. For instance, the new iterators use vtkDataArrayAccessor, > GetPointer, and VTK_ASSUME internally. The Accessors internally use both > the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily > view the newer techniques as full-on replacements for the old APIs, but > rather layers on top of them that simplify the usage of the older > techniques, especially in performance-critical and generic contexts. > > The older APIs still have merit, IMO: > > vtkDataArray APIs are slow, but easy to write. They're just fine for fast > prototyping and proof of concepts, and situations where a fast execution > path is not as important as having broad support for any array that comes > in. It's also critical to have for the fall-back pattern when a dispatch > fails. > > vtkGenericDataArray API is the cornerstone of all of modern fast-path code. > > Accessors can and probably should be discouraged once the iterators are > in. They still may be more convenient, however, when dealing with more > complex traversals and access patterns that would be cumbersome using > iterators. > > AOS::GetPointer and SOA::GetComponentArray are still extremely useful for > writing very low-level optimized code in the rare cases where having > separately tuned implementations for SOA vs. AOS would pay off. > > However....vtkDataArray::GetVoidPointer() should be chucked in the bin, > IMO. It made sense when it was added, but it relies on the AOS assumption, > which is no longer guaranteed. There would be significant internal and > external development cost to move away from it, so idk what to do about > that one. Maybe just permanent deprecation, or hide it behind a > compatibility layer? We'd need a decent sized chunk of funding to migrate > VTK itself away from it first. > > So, rather than deprecating and removing old methods, creating simpler > layers on top of them and providing reference / educational resources seems > like the better option to me. > > As for more complex examples, there are absolutely cases where iterator > APIs are not going to be the best choice. For complicated code doing > multiple lookups and random accesses, using a more verbose / explicit API > will lead to much more maintainable, readable, and debuggable code. The > array APIs or Accessors would still be preferred in those cases. > > But for simple traversals, or work that could be accomplished by > leveraging the STL? Iterators are the way to go :-) > > Allie > >> -- 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 lasso at queensu.ca Fri Nov 9 11:56:35 2018 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 9 Nov 2018 16:56:35 +0000 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: > Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten ? Along with benchmarking Fully agree. I wish there was a +1 button that I could click to show support, instead of littering everyone?s mailbox with yet another email. I hope VTK forum will be available soon. Andras From: vtk-developers On Behalf Of Will Schroeder Sent: Friday, November 9, 2018 11:40 AM To: Allison Vacanti Cc: vtk-developers Subject: Re: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten using the preferred approach of your choosing :-) (or alternatively point us to good, non-trivial examples). Along with benchmarking to see what the impacts are... IMO code examples like this can go a long way to helping others do the right thing. On Fri, Nov 9, 2018 at 10:51 AM Allie Vacanti > wrote: On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder > wrote: Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK. As the blog hints at, one concern which is readily apparent when perusing VTK source code is the number of options available to do the same thing. I'd really like to see consolidation at some point. Many of our *core* algorithms like contouring (whether you are looking at marching cubes, synchronized templates or flying edges) use the old template macro dispatch, while classes like vtkContourGrid use virtual methods etc. and so on. If you are a budding visualization enthusiast or algorithm writer/developer this can be quite confusing, as the code is increasingly peppered with complexity -- a potential barrier to new developers and community growth. Finally, the examples used in the blog to demonstrate the different iterators are necessarily simple. However I'd like to see how these various approaches work in more complex algorithms when data flies in many simultaneous directions :-) But maybe the reality is that we need multiple options for good reasons e.g., to address increasing computing complexity.... but I'd like to explicitly agree this is the case rather than leaving a trail of alternate implementations. So is there a roadmap for consolidation etc? There is not a plan to deprecate the older methods at this point. In the past, changes to the vtkDataArray API have been frowned upon as they can force external (and internal!) code to require significant and expensive refactoring effort to use the new methods. My goal with this post is to provide education and insight into the various ways to access array data, and compare their good and bad traits as fairly as possible. A lot of the current preferred techniques build upon the older APIs and use them under the covers -- they just package them up in ways that are easier to use. For instance, the new iterators use vtkDataArrayAccessor, GetPointer, and VTK_ASSUME internally. The Accessors internally use both the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily view the newer techniques as full-on replacements for the old APIs, but rather layers on top of them that simplify the usage of the older techniques, especially in performance-critical and generic contexts. The older APIs still have merit, IMO: vtkDataArray APIs are slow, but easy to write. They're just fine for fast prototyping and proof of concepts, and situations where a fast execution path is not as important as having broad support for any array that comes in. It's also critical to have for the fall-back pattern when a dispatch fails. vtkGenericDataArray API is the cornerstone of all of modern fast-path code. Accessors can and probably should be discouraged once the iterators are in. They still may be more convenient, however, when dealing with more complex traversals and access patterns that would be cumbersome using iterators. AOS::GetPointer and SOA::GetComponentArray are still extremely useful for writing very low-level optimized code in the rare cases where having separately tuned implementations for SOA vs. AOS would pay off. However....vtkDataArray::GetVoidPointer() should be chucked in the bin, IMO. It made sense when it was added, but it relies on the AOS assumption, which is no longer guaranteed. There would be significant internal and external development cost to move away from it, so idk what to do about that one. Maybe just permanent deprecation, or hide it behind a compatibility layer? We'd need a decent sized chunk of funding to migrate VTK itself away from it first. So, rather than deprecating and removing old methods, creating simpler layers on top of them and providing reference / educational resources seems like the better option to me. As for more complex examples, there are absolutely cases where iterator APIs are not going to be the best choice. For complicated code doing multiple lookups and random accesses, using a more verbose / explicit API will lead to much more maintainable, readable, and debuggable code. The array APIs or Accessors would still be preferred in those cases. But for simple traversals, or work that could be accomplished by leveraging the STL? Iterators are the way to go :-) Allie -- 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 prabhu at aero.iitb.ac.in Fri Nov 9 12:05:34 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Fri, 9 Nov 2018 12:05:34 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> Message-ID: <568437f8-505e-e640-158f-04c31f7830d9@aero.iitb.ac.in> On 11/8/18 3:15 PM, David Gobbi wrote: > On Thu, Nov 8, 2018 at 12:18 PM Ben Boeckel > wrote: > > > > * Building any VTK module either externally or along with the VTK project > > ?? (e.g this will be useful for creating python wheels) > > I'm not sure the use case is clear to me. How are Python wheels related > to remote modules? > > > Package managers like to be able to subdivide VTK into multiple packages. > Being able to modularize the build itself, so that VTK can be built kit-by-kit > instead of all at once, is a logical extension of the multiple package idea. > If I recall correctly, the CI system for pypi was failing to build VTK due to > timeouts (I'm not sure what the workaround was, I suspect that Prabhu > built the wheels manually). Yes, I built the wheels with the VTKPythonPackage, (https://github.com/KitwareMedical/VTKPythonPackage), it is largely automated but I did build it by hand and uploaded it.? I am not sure if this is still broken with 8.2 and hope to check this weekend. cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison.vacanti at kitware.com Fri Nov 9 12:21:17 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Fri, 9 Nov 2018 12:21:17 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: On Fri, Nov 9, 2018 at 11:39 AM Will Schroeder wrote: > Personally I'd love to see one of the core algorithms (isocontouring?) > currently using GetVoidPointer() / vtkTemplateMacro rewitten using the > preferred approach of your choosing :-) (or alternatively point us to good, > non-trivial examples). Along with benchmarking to see what the impacts > are... IMO code examples like this can go a long way to helping others do > the right thing. > >From the a quick glance at the vtkMarchingCubes code, this would actually be a decent candidate for the iterators. It would take some serious refactoring, but it's essentially four locations in the scalar array moving sequentially through the data simultaneously -- something that could be modeled with iterators fairly easily. I agree, some more "real life" examples would be useful, right now it's just a matter of finding the cycles to undertake something like this =) Allie -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Nov 9 12:35:50 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 9 Nov 2018 12:35:50 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: Message-ID: I think (at times I am guilty of this I'm afraid) that we do not do enough to include the broader VTK community. We may not have funding and/or time at the moment at Kitware, but the VTK community includes many very talented non-KW people who can bring their own resources to the table. If together we agree on the challenges, and then "teach" others as necessary, then I have no doubt we can get a lot more done that we might think :-) On Fri, Nov 9, 2018 at 12:21 PM Allie Vacanti wrote: > On Fri, Nov 9, 2018 at 11:39 AM Will Schroeder > wrote: > >> Personally I'd love to see one of the core algorithms (isocontouring?) >> currently using GetVoidPointer() / vtkTemplateMacro rewitten using the >> preferred approach of your choosing :-) (or alternatively point us to good, >> non-trivial examples). Along with benchmarking to see what the impacts >> are... IMO code examples like this can go a long way to helping others do >> the right thing. >> > > From the a quick glance at the vtkMarchingCubes code, this would actually > be a decent candidate for the iterators. It would take some serious > refactoring, but it's essentially four locations in the scalar array moving > sequentially through the data simultaneously -- something that could be > modeled with iterators fairly easily. > > I agree, some more "real life" examples would be useful, right now it's > just a matter of finding the cycles to undertake something like this =) > > Allie > -- 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 jcfr at kitware.com Fri Nov 9 13:58:56 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 9 Nov 2018 13:58:56 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: <568437f8-505e-e640-158f-04c31f7830d9@aero.iitb.ac.in> References: <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <568437f8-505e-e640-158f-04c31f7830d9@aero.iitb.ac.in> Message-ID: -------------------- > > * Building any VTK module either externally or along with the VTK project > > ? (e.g this will be useful for creating python wheels) > I'm not sure the use case is clear to me. How are Python wheels related to remote modules? As of today, it is possible to distribute and package part of VTK independently. this is already done for the VTKOpenVR module. See [1] [1] https://github.com/Kitware/VTK/blob/4cb368df22c2db23ed230f743422fcfd78570229/Rendering/OpenVR/CMakeLists.txt#L1-L9 The comment of David "VTK can be built kit-by-kit instead of all at once, is a logical extension of the multiple package idea" also capture this idea. >From a user perspective, I see remote module as in "VTK module source stored outside of VTK source tree" exactly the same way as regular module. Ideally, a "project" command as well as a "find_package(VTK ... )" with the expected dependency would be written in every VTK module. The only exception would be a "VTKCore" module providing the build system infrastructure. -------------------- > I love the ***idea*** of remote modules but sort of hate them in practice. I'm not sure if there is a way to make them work. Maybe someone knows a way. > Right now a change in VTK is as simple as one commit to one repo. This shouldn't change. The key idea here is that the underlying build-system should treat them the same way. The only different is that the source happen to already be available. On Fri, Nov 9, 2018 at 12:05 PM Prabhu Ramachandran wrote: > On 11/8/18 3:15 PM, David Gobbi wrote: > > On Thu, Nov 8, 2018 at 12:18 PM Ben Boeckel > wrote: > >> >> > * Building any VTK module either externally or along with the VTK >> project >> > ? (e.g this will be useful for creating python wheels) >> >> I'm not sure the use case is clear to me. How are Python wheels related >> to remote modules? >> > > Package managers like to be able to subdivide VTK into multiple packages. > Being able to modularize the build itself, so that VTK can be built > kit-by-kit > instead of all at once, is a logical extension of the multiple package > idea. > If I recall correctly, the CI system for pypi was failing to build VTK due > to > timeouts (I'm not sure what the workaround was, I suspect that Prabhu > built the wheels manually). > > Yes, I built the wheels with the VTKPythonPackage, ( > https://github.com/KitwareMedical/VTKPythonPackage), it is largely > automated but I did build it by hand and uploaded it. > > I am not sure if this is still broken with 8.2 and hope to check this > weekend. > > cheers, > > Prabhu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Nov 9 16:36:56 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 9 Nov 2018 13:36:56 -0800 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029180524.GA6078@rotor.localdomain> <20181029184335.GA21724@rotor.localdomain> <47D40257-F4CD-4829-AA63-4CC4D7CF494A@kitware.com> <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <568437f8-505e-e640-158f-04c31f7830d9@aero.iitb.ac.in> Message-ID: +1 On Fri, Nov 9, 2018, 10:59 AM Jean-Christophe Fillion-Robin < jcfr at kitware.com wrote: > > -------------------- > > > * Building any VTK module either externally or along with the VTK > project > > > ? (e.g this will be useful for creating python wheels) > > > I'm not sure the use case is clear to me. How are Python wheels related > to remote modules? > > As of today, it is possible to distribute and package part of VTK > independently. this is already done for the VTKOpenVR module. See [1] > > [1] > https://github.com/Kitware/VTK/blob/4cb368df22c2db23ed230f743422fcfd78570229/Rendering/OpenVR/CMakeLists.txt#L1-L9 > > The comment of David "VTK can be built kit-by-kit instead of all at once, > is a logical extension of the multiple package idea" also capture this > idea. > > From a user perspective, I see remote module as in "VTK module source > stored outside of VTK source tree" exactly the same way as regular module. > Ideally, a "project" command as well as a "find_package(VTK ... )" with > the expected dependency would be written in every VTK module. The only > exception would be a "VTKCore" module providing the build system > infrastructure. > > > -------------------- > > > I love the ***idea*** of remote modules but sort of hate them in > practice. I'm not sure if there is a way to make them work. Maybe someone > knows a way. > > Right now a change in VTK is as simple as one commit to one repo. > > This shouldn't change. The key idea here is that the underlying > build-system should treat them the same way. The only different is that the > source happen to already be available. > > > > > On Fri, Nov 9, 2018 at 12:05 PM Prabhu Ramachandran < > prabhu at aero.iitb.ac.in> wrote: > >> On 11/8/18 3:15 PM, David Gobbi wrote: >> >> On Thu, Nov 8, 2018 at 12:18 PM Ben Boeckel >> wrote: >> >>> >>> > * Building any VTK module either externally or along with the VTK >>> project >>> > ? (e.g this will be useful for creating python wheels) >>> >>> I'm not sure the use case is clear to me. How are Python wheels related >>> to remote modules? >>> >> >> Package managers like to be able to subdivide VTK into multiple packages. >> Being able to modularize the build itself, so that VTK can be built >> kit-by-kit >> instead of all at once, is a logical extension of the multiple package >> idea. >> If I recall correctly, the CI system for pypi was failing to build VTK >> due to >> timeouts (I'm not sure what the workaround was, I suspect that Prabhu >> built the wheels manually). >> >> Yes, I built the wheels with the VTKPythonPackage, ( >> https://github.com/KitwareMedical/VTKPythonPackage), it is largely >> automated but I did build it by hand and uploaded it. >> >> I am not sure if this is still broken with 8.2 and hope to check this >> weekend. >> >> cheers, >> >> Prabhu >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Sat Nov 10 03:16:06 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 10 Nov 2018 09:16:06 +0100 Subject: [vtk-developers] Up-to-date vtk-master debs? In-Reply-To: References: Message-ID: Den ons 7 nov. 2018 kl 20:48 skrev Elvis Stansvik : > > Hi all, > > The blog series about the Debian packaging back in July [1] mentioned > that a nightly builds of VTK would be packaged as vtk-master, but the > package currently in the APT repo (https://apt.kitware.com/) seems to > be to be from July 6. > > Anyone if nightly builds will become available at some point, or if > the initiative was cancelled? > > Would be absolutely fantastic if nightly packages were available, for > testing purposes ahead of releases. I found now that the source package kept at https://gitlab.kitware.com/debian/vtk seems to be up-to-date (current version is 2018.11.10-0kw1). But the version in the repo is 2018.07.06-0kw1 (see https://apt.kitware.com/debian/dists/sid/main/binary-amd64/Packages). Have the package builds stopped? Elvis > > Cheers, > Elvis > > [1] https://blog.kitware.com/rethinking-debian-packaging-for-vtk-and-other-cmake-projects-part-1/ From prabhu at aero.iitb.ac.in Sun Nov 11 22:05:50 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 11 Nov 2018 22:05:50 -0500 Subject: [vtk-developers] Transparency/depth peeling with Python and Qt on Linux Message-ID: <4d9c5670-b1b6-24e2-0ebc-f20aceffb8db@aero.iitb.ac.in> Hi all, Some folks have been running into strange rendering issues with the Qt Render window interactor in Python, on Linux, with transparent actors.? I've reduced this to two scripts that I attach which just require VTK-Python.? The first is with pure VTK and which seems to work fine and the second is with the QVTKRenderWindowInteractor which fails. The script just creates two semi-transparent spheres one next to the other and turns on depth peeling. When the example fails, the blue ball can never be seen in front of the red one.? This example works fine with VTK 8.1.1 on Mac OSX but fails on Linux (ubuntu 16.04 and 18.04).? The non pyqt one works just fine.? I did try experimenting with using QGLWidget and also with using the newer QOpenGLWidget but they both display the same issue on Linux it seems like. Have any of you seen this before?? The blog post here: https://blog.kitware.com/vtk-8-0-0/ suggests there are some transparency issues with the C++ widget as well but I am not sure if those are already resolved.? Any thoughts or pointers on this? Thanks! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tr_vtk_pyqt.py Type: text/x-python-script Size: 924 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tr_vtk.py Type: text/x-python-script Size: 945 bytes Desc: not available URL: From prabhu at aero.iitb.ac.in Sun Nov 11 22:18:52 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 11 Nov 2018 22:18:52 -0500 Subject: [vtk-developers] Transparency/depth peeling with Python and Qt on Linux In-Reply-To: <4d9c5670-b1b6-24e2-0ebc-f20aceffb8db@aero.iitb.ac.in> References: <4d9c5670-b1b6-24e2-0ebc-f20aceffb8db@aero.iitb.ac.in> Message-ID: Just another data point.? This is definitely Qt5 related as the script works fine with Qt4.8.x (PySide-1.2.2). cheers, Prabhu On 11/11/18 10:05 PM, Prabhu Ramachandran wrote: > > Hi all, > > Some folks have been running into strange rendering issues with the Qt Render > window interactor in Python, on Linux, with transparent actors.? I've reduced > this to two scripts that I attach which just require VTK-Python.? The first is > with pure VTK and which seems to work fine and the second is with the > QVTKRenderWindowInteractor which fails. > > The script just creates two semi-transparent spheres one next to the other and > turns on depth peeling. When the example fails, the blue ball can never be > seen in front of the red one.? This example works fine with VTK 8.1.1 on Mac > OSX but fails on Linux (ubuntu 16.04 and 18.04).? The non pyqt one works just > fine.? I did try experimenting with using QGLWidget and also with using the > newer QOpenGLWidget but they both display the same issue on Linux it seems like. > > Have any of you seen this before?? The blog post here: > https://blog.kitware.com/vtk-8-0-0/ suggests there are some transparency > issues with the C++ widget as well but I am not sure if those are already > resolved.? Any thoughts or pointers on this? > > Thanks! > > cheers, > > Prabhu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Nov 12 11:12:13 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 12 Nov 2018 11:12:13 -0500 Subject: [vtk-developers] New module system preview In-Reply-To: References: <20181029204225.GA22076@rotor.localdomain> <20181029214211.GA16451@rotor.localdomain> <20181108191757.GA7191@rotor.localdomain> <568437f8-505e-e640-158f-04c31f7830d9@aero.iitb.ac.in> Message-ID: <20181112161213.GB2265@rotor.localdomain> On Fri, Nov 09, 2018 at 13:58:56 -0500, Jean-Christophe Fillion-Robin wrote: > From a user perspective, I see remote module as in "VTK module source > stored outside of VTK source tree" exactly the same way as regular module. > Ideally, a "project" command as well as a "find_package(VTK ... )" with the > expected dependency would be written in every VTK module. The only > exception would be a "VTKCore" module providing the build system > infrastructure. OK, this is basically the same as my comment elsewhere in the thread where deciding where to slice up VTK is done after landing the module system. But, IMO, not something for this thread. Personally, I'd rather just see modules inside VTK's source repo only have one way to build (whether it be as part of VTK's main build or a standalone `find_package(VTK)` and calling the module system on their own). Those outside also only have one: `find_package(VTK)`. We're never going to test all the combinations. Note that `vtk_module_add_module` *only* works within `vtk_module_build` call. This does *not* make a module: ```cmake find_package(VTK COMPONENTS ...) vtk_module_add_module(mymodule) ``` Well, it'd be possible to hack up all the properties and such that are assumed, but I'm not going to document it because I don't want to have to support all the internals in use outside of a single version of `vtkModule.cmake`. --Ben From allison.vacanti at kitware.com Tue Nov 13 12:24:52 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Tue, 13 Nov 2018 12:24:52 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: <9be6acf8-a1e1-4e0f-bf61-2ffde98c8152@email.android.com> Message-ID: On Fri, Nov 9, 2018 at 8:45 AM David E DeMarle wrote: > +1 for the idea of converting vtk collections into stl conventions. > et voila: https://gitlab.kitware.com/vtk/vtk/commit/dd3fce7815ff2285a7b93e2ee5a642cdcd066626?merge_request_iid=4826 vtkCollection *collection = ...; for (auto item : vtk::Range(collection)) { // item is a vtkObject*. } vtkRendererCollection *renCollection = ...; for (auto item : vtk::Range(renCollection)) { // item is a vtkRenderer*. Type deduction works for all // collection types that define a GetNextItem() method // with a specialized type. } This design leaves the door open for other usages of vtk::Range(iterable) in the future. vtkCellIterators come to mind... Allie > On Fri, Nov 9, 2018, 6:49 AM Todd via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> Nice blog. >> >> On 10 Nov 2018 12:00 a.m., Allie Vacanti >> wrote: >> >> On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik > wrote: >> >> Any plans for something similar for vtkCollection*? >> >> >> Not currently, but that would be a very useful feature indeed. I think >> it'd be more than worthwhile to add a template that just translates the VTK >> iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to >> a set of STL iterators/range objects. This would allow it to work with >> quite a few different iterables in VTK. >> >> It'd have a similarly usage as the array iterators: >> >> vtk[...]Collection *myCollection = ...; >> for (auto item : vtk::Range(myCollection)) { ... } >> >> I'll put this on my list to look at in my spare cycles. Good suggestion! >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue Nov 13 13:53:45 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 13 Nov 2018 19:53:45 +0100 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: <9be6acf8-a1e1-4e0f-bf61-2ffde98c8152@email.android.com> Message-ID: Den tis 13 nov. 2018 kl 18:25 skrev Allie Vacanti : > > On Fri, Nov 9, 2018 at 8:45 AM David E DeMarle wrote: >> >> +1 for the idea of converting vtk collections into stl conventions. > > > et voila: > > https://gitlab.kitware.com/vtk/vtk/commit/dd3fce7815ff2285a7b93e2ee5a642cdcd066626?merge_request_iid=4826 > > vtkCollection *collection = ...; > for (auto item : vtk::Range(collection)) > { > // item is a vtkObject*. > } > > vtkRendererCollection *renCollection = ...; > for (auto item : vtk::Range(renCollection)) > { > // item is a vtkRenderer*. Type deduction works for all > // collection types that define a GetNextItem() method > // with a specialized type. > } > > This design leaves the door open for other usages of vtk::Range(iterable) in the future. vtkCellIterators come to mind... Wow, all-inclusive service at this place! In the same MR even. Let me see, what should I think up next.. :) Elvis > > Allie > >> >> On Fri, Nov 9, 2018, 6:49 AM Todd via vtk-developers wrote: >>> >>> Nice blog. >>> >>> On 10 Nov 2018 12:00 a.m., Allie Vacanti wrote: >>> >>> On Fri, Nov 9, 2018, 2:07 AM Elvis Stansvik >> >>> Any plans for something similar for vtkCollection*? >>> >>> >>> Not currently, but that would be a very useful feature indeed. I think it'd be more than worthwhile to add a template that just translates the VTK iteration convention (InitTraversal, GoToNextItem, IsDoneWithTraversal) to a set of STL iterators/range objects. This would allow it to work with quite a few different iterables in VTK. >>> >>> It'd have a similarly usage as the array iterators: >>> >>> vtk[...]Collection *myCollection = ...; >>> for (auto item : vtk::Range(myCollection)) { ... } >>> >>> I'll put this on my list to look at in my spare cycles. Good suggestion! >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From allison.vacanti at kitware.com Tue Nov 13 13:56:34 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Tue, 13 Nov 2018 13:56:34 -0500 Subject: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays In-Reply-To: References: <9be6acf8-a1e1-4e0f-bf61-2ffde98c8152@email.android.com> Message-ID: On Tue, Nov 13, 2018 at 1:53 PM Elvis Stansvik wrote: > Wow, all-inclusive service at this place! In the same MR even. Let me > see, what should I think up next.. :) > It was a good idea! And much easier/faster to write since performance here isn't nearly as critical as the DataArray case ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chethanab26 at gmail.com Fri Nov 16 03:07:10 2018 From: chethanab26 at gmail.com (chethana) Date: Fri, 16 Nov 2018 01:07:10 -0700 (MST) Subject: [vtk-developers] VTK water flow visualization or vector field visualization Message-ID: <1542355630491-0.post@n5.nabble.com> VTK C++ is used to visualize .obj file which contain multiple pipes and problem is that water flow representation has to be done inside the .obj file using arrow glyph or stream line and also how to generate structured gride date file using VTK C++.Thanks in advance -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From julien.finet at kitware.com Thu Nov 22 08:09:23 2018 From: julien.finet at kitware.com (Julien Finet) Date: Thu, 22 Nov 2018 14:09:23 +0100 Subject: [vtk-developers] Offscreen rendering Message-ID: Hi, What is the current best practice to have VTK with offscreen rendering support on Windows and with an NVidia card ? Mesa ? EGL ? Other ? Thanks, Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From biswajit.cs.10 at gmail.com Thu Nov 22 21:15:03 2018 From: biswajit.cs.10 at gmail.com (Biswajit Biswas) Date: Fri, 23 Nov 2018 07:45:03 +0530 Subject: [vtk-developers] vtk-developers Digest, Vol 175, Issue 16 In-Reply-To: References: Message-ID: Mesa On Thu, Nov 22, 2018 at 10:30 PM wrote: > Send vtk-developers mailing list submissions to > vtk-developers at public.kitware.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://public.kitware.com/mailman/listinfo/vtk-developers > or, via email, send a message with subject or body 'help' to > vtk-developers-request at public.kitware.com > > You can reach the person managing the list at > vtk-developers-owner at public.kitware.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vtk-developers digest..." > > > Today's Topics: > > 1. Offscreen rendering (Julien Finet) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Nov 2018 14:09:23 +0100 > From: Julien Finet > To: vtk-developers at vtk.org > Subject: [vtk-developers] Offscreen rendering > Message-ID: > < > CAKoWPPEzAzRBdjK_WTfmjPTxZEf9b_pqtvAwDHidSyRQJGUZZw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > What is the current best practice to have VTK with offscreen rendering > support on Windows and with an NVidia card ? Mesa ? EGL ? Other ? > > Thanks, > Julien. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://public.kitware.com/pipermail/vtk-developers/attachments/20181122/077b16a9/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > ------------------------------ > > End of vtk-developers Digest, Vol 175, Issue 16 > *********************************************** > -- thanks and regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Nov 23 10:01:04 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 23 Nov 2018 10:01:04 -0500 Subject: [vtk-developers] Offscreen rendering In-Reply-To: References: Message-ID: In vtk master I think the answer for all of those is to call OffScreenRenderingOn() prior to the first render. Or after the first render to call ShowWindow(false) UseOffScreenBuffers(true) On Thu, Nov 22, 2018 at 8:10 AM Julien Finet wrote: > Hi, > > What is the current best practice to have VTK with offscreen rendering > support on Windows and with an NVidia card ? Mesa ? EGL ? Other ? > > Thanks, > Julien. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Sat Nov 24 14:59:17 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sat, 24 Nov 2018 14:59:17 -0500 Subject: [vtk-developers] Offscreen rendering In-Reply-To: References: Message-ID: <95dd8fa9-69cd-7edc-1865-ea33dbafe683@aero.iitb.ac.in> On 11/23/18 10:01 AM, Ken Martin wrote: > In vtk master I think the answer for all of those is to call > OffScreenRenderingOn() prior to the first render.? Or after the first render > to call > > ShowWindow(false) > UseOffScreenBuffers(true) I see that you've centralized some of the code recently but you still need to enable EGL or Mesa at build time, and that can still be a bit tricky, right? Would it at all be possible to support one VTK build that has all the possible options available?? i.e. EGL, OSMesa, and the normal backend?? Or is that simply impossible to do on all platforms?? Would it make sense to bundle OSMesa with VTK?? At least on Linux this would make many things very convenient. Regards, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Sat Nov 24 17:10:45 2018 From: ken.martin at kitware.com (Ken Martin) Date: Sat, 24 Nov 2018 17:10:45 -0500 Subject: [vtk-developers] Offscreen rendering In-Reply-To: <95dd8fa9-69cd-7edc-1865-ea33dbafe683@aero.iitb.ac.in> References: <95dd8fa9-69cd-7edc-1865-ea33dbafe683@aero.iitb.ac.in> Message-ID: OffScreen does not require EGL or Mesa. You should be able to do offscreen with any opengl implementation. When folks mention offscreen, sometimes they mean "rendering without an xserver" or "rendering on a system without opengl 3.2" for those cases you can use EGL or Mesa or OSMesa depending on the issue. In terms of putting it all into one there is some OpenGL initiative to support this (I forget the name, gl virtual dispatch maybe) which could handle it I think. Failing that you can do the test at runtime and then dynamically load osmesa/mesa etc as needed. Some folks do that. I agree having it built in and automatically selected would be nice. Not sure how difficult it is though. On Sat, Nov 24, 2018 at 2:59 PM Prabhu Ramachandran wrote: > On 11/23/18 10:01 AM, Ken Martin wrote: > > In vtk master I think the answer for all of those is to call > OffScreenRenderingOn() prior to the first render. Or after the first > render to call > > ShowWindow(false) > UseOffScreenBuffers(true) > > > I see that you've centralized some of the code recently but you still need > to enable EGL or Mesa at build time, and that can still be a bit tricky, > right? > > Would it at all be possible to support one VTK build that has all the > possible options available? i.e. EGL, OSMesa, and the normal backend? Or > is that simply impossible to do on all platforms? Would it make sense to > bundle OSMesa with VTK? At least on Linux this would make many things very > convenient. > > Regards, > > Prabhu > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Sat Nov 24 21:52:09 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sat, 24 Nov 2018 21:52:09 -0500 Subject: [vtk-developers] Offscreen rendering In-Reply-To: References: <95dd8fa9-69cd-7edc-1865-ea33dbafe683@aero.iitb.ac.in> Message-ID: <81779cc7-c748-a45d-85a1-cb15d501541d@aero.iitb.ac.in> On 11/24/18 5:10 PM, Ken Martin wrote: > OffScreen does not require EGL or Mesa.? You should be able to do offscreen > with any opengl implementation. > > When folks mention offscreen, sometimes they mean "rendering without an > xserver" or "rendering on a system without opengl 3.2"? for those cases you > can use EGL or Mesa or OSMesa depending on the issue. Sorry that is what I meant, most of the use cases I've seen for off screen are typically for cases where having an xserver or any windowing system is not desired. > > In terms of putting it all into one there is some OpenGL initiative to support > this (I forget the name, gl virtual dispatch maybe) which could handle it I > think. Failing that you can do the test at runtime and then dynamically load > osmesa/mesa etc as needed. Some folks do that. I agree having it built in and > automatically selected would be nice. Not sure how difficult it is though. Thanks for the clarification! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From simakov.w at gmail.com Sun Nov 25 07:51:36 2018 From: simakov.w at gmail.com (Met@ll) Date: Sun, 25 Nov 2018 05:51:36 -0700 (MST) Subject: [vtk-developers] Bug in vtkXYPlotActor Message-ID: <1543150296356-0.post@n5.nabble.com> Hello! I found the following bug in the vtkXYPlotActor class: when using the ChartBoxOn method, the background does not move with the graph when the window size is changed (VTK-8.2.0.rc1) thank) -- Sent from: http://vtk.1045678.n5.nabble.com/VTK-Dev-f1251487.html From prabhu at aero.iitb.ac.in Sun Nov 25 20:23:14 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 25 Nov 2018 20:23:14 -0500 Subject: [vtk-developers] Python wheel building breakage in master In-Reply-To: References: Message-ID: <4fe20a84-4a03-2a1b-44b6-a7afd464a573@aero.iitb.ac.in> Hi everyone, I think I have a possible fix for this issue,? I've sent a MR here: https://gitlab.kitware.com/vtk/vtk/merge_requests/4913 Its a simple fix and allows the VTKPythonPackage to set the install dir for the Python modules and this makes it easy to build wheels for VTK 8.2.0. It would be great if this could be merged so we can make the required changes to the VTKPythonPackage thereafter. Incidentally, after building the wheels I found an issue that I will report separately. cheers, Prabhu On 10/8/18 1:17 AM, Prabhu Ramachandran wrote: > > Hi everyone, > > I was trying to build wheels with VTKPythonPackage with VTK master but the > recent changes with the vtkmodules package seems to have broken things. > > It is not clear what exact changes we need for this but it looks like this > commit may have broken this: > > https://gitlab.kitware.com/vtk/vtk/commit/867d93c2ab6bb4aaff80503e8037f649fe23cc4f > > It may be a simple thing to fix with the possible options available but I > haven't been able to get it working correctly.? This would be nice to fix > before the next VTK release. > > Thanks! > > cheers, > > Prabhu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Sun Nov 25 20:30:13 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sun, 25 Nov 2018 20:30:13 -0500 Subject: [vtk-developers] Segfault importing vtk on master Message-ID: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> Hi all, With VTK 8.2.x (master), I run into a segfault when I "import vtk" on Python 3.7 (I doubt it is specific to a particular Python version).? By simply commenting out from .vtkPythonInterpreter import * in the all.py module, the segfault is fixed.? I am not sure why this module should be put into all.py? If someone desires it they can manually import it.? Or is there something I am missing? Thanks! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Mon Nov 26 07:31:53 2018 From: julien.finet at kitware.com (Julien Finet) Date: Mon, 26 Nov 2018 13:31:53 +0100 Subject: [vtk-developers] Offscreen rendering In-Reply-To: References: <95dd8fa9-69cd-7edc-1865-ea33dbafe683@aero.iitb.ac.in> Message-ID: Thanks Ken for the detailed explanation. It is helpful. Julien. On Sat, Nov 24, 2018 at 11:10 PM Ken Martin wrote: > OffScreen does not require EGL or Mesa. You should be able to do > offscreen with any opengl implementation. > > When folks mention offscreen, sometimes they mean "rendering without an > xserver" or "rendering on a system without opengl 3.2" for those cases you > can use EGL or Mesa or OSMesa depending on the issue. > > In terms of putting it all into one there is some OpenGL initiative to > support this (I forget the name, gl virtual dispatch maybe) which could > handle it I think. Failing that you can do the test at runtime and then > dynamically load osmesa/mesa etc as needed. Some folks do that. I agree > having it built in and automatically selected would be nice. Not sure how > difficult it is though. > > > > On Sat, Nov 24, 2018 at 2:59 PM Prabhu Ramachandran < > prabhu at aero.iitb.ac.in> wrote: > >> On 11/23/18 10:01 AM, Ken Martin wrote: >> >> In vtk master I think the answer for all of those is to call >> OffScreenRenderingOn() prior to the first render. Or after the first >> render to call >> >> ShowWindow(false) >> UseOffScreenBuffers(true) >> >> >> I see that you've centralized some of the code recently but you still >> need to enable EGL or Mesa at build time, and that can still be a bit >> tricky, right? >> >> Would it at all be possible to support one VTK build that has all the >> possible options available? i.e. EGL, OSMesa, and the normal backend? Or >> is that simply impossible to do on all platforms? Would it make sense to >> bundle OSMesa with VTK? At least on Linux this would make many things very >> convenient. >> >> Regards, >> >> Prabhu >> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > Carrboro, North Carolina > 27510 USA > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Nov 26 09:42:37 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 26 Nov 2018 09:42:37 -0500 Subject: [vtk-developers] Segfault importing vtk on master In-Reply-To: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> References: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> Message-ID: It's getting added to all.py through the CMake code that simply adds all wrapped modules to it. I can't think of reason why the vtkPythonInterpreter module should be Python wrapped at all, however. Can you try the attached patch, please? Does it work? Thanks Utkarsh On Sun, Nov 25, 2018 at 8:30 PM Prabhu Ramachandran wrote: > > Hi all, > > With VTK 8.2.x (master), I run into a segfault when I "import vtk" on Python 3.7 (I doubt it is specific to a particular Python version). By simply commenting out > > from .vtkPythonInterpreter import * > > in the all.py module, the segfault is fixed. I am not sure why this module should be put into all.py? If someone desires it they can manually import it. Or is there something I am missing? > > Thanks! > > cheers, > > Prabhu > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- A non-text attachment was scrubbed... Name: dont-wrap-pythoninterpreter.patch Type: text/x-patch Size: 372 bytes Desc: not available URL: From marcus.hanwell at kitware.com Mon Nov 26 11:59:20 2018 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 26 Nov 2018 11:59:20 -0500 Subject: [vtk-developers] Python 3.7 behavior change, GIL, and threading in C/C++ with Python Message-ID: Hi, I have seen several fixes for Python 3.7, but have been tracking down why Tomviz deadlocks on when using vtkPythonScopeGilEnsurer, and it appears to be related to the Python specific flags we are using and a behavior change in Python 3.7. This may mainly be a question for David Gobbi and/or Utkarsh. but I send it to the list so that others have a chance to see it, and it gets indexed should others hit this issue. We use VTK_PYTHON_FULL_THREADSAFE set to ON, and VTK_NO_PYTHON_THREADS set to OFF. This means that when vtkPythonInterpreter::Initialize is called that the following code will be called: #ifdef VTK_PYTHON_FULL_THREADSAFE int threadInit = PyEval_ThreadsInitialized(); PyEval_InitThreads(); // safe to call this multiple time if (!threadInit) { PyEval_SaveThread(); // release GIL } #endif This was effectively always calling PyEval_SaveThread() before Python 3.7. but this is now never being called as starting with Python 3.7 Py_Initialize will initialize the GIL, see https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads for details. It looks like this check was done to ensure that PyEval_SaveThread would only be called once, now that PyEval_InitThreads doesn't need to be called, moving PyEval_SaveThread outside of the conditional gets rid of the deadlock for me. It looks like something needs to be changed for 3.7+, but I am not clear on how necessary this logic is. This reminds me that VTK_PYTHON_FULL_THREADSAFE is used in VTK, but the CMake option is in ParaView only as far as I can see. Should that be moved down into VTK, it seems odd. Thanks, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Mon Nov 26 13:56:22 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Mon, 26 Nov 2018 13:56:22 -0500 Subject: [vtk-developers] Segfault importing vtk on master In-Reply-To: References: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> Message-ID: <4adb844b-31c0-fd20-d090-d0014a510354@aero.iitb.ac.in> Hi Utkarsh, Yes, I can confirm that this fixes the issue.? Can you please merge this to master and the 8.2.0 release?? Thanks! Regards, Prabhu On 11/26/18 9:42 AM, Utkarsh Ayachit wrote: > It's getting added to all.py through the CMake code that simply adds > all wrapped modules to it. I can't think of reason why the > vtkPythonInterpreter module should be Python wrapped at all, however. > Can you try the attached patch, please? Does it work? > > Thanks > Utkarsh > On Sun, Nov 25, 2018 at 8:30 PM Prabhu Ramachandran > wrote: >> Hi all, >> >> With VTK 8.2.x (master), I run into a segfault when I "import vtk" on Python 3.7 (I doubt it is specific to a particular Python version). By simply commenting out >> >> from .vtkPythonInterpreter import * >> >> in the all.py module, the segfault is fixed. I am not sure why this module should be put into all.py? If someone desires it they can manually import it. Or is there something I am missing? >> >> Thanks! >> >> cheers, >> >> Prabhu >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Nov 26 14:14:10 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 26 Nov 2018 12:14:10 -0700 Subject: [vtk-developers] Segfault importing vtk on master In-Reply-To: <4adb844b-31c0-fd20-d090-d0014a510354@aero.iitb.ac.in> References: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> <4adb844b-31c0-fd20-d090-d0014a510354@aero.iitb.ac.in> Message-ID: EXCLUDE_FROM_WRAPPING might be better than EXCLUDE_FROM_PYTHON_WRAPPING, for consistency with the rest of the Utilities modules. On Mon, Nov 26, 2018 at 11:56 AM Prabhu Ramachandran wrote: > Hi Utkarsh, > > Yes, I can confirm that this fixes the issue. Can you please merge this > to master and the 8.2.0 release? Thanks! > > Regards, > Prabhu > > On 11/26/18 9:42 AM, Utkarsh Ayachit wrote: > > It's getting added to all.py through the CMake code that simply adds > all wrapped modules to it. I can't think of reason why the > vtkPythonInterpreter module should be Python wrapped at all, however. > Can you try the attached patch, please? Does it work? > > Thanks > Utkarsh > On Sun, Nov 25, 2018 at 8:30 PM Prabhu Ramachandran wrote: > > Hi all, > > With VTK 8.2.x (master), I run into a segfault when I "import vtk" on Python 3.7 (I doubt it is specific to a particular Python version). By simply commenting out > > from .vtkPythonInterpreter import * > > in the all.py module, the segfault is fixed. I am not sure why this module should be put into all.py? If someone desires it they can manually import it. Or is there something I am missing? > > Thanks! > > cheers, > > Prabhu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Mon Nov 26 14:32:24 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 26 Nov 2018 14:32:24 -0500 Subject: [vtk-developers] Python wheel building breakage in master In-Reply-To: <4fe20a84-4a03-2a1b-44b6-a7afd464a573@aero.iitb.ac.in> References: <4fe20a84-4a03-2a1b-44b6-a7afd464a573@aero.iitb.ac.in> Message-ID: Hi Prabhu, Thanks a lot for helping fix VTK and the VTKPythonPackage package. Jc On Sun, Nov 25, 2018 at 8:23 PM Prabhu Ramachandran wrote: > Hi everyone, > > I think I have a possible fix for this issue, I've sent a MR here: > https://gitlab.kitware.com/vtk/vtk/merge_requests/4913 > > Its a simple fix and allows the VTKPythonPackage to set the install dir > for the Python modules and this makes it easy to build wheels for VTK 8.2.0. > > It would be great if this could be merged so we can make the required > changes to the VTKPythonPackage thereafter. > > Incidentally, after building the wheels I found an issue that I will > report separately. > > cheers, > Prabhu > > On 10/8/18 1:17 AM, Prabhu Ramachandran wrote: > > Hi everyone, > > I was trying to build wheels with VTKPythonPackage with VTK master but the > recent changes with the vtkmodules package seems to have broken things. > > It is not clear what exact changes we need for this but it looks like this > commit may have broken this: > > > https://gitlab.kitware.com/vtk/vtk/commit/867d93c2ab6bb4aaff80503e8037f649fe23cc4f > > It may be a simple thing to fix with the possible options available but I > haven't been able to get it working correctly. This would be nice to fix > before the next VTK release. > > Thanks! > > cheers, > > Prabhu > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Nov 26 15:45:00 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 26 Nov 2018 15:45:00 -0500 Subject: [vtk-developers] Segfault importing vtk on master In-Reply-To: References: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> <4adb844b-31c0-fd20-d090-d0014a510354@aero.iitb.ac.in> Message-ID: Here's the MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/4920 On Mon, Nov 26, 2018 at 2:14 PM David Gobbi wrote: > > EXCLUDE_FROM_WRAPPING might be better than EXCLUDE_FROM_PYTHON_WRAPPING, for consistency with the rest of the Utilities modules. > > On Mon, Nov 26, 2018 at 11:56 AM Prabhu Ramachandran wrote: >> >> Hi Utkarsh, >> >> Yes, I can confirm that this fixes the issue. Can you please merge this to master and the 8.2.0 release? Thanks! >> >> Regards, >> Prabhu >> >> On 11/26/18 9:42 AM, Utkarsh Ayachit wrote: >> >> It's getting added to all.py through the CMake code that simply adds >> all wrapped modules to it. I can't think of reason why the >> vtkPythonInterpreter module should be Python wrapped at all, however. >> Can you try the attached patch, please? Does it work? >> >> Thanks >> Utkarsh >> On Sun, Nov 25, 2018 at 8:30 PM Prabhu Ramachandran >> wrote: >> >> Hi all, >> >> With VTK 8.2.x (master), I run into a segfault when I "import vtk" on Python 3.7 (I doubt it is specific to a particular Python version). By simply commenting out >> >> from .vtkPythonInterpreter import * >> >> in the all.py module, the segfault is fixed. I am not sure why this module should be put into all.py? If someone desires it they can manually import it. Or is there something I am missing? >> >> Thanks! >> >> cheers, >> >> Prabhu From utkarsh.ayachit at kitware.com Mon Nov 26 20:03:57 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 26 Nov 2018 20:03:57 -0500 Subject: [vtk-developers] Segfault importing vtk on master In-Reply-To: References: <6c57eaf5-a2eb-3d8d-9e20-c71d2d1b4c00@aero.iitb.ac.in> <4adb844b-31c0-fd20-d090-d0014a510354@aero.iitb.ac.in> Message-ID: This fix is now merged in master and the release branch. Utkarsh On Mon, Nov 26, 2018 at 3:45 PM Utkarsh Ayachit wrote: > > Here's the MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/4920 > On Mon, Nov 26, 2018 at 2:14 PM David Gobbi wrote: > > > > EXCLUDE_FROM_WRAPPING might be better than EXCLUDE_FROM_PYTHON_WRAPPING, for consistency with the rest of the Utilities modules. > > > > On Mon, Nov 26, 2018 at 11:56 AM Prabhu Ramachandran wrote: > >> > >> Hi Utkarsh, > >> > >> Yes, I can confirm that this fixes the issue. Can you please merge this to master and the 8.2.0 release? Thanks! > >> > >> Regards, > >> Prabhu > >> > >> On 11/26/18 9:42 AM, Utkarsh Ayachit wrote: > >> > >> It's getting added to all.py through the CMake code that simply adds > >> all wrapped modules to it. I can't think of reason why the > >> vtkPythonInterpreter module should be Python wrapped at all, however. > >> Can you try the attached patch, please? Does it work? > >> > >> Thanks > >> Utkarsh > >> On Sun, Nov 25, 2018 at 8:30 PM Prabhu Ramachandran > >> wrote: > >> > >> Hi all, > >> > >> With VTK 8.2.x (master), I run into a segfault when I "import vtk" on Python 3.7 (I doubt it is specific to a particular Python version). By simply commenting out > >> > >> from .vtkPythonInterpreter import * > >> > >> in the all.py module, the segfault is fixed. I am not sure why this module should be put into all.py? If someone desires it they can manually import it. Or is there something I am missing? > >> > >> Thanks! > >> > >> cheers, > >> > >> Prabhu From dave.demarle at kitware.com Tue Nov 27 10:46:17 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 27 Nov 2018 10:46:17 -0500 Subject: [vtk-developers] announce: VTK 8.2.0 release candidate two is out Message-ID: Please give it a try. More info here: https://blog.kitware.com/vtk-8-2-0-rc2-ready-for-testing/ David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Tue Nov 27 15:01:01 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Tue, 27 Nov 2018 15:01:01 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels Message-ID: Hi all, Here is hopefully the last of the issues I am running into, I just tried to create wheels for 8.2.0-rc2 and have the following problem.? First for some background.? Some of the VTK Python libraries seem to link to the PYTHON_LIBRARY, for the wheels, we do not do this.? JC pointed this out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1 Basically, if we build wheels linking to the libpython* the wheel may not work on Ubuntu/Debian which would be sad. In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that.? This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain.? Anyway, when I try to build the wheels now on MacOS I get this error: Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib : && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup? -compatibility_version 1.0.0 -current_version 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name @rpath/libvtkPythonInterpreter-8.2.1.dylib Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o? -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && : ld: file too small (length=0) file 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY entry blank.? This means that the libvtkPythonInterpreter-8.2.1.dylib does indeed link to the libpythonx.y.dylib.? However, I do notice that the other libvtk*Python*8.2.1.dylib do not link to libpython.? So libvtkPythonInterpreter is the only one linking to libpython. So I think maybe if a user never uses the libvtkPythonInterpreter or if that is never explicitly imported or linked to in any Python code, we may be fine with these wheels.? Also I see that none of the Python extension modules, i.e. all the vtk*Python.so do not link to libpython or to libvtkPythonInterpreter. Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank? I would appreciate your thoughts on this matter. Thanks! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreekanth.arikatla at kitware.com Tue Nov 27 15:59:40 2018 From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla) Date: Tue, 27 Nov 2018 15:59:40 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: Message-ID: https://docs.google.com/document/d/1oNurBxXA_UCZcg_08E54fxWTe0noDnxdIX9gPw-74d8/edit# On Tue, Nov 27, 2018 at 3:01 PM Prabhu Ramachandran wrote: > Hi all, > > Here is hopefully the last of the issues I am running into, I just tried > to create wheels for 8.2.0-rc2 and have the following problem. > > First for some background. Some of the VTK Python libraries seem to link > to the PYTHON_LIBRARY, for the wheels, we do not do this. JC pointed this > out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1 > > Basically, if we build wheels linking to the libpython* the wheel may not > work on Ubuntu/Debian which would be sad. > > In the past what we did to build the wheels is provide a dummy > VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter > and passing that. This somehow worked by tricking CMake into thinking > there was a library specified but I am not sure how the linker did not > complain. Anyway, when I try to build the wheels now on MacOS I get this > error: > > Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib > FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib > : && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch > x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk > -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names > -undefined dynamic_lookup -compatibility_version 1.0.0 -current_version > 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name > @rpath/libvtkPythonInterpreter-8.2.1.dylib > Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o > Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o > -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib > VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter > lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && : > ld: file too small (length=0) file > 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' > for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY > entry blank. This means that the libvtkPythonInterpreter-8.2.1.dylib does > indeed link to the libpythonx.y.dylib. > > However, I do notice that the other libvtk*Python*8.2.1.dylib do not link > to libpython. So libvtkPythonInterpreter is the only one linking to > libpython. So I think maybe if a user never uses the > libvtkPythonInterpreter or if that is never explicitly imported or linked > to in any Python code, we may be fine with these wheels. Also I see that > none of the Python extension modules, i.e. all the vtk*Python.so do not > link to libpython or to libvtkPythonInterpreter. > > Should I just ignore the libvtkPythonInterpreter and leave the > PYTHON_LIBRARY field blank? > > I would appreciate your thoughts on this matter. Thanks! > > cheers, > > Prabhu > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- Sreekanth Arikatla, Ph.D., Senior R&D Engineer, Kitware, Inc. , Carrboro, NC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreekanth.arikatla at kitware.com Tue Nov 27 16:00:36 2018 From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla) Date: Tue, 27 Nov 2018 16:00:36 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: Message-ID: Please ignore the previous email. I sent it by mistake. On Tue, Nov 27, 2018 at 3:59 PM Sreekanth Arikatla < sreekanth.arikatla at kitware.com> wrote: > > https://docs.google.com/document/d/1oNurBxXA_UCZcg_08E54fxWTe0noDnxdIX9gPw-74d8/edit# > > On Tue, Nov 27, 2018 at 3:01 PM Prabhu Ramachandran < > prabhu at aero.iitb.ac.in> wrote: > >> Hi all, >> >> Here is hopefully the last of the issues I am running into, I just tried >> to create wheels for 8.2.0-rc2 and have the following problem. >> >> First for some background. Some of the VTK Python libraries seem to link >> to the PYTHON_LIBRARY, for the wheels, we do not do this. JC pointed this >> out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1 >> >> Basically, if we build wheels linking to the libpython* the wheel may not >> work on Ubuntu/Debian which would be sad. >> >> In the past what we did to build the wheels is provide a dummy >> VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter >> and passing that. This somehow worked by tricking CMake into thinking >> there was a library specified but I am not sure how the linker did not >> complain. Anyway, when I try to build the wheels now on MacOS I get this >> error: >> >> Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib >> FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib >> : && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch >> x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk >> -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names >> -undefined dynamic_lookup -compatibility_version 1.0.0 -current_version >> 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name >> @rpath/libvtkPythonInterpreter-8.2.1.dylib >> Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o >> Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o >> -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib >> VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter >> lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && : >> ld: file too small (length=0) file >> 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' >> for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> >> Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY >> entry blank. This means that the libvtkPythonInterpreter-8.2.1.dylib does >> indeed link to the libpythonx.y.dylib. >> >> However, I do notice that the other libvtk*Python*8.2.1.dylib do not link >> to libpython. So libvtkPythonInterpreter is the only one linking to >> libpython. So I think maybe if a user never uses the >> libvtkPythonInterpreter or if that is never explicitly imported or linked >> to in any Python code, we may be fine with these wheels. Also I see that >> none of the Python extension modules, i.e. all the vtk*Python.so do not >> link to libpython or to libvtkPythonInterpreter. >> >> Should I just ignore the libvtkPythonInterpreter and leave the >> PYTHON_LIBRARY field blank? >> >> I would appreciate your thoughts on this matter. Thanks! >> >> cheers, >> >> Prabhu >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > -- > Sreekanth Arikatla, Ph.D., > Senior R&D Engineer, > Kitware, Inc. , Carrboro, NC. > > -- Sreekanth Arikatla, Ph.D., Senior R&D Engineer, Kitware, Inc. , Carrboro, NC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Tue Nov 27 19:02:14 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 27 Nov 2018 19:02:14 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: Message-ID: Hi Prabhu, > In the past what we did to build the wheels is provide a dummy VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter and passing that. This somehow worked by tricking CMake into thinking there was a library specified but I am not sure how the linker did not complain. This was done to ensure no library was strongly linking against python library. And if it did, the error message would be more explicit. It was working because the library was always weakly linked in older version of VTK. > Should I just ignore the libvtkPythonInterpreter and leave the PYTHON_LIBRARY field blank? It looks like introducing an option to conditionally build vtkPythonInterpreter would address the issue here. @Ben: What do you think ? Jc On Tue, Nov 27, 2018 at 3:01 PM Prabhu Ramachandran wrote: > Hi all, > > Here is hopefully the last of the issues I am running into, I just tried > to create wheels for 8.2.0-rc2 and have the following problem. > > First for some background. Some of the VTK Python libraries seem to link > to the PYTHON_LIBRARY, for the wheels, we do not do this. JC pointed this > out to me https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1 > > Basically, if we build wheels linking to the libpython* the wheel may not > work on Ubuntu/Debian which would be sad. > > In the past what we did to build the wheels is provide a dummy > VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter > and passing that. This somehow worked by tricking CMake into thinking > there was a library specified but I am not sure how the linker did not > complain. Anyway, when I try to build the wheels now on MacOS I get this > error: > > Linking CXX shared library...ib/libvtkPythonInterpreter-8.2.1.dylib > FAILED: lib/libvtkPythonInterpreter-8.2.1.dylib > : && /Library/Developer/CommandLineTools/usr/bin/c++ -O3 -DNDEBUG -arch > x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk > -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names > -undefined dynamic_lookup -compatibility_version 1.0.0 -current_version > 1.0.0 -o lib/libvtkPythonInterpreter-8.2.1.dylib -install_name > @rpath/libvtkPythonInterpreter-8.2.1.dylib > Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInterpreter.cxx.o > Utilities/PythonInterpreter/CMakeFiles/vtkPythonInterpreter.dir/vtkPythonInteractiveInterpreter.cxx.o > -Wl,-rpath,VTKPythonPackage/VTK-osx_3.7/lib > VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter > lib/libvtksys-8.2.1.dylib lib/libvtkCommon-8.2.1.dylib && : > ld: file too small (length=0) file > 'VTKPythonPackage/scripts/internal/libpython-not-needed-symbols-exported-by-interpreter' > for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > Right now, I am able to build wheels only by leaving the PYTHON_LIBRARY > entry blank. This means that the libvtkPythonInterpreter-8.2.1.dylib does > indeed link to the libpythonx.y.dylib. > > However, I do notice that the other libvtk*Python*8.2.1.dylib do not link > to libpython. So libvtkPythonInterpreter is the only one linking to > libpython. So I think maybe if a user never uses the > libvtkPythonInterpreter or if that is never explicitly imported or linked > to in any Python code, we may be fine with these wheels. Also I see that > none of the Python extension modules, i.e. all the vtk*Python.so do not > link to libpython or to libvtkPythonInterpreter. > > Should I just ignore the libvtkPythonInterpreter and leave the > PYTHON_LIBRARY field blank? > > I would appreciate your thoughts on this matter. Thanks! > > cheers, > > Prabhu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rroemer at gmail.com Wed Nov 28 09:31:57 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Wed, 28 Nov 2018 15:31:57 +0100 Subject: [vtk-developers] Identify the Python version of VTK Message-ID: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> Hello. How could I get the Python version VTK is wrapped to? I want to know whether it is Python 2 or 3. Within CMake! Best regards Ronald From ben.boeckel at kitware.com Wed Nov 28 11:00:41 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 28 Nov 2018 11:00:41 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: Message-ID: <20181128160041.GA25730@megas.kitware.com> On Tue, Nov 27, 2018 at 19:02:14 -0500, Jean-Christophe Fillion-Robin wrote: > > Should I just ignore the libvtkPythonInterpreter and leave the > > PYTHON_LIBRARY field blank? It being blank will cause `find_library` to try and find it itself. I think the error is that now an empty linker script is not valid, but I'm not sure. Is it possible to use an older compiler/linker to make the wheels? > It looks like introducing an option to conditionally build > vtkPythonInterpreter would address the issue here. > > @Ben: What do you think ? How would this work? If it is disabled, `vtkWrappingPythonCore` (a dependency of all wrapped Python modules) and `vtkRenderingMatplotlib` can't be built. For the record, the new module system's way of doing this is here: https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Utilities/Python/CMakeLists.txt#L118 Basically, the `VTK::Python` module contains the library for executables, but is just the magic flags to ignore the missing symbols when linking libraries. So, it should "just work", but it does require 3.13+ for `target_link_options` (without it, direct linking is used). It can't really be backported because the old module system is quite allergic to CMake's target stuff (since it was designed basically as the same thing, but predate's CMake's logic). --Ben From aron.helser at kitware.com Wed Nov 28 11:24:55 2018 From: aron.helser at kitware.com (Aron Helser) Date: Wed, 28 Nov 2018 11:24:55 -0500 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> Message-ID: The cmake variable VTK_PYTHON_VERSION has the requested version, and it's 2 by default. The user can make it more specific, like "3.6", for example. -Aron On Wed, Nov 28, 2018 at 9:43 AM Ronald R?mer wrote: > Hello. > > How could I get the Python version VTK is wrapped to? I want to know > whether it is Python 2 or 3. Within CMake! > > > Best regards > > Ronald > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rroemer at gmail.com Wed Nov 28 12:55:36 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Wed, 28 Nov 2018 18:55:36 +0100 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> Message-ID: According to https://blog.kitware.com/vtk-7-0-0/ VTK_PYTHON_VERSION should be set. I installed VTK 8.1.2 with pacman on Arch Linux. These are the variables starting with VTK_: https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 But where is VTK_PYTHON_VERSION? Do you have an idea? On 28.11.18 17:24, Aron Helser wrote: > The cmake variable?VTK_PYTHON_VERSION has the requested version, and > it's 2 by default. The user can make it more specific, like "3.6", for > example. > > -Aron > > On Wed, Nov 28, 2018 at 9:43 AM Ronald R?mer > wrote: > > Hello. > > How could I get the Python version VTK is wrapped to? I want to know > whether it is Python 2 or 3. Within CMake! > > > Best regards > > Ronald > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > -- Viele Gr??e Ronald R?mer -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Nov 28 13:18:18 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 28 Nov 2018 11:18:18 -0700 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> Message-ID: Hi Ronald, The exported configuration options are in VTKConfig.cmake. I searched this file, and the only Python-related setting was VTK_WRAP_PYTHON. VTK doesn't export VTK_PYTHON_VERSION for use by other projects. David On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer wrote: > According to https://blog.kitware.com/vtk-7-0-0/ VTK_PYTHON_VERSION > should be set. I installed VTK 8.1.2 with pacman on Arch Linux. These are > the variables starting with VTK_: > https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 But > where is VTK_PYTHON_VERSION? Do you have an idea? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rroemer at gmail.com Wed Nov 28 13:28:54 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Wed, 28 Nov 2018 19:28:54 +0100 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> Message-ID: <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> :( On 28.11.18 19:18, David Gobbi wrote: > Hi Ronald, > > The exported configuration options are in VTKConfig.cmake.? I searched > this file, and the only Python-related setting was VTK_WRAP_PYTHON.? > VTK doesn't export VTK_PYTHON_VERSION for use by other projects. > > ? David > > > On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer > wrote: > > According to https://blog.kitware.com/vtk-7-0-0/ > VTK_PYTHON_VERSION should be set. I installed VTK 8.1.2 with > pacman on Arch Linux. These are the variables starting with VTK_: > https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 > But where is VTK_PYTHON_VERSION? Do you have an idea? > -- Viele Gr??e Ronald R?mer -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Nov 28 13:32:24 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 28 Nov 2018 11:32:24 -0700 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> Message-ID: Would be a useful thing, though. I'll see about submitting an MR. On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer wrote: > :( > > On 28.11.18 19:18, David Gobbi wrote: > > Hi Ronald, > > The exported configuration options are in VTKConfig.cmake. I searched > this file, and the only Python-related setting was VTK_WRAP_PYTHON. VTK > doesn't export VTK_PYTHON_VERSION for use by other projects. > > David > > > On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer wrote: > >> According to https://blog.kitware.com/vtk-7-0-0/ VTK_PYTHON_VERSION >> should be set. I installed VTK 8.1.2 with pacman on Arch Linux. These are >> the variables starting with VTK_: >> https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 But >> where is VTK_PYTHON_VERSION? Do you have an idea? >> > > -- > Viele Gr??e > Ronald R?mer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Nov 28 14:10:12 2018 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 28 Nov 2018 14:10:12 -0500 Subject: [vtk-developers] Python 3.7 behavior change, GIL, and threading in C/C++ with Python In-Reply-To: References: Message-ID: On Mon, Nov 26, 2018 at 11:59 AM Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > Hi, > > I have seen several fixes for Python 3.7, but have been tracking down why > Tomviz deadlocks on when using vtkPythonScopeGilEnsurer, and it appears to > be related to the Python specific flags we are using and a behavior change > in Python 3.7. This may mainly be a question for David Gobbi and/or > Utkarsh. but I send it to the list so that others have a chance to see it, > and it gets indexed should others hit this issue. > > We use VTK_PYTHON_FULL_THREADSAFE set to ON, and VTK_NO_PYTHON_THREADS set > to OFF. This means that when vtkPythonInterpreter::Initialize is called > that the following code will be called: > > #ifdef VTK_PYTHON_FULL_THREADSAFE > int threadInit = PyEval_ThreadsInitialized(); > PyEval_InitThreads(); // safe to call this multiple time > if (!threadInit) > { > PyEval_SaveThread(); // release GIL > } > #endif > > This was effectively always calling PyEval_SaveThread() before Python 3.7. > but this is now never being called as starting with Python 3.7 > Py_Initialize will initialize the GIL, see > https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads for > details. > > It looks like this check was done to ensure that PyEval_SaveThread would > only be called once, now that PyEval_InitThreads doesn't need to be called, > moving PyEval_SaveThread outside of the conditional gets rid of the > deadlock for me. It looks like something needs to be changed for 3.7+, but > I am not clear on how necessary this logic is. > I submitted https://gitlab.kitware.com/vtk/vtk/merge_requests/4921 for review, it seems to check out in VTK, and a related ParaView branch moving VTK forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Wed Nov 28 15:06:43 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 28 Nov 2018 15:06:43 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: <20181128160041.GA25730@megas.kitware.com> References: <20181128160041.GA25730@megas.kitware.com> Message-ID: On 11/28/18 11:00 AM, Ben Boeckel wrote: > On Tue, Nov 27, 2018 at 19:02:14 -0500, Jean-Christophe Fillion-Robin wrote: >>> Should I just ignore the libvtkPythonInterpreter and leave the >>> PYTHON_LIBRARY field blank? > It being blank will cause `find_library` to try and find it itself. I > think the error is that now an empty linker script is not valid, but I'm > not sure. Is it possible to use an older compiler/linker to make the > wheels? Unfortunately, that is a pain, so no, I don't think it would be convenient or meaningful to expect an older compiler/linker. >> It looks like introducing an option to conditionally build >> vtkPythonInterpreter would address the issue here. >> >> @Ben: What do you think ? > How would this work? If it is disabled, `vtkWrappingPythonCore` (a > dependency of all wrapped Python modules) and `vtkRenderingMatplotlib` > can't be built. Does vtkWrappingPythonCore depend on vtkPythonInterpreter?? vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter.? The wheels by default do not seem to enable vtkRenderingMatplotlib although I am not sure if it should be added by default in the future, in which case this is a more serious issue. > For the record, the new module system's way of doing this is here: > > https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Utilities/Python/CMakeLists.txt#L118 > > Basically, the `VTK::Python` module contains the library for > executables, but is just the magic flags to ignore the missing symbols > when linking libraries. So, it should "just work", but it does require > 3.13+ for `target_link_options` (without it, direct linking is used). It > can't really be backported because the old module system is quite > allergic to CMake's target stuff (since it was designed basically as the > same thing, but predate's CMake's logic). I think requiring a newer CMake is fairly reasonable if that will solve the problem unless I am missing something obvious here (which is very likely). cheers, Prabhu > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Nov 28 15:44:33 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 28 Nov 2018 15:44:33 -0500 Subject: [vtk-developers] vtk-8.2.0-rc2 problem building wheels In-Reply-To: References: <20181128160041.GA25730@megas.kitware.com> Message-ID: <20181128204433.GB4242@megas.kitware.com> On Wed, Nov 28, 2018 at 15:06:43 -0500, Prabhu Ramachandran wrote: > Does vtkWrappingPythonCore depend on vtkPythonInterpreter?? > vtkWrappingPythonCore does not link to libpython or to vtkPythonInterpreter.? My bad, it's a COMPILE_DEPENDS. Though why that is isn't obvious. Removing that dependency and then disabling the module should work. > The wheels by default do not seem to enable vtkRenderingMatplotlib although I am > not sure if it should be added by default in the future, in which case this is a > more serious issue. IMO, distribution builds should try to enable *everything* so there isn't a question of "what do I have today?" when doing `import vtk`. Keeping it disabled for 8.2 sounds fine, but 9.x will make it easier to not have the linking problem. --Ben From rroemer at gmail.com Thu Nov 29 04:06:54 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Thu, 29 Nov 2018 10:06:54 +0100 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> Message-ID: <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> What else could I do to get the version? On 28.11.18 19:32, David Gobbi wrote: > Would be a useful thing, though.? I'll see about submitting an MR. > > On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer > wrote: > > :( > > On 28.11.18 19:18, David Gobbi wrote: >> Hi Ronald, >> >> The exported configuration options are in VTKConfig.cmake.? I >> searched this file, and the only Python-related setting was >> VTK_WRAP_PYTHON.? VTK doesn't export VTK_PYTHON_VERSION for use >> by other projects. >> >> ? David >> >> >> On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer > > wrote: >> >> According to https://blog.kitware.com/vtk-7-0-0/ >> VTK_PYTHON_VERSION should be set. I installed VTK 8.1.2 with >> pacman on Arch Linux. These are the variables starting with >> VTK_: >> https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 >> But where is VTK_PYTHON_VERSION? Do you have an idea? >> > > -- > Viele Gr??e > Ronald R?mer > -- Viele Gr??e Ronald R?mer -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Nov 29 09:28:24 2018 From: DLRdave at aol.com (David Cole) Date: Thu, 29 Nov 2018 09:28:24 -0500 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> Message-ID: Can you run vtkpython and try something that only works in python 2 (or 3) and infer it...? On Thu, Nov 29, 2018 at 4:06 AM Ronald R?mer wrote: > > What else could I do to get the version? > > > On 28.11.18 19:32, David Gobbi wrote: > > Would be a useful thing, though. I'll see about submitting an MR. > > On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer wrote: >> >> :( >> >> On 28.11.18 19:18, David Gobbi wrote: >> >> Hi Ronald, >> >> The exported configuration options are in VTKConfig.cmake. I searched this file, and the only Python-related setting was VTK_WRAP_PYTHON. VTK doesn't export VTK_PYTHON_VERSION for use by other projects. >> >> David >> >> >> On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer wrote: >>> >>> According to https://blog.kitware.com/vtk-7-0-0/ VTK_PYTHON_VERSION should be set. I installed VTK 8.1.2 with pacman on Arch Linux. These are the variables starting with VTK_: https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 But where is VTK_PYTHON_VERSION? Do you have an idea? >> >> >> -- >> Viele Gr??e >> Ronald R?mer > > -- > Viele Gr??e > Ronald R?mer > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > From jcfr at kitware.com Thu Nov 29 10:00:29 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 29 Nov 2018 10:00:29 -0500 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> Message-ID: Hi Ronald, Running the following with the help of execute_process should help answer your question: ./bin/vtkpython -c "import sys; print(sys.version_info[0:3])" You could also call it three times in a row, to get major, minor and patch version. ./bin/vtkpython -c "import sys; print(sys.version_info[0])" ./bin/vtkpython -c "import sys; print(sys.version_info[1])" ./bin/vtkpython -c "import sys; print(sys.version_info[2])" On Thu, Nov 29, 2018 at 9:28 AM David Cole via vtk-developers < vtk-developers at public.kitware.com> wrote: > Can you run vtkpython and try something that only works in python 2 > (or 3) and infer it...? > On Thu, Nov 29, 2018 at 4:06 AM Ronald R?mer wrote: > > > > What else could I do to get the version? > > > > > > On 28.11.18 19:32, David Gobbi wrote: > > > > Would be a useful thing, though. I'll see about submitting an MR. > > > > On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer wrote: > >> > >> :( > >> > >> On 28.11.18 19:18, David Gobbi wrote: > >> > >> Hi Ronald, > >> > >> The exported configuration options are in VTKConfig.cmake. I searched > this file, and the only Python-related setting was VTK_WRAP_PYTHON. VTK > doesn't export VTK_PYTHON_VERSION for use by other projects. > >> > >> David > >> > >> > >> On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer > wrote: > >>> > >>> According to https://blog.kitware.com/vtk-7-0-0/ VTK_PYTHON_VERSION > should be set. I installed VTK 8.1.2 with pacman on Arch Linux. These are > the variables starting with VTK_: > https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 But > where is VTK_PYTHON_VERSION? Do you have an idea? > >> > >> > >> -- > >> Viele Gr??e > >> Ronald R?mer > > > > -- > > Viele Gr??e > > Ronald R?mer > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rroemer at gmail.com Thu Nov 29 10:02:07 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Thu, 29 Nov 2018 16:02:07 +0100 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> Message-ID: <1ff5969a-a0d3-7836-1687-a7cdafacfdd9@gmail.com> Thanks. On 29.11.18 16:00, Jean-Christophe Fillion-Robin wrote: > Hi Ronald, > > Running the following with the help of execute_process should help > answer your question: > > ./bin/vtkpython -c "import sys; print(sys.version_info[0:3])" > > You could also call it three times in a row, to get major, minor and > patch version. > > ./bin/vtkpython -c "import sys; print(sys.version_info[0])" > ./bin/vtkpython -c "import sys; print(sys.version_info[1])" > ./bin/vtkpython -c "import sys; print(sys.version_info[2])" > > On Thu, Nov 29, 2018 at 9:28 AM David Cole via vtk-developers > > wrote: > > Can you run vtkpython and try something that only works in python 2 > (or 3) and infer it...? > On Thu, Nov 29, 2018 at 4:06 AM Ronald R?mer > wrote: > > > > What else could I do to get the version? > > > > > > On 28.11.18 19:32, David Gobbi wrote: > > > > Would be a useful thing, though.? I'll see about submitting an MR. > > > > On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer > wrote: > >> > >> :( > >> > >> On 28.11.18 19:18, David Gobbi wrote: > >> > >> Hi Ronald, > >> > >> The exported configuration options are in VTKConfig.cmake.? I > searched this file, and the only Python-related setting was > VTK_WRAP_PYTHON.? VTK doesn't export VTK_PYTHON_VERSION for use by > other projects. > >> > >>? ?David > >> > >> > >> On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer > > wrote: > >>> > >>> According to https://blog.kitware.com/vtk-7-0-0/ > VTK_PYTHON_VERSION should be set. I installed VTK 8.1.2 with > pacman on Arch Linux. These are the variables starting with VTK_: > https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 > But where is VTK_PYTHON_VERSION? Do you have an idea? > >> > >> > >> -- > >> Viele Gr??e > >> Ronald R?mer > > > > -- > > Viele Gr??e > > Ronald R?mer > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > -- Viele Gr??e Ronald R?mer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcfr at kitware.com Thu Nov 29 10:05:28 2018 From: jcfr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 29 Nov 2018 10:05:28 -0500 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: <1ff5969a-a0d3-7836-1687-a7cdafacfdd9@gmail.com> References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> <1ff5969a-a0d3-7836-1687-a7cdafacfdd9@gmail.com> Message-ID: You could also inspire from logic found in this module: https://github.com/Kitware/CMake/blob/7bc72efb3ce30aae61a685c8f973888574728c8d/Modules/FindPython/Support.cmake#L91-L96 On Thu, Nov 29, 2018 at 10:02 AM Ronald R?mer wrote: > Thanks. > On 29.11.18 16:00, Jean-Christophe Fillion-Robin wrote: > > Hi Ronald, > > Running the following with the help of execute_process should help answer > your question: > > ./bin/vtkpython -c "import sys; print(sys.version_info[0:3])" > > You could also call it three times in a row, to get major, minor and patch > version. > > ./bin/vtkpython -c "import sys; print(sys.version_info[0])" > ./bin/vtkpython -c "import sys; print(sys.version_info[1])" > ./bin/vtkpython -c "import sys; print(sys.version_info[2])" > > On Thu, Nov 29, 2018 at 9:28 AM David Cole via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> Can you run vtkpython and try something that only works in python 2 >> (or 3) and infer it...? >> On Thu, Nov 29, 2018 at 4:06 AM Ronald R?mer wrote: >> > >> > What else could I do to get the version? >> > >> > >> > On 28.11.18 19:32, David Gobbi wrote: >> > >> > Would be a useful thing, though. I'll see about submitting an MR. >> > >> > On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer >> wrote: >> >> >> >> :( >> >> >> >> On 28.11.18 19:18, David Gobbi wrote: >> >> >> >> Hi Ronald, >> >> >> >> The exported configuration options are in VTKConfig.cmake. I searched >> this file, and the only Python-related setting was VTK_WRAP_PYTHON. VTK >> doesn't export VTK_PYTHON_VERSION for use by other projects. >> >> >> >> David >> >> >> >> >> >> On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer >> wrote: >> >>> >> >>> According to https://blog.kitware.com/vtk-7-0-0/ VTK_PYTHON_VERSION >> should be set. I installed VTK 8.1.2 with pacman on Arch Linux. These are >> the variables starting with VTK_: >> https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 But >> where is VTK_PYTHON_VERSION? Do you have an idea? >> >> >> >> >> >> -- >> >> Viele Gr??e >> >> Ronald R?mer >> > >> > -- >> > Viele Gr??e >> > Ronald R?mer >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > https://public.kitware.com/mailman/listinfo/vtk-developers >> > >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- > Viele Gr??e > Ronald R?mer > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rroemer at gmail.com Thu Nov 29 15:23:02 2018 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=c3=b6mer?=) Date: Thu, 29 Nov 2018 21:23:02 +0100 Subject: [vtk-developers] Identify the Python version of VTK In-Reply-To: References: <8ce42c60-bf3f-3704-6a40-4981a54a7418@gmail.com> <3d1c70a3-b97d-f370-ecbc-d43f52a204a3@gmail.com> <4356c532-ed57-9cca-5d6a-717e7836b767@gmail.com> <1ff5969a-a0d3-7836-1687-a7cdafacfdd9@gmail.com> Message-ID: What do you think about this wrapping https://gist.github.com/zippy84/ee6b4d04222ed62599f484cefdea2ecb ? It's a lot of code for such a simple thing, but it works. Feel free to change it. On 29.11.18 16:05, Jean-Christophe Fillion-Robin wrote: > You could also inspire from logic found in this module: > https://github.com/Kitware/CMake/blob/7bc72efb3ce30aae61a685c8f973888574728c8d/Modules/FindPython/Support.cmake#L91-L96 > > On Thu, Nov 29, 2018 at 10:02 AM Ronald R?mer > wrote: > > Thanks. > > On 29.11.18 16:00, Jean-Christophe Fillion-Robin wrote: >> Hi Ronald, >> >> Running the following with the help of execute_process should >> help answer your question: >> >> ./bin/vtkpython -c "import sys; print(sys.version_info[0:3])" >> >> You could also call it three times in a row, to get major, minor >> and patch version. >> >> ./bin/vtkpython -c "import sys; print(sys.version_info[0])" >> ./bin/vtkpython -c "import sys; print(sys.version_info[1])" >> ./bin/vtkpython -c "import sys; print(sys.version_info[2])" >> >> On Thu, Nov 29, 2018 at 9:28 AM David Cole via vtk-developers >> > > wrote: >> >> Can you run vtkpython and try something that only works in >> python 2 >> (or 3) and infer it...? >> On Thu, Nov 29, 2018 at 4:06 AM Ronald R?mer >> > wrote: >> > >> > What else could I do to get the version? >> > >> > >> > On 28.11.18 19:32, David Gobbi wrote: >> > >> > Would be a useful thing, though.? I'll see about submitting >> an MR. >> > >> > On Wed, Nov 28, 2018 at 11:28 AM Ronald R?mer >> > wrote: >> >> >> >> :( >> >> >> >> On 28.11.18 19:18, David Gobbi wrote: >> >> >> >> Hi Ronald, >> >> >> >> The exported configuration options are in >> VTKConfig.cmake.? I searched this file, and the only >> Python-related setting was VTK_WRAP_PYTHON.? VTK doesn't >> export VTK_PYTHON_VERSION for use by other projects. >> >> >> >>? ?David >> >> >> >> >> >> On Wed, Nov 28, 2018 at 10:55 AM Ronald R?mer >> > wrote: >> >>> >> >>> According to https://blog.kitware.com/vtk-7-0-0/ >> VTK_PYTHON_VERSION should be set. I installed VTK 8.1.2 with >> pacman on Arch Linux. These are the variables starting with >> VTK_: >> https://gist.github.com/zippy84/1d4560c721018ebd31ddc87fbfae8083 >> But where is VTK_PYTHON_VERSION? Do you have an idea? >> >> >> >> >> >> -- >> >> Viele Gr??e >> >> Ronald R?mer >> > >> > -- >> > Viele Gr??e >> > Ronald R?mer >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > https://public.kitware.com/mailman/listinfo/vtk-developers >> > >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> > -- > Viele Gr??e > Ronald R?mer > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sal.choueib at queensu.ca Thu Nov 29 21:11:11 2018 From: sal.choueib at queensu.ca (Sal Choueib) Date: Fri, 30 Nov 2018 02:11:11 +0000 Subject: [vtk-developers] vtk-glTF Message-ID: Hello All, We are currently in the process of developing an exporter to glTF 2.0. Does anyone have experience working with gltf? Or perhaps knows of any resources that might be useful? Furthermore, we are utilizing tiny-gltf, a header only glTF library, to serialize data and write the gltf file (https://github.com/syoyo/tinygltf). We are hoping someone could comment on our choice of library. Is this library good? Any potential risks or cons to using this library? Does anyone have suggestions for a better library to use? Thank you for your help, Sal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Nov 29 22:31:55 2018 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 29 Nov 2018 22:31:55 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: FWIW I'm working on a simple very basic starting point for gltf ala https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a if you want to work off that. I'll probably try merging it soon . - Ken On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib wrote: > Hello All, > > > > We are currently in the process of developing an exporter to glTF 2.0. > Does anyone have experience working with gltf? Or perhaps knows of any > resources that might be useful? > > > Furthermore, we are utilizing tiny-gltf, a header only glTF library, > to serialize data and write the gltf file ( > https://github.com/syoyo/tinygltf > ). > We are hoping someone could comment on our choice of library. Is this > library good? Any potential risks or cons to using this library? Does > anyone have suggestions for a better library to use? > > > > > > > Thank you for your help, > > Sal > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Fri Nov 30 07:57:13 2018 From: pieper at isomics.com (Steve Pieper) Date: Fri, 30 Nov 2018 07:57:13 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: Hi - I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 version in python a while back if you want to look at that for reference [1]. On request: please include a WriteToMemory option like in the vtkImageWriter classes so it can be used easily without the file system (e.g. like in the web server mode I was doing). Good luck, Steve [1] https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < vtk-developers at public.kitware.com> wrote: > FWIW I'm working on a simple very basic starting point for gltf ala > > > https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a > > if you want to work off that. I'll probably try merging it soon . > > - Ken > > > On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib > wrote: > >> Hello All, >> >> >> >> We are currently in the process of developing an exporter to glTF 2.0. >> Does anyone have experience working with gltf? Or perhaps knows of any >> resources that might be useful? >> >> >> Furthermore, we are utilizing tiny-gltf, a header only glTF library, >> to serialize data and write the gltf file ( >> https://github.com/syoyo/tinygltf >> ). >> We are hoping someone could comment on our choice of library. Is this >> library good? Any potential risks or cons to using this library? Does >> anyone have suggestions for a better library to use? >> >> >> >> >> >> >> Thank you for your help, >> >> Sal >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > Carrboro, North Carolina > 27510 USA > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Nov 30 09:58:28 2018 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 30 Nov 2018 09:58:28 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: Having a glTF reader/writer would be great to have in VTK specifically for us as geospatial community is producing more data in this format. - Aashish On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper wrote: > Hi - > > I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 > version in python a while back if you want to look at that for reference > [1]. > > On request: please include a WriteToMemory option like in the > vtkImageWriter classes so it can be used easily without the file system > (e.g. like in the web server mode I was doing). > > Good luck, > Steve > > [1] > https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 > > On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> FWIW I'm working on a simple very basic starting point for gltf ala >> >> >> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >> >> if you want to work off that. I'll probably try merging it soon . >> >> - Ken >> >> >> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >> wrote: >> >>> Hello All, >>> >>> >>> >>> We are currently in the process of developing an exporter to glTF >>> 2.0. Does anyone have experience working with gltf? Or perhaps knows of any >>> resources that might be useful? >>> >>> >>> Furthermore, we are utilizing tiny-gltf, a header only glTF library, >>> to serialize data and write the gltf file ( >>> https://github.com/syoyo/tinygltf >>> ). >>> We are hoping someone could comment on our choice of library. Is this >>> library good? Any potential risks or cons to using this library? Does >>> anyone have suggestions for a better library to use? >>> >>> >>> >>> >>> >>> >>> Thank you for your help, >>> >>> Sal >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 101 East Weaver Street >> Carrboro, North Carolina >> 27510 USA >> >> This communication, including all attachments, contains confidential and >> legally privileged information, and it is intended only for the use of the >> addressee. Access to this email by anyone else is unauthorized. If you are >> not the intended recipient, any disclosure, copying, distribution or any >> action taken in reliance on it is prohibited and may be unlawful. If you >> received this communication in error please notify us immediately and >> destroy the original message. Thank you. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Nov 30 10:29:30 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 30 Nov 2018 16:29:30 +0100 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: HI Aashish, list, We are currently working on a gltf reader ! But only for next year. Let us know if you want to be kept in the loop. Best, Mathieu Westphal On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < vtk-developers at public.kitware.com> wrote: > Having a glTF reader/writer would be great to have in VTK specifically for > us as geospatial community is producing more data in this format. > > - Aashish > > On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper wrote: > >> Hi - >> >> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 >> version in python a while back if you want to look at that for reference >> [1]. >> >> On request: please include a WriteToMemory option like in the >> vtkImageWriter classes so it can be used easily without the file system >> (e.g. like in the web server mode I was doing). >> >> Good luck, >> Steve >> >> [1] >> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >> >> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >> vtk-developers at public.kitware.com> wrote: >> >>> FWIW I'm working on a simple very basic starting point for gltf ala >>> >>> >>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>> >>> if you want to work off that. I'll probably try merging it soon . >>> >>> - Ken >>> >>> >>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>> wrote: >>> >>>> Hello All, >>>> >>>> >>>> >>>> We are currently in the process of developing an exporter to glTF >>>> 2.0. Does anyone have experience working with gltf? Or perhaps knows of any >>>> resources that might be useful? >>>> >>>> >>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>> library, to serialize data and write the gltf file ( >>>> https://github.com/syoyo/tinygltf >>>> ). >>>> We are hoping someone could comment on our choice of library. Is this >>>> library good? Any potential risks or cons to using this library? Does >>>> anyone have suggestions for a better library to use? >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thank you for your help, >>>> >>>> Sal >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 101 East Weaver Street >>> Carrboro, North Carolina >>> 27510 USA >>> >>> This communication, including all attachments, contains confidential and >>> legally privileged information, and it is intended only for the use of the >>> addressee. Access to this email by anyone else is unauthorized. If you are >>> not the intended recipient, any disclosure, copying, distribution or any >>> action taken in reliance on it is prohibited and may be unlawful. If you >>> received this communication in error please notify us immediately and >>> destroy the original message. Thank you. >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Nov 30 10:04:28 2018 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 30 Nov 2018 10:04:28 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: Yes please do. You could post the updates on the mailing list (dev). Thanks On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > HI Aashish, list, > > We are currently working on a gltf reader ! But only for next year. > Let us know if you want to be kept in the loop. > > Best, > > Mathieu Westphal > > > On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> Having a glTF reader/writer would be great to have in VTK specifically >> for us as geospatial community is producing more data in this format. >> >> - Aashish >> >> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper wrote: >> >>> Hi - >>> >>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 >>> version in python a while back if you want to look at that for reference >>> [1]. >>> >>> On request: please include a WriteToMemory option like in the >>> vtkImageWriter classes so it can be used easily without the file system >>> (e.g. like in the web server mode I was doing). >>> >>> Good luck, >>> Steve >>> >>> [1] >>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>> >>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>> vtk-developers at public.kitware.com> wrote: >>> >>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>> >>>> >>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>> >>>> if you want to work off that. I'll probably try merging it soon . >>>> >>>> - Ken >>>> >>>> >>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>>> wrote: >>>> >>>>> Hello All, >>>>> >>>>> >>>>> >>>>> We are currently in the process of developing an exporter to glTF >>>>> 2.0. Does anyone have experience working with gltf? Or perhaps knows of any >>>>> resources that might be useful? >>>>> >>>>> >>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>> library, to serialize data and write the gltf file ( >>>>> https://github.com/syoyo/tinygltf >>>>> ). >>>>> We are hoping someone could comment on our choice of library. Is this >>>>> library good? Any potential risks or cons to using this library? Does >>>>> anyone have suggestions for a better library to use? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thank you for your help, >>>>> >>>>> Sal >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Distinguished Engineer >>>> Kitware Inc. >>>> 101 East Weaver Street >>>> >>>> Carrboro, North Carolina >>>> >>>> 27510 USA >>>> >>>> >>>> This communication, including all attachments, contains confidential >>>> and legally privileged information, and it is intended only for the use of >>>> the addressee. Access to this email by anyone else is unauthorized. If you >>>> are not the intended recipient, any disclosure, copying, distribution or >>>> any action taken in reliance on it is prohibited and may be unlawful. If >>>> you received this communication in error please notify us immediately and >>>> destroy the original message. Thank you. >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.girault at kitware.com Fri Nov 30 10:09:25 2018 From: alexis.girault at kitware.com (Alexis Girault) Date: Fri, 30 Nov 2018 10:09:25 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: For a list of existing IO toolkits, see "Converters, Importers, and Exporters" on Khronos page for gltf here: https://www.khronos.org/gltf/ In iMSTK, we have been using ASSIMP (mentioned in the list above) for some other formats. I believe people inquired about integrating ASSIMP in VTK in the past. Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers < vtk-developers at public.kitware.com> wrote: > Yes please do. You could post the updates on the mailing list (dev). > > Thanks > > On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> HI Aashish, list, >> >> We are currently working on a gltf reader ! But only for next year. >> Let us know if you want to be kept in the loop. >> >> Best, >> >> Mathieu Westphal >> >> >> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < >> vtk-developers at public.kitware.com> wrote: >> >>> Having a glTF reader/writer would be great to have in VTK specifically >>> for us as geospatial community is producing more data in this format. >>> >>> - Aashish >>> >>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper wrote: >>> >>>> Hi - >>>> >>>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 >>>> version in python a while back if you want to look at that for reference >>>> [1]. >>>> >>>> On request: please include a WriteToMemory option like in the >>>> vtkImageWriter classes so it can be used easily without the file system >>>> (e.g. like in the web server mode I was doing). >>>> >>>> Good luck, >>>> Steve >>>> >>>> [1] >>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>>> >>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>>> vtk-developers at public.kitware.com> wrote: >>>> >>>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>>> >>>>> >>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>>> >>>>> if you want to work off that. I'll probably try merging it soon . >>>>> >>>>> - Ken >>>>> >>>>> >>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>>>> wrote: >>>>> >>>>>> Hello All, >>>>>> >>>>>> >>>>>> >>>>>> We are currently in the process of developing an exporter to glTF >>>>>> 2.0. Does anyone have experience working with gltf? Or perhaps knows of any >>>>>> resources that might be useful? >>>>>> >>>>>> >>>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>>> library, to serialize data and write the gltf file ( >>>>>> https://github.com/syoyo/tinygltf >>>>>> ). >>>>>> We are hoping someone could comment on our choice of library. Is this >>>>>> library good? Any potential risks or cons to using this library? Does >>>>>> anyone have suggestions for a better library to use? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thank you for your help, >>>>>> >>>>>> Sal >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ken Martin PhD >>>>> Distinguished Engineer >>>>> Kitware Inc. >>>>> 101 East Weaver Street >>>>> >>>>> Carrboro, North Carolina >>>>> >>>>> 27510 USA >>>>> >>>>> >>>>> This communication, including all attachments, contains confidential >>>>> and legally privileged information, and it is intended only for the use of >>>>> the addressee. Access to this email by anyone else is unauthorized. If you >>>>> are not the intended recipient, any disclosure, copying, distribution or >>>>> any action taken in reliance on it is prohibited and may be unlawful. If >>>>> you received this communication in error please notify us immediately and >>>>> destroy the original message. Thank you. >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Nov 30 10:23:08 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 30 Nov 2018 10:23:08 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: Has anyone looked into putting assimp into VTK? On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault via vtk-developers < vtk-developers at public.kitware.com> wrote: > For a list of existing IO toolkits, see "Converters, Importers, and > Exporters" on Khronos page for gltf here: https://www.khronos.org/gltf/ > > In iMSTK, we have been using ASSIMP (mentioned > in the list above) for some other formats. I believe people inquired about > integrating ASSIMP in VTK in the past. > > Alexis Girault > R&D Engineer in Medical Computing > Kitware, Inc. > > http://www.kitware.com > (919) 969-6990 x325 > > > On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> Yes please do. You could post the updates on the mailing list (dev). >> >> Thanks >> >> On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> HI Aashish, list, >>> >>> We are currently working on a gltf reader ! But only for next year. >>> Let us know if you want to be kept in the loop. >>> >>> Best, >>> >>> Mathieu Westphal >>> >>> >>> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < >>> vtk-developers at public.kitware.com> wrote: >>> >>>> Having a glTF reader/writer would be great to have in VTK specifically >>>> for us as geospatial community is producing more data in this format. >>>> >>>> - Aashish >>>> >>>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper >>>> wrote: >>>> >>>>> Hi - >>>>> >>>>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 >>>>> version in python a while back if you want to look at that for reference >>>>> [1]. >>>>> >>>>> On request: please include a WriteToMemory option like in the >>>>> vtkImageWriter classes so it can be used easily without the file system >>>>> (e.g. like in the web server mode I was doing). >>>>> >>>>> Good luck, >>>>> Steve >>>>> >>>>> [1] >>>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>>>> >>>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>>>> vtk-developers at public.kitware.com> wrote: >>>>> >>>>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>>>> >>>>>> >>>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>>>> >>>>>> if you want to work off that. I'll probably try merging it soon . >>>>>> >>>>>> - Ken >>>>>> >>>>>> >>>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>>>>> wrote: >>>>>> >>>>>>> Hello All, >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are currently in the process of developing an exporter to glTF >>>>>>> 2.0. Does anyone have experience working with gltf? Or perhaps knows of any >>>>>>> resources that might be useful? >>>>>>> >>>>>>> >>>>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>>>> library, to serialize data and write the gltf file ( >>>>>>> https://github.com/syoyo/tinygltf >>>>>>> ). >>>>>>> We are hoping someone could comment on our choice of library. Is this >>>>>>> library good? Any potential risks or cons to using this library? Does >>>>>>> anyone have suggestions for a better library to use? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you for your help, >>>>>>> >>>>>>> Sal >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Ken Martin PhD >>>>>> Distinguished Engineer >>>>>> Kitware Inc. >>>>>> 101 East Weaver Street >>>>>> >>>>>> Carrboro, North Carolina >>>>>> >>>>>> 27510 USA >>>>>> >>>>>> >>>>>> This communication, including all attachments, contains confidential >>>>>> and legally privileged information, and it is intended only for the use of >>>>>> the addressee. Access to this email by anyone else is unauthorized. If you >>>>>> are not the intended recipient, any disclosure, copying, distribution or >>>>>> any action taken in reliance on it is prohibited and may be unlawful. If >>>>>> you received this communication in error please notify us immediately and >>>>>> destroy the original message. Thank you. >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Fri Nov 30 10:45:55 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 30 Nov 2018 10:45:55 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: Are there any plans for a glTF reader in vtk.js? With a writer in VTK, this may be an efficient path for VTK/ITK output in WebAssembly rendered in vtk.js. - Matt On Fri, Nov 30, 2018 at 10:23 AM Ken Martin via vtk-developers < vtk-developers at public.kitware.com> wrote: > Has anyone looked into putting assimp into VTK? > > On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> For a list of existing IO toolkits, see "Converters, Importers, and >> Exporters" on Khronos page for gltf here: https://www.khronos.org/gltf/ >> >> In iMSTK, we have been using ASSIMP (mentioned >> in the list above) for some other formats. I believe people inquired about >> integrating ASSIMP in VTK in the past. >> >> Alexis Girault >> R&D Engineer in Medical Computing >> Kitware, Inc. >> >> http://www.kitware.com >> (919) 969-6990 x325 >> >> >> On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers < >> vtk-developers at public.kitware.com> wrote: >> >>> Yes please do. You could post the updates on the mailing list (dev). >>> >>> Thanks >>> >>> On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < >>> mathieu.westphal at kitware.com> wrote: >>> >>>> HI Aashish, list, >>>> >>>> We are currently working on a gltf reader ! But only for next year. >>>> Let us know if you want to be kept in the loop. >>>> >>>> Best, >>>> >>>> Mathieu Westphal >>>> >>>> >>>> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < >>>> vtk-developers at public.kitware.com> wrote: >>>> >>>>> Having a glTF reader/writer would be great to have in VTK specifically >>>>> for us as geospatial community is producing more data in this format. >>>>> >>>>> - Aashish >>>>> >>>>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper >>>>> wrote: >>>>> >>>>>> Hi - >>>>>> >>>>>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF >>>>>> 1.0 version in python a while back if you want to look at that for >>>>>> reference [1]. >>>>>> >>>>>> On request: please include a WriteToMemory option like in the >>>>>> vtkImageWriter classes so it can be used easily without the file system >>>>>> (e.g. like in the web server mode I was doing). >>>>>> >>>>>> Good luck, >>>>>> Steve >>>>>> >>>>>> [1] >>>>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>>>>> >>>>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>>>>> vtk-developers at public.kitware.com> wrote: >>>>>> >>>>>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>>>>> >>>>>>> >>>>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>>>>> >>>>>>> if you want to work off that. I'll probably try merging it soon . >>>>>>> >>>>>>> - Ken >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>>>>>> wrote: >>>>>>> >>>>>>>> Hello All, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We are currently in the process of developing an exporter to >>>>>>>> glTF 2.0. Does anyone have experience working with gltf? Or perhaps knows >>>>>>>> of any resources that might be useful? >>>>>>>> >>>>>>>> >>>>>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>>>>> library, to serialize data and write the gltf file ( >>>>>>>> https://github.com/syoyo/tinygltf >>>>>>>> ). >>>>>>>> We are hoping someone could comment on our choice of library. Is this >>>>>>>> library good? Any potential risks or cons to using this library? Does >>>>>>>> anyone have suggestions for a better library to use? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thank you for your help, >>>>>>>> >>>>>>>> Sal >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Search the list archives at: >>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ken Martin PhD >>>>>>> Distinguished Engineer >>>>>>> Kitware Inc. >>>>>>> 101 East Weaver Street >>>>>>> >>>>>>> Carrboro, North Carolina >>>>>>> >>>>>>> 27510 USA >>>>>>> >>>>>>> >>>>>>> This communication, including all attachments, contains confidential >>>>>>> and legally privileged information, and it is intended only for the use of >>>>>>> the addressee. Access to this email by anyone else is unauthorized. If you >>>>>>> are not the intended recipient, any disclosure, copying, distribution or >>>>>>> any action taken in reliance on it is prohibited and may be unlawful. If >>>>>>> you received this communication in error please notify us immediately and >>>>>>> destroy the original message. Thank you. >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > Carrboro, North Carolina > 27510 USA > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Nov 30 10:48:40 2018 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 30 Nov 2018 10:48:40 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: assimp is looking great, although they have partial support for glTF. How did you use ASSIMP in iMSTK without using VTK? - Aashish On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault wrote: > For a list of existing IO toolkits, see "Converters, Importers, and > Exporters" on Khronos page for gltf here: https://www.khronos.org/gltf/ > > In iMSTK, we have been using ASSIMP (mentioned > in the list above) for some other formats. I believe people inquired about > integrating ASSIMP in VTK in the past. > > Alexis Girault > R&D Engineer in Medical Computing > Kitware, Inc. > > http://www.kitware.com > (919) 969-6990 x325 > > > On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> Yes please do. You could post the updates on the mailing list (dev). >> >> Thanks >> >> On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> HI Aashish, list, >>> >>> We are currently working on a gltf reader ! But only for next year. >>> Let us know if you want to be kept in the loop. >>> >>> Best, >>> >>> Mathieu Westphal >>> >>> >>> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < >>> vtk-developers at public.kitware.com> wrote: >>> >>>> Having a glTF reader/writer would be great to have in VTK specifically >>>> for us as geospatial community is producing more data in this format. >>>> >>>> - Aashish >>>> >>>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper >>>> wrote: >>>> >>>>> Hi - >>>>> >>>>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 >>>>> version in python a while back if you want to look at that for reference >>>>> [1]. >>>>> >>>>> On request: please include a WriteToMemory option like in the >>>>> vtkImageWriter classes so it can be used easily without the file system >>>>> (e.g. like in the web server mode I was doing). >>>>> >>>>> Good luck, >>>>> Steve >>>>> >>>>> [1] >>>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>>>> >>>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>>>> vtk-developers at public.kitware.com> wrote: >>>>> >>>>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>>>> >>>>>> >>>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>>>> >>>>>> if you want to work off that. I'll probably try merging it soon . >>>>>> >>>>>> - Ken >>>>>> >>>>>> >>>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>>>>> wrote: >>>>>> >>>>>>> Hello All, >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are currently in the process of developing an exporter to glTF >>>>>>> 2.0. Does anyone have experience working with gltf? Or perhaps knows of any >>>>>>> resources that might be useful? >>>>>>> >>>>>>> >>>>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>>>> library, to serialize data and write the gltf file ( >>>>>>> https://github.com/syoyo/tinygltf >>>>>>> ). >>>>>>> We are hoping someone could comment on our choice of library. Is this >>>>>>> library good? Any potential risks or cons to using this library? Does >>>>>>> anyone have suggestions for a better library to use? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you for your help, >>>>>>> >>>>>>> Sal >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Ken Martin PhD >>>>>> Distinguished Engineer >>>>>> Kitware Inc. >>>>>> 101 East Weaver Street >>>>>> >>>>>> Carrboro, North Carolina >>>>>> >>>>>> 27510 USA >>>>>> >>>>>> >>>>>> This communication, including all attachments, contains confidential >>>>>> and legally privileged information, and it is intended only for the use of >>>>>> the addressee. Access to this email by anyone else is unauthorized. If you >>>>>> are not the intended recipient, any disclosure, copying, distribution or >>>>>> any action taken in reliance on it is prohibited and may be unlawful. If >>>>>> you received this communication in error please notify us immediately and >>>>>> destroy the original message. Thank you. >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Fri Nov 30 10:49:28 2018 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Fri, 30 Nov 2018 08:49:28 -0700 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: I would love that, but I'm not aware of any. On Fri, Nov 30, 2018 at 8:46 AM Matt McCormick wrote: > Are there any plans for a glTF reader in vtk.js? With a writer in VTK, > this may be an efficient path for VTK/ITK output in WebAssembly rendered in > vtk.js. > > - Matt > > On Fri, Nov 30, 2018 at 10:23 AM Ken Martin via vtk-developers < > vtk-developers at public.kitware.com> wrote: > >> Has anyone looked into putting assimp into VTK? >> >> On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault via vtk-developers < >> vtk-developers at public.kitware.com> wrote: >> >>> For a list of existing IO toolkits, see "Converters, Importers, and >>> Exporters" on Khronos page for gltf here: https://www.khronos.org/gltf/ >>> >>> In iMSTK, we have been using ASSIMP (mentioned >>> in the list above) for some other formats. I believe people inquired about >>> integrating ASSIMP in VTK in the past. >>> >>> Alexis Girault >>> R&D Engineer in Medical Computing >>> Kitware, Inc. >>> >>> http://www.kitware.com >>> (919) 969-6990 x325 >>> >>> >>> On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers < >>> vtk-developers at public.kitware.com> wrote: >>> >>>> Yes please do. You could post the updates on the mailing list (dev). >>>> >>>> Thanks >>>> >>>> On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < >>>> mathieu.westphal at kitware.com> wrote: >>>> >>>>> HI Aashish, list, >>>>> >>>>> We are currently working on a gltf reader ! But only for next year. >>>>> Let us know if you want to be kept in the loop. >>>>> >>>>> Best, >>>>> >>>>> Mathieu Westphal >>>>> >>>>> >>>>> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < >>>>> vtk-developers at public.kitware.com> wrote: >>>>> >>>>>> Having a glTF reader/writer would be great to have in VTK >>>>>> specifically for us as geospatial community is producing more data in this >>>>>> format. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper >>>>>> wrote: >>>>>> >>>>>>> Hi - >>>>>>> >>>>>>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF >>>>>>> 1.0 version in python a while back if you want to look at that for >>>>>>> reference [1]. >>>>>>> >>>>>>> On request: please include a WriteToMemory option like in the >>>>>>> vtkImageWriter classes so it can be used easily without the file system >>>>>>> (e.g. like in the web server mode I was doing). >>>>>>> >>>>>>> Good luck, >>>>>>> Steve >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>>>>>> >>>>>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>>>>>> vtk-developers at public.kitware.com> wrote: >>>>>>> >>>>>>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>>>>>> >>>>>>>> >>>>>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>>>>>> >>>>>>>> if you want to work off that. I'll probably try merging it soon . >>>>>>>> >>>>>>>> - Ken >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> We are currently in the process of developing an exporter to >>>>>>>>> glTF 2.0. Does anyone have experience working with gltf? Or perhaps knows >>>>>>>>> of any resources that might be useful? >>>>>>>>> >>>>>>>>> >>>>>>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>>>>>> library, to serialize data and write the gltf file ( >>>>>>>>> https://github.com/syoyo/tinygltf >>>>>>>>> ). >>>>>>>>> We are hoping someone could comment on our choice of library. Is this >>>>>>>>> library good? Any potential risks or cons to using this library? Does >>>>>>>>> anyone have suggestions for a better library to use? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for your help, >>>>>>>>> >>>>>>>>> Sal >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Search the list archives at: >>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ken Martin PhD >>>>>>>> Distinguished Engineer >>>>>>>> Kitware Inc. >>>>>>>> 101 East Weaver Street >>>>>>>> >>>>>>>> Carrboro, North Carolina >>>>>>>> >>>>>>>> 27510 USA >>>>>>>> >>>>>>>> >>>>>>>> This communication, including all attachments, contains >>>>>>>> confidential and legally privileged information, and it is intended only >>>>>>>> for the use of the addressee. Access to this email by anyone else is >>>>>>>> unauthorized. If you are not the intended recipient, any disclosure, >>>>>>>> copying, distribution or any action taken in reliance on it is prohibited >>>>>>>> and may be unlawful. If you received this communication in error please >>>>>>>> notify us immediately and destroy the original message. Thank you. >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Search the list archives at: >>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 101 East Weaver Street >> Carrboro, North Carolina >> 27510 USA >> >> This communication, including all attachments, contains confidential and >> legally privileged information, and it is intended only for the use of the >> addressee. Access to this email by anyone else is unauthorized. If you are >> not the intended recipient, any disclosure, copying, distribution or any >> action taken in reliance on it is prohibited and may be unlawful. If you >> received this communication in error please notify us immediately and >> destroy the original message. Thank you. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.girault at kitware.com Fri Nov 30 12:37:21 2018 From: alexis.girault at kitware.com (Alexis Girault) Date: Fri, 30 Nov 2018 12:37:21 -0500 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: Message-ID: Nicholas Milef from RPI was the one who inquired about ASSIMP in VTK: http://vtk.1045678.n5.nabble.com/Assimp-integration-td5741474.html CCing in case he wants to follow up on it Nick also integrated ASSIMP in iMSTK. To answer your question Aashish: - iMSTK has its own data structure for geometries that uses Eigen: https://gitlab.kitware.com/iMSTK/iMSTK/tree/master/Source/Geometry/Mesh - The ASSIMP importer converts (copies) the data from ASSIMP to those internal Eigen structures: https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Source/Geometry/Reader/imstkAssimpMeshIO.cpp - The geometry vertices are mapped to a VTK data array with no copy: https://gitlab.kitware.com/iMSTK/iMSTK/blob/85c154f1/Source/Rendering/VTKRenderer/RenderDelegate/imstkVTKSurfaceMeshRenderDelegate.cpp#L48-52 Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Fri, Nov 30, 2018 at 10:50 AM Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > I would love that, but I'm not aware of any. > > On Fri, Nov 30, 2018 at 8:46 AM Matt McCormick > wrote: > >> Are there any plans for a glTF reader in vtk.js? With a writer in VTK, >> this may be an efficient path for VTK/ITK output in WebAssembly rendered in >> vtk.js. >> >> - Matt >> >> On Fri, Nov 30, 2018 at 10:23 AM Ken Martin via vtk-developers < >> vtk-developers at public.kitware.com> wrote: >> >>> Has anyone looked into putting assimp into VTK? >>> >>> On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault via vtk-developers < >>> vtk-developers at public.kitware.com> wrote: >>> >>>> For a list of existing IO toolkits, see "Converters, Importers, and >>>> Exporters" on Khronos page for gltf here: >>>> https://www.khronos.org/gltf/ >>>> >>>> In iMSTK, we have been using ASSIMP (mentioned >>>> in the list above) for some other formats. I believe people inquired about >>>> integrating ASSIMP in VTK in the past. >>>> >>>> Alexis Girault >>>> R&D Engineer in Medical Computing >>>> Kitware, Inc. >>>> >>>> http://www.kitware.com >>>> (919) 969-6990 x325 >>>> >>>> >>>> On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers < >>>> vtk-developers at public.kitware.com> wrote: >>>> >>>>> Yes please do. You could post the updates on the mailing list (dev). >>>>> >>>>> Thanks >>>>> >>>>> On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal < >>>>> mathieu.westphal at kitware.com> wrote: >>>>> >>>>>> HI Aashish, list, >>>>>> >>>>>> We are currently working on a gltf reader ! But only for next year. >>>>>> Let us know if you want to be kept in the loop. >>>>>> >>>>>> Best, >>>>>> >>>>>> Mathieu Westphal >>>>>> >>>>>> >>>>>> On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers < >>>>>> vtk-developers at public.kitware.com> wrote: >>>>>> >>>>>>> Having a glTF reader/writer would be great to have in VTK >>>>>>> specifically for us as geospatial community is producing more data in this >>>>>>> format. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper >>>>>>> wrote: >>>>>>> >>>>>>>> Hi - >>>>>>>> >>>>>>>> I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF >>>>>>>> 1.0 version in python a while back if you want to look at that for >>>>>>>> reference [1]. >>>>>>>> >>>>>>>> On request: please include a WriteToMemory option like in the >>>>>>>> vtkImageWriter classes so it can be used easily without the file system >>>>>>>> (e.g. like in the web server mode I was doing). >>>>>>>> >>>>>>>> Good luck, >>>>>>>> Steve >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 >>>>>>>> >>>>>>>> On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers < >>>>>>>> vtk-developers at public.kitware.com> wrote: >>>>>>>> >>>>>>>>> FWIW I'm working on a simple very basic starting point for gltf ala >>>>>>>>> >>>>>>>>> >>>>>>>>> https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a >>>>>>>>> >>>>>>>>> if you want to work off that. I'll probably try merging it soon . >>>>>>>>> >>>>>>>>> - Ken >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib < >>>>>>>>> sal.choueib at queensu.ca> wrote: >>>>>>>>> >>>>>>>>>> Hello All, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We are currently in the process of developing an exporter to >>>>>>>>>> glTF 2.0. Does anyone have experience working with gltf? Or perhaps knows >>>>>>>>>> of any resources that might be useful? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Furthermore, we are utilizing tiny-gltf, a header only glTF >>>>>>>>>> library, to serialize data and write the gltf file ( >>>>>>>>>> https://github.com/syoyo/tinygltf >>>>>>>>>> ). >>>>>>>>>> We are hoping someone could comment on our choice of library. Is this >>>>>>>>>> library good? Any potential risks or cons to using this library? Does >>>>>>>>>> anyone have suggestions for a better library to use? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you for your help, >>>>>>>>>> >>>>>>>>>> Sal >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Powered by www.kitware.com >>>>>>>>>> >>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>> >>>>>>>>>> Search the list archives at: >>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>> >>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ken Martin PhD >>>>>>>>> Distinguished Engineer >>>>>>>>> Kitware Inc. >>>>>>>>> 101 East Weaver Street >>>>>>>>> >>>>>>>>> Carrboro, North Carolina >>>>>>>>> >>>>>>>>> 27510 USA >>>>>>>>> >>>>>>>>> >>>>>>>>> This communication, including all attachments, contains >>>>>>>>> confidential and legally privileged information, and it is intended only >>>>>>>>> for the use of the addressee. Access to this email by anyone else is >>>>>>>>> unauthorized. If you are not the intended recipient, any disclosure, >>>>>>>>> copying, distribution or any action taken in reliance on it is prohibited >>>>>>>>> and may be unlawful. If you received this communication in error please >>>>>>>>> notify us immediately and destroy the original message. Thank you. >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Search the list archives at: >>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Search the list archives at: >>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the list archives at: >>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: >>>> http://markmail.org/search/?q=vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 101 East Weaver Street >>> Carrboro, North Carolina >>> 27510 USA >>> >>> This communication, including all attachments, contains confidential and >>> legally privileged information, and it is intended only for the use of the >>> addressee. Access to this email by anyone else is unauthorized. If you are >>> not the intended recipient, any disclosure, copying, distribution or any >>> action taken in reliance on it is prohibited and may be unlawful. If you >>> received this communication in error please notify us immediately and >>> destroy the original message. Thank you. >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: >>> http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Fri Nov 30 13:20:53 2018 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Fri, 30 Nov 2018 18:20:53 +0000 Subject: [vtk-developers] vtk-glTF In-Reply-To: References: , Message-ID: I also integrated Assimp with a fork of VTK before as well, but it was for something very specific because we needed bone weights/indices. However, from what I understand, Assimp seems to internally process the mesh data, so you may get slightly different results than the vtkOBJReader (for instance) because of vertex reordering. ________________________________ From: Alexis Girault [alexis.girault at kitware.com] Sent: Friday, November 30, 2018 12:37 PM To: Milef, Nicholas Boris; Aashish Chaudhary; Mathieu Westphal Cc: Ken Martin; Steve Pieper; vtk-developers at public.kitware.com Subject: Re: [vtk-developers] vtk-glTF Nicholas Milef from RPI was the one who inquired about ASSIMP in VTK: http://vtk.1045678.n5.nabble.com/Assimp-integration-td5741474.html CCing in case he wants to follow up on it Nick also integrated ASSIMP in iMSTK. To answer your question Aashish: - iMSTK has its own data structure for geometries that uses Eigen: https://gitlab.kitware.com/iMSTK/iMSTK/tree/master/Source/Geometry/Mesh - The ASSIMP importer converts (copies) the data from ASSIMP to those internal Eigen structures: https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Source/Geometry/Reader/imstkAssimpMeshIO.cpp - The geometry vertices are mapped to a VTK data array with no copy: https://gitlab.kitware.com/iMSTK/iMSTK/blob/85c154f1/Source/Rendering/VTKRenderer/RenderDelegate/imstkVTKSurfaceMeshRenderDelegate.cpp#L48-52 Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Fri, Nov 30, 2018 at 10:50 AM Sebastien Jourdain > wrote: I would love that, but I'm not aware of any. On Fri, Nov 30, 2018 at 8:46 AM Matt McCormick > wrote: Are there any plans for a glTF reader in vtk.js? With a writer in VTK, this may be an efficient path for VTK/ITK output in WebAssembly rendered in vtk.js. - Matt On Fri, Nov 30, 2018 at 10:23 AM Ken Martin via vtk-developers > wrote: Has anyone looked into putting assimp into VTK? On Fri, Nov 30, 2018 at 10:09 AM Alexis Girault via vtk-developers > wrote: For a list of existing IO toolkits, see "Converters, Importers, and Exporters" on Khronos page for gltf here: https://www.khronos.org/gltf/ In iMSTK, we have been using ASSIMP (mentioned in the list above) for some other formats. I believe people inquired about integrating ASSIMP in VTK in the past. Alexis Girault R&D Engineer in Medical Computing Kitware, Inc. http://www.kitware.com (919) 969-6990 x325 On Fri, Nov 30, 2018 at 10:04 AM Aashish Chaudhary via vtk-developers > wrote: Yes please do. You could post the updates on the mailing list (dev). Thanks On Fri, Nov 30, 2018 at 10:01 AM Mathieu Westphal > wrote: HI Aashish, list, We are currently working on a gltf reader ! But only for next year. Let us know if you want to be kept in the loop. Best, Mathieu Westphal On Fri, Nov 30, 2018 at 3:58 PM Aashish Chaudhary via vtk-developers > wrote: Having a glTF reader/writer would be great to have in VTK specifically for us as geospatial community is producing more data in this format. - Aashish On Fri, Nov 30, 2018 at 7:57 AM Steve Pieper > wrote: Hi - I'd love to see a glTF 2.0 exporter native in VTK. I wrote a glTF 1.0 version in python a while back if you want to look at that for reference [1]. On request: please include a WriteToMemory option like in the vtkImageWriter classes so it can be used easily without the file system (e.g. like in the web server mode I was doing). Good luck, Steve [1] https://github.com/pieper/SlicerWeb/blob/master/WebServer/WebServer.py#L37-L457 On Thu, Nov 29, 2018 at 10:32 PM Ken Martin via vtk-developers > wrote: FWIW I'm working on a simple very basic starting point for gltf ala https://gitlab.kitware.com/ken-martin/vtk/commit/656f7e231e9434431e234f701c7101006e2be40a if you want to work off that. I'll probably try merging it soon . - Ken On Thu, Nov 29, 2018 at 9:11 PM Sal Choueib > wrote: Hello All, We are currently in the process of developing an exporter to glTF 2.0. Does anyone have experience working with gltf? Or perhaps knows of any resources that might be useful? Furthermore, we are utilizing tiny-gltf, a header only glTF library, to serialize data and write the gltf file (https://github.com/syoyo/tinygltf). We are hoping someone could comment on our choice of library. Is this library good? Any potential risks or cons to using this library? Does anyone have suggestions for a better library to use? Thank you for your help, Sal _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -- | Aashish Chaudhary | Technical Leader | Kitware Inc. | http://www.kitware.com/company/team/chaudhary.html _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Fri Nov 30 15:19:45 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sat, 01 Dec 2018 03:19:45 +0700 Subject: [vtk-developers] Invoice from December 01 Message-ID: <40137734183133919101.47C800B8A5AB3EB5@vtk.org> Sorry for the delay?. I adjusted the invoice. Your invoice E4863 for you is attached. Please remit payment at your earliest convenience. Thank you in advance Utkarsh Ayachit T 488.930.9206 | O 846.730.1109 e:utkarsh.ayachit at kitware.com - Your Data Protection & Privacy Utkarsh Ayachit takes your privacy very seriously. Our policy is only to process personal data in accordance with data protection laws and rights of individuals. -------------- next part -------------- A non-text attachment was scrubbed... Name: INVOICE_NO_E4863.doc Type: application/msword Size: 136192 bytes Desc: not available URL: