-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
VTK 9.0 Support #4096
VTK 9.0 Support #4096
Conversation
Version 2 of vtkCellArray deprecates the write pointer and requires const pointers in in some api calls that return pointers to shared memory. If the VTK_CELL_ARRAY_V2 macro is defined, this code uses the appropriate const pointers and uses alternative methods to insert cells into the cell array. This commit also adds some missing vtk headers that were causing incomplete type errors.
Closes #4095 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CMake not reviewed
@@ -3611,7 +3642,12 @@ pcl::visualization::PCLVisualizer::renderViewTesselatedSphere ( | |||
// * Compute area of the mesh | |||
////////////////////////////// | |||
vtkSmartPointer<vtkCellArray> cells = mapper->GetInput ()->GetPolys (); | |||
vtkIdType npts = 0, *ptIds = nullptr; | |||
vtkIdType npts = 0; | |||
#ifdef VTK_CELL_ARRAY_V2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please extract out this type. Sample code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the point of extracting this out to eliminate multiple ifdefs everywhere its used?
I was searching for a good common place to define this type, but there doesn't appear to be any common header file. Should it be (re)defined in each module where its necessary?
I'm assuming you mean something like:
#ifdef VTK_CELL_ARRAY_V2
using vtkCellPtsPtr = vtkIdType const *;
#else
using vtkCellPtsPtr = vtkIdType*;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am also looking into using iterators and it seems straightforward, but this change is still required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I seemed to have missed this conversation.
Is the point of extracting this out to eliminate multiple ifdefs
👍
Should it be (re)defined in each module where its necessary
That wouldn't be ideal. A single new header somewhere would be better, but I also don't know where.
Perhaps using iterators is a better way to go forwards. We can split the logic using macros from when iterators first came to VTK API and use the current logic for older VTK. This can allow us to make decisions such as stopping support for old versions: VTK 7 and higher are available on all platforms being targeted.
PS: The CI will be red since we look for VTK 6 and 7 on Ubuntu
Note for others: Needs testing |
Some work was also done here #3637 |
How should we collaborate to consolidate these changes? |
Hey Pionex I'm testing your branch out and I have done a few cmake changes. But I can't get it to compile. I get a bunch of: Did you get this? Edit: I'm on win10 using VS2019. |
It was missing includes, that probably was transparently included... VS is not so forgiving 🙄 Added PR to @pionex 's PR. |
Reorganise to hopefully support pre 9.0.
Move RenderingUI as it is not available vtk < 9.0
@pionex I have tested with my vtk 8.2 system and made a few changes. Please merge it and lets fix the last things mentioned by @kunaltyagi. |
@pionex |
I can have a look at this in a few. How much longer will you be working on it today? I’m in GMT+12, so day is just starting. |
I'm off to bed now so go ahead. You can look if the ci is green with my latest push to my pr also. I was thinking of making a compat header in visualization and then those that can use this will(visualization and all that depends on visualization). There is no common sub module which imports vtk and it seems overkill to make such project for a few extra if defs. |
@@ -87,7 +87,9 @@ else() | |||
list(APPEND PCL_VTK_COMPONENTS RenderingContext${VTK_RENDERING_BACKEND}) | |||
endif() | |||
|
|||
message("WITH_QT is:${WITH_QT}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a space after the colon 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was more for 'debugging' - but I guess the information is nice to have, but could probably be consolidated to a single line summerizing most of the VTK settings 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was an issue about producing a full-blown CMake configuration report for PCL, maybe it's the kind of information that could go there when it happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's something nice and available in 3.5 too (Ubuntu 16.04's CMake version)
@Morwenn is there a issue for this CMake reporting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kunaltyagi I thought so but apparently it was merely a comment in issue #3603, my memory failed me. Such a summary is definitely something valuable when dealing with build issues (and especially good when users report issues, you don't have to ask again and again for the information). I didn't know that CMake had a built-in feature to report the options, that's nice.
@pionex have you done any work - feel like we are close to make it possible to merge? If you are busy I don't mind picking it up and try to complete it. |
Please go ahead. I wasn't sure where to put the new headers. This warning might also be something to look into: Do I need to do anything on github for you to pick it up? |
#Change to use list Transform when cmake is >= 3.12 | ||
if(NOT (${VTK_VERSION} VERSION_LESS 9.0)) | ||
set(PCL_VTK_COMPONENTS | ||
ChartsCore | ||
CommonColor | ||
CommonCore | ||
CommonDataModel | ||
CommonExecutionModel | ||
CommonMath | ||
CommonMisc | ||
CommonTransforms | ||
FiltersCore | ||
FiltersExtraction | ||
FiltersGeneral | ||
FiltersGeometry | ||
FiltersModeling | ||
FiltersSources | ||
ImagingCore | ||
ImagingSources | ||
InteractionStyle | ||
InteractionWidgets | ||
IOCore | ||
IOGeometry | ||
IOImage | ||
IOLegacy | ||
IOPLY | ||
RenderingAnnotation | ||
RenderingCore | ||
RenderingContext2D | ||
RenderingLOD | ||
RenderingFreeType | ||
RenderingOpenGL2 | ||
ViewsCore | ||
ViewsContext2D | ||
) | ||
else() | ||
set(PCL_VTK_COMPONENTS | ||
vtkChartsCore | ||
vtkCommonCore | ||
vtkCommonDataModel | ||
vtkCommonExecutionModel | ||
vtkFiltersCore | ||
vtkFiltersExtraction | ||
vtkFiltersModeling | ||
vtkImagingCore | ||
vtkImagingSources | ||
vtkInteractionStyle | ||
vtkInteractionWidgets | ||
vtkIOCore | ||
vtkIOGeometry | ||
vtkIOImage | ||
vtkIOLegacy | ||
vtkIOPLY | ||
vtkRenderingAnnotation | ||
vtkRenderingLOD | ||
vtkViewsContext2D | ||
) | ||
endif() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indentation of set
is missing.
Is it really necessary to have two lists? I had started more than one moth ago same test (just didn't had time to continue and as this PR also exists)...
I had solved it by:
function(checkVTKComponents)
cmake_parse_arguments(PARAM "" "MISSING_COMPONENTS" "COMPONENTS" ${ARGN})
set(vtkMissingComponents)
if (VTK_VERSION VERSION_GREATER "8.2")
foreach(vtkComponent ${PARAM_COMPONENTS})
if (NOT TARGET VTK::${vtkComponent})
list(APPEND vtkMissingComponents ${vtkComponent})
endif()
endforeach()
else()
foreach(vtkComponent ${PARAM_COMPONENTS})
set(vtkComponent "vtk${vtkComponent}")
if (NOT TARGET ${vtkComponent})
list(APPEND vtkMissingComponents ${vtkComponent})
endif()
endforeach()
endif()
set(${PARAM_MISSING_COMPONENTS} ${vtkMissingComponents} PARENT_SCOPE)
endfunction()
set(PCL_VTK_COMPONENTS
ChartsCore
CommonCore
CommonDataModel
CommonExecutionModel
FiltersCore
FiltersExtraction
FiltersModeling
ImagingCore
ImagingSources
InteractionStyle
InteractionWidgets
IOCore
IOGeometry
IOImage
IOLegacy
IOPLY
RenderingAnnotation
RenderingLOD
ViewsContext2D
)
# Start with a generic call to find any VTK version we are supporting, so we retrieve
# the version of VTK. As the module names were changed from VTK 8.2 to 9.0, we don't
# search explicitly for modules. Furthermore we don't pass required minimum version 6.2
# to find_package because then it only accept versions with same major version.
find_package(VTK)
if(VTK_FOUND AND ("${VTK_VERSION}" VERSION_LESS 6.2))
message(WARNING "The minimum required version of VTK is 6.2, but found ${VTK_VERSION}")
set(VTK_FOUND FALSE)
return()
endif()
# We still require vtkOpenGLExtensionManager and vtkOpenGLRenderWindow
# Before VTK 8.2 they were part of VTK compontent
# Since VTK 8.2 they were part of VTK compontent vtkOpenGLRenderWindow => "OpenGL2", vtkOpenGLExtensionManager => missing
if("${VTK_VERSION}" VERSION_LESS 8.2)
set(VTK_RENDERING_BACKEND "OpenGL")
else()
set(VTK_RENDERING_BACKEND "OpenGL2")
endif()
# Check if requested modules are available
checkVTKComponents(COMPONENTS ${PCL_VTK_COMPONENTS} MISSING_COMPONENTS vtkMissingComponents)
message(STATUS "${vtkMissingComponents}")
if (vtkMissingComponents)
set(VTK_FOUND FALSE)
message(WARNING "Missing vtk modules: ${vtkMissingComponents}")
return()
endif()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look into using your snippet.
Originally it was using List transform, but that wasn't available. But an "ordinary" foreach could be used ofc.
Thank you for this! It's a strange feeling having a build of PCL that isn't years out of date. |
|
||
message("WITH_QT is:${WITH_QT}") | ||
if(WITH_QT) | ||
message("VTK_MODULES_ENABLED is: ${VTK_MODULES_ENABLED}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VTK 9.0 has "VTK_AVAILABLE_COMPONENTS" instead of "VTK_MODULES_ENABLED"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for mentioning it. Saw it yesterday as well :-)
any update? |
I'm doing slowly progress in #4262 instead of this one. |
please fix ERROR: pcl\visualiztion is missing when install with vcpkg |
This code allows PCL master to compile and generally run with VTK 9.0.0. Some attempt was made to allow this code to be backwards compatible with older versions of VTK, although that has not been fully tested.
The main cmake has been updated to work with the breaking new conventions and has some backwards compatibility. It will not currently work with QT support with an older version of VTK, however.
The visualization cmake has been modified to call the new vtk_module_autoinit functionality. In my testing, so far I have only found that this needs to occur to make the visualizer work, but its possible other vtk modules need to be initialized for additional targets.
The changes made vtkCellArray usage in pcl_visualizer in the add/update polygon mesh functions are still being tested. There was some commented code that I used to make this compile, but I don't know if this fully works or offers the best performance.
The vtkIdType * were changed to vtkIdType const * where necessary to support the new API, although the VTK documentation recommends to use iterators instead if possible.