To help the VTK community better anticipate VTK’s release schedule, we are posting a feature deadline for the next release cycle of October 29, 2020. We are hopeful that this approach will give the community enough time to better plan their workflows around VTK’s release, and we think it will help keep the release team vigilant about regularly cutting releases in the future. This does not necessarily mean we will not have a minor release until after the posted date, but it does give some assurances that a release will occur soon after the deadline. Please let us know what you think!
I LOVE THIS. One my of my bigger complaints was not having any insight into when the next release may be…
Yes, not knowing is what ends up with the stampede of “oh, I need this fixed too” MRs after we announce rc1. Hopefully this will allow us to say “sorry, you had 6 months to get this ready” for such things instead of pushing the release back further and further…
Basically, if you have some use case that is not covered by our CI today, now is the time to start that process with a nightly builder or, at the least, an issue to bring it to our attention. I hope to be getting gitlab-ci up and running more of our target setups over the summer.
Hi everyone,
I was checking some stuff for my work and I notice that IceT is not in VTK, but Paraview. There were plans to migrate from Paraview. Would you accept such changes for VTK 9.1?
This are the references about this topic:
https://vtk.org/Wiki/Multiple_views
https://vtk.org/Wiki/VTK/MultiPass_Rendering_With_IceT
I can open a new thread to discuss this further.
To make VTK’s growth sustainable, it would be great if new non-essential features would not be added to VTK core but to remote modules.
Is there a special meaning for “remote modules”?
Remote modules are VTK modules that are maintained in separate repositories and pulled into the build tree when enabled by setting CMake variables. I remember that @ben.boeckel wanted to get rid of them, but they are essential for keeping size of VTK core in check. There could be other solutions, but this one is proven to work well in ITK and was successfully used for a few modules in VTK, too.
1 Like
Correct. Just make them projects that depend on VTK just like you depend on Qt, zlib, or any other project. VTK is now much better behaved and being part of VTK’s build doesn’t grant you any special powers over external projects (unlike the old build system).
Understood. I tried to get it out from Paraview, but it is more complicated than expected. There are a lot of mixed dependencies.
Qt, zlib, etc. are different because they have no interest in VTK. I don’t expect them to help to make life of VTK developers easier.
VTK’s long-term success highly depends on how well suited it as an algorithm/library development platform. If there is no easy way to distribute VTK-based libraries as packages on PyPI then developers will spend their time, effort, and funding on VTK competitors.
It should be already possible to create and maintain VTK-based Python packages but I don’t know about any examples. Please give us a pointer to at least one project that can serve as an example for us to follow.
The best that I could imagine would be if VTK developers would maintain non-essential features in such VTK-based external packages, because we would then have lots of examples, they would be guaranteed to be up-to-date, and interests of VTK core developers would be naturally aligned with interests of VTK-based library developers. It would also make VTK truly modular and much smaller.
Remote modules only help those who are building their own VTK anyways. Remove modules are not part of the VTK wheels that we publish. If you want remote modules in a wheel, you’re starting from scratch because you’re also building the vtk wheel at that point.
Python really needs to figure out a way to ship headers and SDKs in wheels if they want C++ packages to be used between wheels. VTK can’t ever interact with the h5py wheel except through the Python interface because there aren’t any HDF5 headers for VTK to use when it compiles its HDF5-using code. We’re not going to solve that problem for Python. Anaconda is probably a better route because they do have allowances for SDKs.
This is what I want long-term, but convincing anyone to maintain the unmaintained bits of VTK while it lives inside is hard enough.
The closest project to doing this is probably the SMTK stack, but there’s a lot of extra things in there to take out before it’s actually an example for that kind of thing.
1 Like
There are quite a few packages that have followed in the path of making VTK a dependency and relying on it like any other library with great success. To name just a few: PyVista (and MNE-Python by extension), Mayavi, Vedo, and the many projects that depend on those. I can speak for PyVista and its experience relying on VTK this way - while painful at times (mostly from being in the dark about when the next release is coming and frantically trying to make updates for compatibility when it does come, which this thread seeks to resolve), it has worked quite well because there are VTK wheels on PyPI we can count on working (because they aren’t updated often) for most major OS and Python versions and there is a community on conda-forge maintaining a build recipe for VTK. The reality is that most Python 3D visualization consumers do not need the latest features from VTK, and they can get by with VTK 8.1, so these concerns about growth and maintainability are honestly a non-issue from a (perhaps just mine) downstream perspective.
I’ll just throw this out as an example of where things work great, but could be improved.
A group of us recently developed trako which leverages point cloud compression from glTF for use in diffusion tractography streamlines with scalar and tensor values per-vertex. One use case is to convert to/from our existing vtk/vtp format. The pypi package works fine for this with vtk as a dependency, but note that we only want to make use of VTK, not provide a superset of functionality that exposes all of VTK, like PyVista or Mayavi.
We did get feedback from a potential user of the format that our package was way too big to use as a dependency.
On investigation, as shown in this notebook, even though we are only using a couple reader/writer classes we end up pulling in 327 megabytes of VTK libraries.
It would be ideal if we could just get the small parts of VTK we actually need for this package.
1 Like
That’s totally fair
I can’t access that notebook to see the full details… however…
I’d propose not using VTK if you’re only using for file IO. There are plenty of alternatives like meshio that will likely meet your needs and is pure Python. After all, VTK is a visualization framework and you should only pull it into your stack if leveraging it for viz. Otherwise, I’d highly recommend pursuing other libs for your task to keep your stack lean and clean.
Sorry about that, [this link should work now[(Google Colab).
Thanks for the suggestion, I hadn’t considered that. Unfortunately it appears meshio only supports unstructured grid and not polydata. Also it appears they only support .vtk and not .vtp, which some of our users have been saving in. Plus of course we are used to VTK and switching to a different library would be a big pain.
And again, our use case generally works fine, it’s just that we get a bigger install than we might want. If there were a way to pip install subsets of VTK it might help projects like trako.
You can make your own wheels with just what you need from VTK by using a build with all the other stuff disabled, but the PyPI installs will almost always be bigger (because, AFAIK, I can’t put part of VTK in one wheel and other parts in other wheels and also guarantee that you don’t mix-and-match the wrong versions/builds together).
That’s exactly why VTK remote modules can be very useful. They make trivially easy for VTK maintainers (and any developer) to build wheels for VTK and all official remote modules using the exact same build environment and build options.
This seems to works nicely for ITK remote modules - see packages uploaded to PyPI by itkrobot: Profile of itkrobot · PyPI.
@thewtex can you comment on how well remote modules are working out for ITK and if you see them as a good solution for developing and distributing algorithms?
Official VTK wheels have no remote modules. I don’t forsee that ever changing. It does support making your own wheels with them, but a plain pip install vtk won’t have them.
I’d rather see them just go into VTK or stay out of its repository. It’s code that isn’t under our code review process and my knee-jerk reaction to remote modules breaking our CI is to just turn them off because coordinating changes is not easy (though not breaking API is obviously better here).