On behalf of the ParaView development team I am pleased to announce that ParaView 5.8.0 binaries and source code archives are now available for download at
https://www.paraview.org/download
Full release notes for 5.8.0 are available at
ParaView’s git repository and the ParaView superbuild repository have both been tagged with v5.8.0.
Thanks, and enjoy!
The ParaView Team
It is really cool.
Thanks for coding. Just for those who might also find they did great work:
** Hyper Tree Grids
what is ghost cells?
A visualization metric is also proposed so you can, for example, decide to subdivide using entropy while being able to visualize the arithmetic mean.
what does it mean?
** Calculator
what is vtkTable?
** Physically based rendering
the head is so cool
** BigBrain Project
what’s this project?
** Custom labels
** Linear camera?
** Cropping volume rendering is so beatiful
** New Billboard and Flagpole mode for Text source
this is really useful.
** Explicit refinement for line source points
What does it mean?
** Lagrangian Particle Tracker?
** Larger icons is useful for a my poor eyes.
** Light widgets
super cool. Now I have beam in ParaView.
https://vtk.org/doc/nightly/html/classvtkTable.html
** Linear camera?
What is your question here ?
** Explicit refinement for line source points
What does it mean?
Explained in the blog post
** Lagrangian Particle Tracker?
https://blog.kitware.com/vtk-and-paraview-add-highly-configurable-particle-tracker/
@cory.quammen : on Windows 10, opening any system dialog (File -> Open eg) segfaults ParaView.
I believe that 5.8.0 worked at work also, but I was primarily testing with Wavelet and Fast Uniform Grid.
Only the MPI version is buggy. Debugging right now.
Fixed by removing old version of ParaView and clearing my PATH.
I mostly suspect PATH was the issue.
Maybe hard to tell, but how would you judge the required effort to port an existing “custom application” that is currently based on PV 5.7 to that very cool new version 5.8?
Porting from 5.5 to 5.6 was rather easy, but I remember that porting from 5.6 to 5.7 was extremely much work because so many internals of how plugins are organized have changed. Now I see that the folder structure of the v5.8 source code has changed completely from v5.7, but this is maybe not such a big issue for a custom application if the “module” concept is still more or less the same as in 5.7.
Any hint or educated guess?
@cobo, there aren’t that many major changes in this version, definitely not to scale of 5.6 to 5.7. We changed the CMake system entirely for 5.7 so that is not too surprising. The directory structure changed, but as mentioned here, it should not be too complex to figure out the names for new modules. It also is a good opportunity to clean up unnecessary dependencies. The major API changes are listed here. Hope that helps.
