The smtk/cmb dashboards have not seen a lot of love in the past few months, so I’m spending a little time getting them back up and glowing green. In the process, I have made a few changes to CMB’s build process:
Bump boost to 1.66
This change was needed to support msvc2017, which is on my list of things to implement
A side effect of this update is that we now require the latest version of cmake. Moho has been updated and deployed (thus it is currently the only buildbot that successfully builds). Kerbin, TalosIV, Junction and Praxis will be updated shortly (and their dashboards will be broken until then).
Remove smtk’s custom rtvl in favor of the version in vxl master
rtvl doesn’t have the quietest build, and we were supporting an independent (and outdated) fork of it because of a few features that were added but never accepted back into the main fork. I have factored out the changed code and put it in smtk’s vxl extension.
It looks as though our build permutation for VXL is not tested, because it did not work out of the box. I am working on updating VXL’s master (here, here and here); when these changes land, we can switch cmb superbuild’s VXL repository from my fork back to the main fork.
The next steps include
Update ParaView to the latest master
@dcthomp and @Bob_Obara have made changes to ParaView master (does anyone have links to these MRs?) that we would like to see in CMB
Move some (all?) of the dashboard machines to Qt 5.11
MSVC2017 testing on Kerbin?
Superbuild for development?
Our superbuild is currently a pain point for external contributors
Marcus wrote an interesting blog post about the different types of superbuilds he’s maintained, and one of them that caught my eye was a “developer build” designed to bootstrap a developer’s environment.
If Marcus creates a developer superbuild for TomViz (and I believe he means to), we could get most of the infrastructure for CMB’s developer superbuild for free.
@tj.corona My PV MR made it in today. It should fix the “Could not locate server on which the source is being added” error message.
I am all for a “developer” superbuild, but we also need to generate packages. I would prefer to generate packages that have a chance at being included in system distribution channels (fedora, ubuntu, homebrew, chocolatey/nuget), as that also reduces the demand for developer superbuilds and one-off customer packaging. But all of these things cost time.
This past March, VTK’s vtkGDALRasterReader API was modified to remove GetNumberOfPoints(). Oddly, it was replaced with GetNumberOfCells(), which looks like it returns the same integral value. This MR updates smtk to use the new function call, but I need confirmation that this is a logically sane change. If this is still up in the air next week, I can ask the VTK developer who made the changes for his input.
(Edit) I am including this here because it will most likely come up when we update ParaView (it is currently breaking the VTK-only build).
Looking at the commit, it switched the reader to use the dual of the original grid (i.e., instead of reporting an image data with values at corner points, it returns a grid with values at the same set of locations but now they are cell centers rather than corner points. Depending on how you use the reader’s output, your solution may or may not be correct. If it’s not, you can run a cell-to-points filter on the reader’s output to get point-data. If you look at the changes to TestGDALRasterReader.cxx in the same commit (646b2dedba4…19b695dedb), you’ll see how they use vtkCellDataToPointData.
I suppose that our use of the reader hasn’t changed, so an implicit conversion from cell-centered to point-centered data for our use case shouldn’t hurt.
Are we fetching the point-data directly and using it? Or are we using the dataset to interpolate values? The interpolation will be different now (cell-data is constant over the entire cell while point-data varies (bi-/tri-)linearly. If the latter, we should explicitly run vtkCellDataToPointData. If the former, your change is fine although perhaps a little confusing to future developers (or yourself if your memory is anything like mine ).
Ok, after some digging: vtkGDALRasterPolydataWrapper is pv-wrapped as a converter from GDAL to point cloud data (so no testing on the master branch). The implementation iterates over the extent of the vtkImageData and for each location it computes the point ID and extracts the the scalar value for that point.
It looks like we will need to convert from cell data to point data before performing this step. I will update the MR accordingly.
(Edit) I’m having a slow morning. We don’t need to convert the data. I’ll make the appropriate changes to the MR just now.
My PRs to VXL have been accepted into the master branch, so we can now start tracking the main fork of VXL. A MR to make this change in our superbuild can be found here.
).