From bill.lorensen at gmail.com Tue May 2 14:46:56 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 2 May 2017 14:46:56 -0400 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki Message-ID: Folks, Time to kick the tires. Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home I have converted the top level example and cxx example pages. The wiki pages are automatically created from the gitlab repo pages. Need feedback before proceeding. Things I don't like: 1) Rendering of the large Cxx page is very slow. 2) I can't get rid of the file list on the right of the page. 3) gitlab converts the camel case to lower except for the first letter. markdown formatting is very limited. Bill From will.schroeder at kitware.com Tue May 2 15:02:49 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 2 May 2017 15:02:49 -0400 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: I am pretty impressed! The file list doesn't bother me all that much. I'm not sure how to address the other issues you list. I agree the Camel case problem is annoying; it'd be nice if this could be fixed. Great work, W On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen wrote: > Folks, > > Time to kick the tires. > > Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home > > I have converted the top level example and cxx example pages. > > The wiki pages are automatically created from the gitlab repo pages. > > Need feedback before proceeding. > > Things I don't like: > 1) Rendering of the large Cxx page is very slow. > 2) I can't get rid of the file list on the right of the page. > 3) gitlab converts the camel case to lower except for the first letter. > > markdown formatting is very limited. > > Bill > _______________________________________________ > 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: > http://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 rcourant at gmail.com Tue May 2 18:05:18 2017 From: rcourant at gmail.com (Carlos Lopez) Date: Tue, 2 May 2017 18:05:18 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow Message-ID: Hello, Is it possible to have a vtkOpenVRRenderWindow and a vtkWin32OpenGLRenderWindow working in the same application? I'm trying it by compiling vtk without the OpenVR render factory enabled and initializing the openvr classes directly. I get to have 2 render windows, one for openvr and a regular one. Calling renwin->Render() inside a loop for the openvr window works as it tracks the HMD and shows the controllers, but if I call Render() for the regular window, the openVRRenderWindow stops tracking the HMD and the rendering starts to flicker. Is there any shared resource between these windows that would break the rendering? thanks, carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Tue May 2 19:00:42 2017 From: wascott at sandia.gov (Scott, W Alan) Date: Tue, 2 May 2017 23:00:42 +0000 Subject: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Very nice. Well done. From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Will Schroeder Sent: Tuesday, May 2, 2017 1:03 PM To: Bill Lorensen Cc: VTK Developers Subject: [EXTERNAL] Re: [vtk-developers] Request for feedback: Gitlab examples wiki I am pretty impressed! The file list doesn't bother me all that much. I'm not sure how to address the other issues you list. I agree the Camel case problem is annoying; it'd be nice if this could be fixed. Great work, W On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen > wrote: Folks, Time to kick the tires. Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home I have converted the top level example and cxx example pages. The wiki pages are automatically created from the gitlab repo pages. Need feedback before proceeding. Things I don't like: 1) Rendering of the large Cxx page is very slow. 2) I can't get rid of the file list on the right of the page. 3) gitlab converts the camel case to lower except for the first letter. markdown formatting is very limited. Bill _______________________________________________ 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: http://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 ken.martin at kitware.com Wed May 3 08:34:16 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 3 May 2017 08:34:16 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow In-Reply-To: References: Message-ID: It should work, but you have to be careful, I would not share any mappers/actors etc between the two and make sure you are letting the OpenVR loop run at least 100 fps. On Tue, May 2, 2017 at 6:05 PM, Carlos Lopez wrote: > Hello, > > Is it possible to have a vtkOpenVRRenderWindow and a > vtkWin32OpenGLRenderWindow > working in the same application? > > I'm trying it by compiling vtk without the OpenVR render factory enabled > and initializing the openvr classes directly. > > I get to have 2 render windows, one for openvr and a regular one. Calling > renwin->Render() inside a loop for the openvr window works as it tracks the > HMD and shows the controllers, but if I call Render() for the regular > window, the openVRRenderWindow stops tracking the HMD and the rendering > starts to flicker. > > Is there any shared resource between these windows that would break the > rendering? > > thanks, > carlos > > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 sean at rogue-research.com Wed May 3 11:06:18 2017 From: sean at rogue-research.com (Sean McBride) Date: Wed, 3 May 2017 11:06:18 -0400 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170120031324.934419583@mail.rogue-research.com> References: <20170120031324.934419583@mail.rogue-research.com> Message-ID: <20170503150618.375492316@mail.rogue-research.com> There are about 20 of these left... does anyone want to tackle them or shall I suppress them all? (Their presence, I believe, is making people miss other new warnings that cppcheck is finding.) Cheers, Sean On Thu, 19 Jan 2017 22:13:24 -0500, Sean McBride said: >Hi all, > >I've deliberately un-suppressed cppcheck's duplInheritedMember warning >and now we have 24 warnings here: > > > >The warning is telling us that various classes have ivars with the same >name as an ivar in their superclass. This is a pretty bad code smell IMNSHO. > >But it takes someone who knows the classes well to decide on the best fix... > >The warnings are: > >Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines >member variable with name 'Colors' also defined in its parent class >'vtkPlot3D'. > >Charts/Core/vtkChartMatrix.h:155: warning: The class >'vtkScatterPlotMatrix' defines member variable with name 'Private' also >defined in its parent class 'vtkChartMatrix'. > >Common/DataModel/vtkPlanes.h:129: warning: The class >'vtkPlanesIntersection' defines member variable with name 'Plane' also >defined in its parent class 'vtkPlanes'. > >Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class >'vtkSimpleCellTessellator' defines member variable with name 'DataSet' >also defined in its parent class 'vtkGenericCellTessellator'. > >Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: >The class 'vtkCompositeDataPipeline' defines member variable with name >'UpdateExtentRequest' also defined in its parent class >'vtkStreamingDemandDrivenPipeline'. > >Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: >The class 'vtkCompositeInterpolatedVelocityField' defines member >variable with name 'TOLERANCE_SCALE' also defined in its parent class >'vtkAbstractInterpolatedVelocityField'. > >IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class >'vtkTableToSQLiteWriter' defines member variable with name 'Input' also >defined in its parent class 'vtkTableToDatabaseWriter'. > >Imaging/Core/vtkImageReslice.h:510: warning: The class >'vtkImageResample' defines member variable with name 'OutputSpacing' >also defined in its parent class 'vtkImageReslice'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'Modifier' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'P1World' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'P2World' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'P3World' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'P4World' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'P21World' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'P43World' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'T21' also defined in its parent class 'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'T43' also defined in its parent class 'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'CenterWorld' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The >class 'vtkBiDimensionalRepresentation2D' defines member variable with >name 'StartEventPositionWorld' also defined in its parent class >'vtkBiDimensionalRepresentation'. > >Rendering/Core/vtkColorTransferFunction.h:398: warning: The class >'vtkDiscretizableColorTransferFunction' defines member variable with >name 'BuildTime' also defined in its parent class 'vtkColorTransferFunction'. > >Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class >'vtkHardwareSelectionPolyDataPainter' defines member variable with name >'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. > >Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class >'vtkXRenderWindowTclInteractor' defines member variable with name >'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. > >Views/Infovis/vtkRenderView.h:289: warning: The class >'vtkGraphLayoutView' defines member variable with name 'Interacting' >also defined in its parent class 'vtkRenderView'. > >Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class >'vtkRenderedTreeAreaRepresentation' defines member variable with name >'Implementation' also defined in its parent class 'vtkRenderedRepresentation'. From rcourant at gmail.com Wed May 3 11:08:05 2017 From: rcourant at gmail.com (Carlos Lopez) Date: Wed, 3 May 2017 11:08:05 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow In-Reply-To: References: Message-ID: Hi Ken, Thanks for your reply. There seems to be something else going on. In my example, I create 2 of source (cubesource),mapper, actor , renderer, and renderwindow; for the last 2 one is win32 and the other OpenVR. I add the cube to the win32 render window and call render, it appears and renders correctly. Calling renwin->Render() in a loop only for the OpenVR render window, running under the debugger, makes the OpenVR window on the screen show in sequence, a black screen and then the VR circles. It does not update the graphics and seems to be showing an old frame. If I run the OpenVR loop, before the win32 window renders, then it works ok, it tracks and renders the geometry and the controllers, but then calling render on the other one, one single time and going back to its own loop, breaks the rendering as described above. There also seems to be an issue with the order of initialization if I add an interactor to the win32 window. any suggestions are welcome. thanks, carlos On Wed, May 3, 2017 at 8:34 AM, Ken Martin wrote: > It should work, but you have to be careful, I would not share any > mappers/actors etc between the two and make sure you are letting the OpenVR > loop run at least 100 fps. > > On Tue, May 2, 2017 at 6:05 PM, Carlos Lopez wrote: > >> Hello, >> >> Is it possible to have a vtkOpenVRRenderWindow and a >> vtkWin32OpenGLRenderWindow >> working in the same application? >> >> I'm trying it by compiling vtk without the OpenVR render factory enabled >> and initializing the openvr classes directly. >> >> I get to have 2 render windows, one for openvr and a regular one. Calling >> renwin->Render() inside a loop for the openvr window works as it tracks the >> HMD and shows the controllers, but if I call Render() for the regular >> window, the openVRRenderWindow stops tracking the HMD and the rendering >> starts to flicker. >> >> Is there any shared resource between these windows that would break the >> rendering? >> >> thanks, >> carlos >> >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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 ken.martin at kitware.com Wed May 3 11:20:38 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 3 May 2017 11:20:38 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow In-Reply-To: References: Message-ID: Make sure you also explicitly create the OpenGL/OpenVRCamera for each renderer as they are different. And I would create the OpenVRRenderWindowInteractor Win32OpenGLRenderWindowInteractor explicitly and assign them. Those are the 4 key classes you have to explicitly create as leaf nodes OpenVRRenderWIndow OpenVRRenderer OpenVRCamera OpenVRRenderWIndowInteractor Win32OpenGLRenderWindow OpenGLRenderer OpenGLCamera Win32OpenGLRenderWIndowInteractor On Wed, May 3, 2017 at 11:08 AM, Carlos Lopez wrote: > Hi Ken, > > Thanks for your reply. > > There seems to be something else going on. > > In my example, I create 2 of source (cubesource),mapper, actor , renderer, > and renderwindow; for the last 2 one is win32 and the other OpenVR. > > I add the cube to the win32 render window and call render, it appears and > renders correctly. > > Calling renwin->Render() in a loop only for the OpenVR render window, > running under the debugger, makes the OpenVR window on the screen show in > sequence, a black screen and then the VR circles. It does not update the > graphics and seems to be showing an old frame. > > If I run the OpenVR loop, before the win32 window renders, then it works > ok, it tracks and renders the geometry and the controllers, but then > calling render on the other one, one single time and going back to its own > loop, breaks the rendering as described above. > > There also seems to be an issue with the order of initialization if I add > an interactor to the win32 window. > > any suggestions are welcome. > > thanks, > carlos > > > > > > > > On Wed, May 3, 2017 at 8:34 AM, Ken Martin wrote: > >> It should work, but you have to be careful, I would not share any >> mappers/actors etc between the two and make sure you are letting the OpenVR >> loop run at least 100 fps. >> >> On Tue, May 2, 2017 at 6:05 PM, Carlos Lopez wrote: >> >>> Hello, >>> >>> Is it possible to have a vtkOpenVRRenderWindow and a >>> vtkWin32OpenGLRenderWindow >>> working in the same application? >>> >>> I'm trying it by compiling vtk without the OpenVR render factory enabled >>> and initializing the openvr classes directly. >>> >>> I get to have 2 render windows, one for openvr and a regular one. >>> Calling renwin->Render() inside a loop for the openvr window works as it >>> tracks the HMD and shows the controllers, but if I call Render() for the >>> regular window, the openVRRenderWindow stops tracking the HMD and the >>> rendering starts to flicker. >>> >>> Is there any shared resource between these windows that would break the >>> rendering? >>> >>> thanks, >>> carlos >>> >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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. >> > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 jhlegarreta at vicomtech.org Wed May 3 11:22:40 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Wed, 3 May 2017 17:22:40 +0200 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170503150618.375492316@mail.rogue-research.com> References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> Message-ID: I will give the warnings in vtkBiDimensionalRepresentation2D a try. JON HAITZ -- On 3 May 2017 at 17:06, Sean McBride wrote: > There are about 20 of these left... does anyone want to tackle them or > shall I suppress them all? (Their presence, I believe, is making people > miss other new warnings that cppcheck is finding.) > > Cheers, > > Sean > > > On Thu, 19 Jan 2017 22:13:24 -0500, Sean McBride said: > > >Hi all, > > > >I've deliberately un-suppressed cppcheck's duplInheritedMember warning > >and now we have 24 warnings here: > > > > > > > >The warning is telling us that various classes have ivars with the same > >name as an ivar in their superclass. This is a pretty bad code smell > IMNSHO. > > > >But it takes someone who knows the classes well to decide on the best > fix... > > > >The warnings are: > > > >Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines > >member variable with name 'Colors' also defined in its parent class > >'vtkPlot3D'. > > > >Charts/Core/vtkChartMatrix.h:155: warning: The class > >'vtkScatterPlotMatrix' defines member variable with name 'Private' also > >defined in its parent class 'vtkChartMatrix'. > > > >Common/DataModel/vtkPlanes.h:129: warning: The class > >'vtkPlanesIntersection' defines member variable with name 'Plane' also > >defined in its parent class 'vtkPlanes'. > > > >Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class > >'vtkSimpleCellTessellator' defines member variable with name 'DataSet' > >also defined in its parent class 'vtkGenericCellTessellator'. > > > >Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: > >The class 'vtkCompositeDataPipeline' defines member variable with name > >'UpdateExtentRequest' also defined in its parent class > >'vtkStreamingDemandDrivenPipeline'. > > > >Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: > >The class 'vtkCompositeInterpolatedVelocityField' defines member > >variable with name 'TOLERANCE_SCALE' also defined in its parent class > >'vtkAbstractInterpolatedVelocityField'. > > > >IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class > >'vtkTableToSQLiteWriter' defines member variable with name 'Input' also > >defined in its parent class 'vtkTableToDatabaseWriter'. > > > >Imaging/Core/vtkImageReslice.h:510: warning: The class > >'vtkImageResample' defines member variable with name 'OutputSpacing' > >also defined in its parent class 'vtkImageReslice'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'Modifier' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P1World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P2World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P3World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P4World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P21World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P43World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'T21' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'T43' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'CenterWorld' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'StartEventPositionWorld' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Rendering/Core/vtkColorTransferFunction.h:398: warning: The class > >'vtkDiscretizableColorTransferFunction' defines member variable with > >name 'BuildTime' also defined in its parent class > 'vtkColorTransferFunction'. > > > >Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class > >'vtkHardwareSelectionPolyDataPainter' defines member variable with name > >'TotalCells' also defined in its parent class > 'vtkStandardPolyDataPainter'. > > > >Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class > >'vtkXRenderWindowTclInteractor' defines member variable with name > >'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. > > > >Views/Infovis/vtkRenderView.h:289: warning: The class > >'vtkGraphLayoutView' defines member variable with name 'Interacting' > >also defined in its parent class 'vtkRenderView'. > > > >Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class > >'vtkRenderedTreeAreaRepresentation' defines member variable with name > >'Implementation' also defined in its parent class > 'vtkRenderedRepresentation'. > > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed May 3 11:25:09 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 3 May 2017 09:25:09 -0600 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170503150618.375492316@mail.rogue-research.com> References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> Message-ID: I don't think suppressing them is a good idea, redefined member variables are strongly indicative of real bugs. I'll fix the trivial lex one, at least, and I'll take a glance at some of the others. - David On Wed, May 3, 2017 at 9:06 AM, Sean McBride wrote: > There are about 20 of these left... does anyone want to tackle them or > shall I suppress them all? (Their presence, I believe, is making people > miss other new warnings that cppcheck is finding.) > > Cheers, > > Sean > > > On Thu, 19 Jan 2017 22:13:24 -0500, Sean McBride said: > > >Hi all, > > > >I've deliberately un-suppressed cppcheck's duplInheritedMember warning > >and now we have 24 warnings here: > > > > > > > >The warning is telling us that various classes have ivars with the same > >name as an ivar in their superclass. This is a pretty bad code smell > IMNSHO. > > > >But it takes someone who knows the classes well to decide on the best > fix... > > > >The warnings are: > > > >Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines > >member variable with name 'Colors' also defined in its parent class > >'vtkPlot3D'. > > > >Charts/Core/vtkChartMatrix.h:155: warning: The class > >'vtkScatterPlotMatrix' defines member variable with name 'Private' also > >defined in its parent class 'vtkChartMatrix'. > > > >Common/DataModel/vtkPlanes.h:129: warning: The class > >'vtkPlanesIntersection' defines member variable with name 'Plane' also > >defined in its parent class 'vtkPlanes'. > > > >Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class > >'vtkSimpleCellTessellator' defines member variable with name 'DataSet' > >also defined in its parent class 'vtkGenericCellTessellator'. > > > >Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: > >The class 'vtkCompositeDataPipeline' defines member variable with name > >'UpdateExtentRequest' also defined in its parent class > >'vtkStreamingDemandDrivenPipeline'. > > > >Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: > >The class 'vtkCompositeInterpolatedVelocityField' defines member > >variable with name 'TOLERANCE_SCALE' also defined in its parent class > >'vtkAbstractInterpolatedVelocityField'. > > > >IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class > >'vtkTableToSQLiteWriter' defines member variable with name 'Input' also > >defined in its parent class 'vtkTableToDatabaseWriter'. > > > >Imaging/Core/vtkImageReslice.h:510: warning: The class > >'vtkImageResample' defines member variable with name 'OutputSpacing' > >also defined in its parent class 'vtkImageReslice'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'Modifier' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P1World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P2World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P3World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P4World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P21World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'P43World' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'T21' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'T43' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'CenterWorld' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The > >class 'vtkBiDimensionalRepresentation2D' defines member variable with > >name 'StartEventPositionWorld' also defined in its parent class > >'vtkBiDimensionalRepresentation'. > > > >Rendering/Core/vtkColorTransferFunction.h:398: warning: The class > >'vtkDiscretizableColorTransferFunction' defines member variable with > >name 'BuildTime' also defined in its parent class > 'vtkColorTransferFunction'. > > > >Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class > >'vtkHardwareSelectionPolyDataPainter' defines member variable with name > >'TotalCells' also defined in its parent class > 'vtkStandardPolyDataPainter'. > > > >Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class > >'vtkXRenderWindowTclInteractor' defines member variable with name > >'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. > > > >Views/Infovis/vtkRenderView.h:289: warning: The class > >'vtkGraphLayoutView' defines member variable with name 'Interacting' > >also defined in its parent class 'vtkRenderView'. > > > >Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class > >'vtkRenderedTreeAreaRepresentation' defines member variable with name > >'Implementation' also defined in its parent class > 'vtkRenderedRepresentation'. > > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcourant at gmail.com Wed May 3 11:31:01 2017 From: rcourant at gmail.com (Carlos Lopez) Date: Wed, 3 May 2017 11:31:01 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow In-Reply-To: References: Message-ID: Ok, am I missing a step? I create the classes as you suggest, since turning off the factory option makes OpenVRRenderer initialize the wrong camera class. (I rebuilt vtk with the openvr factory on, and initialized both sets explicitly) I set: renWin->AddRenderer(ren1); iren->SetRenderWindow(renWin) ren1->SetActiveCamera(camera); is there some other connection that should be done explicitly? thanks, carlos On Wed, May 3, 2017 at 11:20 AM, Ken Martin wrote: > Make sure you also explicitly create the OpenGL/OpenVRCamera for each > renderer as they are different. And I would create the > OpenVRRenderWindowInteractor Win32OpenGLRenderWindowInteractor explicitly > and assign them. Those are the 4 key classes you have to explicitly create > as leaf nodes > > OpenVRRenderWIndow > OpenVRRenderer > OpenVRCamera > OpenVRRenderWIndowInteractor > > Win32OpenGLRenderWindow > OpenGLRenderer > OpenGLCamera > Win32OpenGLRenderWIndowInteractor > > > > > On Wed, May 3, 2017 at 11:08 AM, Carlos Lopez wrote: > >> Hi Ken, >> >> Thanks for your reply. >> >> There seems to be something else going on. >> >> In my example, I create 2 of source (cubesource),mapper, actor , >> renderer, and renderwindow; for the last 2 one is win32 and the other >> OpenVR. >> >> I add the cube to the win32 render window and call render, it appears and >> renders correctly. >> >> Calling renwin->Render() in a loop only for the OpenVR render window, >> running under the debugger, makes the OpenVR window on the screen show in >> sequence, a black screen and then the VR circles. It does not update the >> graphics and seems to be showing an old frame. >> >> If I run the OpenVR loop, before the win32 window renders, then it works >> ok, it tracks and renders the geometry and the controllers, but then >> calling render on the other one, one single time and going back to its own >> loop, breaks the rendering as described above. >> >> There also seems to be an issue with the order of initialization if I add >> an interactor to the win32 window. >> >> any suggestions are welcome. >> >> thanks, >> carlos >> >> >> >> >> >> >> >> On Wed, May 3, 2017 at 8:34 AM, Ken Martin >> wrote: >> >>> It should work, but you have to be careful, I would not share any >>> mappers/actors etc between the two and make sure you are letting the OpenVR >>> loop run at least 100 fps. >>> >>> On Tue, May 2, 2017 at 6:05 PM, Carlos Lopez wrote: >>> >>>> Hello, >>>> >>>> Is it possible to have a vtkOpenVRRenderWindow and a >>>> vtkWin32OpenGLRenderWindow >>>> working in the same application? >>>> >>>> I'm trying it by compiling vtk without the OpenVR render factory >>>> enabled and initializing the openvr classes directly. >>>> >>>> I get to have 2 render windows, one for openvr and a regular one. >>>> Calling renwin->Render() inside a loop for the openvr window works as it >>>> tracks the HMD and shows the controllers, but if I call Render() for the >>>> regular window, the openVRRenderWindow stops tracking the HMD and the >>>> rendering starts to flicker. >>>> >>>> Is there any shared resource between these windows that would break the >>>> rendering? >>>> >>>> thanks, >>>> carlos >>>> >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> >>> 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. >>> >> >> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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 jhlegarreta at vicomtech.org Wed May 3 11:32:57 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Wed, 3 May 2017 17:32:57 +0200 Subject: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Nice job Bill. Thanks. Despite the limitations you have identified, I think transitioning to gitlab makes it easier for people to use the examples resource, and also, easier to maintain the VTK eco-system. The yet-to-come steps to add an example will also be a nice addition. IMHO, the right pane could be helpful if it were a true index of the sections so that one could easily switch between them without scrolling back to the top of the page, and if it could be collapsed. I think this is a step yet too distant, but having an image gallery instead of (or in addition to) a list would be helpful for such cases in which the person seeks by a visualization rather than by the filter name. It may happen that we have difficulties in identifying the right name/class in the class index. I think someone pointed an example during the hackathon, but as pointed then, the wiki is not well adapted to that. May be sharing that could be useful in case someone has a better idea, or else just for the records. JON HAITZ -- On 3 May 2017 at 01:00, Scott, W Alan wrote: > Very nice. Well done. > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Will Schroeder > *Sent:* Tuesday, May 2, 2017 1:03 PM > *To:* Bill Lorensen > *Cc:* VTK Developers > *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: Gitlab > examples wiki > > > > I am pretty impressed! > > > > The file list doesn't bother me all that much. I'm not sure how to address > the other issues you list. I agree the Camel case problem is annoying; it'd > be nice if this could be fixed. > > > > Great work, > > W > > > > On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen > wrote: > > Folks, > > Time to kick the tires. > > Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home > > I have converted the top level example and cxx example pages. > > The wiki pages are automatically created from the gitlab repo pages. > > Need feedback before proceeding. > > Things I don't like: > 1) Rendering of the large Cxx page is very slow. > 2) I can't get rid of the file list on the right of the page. > 3) gitlab converts the camel case to lower except for the first letter. > > markdown formatting is very limited. > > Bill > _______________________________________________ > 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: > http://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 > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed May 3 11:35:59 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 3 May 2017 11:35:59 -0400 Subject: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Jon, Thanks for the feedback. All of the pages on the wiki are generated from the repo. I think I can generate a gallery of images. Still some cleanup before I get to that. Bill On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < jhlegarreta at vicomtech.org> wrote: > Nice job Bill. Thanks. > > Despite the limitations you have identified, I think transitioning to > gitlab makes it easier for people to use the examples resource, and also, > easier to maintain the VTK eco-system. > > The yet-to-come steps to add an example will also be a nice addition. > > IMHO, the right pane could be helpful if it were a true index of the > sections so that one could easily switch between them without scrolling > back to the top of the page, and if it could be collapsed. > > I think this is a step yet too distant, but having an image gallery > instead of (or in addition to) a list would be helpful for such cases in > which the person seeks by a visualization rather than by the filter name. > It may happen that we have difficulties in identifying the right name/class > in the class index. I think someone pointed an example during the > hackathon, but as pointed then, the wiki is not well adapted to that. > > May be sharing that could be useful in case someone has a better idea, or > else just for the records. > > JON HAITZ > > > -- > > > On 3 May 2017 at 01:00, Scott, W Alan wrote: > >> Very nice. Well done. >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *Will Schroeder >> *Sent:* Tuesday, May 2, 2017 1:03 PM >> *To:* Bill Lorensen >> *Cc:* VTK Developers >> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: Gitlab >> examples wiki >> >> >> >> I am pretty impressed! >> >> >> >> The file list doesn't bother me all that much. I'm not sure how to >> address the other issues you list. I agree the Camel case problem is >> annoying; it'd be nice if this could be fixed. >> >> >> >> Great work, >> >> W >> >> >> >> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen >> wrote: >> >> Folks, >> >> Time to kick the tires. >> >> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >> >> I have converted the top level example and cxx example pages. >> >> The wiki pages are automatically created from the gitlab repo pages. >> >> Need feedback before proceeding. >> >> Things I don't like: >> 1) Rendering of the large Cxx page is very slow. >> 2) I can't get rid of the file list on the right of the page. >> 3) gitlab converts the camel case to lower except for the first letter. >> >> markdown formatting is very limited. >> >> Bill >> _______________________________________________ >> 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: >> http://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 >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed May 3 12:58:20 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 3 May 2017 12:58:20 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow In-Reply-To: References: Message-ID: Nope that looks like it - Ken On Wed, May 3, 2017 at 11:31 AM, Carlos Lopez wrote: > Ok, am I missing a step? > > I create the classes as you suggest, since turning off the factory option > makes OpenVRRenderer initialize the wrong camera class. > (I rebuilt vtk with the openvr factory on, and initialized both sets > explicitly) > > I set: > > renWin->AddRenderer(ren1); > iren->SetRenderWindow(renWin) > ren1->SetActiveCamera(camera); > > is there some other connection that should be done explicitly? > > thanks, > carlos > > > > > > > > On Wed, May 3, 2017 at 11:20 AM, Ken Martin > wrote: > >> Make sure you also explicitly create the OpenGL/OpenVRCamera for each >> renderer as they are different. And I would create the >> OpenVRRenderWindowInteractor Win32OpenGLRenderWindowInteractor >> explicitly and assign them. Those are the 4 key classes you have to >> explicitly create as leaf nodes >> >> OpenVRRenderWIndow >> OpenVRRenderer >> OpenVRCamera >> OpenVRRenderWIndowInteractor >> >> Win32OpenGLRenderWindow >> OpenGLRenderer >> OpenGLCamera >> Win32OpenGLRenderWIndowInteractor >> >> >> >> >> On Wed, May 3, 2017 at 11:08 AM, Carlos Lopez wrote: >> >>> Hi Ken, >>> >>> Thanks for your reply. >>> >>> There seems to be something else going on. >>> >>> In my example, I create 2 of source (cubesource),mapper, actor , >>> renderer, and renderwindow; for the last 2 one is win32 and the other >>> OpenVR. >>> >>> I add the cube to the win32 render window and call render, it appears >>> and renders correctly. >>> >>> Calling renwin->Render() in a loop only for the OpenVR render window, >>> running under the debugger, makes the OpenVR window on the screen show in >>> sequence, a black screen and then the VR circles. It does not update the >>> graphics and seems to be showing an old frame. >>> >>> If I run the OpenVR loop, before the win32 window renders, then it works >>> ok, it tracks and renders the geometry and the controllers, but then >>> calling render on the other one, one single time and going back to its own >>> loop, breaks the rendering as described above. >>> >>> There also seems to be an issue with the order of initialization if I >>> add an interactor to the win32 window. >>> >>> any suggestions are welcome. >>> >>> thanks, >>> carlos >>> >>> >>> >>> >>> >>> >>> >>> On Wed, May 3, 2017 at 8:34 AM, Ken Martin >>> wrote: >>> >>>> It should work, but you have to be careful, I would not share any >>>> mappers/actors etc between the two and make sure you are letting the OpenVR >>>> loop run at least 100 fps. >>>> >>>> On Tue, May 2, 2017 at 6:05 PM, Carlos Lopez >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> Is it possible to have a vtkOpenVRRenderWindow and a >>>>> vtkWin32OpenGLRenderWindow >>>>> working in the same application? >>>>> >>>>> I'm trying it by compiling vtk without the OpenVR render factory >>>>> enabled and initializing the openvr classes directly. >>>>> >>>>> I get to have 2 render windows, one for openvr and a regular one. >>>>> Calling renwin->Render() inside a loop for the openvr window works as it >>>>> tracks the HMD and shows the controllers, but if I call Render() for the >>>>> regular window, the openVRRenderWindow stops tracking the HMD and the >>>>> rendering starts to flicker. >>>>> >>>>> Is there any shared resource between these windows that would break >>>>> the rendering? >>>>> >>>>> thanks, >>>>> carlos >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Distinguished Engineer >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Clifton Park NY 12065 >>>> >>>> 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. >>>> >>> >>> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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. >> > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 rcourant at gmail.com Wed May 3 13:33:56 2017 From: rcourant at gmail.com (Carlos Lopez) Date: Wed, 3 May 2017 13:33:56 -0400 Subject: [vtk-developers] vtkOpenVRRenderWindow and vtkWin32OpenGLRenderWindow In-Reply-To: References: Message-ID: Thanks for the confirmation. I've now gotten both windows to work by creating them in different threads, but I don't see the window events in the win32 window. best, carlos On Wed, May 3, 2017 at 12:58 PM, Ken Martin wrote: > Nope that looks like it - Ken > > On Wed, May 3, 2017 at 11:31 AM, Carlos Lopez wrote: > >> Ok, am I missing a step? >> >> I create the classes as you suggest, since turning off the factory option >> makes OpenVRRenderer initialize the wrong camera class. >> (I rebuilt vtk with the openvr factory on, and initialized both sets >> explicitly) >> >> I set: >> >> renWin->AddRenderer(ren1); >> iren->SetRenderWindow(renWin) >> ren1->SetActiveCamera(camera); >> >> is there some other connection that should be done explicitly? >> >> thanks, >> carlos >> >> >> >> >> >> >> >> On Wed, May 3, 2017 at 11:20 AM, Ken Martin >> wrote: >> >>> Make sure you also explicitly create the OpenGL/OpenVRCamera for each >>> renderer as they are different. And I would create the >>> OpenVRRenderWindowInteractor Win32OpenGLRenderWindowInteractor >>> explicitly and assign them. Those are the 4 key classes you have to >>> explicitly create as leaf nodes >>> >>> OpenVRRenderWIndow >>> OpenVRRenderer >>> OpenVRCamera >>> OpenVRRenderWIndowInteractor >>> >>> Win32OpenGLRenderWindow >>> OpenGLRenderer >>> OpenGLCamera >>> Win32OpenGLRenderWIndowInteractor >>> >>> >>> >>> >>> On Wed, May 3, 2017 at 11:08 AM, Carlos Lopez >>> wrote: >>> >>>> Hi Ken, >>>> >>>> Thanks for your reply. >>>> >>>> There seems to be something else going on. >>>> >>>> In my example, I create 2 of source (cubesource),mapper, actor , >>>> renderer, and renderwindow; for the last 2 one is win32 and the other >>>> OpenVR. >>>> >>>> I add the cube to the win32 render window and call render, it appears >>>> and renders correctly. >>>> >>>> Calling renwin->Render() in a loop only for the OpenVR render window, >>>> running under the debugger, makes the OpenVR window on the screen show in >>>> sequence, a black screen and then the VR circles. It does not update the >>>> graphics and seems to be showing an old frame. >>>> >>>> If I run the OpenVR loop, before the win32 window renders, then it >>>> works ok, it tracks and renders the geometry and the controllers, but then >>>> calling render on the other one, one single time and going back to its own >>>> loop, breaks the rendering as described above. >>>> >>>> There also seems to be an issue with the order of initialization if I >>>> add an interactor to the win32 window. >>>> >>>> any suggestions are welcome. >>>> >>>> thanks, >>>> carlos >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, May 3, 2017 at 8:34 AM, Ken Martin >>>> wrote: >>>> >>>>> It should work, but you have to be careful, I would not share any >>>>> mappers/actors etc between the two and make sure you are letting the OpenVR >>>>> loop run at least 100 fps. >>>>> >>>>> On Tue, May 2, 2017 at 6:05 PM, Carlos Lopez >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Is it possible to have a vtkOpenVRRenderWindow and a >>>>>> vtkWin32OpenGLRenderWindow >>>>>> working in the same application? >>>>>> >>>>>> I'm trying it by compiling vtk without the OpenVR render factory >>>>>> enabled and initializing the openvr classes directly. >>>>>> >>>>>> I get to have 2 render windows, one for openvr and a regular one. >>>>>> Calling renwin->Render() inside a loop for the openvr window works as it >>>>>> tracks the HMD and shows the controllers, but if I call Render() for the >>>>>> regular window, the openVRRenderWindow stops tracking the HMD and the >>>>>> rendering starts to flicker. >>>>>> >>>>>> Is there any shared resource between these windows that would break >>>>>> the rendering? >>>>>> >>>>>> thanks, >>>>>> carlos >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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: >>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ken Martin PhD >>>>> Distinguished Engineer >>>>> Kitware Inc. >>>>> 28 Corporate Drive >>>>> Clifton Park NY 12065 >>>>> >>>>> 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. >>>>> >>>> >>>> >>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> >>> 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. >>> >> >> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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 aron.helser at kitware.com Wed May 3 13:45:56 2017 From: aron.helser at kitware.com (Aron Helser) Date: Wed, 3 May 2017 13:45:56 -0400 Subject: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: The automatically generated list of examples is looking quite good - the clean look of the wiki suits the content well, I think. I pointed out two examples of an image gallery I liked during the hackathon - First https://d3js.org/, which has a hand-picked gallery of examples as the banner "image" explaining what d3.js is. The second and more applicable example was https://bl.ocks.org/mbostock, or https://bl.ocks.org/ which is an automatically generated gallery of all examples (possibly filtered to those written by the author of d3). Once you click an example, it is interactive, because they are all done in javascript. Anyone can contribute to bl.ocks.org, and each example is backed by a github 'gist', like https://gist.github.com/mbostock/4063269 This setup makes it very easy to work with single examples, and fork them to make your own versions. I don't propose that this is the right approach for VTK, but for ideas or inspiration. Thanks, Aron On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen wrote: > Jon, > > Thanks for the feedback. All of the pages on the wiki are generated from > the repo. I think I can generate a gallery of images. Still some cleanup > before I get to that. > > Bill > > On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < > jhlegarreta at vicomtech.org> wrote: > >> Nice job Bill. Thanks. >> >> Despite the limitations you have identified, I think transitioning to >> gitlab makes it easier for people to use the examples resource, and also, >> easier to maintain the VTK eco-system. >> >> The yet-to-come steps to add an example will also be a nice addition. >> >> IMHO, the right pane could be helpful if it were a true index of the >> sections so that one could easily switch between them without scrolling >> back to the top of the page, and if it could be collapsed. >> >> I think this is a step yet too distant, but having an image gallery >> instead of (or in addition to) a list would be helpful for such cases in >> which the person seeks by a visualization rather than by the filter name. >> It may happen that we have difficulties in identifying the right name/class >> in the class index. I think someone pointed an example during the >> hackathon, but as pointed then, the wiki is not well adapted to that. >> >> May be sharing that could be useful in case someone has a better idea, or >> else just for the records. >> >> JON HAITZ >> >> >> -- >> >> >> On 3 May 2017 at 01:00, Scott, W Alan wrote: >> >>> Very nice. Well done. >>> >>> >>> >>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>> Behalf Of *Will Schroeder >>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>> *To:* Bill Lorensen >>> *Cc:* VTK Developers >>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: Gitlab >>> examples wiki >>> >>> >>> >>> I am pretty impressed! >>> >>> >>> >>> The file list doesn't bother me all that much. I'm not sure how to >>> address the other issues you list. I agree the Camel case problem is >>> annoying; it'd be nice if this could be fixed. >>> >>> >>> >>> Great work, >>> >>> W >>> >>> >>> >>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen >>> wrote: >>> >>> Folks, >>> >>> Time to kick the tires. >>> >>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>> >>> I have converted the top level example and cxx example pages. >>> >>> The wiki pages are automatically created from the gitlab repo pages. >>> >>> Need feedback before proceeding. >>> >>> Things I don't like: >>> 1) Rendering of the large Cxx page is very slow. >>> 2) I can't get rid of the file list on the right of the page. >>> 3) gitlab converts the camel case to lower except for the first letter. >>> >>> markdown formatting is very limited. >>> >>> Bill >>> _______________________________________________ >>> 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: >>> http://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 >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Unpaid intern in BillsBasement at noware dot com > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed May 3 13:57:21 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 3 May 2017 13:57:21 -0400 Subject: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Aron, That is pretty cool. I think we can do some kind of image gallery to navigate the examples. Bill On Wed, May 3, 2017 at 1:45 PM, Aron Helser wrote: > The automatically generated list of examples is looking quite good - the > clean look of the wiki suits the content well, I think. > > I pointed out two examples of an image gallery I liked during the > hackathon - First https://d3js.org/, which has a hand-picked gallery of > examples as the banner "image" explaining what d3.js is. > The second and more applicable example was https://bl.ocks.org/mbostock, > or https://bl.ocks.org/ which is an automatically generated gallery of > all examples (possibly filtered to those written by the author of d3). > Once you click an example, it is interactive, because they are all done in > javascript. > > Anyone can contribute to bl.ocks.org, and each example is backed by a > github 'gist', like https://gist.github.com/mbostock/4063269 > This setup makes it very easy to work with single examples, and fork them > to make your own versions. > > I don't propose that this is the right approach for VTK, but for ideas or > inspiration. > Thanks, > Aron > > On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen > wrote: > >> Jon, >> >> Thanks for the feedback. All of the pages on the wiki are generated from >> the repo. I think I can generate a gallery of images. Still some cleanup >> before I get to that. >> >> Bill >> >> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >> jhlegarreta at vicomtech.org> wrote: >> >>> Nice job Bill. Thanks. >>> >>> Despite the limitations you have identified, I think transitioning to >>> gitlab makes it easier for people to use the examples resource, and also, >>> easier to maintain the VTK eco-system. >>> >>> The yet-to-come steps to add an example will also be a nice addition. >>> >>> IMHO, the right pane could be helpful if it were a true index of the >>> sections so that one could easily switch between them without scrolling >>> back to the top of the page, and if it could be collapsed. >>> >>> I think this is a step yet too distant, but having an image gallery >>> instead of (or in addition to) a list would be helpful for such cases in >>> which the person seeks by a visualization rather than by the filter name. >>> It may happen that we have difficulties in identifying the right name/class >>> in the class index. I think someone pointed an example during the >>> hackathon, but as pointed then, the wiki is not well adapted to that. >>> >>> May be sharing that could be useful in case someone has a better idea, >>> or else just for the records. >>> >>> JON HAITZ >>> >>> >>> -- >>> >>> >>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>> >>>> Very nice. Well done. >>>> >>>> >>>> >>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>> Behalf Of *Will Schroeder >>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>> *To:* Bill Lorensen >>>> *Cc:* VTK Developers >>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>> Gitlab examples wiki >>>> >>>> >>>> >>>> I am pretty impressed! >>>> >>>> >>>> >>>> The file list doesn't bother me all that much. I'm not sure how to >>>> address the other issues you list. I agree the Camel case problem is >>>> annoying; it'd be nice if this could be fixed. >>>> >>>> >>>> >>>> Great work, >>>> >>>> W >>>> >>>> >>>> >>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen >>>> wrote: >>>> >>>> Folks, >>>> >>>> Time to kick the tires. >>>> >>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>> >>>> I have converted the top level example and cxx example pages. >>>> >>>> The wiki pages are automatically created from the gitlab repo pages. >>>> >>>> Need feedback before proceeding. >>>> >>>> Things I don't like: >>>> 1) Rendering of the large Cxx page is very slow. >>>> 2) I can't get rid of the file list on the right of the page. >>>> 3) gitlab converts the camel case to lower except for the first letter. >>>> >>>> markdown formatting is very limited. >>>> >>>> Bill >>>> _______________________________________________ >>>> 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: >>>> http://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 >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Wed May 3 14:36:47 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 3 May 2017 14:36:47 -0400 Subject: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Hi Bill, Great effort pushing this forward! It looks really good to me. Cheers, Andy On Wed, May 3, 2017 at 1:57 PM, Bill Lorensen wrote: > Aron, > > That is pretty cool. I think we can do some kind of image gallery to > navigate the examples. > > Bill > > > On Wed, May 3, 2017 at 1:45 PM, Aron Helser > wrote: > >> The automatically generated list of examples is looking quite good - the >> clean look of the wiki suits the content well, I think. >> >> I pointed out two examples of an image gallery I liked during the >> hackathon - First https://d3js.org/, which has a hand-picked gallery of >> examples as the banner "image" explaining what d3.js is. >> The second and more applicable example was https://bl.ocks.org/mbostock, >> or https://bl.ocks.org/ which is an automatically generated gallery of >> all examples (possibly filtered to those written by the author of d3). >> Once you click an example, it is interactive, because they are all done in >> javascript. >> >> Anyone can contribute to bl.ocks.org, and each example is backed by a >> github 'gist', like https://gist.github.com/mbostock/4063269 >> This setup makes it very easy to work with single examples, and fork them >> to make your own versions. >> >> I don't propose that this is the right approach for VTK, but for ideas or >> inspiration. >> Thanks, >> Aron >> >> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen >> wrote: >> >>> Jon, >>> >>> Thanks for the feedback. All of the pages on the wiki are generated from >>> the repo. I think I can generate a gallery of images. Still some cleanup >>> before I get to that. >>> >>> Bill >>> >>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>> jhlegarreta at vicomtech.org> wrote: >>> >>>> Nice job Bill. Thanks. >>>> >>>> Despite the limitations you have identified, I think transitioning to >>>> gitlab makes it easier for people to use the examples resource, and also, >>>> easier to maintain the VTK eco-system. >>>> >>>> The yet-to-come steps to add an example will also be a nice addition. >>>> >>>> IMHO, the right pane could be helpful if it were a true index of the >>>> sections so that one could easily switch between them without scrolling >>>> back to the top of the page, and if it could be collapsed. >>>> >>>> I think this is a step yet too distant, but having an image gallery >>>> instead of (or in addition to) a list would be helpful for such cases in >>>> which the person seeks by a visualization rather than by the filter name. >>>> It may happen that we have difficulties in identifying the right name/class >>>> in the class index. I think someone pointed an example during the >>>> hackathon, but as pointed then, the wiki is not well adapted to that. >>>> >>>> May be sharing that could be useful in case someone has a better idea, >>>> or else just for the records. >>>> >>>> JON HAITZ >>>> >>>> >>>> -- >>>> >>>> >>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>> >>>>> Very nice. Well done. >>>>> >>>>> >>>>> >>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>> Behalf Of *Will Schroeder >>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>> *To:* Bill Lorensen >>>>> *Cc:* VTK Developers >>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>> Gitlab examples wiki >>>>> >>>>> >>>>> >>>>> I am pretty impressed! >>>>> >>>>> >>>>> >>>>> The file list doesn't bother me all that much. I'm not sure how to >>>>> address the other issues you list. I agree the Camel case problem is >>>>> annoying; it'd be nice if this could be fixed. >>>>> >>>>> >>>>> >>>>> Great work, >>>>> >>>>> W >>>>> >>>>> >>>>> >>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen >>>>> wrote: >>>>> >>>>> Folks, >>>>> >>>>> Time to kick the tires. >>>>> >>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>> >>>>> I have converted the top level example and cxx example pages. >>>>> >>>>> The wiki pages are automatically created from the gitlab repo pages. >>>>> >>>>> Need feedback before proceeding. >>>>> >>>>> Things I don't like: >>>>> 1) Rendering of the large Cxx page is very slow. >>>>> 2) I can't get rid of the file list on the right of the page. >>>>> 3) gitlab converts the camel case to lower except for the first letter. >>>>> >>>>> markdown formatting is very limited. >>>>> >>>>> Bill >>>>> _______________________________________________ >>>>> 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: >>>>> http://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 >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Unpaid intern in BillsBasement at noware dot com > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed May 3 18:56:04 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 4 May 2017 08:56:04 +1000 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki Message-ID: Hi Bill, I just looked at it and it is not too bad. Like you I don't like the automatic conversion of camel case e.g "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It certainly doesn't add to readability. I don't mind the file list on the right-hand side, I think it is useful. One big thing missing is the description, will you be able to automatically grab this too? I think it is important as it provides rationale and background to the examples. Thinking further along, how easy will it be to add new examples or update existing ones? Regards Andrew > ---------- Forwarded message ---------- > From: Bill Lorensen > To: Aron Helser > Cc: VTK Developers , Will Schroeder < > will.schroeder at kitware.com> > Bcc: > Date: Wed, 3 May 2017 13:57:21 -0400 > Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab > examples wiki > Aron, > > That is pretty cool. I think we can do some kind of image gallery to > navigate the examples. > > Bill > > > On Wed, May 3, 2017 at 1:45 PM, Aron Helser > wrote: > >> The automatically generated list of examples is looking quite good - the >> clean look of the wiki suits the content well, I think. >> >> I pointed out two examples of an image gallery I liked during the >> hackathon - First https://d3js.org/, which has a hand-picked gallery of >> examples as the banner "image" explaining what d3.js is. >> The second and more applicable example was https://bl.ocks.org/mbostock, >> or https://bl.ocks.org/ which is an automatically generated gallery of >> all examples (possibly filtered to those written by the author of d3). >> Once you click an example, it is interactive, because they are all done in >> javascript. >> >> Anyone can contribute to bl.ocks.org, and each example is backed by a >> github 'gist', like https://gist.github.com/mbostock/4063269 >> This setup makes it very easy to work with single examples, and fork them >> to make your own versions. >> >> I don't propose that this is the right approach for VTK, but for ideas or >> inspiration. >> Thanks, >> Aron >> >> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen >> wrote: >> >>> Jon, >>> >>> Thanks for the feedback. All of the pages on the wiki are generated from >>> the repo. I think I can generate a gallery of images. Still some cleanup >>> before I get to that. >>> >>> Bill >>> >>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>> jhlegarreta at vicomtech.org> wrote: >>> >>>> Nice job Bill. Thanks. >>>> >>>> Despite the limitations you have identified, I think transitioning to >>>> gitlab makes it easier for people to use the examples resource, and also, >>>> easier to maintain the VTK eco-system. >>>> >>>> The yet-to-come steps to add an example will also be a nice addition. >>>> >>>> IMHO, the right pane could be helpful if it were a true index of the >>>> sections so that one could easily switch between them without scrolling >>>> back to the top of the page, and if it could be collapsed. >>>> >>>> I think this is a step yet too distant, but having an image gallery >>>> instead of (or in addition to) a list would be helpful for such cases in >>>> which the person seeks by a visualization rather than by the filter name. >>>> It may happen that we have difficulties in identifying the right name/class >>>> in the class index. I think someone pointed an example during the >>>> hackathon, but as pointed then, the wiki is not well adapted to that. >>>> >>>> May be sharing that could be useful in case someone has a better idea, >>>> or else just for the records. >>>> >>>> JON HAITZ >>>> >>>> >>>> -- >>>> >>>> >>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>> >>>>> Very nice. Well done. >>>>> >>>>> >>>>> >>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>> Behalf Of *Will Schroeder >>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>> *To:* Bill Lorensen >>>>> *Cc:* VTK Developers >>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>> Gitlab examples wiki >>>>> >>>>> >>>>> >>>>> I am pretty impressed! >>>>> >>>>> >>>>> >>>>> The file list doesn't bother me all that much. I'm not sure how to >>>>> address the other issues you list. I agree the Camel case problem is >>>>> annoying; it'd be nice if this could be fixed. >>>>> >>>>> >>>>> >>>>> Great work, >>>>> >>>>> W >>>>> >>>>> >>>>> >>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen >>>>> wrote: >>>>> >>>>> Folks, >>>>> >>>>> Time to kick the tires. >>>>> >>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>> >>>>> I have converted the top level example and cxx example pages. >>>>> >>>>> The wiki pages are automatically created from the gitlab repo pages. >>>>> >>>>> Need feedback before proceeding. >>>>> >>>>> Things I don't like: >>>>> 1) Rendering of the large Cxx page is very slow. >>>>> 2) I can't get rid of the file list on the right of the page. >>>>> 3) gitlab converts the camel case to lower except for the first letter. >>>>> >>>>> markdown formatting is very limited. >>>>> >>>>> Bill >>>>> _______________________________________________ >>>>> 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: >>>>> http://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 >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Unpaid intern in BillsBasement at noware dot com > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed May 3 19:05:49 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 3 May 2017 19:05:49 -0400 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Yes I have a way to include the descriptions. Now I need to get the old ones automatically. I'm working on a script for that. For example I did one of yours manually https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Visualization/ElevationBandsWithGlyphs On May 3, 2017 6:56 PM, "Andrew Maclean" wrote: > Hi Bill, > I just looked at it and it is not too bad. > > Like you I don't like the automatic conversion of camel case e.g > "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It > certainly doesn't add to readability. > > I don't mind the file list on the right-hand side, I think it is useful. > > One big thing missing is the description, will you be able to > automatically grab this too? I think it is important as it provides > rationale and background to the examples. > > Thinking further along, how easy will it be to add new examples or update > existing ones? > > Regards > Andrew > > > > >> ---------- Forwarded message ---------- >> From: Bill Lorensen >> To: Aron Helser >> Cc: VTK Developers , Will Schroeder < >> will.schroeder at kitware.com> >> Bcc: >> Date: Wed, 3 May 2017 13:57:21 -0400 >> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: Gitlab >> examples wiki >> Aron, >> >> That is pretty cool. I think we can do some kind of image gallery to >> navigate the examples. >> >> Bill >> >> >> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >> wrote: >> >>> The automatically generated list of examples is looking quite good - the >>> clean look of the wiki suits the content well, I think. >>> >>> I pointed out two examples of an image gallery I liked during the >>> hackathon - First https://d3js.org/, which has a hand-picked gallery of >>> examples as the banner "image" explaining what d3.js is. >>> The second and more applicable example was https://bl.ocks.org/mbostock, >>> or https://bl.ocks.org/ which is an automatically generated gallery of >>> all examples (possibly filtered to those written by the author of d3). >>> Once you click an example, it is interactive, because they are all done in >>> javascript. >>> >>> Anyone can contribute to bl.ocks.org, and each example is backed by a >>> github 'gist', like https://gist.github.com/mbostock/4063269 >>> This setup makes it very easy to work with single examples, and fork >>> them to make your own versions. >>> >>> I don't propose that this is the right approach for VTK, but for ideas >>> or inspiration. >>> Thanks, >>> Aron >>> >>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen >>> wrote: >>> >>>> Jon, >>>> >>>> Thanks for the feedback. All of the pages on the wiki are generated >>>> from the repo. I think I can generate a gallery of images. Still some >>>> cleanup before I get to that. >>>> >>>> Bill >>>> >>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>> jhlegarreta at vicomtech.org> wrote: >>>> >>>>> Nice job Bill. Thanks. >>>>> >>>>> Despite the limitations you have identified, I think transitioning to >>>>> gitlab makes it easier for people to use the examples resource, and also, >>>>> easier to maintain the VTK eco-system. >>>>> >>>>> The yet-to-come steps to add an example will also be a nice addition. >>>>> >>>>> IMHO, the right pane could be helpful if it were a true index of the >>>>> sections so that one could easily switch between them without scrolling >>>>> back to the top of the page, and if it could be collapsed. >>>>> >>>>> I think this is a step yet too distant, but having an image gallery >>>>> instead of (or in addition to) a list would be helpful for such cases in >>>>> which the person seeks by a visualization rather than by the filter name. >>>>> It may happen that we have difficulties in identifying the right name/class >>>>> in the class index. I think someone pointed an example during the >>>>> hackathon, but as pointed then, the wiki is not well adapted to that. >>>>> >>>>> May be sharing that could be useful in case someone has a better idea, >>>>> or else just for the records. >>>>> >>>>> JON HAITZ >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>> >>>>>> Very nice. Well done. >>>>>> >>>>>> >>>>>> >>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>> Behalf Of *Will Schroeder >>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>> *To:* Bill Lorensen >>>>>> *Cc:* VTK Developers >>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>>> Gitlab examples wiki >>>>>> >>>>>> >>>>>> >>>>>> I am pretty impressed! >>>>>> >>>>>> >>>>>> >>>>>> The file list doesn't bother me all that much. I'm not sure how to >>>>>> address the other issues you list. I agree the Camel case problem is >>>>>> annoying; it'd be nice if this could be fixed. >>>>>> >>>>>> >>>>>> >>>>>> Great work, >>>>>> >>>>>> W >>>>>> >>>>>> >>>>>> >>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>> bill.lorensen at gmail.com> wrote: >>>>>> >>>>>> Folks, >>>>>> >>>>>> Time to kick the tires. >>>>>> >>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>> >>>>>> I have converted the top level example and cxx example pages. >>>>>> >>>>>> The wiki pages are automatically created from the gitlab repo pages. >>>>>> >>>>>> Need feedback before proceeding. >>>>>> >>>>>> Things I don't like: >>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>> letter. >>>>>> >>>>>> markdown formatting is very limited. >>>>>> >>>>>> Bill >>>>>> _______________________________________________ >>>>>> 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: >>>>>> http://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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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: >>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed May 3 19:09:23 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 4 May 2017 09:09:23 +1000 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Hi Bill, That looks really great. Thanks Andrew On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen wrote: > Yes I have a way to include the descriptions. Now I need to get the old > ones automatically. I'm working on a script for that. > For example I did one of yours manually > https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Visualization/ > ElevationBandsWithGlyphs > > On May 3, 2017 6:56 PM, "Andrew Maclean" > wrote: > >> Hi Bill, >> I just looked at it and it is not too bad. >> >> Like you I don't like the automatic conversion of camel case e.g >> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >> certainly doesn't add to readability. >> >> I don't mind the file list on the right-hand side, I think it is useful. >> >> One big thing missing is the description, will you be able to >> automatically grab this too? I think it is important as it provides >> rationale and background to the examples. >> >> Thinking further along, how easy will it be to add new examples or update >> existing ones? >> >> Regards >> Andrew >> >> >> >> >>> ---------- Forwarded message ---------- >>> From: Bill Lorensen >>> To: Aron Helser >>> Cc: VTK Developers , Will Schroeder < >>> will.schroeder at kitware.com> >>> Bcc: >>> Date: Wed, 3 May 2017 13:57:21 -0400 >>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>> Gitlab examples wiki >>> Aron, >>> >>> That is pretty cool. I think we can do some kind of image gallery to >>> navigate the examples. >>> >>> Bill >>> >>> >>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >>> wrote: >>> >>>> The automatically generated list of examples is looking quite good - >>>> the clean look of the wiki suits the content well, I think. >>>> >>>> I pointed out two examples of an image gallery I liked during the >>>> hackathon - First https://d3js.org/, which has a hand-picked gallery >>>> of examples as the banner "image" explaining what d3.js is. >>>> The second and more applicable example was https://bl.ocks.org/mbostock, >>>> or https://bl.ocks.org/ which is an automatically generated gallery of >>>> all examples (possibly filtered to those written by the author of d3). >>>> Once you click an example, it is interactive, because they are all done in >>>> javascript. >>>> >>>> Anyone can contribute to bl.ocks.org, and each example is backed by a >>>> github 'gist', like https://gist.github.com/mbostock/4063269 >>>> This setup makes it very easy to work with single examples, and fork >>>> them to make your own versions. >>>> >>>> I don't propose that this is the right approach for VTK, but for ideas >>>> or inspiration. >>>> Thanks, >>>> Aron >>>> >>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen >>> > wrote: >>>> >>>>> Jon, >>>>> >>>>> Thanks for the feedback. All of the pages on the wiki are generated >>>>> from the repo. I think I can generate a gallery of images. Still some >>>>> cleanup before I get to that. >>>>> >>>>> Bill >>>>> >>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>> jhlegarreta at vicomtech.org> wrote: >>>>> >>>>>> Nice job Bill. Thanks. >>>>>> >>>>>> Despite the limitations you have identified, I think transitioning to >>>>>> gitlab makes it easier for people to use the examples resource, and also, >>>>>> easier to maintain the VTK eco-system. >>>>>> >>>>>> The yet-to-come steps to add an example will also be a nice addition. >>>>>> >>>>>> IMHO, the right pane could be helpful if it were a true index of the >>>>>> sections so that one could easily switch between them without scrolling >>>>>> back to the top of the page, and if it could be collapsed. >>>>>> >>>>>> I think this is a step yet too distant, but having an image gallery >>>>>> instead of (or in addition to) a list would be helpful for such cases in >>>>>> which the person seeks by a visualization rather than by the filter name. >>>>>> It may happen that we have difficulties in identifying the right name/class >>>>>> in the class index. I think someone pointed an example during the >>>>>> hackathon, but as pointed then, the wiki is not well adapted to that. >>>>>> >>>>>> May be sharing that could be useful in case someone has a better >>>>>> idea, or else just for the records. >>>>>> >>>>>> JON HAITZ >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>>> >>>>>>> Very nice. Well done. >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>> Behalf Of *Will Schroeder >>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>> *To:* Bill Lorensen >>>>>>> *Cc:* VTK Developers >>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>>>> Gitlab examples wiki >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am pretty impressed! >>>>>>> >>>>>>> >>>>>>> >>>>>>> The file list doesn't bother me all that much. I'm not sure how to >>>>>>> address the other issues you list. I agree the Camel case problem is >>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Great work, >>>>>>> >>>>>>> W >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Time to kick the tires. >>>>>>> >>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>> >>>>>>> I have converted the top level example and cxx example pages. >>>>>>> >>>>>>> The wiki pages are automatically created from the gitlab repo pages. >>>>>>> >>>>>>> Need feedback before proceeding. >>>>>>> >>>>>>> Things I don't like: >>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>> letter. >>>>>>> >>>>>>> markdown formatting is very limited. >>>>>>> >>>>>>> Bill >>>>>>> _______________________________________________ >>>>>>> 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: >>>>>>> http://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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Unpaid intern in BillsBasement at noware dot com >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu May 4 01:54:29 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 4 May 2017 15:54:29 +1000 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Hi Bill, If you need to test the descriptions, this one: http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/NamedColorPatches has a lot of html links in the description. It also references the python version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/NamedColorPatches Regards Andrew On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean wrote: > Hi Bill, > > That looks really great. > > Thanks > Andrew > > On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen > wrote: > >> Yes I have a way to include the descriptions. Now I need to get the old >> ones automatically. I'm working on a script for that. >> For example I did one of yours manually >> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/ >> Visualization/ElevationBandsWithGlyphs >> >> On May 3, 2017 6:56 PM, "Andrew Maclean" >> wrote: >> >>> Hi Bill, >>> I just looked at it and it is not too bad. >>> >>> Like you I don't like the automatic conversion of camel case e.g >>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>> certainly doesn't add to readability. >>> >>> I don't mind the file list on the right-hand side, I think it is useful. >>> >>> One big thing missing is the description, will you be able to >>> automatically grab this too? I think it is important as it provides >>> rationale and background to the examples. >>> >>> Thinking further along, how easy will it be to add new examples or >>> update existing ones? >>> >>> Regards >>> Andrew >>> >>> >>> >>> >>>> ---------- Forwarded message ---------- >>>> From: Bill Lorensen >>>> To: Aron Helser >>>> Cc: VTK Developers , Will Schroeder < >>>> will.schroeder at kitware.com> >>>> Bcc: >>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>> Gitlab examples wiki >>>> Aron, >>>> >>>> That is pretty cool. I think we can do some kind of image gallery to >>>> navigate the examples. >>>> >>>> Bill >>>> >>>> >>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >>>> wrote: >>>> >>>>> The automatically generated list of examples is looking quite good - >>>>> the clean look of the wiki suits the content well, I think. >>>>> >>>>> I pointed out two examples of an image gallery I liked during the >>>>> hackathon - First https://d3js.org/, which has a hand-picked gallery >>>>> of examples as the banner "image" explaining what d3.js is. >>>>> The second and more applicable example was https://bl.ocks.org/mbosto >>>>> ck, or https://bl.ocks.org/ which is an automatically generated >>>>> gallery of all examples (possibly filtered to those written by the author >>>>> of d3). Once you click an example, it is interactive, because they are all >>>>> done in javascript. >>>>> >>>>> Anyone can contribute to bl.ocks.org, and each example is backed by a >>>>> github 'gist', like https://gist.github.com/mbostock/4063269 >>>>> This setup makes it very easy to work with single examples, and fork >>>>> them to make your own versions. >>>>> >>>>> I don't propose that this is the right approach for VTK, but for ideas >>>>> or inspiration. >>>>> Thanks, >>>>> Aron >>>>> >>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>> bill.lorensen at gmail.com> wrote: >>>>> >>>>>> Jon, >>>>>> >>>>>> Thanks for the feedback. All of the pages on the wiki are generated >>>>>> from the repo. I think I can generate a gallery of images. Still some >>>>>> cleanup before I get to that. >>>>>> >>>>>> Bill >>>>>> >>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>> >>>>>>> Nice job Bill. Thanks. >>>>>>> >>>>>>> Despite the limitations you have identified, I think transitioning >>>>>>> to gitlab makes it easier for people to use the examples resource, and >>>>>>> also, easier to maintain the VTK eco-system. >>>>>>> >>>>>>> The yet-to-come steps to add an example will also be a nice addition. >>>>>>> >>>>>>> IMHO, the right pane could be helpful if it were a true index of the >>>>>>> sections so that one could easily switch between them without scrolling >>>>>>> back to the top of the page, and if it could be collapsed. >>>>>>> >>>>>>> I think this is a step yet too distant, but having an image gallery >>>>>>> instead of (or in addition to) a list would be helpful for such cases in >>>>>>> which the person seeks by a visualization rather than by the filter name. >>>>>>> It may happen that we have difficulties in identifying the right name/class >>>>>>> in the class index. I think someone pointed an example during the >>>>>>> hackathon, but as pointed then, the wiki is not well adapted to that. >>>>>>> >>>>>>> May be sharing that could be useful in case someone has a better >>>>>>> idea, or else just for the records. >>>>>>> >>>>>>> JON HAITZ >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>>>> >>>>>>>> Very nice. Well done. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>>> Behalf Of *Will Schroeder >>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>> *To:* Bill Lorensen >>>>>>>> *Cc:* VTK Developers >>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>>>>> Gitlab examples wiki >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am pretty impressed! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The file list doesn't bother me all that much. I'm not sure how to >>>>>>>> address the other issues you list. I agree the Camel case problem is >>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Great work, >>>>>>>> >>>>>>>> W >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> Time to kick the tires. >>>>>>>> >>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>> >>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>> >>>>>>>> The wiki pages are automatically created from the gitlab repo pages. >>>>>>>> >>>>>>>> Need feedback before proceeding. >>>>>>>> >>>>>>>> Things I don't like: >>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>>> letter. >>>>>>>> >>>>>>>> markdown formatting is very limited. >>>>>>>> >>>>>>>> Bill >>>>>>>> _______________________________________________ >>>>>>>> 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: >>>>>>>> http://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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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: >>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>> >>>>>> _______________________________________________ >>>>>> 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: >>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Unpaid intern in BillsBasement at noware dot com >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>> >>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >>> >> > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankhesh.jhaveri at kitware.com Thu May 4 09:20:59 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Thu, 04 May 2017 13:20:59 +0000 Subject: [vtk-developers] Ready to branch for VTK 8.0.0? Message-ID: Hello, Does anyone have any work in progress branches that should go in before we branch VTK 8.0.0? If there are no objections, we are hoping to get the release process started in the week of May 15. Thanks, Sankhesh ? -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri May 5 10:09:55 2017 From: sean at rogue-research.com (Sean McBride) Date: Fri, 5 May 2017 10:09:55 -0400 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> Message-ID: <20170505140955.1559355036@mail.rogue-research.com> On Wed, 3 May 2017 09:25:09 -0600, David Gobbi said: >I don't think suppressing them is a good idea, redefined member variables >are strongly indicative of real bugs. Thanks David & Jon! We are down to 10 now: Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines member variable with name 'Colors' also defined in its parent class 'vtkPlot3D'. Charts/Core/vtkChartMatrix.h:155: warning: The class 'vtkScatterPlotMatrix' defines member variable with name 'Private' also defined in its parent class 'vtkChartMatrix'. Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also defined in its parent class 'vtkGenericCellTessellator'. Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: The class 'vtkCompositeDataPipeline' defines member variable with name 'UpdateExtentRequest' also defined in its parent class 'vtkStreamingDemandDrivenPipeline'. IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also defined in its parent class 'vtkTableToDatabaseWriter'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'Modifier' also defined in its parent class 'vtkBiDimensionalRepresentation'. Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class 'vtkHardwareSelectionPolyDataPainter' defines member variable with name 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class 'vtkXRenderWindowTclInteractor' defines member variable with name 'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. Views/Infovis/vtkRenderView.h:289: warning: The class 'vtkGraphLayoutView' defines member variable with name 'Interacting' also defined in its parent class 'vtkRenderView'. Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class 'vtkRenderedTreeAreaRepresentation' defines member variable with name 'Implementation' also defined in its parent class 'vtkRenderedRepresentation'. From jhlegarreta at vicomtech.org Fri May 5 10:30:06 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Fri, 5 May 2017 16:30:06 +0200 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170505140955.1559355036@mail.rogue-research.com> References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> Message-ID: You're welcome. I'll adopt the vtkPlotSurface, vtkScatterPlotMatrix, and vtkBiDimensionalRepresentation2D (there was a member in this last that escaped my patch set) class issues. JON HAITZ -- On 5 May 2017 at 16:09, Sean McBride wrote: > On Wed, 3 May 2017 09:25:09 -0600, David Gobbi said: > > >I don't think suppressing them is a good idea, redefined member variables > >are strongly indicative of real bugs. > > Thanks David & Jon! We are down to 10 now: > > Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines > member variable with name 'Colors' also defined in its parent class > 'vtkPlot3D'. > > Charts/Core/vtkChartMatrix.h:155: warning: The class > 'vtkScatterPlotMatrix' defines member variable with name 'Private' also > defined in its parent class 'vtkChartMatrix'. > > Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class > 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also > defined in its parent class 'vtkGenericCellTessellator'. > > Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: > The class 'vtkCompositeDataPipeline' defines member variable with name > 'UpdateExtentRequest' also defined in its parent class ' > vtkStreamingDemandDrivenPipeline'. > > IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class > 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also > defined in its parent class 'vtkTableToDatabaseWriter'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'Modifier' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class ' > vtkHardwareSelectionPolyDataPainter' defines member variable with name > 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. > > Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class 'vtkXRenderWindowTclInteractor' > defines member variable with name 'Internal' also defined in its parent > class 'vtkXRenderWindowInteractor'. > > Views/Infovis/vtkRenderView.h:289: warning: The class > 'vtkGraphLayoutView' defines member variable with name 'Interacting' also > defined in its parent class 'vtkRenderView'. > > Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class ' > vtkRenderedTreeAreaRepresentation' defines member variable with name > 'Implementation' also defined in its parent class > 'vtkRenderedRepresentation'. > > > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhlegarreta at vicomtech.org Fri May 5 12:31:53 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Fri, 5 May 2017 18:31:53 +0200 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> Message-ID: The issue with the vtkScatterPlotMatrix class is interesting. The ivar being reported as a duplicate is not, in fact, a duplicate: both the parent class vtkChartMatrix and the child vtkScatterPlotMatrix define an internal class named PIMPL. And the ivar "Private" is an instance of that class. I was not aware of the use of private implementations that PIMPL represents within the VTK context. Now, I could rename the child class' PIMPL class or its instance. I'd like to have some advice on this. Renaming the parents' does not seem a better idea. BTW, I'm interested in knowing about the (need of/convenience) PIMPL classes. Is the use of such PIMPL classes documented somewhere? Thanks, JON HAITZ -- ---------- Forwarded message ---------- From: Jon Haitz Legarreta Date: 5 May 2017 at 16:30 Subject: Re: [vtk-developers] help with cppcheck duplInheritedMember warnings To: Sean McBride Cc: VTK Developers You're welcome. I'll adopt the vtkPlotSurface, vtkScatterPlotMatrix, and vtkBiDimensionalRepresentation2D (there was a member in this last that escaped my patch set) class issues. JON HAITZ -- On 5 May 2017 at 16:09, Sean McBride wrote: > On Wed, 3 May 2017 09:25:09 -0600, David Gobbi said: > > >I don't think suppressing them is a good idea, redefined member variables > >are strongly indicative of real bugs. > > Thanks David & Jon! We are down to 10 now: > > Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines > member variable with name 'Colors' also defined in its parent class > 'vtkPlot3D'. > > Charts/Core/vtkChartMatrix.h:155: warning: The class > 'vtkScatterPlotMatrix' defines member variable with name 'Private' also > defined in its parent class 'vtkChartMatrix'. > > Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class > 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also > defined in its parent class 'vtkGenericCellTessellator'. > > Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: > The class 'vtkCompositeDataPipeline' defines member variable with name > 'UpdateExtentRequest' also defined in its parent class > 'vtkStreamingDemandDrivenPipeline'. > > IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class > 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also > defined in its parent class 'vtkTableToDatabaseWriter'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'Modifier' also defined in its parent class > 'vtkBiDimensionalRepresentation'. > > Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class > 'vtkHardwareSelectionPolyDataPainter' defines member variable with name > 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. > > Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class > 'vtkXRenderWindowTclInteractor' defines member variable with name > 'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. > > Views/Infovis/vtkRenderView.h:289: warning: The class > 'vtkGraphLayoutView' defines member variable with name 'Interacting' also > defined in its parent class 'vtkRenderView'. > > Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class > 'vtkRenderedTreeAreaRepresentation' defines member variable with name > 'Implementation' also defined in its parent class > 'vtkRenderedRepresentation'. > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foufara at yahoo.fr Sat May 6 04:05:52 2017 From: foufara at yahoo.fr (foufara) Date: Sat, 6 May 2017 01:05:52 -0700 (MST) Subject: [vtk-developers] =?utf-8?q?Is_vtkprobefilter_working_correctly_?= =?utf-8?q?=3F_Here_is_an_example_to_test=E2=80=A6?= Message-ID: <1494057952312-5743104.post@n5.nabble.com> Hi VTK devs ! First thing first, thank you for this amazing tool I'm using every day. :-) For quite a long time I've been wondering if vtkprobefilter is working correctly in every case. Here an example with an extraction of a 3D mesh that I want to probe with 2 points. vtkprobefilter works on one of these points only. I read in detail the source code of vtkprobefilter and tried to reproduce it in python without calling the filter itself but every object and method it uses. But I don't get the same results ! On point 0, vtkprobefilter fails but I find a cell on the 12th walk On point 1, vtkprobefilter does find a cell, but I don't, unless I go until the 27th walk Normaly 12 is the max number of walks in vtk (hard coded). Can it change from one installation to another ? (I used pip) So I really don't understand why I don't get the same results ? Besides, even when it or I find a cell, you'll notice that the point in not necessarily in the cell per se because of the warp aspect of the cell. But let's say it does not matter for now (although if you know ho to find the cell that really contains the point, please tell me !) Here is a link to my data (.vtk file, very light) and a python script which compares both methods. The script outputs several data to vtk files that you can open in paraview. Everything should be straightforward to understand. https://drive.google.com/open?id=0B2Fplxt079XmenF5b1FGemg4VW8 Please can anyone have a look at it and help me understand what's wrong ? If I'm not clear please tell me ! Thank you ! Rapha?l -- View this message in context: http://vtk.1045678.n5.nabble.com/Is-vtkprobefilter-working-correctly-Here-is-an-example-to-test-tp5743104.html Sent from the VTK - Dev mailing list archive at Nabble.com. From foufara at yahoo.fr Sat May 6 12:59:43 2017 From: foufara at yahoo.fr (foufara) Date: Sat, 6 May 2017 09:59:43 -0700 (MST) Subject: [vtk-developers] =?utf-8?q?Is_vtkprobefilter_working_correctly_?= =?utf-8?q?=3F_Here_is_an_example_to_test=E2=80=A6?= In-Reply-To: <1494057952312-5743104.post@n5.nabble.com> References: <1494057952312-5743104.post@n5.nabble.com> Message-ID: <1494089983256-5743106.post@n5.nabble.com> H again, I updated the script I was talking about in my last post with a test with vtkcelllocator. vtkcelllocator works fine on this example. But that somehow surprises me since it seems to me that my "homemade vtkprobefilter" version does exactly the same thing : - a call vtkPointLocator to locate the closest point - a call to data.GetPointCells to get all the cells using that point - and then visiting these cells and their neighbors and calling evaluateposition each time to determine if my point lies inside the cell or to identify the best neighbor to visit. with a maximum walk number of 12. So why would my version not give the same results ? And why would vtkprobefilter fail in the first place ? (if I'm right, vtkprobefilter is essentially a wrapper around the same operations?) Thank you in advance for your help ! -- View this message in context: http://vtk.1045678.n5.nabble.com/Is-vtkprobefilter-working-correctly-Here-is-an-example-to-test-tp5743104p5743106.html Sent from the VTK - Dev mailing list archive at Nabble.com. From bill.lorensen at gmail.com Sun May 7 15:55:05 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 7 May 2017 15:55:05 -0400 Subject: [vtk-developers] Gitlab Wikii Examples Progress Message-ID: Folks, I have converted most files and associated pages. See: https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home SHOW STOPPER: The wiki page is not visible to google. I think I need to create a static html page. I don't think that is a good solution. Bill From elvis.stansvik at orexplore.com Mon May 8 02:44:11 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 8 May 2017 08:44:11 +0200 Subject: [vtk-developers] Gitlab Wikii Examples Progress In-Reply-To: References: Message-ID: Den 7 maj 2017 9:55 em skrev "Bill Lorensen" : > > Folks, > > I have converted most files and associated pages. > See: https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home > > SHOW STOPPER: The wiki page is not visible to google. I think I need > to create a static html page. I don't think that is a good solution. Great work to all of you for doing all this work with the examples, it looks very good. One thing I noticed while on the bus though is that the example image pushes the example code to the side when viewing on a mobile device (Xperia Z5 Compact in my case). See attached screenshot. Perhaps some web guru could have a look if something can be done? On mobile it's probably a good idea to have the image above the content. Cheers, Elvis > > Bill > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20170508-083944.png Type: image/png Size: 86131 bytes Desc: not available URL: From paul at 3dimageautomation.com.au Mon May 8 07:25:38 2017 From: paul at 3dimageautomation.com.au (Paul) Date: Mon, 8 May 2017 11:25:38 +0000 Subject: [vtk-developers] Rendering Corruption Due to PC Time Change Message-ID: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> Hi, We are using VTK in a 3D LiDAR based mining automation application which operates continuously. VTK in medical application is great but VTK controlling the world's largest autonomous machine is interesting for engineering types. If anyone is interested we can post some screenshots. Many of the vtk developers will remember the vtk code impact of our original issue with overflow of ModifiedTime on a Win64 build. Thanks again for the effort, it was certainly a relief as it was so critical for our application success. Subsequent to the overflow fix the application has been running without issues on two system equipped with dual Xeon processors. However one system with a four core i7 was having rendering issues at intervals of a week or more. Our initial thoughts was that the issue was related to high processor loading. It turns out that the issue is related to ModifiedTime. Rendering breaks if the PC time is changed in a negative direction. It took us some time to discover this. The i7 system is running Windows 7 and the Windows Time service was in the Scheduled Tasks to run once a week on Sunday morning. Vtk rendering only breaks if the time synchronisation has a negative correction. This can be reproduced by manually changing the PC time backwards. Q. Could this be resolved by making ModifiedTime independent of the PC clock. We run a PLC (real time automation controller) in kernel mode on the same platform. PLC's are used in time critical applications such as motion synchronisation and use a SystemTime that does not jump. I am not sure what mechanism the PLC uses but suspect that the time is initialised to the PC time on application start and then incremented at 100nS intervals (the timer resolution). Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon May 8 07:44:42 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 8 May 2017 07:44:42 -0400 Subject: [vtk-developers] Rendering Corruption Due to PC Time Change In-Reply-To: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> References: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> Message-ID: I love this bug! The more the esoteric bugs we have time to chase, my obviously biased conclusion is that the better the quality of VTK's core functionality is :-) I would enjoy seeing screenshots. I assume they would be public and we would be able to use them elsewhere? Of course with appropriate credit... Best, W On Mon, May 8, 2017 at 7:25 AM, Paul wrote: > Hi, > > We are using VTK in a 3D LiDAR based mining automation application which > operates continuously. > > VTK in medical application is great but VTK controlling the world?s > largest autonomous machine is interesting for engineering types. > > If anyone is interested we can post some screenshots. > > > > Many of the vtk developers will remember the vtk code impact of our > original issue with overflow of ModifiedTime on a Win64 build. > > Thanks again for the effort, it was certainly a relief as it was so > critical for our application success. > > > > Subsequent to the overflow fix the application has been running without > issues on two system equipped with dual Xeon processors. > > However one system with a four core i7 was having rendering issues at > intervals of a week or more. > > Our initial thoughts was that the issue was related to high processor > loading. > > > > It turns out that the issue is related to ModifiedTime. > > Rendering breaks if the PC time is changed in a negative direction. > > > > It took us some time to discover this. > > The i7 system is running Windows 7 and the Windows Time service was in the > Scheduled Tasks to run once a week on Sunday morning. > > Vtk rendering only breaks if the time synchronisation has a negative > correction. > > This can be reproduced by manually changing the PC time backwards. > > > > > > Q. Could this be resolved by making ModifiedTime independent of the PC > clock. > > We run a PLC (real time automation controller) in kernel mode on the same > platform. > > PLC?s are used in time critical applications such as motion > synchronisation and use a SystemTime that does not jump. > > I am not sure what mechanism the PLC uses but suspect that the time is > initialised to the PC time on application start and then incremented at > 100nS intervals (the timer resolution). > > > > Paul > > _______________________________________________ > 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: > http://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 ben.boeckel at kitware.com Mon May 8 08:48:48 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 8 May 2017 08:48:48 -0400 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> Message-ID: <20170508124848.GA6189@megas.kitware.com> On Fri, May 05, 2017 at 18:31:53 +0200, Jon Haitz Legarreta wrote: > The ivar being reported as a duplicate is not, in fact, a duplicate: both > the parent class vtkChartMatrix and the child vtkScatterPlotMatrix define > an internal class named PIMPL. And the ivar "Private" is an instance of > that class. vtkChartMatrix is doing PIMPL wrong. It is `protected`, not `private`. I think that is likely the proper fix. > I was not aware of the use of private implementations that PIMPL represents > within the VTK context. Usually, I've seen `Internal` instead declared outside of the class itself, but these are usually `protected` so that subclasses can use them. If `vtkChartMatrix::Private` has this intended use, it should follow that pattern instead. > BTW, I'm interested in knowing about the (need of/convenience) PIMPL > classes. Is the use of such PIMPL classes documented somewhere? In VTK? I don't think so. The idea is to hide the amount of data necessary for completely internal data collection out of the header and affecting `sizeof(class)` (an ABI break) or exposing too much (prone to breaking API because users of the class rely on the wrong things). The Wiki page is useful: https://en.wikipedia.org/wiki/Opaque_pointer --Ben From ben.boeckel at kitware.com Mon May 8 08:56:50 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 8 May 2017 08:56:50 -0400 Subject: [vtk-developers] Gitlab Wikii Examples Progress In-Reply-To: References: Message-ID: <20170508125650.GC6189@megas.kitware.com> On Sun, May 07, 2017 at 15:55:05 -0400, Bill Lorensen wrote: > SHOW STOPPER: The wiki page is not visible to google. I think I need > to create a static html page. I don't think that is a good solution. Has Google just not indexed it or is there something preventing the indexer access? --Ben From bill.lorensen at gmail.com Mon May 8 09:00:50 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 8 May 2017 09:00:50 -0400 Subject: [vtk-developers] Gitlab Wikii Examples Progress In-Reply-To: <20170508125650.GC6189@megas.kitware.com> References: <20170508125650.GC6189@megas.kitware.com> Message-ID: I'm not sure why Google doesn't index. The gitlab site talks about dynamic vs static web pages. The gitlab wiki is dynamic. On May 8, 2017 8:56 AM, "Ben Boeckel" wrote: > On Sun, May 07, 2017 at 15:55:05 -0400, Bill Lorensen wrote: > > SHOW STOPPER: The wiki page is not visible to google. I think I need > > to create a static html page. I don't think that is a good solution. > > Has Google just not indexed it or is there something preventing the > indexer access? > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon May 8 10:07:08 2017 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 8 May 2017 10:07:08 -0400 Subject: [vtk-developers] Rendering Corruption Due to PC Time Change In-Reply-To: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> References: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> Message-ID: I think Modified time is independent of the clock. I believe it is a 64bit integer that starts at zero and goes up by one each time something is modified by VTK. So maybe something else is going on here... On Mon, May 8, 2017 at 7:25 AM, Paul wrote: > Hi, > > We are using VTK in a 3D LiDAR based mining automation application which > operates continuously. > > VTK in medical application is great but VTK controlling the world?s > largest autonomous machine is interesting for engineering types. > > If anyone is interested we can post some screenshots. > > > > Many of the vtk developers will remember the vtk code impact of our > original issue with overflow of ModifiedTime on a Win64 build. > > Thanks again for the effort, it was certainly a relief as it was so > critical for our application success. > > > > Subsequent to the overflow fix the application has been running without > issues on two system equipped with dual Xeon processors. > > However one system with a four core i7 was having rendering issues at > intervals of a week or more. > > Our initial thoughts was that the issue was related to high processor > loading. > > > > It turns out that the issue is related to ModifiedTime. > > Rendering breaks if the PC time is changed in a negative direction. > > > > It took us some time to discover this. > > The i7 system is running Windows 7 and the Windows Time service was in the > Scheduled Tasks to run once a week on Sunday morning. > > Vtk rendering only breaks if the time synchronisation has a negative > correction. > > This can be reproduced by manually changing the PC time backwards. > > > > > > Q. Could this be resolved by making ModifiedTime independent of the PC > clock. > > We run a PLC (real time automation controller) in kernel mode on the same > platform. > > PLC?s are used in time critical applications such as motion > synchronisation and use a SystemTime that does not jump. > > I am not sure what mechanism the PLC uses but suspect that the time is > initialised to the PC time on application start and then incremented at > 100nS intervals (the timer resolution). > > > > Paul > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 paul at 3dimageautomation.com.au Mon May 8 10:34:19 2017 From: paul at 3dimageautomation.com.au (Paul) Date: Mon, 8 May 2017 14:34:19 +0000 Subject: [vtk-developers] Rendering Corruption Due to PC Time Change In-Reply-To: References: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> Message-ID: <148831bc1a77452f9d64cb159fc4c088@IHM-PORT-E13M03.prdhosting.local> Hi, We will check again and create a standalone test app if it is confirmed. Thanks, Paul From: Ken Martin [mailto:ken.martin at kitware.com] Sent: Monday, 8 May, 2017 22:07 To: Paul Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] Rendering Corruption Due to PC Time Change I think Modified time is independent of the clock. I believe it is a 64bit integer that starts at zero and goes up by one each time something is modified by VTK. So maybe something else is going on here... On Mon, May 8, 2017 at 7:25 AM, Paul > wrote: Hi, We are using VTK in a 3D LiDAR based mining automation application which operates continuously. VTK in medical application is great but VTK controlling the world?s largest autonomous machine is interesting for engineering types. If anyone is interested we can post some screenshots. Many of the vtk developers will remember the vtk code impact of our original issue with overflow of ModifiedTime on a Win64 build. Thanks again for the effort, it was certainly a relief as it was so critical for our application success. Subsequent to the overflow fix the application has been running without issues on two system equipped with dual Xeon processors. However one system with a four core i7 was having rendering issues at intervals of a week or more. Our initial thoughts was that the issue was related to high processor loading. It turns out that the issue is related to ModifiedTime. Rendering breaks if the PC time is changed in a negative direction. It took us some time to discover this. The i7 system is running Windows 7 and the Windows Time service was in the Scheduled Tasks to run once a week on Sunday morning. Vtk rendering only breaks if the time synchronisation has a negative correction. This can be reproduced by manually changing the PC time backwards. Q. Could this be resolved by making ModifiedTime independent of the PC clock. We run a PLC (real time automation controller) in kernel mode on the same platform. PLC?s are used in time critical applications such as motion synchronisation and use a SystemTime that does not jump. I am not sure what mechanism the PLC uses but suspect that the time is initialised to the PC time on application start and then incremented at 100nS intervals (the timer resolution). Paul _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 elvis.stansvik at orexplore.com Mon May 8 12:25:06 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 8 May 2017 18:25:06 +0200 Subject: [vtk-developers] Rendering Corruption Due to PC Time Change In-Reply-To: References: <19bfd0424ce3499d9deb9f0230dab5c3@IHM-PORT-E13M03.prdhosting.local> Message-ID: Den 8 maj 2017 1:45 em skrev "Will Schroeder" : > > I love this bug! The more the esoteric bugs we have time to chase, my obviously biased conclusion is that the better the quality of VTK's core functionality is :-) > > I would enjoy seeing screenshots. I assume they would be public and we would be able to use them elsewhere? Of course with appropriate credit... I second that. Would love to see what you're up to. We're using VTK for visualisation of the result coming from our xray based drill core scanner, so sort of in the mining field as well. Though obviously our machine is puny compared to yours :) Elvis > > Best, > W > > On Mon, May 8, 2017 at 7:25 AM, Paul wrote: >> >> Hi, >> >> We are using VTK in a 3D LiDAR based mining automation application which operates continuously. >> >> VTK in medical application is great but VTK controlling the world?s largest autonomous machine is interesting for engineering types. >> >> If anyone is interested we can post some screenshots. >> >> >> >> Many of the vtk developers will remember the vtk code impact of our original issue with overflow of ModifiedTime on a Win64 build. >> >> Thanks again for the effort, it was certainly a relief as it was so critical for our application success. >> >> >> >> Subsequent to the overflow fix the application has been running without issues on two system equipped with dual Xeon processors. >> >> However one system with a four core i7 was having rendering issues at intervals of a week or more. >> >> Our initial thoughts was that the issue was related to high processor loading. >> >> >> >> It turns out that the issue is related to ModifiedTime. >> >> Rendering breaks if the PC time is changed in a negative direction. >> >> >> >> It took us some time to discover this. >> >> The i7 system is running Windows 7 and the Windows Time service was in the Scheduled Tasks to run once a week on Sunday morning. >> >> Vtk rendering only breaks if the time synchronisation has a negative correction. >> >> This can be reproduced by manually changing the PC time backwards. >> >> >> >> >> >> Q. Could this be resolved by making ModifiedTime independent of the PC clock. >> >> We run a PLC (real time automation controller) in kernel mode on the same platform. >> >> PLC?s are used in time critical applications such as motion synchronisation and use a SystemTime that does not jump. >> >> I am not sure what mechanism the PLC uses but suspect that the time is initialised to the PC time on application start and then incremented at 100nS intervals (the timer resolution). >> >> >> >> Paul >> >> >> _______________________________________________ >> 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: >> http://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 > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sur.chiranjib at gmail.com Mon May 8 13:50:23 2017 From: sur.chiranjib at gmail.com (Chiranjib Sur) Date: Mon, 8 May 2017 23:20:23 +0530 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: This is fantastic effort and looks very impressive and consolidated. I learnt (and still learning) developing applications using VTK classes by writing my own examples and tests. Some of themI can contribute to the wiki (which are obvious but I had a hard time to figure those out through my interaction over the mailing list). How can I contribute and share my experiences in this wiki format? Thanks in advance, Chiranjib On Thu, May 4, 2017 at 11:24 AM, Andrew Maclean wrote: > Hi Bill, > > If you need to test the descriptions, this one: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/NamedColorPatches > has a lot of html links in the description. It also references the python > version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visualization/ > NamedColorPatches > > Regards > Andrew > > On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean > wrote: > >> Hi Bill, >> >> That looks really great. >> >> Thanks >> Andrew >> >> On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen >> wrote: >> >>> Yes I have a way to include the descriptions. Now I need to get the old >>> ones automatically. I'm working on a script for that. >>> For example I did one of yours manually >>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Vi >>> sualization/ElevationBandsWithGlyphs >>> >>> On May 3, 2017 6:56 PM, "Andrew Maclean" >>> wrote: >>> >>>> Hi Bill, >>>> I just looked at it and it is not too bad. >>>> >>>> Like you I don't like the automatic conversion of camel case e.g >>>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>>> certainly doesn't add to readability. >>>> >>>> I don't mind the file list on the right-hand side, I think it is useful. >>>> >>>> One big thing missing is the description, will you be able to >>>> automatically grab this too? I think it is important as it provides >>>> rationale and background to the examples. >>>> >>>> Thinking further along, how easy will it be to add new examples or >>>> update existing ones? >>>> >>>> Regards >>>> Andrew >>>> >>>> >>>> >>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Bill Lorensen >>>>> To: Aron Helser >>>>> Cc: VTK Developers , Will Schroeder < >>>>> will.schroeder at kitware.com> >>>>> Bcc: >>>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>>> Gitlab examples wiki >>>>> Aron, >>>>> >>>>> That is pretty cool. I think we can do some kind of image gallery to >>>>> navigate the examples. >>>>> >>>>> Bill >>>>> >>>>> >>>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >>>>> wrote: >>>>> >>>>>> The automatically generated list of examples is looking quite good - >>>>>> the clean look of the wiki suits the content well, I think. >>>>>> >>>>>> I pointed out two examples of an image gallery I liked during the >>>>>> hackathon - First https://d3js.org/, which has a hand-picked gallery >>>>>> of examples as the banner "image" explaining what d3.js is. >>>>>> The second and more applicable example was https://bl.ocks.org/mbosto >>>>>> ck, or https://bl.ocks.org/ which is an automatically generated >>>>>> gallery of all examples (possibly filtered to those written by the author >>>>>> of d3). Once you click an example, it is interactive, because they are all >>>>>> done in javascript. >>>>>> >>>>>> Anyone can contribute to bl.ocks.org, and each example is backed by >>>>>> a github 'gist', like https://gist.github.com/mbostock/4063269 >>>>>> This setup makes it very easy to work with single examples, and fork >>>>>> them to make your own versions. >>>>>> >>>>>> I don't propose that this is the right approach for VTK, but for >>>>>> ideas or inspiration. >>>>>> Thanks, >>>>>> Aron >>>>>> >>>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>>> bill.lorensen at gmail.com> wrote: >>>>>> >>>>>>> Jon, >>>>>>> >>>>>>> Thanks for the feedback. All of the pages on the wiki are generated >>>>>>> from the repo. I think I can generate a gallery of images. Still some >>>>>>> cleanup before I get to that. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>>> >>>>>>>> Nice job Bill. Thanks. >>>>>>>> >>>>>>>> Despite the limitations you have identified, I think transitioning >>>>>>>> to gitlab makes it easier for people to use the examples resource, and >>>>>>>> also, easier to maintain the VTK eco-system. >>>>>>>> >>>>>>>> The yet-to-come steps to add an example will also be a nice >>>>>>>> addition. >>>>>>>> >>>>>>>> IMHO, the right pane could be helpful if it were a true index of >>>>>>>> the sections so that one could easily switch between them without scrolling >>>>>>>> back to the top of the page, and if it could be collapsed. >>>>>>>> >>>>>>>> I think this is a step yet too distant, but having an image gallery >>>>>>>> instead of (or in addition to) a list would be helpful for such cases in >>>>>>>> which the person seeks by a visualization rather than by the filter name. >>>>>>>> It may happen that we have difficulties in identifying the right name/class >>>>>>>> in the class index. I think someone pointed an example during the >>>>>>>> hackathon, but as pointed then, the wiki is not well adapted to that. >>>>>>>> >>>>>>>> May be sharing that could be useful in case someone has a better >>>>>>>> idea, or else just for the records. >>>>>>>> >>>>>>>> JON HAITZ >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>>>>> >>>>>>>>> Very nice. Well done. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>>>> Behalf Of *Will Schroeder >>>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>>> *To:* Bill Lorensen >>>>>>>>> *Cc:* VTK Developers >>>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>>>>>> Gitlab examples wiki >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I am pretty impressed! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The file list doesn't bother me all that much. I'm not sure how to >>>>>>>>> address the other issues you list. I agree the Camel case problem is >>>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Great work, >>>>>>>>> >>>>>>>>> W >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> Time to kick the tires. >>>>>>>>> >>>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>>> >>>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>>> >>>>>>>>> The wiki pages are automatically created from the gitlab repo >>>>>>>>> pages. >>>>>>>>> >>>>>>>>> Need feedback before proceeding. >>>>>>>>> >>>>>>>>> Things I don't like: >>>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>>>> letter. >>>>>>>>> >>>>>>>>> markdown formatting is very limited. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> _______________________________________________ >>>>>>>>> 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: >>>>>>>>> http://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 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Unpaid intern in BillsBasement at noware dot com >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>> >>>> >>>> >>>> -- >>>> ___________________________________________ >>>> Andrew J. P. Maclean >>>> >>>> ___________________________________________ >>>> >>> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon May 8 14:18:46 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 8 May 2017 14:18:46 -0400 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Chiranjib, If you want to be an alpha tester, try to follow the instructions for developers here: https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Instructions/ForDevelopers The documentation is fresh out of the oven (still warm) and it would be great to see if it makes sense. Andrew, It would be great if you could kick the tires on the developer contributions. Bill On Mon, May 8, 2017 at 1:50 PM, Chiranjib Sur wrote: > This is fantastic effort and looks very impressive and consolidated. > I learnt (and still learning) developing applications using VTK classes by > writing my own examples and tests. Some of themI can contribute to the wiki > (which are obvious but I had a hard time to figure those out through my > interaction over the mailing list). How can I contribute and share my > experiences in this wiki format? > > Thanks in advance, > Chiranjib > > On Thu, May 4, 2017 at 11:24 AM, Andrew Maclean > wrote: > >> Hi Bill, >> >> If you need to test the descriptions, this one: >> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/NamedColorPatches >> has a lot of html links in the description. It also references the python >> version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visuali >> zation/NamedColorPatches >> >> Regards >> Andrew >> >> On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean > > wrote: >> >>> Hi Bill, >>> >>> That looks really great. >>> >>> Thanks >>> Andrew >>> >>> On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen >>> wrote: >>> >>>> Yes I have a way to include the descriptions. Now I need to get the old >>>> ones automatically. I'm working on a script for that. >>>> For example I did one of yours manually >>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Vi >>>> sualization/ElevationBandsWithGlyphs >>>> >>>> On May 3, 2017 6:56 PM, "Andrew Maclean" >>>> wrote: >>>> >>>>> Hi Bill, >>>>> I just looked at it and it is not too bad. >>>>> >>>>> Like you I don't like the automatic conversion of camel case e.g >>>>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>>>> certainly doesn't add to readability. >>>>> >>>>> I don't mind the file list on the right-hand side, I think it is >>>>> useful. >>>>> >>>>> One big thing missing is the description, will you be able to >>>>> automatically grab this too? I think it is important as it provides >>>>> rationale and background to the examples. >>>>> >>>>> Thinking further along, how easy will it be to add new examples or >>>>> update existing ones? >>>>> >>>>> Regards >>>>> Andrew >>>>> >>>>> >>>>> >>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Bill Lorensen >>>>>> To: Aron Helser >>>>>> Cc: VTK Developers , Will Schroeder < >>>>>> will.schroeder at kitware.com> >>>>>> Bcc: >>>>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>>>> Gitlab examples wiki >>>>>> Aron, >>>>>> >>>>>> That is pretty cool. I think we can do some kind of image gallery to >>>>>> navigate the examples. >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >>>>>> wrote: >>>>>> >>>>>>> The automatically generated list of examples is looking quite good - >>>>>>> the clean look of the wiki suits the content well, I think. >>>>>>> >>>>>>> I pointed out two examples of an image gallery I liked during the >>>>>>> hackathon - First https://d3js.org/, which has a hand-picked >>>>>>> gallery of examples as the banner "image" explaining what d3.js is. >>>>>>> The second and more applicable example was >>>>>>> https://bl.ocks.org/mbostock, or https://bl.ocks.org/ which is an >>>>>>> automatically generated gallery of all examples (possibly filtered to those >>>>>>> written by the author of d3). Once you click an example, it is >>>>>>> interactive, because they are all done in javascript. >>>>>>> >>>>>>> Anyone can contribute to bl.ocks.org, and each example is backed by >>>>>>> a github 'gist', like https://gist.github.com/mbostock/4063269 >>>>>>> This setup makes it very easy to work with single examples, and fork >>>>>>> them to make your own versions. >>>>>>> >>>>>>> I don't propose that this is the right approach for VTK, but for >>>>>>> ideas or inspiration. >>>>>>> Thanks, >>>>>>> Aron >>>>>>> >>>>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>> >>>>>>>> Jon, >>>>>>>> >>>>>>>> Thanks for the feedback. All of the pages on the wiki are generated >>>>>>>> from the repo. I think I can generate a gallery of images. Still some >>>>>>>> cleanup before I get to that. >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>>>> >>>>>>>>> Nice job Bill. Thanks. >>>>>>>>> >>>>>>>>> Despite the limitations you have identified, I think transitioning >>>>>>>>> to gitlab makes it easier for people to use the examples resource, and >>>>>>>>> also, easier to maintain the VTK eco-system. >>>>>>>>> >>>>>>>>> The yet-to-come steps to add an example will also be a nice >>>>>>>>> addition. >>>>>>>>> >>>>>>>>> IMHO, the right pane could be helpful if it were a true index of >>>>>>>>> the sections so that one could easily switch between them without scrolling >>>>>>>>> back to the top of the page, and if it could be collapsed. >>>>>>>>> >>>>>>>>> I think this is a step yet too distant, but having an image >>>>>>>>> gallery instead of (or in addition to) a list would be helpful for such >>>>>>>>> cases in which the person seeks by a visualization rather than by the >>>>>>>>> filter name. It may happen that we have difficulties in identifying the >>>>>>>>> right name/class in the class index. I think someone pointed an example >>>>>>>>> during the hackathon, but as pointed then, the wiki is not well adapted to >>>>>>>>> that. >>>>>>>>> >>>>>>>>> May be sharing that could be useful in case someone has a better >>>>>>>>> idea, or else just for the records. >>>>>>>>> >>>>>>>>> JON HAITZ >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>>>>>> >>>>>>>>>> Very nice. Well done. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>>>>> Behalf Of *Will Schroeder >>>>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>>>> *To:* Bill Lorensen >>>>>>>>>> *Cc:* VTK Developers >>>>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for feedback: >>>>>>>>>> Gitlab examples wiki >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am pretty impressed! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The file list doesn't bother me all that much. I'm not sure how >>>>>>>>>> to address the other issues you list. I agree the Camel case problem is >>>>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Great work, >>>>>>>>>> >>>>>>>>>> W >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Folks, >>>>>>>>>> >>>>>>>>>> Time to kick the tires. >>>>>>>>>> >>>>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>>>> >>>>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>>>> >>>>>>>>>> The wiki pages are automatically created from the gitlab repo >>>>>>>>>> pages. >>>>>>>>>> >>>>>>>>>> Need feedback before proceeding. >>>>>>>>>> >>>>>>>>>> Things I don't like: >>>>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>>>>> letter. >>>>>>>>>> >>>>>>>>>> markdown formatting is very limited. >>>>>>>>>> >>>>>>>>>> Bill >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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: >>>>>>>>>> http://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 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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: >>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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: >>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>> >>>>>> _______________________________________________ >>>>>> 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: >>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ___________________________________________ >>>>> Andrew J. P. Maclean >>>>> >>>>> ___________________________________________ >>>>> >>>> >>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >>> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sur.chiranjib at gmail.com Mon May 8 14:32:24 2017 From: sur.chiranjib at gmail.com (Chiranjib Sur) Date: Tue, 9 May 2017 00:02:24 +0530 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Hi Bill and Andrew, Thank you very much for the reply. Yes, I want to volunteer and will start contributing/testing. Although, until May 20th I am bit irregular with my travel. Thanks, Chiranjib On Mon, May 8, 2017 at 11:48 PM, Bill Lorensen wrote: > Chiranjib, > > If you want to be an alpha tester, try to follow the instructions for > developers here: > > https://gitlab.kitware.com/lorensen/VTKExamples/wikis/ > Instructions/ForDevelopers > > The documentation is fresh out of the oven (still warm) and it would be > great to see if it makes sense. > > Andrew, > > It would be great if you could kick the tires on the developer > contributions. > > Bill > > > On Mon, May 8, 2017 at 1:50 PM, Chiranjib Sur > wrote: > >> This is fantastic effort and looks very impressive and consolidated. >> I learnt (and still learning) developing applications using VTK classes >> by writing my own examples and tests. Some of themI can contribute to the >> wiki (which are obvious but I had a hard time to figure those out through >> my interaction over the mailing list). How can I contribute and share my >> experiences in this wiki format? >> >> Thanks in advance, >> Chiranjib >> >> On Thu, May 4, 2017 at 11:24 AM, Andrew Maclean < >> andrew.amaclean at gmail.com> wrote: >> >>> Hi Bill, >>> >>> If you need to test the descriptions, this one: >>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/NamedColorPatches >>> has a lot of html links in the description. It also references the >>> python version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visuali >>> zation/NamedColorPatches >>> >>> Regards >>> Andrew >>> >>> On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean < >>> andrew.amaclean at gmail.com> wrote: >>> >>>> Hi Bill, >>>> >>>> That looks really great. >>>> >>>> Thanks >>>> Andrew >>>> >>>> On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen >>>> wrote: >>>> >>>>> Yes I have a way to include the descriptions. Now I need to get the >>>>> old ones automatically. I'm working on a script for that. >>>>> For example I did one of yours manually >>>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Vi >>>>> sualization/ElevationBandsWithGlyphs >>>>> >>>>> On May 3, 2017 6:56 PM, "Andrew Maclean" >>>>> wrote: >>>>> >>>>>> Hi Bill, >>>>>> I just looked at it and it is not too bad. >>>>>> >>>>>> Like you I don't like the automatic conversion of camel case e.g >>>>>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>>>>> certainly doesn't add to readability. >>>>>> >>>>>> I don't mind the file list on the right-hand side, I think it is >>>>>> useful. >>>>>> >>>>>> One big thing missing is the description, will you be able to >>>>>> automatically grab this too? I think it is important as it provides >>>>>> rationale and background to the examples. >>>>>> >>>>>> Thinking further along, how easy will it be to add new examples or >>>>>> update existing ones? >>>>>> >>>>>> Regards >>>>>> Andrew >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Bill Lorensen >>>>>>> To: Aron Helser >>>>>>> Cc: VTK Developers , Will Schroeder < >>>>>>> will.schroeder at kitware.com> >>>>>>> Bcc: >>>>>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>>>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>>>>> Gitlab examples wiki >>>>>>> Aron, >>>>>>> >>>>>>> That is pretty cool. I think we can do some kind of image gallery to >>>>>>> navigate the examples. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >>>>>> > wrote: >>>>>>> >>>>>>>> The automatically generated list of examples is looking quite good >>>>>>>> - the clean look of the wiki suits the content well, I think. >>>>>>>> >>>>>>>> I pointed out two examples of an image gallery I liked during the >>>>>>>> hackathon - First https://d3js.org/, which has a hand-picked >>>>>>>> gallery of examples as the banner "image" explaining what d3.js is. >>>>>>>> The second and more applicable example was >>>>>>>> https://bl.ocks.org/mbostock, or https://bl.ocks.org/ which is an >>>>>>>> automatically generated gallery of all examples (possibly filtered to those >>>>>>>> written by the author of d3). Once you click an example, it is >>>>>>>> interactive, because they are all done in javascript. >>>>>>>> >>>>>>>> Anyone can contribute to bl.ocks.org, and each example is backed >>>>>>>> by a github 'gist', like https://gist.github.com/mbostock/4063269 >>>>>>>> This setup makes it very easy to work with single examples, and >>>>>>>> fork them to make your own versions. >>>>>>>> >>>>>>>> I don't propose that this is the right approach for VTK, but for >>>>>>>> ideas or inspiration. >>>>>>>> Thanks, >>>>>>>> Aron >>>>>>>> >>>>>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>> >>>>>>>>> Jon, >>>>>>>>> >>>>>>>>> Thanks for the feedback. All of the pages on the wiki are >>>>>>>>> generated from the repo. I think I can generate a gallery of images. Still >>>>>>>>> some cleanup before I get to that. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>>>>> >>>>>>>>>> Nice job Bill. Thanks. >>>>>>>>>> >>>>>>>>>> Despite the limitations you have identified, I think >>>>>>>>>> transitioning to gitlab makes it easier for people to use the examples >>>>>>>>>> resource, and also, easier to maintain the VTK eco-system. >>>>>>>>>> >>>>>>>>>> The yet-to-come steps to add an example will also be a nice >>>>>>>>>> addition. >>>>>>>>>> >>>>>>>>>> IMHO, the right pane could be helpful if it were a true index of >>>>>>>>>> the sections so that one could easily switch between them without scrolling >>>>>>>>>> back to the top of the page, and if it could be collapsed. >>>>>>>>>> >>>>>>>>>> I think this is a step yet too distant, but having an image >>>>>>>>>> gallery instead of (or in addition to) a list would be helpful for such >>>>>>>>>> cases in which the person seeks by a visualization rather than by the >>>>>>>>>> filter name. It may happen that we have difficulties in identifying the >>>>>>>>>> right name/class in the class index. I think someone pointed an example >>>>>>>>>> during the hackathon, but as pointed then, the wiki is not well adapted to >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> May be sharing that could be useful in case someone has a better >>>>>>>>>> idea, or else just for the records. >>>>>>>>>> >>>>>>>>>> JON HAITZ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>>>>>>> >>>>>>>>>>> Very nice. Well done. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>>>>>> Behalf Of *Will Schroeder >>>>>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>>>>> *To:* Bill Lorensen >>>>>>>>>>> *Cc:* VTK Developers >>>>>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for >>>>>>>>>>> feedback: Gitlab examples wiki >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am pretty impressed! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The file list doesn't bother me all that much. I'm not sure how >>>>>>>>>>> to address the other issues you list. I agree the Camel case problem is >>>>>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Great work, >>>>>>>>>>> >>>>>>>>>>> W >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> Time to kick the tires. >>>>>>>>>>> >>>>>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>>>>> >>>>>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>>>>> >>>>>>>>>>> The wiki pages are automatically created from the gitlab repo >>>>>>>>>>> pages. >>>>>>>>>>> >>>>>>>>>>> Need feedback before proceeding. >>>>>>>>>>> >>>>>>>>>>> Things I don't like: >>>>>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>>>>>> letter. >>>>>>>>>>> >>>>>>>>>>> markdown formatting is very limited. >>>>>>>>>>> >>>>>>>>>>> Bill >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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: >>>>>>>>>>> http://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 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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: >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ___________________________________________ >>>>>> Andrew J. P. Maclean >>>>>> >>>>>> ___________________________________________ >>>>>> >>>>> >>>> >>>> >>>> -- >>>> ___________________________________________ >>>> Andrew J. P. Maclean >>>> >>>> ___________________________________________ >>>> >>> >>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon May 8 14:42:34 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 8 May 2017 14:42:34 -0400 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Chiranjib, Thanks. No problem. Things may be in better shape by then. Bill On Mon, May 8, 2017 at 2:32 PM, Chiranjib Sur wrote: > Hi Bill and Andrew, > Thank you very much for the reply. > > Yes, I want to volunteer and will start contributing/testing. Although, > until May 20th I am bit irregular with my travel. > > Thanks, > Chiranjib > > On Mon, May 8, 2017 at 11:48 PM, Bill Lorensen > wrote: > >> Chiranjib, >> >> If you want to be an alpha tester, try to follow the instructions for >> developers here: >> >> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Instru >> ctions/ForDevelopers >> >> The documentation is fresh out of the oven (still warm) and it would be >> great to see if it makes sense. >> >> Andrew, >> >> It would be great if you could kick the tires on the developer >> contributions. >> >> Bill >> >> >> On Mon, May 8, 2017 at 1:50 PM, Chiranjib Sur >> wrote: >> >>> This is fantastic effort and looks very impressive and consolidated. >>> I learnt (and still learning) developing applications using VTK classes >>> by writing my own examples and tests. Some of themI can contribute to the >>> wiki (which are obvious but I had a hard time to figure those out through >>> my interaction over the mailing list). How can I contribute and share my >>> experiences in this wiki format? >>> >>> Thanks in advance, >>> Chiranjib >>> >>> On Thu, May 4, 2017 at 11:24 AM, Andrew Maclean < >>> andrew.amaclean at gmail.com> wrote: >>> >>>> Hi Bill, >>>> >>>> If you need to test the descriptions, this one: >>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/Named >>>> ColorPatches >>>> has a lot of html links in the description. It also references the >>>> python version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visuali >>>> zation/NamedColorPatches >>>> >>>> Regards >>>> Andrew >>>> >>>> On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean < >>>> andrew.amaclean at gmail.com> wrote: >>>> >>>>> Hi Bill, >>>>> >>>>> That looks really great. >>>>> >>>>> Thanks >>>>> Andrew >>>>> >>>>> On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen >>>> > wrote: >>>>> >>>>>> Yes I have a way to include the descriptions. Now I need to get the >>>>>> old ones automatically. I'm working on a script for that. >>>>>> For example I did one of yours manually >>>>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Vi >>>>>> sualization/ElevationBandsWithGlyphs >>>>>> >>>>>> On May 3, 2017 6:56 PM, "Andrew Maclean" >>>>>> wrote: >>>>>> >>>>>>> Hi Bill, >>>>>>> I just looked at it and it is not too bad. >>>>>>> >>>>>>> Like you I don't like the automatic conversion of camel case e.g >>>>>>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>>>>>> certainly doesn't add to readability. >>>>>>> >>>>>>> I don't mind the file list on the right-hand side, I think it is >>>>>>> useful. >>>>>>> >>>>>>> One big thing missing is the description, will you be able to >>>>>>> automatically grab this too? I think it is important as it provides >>>>>>> rationale and background to the examples. >>>>>>> >>>>>>> Thinking further along, how easy will it be to add new examples or >>>>>>> update existing ones? >>>>>>> >>>>>>> Regards >>>>>>> Andrew >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: Bill Lorensen >>>>>>>> To: Aron Helser >>>>>>>> Cc: VTK Developers , Will Schroeder < >>>>>>>> will.schroeder at kitware.com> >>>>>>>> Bcc: >>>>>>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>>>>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>>>>>> Gitlab examples wiki >>>>>>>> Aron, >>>>>>>> >>>>>>>> That is pretty cool. I think we can do some kind of image gallery >>>>>>>> to navigate the examples. >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser < >>>>>>>> aron.helser at kitware.com> wrote: >>>>>>>> >>>>>>>>> The automatically generated list of examples is looking quite good >>>>>>>>> - the clean look of the wiki suits the content well, I think. >>>>>>>>> >>>>>>>>> I pointed out two examples of an image gallery I liked during the >>>>>>>>> hackathon - First https://d3js.org/, which has a hand-picked >>>>>>>>> gallery of examples as the banner "image" explaining what d3.js is. >>>>>>>>> The second and more applicable example was >>>>>>>>> https://bl.ocks.org/mbostock, or https://bl.ocks.org/ which is an >>>>>>>>> automatically generated gallery of all examples (possibly filtered to those >>>>>>>>> written by the author of d3). Once you click an example, it is >>>>>>>>> interactive, because they are all done in javascript. >>>>>>>>> >>>>>>>>> Anyone can contribute to bl.ocks.org, and each example is backed >>>>>>>>> by a github 'gist', like https://gist.github.com/mbostock/4063269 >>>>>>>>> This setup makes it very easy to work with single examples, and >>>>>>>>> fork them to make your own versions. >>>>>>>>> >>>>>>>>> I don't propose that this is the right approach for VTK, but for >>>>>>>>> ideas or inspiration. >>>>>>>>> Thanks, >>>>>>>>> Aron >>>>>>>>> >>>>>>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Jon, >>>>>>>>>> >>>>>>>>>> Thanks for the feedback. All of the pages on the wiki are >>>>>>>>>> generated from the repo. I think I can generate a gallery of images. Still >>>>>>>>>> some cleanup before I get to that. >>>>>>>>>> >>>>>>>>>> Bill >>>>>>>>>> >>>>>>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>>>>>> >>>>>>>>>>> Nice job Bill. Thanks. >>>>>>>>>>> >>>>>>>>>>> Despite the limitations you have identified, I think >>>>>>>>>>> transitioning to gitlab makes it easier for people to use the examples >>>>>>>>>>> resource, and also, easier to maintain the VTK eco-system. >>>>>>>>>>> >>>>>>>>>>> The yet-to-come steps to add an example will also be a nice >>>>>>>>>>> addition. >>>>>>>>>>> >>>>>>>>>>> IMHO, the right pane could be helpful if it were a true index of >>>>>>>>>>> the sections so that one could easily switch between them without scrolling >>>>>>>>>>> back to the top of the page, and if it could be collapsed. >>>>>>>>>>> >>>>>>>>>>> I think this is a step yet too distant, but having an image >>>>>>>>>>> gallery instead of (or in addition to) a list would be helpful for such >>>>>>>>>>> cases in which the person seeks by a visualization rather than by the >>>>>>>>>>> filter name. It may happen that we have difficulties in identifying the >>>>>>>>>>> right name/class in the class index. I think someone pointed an example >>>>>>>>>>> during the hackathon, but as pointed then, the wiki is not well adapted to >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> May be sharing that could be useful in case someone has a better >>>>>>>>>>> idea, or else just for the records. >>>>>>>>>>> >>>>>>>>>>> JON HAITZ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3 May 2017 at 01:00, Scott, W Alan >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Very nice. Well done. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>>>>>>> Behalf Of *Will Schroeder >>>>>>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>>>>>> *To:* Bill Lorensen >>>>>>>>>>>> *Cc:* VTK Developers >>>>>>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for >>>>>>>>>>>> feedback: Gitlab examples wiki >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I am pretty impressed! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The file list doesn't bother me all that much. I'm not sure how >>>>>>>>>>>> to address the other issues you list. I agree the Camel case problem is >>>>>>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Great work, >>>>>>>>>>>> >>>>>>>>>>>> W >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Folks, >>>>>>>>>>>> >>>>>>>>>>>> Time to kick the tires. >>>>>>>>>>>> >>>>>>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>>>>>> >>>>>>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>>>>>> >>>>>>>>>>>> The wiki pages are automatically created from the gitlab repo >>>>>>>>>>>> pages. >>>>>>>>>>>> >>>>>>>>>>>> Need feedback before proceeding. >>>>>>>>>>>> >>>>>>>>>>>> Things I don't like: >>>>>>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>>>>>>> letter. >>>>>>>>>>>> >>>>>>>>>>>> markdown formatting is very limited. >>>>>>>>>>>> >>>>>>>>>>>> Bill >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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: >>>>>>>>>>>> http://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 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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: >>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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: >>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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: >>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ___________________________________________ >>>>>>> Andrew J. P. Maclean >>>>>>> >>>>>>> ___________________________________________ >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> ___________________________________________ >>>>> Andrew J. P. Maclean >>>>> >>>>> ___________________________________________ >>>>> >>>> >>>> >>>> >>>> -- >>>> ___________________________________________ >>>> Andrew J. P. Maclean >>>> >>>> ___________________________________________ >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> > > -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sur.chiranjib at gmail.com Mon May 8 15:02:00 2017 From: sur.chiranjib at gmail.com (Chiranjib Sur) Date: Tue, 9 May 2017 00:32:00 +0530 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Thanks. One a separate note, do you have a list of VTK classes which are classified as "not thread safe". For example vtkKDTreePopintLocator class is not thread safe unless BuildLocator() is directly or indirectly called from a single thread first (the class description says so). Do you plan to maintain and publish such a list? Just curious again. Chiranjib On Tue, May 9, 2017 at 12:12 AM, Bill Lorensen wrote: > Chiranjib, > > Thanks. No problem. Things may be in better shape by then. > > Bill > > On Mon, May 8, 2017 at 2:32 PM, Chiranjib Sur > wrote: > >> Hi Bill and Andrew, >> Thank you very much for the reply. >> >> Yes, I want to volunteer and will start contributing/testing. Although, >> until May 20th I am bit irregular with my travel. >> >> Thanks, >> Chiranjib >> >> On Mon, May 8, 2017 at 11:48 PM, Bill Lorensen >> wrote: >> >>> Chiranjib, >>> >>> If you want to be an alpha tester, try to follow the instructions for >>> developers here: >>> >>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Instru >>> ctions/ForDevelopers >>> >>> The documentation is fresh out of the oven (still warm) and it would be >>> great to see if it makes sense. >>> >>> Andrew, >>> >>> It would be great if you could kick the tires on the developer >>> contributions. >>> >>> Bill >>> >>> >>> On Mon, May 8, 2017 at 1:50 PM, Chiranjib Sur >>> wrote: >>> >>>> This is fantastic effort and looks very impressive and consolidated. >>>> I learnt (and still learning) developing applications using VTK classes >>>> by writing my own examples and tests. Some of themI can contribute to the >>>> wiki (which are obvious but I had a hard time to figure those out through >>>> my interaction over the mailing list). How can I contribute and share my >>>> experiences in this wiki format? >>>> >>>> Thanks in advance, >>>> Chiranjib >>>> >>>> On Thu, May 4, 2017 at 11:24 AM, Andrew Maclean < >>>> andrew.amaclean at gmail.com> wrote: >>>> >>>>> Hi Bill, >>>>> >>>>> If you need to test the descriptions, this one: >>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/Named >>>>> ColorPatches >>>>> has a lot of html links in the description. It also references the >>>>> python version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visuali >>>>> zation/NamedColorPatches >>>>> >>>>> Regards >>>>> Andrew >>>>> >>>>> On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean < >>>>> andrew.amaclean at gmail.com> wrote: >>>>> >>>>>> Hi Bill, >>>>>> >>>>>> That looks really great. >>>>>> >>>>>> Thanks >>>>>> Andrew >>>>>> >>>>>> On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen < >>>>>> bill.lorensen at gmail.com> wrote: >>>>>> >>>>>>> Yes I have a way to include the descriptions. Now I need to get the >>>>>>> old ones automatically. I'm working on a script for that. >>>>>>> For example I did one of yours manually >>>>>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Vi >>>>>>> sualization/ElevationBandsWithGlyphs >>>>>>> >>>>>>> On May 3, 2017 6:56 PM, "Andrew Maclean" >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Bill, >>>>>>>> I just looked at it and it is not too bad. >>>>>>>> >>>>>>>> Like you I don't like the automatic conversion of camel case e.g >>>>>>>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>>>>>>> certainly doesn't add to readability. >>>>>>>> >>>>>>>> I don't mind the file list on the right-hand side, I think it is >>>>>>>> useful. >>>>>>>> >>>>>>>> One big thing missing is the description, will you be able to >>>>>>>> automatically grab this too? I think it is important as it provides >>>>>>>> rationale and background to the examples. >>>>>>>> >>>>>>>> Thinking further along, how easy will it be to add new examples or >>>>>>>> update existing ones? >>>>>>>> >>>>>>>> Regards >>>>>>>> Andrew >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: Bill Lorensen >>>>>>>>> To: Aron Helser >>>>>>>>> Cc: VTK Developers , Will Schroeder < >>>>>>>>> will.schroeder at kitware.com> >>>>>>>>> Bcc: >>>>>>>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>>>>>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>>>>>>> Gitlab examples wiki >>>>>>>>> Aron, >>>>>>>>> >>>>>>>>> That is pretty cool. I think we can do some kind of image gallery >>>>>>>>> to navigate the examples. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser < >>>>>>>>> aron.helser at kitware.com> wrote: >>>>>>>>> >>>>>>>>>> The automatically generated list of examples is looking quite >>>>>>>>>> good - the clean look of the wiki suits the content well, I think. >>>>>>>>>> >>>>>>>>>> I pointed out two examples of an image gallery I liked during the >>>>>>>>>> hackathon - First https://d3js.org/, which has a hand-picked >>>>>>>>>> gallery of examples as the banner "image" explaining what d3.js is. >>>>>>>>>> The second and more applicable example was >>>>>>>>>> https://bl.ocks.org/mbostock, or https://bl.ocks.org/ which is >>>>>>>>>> an automatically generated gallery of all examples (possibly filtered to >>>>>>>>>> those written by the author of d3). Once you click an example, it is >>>>>>>>>> interactive, because they are all done in javascript. >>>>>>>>>> >>>>>>>>>> Anyone can contribute to bl.ocks.org, and each example is backed >>>>>>>>>> by a github 'gist', like https://gist.github.com/mbostock/4063269 >>>>>>>>>> >>>>>>>>>> This setup makes it very easy to work with single examples, and >>>>>>>>>> fork them to make your own versions. >>>>>>>>>> >>>>>>>>>> I don't propose that this is the right approach for VTK, but for >>>>>>>>>> ideas or inspiration. >>>>>>>>>> Thanks, >>>>>>>>>> Aron >>>>>>>>>> >>>>>>>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Jon, >>>>>>>>>>> >>>>>>>>>>> Thanks for the feedback. All of the pages on the wiki are >>>>>>>>>>> generated from the repo. I think I can generate a gallery of images. Still >>>>>>>>>>> some cleanup before I get to that. >>>>>>>>>>> >>>>>>>>>>> Bill >>>>>>>>>>> >>>>>>>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>>>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Nice job Bill. Thanks. >>>>>>>>>>>> >>>>>>>>>>>> Despite the limitations you have identified, I think >>>>>>>>>>>> transitioning to gitlab makes it easier for people to use the examples >>>>>>>>>>>> resource, and also, easier to maintain the VTK eco-system. >>>>>>>>>>>> >>>>>>>>>>>> The yet-to-come steps to add an example will also be a nice >>>>>>>>>>>> addition. >>>>>>>>>>>> >>>>>>>>>>>> IMHO, the right pane could be helpful if it were a true index >>>>>>>>>>>> of the sections so that one could easily switch between them without >>>>>>>>>>>> scrolling back to the top of the page, and if it could be collapsed. >>>>>>>>>>>> >>>>>>>>>>>> I think this is a step yet too distant, but having an image >>>>>>>>>>>> gallery instead of (or in addition to) a list would be helpful for such >>>>>>>>>>>> cases in which the person seeks by a visualization rather than by the >>>>>>>>>>>> filter name. It may happen that we have difficulties in identifying the >>>>>>>>>>>> right name/class in the class index. I think someone pointed an example >>>>>>>>>>>> during the hackathon, but as pointed then, the wiki is not well adapted to >>>>>>>>>>>> that. >>>>>>>>>>>> >>>>>>>>>>>> May be sharing that could be useful in case someone has a >>>>>>>>>>>> better idea, or else just for the records. >>>>>>>>>>>> >>>>>>>>>>>> JON HAITZ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3 May 2017 at 01:00, Scott, W Alan >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Very nice. Well done. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] >>>>>>>>>>>>> *On Behalf Of *Will Schroeder >>>>>>>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>>>>>>> *To:* Bill Lorensen >>>>>>>>>>>>> *Cc:* VTK Developers >>>>>>>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for >>>>>>>>>>>>> feedback: Gitlab examples wiki >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I am pretty impressed! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The file list doesn't bother me all that much. I'm not sure >>>>>>>>>>>>> how to address the other issues you list. I agree the Camel case problem is >>>>>>>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Great work, >>>>>>>>>>>>> >>>>>>>>>>>>> W >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Folks, >>>>>>>>>>>>> >>>>>>>>>>>>> Time to kick the tires. >>>>>>>>>>>>> >>>>>>>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>>>>>>> >>>>>>>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>>>>>>> >>>>>>>>>>>>> The wiki pages are automatically created from the gitlab repo >>>>>>>>>>>>> pages. >>>>>>>>>>>>> >>>>>>>>>>>>> Need feedback before proceeding. >>>>>>>>>>>>> >>>>>>>>>>>>> Things I don't like: >>>>>>>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>>>>>>> 3) gitlab converts the camel case to lower except for the >>>>>>>>>>>>> first letter. >>>>>>>>>>>>> >>>>>>>>>>>>> markdown formatting is very limited. >>>>>>>>>>>>> >>>>>>>>>>>>> Bill >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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: >>>>>>>>>>>>> http://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 >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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: >>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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: >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ___________________________________________ >>>>>>>> Andrew J. P. Maclean >>>>>>>> >>>>>>>> ___________________________________________ >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ___________________________________________ >>>>>> Andrew J. P. Maclean >>>>>> >>>>>> ___________________________________________ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ___________________________________________ >>>>> Andrew J. P. Maclean >>>>> >>>>> ___________________________________________ >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> >> >> > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhlegarreta at vicomtech.org Mon May 8 16:54:58 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Mon, 8 May 2017 22:54:58 +0200 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170508124848.GA6189@megas.kitware.com> References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> <20170508124848.GA6189@megas.kitware.com> Message-ID: Thanks for the explanation Ben. The MR to fix it is under way. Kind regards, JON HAITZ -- On 8 May 2017 at 14:48, Ben Boeckel wrote: > On Fri, May 05, 2017 at 18:31:53 +0200, Jon Haitz Legarreta wrote: > > The ivar being reported as a duplicate is not, in fact, a duplicate: both > > the parent class vtkChartMatrix and the child vtkScatterPlotMatrix define > > an internal class named PIMPL. And the ivar "Private" is an instance of > > that class. > > vtkChartMatrix is doing PIMPL wrong. It is `protected`, not `private`. I > think that is likely the proper fix. > > > I was not aware of the use of private implementations that PIMPL > represents > > within the VTK context. > > Usually, I've seen `Internal` instead declared outside of the > class itself, but these are usually `protected` so that subclasses can > use them. If `vtkChartMatrix::Private` has this intended use, it should > follow that pattern instead. > > > BTW, I'm interested in knowing about the (need of/convenience) PIMPL > > classes. Is the use of such PIMPL classes documented somewhere? > > In VTK? I don't think so. The idea is to hide the amount of data > necessary for completely internal data collection out of the header and > affecting `sizeof(class)` (an ABI break) or exposing too much (prone to > breaking API because users of the class rely on the wrong things). The > Wiki page is useful: > > https://en.wikipedia.org/wiki/Opaque_pointer > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue May 9 02:41:26 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 9 May 2017 16:41:26 +1000 Subject: [vtk-developers] Request for feedback: Gitlab examples wiki In-Reply-To: References: Message-ID: Hi Bill, I successfully forked/cloned the repository but I had to modify your cloning instructions. So I pushed the changes to *ForDevelopers.md* for you. Note that for some reason when sync your my repository with the VTKExamples repository a changed file Java/Interaction/SphereInteractionPanel.Java was picked up. So this also got pushed up. There is a merge request up there for you. I apologise for not branching! I have just compiled and built release and debug versions for windows VS15/Qt 5.8 with no problems. Regards Andrew On Tue, May 9, 2017 at 4:18 AM, Bill Lorensen wrote: > Chiranjib, > > If you want to be an alpha tester, try to follow the instructions for > developers here: > > https://gitlab.kitware.com/lorensen/VTKExamples/wikis/ > Instructions/ForDevelopers > > The documentation is fresh out of the oven (still warm) and it would be > great to see if it makes sense. > > Andrew, > > It would be great if you could kick the tires on the developer > contributions. > > Bill > > > On Mon, May 8, 2017 at 1:50 PM, Chiranjib Sur > wrote: > >> This is fantastic effort and looks very impressive and consolidated. >> I learnt (and still learning) developing applications using VTK classes >> by writing my own examples and tests. Some of themI can contribute to the >> wiki (which are obvious but I had a hard time to figure those out through >> my interaction over the mailing list). How can I contribute and share my >> experiences in this wiki format? >> >> Thanks in advance, >> Chiranjib >> >> On Thu, May 4, 2017 at 11:24 AM, Andrew Maclean < >> andrew.amaclean at gmail.com> wrote: >> >>> Hi Bill, >>> >>> If you need to test the descriptions, this one: >>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/NamedColorPatches >>> has a lot of html links in the description. It also references the >>> python version: http://www.vtk.org/Wiki/VTK/Examples/Python/Visuali >>> zation/NamedColorPatches >>> >>> Regards >>> Andrew >>> >>> On Thu, May 4, 2017 at 9:09 AM, Andrew Maclean < >>> andrew.amaclean at gmail.com> wrote: >>> >>>> Hi Bill, >>>> >>>> That looks really great. >>>> >>>> Thanks >>>> Andrew >>>> >>>> On Thu, May 4, 2017 at 9:05 AM, Bill Lorensen >>>> wrote: >>>> >>>>> Yes I have a way to include the descriptions. Now I need to get the >>>>> old ones automatically. I'm working on a script for that. >>>>> For example I did one of yours manually >>>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Cxx/Vi >>>>> sualization/ElevationBandsWithGlyphs >>>>> >>>>> On May 3, 2017 6:56 PM, "Andrew Maclean" >>>>> wrote: >>>>> >>>>>> Hi Bill, >>>>>> I just looked at it and it is not too bad. >>>>>> >>>>>> Like you I don't like the automatic conversion of camel case e.g >>>>>> "CurvatureBandsWithGlyphs" is converted to "Curvaturebandswithglyphs". It >>>>>> certainly doesn't add to readability. >>>>>> >>>>>> I don't mind the file list on the right-hand side, I think it is >>>>>> useful. >>>>>> >>>>>> One big thing missing is the description, will you be able to >>>>>> automatically grab this too? I think it is important as it provides >>>>>> rationale and background to the examples. >>>>>> >>>>>> Thinking further along, how easy will it be to add new examples or >>>>>> update existing ones? >>>>>> >>>>>> Regards >>>>>> Andrew >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Bill Lorensen >>>>>>> To: Aron Helser >>>>>>> Cc: VTK Developers , Will Schroeder < >>>>>>> will.schroeder at kitware.com> >>>>>>> Bcc: >>>>>>> Date: Wed, 3 May 2017 13:57:21 -0400 >>>>>>> Subject: Re: [vtk-developers] [EXTERNAL] Re: Request for feedback: >>>>>>> Gitlab examples wiki >>>>>>> Aron, >>>>>>> >>>>>>> That is pretty cool. I think we can do some kind of image gallery to >>>>>>> navigate the examples. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> On Wed, May 3, 2017 at 1:45 PM, Aron Helser >>>>>> > wrote: >>>>>>> >>>>>>>> The automatically generated list of examples is looking quite good >>>>>>>> - the clean look of the wiki suits the content well, I think. >>>>>>>> >>>>>>>> I pointed out two examples of an image gallery I liked during the >>>>>>>> hackathon - First https://d3js.org/, which has a hand-picked >>>>>>>> gallery of examples as the banner "image" explaining what d3.js is. >>>>>>>> The second and more applicable example was >>>>>>>> https://bl.ocks.org/mbostock, or https://bl.ocks.org/ which is an >>>>>>>> automatically generated gallery of all examples (possibly filtered to those >>>>>>>> written by the author of d3). Once you click an example, it is >>>>>>>> interactive, because they are all done in javascript. >>>>>>>> >>>>>>>> Anyone can contribute to bl.ocks.org, and each example is backed >>>>>>>> by a github 'gist', like https://gist.github.com/mbostock/4063269 >>>>>>>> This setup makes it very easy to work with single examples, and >>>>>>>> fork them to make your own versions. >>>>>>>> >>>>>>>> I don't propose that this is the right approach for VTK, but for >>>>>>>> ideas or inspiration. >>>>>>>> Thanks, >>>>>>>> Aron >>>>>>>> >>>>>>>> On Wed, May 3, 2017 at 11:35 AM, Bill Lorensen < >>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>> >>>>>>>>> Jon, >>>>>>>>> >>>>>>>>> Thanks for the feedback. All of the pages on the wiki are >>>>>>>>> generated from the repo. I think I can generate a gallery of images. Still >>>>>>>>> some cleanup before I get to that. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>>> On Wed, May 3, 2017 at 11:32 AM, Jon Haitz Legarreta < >>>>>>>>> jhlegarreta at vicomtech.org> wrote: >>>>>>>>> >>>>>>>>>> Nice job Bill. Thanks. >>>>>>>>>> >>>>>>>>>> Despite the limitations you have identified, I think >>>>>>>>>> transitioning to gitlab makes it easier for people to use the examples >>>>>>>>>> resource, and also, easier to maintain the VTK eco-system. >>>>>>>>>> >>>>>>>>>> The yet-to-come steps to add an example will also be a nice >>>>>>>>>> addition. >>>>>>>>>> >>>>>>>>>> IMHO, the right pane could be helpful if it were a true index of >>>>>>>>>> the sections so that one could easily switch between them without scrolling >>>>>>>>>> back to the top of the page, and if it could be collapsed. >>>>>>>>>> >>>>>>>>>> I think this is a step yet too distant, but having an image >>>>>>>>>> gallery instead of (or in addition to) a list would be helpful for such >>>>>>>>>> cases in which the person seeks by a visualization rather than by the >>>>>>>>>> filter name. It may happen that we have difficulties in identifying the >>>>>>>>>> right name/class in the class index. I think someone pointed an example >>>>>>>>>> during the hackathon, but as pointed then, the wiki is not well adapted to >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> May be sharing that could be useful in case someone has a better >>>>>>>>>> idea, or else just for the records. >>>>>>>>>> >>>>>>>>>> JON HAITZ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3 May 2017 at 01:00, Scott, W Alan wrote: >>>>>>>>>> >>>>>>>>>>> Very nice. Well done. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>>>>>>>>>> Behalf Of *Will Schroeder >>>>>>>>>>> *Sent:* Tuesday, May 2, 2017 1:03 PM >>>>>>>>>>> *To:* Bill Lorensen >>>>>>>>>>> *Cc:* VTK Developers >>>>>>>>>>> *Subject:* [EXTERNAL] Re: [vtk-developers] Request for >>>>>>>>>>> feedback: Gitlab examples wiki >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am pretty impressed! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The file list doesn't bother me all that much. I'm not sure how >>>>>>>>>>> to address the other issues you list. I agree the Camel case problem is >>>>>>>>>>> annoying; it'd be nice if this could be fixed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Great work, >>>>>>>>>>> >>>>>>>>>>> W >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, May 2, 2017 at 2:46 PM, Bill Lorensen < >>>>>>>>>>> bill.lorensen at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> Time to kick the tires. >>>>>>>>>>> >>>>>>>>>>> Try https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home >>>>>>>>>>> >>>>>>>>>>> I have converted the top level example and cxx example pages. >>>>>>>>>>> >>>>>>>>>>> The wiki pages are automatically created from the gitlab repo >>>>>>>>>>> pages. >>>>>>>>>>> >>>>>>>>>>> Need feedback before proceeding. >>>>>>>>>>> >>>>>>>>>>> Things I don't like: >>>>>>>>>>> 1) Rendering of the large Cxx page is very slow. >>>>>>>>>>> 2) I can't get rid of the file list on the right of the page. >>>>>>>>>>> 3) gitlab converts the camel case to lower except for the first >>>>>>>>>>> letter. >>>>>>>>>>> >>>>>>>>>>> markdown formatting is very limited. >>>>>>>>>>> >>>>>>>>>>> Bill >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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: >>>>>>>>>>> http://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 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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: >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Unpaid intern in BillsBasement at noware dot com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: >>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ___________________________________________ >>>>>> Andrew J. P. Maclean >>>>>> >>>>>> ___________________________________________ >>>>>> >>>>> >>>> >>>> >>>> -- >>>> ___________________________________________ >>>> Andrew J. P. Maclean >>>> >>>> ___________________________________________ >>>> >>> >>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Unpaid intern in BillsBasement at noware dot com > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From foufara at yahoo.fr Tue May 9 02:48:45 2017 From: foufara at yahoo.fr (foufara) Date: Mon, 8 May 2017 23:48:45 -0700 (MST) Subject: [vtk-developers] =?utf-8?q?Is_vtkprobefilter_working_correctly_?= =?utf-8?q?=3F_Here_is_an_example_to_test=E2=80=A6?= In-Reply-To: <1494089983256-5743106.post@n5.nabble.com> References: <1494057952312-5743104.post@n5.nabble.com> <1494089983256-5743106.post@n5.nabble.com> Message-ID: <1494312525382-5743147.post@n5.nabble.com> Hi it's me again ! :-) No one can help me on that ? Here is this time a Cxx example. To sum it up, vtkprobefilter and vtkcelllocator do not give the same results on this example and that does not seem right to me? I'll be debugging it to see what happens. But if you already have the explanation, please et me know ! Thanks Raphael #include "vtkPoints.h" #include "vtkPolyData.h" #include "vtkUnstructuredGrid.h" #include "vtkDataSet.h" #include "vtkPointData.h" #include "vtkDataArray.h" #include "vtkDataSetReader.h" #include "vtkProbeFilter.h" #include "vtkPointLocator.h" #include "vtkCellLocator.h" #include "vtkIdList.h" #include "vtkPolyDataWriter.h" int main() { std::cout << "DEBUGRAPHA : Debug1" << "\n "<InsertNextPoint(point1); vtkIdType nextPoint2 = points->InsertNextPoint(point2); vtkPolyData* polydata = vtkPolyData::New(); polydata->SetPoints(points); std::cout << "Points" <SetInputData(polydata); writer1->SetFileName("polydata.vtk"); writer1->Write(); // 3D Data to probe vtkDataSetReader *reader = vtkDataSetReader::New(); reader->SetFileName("extraction.vtk"); reader->Update(); vtkDataSet* data=reader->GetOutput(); // Probing vtkProbeFilter* probe = vtkProbeFilter::New(); probe->SetInputData(polydata); probe->SetSourceData(data); probe->Update(); vtkDataSet* result=probe->GetOutput(); // Results probing vtkPointData* pointData = result->GetPointData(); vtkDataArray* valid = pointData->GetArray("vtkValidPointMask"); vtkDataArray* cellid = pointData->GetArray("ID"); std::cout << "Probing" <GetTuple1(0) << " " << valid->GetTuple1(1) << std::endl; std::cout << "ID : " << cellid->GetTuple1(0) << " " << cellid->GetTuple1(1) << std::endl; std::cout << "\n" << std::endl; // CellLocator vtkIdType cellids[2]; vtkCellLocator* locator=vtkCellLocator::New(); locator->SetDataSet(data); locator->BuildLocator(); for (int i=0; iGetNumberOfPoints(); i++) { cellids[i]=locator->FindCell(polydata->GetPoint(i)); } std::cout << "CellLocator" < References: <1494057952312-5743104.post@n5.nabble.com> <1494089983256-5743106.post@n5.nabble.com> <1494312525382-5743147.post@n5.nabble.com> Message-ID: Unless I am missing something in your question, probing and locating cells are two different things. I would expect them to have different results. Probing interpolates, locators don't. From the documentation of the two classes... vtkProbeFilter is a filter that computes point attributes (e.g., scalars, * vectors, etc.) at specified point positions. The filter has two inputs: * the Input and Source. The Input geometric structure is passed through the * filter. The point attributes are computed at the Input point positions * by interpolating into the source data. For example, we can compute data * values on a plane (plane specified as Input) from a volume (Source). * The cell data of the source data is copied to the output based on in * which source cell each input point is. If an array of the same name exists * both in source's point and cell data, only the one from the point data is * probed. * * This filter can be used to resample data, or convert one dataset form into * another. For example, an unstructured grid (vtkUnstructuredGrid) can be * probed with a volume (three-dimensional vtkImageData), and then volume * rendering techniques can be used to visualize the results. Another example: * a line or curve can be used to probe data to produce x-y plots along * that line or curve. Versus * vtkCellLocator is a spatial search object to quickly locate cells in 3D. * vtkCellLocator uses a uniform-level octree subdivision, where each octant * (an octant is also referred to as a bucket) carries an indication of * whether it is empty or not, and each leaf octant carries a list of the * cells inside of it. (An octant is not empty if it has one or more cells * inside of it.) Typical operations are intersection with a line to return * candidate cells, or intersection with another vtkCellLocator to return * candidate cells. On Tue, May 9, 2017 at 2:48 AM, foufara via vtk-developers < vtk-developers at vtk.org> wrote: > Hi it's me again ! :-) > > No one can help me on that ? > > Here is this time a Cxx example. > > To sum it up, vtkprobefilter and vtkcelllocator do not give the same > results > on this example and that does not seem right to me? > > I'll be debugging it to see what happens. > But if you already have the explanation, please et me know ! > > Thanks > > Raphael > > > #include "vtkPoints.h" > #include "vtkPolyData.h" > #include "vtkUnstructuredGrid.h" > #include "vtkDataSet.h" > #include "vtkPointData.h" > #include "vtkDataArray.h" > #include "vtkDataSetReader.h" > #include "vtkProbeFilter.h" > #include "vtkPointLocator.h" > #include "vtkCellLocator.h" > #include "vtkIdList.h" > #include "vtkPolyDataWriter.h" > > > int main() > { > > std::cout << "DEBUGRAPHA : Debug1" << "\n "< > > > double point1[3] = {-312.,-1407.,37.}; > double point2[3] = {-312.,-1407.,57.}; > > // 2 Points to probe with > vtkPoints* points = vtkPoints::New(); > vtkIdType nextPoint1 = points->InsertNextPoint(point1); > vtkIdType nextPoint2 = points->InsertNextPoint(point2); > vtkPolyData* polydata = vtkPolyData::New(); > polydata->SetPoints(points); > > std::cout << "Points" < std::cout << "Point 1 : " << point1[0] << > " " << point1[1] << " " << point1[2] > << std::endl; > std::cout << "Point 2 : " << point2[0] << > " " << point2[1] << " " << point2[2] > << std::endl; > std::cout << "\n" << std::endl; > > //Writing the points to vtk file > vtkPolyDataWriter* writer1 = vtkPolyDataWriter::New(); > writer1->SetInputData(polydata); > writer1->SetFileName("polydata.vtk"); > writer1->Write(); > > // 3D Data to probe > vtkDataSetReader *reader = vtkDataSetReader::New(); > reader->SetFileName("extraction.vtk"); > reader->Update(); > vtkDataSet* data=reader->GetOutput(); > > // Probing > vtkProbeFilter* probe = vtkProbeFilter::New(); > probe->SetInputData(polydata); > probe->SetSourceData(data); > probe->Update(); > vtkDataSet* result=probe->GetOutput(); > > // Results probing > vtkPointData* pointData = result->GetPointData(); > vtkDataArray* valid = pointData->GetArray("vtkValidPointMask"); > vtkDataArray* cellid = pointData->GetArray("ID"); > > std::cout << "Probing" < std::cout << "Valid : " << valid->GetTuple1(0) << > " " << valid->GetTuple1(1) << std::endl; > std::cout << "ID : " << cellid->GetTuple1(0) << " " << > cellid->GetTuple1(1) << std::endl; > std::cout << "\n" << std::endl; > > > // CellLocator > vtkIdType cellids[2]; > vtkCellLocator* locator=vtkCellLocator::New(); > locator->SetDataSet(data); > locator->BuildLocator(); > for (int i=0; iGetNumberOfPoints(); i++) > { > cellids[i]=locator->FindCell(polydata->GetPoint(i)); > } > std::cout << "CellLocator" < std::cout << "ID : " << cellids[0] << " " << cellids[1] << std::endl; > > return 0; > } > > > > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/Is-vtkprobefilter-working-correctly-Here-is-an-example- > to-test-tp5743104p5743147.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 foufara at yahoo.fr Tue May 9 13:47:12 2017 From: foufara at yahoo.fr (foufara) Date: Tue, 9 May 2017 10:47:12 -0700 (MST) Subject: [vtk-developers] =?utf-8?q?Is_vtkprobefilter_working_correctly_?= =?utf-8?q?=3F_Here_is_an_example_to_test=E2=80=A6?= In-Reply-To: References: <1494057952312-5743104.post@n5.nabble.com> <1494089983256-5743106.post@n5.nabble.com> <1494312525382-5743147.post@n5.nabble.com> Message-ID: <1494352032898-5743162.post@n5.nabble.com> Hi Ken, thank you for your answer. I'm really flattered to get an answer from one of the fathers of VTK (right ?) whose book lies on my desk ! :-) I realize I could have been more clearer on what I intend to do. I want indeed interpolate from one dataset to another, from the source point or cell data to the input points. For that purpose vtkprobefilter seems perfect. I also understand that the interpolation will be different whether the data are point or cell located on the source : - for pointdata, it will be interpolation based on the parametric coordinates of the input points in the cells that contain them - for celldata it will just be passing cell values to the input points contained in them? Please correct me if I'm wrong so far? However I notice that on some occasions vtkprobefilter fails while it should not (according to me) So I though I can get the same celldata "interpolation" using vtkcellLocator to identify which cell contains each input point and then passing manually the right values from the source cells to the input points. And doing that I realize that vtkcellLocator does find the "right" cells where vtkprobeFilter fails. So I don't expect here to get the same results in terms of interpolated data (at least when we deal with point data, since cell data should be treated the same way here, right ?) but in terms of which cell is found to contain each input point. The example I joined in a previous post (in python and then C++) shows that the cells identified are different (vtkprobefilter fails but vtkcelllocator don't). Check the prints. What surprises me is that, by reading the vtk code, it seemed to me that about the same functions were called by each filter (vtkpointlocator to identify the closest point in the source, then FindCell and FindCellWalk for each cell using the points, etc.). I'm trying to "debug" (I'm sure it's not really bugged") each filter to understand where the difference arises. But I'm not used to C++ (see my other post : "Best way to add a print in a distribution file ?"). Finaly, I wrote earlier "find the "right" cells" because in my example the source cells are "warp hexa" (built from warp quadrangles). So the cell found to contain a point by either vtkprobefilter (when it works) or vtkcellLocator is not necessarily the cell that physically contains the point. You'll see it if you run the python version of my example and check the outputs in paraview. But I don't know if I can do better. Well I hope I'm clearer now, and not too long :-) Thank you for you help on that. Rapha?l -- View this message in context: http://vtk.1045678.n5.nabble.com/Is-vtkprobefilter-working-correctly-Here-is-an-example-to-test-tp5743104p5743162.html Sent from the VTK - Dev mailing list archive at Nabble.com. From marcus.hanwell at kitware.com Tue May 9 14:34:06 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 9 May 2017 14:34:06 -0400 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170505140955.1559355036@mail.rogue-research.com> References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> Message-ID: On Fri, May 5, 2017 at 10:09 AM, Sean McBride wrote: > > On Wed, 3 May 2017 09:25:09 -0600, David Gobbi said: > > >I don't think suppressing them is a good idea, redefined member variables > >are strongly indicative of real bugs. > > Thanks David & Jon! We are down to 10 now: > > Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines member variable with name 'Colors' also defined in its parent class 'vtkPlot3D'. > > Charts/Core/vtkChartMatrix.h:155: warning: The class 'vtkScatterPlotMatrix' defines member variable with name 'Private' also defined in its parent class 'vtkChartMatrix'. > I missed your original email, I haven't always had time to monitor the mailing list. Are both of these still open? I can take a look if so, they should be pretty simple and I likely wrote them, if there are others in charts I can take a look too. From jhlegarreta at vicomtech.org Tue May 9 17:21:00 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Tue, 9 May 2017 23:21:00 +0200 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> Message-ID: Hi Marcus, thanks ! The issues with vtk::PlotSurface were addressed here: https://gitlab.kitware.com/vtk/vtk/merge_requests/2787 Still pending some approval/review/suggestion, since the build errors seem unrelated to me. The last bunch of warnings (including that one belonging to the vtk::vtkScatterPlotMatrix class) is addressed here: https://gitlab.kitware.com/vtk/vtk/merge_requests/2799 I've got to review the errors in this last still. That's why I did not add any reviewers yet. But if they look immediate to you, suggestions are welcome. JON HAITZ -- On 9 May 2017 at 20:34, Marcus D. Hanwell wrote: > On Fri, May 5, 2017 at 10:09 AM, Sean McBride > wrote: > > > > On Wed, 3 May 2017 09:25:09 -0600, David Gobbi said: > > > > >I don't think suppressing them is a good idea, redefined member > variables > > >are strongly indicative of real bugs. > > > > Thanks David & Jon! We are down to 10 now: > > > > Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines > member variable with name 'Colors' also defined in its parent class > 'vtkPlot3D'. > > > > Charts/Core/vtkChartMatrix.h:155: warning: The class > 'vtkScatterPlotMatrix' defines member variable with name 'Private' also > defined in its parent class 'vtkChartMatrix'. > > > I missed your original email, I haven't always had time to monitor the > mailing list. Are both of these still open? I can take a look if so, > they should be pretty simple and I likely wrote them, if there are > others in charts I can take a look too. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.engelgardt at gmail.com Wed May 10 06:14:44 2017 From: v.engelgardt at gmail.com (Vladimir Engelgardt) Date: Wed, 10 May 2017 03:14:44 -0700 (MST) Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 Message-ID: <1494411284283-5743167.post@n5.nabble.com> Hi, Problem description: Application uses VTK 7.0 (OpenGL 2 module) for rendering on Windows platform. But the problem is, that OpenGL 2 has limited support over Microsoft's Remote Desktop. RDP is a must for our application (VNC, TeamViewer is not an option). On Win 10 there is an option called 'Use hardware drivers over RDP' and it works, but for limited set of video adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid only). Is there any workaround for this problem, i.e. detect GL version at runtime and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. We concern about OpenGL 1.1 support in future versions of VTK. Is it going to be supported and how long? Best Regards, Vladimir. -- View this message in context: http://vtk.1045678.n5.nabble.com/OpenGL-backend-1-1-vs-2-0-tp5743167.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lasso at queensu.ca Wed May 10 07:44:07 2017 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 10 May 2017 11:44:07 +0000 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: <1494411284283-5743167.post@n5.nabble.com> References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: OpenGL capability detection is broken when you use RDP: if you start an application before connecting through RDP it works just fine (see some details and workarounds here: http://na-mic.org/Mantis/view.php?id=4252). Could somebody try what happens if we skip capability detection on startup and force using all OpenGL features that is needed for the OpenGL2 backend? Andras From: Vladimir Engelgardt Sent: Wednesday, May 10, 2017 6:14 AM To: vtk-developers at vtk.org Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 Hi, Problem description: Application uses VTK 7.0 (OpenGL 2 module) for rendering on Windows platform. But the problem is, that OpenGL 2 has limited support over Microsoft's Remote Desktop. RDP is a must for our application (VNC, TeamViewer is not an option). On Win 10 there is an option called 'Use hardware drivers over RDP' and it works, but for limited set of video adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid only). Is there any workaround for this problem, i.e. detect GL version at runtime and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. We concern about OpenGL 1.1 support in future versions of VTK. Is it going to be supported and how long? Best Regards, Vladimir. -- View this message in context: http://vtk.1045678.n5.nabble.com/OpenGL-backend-1-1-vs-2-0-tp5743167.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed May 10 08:51:08 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 May 2017 08:51:08 -0400 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: <1494411284283-5743167.post@n5.nabble.com> References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: If you have to support RDP (as opposed to other solutions), and you have to support clients that lack a GPU etc, then you could build your application against Mesa (with OpenSWR or llvm as the renderer) and I believe it should work everywhere including RDP. Ideally at run time we could detect this and pick Mesa/Hardware but I don't think anyone has had time to dig into how difficult that would be. >From what I could find nvidia only supports hardware RDP on their professional cards. It would certainly be nice if vendors would do what they can to support modern OpenGL more broadly in cases like this. On Wed, May 10, 2017 at 6:14 AM, Vladimir Engelgardt wrote: > Hi, > > Problem description: Application uses VTK 7.0 (OpenGL 2 module) for > rendering on Windows platform. But the problem is, that OpenGL 2 has > limited > support over Microsoft's Remote Desktop. RDP is a must for our application > (VNC, TeamViewer is not an option). On Win 10 there is an option called > 'Use > hardware drivers over RDP' and it works, but for limited set of video > adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid > only). > > Is there any workaround for this problem, i.e. detect GL version at runtime > and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. > > We concern about OpenGL 1.1 support in future versions of VTK. Is it going > to be supported and how long? > > Best Regards, > Vladimir. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/OpenGL-backend-1-1-vs-2-0-tp5743167.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 Wed May 10 09:28:58 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 10 May 2017 09:28:58 -0400 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: <1494411284283-5743167.post@n5.nabble.com> References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: <20170510132858.GA1339@megas.kitware.com> On Wed, May 10, 2017 at 03:14:44 -0700, Vladimir Engelgardt wrote: > Is there any workaround for this problem, i.e. detect GL version at runtime > and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. Note that the 1 vs. 2 meaning is a VTK-ism. The OpenGL2 backend requires features from OpenGL 3.2 (at least). The "2" comes from the fact that it's the second OpenGL backend, not the version of OpenGL. --Ben From ken.martin at kitware.com Wed May 10 09:40:30 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 May 2017 09:40:30 -0400 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: <20170510132858.GA1339@megas.kitware.com> References: <1494411284283-5743167.post@n5.nabble.com> <20170510132858.GA1339@megas.kitware.com> Message-ID: Yes :-) The thought was that the old backend would go away fairly quickly and then OpenGL2 would be renamed OpenGL. I don't think we expected the old backend to be needed this long. One of the reasons I'd like to see Mesa as a fallback is to allow us to get rid of the old backend as at that point we should have a solution that works on everything above a vt100 :-) On Wed, May 10, 2017 at 9:28 AM, Ben Boeckel wrote: > On Wed, May 10, 2017 at 03:14:44 -0700, Vladimir Engelgardt wrote: > > Is there any workaround for this problem, i.e. detect GL version at > runtime > > and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. > > Note that the 1 vs. 2 meaning is a VTK-ism. The OpenGL2 backend requires > features from OpenGL 3.2 (at least). The "2" comes from the fact that > it's the second OpenGL backend, not the version of OpenGL. > > --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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 lasso at queensu.ca Wed May 10 09:40:57 2017 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 10 May 2017 13:40:57 +0000 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: VTK's OpenGL2 backend works very well through RDP - including volume rendering, even using a client without GPU. The only limitation (an important one) is that you have to start your application before connecting through RDP. The only thing to figure out is how to convince applications to start ?normally? when connected through RDP. Andras From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ken Martin Sent: Wednesday, May 10, 2017 8:51 AM To: Vladimir Engelgardt Cc: VTK Developers Subject: Re: [vtk-developers] OpenGL backend - 1.1 vs 2.0 If you have to support RDP (as opposed to other solutions), and you have to support clients that lack a GPU etc, then you could build your application against Mesa (with OpenSWR or llvm as the renderer) and I believe it should work everywhere including RDP. Ideally at run time we could detect this and pick Mesa/Hardware but I don't think anyone has had time to dig into how difficult that would be. From what I could find nvidia only supports hardware RDP on their professional cards. It would certainly be nice if vendors would do what they can to support modern OpenGL more broadly in cases like this. On Wed, May 10, 2017 at 6:14 AM, Vladimir Engelgardt > wrote: Hi, Problem description: Application uses VTK 7.0 (OpenGL 2 module) for rendering on Windows platform. But the problem is, that OpenGL 2 has limited support over Microsoft's Remote Desktop. RDP is a must for our application (VNC, TeamViewer is not an option). On Win 10 there is an option called 'Use hardware drivers over RDP' and it works, but for limited set of video adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid only). Is there any workaround for this problem, i.e. detect GL version at runtime and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. We concern about OpenGL 1.1 support in future versions of VTK. Is it going to be supported and how long? Best Regards, Vladimir. -- View this message in context: http://vtk.1045678.n5.nabble.com/OpenGL-backend-1-1-vs-2-0-tp5743167.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 ken.martin at kitware.com Wed May 10 09:50:44 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 May 2017 09:50:44 -0400 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: Hmmm, maybe something like this https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS In your batch file make sure you reconnect your session to the physical console before attempting to launch the CAD app. Here is the command: tscon 1 /dest:console I am thinking your batch file only needs two lines, something like: tscon 1 /dest:console start "C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe" The first line will disconnect your remote PC and connect the session to the physical keyboard/video/mouse, then the second line will launch the CAD program (substitute your CAD software). After that you wait several seconds for the software to start and then reconnect to the session from your home PC. You should have the batch file Run as administrator. I made an assumption above that the current session id is 1. Your session id may be different--you can use query session at a command prompt to find your session id. On Wed, May 10, 2017 at 9:40 AM, Andras Lasso wrote: > VTK's OpenGL2 backend works very well through RDP - including volume > rendering, even using a client without GPU. The only limitation (an > important one) is that you have to start your application before connecting > through RDP. > > > > The only thing to figure out is how to convince applications to start > ?normally? when connected through RDP. > > > > Andras > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Ken Martin > *Sent:* Wednesday, May 10, 2017 8:51 AM > *To:* Vladimir Engelgardt > *Cc:* VTK Developers > *Subject:* Re: [vtk-developers] OpenGL backend - 1.1 vs 2.0 > > > > If you have to support RDP (as opposed to other solutions), and you have > to support clients that lack a GPU etc, then you could build your > application against Mesa (with OpenSWR or llvm as the renderer) and I > believe it should work everywhere including RDP. > > > > Ideally at run time we could detect this and pick Mesa/Hardware but I > don't think anyone has had time to dig into how difficult that would be. > > > > From what I could find nvidia only supports hardware RDP on their > professional cards. It would certainly be nice if vendors would do what > they can to support modern OpenGL more broadly in cases like this. > > > > > > > > > > > > On Wed, May 10, 2017 at 6:14 AM, Vladimir Engelgardt < > v.engelgardt at gmail.com> wrote: > > Hi, > > Problem description: Application uses VTK 7.0 (OpenGL 2 module) for > rendering on Windows platform. But the problem is, that OpenGL 2 has > limited > support over Microsoft's Remote Desktop. RDP is a must for our application > (VNC, TeamViewer is not an option). On Win 10 there is an option called > 'Use > hardware drivers over RDP' and it works, but for limited set of video > adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid > only). > > Is there any workaround for this problem, i.e. detect GL version at runtime > and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. > > We concern about OpenGL 1.1 support in future versions of VTK. Is it going > to be supported and how long? > > Best Regards, > Vladimir. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/OpenGL-backend-1-1-vs-2-0-tp5743167.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > Kitware Inc. > > 28 Corporate Drive > Clifton Park NY 12065 > > > > 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. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 lasso at queensu.ca Wed May 10 10:19:06 2017 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 10 May 2017 14:19:06 +0000 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: Terminating RDP connection and restart the application in a batch file works well. It would be quite usable if we could build this into the application instead of setting up a separate batch file. We need to detect insufficient OpenGL capabilities anyway (the current way of Paraview simply crashing when starting through RDP is just embarrassing). It should not be too difficult to add RDP connection termination and application restart there. After some more web search, it doesn?t seem to be possible to access the regular OpenGL context when an application started through RDP. Applications that need maximum compatibility include multiple rendering backends with dynamic switching (such as Qt 5 rendering engine, based on a run-time check at application startup) or static selection (e.g., 3D Studio Max). However, in the long term I would prefer seeing the VTK community spending time with developing new features than maintaining a legacy backend. Andras From: Ken Martin [mailto:ken.martin at kitware.com] Sent: Wednesday, May 10, 2017 9:51 AM To: Andras Lasso Cc: Vladimir Engelgardt ; VTK Developers Subject: Re: [vtk-developers] OpenGL backend - 1.1 vs 2.0 Hmmm, maybe something like this https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS In your batch file make sure you reconnect your session to the physical console before attempting to launch the CAD app. Here is the command: tscon 1 /dest:console I am thinking your batch file only needs two lines, something like: tscon 1 /dest:console start "C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe" The first line will disconnect your remote PC and connect the session to the physical keyboard/video/mouse, then the second line will launch the CAD program (substitute your CAD software). After that you wait several seconds for the software to start and then reconnect to the session from your home PC. You should have the batch file Run as administrator. I made an assumption above that the current session id is 1. Your session id may be different--you can use query session at a command prompt to find your session id. On Wed, May 10, 2017 at 9:40 AM, Andras Lasso > wrote: VTK's OpenGL2 backend works very well through RDP - including volume rendering, even using a client without GPU. The only limitation (an important one) is that you have to start your application before connecting through RDP. The only thing to figure out is how to convince applications to start ?normally? when connected through RDP. Andras From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ken Martin Sent: Wednesday, May 10, 2017 8:51 AM To: Vladimir Engelgardt > Cc: VTK Developers > Subject: Re: [vtk-developers] OpenGL backend - 1.1 vs 2.0 If you have to support RDP (as opposed to other solutions), and you have to support clients that lack a GPU etc, then you could build your application against Mesa (with OpenSWR or llvm as the renderer) and I believe it should work everywhere including RDP. Ideally at run time we could detect this and pick Mesa/Hardware but I don't think anyone has had time to dig into how difficult that would be. From what I could find nvidia only supports hardware RDP on their professional cards. It would certainly be nice if vendors would do what they can to support modern OpenGL more broadly in cases like this. On Wed, May 10, 2017 at 6:14 AM, Vladimir Engelgardt > wrote: Hi, Problem description: Application uses VTK 7.0 (OpenGL 2 module) for rendering on Windows platform. But the problem is, that OpenGL 2 has limited support over Microsoft's Remote Desktop. RDP is a must for our application (VNC, TeamViewer is not an option). On Win 10 there is an option called 'Use hardware drivers over RDP' and it works, but for limited set of video adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid only). Is there any workaround for this problem, i.e. detect GL version at runtime and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. We concern about OpenGL 1.1 support in future versions of VTK. Is it going to be supported and how long? Best Regards, Vladimir. -- View this message in context: http://vtk.1045678.n5.nabble.com/OpenGL-backend-1-1-vs-2-0-tp5743167.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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. -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 berk.geveci at kitware.com Wed May 10 10:27:36 2017 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 May 2017 10:27:36 -0400 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: <1494411284283-5743167.post@n5.nabble.com> References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: To answer this questions that wasn't answered: > We concern about OpenGL 1.1 support in future versions of VTK. Is it going > to be supported and how long? The plan that was floated so far is to drop OpenGL 1 support by the end of 2017. Even this drags a bit longer, it will not be supported for very long. We encourage everyone who are running on drivers that do not support OpenGL 3.2 to start looking into Mesa with OpenSWR. Best, -berk On Wed, May 10, 2017 at 6:14 AM, Vladimir Engelgardt wrote: > Hi, > > Problem description: Application uses VTK 7.0 (OpenGL 2 module) for > rendering on Windows platform. But the problem is, that OpenGL 2 has > limited > support over Microsoft's Remote Desktop. RDP is a must for our application > (VNC, TeamViewer is not an option). On Win 10 there is an option called > 'Use > hardware drivers over RDP' and it works, but for limited set of video > adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid > only). > > Is there any workaround for this problem, i.e. detect GL version at runtime > and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. > > We concern about OpenGL 1.1 support in future versions of VTK. Is it going > to be supported and how long? > > Best Regards, > Vladimir. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/OpenGL-backend-1-1-vs-2-0-tp5743167.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed May 10 10:55:56 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 10 May 2017 10:55:56 -0400 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> <20170503150618.375492316@mail.rogue-research.com> <20170505140955.1559355036@mail.rogue-research.com> Message-ID: Hi Jon, The charts related changed look good to me, just added +2 for that piece for both. Thanks for fixing these up, it looks like there are some dashboard issues hopefully they can be cleared up (look unrelated to the charts changes to me). Marcus On Tue, May 9, 2017 at 5:21 PM, Jon Haitz Legarreta < jhlegarreta at vicomtech.org> wrote: > Hi Marcus, > thanks ! > > The issues with vtk::PlotSurface were addressed here: > https://gitlab.kitware.com/vtk/vtk/merge_requests/2787 > > Still pending some approval/review/suggestion, since the build errors seem > unrelated to me. > > The last bunch of warnings (including that one belonging to the > vtk::vtkScatterPlotMatrix class) is addressed here: > https://gitlab.kitware.com/vtk/vtk/merge_requests/2799 > > I've got to review the errors in this last still. That's why I did not add > any reviewers yet. But if they look immediate to you, suggestions are > welcome. > > JON HAITZ > > -- > > > On 9 May 2017 at 20:34, Marcus D. Hanwell > wrote: > >> On Fri, May 5, 2017 at 10:09 AM, Sean McBride >> wrote: >> > >> > On Wed, 3 May 2017 09:25:09 -0600, David Gobbi said: >> > >> > >I don't think suppressing them is a good idea, redefined member >> variables >> > >are strongly indicative of real bugs. >> > >> > Thanks David & Jon! We are down to 10 now: >> > >> > Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' >> defines member variable with name 'Colors' also defined in its parent class >> 'vtkPlot3D'. >> > >> > Charts/Core/vtkChartMatrix.h:155: warning: The class >> 'vtkScatterPlotMatrix' defines member variable with name 'Private' also >> defined in its parent class 'vtkChartMatrix'. >> > >> I missed your original email, I haven't always had time to monitor the >> mailing list. Are both of these still open? I can take a look if so, >> they should be pretty simple and I likely wrote them, if there are >> others in charts I can take a look too. >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed May 10 11:01:11 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 May 2017 11:01:11 -0400 Subject: [vtk-developers] OpenGL backend - 1.1 vs 2.0 In-Reply-To: References: <1494411284283-5743167.post@n5.nabble.com> Message-ID: We need to detect insufficient OpenGL capabilities anyway (the current way > of Paraview simply crashing when starting through RDP is just > embarrassing). It should not be too difficult to add RDP connection > termination and application restart there. > > It should be graceful but it wasn't. This topic makes it so that VTK at least can check and fail gracefully when running on RDP. https://gitlab.kitware.com/vtk/vtk/merge_requests/2812 > > > After some more web search, it doesn?t seem to be possible to access the > regular OpenGL context when an application started through RDP. > Applications that need maximum compatibility include multiple rendering > backends with dynamic switching (such as Qt 5 rendering engine, based on a > run-time check at application startup) or static selection (e.g., 3D Studio > Max). However, in the long term I would prefer seeing the VTK community > spending time with developing new features than maintaining a legacy > backend. > > > > Andras > > > > *From:* Ken Martin [mailto:ken.martin at kitware.com] > *Sent:* Wednesday, May 10, 2017 9:51 AM > *To:* Andras Lasso > *Cc:* Vladimir Engelgardt ; VTK Developers < > vtk-developers at vtk.org> > *Subject:* Re: [vtk-developers] OpenGL backend - 1.1 vs 2.0 > > > > Hmmm, maybe something like this > > > > https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8- > 3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS > > > > In your batch file make sure you reconnect your session to the physical > console before attempting to launch the CAD app. Here is the command: > > tscon 1 /dest:console > > I am thinking your batch file only needs two lines, something like: > > tscon 1 /dest:console > start "C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe" > > The first line will disconnect your remote PC and connect the session to > the physical keyboard/video/mouse, then the second line will launch the CAD > program (substitute your CAD software). After that you wait several > seconds for the software to start and then reconnect to the session from > your home PC. > > You should have the batch file Run as administrator. I made an assumption > above that the current session id is 1. Your session id may be > different--you can use query session at a command prompt to find your > session id. > > > > On Wed, May 10, 2017 at 9:40 AM, Andras Lasso wrote: > > VTK's OpenGL2 backend works very well through RDP - including volume > rendering, even using a client without GPU. The only limitation (an > important one) is that you have to start your application before connecting > through RDP. > > > > The only thing to figure out is how to convince applications to start > ?normally? when connected through RDP. > > > > Andras > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Ken Martin > *Sent:* Wednesday, May 10, 2017 8:51 AM > *To:* Vladimir Engelgardt > *Cc:* VTK Developers > *Subject:* Re: [vtk-developers] OpenGL backend - 1.1 vs 2.0 > > > > If you have to support RDP (as opposed to other solutions), and you have > to support clients that lack a GPU etc, then you could build your > application against Mesa (with OpenSWR or llvm as the renderer) and I > believe it should work everywhere including RDP. > > > > Ideally at run time we could detect this and pick Mesa/Hardware but I > don't think anyone has had time to dig into how difficult that would be. > > > > From what I could find nvidia only supports hardware RDP on their > professional cards. It would certainly be nice if vendors would do what > they can to support modern OpenGL more broadly in cases like this. > > > > > > > > > > > > On Wed, May 10, 2017 at 6:14 AM, Vladimir Engelgardt < > v.engelgardt at gmail.com> wrote: > > Hi, > > Problem description: Application uses VTK 7.0 (OpenGL 2 module) for > rendering on Windows platform. But the problem is, that OpenGL 2 has > limited > support over Microsoft's Remote Desktop. RDP is a must for our application > (VNC, TeamViewer is not an option). On Win 10 there is an option called > 'Use > hardware drivers over RDP' and it works, but for limited set of video > adapters - AMD, Integrated Graphics from Intel and NVIDIA (Tesla, Grid > only). > > Is there any workaround for this problem, i.e. detect GL version at runtime > and use 1.1 or 2.0? If no, we are going to switch for OpenGL 1.1. > > We concern about OpenGL 1.1 support in future versions of VTK. Is it going > to be supported and how long? > > Best Regards, > Vladimir. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/OpenGL-backend-1-1-vs-2-0-tp5743167.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > Kitware Inc. > > 28 Corporate Drive > Clifton Park NY 12065 > > > > 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. > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > Kitware Inc. > > 28 Corporate Drive > Clifton Park NY 12065 > > > > 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. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 elvis.stansvik at orexplore.com Thu May 11 11:17:33 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 11 May 2017 17:17:33 +0200 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: <20161107185835.473800880@mail.rogue-research.com> References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: 2016-11-07 19:58 GMT+01:00 Sean McBride : > On Fri, 4 Nov 2016 14:36:56 -0400, Marcus D. Hanwell said: > >>On Fri, Nov 4, 2016 at 8:28 AM, Michael Jackson >> wrote: >>> I just tried the HiDPI support on VTK 7.1.0-rc2 and I get the usual VTK >>> rendering canvas that is half the size of the widget that it is embedded >>> into. >>> >>> We are using Qt 5.6.2 on macOS 10.10.5. I compiled my original pull request >>> (way back in Aug 2016) and that patch gives me a full size canvas. But when >>> compiling the latest VTK 7.1.0-rc2 I get the half size canvas. I thought the >>> branch was merged on Sept 28 2016 but I guess I got busy and never actually >>> tested it on a retina screen. >>> >>> Most likely I am doing something wrong in the initialization in my code but >>> just in case can anyone else confirm with Qt 5.6.x that they can actually >>> get a Retina/HiDPI canvas? >>> >>Bob has a retinal Mac that I can do some testing on, this is likely to >>end up being after Supercomputing, but I would like to follow up on >>this. We had it working when you visited, and I am hoping to get this >>enabled in Tomviz at some point soon. It would be great to hear from >>Sean and/or David. To the best of my recollection an alternate >>approach was developed, and that was merged. It had several other >>changes in addition to what was proposed originally. > > We merged my PR: > > > and not Mike's: > > > IIRC mine was a superset of Mike's, unless we screwed something up somewhere. I was always of the view that the changes were necessary but not sufficient. > > I'm swamped this week preparing for the SfN conference, but can look more next week... Bumping this old thread since I'm in this boat as well now. I've finally gotten around to porting our application to macOS. Everything went pretty smooth. We're using 7.1.1, and we're using QVTKWidget (will port to QVTKOpenGLWidget once 8.0.0 is out). I am however seeing the problem on a retina screen that VTK render windows only take up a quarter of their alotted space. So my question: Is it possible to make VTK work fine on retina displays with 7.1.1? If not, is there some patch I could apply? Or will I have to build from Git (to be 8.0.0)? Cheers, Elvis > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From marcus.hanwell at kitware.com Thu May 11 11:25:08 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 11 May 2017 11:25:08 -0400 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: On Thu, May 11, 2017 at 11:17 AM, Elvis Stansvik wrote: > 2016-11-07 19:58 GMT+01:00 Sean McBride : >> On Fri, 4 Nov 2016 14:36:56 -0400, Marcus D. Hanwell said: >> >>>On Fri, Nov 4, 2016 at 8:28 AM, Michael Jackson >>> wrote: >>>> I just tried the HiDPI support on VTK 7.1.0-rc2 and I get the usual VTK >>>> rendering canvas that is half the size of the widget that it is embedded >>>> into. >>>> >>>> We are using Qt 5.6.2 on macOS 10.10.5. I compiled my original pull request >>>> (way back in Aug 2016) and that patch gives me a full size canvas. But when >>>> compiling the latest VTK 7.1.0-rc2 I get the half size canvas. I thought the >>>> branch was merged on Sept 28 2016 but I guess I got busy and never actually >>>> tested it on a retina screen. >>>> >>>> Most likely I am doing something wrong in the initialization in my code but >>>> just in case can anyone else confirm with Qt 5.6.x that they can actually >>>> get a Retina/HiDPI canvas? >>>> >>>Bob has a retinal Mac that I can do some testing on, this is likely to >>>end up being after Supercomputing, but I would like to follow up on >>>this. We had it working when you visited, and I am hoping to get this >>>enabled in Tomviz at some point soon. It would be great to hear from >>>Sean and/or David. To the best of my recollection an alternate >>>approach was developed, and that was merged. It had several other >>>changes in addition to what was proposed originally. >> >> We merged my PR: >> >> >> and not Mike's: >> >> >> IIRC mine was a superset of Mike's, unless we screwed something up somewhere. I was always of the view that the changes were necessary but not sufficient. >> >> I'm swamped this week preparing for the SfN conference, but can look more next week... > > Bumping this old thread since I'm in this boat as well now. > > I've finally gotten around to porting our application to macOS. > Everything went pretty smooth. We're using 7.1.1, and we're using > QVTKWidget (will port to QVTKOpenGLWidget once 8.0.0 is out). > > I am however seeing the problem on a retina screen that VTK render > windows only take up a quarter of their alotted space. > > So my question: Is it possible to make VTK work fine on retina > displays with 7.1.1? If not, is there some patch I could apply? Or > will I have to build from Git (to be 8.0.0)? > So I worked on some pieces of this, but may not know all the moving parts. If you are using Qt 5 and want a retinal display application, then you should be using QVTKOpenGLWidget. If you are using Qt 4 then it will never work properly as Qt 4 lacks the support, or not to the best of my knowledge. We did quite a bit of work, but it focused on the QVTKOpenGLWidget and Qt 5, but you would need master or the 8.0 release. From elvis.stansvik at orexplore.com Thu May 11 11:50:58 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 11 May 2017 17:50:58 +0200 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: Den 11 maj 2017 5:25 em skrev "Marcus D. Hanwell" < marcus.hanwell at kitware.com>: > > On Thu, May 11, 2017 at 11:17 AM, Elvis Stansvik > wrote: > > 2016-11-07 19:58 GMT+01:00 Sean McBride : > >> On Fri, 4 Nov 2016 14:36:56 -0400, Marcus D. Hanwell said: > >> > >>>On Fri, Nov 4, 2016 at 8:28 AM, Michael Jackson > >>> wrote: > >>>> I just tried the HiDPI support on VTK 7.1.0-rc2 and I get the usual VTK > >>>> rendering canvas that is half the size of the widget that it is embedded > >>>> into. > >>>> > >>>> We are using Qt 5.6.2 on macOS 10.10.5. I compiled my original pull request > >>>> (way back in Aug 2016) and that patch gives me a full size canvas. But when > >>>> compiling the latest VTK 7.1.0-rc2 I get the half size canvas. I thought the > >>>> branch was merged on Sept 28 2016 but I guess I got busy and never actually > >>>> tested it on a retina screen. > >>>> > >>>> Most likely I am doing something wrong in the initialization in my code but > >>>> just in case can anyone else confirm with Qt 5.6.x that they can actually > >>>> get a Retina/HiDPI canvas? > >>>> > >>>Bob has a retinal Mac that I can do some testing on, this is likely to > >>>end up being after Supercomputing, but I would like to follow up on > >>>this. We had it working when you visited, and I am hoping to get this > >>>enabled in Tomviz at some point soon. It would be great to hear from > >>>Sean and/or David. To the best of my recollection an alternate > >>>approach was developed, and that was merged. It had several other > >>>changes in addition to what was proposed originally. > >> > >> We merged my PR: > >> > >> > >> and not Mike's: > >> > >> > >> IIRC mine was a superset of Mike's, unless we screwed something up somewhere. I was always of the view that the changes were necessary but not sufficient. > >> > >> I'm swamped this week preparing for the SfN conference, but can look more next week... > > > > Bumping this old thread since I'm in this boat as well now. > > > > I've finally gotten around to porting our application to macOS. > > Everything went pretty smooth. We're using 7.1.1, and we're using > > QVTKWidget (will port to QVTKOpenGLWidget once 8.0.0 is out). > > > > I am however seeing the problem on a retina screen that VTK render > > windows only take up a quarter of their alotted space. > > > > So my question: Is it possible to make VTK work fine on retina > > displays with 7.1.1? If not, is there some patch I could apply? Or > > will I have to build from Git (to be 8.0.0)? > > > So I worked on some pieces of this, but may not know all the moving > parts. If you are using Qt 5 and want a retinal display application, > then you should be using QVTKOpenGLWidget. If you are using Qt 4 then > it will never work properly as Qt 4 lacks the support, or not to the > best of my knowledge. We did quite a bit of work, but it focused on > the QVTKOpenGLWidget and Qt 5, but you would need master or the 8.0 > release. Alright, thanks for the info Marcus. I better switch to VTK master and try out the new widget for the macOS build then. Was planning on that anyway soon. Do you know if the 8.0.0 branching is on for the week of may 15 still? Elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu May 11 11:57:36 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 11 May 2017 17:57:36 +0200 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: Den 11 maj 2017 5:50 em skrev "Elvis Stansvik" : > > Den 11 maj 2017 5:25 em skrev "Marcus D. Hanwell" < marcus.hanwell at kitware.com>: > > > > On Thu, May 11, 2017 at 11:17 AM, Elvis Stansvik > > wrote: > > > 2016-11-07 19:58 GMT+01:00 Sean McBride : > > >> On Fri, 4 Nov 2016 14:36:56 -0400, Marcus D. Hanwell said: > > >> > > >>>On Fri, Nov 4, 2016 at 8:28 AM, Michael Jackson > > >>> wrote: > > >>>> I just tried the HiDPI support on VTK 7.1.0-rc2 and I get the usual VTK > > >>>> rendering canvas that is half the size of the widget that it is embedded > > >>>> into. > > >>>> > > >>>> We are using Qt 5.6.2 on macOS 10.10.5. I compiled my original pull request > > >>>> (way back in Aug 2016) and that patch gives me a full size canvas. But when > > >>>> compiling the latest VTK 7.1.0-rc2 I get the half size canvas. I thought the > > >>>> branch was merged on Sept 28 2016 but I guess I got busy and never actually > > >>>> tested it on a retina screen. > > >>>> > > >>>> Most likely I am doing something wrong in the initialization in my code but > > >>>> just in case can anyone else confirm with Qt 5.6.x that they can actually > > >>>> get a Retina/HiDPI canvas? > > >>>> > > >>>Bob has a retinal Mac that I can do some testing on, this is likely to > > >>>end up being after Supercomputing, but I would like to follow up on > > >>>this. We had it working when you visited, and I am hoping to get this > > >>>enabled in Tomviz at some point soon. It would be great to hear from > > >>>Sean and/or David. To the best of my recollection an alternate > > >>>approach was developed, and that was merged. It had several other > > >>>changes in addition to what was proposed originally. > > >> > > >> We merged my PR: > > >> > > >> > > >> and not Mike's: > > >> > > >> > > >> IIRC mine was a superset of Mike's, unless we screwed something up somewhere. I was always of the view that the changes were necessary but not sufficient. > > >> > > >> I'm swamped this week preparing for the SfN conference, but can look more next week... > > > > > > Bumping this old thread since I'm in this boat as well now. > > > > > > I've finally gotten around to porting our application to macOS. > > > Everything went pretty smooth. We're using 7.1.1, and we're using > > > QVTKWidget (will port to QVTKOpenGLWidget once 8.0.0 is out). > > > > > > I am however seeing the problem on a retina screen that VTK render > > > windows only take up a quarter of their alotted space. > > > > > > So my question: Is it possible to make VTK work fine on retina > > > displays with 7.1.1? If not, is there some patch I could apply? Or > > > will I have to build from Git (to be 8.0.0)? > > > > > So I worked on some pieces of this, but may not know all the moving > > parts. If you are using Qt 5 and want a retinal display application, > > then you should be using QVTKOpenGLWidget. If you are using Qt 4 then > > it will never work properly as Qt 4 lacks the support, or not to the > > best of my knowledge. We did quite a bit of work, but it focused on > > the QVTKOpenGLWidget and Qt 5, but you would need master or the 8.0 > > release. > > Alright, thanks for the info Marcus. I better switch to VTK master and try out the new widget for the macOS build then. Was planning on that anyway soon. But just so I'm clear, QVTKWidget won't work well, even with master? > > Do you know if the 8.0.0 branching is on for the week of may 15 still? > > Elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu May 11 13:13:27 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 11 May 2017 13:13:27 -0400 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: On Thu, May 11, 2017 at 11:57 AM, Elvis Stansvik wrote: > > Den 11 maj 2017 5:50 em skrev "Elvis Stansvik" : > > > > Den 11 maj 2017 5:25 em skrev "Marcus D. Hanwell" : > > > > > > On Thu, May 11, 2017 at 11:17 AM, Elvis Stansvik > > > wrote: > > > > 2016-11-07 19:58 GMT+01:00 Sean McBride : > > > >> On Fri, 4 Nov 2016 14:36:56 -0400, Marcus D. Hanwell said: > > > >> > > > >>>On Fri, Nov 4, 2016 at 8:28 AM, Michael Jackson > > > >>> wrote: > > > >>>> I just tried the HiDPI support on VTK 7.1.0-rc2 and I get the usual VTK > > > >>>> rendering canvas that is half the size of the widget that it is embedded > > > >>>> into. > > > >>>> > > > >>>> We are using Qt 5.6.2 on macOS 10.10.5. I compiled my original pull request > > > >>>> (way back in Aug 2016) and that patch gives me a full size canvas. But when > > > >>>> compiling the latest VTK 7.1.0-rc2 I get the half size canvas. I thought the > > > >>>> branch was merged on Sept 28 2016 but I guess I got busy and never actually > > > >>>> tested it on a retina screen. > > > >>>> > > > >>>> Most likely I am doing something wrong in the initialization in my code but > > > >>>> just in case can anyone else confirm with Qt 5.6.x that they can actually > > > >>>> get a Retina/HiDPI canvas? > > > >>>> > > > >>>Bob has a retinal Mac that I can do some testing on, this is likely to > > > >>>end up being after Supercomputing, but I would like to follow up on > > > >>>this. We had it working when you visited, and I am hoping to get this > > > >>>enabled in Tomviz at some point soon. It would be great to hear from > > > >>>Sean and/or David. To the best of my recollection an alternate > > > >>>approach was developed, and that was merged. It had several other > > > >>>changes in addition to what was proposed originally. > > > >> > > > >> We merged my PR: > > > >> > > > >> > > > >> and not Mike's: > > > >> > > > >> > > > >> IIRC mine was a superset of Mike's, unless we screwed something up somewhere. I was always of the view that the changes were necessary but not sufficient. > > > >> > > > >> I'm swamped this week preparing for the SfN conference, but can look more next week... > > > > > > > > Bumping this old thread since I'm in this boat as well now. > > > > > > > > I've finally gotten around to porting our application to macOS. > > > > Everything went pretty smooth. We're using 7.1.1, and we're using > > > > QVTKWidget (will port to QVTKOpenGLWidget once 8.0.0 is out). > > > > > > > > I am however seeing the problem on a retina screen that VTK render > > > > windows only take up a quarter of their alotted space. > > > > > > > > So my question: Is it possible to make VTK work fine on retina > > > > displays with 7.1.1? If not, is there some patch I could apply? Or > > > > will I have to build from Git (to be 8.0.0)? > > > > > > > So I worked on some pieces of this, but may not know all the moving > > > parts. If you are using Qt 5 and want a retinal display application, > > > then you should be using QVTKOpenGLWidget. If you are using Qt 4 then > > > it will never work properly as Qt 4 lacks the support, or not to the > > > best of my knowledge. We did quite a bit of work, but it focused on > > > the QVTKOpenGLWidget and Qt 5, but you would need master or the 8.0 > > > release. > > > > Alright, thanks for the info Marcus. I better switch to VTK master and try out the new widget for the macOS build then. Was planning on that anyway soon. > > But just so I'm clear, QVTKWidget won't work well, even with master? > It will work well with Qt 4, OK with Qt 5 but it will not give you a retinal resolution widget on macOS. Tomviz tracked the bleeding edge, and used QVTKWidget for a while with Qt 5 (a year or more), but there were several issues we never resolved. Developing the QVTKOpenGLWidget let us move past that, and was the first widget to yield VTK OpenGL rendering at full resolution on retinal macOS displays. From marcus.hanwell at kitware.com Thu May 11 13:14:27 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 11 May 2017 13:14:27 -0400 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: On Thu, May 11, 2017 at 11:50 AM, Elvis Stansvik wrote: > > Do you know if the 8.0.0 branching is on for the week of may 15 still? To the best of my knowledge yes, but our release team would have the most up to date information on that. From elvis.stansvik at orexplore.com Thu May 11 13:20:05 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 11 May 2017 19:20:05 +0200 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: 2017-05-11 19:13 GMT+02:00 Marcus D. Hanwell : > On Thu, May 11, 2017 at 11:57 AM, Elvis Stansvik > wrote: >> >> Den 11 maj 2017 5:50 em skrev "Elvis Stansvik" : >> > >> > Den 11 maj 2017 5:25 em skrev "Marcus D. Hanwell" : >> > > >> > > On Thu, May 11, 2017 at 11:17 AM, Elvis Stansvik >> > > wrote: >> > > > 2016-11-07 19:58 GMT+01:00 Sean McBride : >> > > >> On Fri, 4 Nov 2016 14:36:56 -0400, Marcus D. Hanwell said: >> > > >> >> > > >>>On Fri, Nov 4, 2016 at 8:28 AM, Michael Jackson >> > > >>> wrote: >> > > >>>> I just tried the HiDPI support on VTK 7.1.0-rc2 and I get the usual VTK >> > > >>>> rendering canvas that is half the size of the widget that it is embedded >> > > >>>> into. >> > > >>>> >> > > >>>> We are using Qt 5.6.2 on macOS 10.10.5. I compiled my original pull request >> > > >>>> (way back in Aug 2016) and that patch gives me a full size canvas. But when >> > > >>>> compiling the latest VTK 7.1.0-rc2 I get the half size canvas. I thought the >> > > >>>> branch was merged on Sept 28 2016 but I guess I got busy and never actually >> > > >>>> tested it on a retina screen. >> > > >>>> >> > > >>>> Most likely I am doing something wrong in the initialization in my code but >> > > >>>> just in case can anyone else confirm with Qt 5.6.x that they can actually >> > > >>>> get a Retina/HiDPI canvas? >> > > >>>> >> > > >>>Bob has a retinal Mac that I can do some testing on, this is likely to >> > > >>>end up being after Supercomputing, but I would like to follow up on >> > > >>>this. We had it working when you visited, and I am hoping to get this >> > > >>>enabled in Tomviz at some point soon. It would be great to hear from >> > > >>>Sean and/or David. To the best of my recollection an alternate >> > > >>>approach was developed, and that was merged. It had several other >> > > >>>changes in addition to what was proposed originally. >> > > >> >> > > >> We merged my PR: >> > > >> >> > > >> >> > > >> and not Mike's: >> > > >> >> > > >> >> > > >> IIRC mine was a superset of Mike's, unless we screwed something up somewhere. I was always of the view that the changes were necessary but not sufficient. >> > > >> >> > > >> I'm swamped this week preparing for the SfN conference, but can look more next week... >> > > > >> > > > Bumping this old thread since I'm in this boat as well now. >> > > > >> > > > I've finally gotten around to porting our application to macOS. >> > > > Everything went pretty smooth. We're using 7.1.1, and we're using >> > > > QVTKWidget (will port to QVTKOpenGLWidget once 8.0.0 is out). >> > > > >> > > > I am however seeing the problem on a retina screen that VTK render >> > > > windows only take up a quarter of their alotted space. >> > > > >> > > > So my question: Is it possible to make VTK work fine on retina >> > > > displays with 7.1.1? If not, is there some patch I could apply? Or >> > > > will I have to build from Git (to be 8.0.0)? >> > > > >> > > So I worked on some pieces of this, but may not know all the moving >> > > parts. If you are using Qt 5 and want a retinal display application, >> > > then you should be using QVTKOpenGLWidget. If you are using Qt 4 then >> > > it will never work properly as Qt 4 lacks the support, or not to the >> > > best of my knowledge. We did quite a bit of work, but it focused on >> > > the QVTKOpenGLWidget and Qt 5, but you would need master or the 8.0 >> > > release. >> > >> > Alright, thanks for the info Marcus. I better switch to VTK master and try out the new widget for the macOS build then. Was planning on that anyway soon. >> >> But just so I'm clear, QVTKWidget won't work well, even with master? >> > It will work well with Qt 4, OK with Qt 5 but it will not give you a > retinal resolution widget on macOS. Tomviz tracked the bleeding edge, > and used QVTKWidget for a while with Qt 5 (a year or more), but there > were several issues we never resolved. Developing the QVTKOpenGLWidget > let us move past that, and was the first widget to yield VTK OpenGL > rendering at full resolution on retinal macOS displays. Alright. Sounds like QVTKOpenGLWidget is the way to go then, sooner rather than later. I guess also good since it'll provide some pre-release testing of master in preparation for 8.0.0. Elvis From sankhesh.jhaveri at kitware.com Thu May 11 13:20:56 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Thu, 11 May 2017 17:20:56 +0000 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: Do you know if the 8.0.0 branching is on for the week of may 15 still? Yes. Note that this involves branching 8.0.0 in the coming week and consequently, starting the release process (release candidates, collating change notes, etc.). The final release and tagging will happen later. ? On Thu, May 11, 2017 at 1:14 PM Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Thu, May 11, 2017 at 11:50 AM, Elvis Stansvik > wrote: > > > > Do you know if the 8.0.0 branching is on for the week of may 15 still? > > To the best of my knowledge yes, but our release team would have the > most up to date information on that. > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu May 11 13:21:51 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 11 May 2017 19:21:51 +0200 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: 2017-05-11 19:14 GMT+02:00 Marcus D. Hanwell : > On Thu, May 11, 2017 at 11:50 AM, Elvis Stansvik > wrote: >> >> Do you know if the 8.0.0 branching is on for the week of may 15 still? > > To the best of my knowledge yes, but our release team would have the > most up to date information on that. Alright. I saw Sankesh's post to vtk-developers from a week ago go unanswered, so wasn't sure. Elvis From elvis.stansvik at orexplore.com Thu May 11 13:24:50 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 11 May 2017 19:24:50 +0200 Subject: [vtk-developers] [vtkusers] HiDPI not working on VTK 7.1.0 rc2 In-Reply-To: References: <581C7ED9.90003@bluequartz.net> <20161107185835.473800880@mail.rogue-research.com> Message-ID: 2017-05-11 19:20 GMT+02:00 Sankhesh Jhaveri : > > Do you know if the 8.0.0 branching is on for the week of may 15 still? > > Yes. Note that this involves branching 8.0.0 in the coming week and > consequently, starting the release process (release candidates, collating > change notes, etc.). The final release and tagging will happen later. Yep, I know that's just the start of the provess. That first -rc tarball is what I really hunger for. Then I can switch our internal BuildBot jobs for Debian packages and Windows build to use that, and use my collegues as guinea pigs :) Elvis > > > On Thu, May 11, 2017 at 1:14 PM Marcus D. Hanwell > wrote: >> >> On Thu, May 11, 2017 at 11:50 AM, Elvis Stansvik >> wrote: >> > >> > Do you know if the 8.0.0 branching is on for the week of may 15 still? >> >> To the best of my knowledge yes, but our release team would have the >> most up to date information on that. >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- > > Sankhesh Jhaveri > > Sr. Research & Development Engineer | Kitware | (518) 881-4417 From spir.robert at gmail.com Fri May 12 04:25:58 2017 From: spir.robert at gmail.com (RobertS) Date: Fri, 12 May 2017 01:25:58 -0700 (MST) Subject: [vtk-developers] Crash in subdivision filters Message-ID: <1494577558914-5743200.post@n5.nabble.com> Im working with subdivision filters and there is a reproducible case where both vtkLoopSubdivisionFilter and vtkButterflySubdivisionFilter crash. Try the example at http://www.vtk.org/Wiki/VTK/Examples/Cxx/Meshes/Subdivision and modify it that the sphere has higher number of triangles by adding lines sphereSource->SetPhiResolution(500); sphereSource->SetThetaResolution(500); before sphereSource->Update(); After that, vtkLinearSubdivisionFilter works fine but both other filters crash. This happens in both 7.1.1 and master version, in windows and in linux Robert -- View this message in context: http://vtk.1045678.n5.nabble.com/Crash-in-subdivision-filters-tp5743200.html Sent from the VTK - Dev mailing list archive at Nabble.com. From andrew.amaclean at gmail.com Sat May 13 02:35:18 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sat, 13 May 2017 16:35:18 +1000 Subject: [vtk-developers] VTK Examples - congratulations to Bill Message-ID: Hi Bill, Thankyou so much for all the effort you have put into the VTK Examples: https://gitlab.kitware.com/lorensen/VTKExamples/wikis/Home It is so much easier to use than the old version. I have been "kicking the tyres", so to speak, and the process of updating is so much better than the old system. Thanks again for all your hard work and effort. I really appreciate it. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sun May 14 15:08:23 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 14 May 2017 15:08:23 -0400 Subject: [vtk-developers] Static pages for VTKExamples Message-ID: Folks, Take a look here: https://lorensen.github.io/VTKExamples/site These are static HTML pages that I think google will find. looks pretty good on my phone. Also, the style is much cleaner than: https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home Bill From andrew.amaclean at gmail.com Sun May 14 16:15:13 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 15 May 2017 06:15:13 +1000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Much nicer however numbered lists don't seem to be generated, see https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/ElevationBandsWithGlyphs/ for example. Andrew Maclean On 15 May 2017 05:08, "Bill Lorensen" wrote: > Folks, > > Take a look here: > https://lorensen.github.io/VTKExamples/site > > These are static HTML pages that I think google will find. looks > pretty good on my phone. > > Also, the style is much cleaner than: > https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sun May 14 16:44:03 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 14 May 2017 16:44:03 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: I'll take a look at numbered lists BTW, at the top left of each page, the 3 bar icon is a navigation bar. On May 14, 2017 4:15 PM, "Andrew Maclean" wrote: > Much nicer however numbered lists don't seem to be generated, see > https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/ > ElevationBandsWithGlyphs/ for example. > > Andrew Maclean > > On 15 May 2017 05:08, "Bill Lorensen" wrote: > >> Folks, >> >> Take a look here: >> https://lorensen.github.io/VTKExamples/site >> >> These are static HTML pages that I think google will find. looks >> pretty good on my phone. >> >> Also, the style is much cleaner than: >> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >> >> Bill >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sun May 14 19:14:12 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 15 May 2017 09:14:12 +1000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Hi Bill, I really like it. This is what I see when using Google Chrome. If the screen is small I see the 3 Bar Icon. When the screen is expanded the 3 Bar Icon disappears and a menu appears on the left. I like the additional drop down list that appears under the links. For instance I have clicked on Cxx and the index comes up in the main part of the screen. When you click on Cxx with the down arrow a list opens up and clicking here lets you go directly to the code you want. Nice! BTW I have added merge requests with fixes to the links, especially for NamedColorPatches and Parametric Surfaces. So don't worry if the links don't work, the fixes are in the merge requests. This new way of doing things makes it so much easier. Regards Andrew On Mon, May 15, 2017 at 6:44 AM, Bill Lorensen wrote: > I'll take a look at numbered lists > > > BTW, at the top left of each page, the 3 bar icon is a navigation bar. > > On May 14, 2017 4:15 PM, "Andrew Maclean" > wrote: > >> Much nicer however numbered lists don't seem to be generated, see >> https://lorensen.github.io/VTKExamples/site/Cxx/Visualiz >> ation/ElevationBandsWithGlyphs/ for example. >> >> Andrew Maclean >> >> On 15 May 2017 05:08, "Bill Lorensen" wrote: >> >>> Folks, >>> >>> Take a look here: >>> https://lorensen.github.io/VTKExamples/site >>> >>> These are static HTML pages that I think google will find. looks >>> pretty good on my phone. >>> >>> Also, the style is much cleaner than: >>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >>> >>> Bill >>> >> -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20170515_085749.png Type: image/png Size: 61789 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20170515_085650.png Type: image/png Size: 73187 bytes Desc: not available URL: From andrew.amaclean at gmail.com Sun May 14 19:29:13 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 15 May 2017 09:29:13 +1000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Bill, There is an error in the paths specified in the links in the main menu when you click on Cxx and then Visualisation and the Example name in the table. The link is missing "site" in the address: https://lorensen.github.io/VTKExamples/Cxx/Visualization/NamedColorPatches This does work (from the sidebar): https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColorPatches/ Regards Andrew On Mon, May 15, 2017 at 9:14 AM, Andrew Maclean wrote: > Hi Bill, > > I really like it. > > This is what I see when using Google Chrome. > > If the screen is small I see the 3 Bar Icon. When the screen is expanded > the 3 Bar Icon disappears and a menu appears on the left. I like the > additional drop down list that appears under the links. For instance I have > clicked on Cxx and the index comes up in the main part of the screen. When > you click on Cxx with the down arrow a list opens up and clicking here lets > you go directly to the code you want. Nice! > > BTW I have added merge requests with fixes to the links, especially > for NamedColorPatches and Parametric Surfaces. So don't worry if the links > don't work, the fixes are in the merge requests. This new way of doing > things makes it so much easier. > > Regards > Andrew > > > On Mon, May 15, 2017 at 6:44 AM, Bill Lorensen > wrote: > >> I'll take a look at numbered lists >> >> >> BTW, at the top left of each page, the 3 bar icon is a navigation bar. >> >> On May 14, 2017 4:15 PM, "Andrew Maclean" >> wrote: >> >>> Much nicer however numbered lists don't seem to be generated, see >>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualiz >>> ation/ElevationBandsWithGlyphs/ for example. >>> >>> Andrew Maclean >>> >>> On 15 May 2017 05:08, "Bill Lorensen" wrote: >>> >>>> Folks, >>>> >>>> Take a look here: >>>> https://lorensen.github.io/VTKExamples/site >>>> >>>> These are static HTML pages that I think google will find. looks >>>> pretty good on my phone. >>>> >>>> Also, the style is much cleaner than: >>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >>>> >>>> Bill >>>> >>> > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sun May 14 20:37:36 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 14 May 2017 20:37:36 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Apparently mkdocs wants a space before each number list item. I fixed them. On Sun, May 14, 2017 at 7:29 PM, Andrew Maclean wrote: > Bill, > There is an error in the paths specified in the links in the main menu when > you click on Cxx and then Visualisation and the Example name in the table. > > The link is missing "site" in the address: > https://lorensen.github.io/VTKExamples/Cxx/Visualization/NamedColorPatches > > This does work (from the sidebar): > https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColorPatches/ > > Regards > Andrew > > > On Mon, May 15, 2017 at 9:14 AM, Andrew Maclean > wrote: >> >> Hi Bill, >> >> I really like it. >> >> This is what I see when using Google Chrome. >> >> If the screen is small I see the 3 Bar Icon. When the screen is expanded >> the 3 Bar Icon disappears and a menu appears on the left. I like the >> additional drop down list that appears under the links. For instance I have >> clicked on Cxx and the index comes up in the main part of the screen. When >> you click on Cxx with the down arrow a list opens up and clicking here lets >> you go directly to the code you want. Nice! >> >> BTW I have added merge requests with fixes to the links, especially for >> NamedColorPatches and Parametric Surfaces. So don't worry if the links don't >> work, the fixes are in the merge requests. This new way of doing things >> makes it so much easier. >> >> Regards >> Andrew >> >> >> On Mon, May 15, 2017 at 6:44 AM, Bill Lorensen >> wrote: >>> >>> I'll take a look at numbered lists >>> >>> >>> BTW, at the top left of each page, the 3 bar icon is a navigation bar. >>> >>> On May 14, 2017 4:15 PM, "Andrew Maclean" >>> wrote: >>>> >>>> Much nicer however numbered lists don't seem to be generated, see >>>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/ElevationBandsWithGlyphs/ >>>> for example. >>>> >>>> Andrew Maclean >>>> >>>> On 15 May 2017 05:08, "Bill Lorensen" wrote: >>>>> >>>>> Folks, >>>>> >>>>> Take a look here: >>>>> https://lorensen.github.io/VTKExamples/site >>>>> >>>>> These are static HTML pages that I think google will find. looks >>>>> pretty good on my phone. >>>>> >>>>> Also, the style is much cleaner than: >>>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >>>>> >>>>> Bill >> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ > > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ -- Unpaid intern in BillsBasement at noware dot com From andrew.amaclean at gmail.com Mon May 15 02:02:18 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 15 May 2017 16:02:18 +1000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Thanks Bill, I updated my current merge requests to add leading spaces. I have also added a new merge request for a Python example called PointDataSubdivision.py. I did add a test image in the hope this will be picked up for the html static pages. There is no C++ version of this yet! Regards Andrew On Mon, May 15, 2017 at 10:37 AM, Bill Lorensen wrote: > Apparently mkdocs wants a space before each number list item. > > I fixed them. > > On Sun, May 14, 2017 at 7:29 PM, Andrew Maclean > wrote: > > Bill, > > There is an error in the paths specified in the links in the main menu > when > > you click on Cxx and then Visualisation and the Example name in the > table. > > > > The link is missing "site" in the address: > > https://lorensen.github.io/VTKExamples/Cxx/Visualization/ > NamedColorPatches > > > > This does work (from the sidebar): > > https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/ > NamedColorPatches/ > > > > Regards > > Andrew > > > > > > On Mon, May 15, 2017 at 9:14 AM, Andrew Maclean < > andrew.amaclean at gmail.com> > > wrote: > >> > >> Hi Bill, > >> > >> I really like it. > >> > >> This is what I see when using Google Chrome. > >> > >> If the screen is small I see the 3 Bar Icon. When the screen is expanded > >> the 3 Bar Icon disappears and a menu appears on the left. I like the > >> additional drop down list that appears under the links. For instance I > have > >> clicked on Cxx and the index comes up in the main part of the screen. > When > >> you click on Cxx with the down arrow a list opens up and clicking here > lets > >> you go directly to the code you want. Nice! > >> > >> BTW I have added merge requests with fixes to the links, especially for > >> NamedColorPatches and Parametric Surfaces. So don't worry if the links > don't > >> work, the fixes are in the merge requests. This new way of doing things > >> makes it so much easier. > >> > >> Regards > >> Andrew > >> > >> > >> On Mon, May 15, 2017 at 6:44 AM, Bill Lorensen > > >> wrote: > >>> > >>> I'll take a look at numbered lists > >>> > >>> > >>> BTW, at the top left of each page, the 3 bar icon is a navigation bar. > >>> > >>> On May 14, 2017 4:15 PM, "Andrew Maclean" > >>> wrote: > >>>> > >>>> Much nicer however numbered lists don't seem to be generated, see > >>>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/ > ElevationBandsWithGlyphs/ > >>>> for example. > >>>> > >>>> Andrew Maclean > >>>> > >>>> On 15 May 2017 05:08, "Bill Lorensen" > wrote: > >>>>> > >>>>> Folks, > >>>>> > >>>>> Take a look here: > >>>>> https://lorensen.github.io/VTKExamples/site > >>>>> > >>>>> These are static HTML pages that I think google will find. looks > >>>>> pretty good on my phone. > >>>>> > >>>>> Also, the style is much cleaner than: > >>>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home > >>>>> > >>>>> Bill > >> > >> > >> > >> > >> -- > >> ___________________________________________ > >> Andrew J. P. Maclean > >> > >> ___________________________________________ > > > > > > > > > > -- > > ___________________________________________ > > Andrew J. P. Maclean > > > > ___________________________________________ > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon May 15 06:34:55 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 15 May 2017 06:34:55 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Bill this is a prototype correct? I ask because if you travel down the hierarchy Cxx Examples -> Input & Output -> 3D File Formats -> VTK Formats -> Input and then click on "ReadUnstructuredGrid" it 404s me. On Sun, May 14, 2017 at 3:08 PM, Bill Lorensen wrote: > Folks, > > Take a look here: > https://lorensen.github.io/VTKExamples/site > > These are static HTML pages that I think google will find. looks > pretty good on my phone. > > Also, the style is much cleaner than: > https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home > > Bill > _______________________________________________ > 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: > http://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 andrew.amaclean at gmail.com Mon May 15 06:54:27 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 15 May 2017 20:54:27 +1000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Hi Will, The correct link is this: https://lorensen.github. io/VTKExamples/site/Cxx/IO/ReadUnstructuredGrid/ You will see the link you are going to is missing "site". I emailed Bill about this but he was most likely asleep given the time difference. I also forgot to share the email ... my bad! Here is a copy of what I said: ------------------ Bill, There is an error in the paths specified in the links in the main menu when you click on Cxx and then Visualisation and the Example name in the table. The link is missing "site" in the address: https://lorensen.github.io/VTKExamples/Cxx/Visualization/NamedColorPatches This does work (from the sidebar): https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/ NamedColorPatches/ ------------------ Regards Andrew Andrew Maclean On 15 May 2017 20:35, "Will Schroeder" wrote: > Bill this is a prototype correct? I ask because if you travel down the > hierarchy Cxx Examples -> Input & Output -> 3D File Formats -> VTK Formats > -> Input and then click on "ReadUnstructuredGrid" it 404s me. > > On Sun, May 14, 2017 at 3:08 PM, Bill Lorensen > wrote: > >> Folks, >> >> Take a look here: >> https://lorensen.github.io/VTKExamples/site >> >> These are static HTML pages that I think google will find. looks >> pretty good on my phone. >> >> Also, the style is much cleaner than: >> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >> >> Bill >> _______________________________________________ >> 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: >> http://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 bill.lorensen at gmail.com Mon May 15 07:43:57 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 May 2017 07:43:57 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Will I'm still working out the kinks. Before I go too much further, I want to get feedback on which of the two approaches is better. I will look at those missing links. On May 15, 2017 6:35 AM, "Will Schroeder" wrote: > Bill this is a prototype correct? I ask because if you travel down the > hierarchy Cxx Examples -> Input & Output -> 3D File Formats -> VTK Formats > -> Input and then click on "ReadUnstructuredGrid" it 404s me. > > On Sun, May 14, 2017 at 3:08 PM, Bill Lorensen > wrote: > >> Folks, >> >> Take a look here: >> https://lorensen.github.io/VTKExamples/site >> >> These are static HTML pages that I think google will find. looks >> pretty good on my phone. >> >> Also, the style is much cleaner than: >> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >> >> Bill >> _______________________________________________ >> 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: >> http://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 c.sell at byterefinery.de Mon May 15 09:17:35 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Mon, 15 May 2017 13:17:35 +0000 Subject: [vtk-developers] VTK and Qt5 / QML Message-ID: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> Hello all, I am looking into the possibility of replacing the 3D rendering engine in my Qt5 / QML based mobile tablet-oriented application with VTK. What I need is a first class QtQuick integration (not a hack or workaround) that is 100% stable in every context (not an unusual requirement, I admit). To my amazement, nothing of that kind seems to exist (correct me if I'm wrong). I went on to investigate what had been done so far and to implement my first prototypes, using the QQuickFrameBufferObject approach. From the very start this felt like an uphill battle, because VTK seems to come from a Windowing background and is quite tightly integrated with concepts that are not valid in a QML context. I'll describe my findings together with the 2 prototypical QML items I implemented: 1st was an adaptation of the DICOM example which now runs as a QML item. All user interaction is handled by QML and forwarded to VTK (which is one thing that doesn't come naturally with VTK), and after some non-elegant tweaking I was able to have the UI move from slice to slice and re-render upon mouse wheel events as expected. The problem here was, that QML insists on keeping mouse event handling and OpenGL rendering on separate threads, with one "rendering thread" dedicated to OpenGL. However, the pre-existing VTK Interactors directly call Render() after reconfiguring the UI from the mouse event data, which is an absolute QML No-Go. I had to introduce a RenderDelegate that works somewhat like this: QML mouse event: tell RenderDelegate about the event call update() on the QML item, which triggers rer-endering on the dedicated thread on the QML rendering thread: call Render() on the RenderWindow inside the RenderDelegate, look at whether a mouse event is pending, and call the corresponding VTK mouse handler call the renderer's default Render() function while setting the delegate's "Used" flag to false 2nd was a QML item that displays a model loaded from a 3ds file. My goal here was to move the model around using mouse drag events. I took the lessons learned from the first example, threw in a vtkInteractorStyleTrackballCamera and hoped for the best. First thing I found was that I needed a specialized RenderWindowInteractor, which I provided. When I realized that the most important requirement for that class was to provide access to timer functionality, I already got wary, as throwing around events and doing stuff offline while on the QML rendering thread is never a good idea. My fears came true when I finished wiring everything together: I was able to move the model using the mouse, but after a few moments things got whacky with error output written to the console and finally a segemtation fault from deep inside VTK. I still need to investigate the second example, but would like to synchronize with the community at this point in order to avoid errors/misconceptions on my side, to seek help if possible and to offer my contribution to the VTK code base once this becomes functional. My first impression is that there are some issues that lie on an architectural level and cannot be (elegantly) dealt with on the QML side alone. Any comments? thanks, Christian Sell From elvis.stansvik at orexplore.com Mon May 15 10:07:03 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 15 May 2017 16:07:03 +0200 Subject: [vtk-developers] Heads up: libharu is unmaintained Message-ID: Hi all, I was trying out a Git master build today, in preparation for moving to VTK 8, and noticed that VTK now depends on (and bundles) the libharu PDF library, for the PDF exporter. I also happened to notice that it's currently unmaintained. From their website [1]: "Looking for a new maintainer! The project seems to be in more or less good shape (as in `it still compiles and works`), but it hasn't been actively maintained and/or developed for a few years and badly needs a new maintainer. If you think you can do it and have some spare time to spend on it (not too much), don't hesitate to introduce yourself on the mailing list: libharu at googlegroups.com (you might want to subscribe to it first)." So perhaps it'll resolve itself with that call for help, but just thought as a heads up, in case you weren't aware and don't want to add new stuff depending on unmaintained libraries. Not a big deal really, and I guess the appeal of libharu is that it's very small. Alternatives like PoDoFo [2] are actively maintained, but bigger of course. Cheers, Elvis [1] http://libharu.org/ [2] http://podofo.sourceforge.net/ From david.lonie at kitware.com Mon May 15 10:16:03 2017 From: david.lonie at kitware.com (David Lonie) Date: Mon, 15 May 2017 10:16:03 -0400 Subject: [vtk-developers] Heads up: libharu is unmaintained In-Reply-To: References: Message-ID: Thanks Elvis, I do appreciate the warning! For some background, we noticed that it was unmaintained before we decided to use it. Since libharu covers most of the functionality we need with a few minor changes, and it has proven to be mature enough to be stable and reliable, we decided to go ahead and use it anyway. Plus, licensing is always a headache -- libharu is BSD compatible, while PoDoFo is not (LGPL), so that played a major role in the decision as well :-) Thanks, Dave On Mon, May 15, 2017 at 10:07 AM, Elvis Stansvik wrote: > Hi all, > > I was trying out a Git master build today, in preparation for moving > to VTK 8, and noticed that VTK now depends on (and bundles) the > libharu PDF library, for the PDF exporter. > > I also happened to notice that it's currently unmaintained. From their > website [1]: > > "Looking for a new maintainer! > > The project seems to be in more or less good shape (as in `it still > compiles and works`), but it hasn't been actively maintained and/or > developed for a few years and badly needs a new maintainer. If you > think you can do it and have some spare time to spend on it (not too > much), don't hesitate to introduce yourself on the mailing list: > libharu at googlegroups.com (you might want to subscribe to it first)." > > So perhaps it'll resolve itself with that call for help, but just > thought as a heads up, in case you weren't aware and don't want to add > new stuff depending on unmaintained libraries. > > Not a big deal really, and I guess the appeal of libharu is that it's > very small. Alternatives like PoDoFo [2] are actively maintained, but > bigger of course. > > Cheers, > Elvis > > [1] http://libharu.org/ > [2] http://podofo.sourceforge.net/ > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Mon May 15 10:50:58 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 15 May 2017 16:50:58 +0200 Subject: [vtk-developers] Heads up: libharu is unmaintained In-Reply-To: References: Message-ID: 2017-05-15 16:16 GMT+02:00 David Lonie : > Thanks Elvis, I do appreciate the warning! > > For some background, we noticed that it was unmaintained before we > decided to use it. Since libharu covers most of the functionality we > need with a few minor changes, and it has proven to be mature enough > to be stable and reliable, we decided to go ahead and use it anyway. > Plus, licensing is always a headache -- libharu is BSD compatible, > while PoDoFo is not (LGPL), so that played a major role in the > decision as well :-) Ah, that makes sense. Good good. Elvis > > Thanks, > Dave > > On Mon, May 15, 2017 at 10:07 AM, Elvis Stansvik > wrote: >> Hi all, >> >> I was trying out a Git master build today, in preparation for moving >> to VTK 8, and noticed that VTK now depends on (and bundles) the >> libharu PDF library, for the PDF exporter. >> >> I also happened to notice that it's currently unmaintained. From their >> website [1]: >> >> "Looking for a new maintainer! >> >> The project seems to be in more or less good shape (as in `it still >> compiles and works`), but it hasn't been actively maintained and/or >> developed for a few years and badly needs a new maintainer. If you >> think you can do it and have some spare time to spend on it (not too >> much), don't hesitate to introduce yourself on the mailing list: >> libharu at googlegroups.com (you might want to subscribe to it first)." >> >> So perhaps it'll resolve itself with that call for help, but just >> thought as a heads up, in case you weren't aware and don't want to add >> new stuff depending on unmaintained libraries. >> >> Not a big deal really, and I guess the appeal of libharu is that it's >> very small. Alternatives like PoDoFo [2] are actively maintained, but >> bigger of course. >> >> Cheers, >> Elvis >> >> [1] http://libharu.org/ >> [2] http://podofo.sourceforge.net/ >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> From rcourant at gmail.com Mon May 15 11:42:27 2017 From: rcourant at gmail.com (Carlos Lopez) Date: Mon, 15 May 2017 11:42:27 -0400 Subject: [vtk-developers] Volume visualization with OpenVR Message-ID: Hello, I'm visualizing a dataset from the visible human project using openVR and I notice that when the camera is outside of the bounds of the dataset, the data renders in a way that the bounding box is noticeable; because of the stereo projection, It is possible to see that the volumetric data is projected onto the faces of the bounding box (this is not visible in 2D, either from a monitor or if I close one eye in the HMD). If the camera is inside the bounding box, then the data renders in a way that this effect is no longer visible, the projection plane parallel to the current view removes the small discontinuity and the 3D perspective is restored. Is it possible to configure the volume rendering so that it always behaves as if the camera is inside the dataset? thanks, carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon May 15 12:09:54 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 May 2017 12:09:54 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: I think I fixed the link issues. On Mon, May 15, 2017 at 7:43 AM, Bill Lorensen wrote: > Will > > I'm still working out the kinks. Before I go too much further, I want to > get feedback on which of the two approaches is better. > > I will look at those missing links. > > On May 15, 2017 6:35 AM, "Will Schroeder" > wrote: >> >> Bill this is a prototype correct? I ask because if you travel down the >> hierarchy Cxx Examples -> Input & Output -> 3D File Formats -> VTK Formats >> -> Input and then click on "ReadUnstructuredGrid" it 404s me. >> >> On Sun, May 14, 2017 at 3:08 PM, Bill Lorensen >> wrote: >>> >>> Folks, >>> >>> Take a look here: >>> https://lorensen.github.io/VTKExamples/site >>> >>> These are static HTML pages that I think google will find. looks >>> pretty good on my phone. >>> >>> Also, the style is much cleaner than: >>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >>> >>> Bill >>> _______________________________________________ >>> 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: >>> http://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 -- Unpaid intern in BillsBasement at noware dot com From aashish.chaudhary at kitware.com Mon May 15 12:18:14 2017 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 15 May 2017 16:18:14 +0000 Subject: [vtk-developers] Volume visualization with OpenVR In-Reply-To: References: Message-ID: Hi Carlos, Can you send a picture of the effect you are mentioning? We have a demo that uses VR in OpenVR but we didn't notice the artifact that you have mentioned but we also have not spent as much time as you did. - Aashish On Mon, May 15, 2017 at 11:42 AM Carlos Lopez wrote: > Hello, > > I'm visualizing a dataset from the visible human project using openVR and > I notice that when the camera is outside of the bounds of the dataset, the > data renders in a way that the bounding box is noticeable; because of the > stereo projection, It is possible to see that the volumetric data is > projected onto the faces of the bounding box (this is not visible in 2D, > either from a monitor or if I close one eye in the HMD). > > If the camera is inside the bounding box, then the data renders in a way > that this effect is no longer visible, the projection plane parallel to the > current view removes the small discontinuity and the 3D perspective is > restored. > > Is it possible to configure the volume rendering so that it always behaves > as if the camera is inside the dataset? > > thanks, > carlos > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Mon May 15 14:09:28 2017 From: lasso at queensu.ca (Andras Lasso) Date: Mon, 15 May 2017 18:09:28 +0000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Google indexing dynamic pages should not be an issue (most websites are dynamic), it may just require some tuning. However, there are a couple of other potential issues with using the wiki for hosting examples. Versioning may be a one of the most difficult problem to solve. We use MediaWiki to maintain Slicer documentation and we've found that maintaining up-to-date documentation for multiple versions is unsustainable (you have to create a large number of wiki pages for each software version), creates confusion (as Google keeps directing users to pages belonging to random software versions), and limits access (you cannot distribute documentation as a package that can be used offline). Hosting documentation on a github or other documentation-oriented service (such as readthedocs) does not have these issues. Another problem hosting on the wiki (again, learned lessons from Slicer) that mixing user-written content with automatically-generated content discourages users from contributing, as it becomes unclear which page is generated manually/automatically, how pages can be modified when they are automatically generated. Also number and size of automatically generated pages (especially when pages are generated for each software version) can be very big. Maintaining history for automatically generated pages is not necessary and if it cannot be avoided then it could be an additional burden on the wiki. Searching on the wiki seems to be quite limited on the wiki (at least as it is set up now). For example, searching for Subdivision has 3 hits on the github version and none on the wiki. Andras -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Bill Lorensen Sent: Monday, May 15, 2017 12:10 PM To: Will Cc: VTK Developers ; Andrew Maclean Subject: Re: [vtk-developers] Static pages for VTKExamples I think I fixed the link issues. On Mon, May 15, 2017 at 7:43 AM, Bill Lorensen wrote: > Will > > I'm still working out the kinks. Before I go too much further, I > want to get feedback on which of the two approaches is better. > > I will look at those missing links. > > On May 15, 2017 6:35 AM, "Will Schroeder" > wrote: >> >> Bill this is a prototype correct? I ask because if you travel down >> the hierarchy Cxx Examples -> Input & Output -> 3D File Formats -> >> VTK Formats >> -> Input and then click on "ReadUnstructuredGrid" it 404s me. >> >> On Sun, May 14, 2017 at 3:08 PM, Bill Lorensen >> >> wrote: >>> >>> Folks, >>> >>> Take a look here: >>> https://lorensen.github.io/VTKExamples/site >>> >>> These are static HTML pages that I think google will find. looks >>> pretty good on my phone. >>> >>> Also, the style is much cleaner than: >>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >>> >>> Bill >>> _______________________________________________ >>> 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: >>> http://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 -- Unpaid intern in BillsBasement at noware dot com _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers From ben.boeckel at kitware.com Mon May 15 14:33:29 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 15 May 2017 14:33:29 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: <20170515183329.GA19790@megas.kitware.com> On Mon, May 15, 2017 at 18:09:28 +0000, Andras Lasso wrote: > Versioning may be a one of the most difficult problem to solve. We use > MediaWiki to maintain Slicer documentation and we've found that > maintaining up-to-date documentation for multiple versions is > unsustainable (you have to create a large number of wiki pages for > each software version), creates confusion (as Google keeps directing > users to pages belonging to random software versions), and limits > access (you cannot distribute documentation as a package that can be > used offline). Hosting documentation on a github or other > documentation-oriented service (such as readthedocs) does not have > these issues. Note that Gitlab's wiki is available via git: https://gitlab.kitware.com/lorensen/VTKExamples.wiki.git --Ben From lasso at queensu.ca Mon May 15 15:57:25 2017 From: lasso at queensu.ca (Andras Lasso) Date: Mon, 15 May 2017 19:57:25 +0000 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: <20170515183329.GA19790@megas.kitware.com> References: <20170515183329.GA19790@megas.kitware.com> Message-ID: If VTK examples have their own dedicated wiki (and not mixed with user-contributed content) then it's a different story, most of the problems that I wrote about have much less impact. But then why would you use wiki instead of other, well-established documentation generator tools? Auto-generated content would not benefit from collaborative editing capabilities of wiki, but you would still pay the price of it (in that you need a server to run it, it is probably less efficient than serving static html, you are more restricted in structure, formatting, etc). Andras -----Original Message----- From: Ben Boeckel [mailto:ben.boeckel at kitware.com] Sent: Monday, May 15, 2017 2:33 PM To: Andras Lasso Cc: Bill Lorensen ; Will ; VTK Developers ; Andrew Maclean Subject: Re: [vtk-developers] Static pages for VTKExamples On Mon, May 15, 2017 at 18:09:28 +0000, Andras Lasso wrote: > Versioning may be a one of the most difficult problem to solve. We use > MediaWiki to maintain Slicer documentation and we've found that > maintaining up-to-date documentation for multiple versions is > unsustainable (you have to create a large number of wiki pages for > each software version), creates confusion (as Google keeps directing > users to pages belonging to random software versions), and limits > access (you cannot distribute documentation as a package that can be > used offline). Hosting documentation on a github or other > documentation-oriented service (such as readthedocs) does not have > these issues. Note that Gitlab's wiki is available via git: https://gitlab.kitware.com/lorensen/VTKExamples.wiki.git --Ben From bill.lorensen at gmail.com Mon May 15 16:13:22 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 May 2017 16:13:22 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: References: Message-ID: Andras, The current VTK Examples have been hosted on a mediawiki site for 6 or 7 years. The new approach is to use either github or gitlab. The new VTKExamples (which is still experimental) is a gitlab wiki so versioning is not an issue. I don't believe it is searched bu google. The second approach uses github pages to host a static wiki. The look and feel of the github pages is much better than that of the gitlab wiki. It also renders large pages much faster. https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home versus https://lorensen.github.io/VTKExamples/site BTW, both sites are generated automatically from the source code tree. Addition documentation of examples is written in markdown. Bill On Mon, May 15, 2017 at 2:09 PM, Andras Lasso wrote: > Google indexing dynamic pages should not be an issue (most websites are dynamic), it may just require some tuning. > > However, there are a couple of other potential issues with using the wiki for hosting examples. > > Versioning may be a one of the most difficult problem to solve. We use MediaWiki to maintain Slicer documentation and we've found that maintaining up-to-date documentation for multiple versions is unsustainable (you have to create a large number of wiki pages for each software version), creates confusion (as Google keeps directing users to pages belonging to random software versions), and limits access (you cannot distribute documentation as a package that can be used offline). Hosting documentation on a github or other documentation-oriented service (such as readthedocs) does not have these issues. > > Another problem hosting on the wiki (again, learned lessons from Slicer) that mixing user-written content with automatically-generated content discourages users from contributing, as it becomes unclear which page is generated manually/automatically, how pages can be modified when they are automatically generated. Also number and size of automatically generated pages (especially when pages are generated for each software version) can be very big. Maintaining history for automatically generated pages is not necessary and if it cannot be avoided then it could be an additional burden on the wiki. > > Searching on the wiki seems to be quite limited on the wiki (at least as it is set up now). For example, searching for Subdivision has 3 hits on the github version and none on the wiki. > > Andras > > > -----Original Message----- > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Bill Lorensen > Sent: Monday, May 15, 2017 12:10 PM > To: Will > Cc: VTK Developers ; Andrew Maclean > Subject: Re: [vtk-developers] Static pages for VTKExamples > > I think I fixed the link issues. > > > On Mon, May 15, 2017 at 7:43 AM, Bill Lorensen wrote: >> Will >> >> I'm still working out the kinks. Before I go too much further, I >> want to get feedback on which of the two approaches is better. >> >> I will look at those missing links. >> >> On May 15, 2017 6:35 AM, "Will Schroeder" >> wrote: >>> >>> Bill this is a prototype correct? I ask because if you travel down >>> the hierarchy Cxx Examples -> Input & Output -> 3D File Formats -> >>> VTK Formats >>> -> Input and then click on "ReadUnstructuredGrid" it 404s me. >>> >>> On Sun, May 14, 2017 at 3:08 PM, Bill Lorensen >>> >>> wrote: >>>> >>>> Folks, >>>> >>>> Take a look here: >>>> https://lorensen.github.io/VTKExamples/site >>>> >>>> These are static HTML pages that I think google will find. looks >>>> pretty good on my phone. >>>> >>>> Also, the style is much cleaner than: >>>> https://gitlab.kitware.com/lorensen/VTKExamples/wikis/home >>>> >>>> Bill >>>> _______________________________________________ >>>> 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: >>>> http://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 > > > > -- > Unpaid intern in BillsBasement at noware dot com _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Mon May 15 16:15:00 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 May 2017 16:15:00 -0400 Subject: [vtk-developers] Static pages for VTKExamples In-Reply-To: <20170515183329.GA19790@megas.kitware.com> References: <20170515183329.GA19790@megas.kitware.com> Message-ID: Ben, Also, the second approach with github pages is available via git: https://github.com/lorensen/VTKExamples On Mon, May 15, 2017 at 2:33 PM, Ben Boeckel wrote: > On Mon, May 15, 2017 at 18:09:28 +0000, Andras Lasso wrote: >> Versioning may be a one of the most difficult problem to solve. We use >> MediaWiki to maintain Slicer documentation and we've found that >> maintaining up-to-date documentation for multiple versions is >> unsustainable (you have to create a large number of wiki pages for >> each software version), creates confusion (as Google keeps directing >> users to pages belonging to random software versions), and limits >> access (you cannot distribute documentation as a package that can be >> used offline). Hosting documentation on a github or other >> documentation-oriented service (such as readthedocs) does not have >> these issues. > > Note that Gitlab's wiki is available via git: > > https://gitlab.kitware.com/lorensen/VTKExamples.wiki.git > > --Ben -- Unpaid intern in BillsBasement at noware dot com From marcus.hanwell at kitware.com Mon May 15 20:09:06 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 15 May 2017 20:09:06 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc Message-ID: Hi, I have been looking into this in the context of Tomviz, which uses Python 3, but was able to reproduce this in a vanilla VTK build tree. If you use Python 3 everything installs fine, but if you turn on Module_SixPython then I get the following install error: -- Installing: /usr/local/vtk/lib/cmake/vtk-7.1/Modules/SixPython.cmake -- Installing: /usr/local/vtk/lib/python3.5/site-packages/six.py CMake Error at ThirdParty/SixPython/cmake_install.cmake:40 (file): file INSTALL cannot find "/home/marcus/build/vtk/Wrapping/Python/six.pyc". Call Stack (most recent call first): cmake_install.cmake:104 (include) A quick grep turned up nothing obvious, but it would seem that other Python modules are correctly finding the pyc files in the __pycache__ directories, but not so with six. Any pointers on where this logic might be, and why it might be breaking down for this very simple module. Thanks, Marcus From marcus.hanwell at kitware.com Mon May 15 20:22:34 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 15 May 2017 20:22:34 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: References: Message-ID: On Mon, May 15, 2017 at 8:09 PM, Marcus D. Hanwell wrote: > I have been looking into this in the context of Tomviz, which uses > Python 3, but was able to reproduce this in a vanilla VTK build tree. > If you use Python 3 everything installs fine, but if you turn on > Module_SixPython then I get the following install error: > > -- Installing: /usr/local/vtk/lib/cmake/vtk-7.1/Modules/SixPython.cmake > -- Installing: /usr/local/vtk/lib/python3.5/site-packages/six.py > CMake Error at ThirdParty/SixPython/cmake_install.cmake:40 (file): > file INSTALL cannot find "/home/marcus/build/vtk/Wrapping/Python/six.pyc". > Call Stack (most recent call first): > cmake_install.cmake:104 (include) > > A quick grep turned up nothing obvious, but it would seem that other > Python modules are correctly finding the pyc files in the __pycache__ > directories, but not so with six. Any pointers on where this logic > might be, and why it might be breaking down for this very simple > module. > Isn't it always the way, but I guess the major issue is that only a few modules use vtk_module_python_package, and that CMake function seems to have no idea about __pycache__ in Python 3, and is only just starting to be used there with AutobahnPython and SixPython. I am guessing when they were added make install wasn't tested with Python 3. Aron, it looks like you added the Autobahn to Python 3, any chance that the install target could be fixed? It seems like the vtk_module_python_package function needs to be extended to deal with __pycache__ when using Python 3 but people more knowledgeable in Python-fu may have other ideas. Thanks, Marcus From c.sell at byterefinery.de Tue May 16 04:57:24 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Tue, 16 May 2017 08:57:24 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> Message-ID: <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> just for the record (nobody care about this subject?): I found that contrary to what I said I had NOT adhered to the principle established with protoype 1 while implementing protoype 2. Rather, I had directly called into the VTK interactor from the QML UI thread. And because the VTK interactors immediately go into rendering, all hell broke loose. After cleaning up example 2 according to the rule laid out earlier ("store event data in RenderDelegate, call update() on the QML item, pass the event to VTK inside RenderDelgate.Render()", all works well. What I would like to do is validate the solution against findings made elsewhere, and then establish the "canonical" way of integrating VTK with QML. As I said, there are some architectural quirks with the solution which I would also like to address. regards, Christian Zitat von c.sell at byterefinery.de: > Hello all, > > I am looking into the possibility of replacing the 3D rendering > engine in my Qt5 / QML based mobile tablet-oriented application with > VTK. What I need is a first class QtQuick integration (not a hack or > workaround) that is 100% stable in every context (not an unusual > requirement, I admit). To my amazement, nothing of that kind seems > to exist (correct me if I'm wrong). > > I went on to investigate what had been done so far and to implement > my first prototypes, using the QQuickFrameBufferObject approach. > From the very start this felt like an uphill battle, because VTK > seems to come from a Windowing background and is quite tightly > integrated with concepts that are not valid in a QML context. > > I'll describe my findings together with the 2 prototypical QML items > I implemented: > > 1st was an adaptation of the DICOM example which now runs as a QML > item. All user interaction is handled by QML and forwarded to VTK > (which is one thing that doesn't come naturally with VTK), and after > some non-elegant tweaking I was able to have the UI move from slice > to slice and re-render upon mouse wheel events as expected. The > problem here was, that QML insists on keeping mouse event handling > and OpenGL rendering on separate threads, with one "rendering > thread" dedicated to OpenGL. However, the pre-existing VTK > Interactors directly call Render() after reconfiguring the UI from > the mouse event data, which is an absolute QML No-Go. I had to > introduce a RenderDelegate that works somewhat like this: > > QML mouse event: > tell RenderDelegate about the event > call update() on the QML item, which triggers rer-endering on > the dedicated thread > on the QML rendering thread: > call Render() on the RenderWindow > inside the RenderDelegate, look at whether a mouse event is > pending, and call the corresponding VTK mouse handler > call the renderer's default Render() function while setting the > delegate's "Used" flag to false > > 2nd was a QML item that displays a model loaded from a 3ds file. My > goal here was to move the model around using mouse drag events. I > took the lessons learned from the first example, threw in a > vtkInteractorStyleTrackballCamera and hoped for the best. First > thing I found was that I needed a specialized > RenderWindowInteractor, which I provided. When I realized that the > most important requirement for that class was to provide access to > timer functionality, I already got wary, as throwing around events > and doing stuff offline while on the QML rendering thread is never a > good idea. My fears came true when I finished wiring everything > together: I was able to move the model using the mouse, but after a > few moments things got whacky with error output written to the > console and finally a segemtation fault from deep inside VTK. > > I still need to investigate the second example, but would like to > synchronize with the community at this point in order to avoid > errors/misconceptions on my side, to seek help if possible and to > offer my contribution to the VTK code base once this becomes > functional. My first impression is that there are some issues that > lie on an architectural level and cannot be (elegantly) dealt with > on the QML side alone. Any comments? > > thanks, > Christian Sell > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers From sankhesh.jhaveri at kitware.com Tue May 16 09:06:38 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Tue, 16 May 2017 13:06:38 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> Message-ID: Hi Christian, Doing all VTK rendering on the QML render thread is the right thing to do. As far as interaction is concerned, make sure that Qt events are queued on the main thread and processed when execution reaches the render thread. I have done some work on VTK and QtQuick integration that I?m planning to add to a VTK remote module. That way, it will be available as part of VTK. Thanks, Sankhesh ? On Tue, May 16, 2017 at 4:57 AM wrote: > just for the record (nobody care about this subject?): > > I found that contrary to what I said I had NOT adhered to the > principle established with protoype 1 while implementing protoype 2. > Rather, I had directly called into the VTK interactor from the QML UI > thread. And because the VTK interactors immediately go into rendering, > all hell broke loose. > > After cleaning up example 2 according to the rule laid out earlier > ("store event data in RenderDelegate, call update() on the QML item, > pass the event to VTK inside RenderDelgate.Render()", all works well. > > What I would like to do is validate the solution against findings made > elsewhere, and then establish the "canonical" way of integrating VTK > with QML. As I said, there are some architectural quirks with the > solution which I would also like to address. > > regards, > Christian > > > Zitat von c.sell at byterefinery.de: > > > Hello all, > > > > I am looking into the possibility of replacing the 3D rendering > > engine in my Qt5 / QML based mobile tablet-oriented application with > > VTK. What I need is a first class QtQuick integration (not a hack or > > workaround) that is 100% stable in every context (not an unusual > > requirement, I admit). To my amazement, nothing of that kind seems > > to exist (correct me if I'm wrong). > > > > I went on to investigate what had been done so far and to implement > > my first prototypes, using the QQuickFrameBufferObject approach. > > From the very start this felt like an uphill battle, because VTK > > seems to come from a Windowing background and is quite tightly > > integrated with concepts that are not valid in a QML context. > > > > I'll describe my findings together with the 2 prototypical QML items > > I implemented: > > > > 1st was an adaptation of the DICOM example which now runs as a QML > > item. All user interaction is handled by QML and forwarded to VTK > > (which is one thing that doesn't come naturally with VTK), and after > > some non-elegant tweaking I was able to have the UI move from slice > > to slice and re-render upon mouse wheel events as expected. The > > problem here was, that QML insists on keeping mouse event handling > > and OpenGL rendering on separate threads, with one "rendering > > thread" dedicated to OpenGL. However, the pre-existing VTK > > Interactors directly call Render() after reconfiguring the UI from > > the mouse event data, which is an absolute QML No-Go. I had to > > introduce a RenderDelegate that works somewhat like this: > > > > QML mouse event: > > tell RenderDelegate about the event > > call update() on the QML item, which triggers rer-endering on > > the dedicated thread > > on the QML rendering thread: > > call Render() on the RenderWindow > > inside the RenderDelegate, look at whether a mouse event is > > pending, and call the corresponding VTK mouse handler > > call the renderer's default Render() function while setting the > > delegate's "Used" flag to false > > > > 2nd was a QML item that displays a model loaded from a 3ds file. My > > goal here was to move the model around using mouse drag events. I > > took the lessons learned from the first example, threw in a > > vtkInteractorStyleTrackballCamera and hoped for the best. First > > thing I found was that I needed a specialized > > RenderWindowInteractor, which I provided. When I realized that the > > most important requirement for that class was to provide access to > > timer functionality, I already got wary, as throwing around events > > and doing stuff offline while on the QML rendering thread is never a > > good idea. My fears came true when I finished wiring everything > > together: I was able to move the model using the mouse, but after a > > few moments things got whacky with error output written to the > > console and finally a segemtation fault from deep inside VTK. > > > > I still need to investigate the second example, but would like to > > synchronize with the community at this point in order to avoid > > errors/misconceptions on my side, to seek help if possible and to > > offer my contribution to the VTK code base once this becomes > > functional. My first impression is that there are some issues that > > lie on an architectural level and cannot be (elegantly) dealt with > > on the QML side alone. Any comments? > > > > thanks, > > Christian Sell > > > > _______________________________________________ > > 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: > > http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpwright at gmail.com Tue May 16 09:45:57 2017 From: gpwright at gmail.com (Geoff Wright) Date: Tue, 16 May 2017 13:45:57 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> Message-ID: Hi guys, I would argue that for qml integration the best approach is for each vtk viewport to render into a texture on a dedicated thread, not the qml rendering thread. Qml then draws the resulting texture which is more in line with the Qt design intention ( see http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ ) I have been using this approach for a couple of years in a high performance real time application. The code is unfortunately proprietary but very happy to explain more about the approach. It would be great to add support for this to VTK. For the interactor part I do what Sankesh said, defer the events and apply them on the render thread of the particular vtk item. Regards, G On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri wrote: > Hi Christian, > > Doing all VTK rendering on the QML render thread is the right thing to do. > As far as interaction is concerned, make sure that Qt events are queued on > the main thread and processed when execution reaches the render thread. > > I have done some work on VTK and QtQuick integration that I?m planning to > add to a VTK remote module. That way, it will be available as part of VTK. > > Thanks, > Sankhesh > ? > > On Tue, May 16, 2017 at 4:57 AM wrote: > >> just for the record (nobody care about this subject?): >> >> I found that contrary to what I said I had NOT adhered to the >> principle established with protoype 1 while implementing protoype 2. >> Rather, I had directly called into the VTK interactor from the QML UI >> thread. And because the VTK interactors immediately go into rendering, >> all hell broke loose. >> >> After cleaning up example 2 according to the rule laid out earlier >> ("store event data in RenderDelegate, call update() on the QML item, >> pass the event to VTK inside RenderDelgate.Render()", all works well. >> >> What I would like to do is validate the solution against findings made >> elsewhere, and then establish the "canonical" way of integrating VTK >> with QML. As I said, there are some architectural quirks with the >> solution which I would also like to address. >> >> regards, >> Christian >> >> >> Zitat von c.sell at byterefinery.de: >> >> > Hello all, >> > >> > I am looking into the possibility of replacing the 3D rendering >> > engine in my Qt5 / QML based mobile tablet-oriented application with >> > VTK. What I need is a first class QtQuick integration (not a hack or >> > workaround) that is 100% stable in every context (not an unusual >> > requirement, I admit). To my amazement, nothing of that kind seems >> > to exist (correct me if I'm wrong). >> > >> > I went on to investigate what had been done so far and to implement >> > my first prototypes, using the QQuickFrameBufferObject approach. >> > From the very start this felt like an uphill battle, because VTK >> > seems to come from a Windowing background and is quite tightly >> > integrated with concepts that are not valid in a QML context. >> > >> > I'll describe my findings together with the 2 prototypical QML items >> > I implemented: >> > >> > 1st was an adaptation of the DICOM example which now runs as a QML >> > item. All user interaction is handled by QML and forwarded to VTK >> > (which is one thing that doesn't come naturally with VTK), and after >> > some non-elegant tweaking I was able to have the UI move from slice >> > to slice and re-render upon mouse wheel events as expected. The >> > problem here was, that QML insists on keeping mouse event handling >> > and OpenGL rendering on separate threads, with one "rendering >> > thread" dedicated to OpenGL. However, the pre-existing VTK >> > Interactors directly call Render() after reconfiguring the UI from >> > the mouse event data, which is an absolute QML No-Go. I had to >> > introduce a RenderDelegate that works somewhat like this: >> > >> > QML mouse event: >> > tell RenderDelegate about the event >> > call update() on the QML item, which triggers rer-endering on >> > the dedicated thread >> > on the QML rendering thread: >> > call Render() on the RenderWindow >> > inside the RenderDelegate, look at whether a mouse event is >> > pending, and call the corresponding VTK mouse handler >> > call the renderer's default Render() function while setting the >> > delegate's "Used" flag to false >> > >> > 2nd was a QML item that displays a model loaded from a 3ds file. My >> > goal here was to move the model around using mouse drag events. I >> > took the lessons learned from the first example, threw in a >> > vtkInteractorStyleTrackballCamera and hoped for the best. First >> > thing I found was that I needed a specialized >> > RenderWindowInteractor, which I provided. When I realized that the >> > most important requirement for that class was to provide access to >> > timer functionality, I already got wary, as throwing around events >> > and doing stuff offline while on the QML rendering thread is never a >> > good idea. My fears came true when I finished wiring everything >> > together: I was able to move the model using the mouse, but after a >> > few moments things got whacky with error output written to the >> > console and finally a segemtation fault from deep inside VTK. >> > >> > I still need to investigate the second example, but would like to >> > synchronize with the community at this point in order to avoid >> > errors/misconceptions on my side, to seek help if possible and to >> > offer my contribution to the VTK code base once this becomes >> > functional. My first impression is that there are some issues that >> > lie on an architectural level and cannot be (elegantly) dealt with >> > on the QML side alone. Any comments? >> > >> > thanks, >> > Christian Sell >> > >> > _______________________________________________ >> > 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: >> > http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- > Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > | (518) 881-4417 > ? > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.sell at byterefinery.de Tue May 16 09:46:30 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Tue, 16 May 2017 13:46:30 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> Message-ID: <20170516134630.Horde.1RZ4gjcPF-AW75GPmFyHjW7@webmail.byterefinery.de> Hello Jankesh, good to hear there's someone out there. Would you care to elaborate a little more what you mean by "Qt events are queued on the main thread"? Moreover, what exact work are you doing and when will that be available for public review? As I said, the only working approach I found for applying UI events was to set a RenderDelegate. However, RenderDelegate is quite clumsy to use (at least in my context), and there are some aspects that make me feel uncomfortable architecture-wise. I would appreciate if you could comment on this and/or provide the "correct" solution for handling events on the QML render thread. thanks, Christian Zitat von Sankhesh Jhaveri : > Hi Christian, > > Doing all VTK rendering on the QML render thread is the right thing to do. > As far as interaction is concerned, make sure that Qt events are queued on > the main thread and processed when execution reaches the render thread. > > I have done some work on VTK and QtQuick integration that I?m planning to > add to a VTK remote module. That way, it will be available as part of VTK. > > Thanks, > Sankhesh > ? > > On Tue, May 16, 2017 at 4:57 AM wrote: > >> just for the record (nobody care about this subject?): >> >> I found that contrary to what I said I had NOT adhered to the >> principle established with protoype 1 while implementing protoype 2. >> Rather, I had directly called into the VTK interactor from the QML UI >> thread. And because the VTK interactors immediately go into rendering, >> all hell broke loose. >> >> After cleaning up example 2 according to the rule laid out earlier >> ("store event data in RenderDelegate, call update() on the QML item, >> pass the event to VTK inside RenderDelgate.Render()", all works well. >> >> What I would like to do is validate the solution against findings made >> elsewhere, and then establish the "canonical" way of integrating VTK >> with QML. As I said, there are some architectural quirks with the >> solution which I would also like to address. >> >> regards, >> Christian >> >> >> Zitat von c.sell at byterefinery.de: >> >> > Hello all, >> > >> > I am looking into the possibility of replacing the 3D rendering >> > engine in my Qt5 / QML based mobile tablet-oriented application with >> > VTK. What I need is a first class QtQuick integration (not a hack or >> > workaround) that is 100% stable in every context (not an unusual >> > requirement, I admit). To my amazement, nothing of that kind seems >> > to exist (correct me if I'm wrong). >> > >> > I went on to investigate what had been done so far and to implement >> > my first prototypes, using the QQuickFrameBufferObject approach. >> > From the very start this felt like an uphill battle, because VTK >> > seems to come from a Windowing background and is quite tightly >> > integrated with concepts that are not valid in a QML context. >> > >> > I'll describe my findings together with the 2 prototypical QML items >> > I implemented: >> > >> > 1st was an adaptation of the DICOM example which now runs as a QML >> > item. All user interaction is handled by QML and forwarded to VTK >> > (which is one thing that doesn't come naturally with VTK), and after >> > some non-elegant tweaking I was able to have the UI move from slice >> > to slice and re-render upon mouse wheel events as expected. The >> > problem here was, that QML insists on keeping mouse event handling >> > and OpenGL rendering on separate threads, with one "rendering >> > thread" dedicated to OpenGL. However, the pre-existing VTK >> > Interactors directly call Render() after reconfiguring the UI from >> > the mouse event data, which is an absolute QML No-Go. I had to >> > introduce a RenderDelegate that works somewhat like this: >> > >> > QML mouse event: >> > tell RenderDelegate about the event >> > call update() on the QML item, which triggers rer-endering on >> > the dedicated thread >> > on the QML rendering thread: >> > call Render() on the RenderWindow >> > inside the RenderDelegate, look at whether a mouse event is >> > pending, and call the corresponding VTK mouse handler >> > call the renderer's default Render() function while setting the >> > delegate's "Used" flag to false >> > >> > 2nd was a QML item that displays a model loaded from a 3ds file. My >> > goal here was to move the model around using mouse drag events. I >> > took the lessons learned from the first example, threw in a >> > vtkInteractorStyleTrackballCamera and hoped for the best. First >> > thing I found was that I needed a specialized >> > RenderWindowInteractor, which I provided. When I realized that the >> > most important requirement for that class was to provide access to >> > timer functionality, I already got wary, as throwing around events >> > and doing stuff offline while on the QML rendering thread is never a >> > good idea. My fears came true when I finished wiring everything >> > together: I was able to move the model using the mouse, but after a >> > few moments things got whacky with error output written to the >> > console and finally a segemtation fault from deep inside VTK. >> > >> > I still need to investigate the second example, but would like to >> > synchronize with the community at this point in order to avoid >> > errors/misconceptions on my side, to seek help if possible and to >> > offer my contribution to the VTK code base once this becomes >> > functional. My first impression is that there are some issues that >> > lie on an architectural level and cannot be (elegantly) dealt with >> > on the QML side alone. Any comments? >> > >> > thanks, >> > Christian Sell >> > >> > _______________________________________________ >> > 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: >> > http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- > Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > | (518) 881-4417 > ? From c.sell at byterefinery.de Tue May 16 10:13:59 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Tue, 16 May 2017 14:13:59 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> Message-ID: <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> Hi Geoff, as I understand it, the blog post you linked to doesn't mention multiple threads beyond the QML UI thread and the scenegraph render thread. So far, I am using that approach with QQuickFrameBufferObject as starting point and vtkExternalOpenGLRenderWindow for the VTK side, which causes VTK to use QML's OpenGL context and thus render into the FBO maintained by QQuickFrameBufferObject. That seems to work flawlessly, as long as ALL rendering is kept on the scenegraph thread, which is not always obvious to do at first, because VTK's API's don't separate between reading event values and rendering them (e.g., SetSlice(2) will internally set the current slice and then do a Render()). But why maintain more threads? Anyway, please go ahead and explain your approach as detailed as possible, I am all ears. regards, Chris Zitat von Geoff Wright : > Hi guys, > > I would argue that for qml integration the best approach is for each vtk > viewport to render into a texture on a dedicated thread, not the qml > rendering thread. Qml then draws the resulting texture which is more in > line with the Qt design intention ( see > http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ > ) > > I have been using this approach for a couple of years in a high performance > real time application. The code is unfortunately proprietary but very > happy to explain more about the approach. It would be great to add support > for this to VTK. > > For the interactor part I do what Sankesh said, defer the events and apply > them on the render thread of the particular vtk item. > > Regards, > > G > > > > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri > wrote: > >> Hi Christian, >> >> Doing all VTK rendering on the QML render thread is the right thing to do. >> As far as interaction is concerned, make sure that Qt events are queued on >> the main thread and processed when execution reaches the render thread. >> >> I have done some work on VTK and QtQuick integration that I?m planning to >> add to a VTK remote module. That way, it will be available as part of VTK. >> >> Thanks, >> Sankhesh >> ? >> >> On Tue, May 16, 2017 at 4:57 AM wrote: >> >>> just for the record (nobody care about this subject?): >>> >>> I found that contrary to what I said I had NOT adhered to the >>> principle established with protoype 1 while implementing protoype 2. >>> Rather, I had directly called into the VTK interactor from the QML UI >>> thread. And because the VTK interactors immediately go into rendering, >>> all hell broke loose. >>> >>> After cleaning up example 2 according to the rule laid out earlier >>> ("store event data in RenderDelegate, call update() on the QML item, >>> pass the event to VTK inside RenderDelgate.Render()", all works well. >>> >>> What I would like to do is validate the solution against findings made >>> elsewhere, and then establish the "canonical" way of integrating VTK >>> with QML. As I said, there are some architectural quirks with the >>> solution which I would also like to address. >>> >>> regards, >>> Christian >>> >>> >>> Zitat von c.sell at byterefinery.de: >>> >>> > Hello all, >>> > >>> > I am looking into the possibility of replacing the 3D rendering >>> > engine in my Qt5 / QML based mobile tablet-oriented application with >>> > VTK. What I need is a first class QtQuick integration (not a hack or >>> > workaround) that is 100% stable in every context (not an unusual >>> > requirement, I admit). To my amazement, nothing of that kind seems >>> > to exist (correct me if I'm wrong). >>> > >>> > I went on to investigate what had been done so far and to implement >>> > my first prototypes, using the QQuickFrameBufferObject approach. >>> > From the very start this felt like an uphill battle, because VTK >>> > seems to come from a Windowing background and is quite tightly >>> > integrated with concepts that are not valid in a QML context. >>> > >>> > I'll describe my findings together with the 2 prototypical QML items >>> > I implemented: >>> > >>> > 1st was an adaptation of the DICOM example which now runs as a QML >>> > item. All user interaction is handled by QML and forwarded to VTK >>> > (which is one thing that doesn't come naturally with VTK), and after >>> > some non-elegant tweaking I was able to have the UI move from slice >>> > to slice and re-render upon mouse wheel events as expected. The >>> > problem here was, that QML insists on keeping mouse event handling >>> > and OpenGL rendering on separate threads, with one "rendering >>> > thread" dedicated to OpenGL. However, the pre-existing VTK >>> > Interactors directly call Render() after reconfiguring the UI from >>> > the mouse event data, which is an absolute QML No-Go. I had to >>> > introduce a RenderDelegate that works somewhat like this: >>> > >>> > QML mouse event: >>> > tell RenderDelegate about the event >>> > call update() on the QML item, which triggers rer-endering on >>> > the dedicated thread >>> > on the QML rendering thread: >>> > call Render() on the RenderWindow >>> > inside the RenderDelegate, look at whether a mouse event is >>> > pending, and call the corresponding VTK mouse handler >>> > call the renderer's default Render() function while setting the >>> > delegate's "Used" flag to false >>> > >>> > 2nd was a QML item that displays a model loaded from a 3ds file. My >>> > goal here was to move the model around using mouse drag events. I >>> > took the lessons learned from the first example, threw in a >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First >>> > thing I found was that I needed a specialized >>> > RenderWindowInteractor, which I provided. When I realized that the >>> > most important requirement for that class was to provide access to >>> > timer functionality, I already got wary, as throwing around events >>> > and doing stuff offline while on the QML rendering thread is never a >>> > good idea. My fears came true when I finished wiring everything >>> > together: I was able to move the model using the mouse, but after a >>> > few moments things got whacky with error output written to the >>> > console and finally a segemtation fault from deep inside VTK. >>> > >>> > I still need to investigate the second example, but would like to >>> > synchronize with the community at this point in order to avoid >>> > errors/misconceptions on my side, to seek help if possible and to >>> > offer my contribution to the VTK code base once this becomes >>> > functional. My first impression is that there are some issues that >>> > lie on an architectural level and cannot be (elegantly) dealt with >>> > on the QML side alone. Any comments? >>> > >>> > thanks, >>> > Christian Sell >>> > >>> > _______________________________________________ >>> > 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: >>> > http://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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> -- >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >> | (518) 881-4417 >> ? >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> From rcourant at gmail.com Tue May 16 10:44:36 2017 From: rcourant at gmail.com (Carlos Lopez) Date: Tue, 16 May 2017 10:44:36 -0400 Subject: [vtk-developers] Volume visualization with OpenVR In-Reply-To: References: Message-ID: Hi Aashish, vtk is 7.1.1 with SHA: b86da7eef93f75c4a7f524b3644523ae6b651bc4 the exact dataset I'm using is custom, but the issue might be the same with any volumetric imagedata. best, carlos On Mon, May 15, 2017 at 2:48 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Thanks for the images Carlos. Could you please send us the exact > SHA/Version of VTK and also if you can point to the dataset (I know where > it is but just in case). > > We have fixed a related view-clipping issue and since then we have not > find any issues. It is possible that 1) There is a bug 2) This is related > to perception since one eye is inside and the other is outside. > > - Aashish > > On Mon, May 15, 2017 at 12:52 PM Carlos Lopez wrote: > >> Hi Aashish, >> >> Here are the screenshots. >> >> In external.png, notice how the arm is being rendered differently for >> this particular angle; in the HMD I get the sense there is a sharp edge >> along the arm. >> >> When the camera is close enough, the mode of projection changes, and it >> looks like internal.png; here I do not see any edges and the 3D effect >> feels better to me. >> >> In the transition, for very specific points of view, I get the >> in-between.png picture. >> >> I think the code is working as it should, but maybe a quick solution >> would be to convince vtk that the data bounds are much larger that what >> they really are so that it always renders as internal. Is there a way to do >> this? >> >> thanks, >> carlos >> >> >> >> On Mon, May 15, 2017 at 12:18 PM, Aashish Chaudhary >> aashish.chaudhary at kitware.com> wrote: >> >>> Hi Carlos, >>> >>> Can you send a picture of the effect you are mentioning? We have a demo >>> that uses VR in OpenVR but we didn't notice the artifact that you have >>> mentioned but we also have not spent as much time as you did. >>> >>> - Aashish >>> >>> On Mon, May 15, 2017 at 11:42 AM Carlos Lopez >>> wrote: >>> >>>> Hello, >>>> >>>> I'm visualizing a dataset from the visible human project using openVR >>>> and I notice that when the camera is outside of the bounds of the dataset, >>>> the data renders in a way that the bounding box is noticeable; because of >>>> the stereo projection, It is possible to see that the volumetric data is >>>> projected onto the faces of the bounding box (this is not visible in 2D, >>>> either from a monitor or if I close one eye in the HMD). >>>> >>>> If the camera is inside the bounding box, then the data renders in a >>>> way that this effect is no longer visible, the projection plane parallel to >>>> the current view removes the small discontinuity and the 3D perspective is >>>> restored. >>>> >>>> Is it possible to configure the volume rendering so that it always >>>> behaves as if the camera is inside the dataset? >>>> >>>> thanks, >>>> carlos >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Tue May 16 10:52:59 2017 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 16 May 2017 14:52:59 +0000 Subject: [vtk-developers] Volume visualization with OpenVR In-Reply-To: References: Message-ID: Thank you so much! We are looking into it as we have few ideas and will post an update soon. - Aashish On Tue, May 16, 2017 at 10:44 AM Carlos Lopez wrote: > Hi Aashish, > > vtk is 7.1.1 with SHA: > b86da7eef93f75c4a7f524b3644523ae6b651bc4 > > the exact dataset I'm using is custom, but the issue might be the same > with any volumetric imagedata. > > best, > carlos > > > > On Mon, May 15, 2017 at 2:48 PM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> Thanks for the images Carlos. Could you please send us the exact >> SHA/Version of VTK and also if you can point to the dataset (I know where >> it is but just in case). >> >> We have fixed a related view-clipping issue and since then we have not >> find any issues. It is possible that 1) There is a bug 2) This is related >> to perception since one eye is inside and the other is outside. >> >> - Aashish >> >> On Mon, May 15, 2017 at 12:52 PM Carlos Lopez wrote: >> > Hi Aashish, >>> >>> Here are the screenshots. >>> >>> In external.png, notice how the arm is being rendered differently for >>> this particular angle; in the HMD I get the sense there is a sharp edge >>> along the arm. >>> >>> When the camera is close enough, the mode of projection changes, and it >>> looks like internal.png; here I do not see any edges and the 3D effect >>> feels better to me. >>> >>> In the transition, for very specific points of view, I get the >>> in-between.png picture. >>> >>> I think the code is working as it should, but maybe a quick solution >>> would be to convince vtk that the data bounds are much larger that what >>> they really are so that it always renders as internal. Is there a way to do >>> this? >>> >>> thanks, >>> carlos >>> >>> >>> >>> On Mon, May 15, 2017 at 12:18 PM, Aashish Chaudhary >>> aashish.chaudhary at kitware.com> wrote: >>> >> Hi Carlos, >>>> >>>> Can you send a picture of the effect you are mentioning? We have a demo >>>> that uses VR in OpenVR but we didn't notice the artifact that you have >>>> mentioned but we also have not spent as much time as you did. >>>> >>>> - Aashish >>>> >>>> On Mon, May 15, 2017 at 11:42 AM Carlos Lopez >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I'm visualizing a dataset from the visible human project using openVR >>>>> and I notice that when the camera is outside of the bounds of the dataset, >>>>> the data renders in a way that the bounding box is noticeable; because of >>>>> the stereo projection, It is possible to see that the volumetric data is >>>>> projected onto the faces of the bounding box (this is not visible in 2D, >>>>> either from a monitor or if I close one eye in the HMD). >>>>> >>>>> If the camera is inside the bounding box, then the data renders in a >>>>> way that this effect is no longer visible, the projection plane parallel to >>>>> the current view removes the small discontinuity and the 3D perspective is >>>>> restored. >>>>> >>>>> Is it possible to configure the volume rendering so that it always >>>>> behaves as if the camera is inside the dataset? >>>>> >>>>> thanks, >>>>> carlos >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron.helser at kitware.com Tue May 16 11:11:50 2017 From: aron.helser at kitware.com (Aron Helser) Date: Tue, 16 May 2017 11:11:50 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: References: Message-ID: On Mon, May 15, 2017 at 8:22 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Mon, May 15, 2017 at 8:09 PM, Marcus D. Hanwell > wrote: > > I have been looking into this in the context of Tomviz, which uses > > Python 3, but was able to reproduce this in a vanilla VTK build tree. > > If you use Python 3 everything installs fine, but if you turn on > > Module_SixPython then I get the following install error: > > > > -- Installing: /usr/local/vtk/lib/cmake/vtk-7.1/Modules/SixPython.cmake > > -- Installing: /usr/local/vtk/lib/python3.5/site-packages/six.py > > CMake Error at ThirdParty/SixPython/cmake_install.cmake:40 (file): > > file INSTALL cannot find "/home/marcus/build/vtk/ > Wrapping/Python/six.pyc". > > Call Stack (most recent call first): > > cmake_install.cmake:104 (include) > > > > A quick grep turned up nothing obvious, but it would seem that other > > Python modules are correctly finding the pyc files in the __pycache__ > > directories, but not so with six. Any pointers on where this logic > > might be, and why it might be breaking down for this very simple > > module. > > > Isn't it always the way, but I guess the major issue is that only a > few modules use vtk_module_python_package, and that CMake function > seems to have no idea about __pycache__ in Python 3, and is only just > starting to be used there with AutobahnPython and SixPython. I am > guessing when they were added make install wasn't tested with Python > 3. > > Aron, it looks like you added the Autobahn to Python 3, any chance > that the install target could be fixed? It seems like the > vtk_module_python_package function needs to be extended to deal with > __pycache__ when using Python 3 but people more knowledgeable in > Python-fu may have other ideas. > Yes, I updated Autobahn to use the third-party update mechanism, and used the cmake files that already existed. I never tested the 'make install' functionality with Python 3. I would expect the ParaView superbuild to do that, but I don't really know. I've not touched the vtk cmake infrastructure yet - I'll go ask for help. I don't see '__pycache__' handled anywhere in vtk/paraview .cmake files.... > Thanks, > > Marcus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpwright at gmail.com Tue May 16 11:13:00 2017 From: gpwright at gmail.com (Geoff Wright) Date: Tue, 16 May 2017 15:13:00 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> Message-ID: Hi Chris, Sorry for the confusion, yes I am doing what you describe. The difference may be that perhaps your app has only one viewport. In my case there are a number of different viewports (aka vtkRenderWindow) each has its own qml item and is each rendering on it's own thread. Plus the qml composition thread which is managed by Qt. I was just making the point that this architecture let's you draw different viewports in parallel provided that each one has its own mappers and actors. G On Tue, May 16, 2017, 4:13 PM wrote: > Hi Geoff, > > as I understand it, the blog post you linked to doesn't mention > multiple threads beyond the QML UI thread and the scenegraph render > thread. > > So far, I am using that approach with QQuickFrameBufferObject as > starting point and vtkExternalOpenGLRenderWindow for the VTK side, > which causes VTK to use QML's OpenGL context and thus render into the > FBO maintained by QQuickFrameBufferObject. That seems to work > flawlessly, as long as ALL rendering is kept on the scenegraph thread, > which is not always obvious to do at first, because VTK's API's don't > separate between reading event values and rendering them (e.g., > SetSlice(2) will internally set the current slice and then do a > Render()). > > But why maintain more threads? > > Anyway, please go ahead and explain your approach as detailed as > possible, I am all ears. > > regards, > Chris > > Zitat von Geoff Wright : > > > Hi guys, > > > > I would argue that for qml integration the best approach is for each vtk > > viewport to render into a texture on a dedicated thread, not the qml > > rendering thread. Qml then draws the resulting texture which is more in > > line with the Qt design intention ( see > > > http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ > > ) > > > > I have been using this approach for a couple of years in a high > performance > > real time application. The code is unfortunately proprietary but very > > happy to explain more about the approach. It would be great to add > support > > for this to VTK. > > > > For the interactor part I do what Sankesh said, defer the events and > apply > > them on the render thread of the particular vtk item. > > > > Regards, > > > > G > > > > > > > > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < > sankhesh.jhaveri at kitware.com> > > wrote: > > > >> Hi Christian, > >> > >> Doing all VTK rendering on the QML render thread is the right thing to > do. > >> As far as interaction is concerned, make sure that Qt events are queued > on > >> the main thread and processed when execution reaches the render thread. > >> > >> I have done some work on VTK and QtQuick integration that I?m planning > to > >> add to a VTK remote module. That way, it will be available as part of > VTK. > >> > >> Thanks, > >> Sankhesh > >> ? > >> > >> On Tue, May 16, 2017 at 4:57 AM wrote: > >> > >>> just for the record (nobody care about this subject?): > >>> > >>> I found that contrary to what I said I had NOT adhered to the > >>> principle established with protoype 1 while implementing protoype 2. > >>> Rather, I had directly called into the VTK interactor from the QML UI > >>> thread. And because the VTK interactors immediately go into rendering, > >>> all hell broke loose. > >>> > >>> After cleaning up example 2 according to the rule laid out earlier > >>> ("store event data in RenderDelegate, call update() on the QML item, > >>> pass the event to VTK inside RenderDelgate.Render()", all works well. > >>> > >>> What I would like to do is validate the solution against findings made > >>> elsewhere, and then establish the "canonical" way of integrating VTK > >>> with QML. As I said, there are some architectural quirks with the > >>> solution which I would also like to address. > >>> > >>> regards, > >>> Christian > >>> > >>> > >>> Zitat von c.sell at byterefinery.de: > >>> > >>> > Hello all, > >>> > > >>> > I am looking into the possibility of replacing the 3D rendering > >>> > engine in my Qt5 / QML based mobile tablet-oriented application with > >>> > VTK. What I need is a first class QtQuick integration (not a hack or > >>> > workaround) that is 100% stable in every context (not an unusual > >>> > requirement, I admit). To my amazement, nothing of that kind seems > >>> > to exist (correct me if I'm wrong). > >>> > > >>> > I went on to investigate what had been done so far and to implement > >>> > my first prototypes, using the QQuickFrameBufferObject approach. > >>> > From the very start this felt like an uphill battle, because VTK > >>> > seems to come from a Windowing background and is quite tightly > >>> > integrated with concepts that are not valid in a QML context. > >>> > > >>> > I'll describe my findings together with the 2 prototypical QML items > >>> > I implemented: > >>> > > >>> > 1st was an adaptation of the DICOM example which now runs as a QML > >>> > item. All user interaction is handled by QML and forwarded to VTK > >>> > (which is one thing that doesn't come naturally with VTK), and after > >>> > some non-elegant tweaking I was able to have the UI move from slice > >>> > to slice and re-render upon mouse wheel events as expected. The > >>> > problem here was, that QML insists on keeping mouse event handling > >>> > and OpenGL rendering on separate threads, with one "rendering > >>> > thread" dedicated to OpenGL. However, the pre-existing VTK > >>> > Interactors directly call Render() after reconfiguring the UI from > >>> > the mouse event data, which is an absolute QML No-Go. I had to > >>> > introduce a RenderDelegate that works somewhat like this: > >>> > > >>> > QML mouse event: > >>> > tell RenderDelegate about the event > >>> > call update() on the QML item, which triggers rer-endering on > >>> > the dedicated thread > >>> > on the QML rendering thread: > >>> > call Render() on the RenderWindow > >>> > inside the RenderDelegate, look at whether a mouse event is > >>> > pending, and call the corresponding VTK mouse handler > >>> > call the renderer's default Render() function while setting the > >>> > delegate's "Used" flag to false > >>> > > >>> > 2nd was a QML item that displays a model loaded from a 3ds file. My > >>> > goal here was to move the model around using mouse drag events. I > >>> > took the lessons learned from the first example, threw in a > >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First > >>> > thing I found was that I needed a specialized > >>> > RenderWindowInteractor, which I provided. When I realized that the > >>> > most important requirement for that class was to provide access to > >>> > timer functionality, I already got wary, as throwing around events > >>> > and doing stuff offline while on the QML rendering thread is never a > >>> > good idea. My fears came true when I finished wiring everything > >>> > together: I was able to move the model using the mouse, but after a > >>> > few moments things got whacky with error output written to the > >>> > console and finally a segemtation fault from deep inside VTK. > >>> > > >>> > I still need to investigate the second example, but would like to > >>> > synchronize with the community at this point in order to avoid > >>> > errors/misconceptions on my side, to seek help if possible and to > >>> > offer my contribution to the VTK code base once this becomes > >>> > functional. My first impression is that there are some issues that > >>> > lie on an architectural level and cannot be (elegantly) dealt with > >>> > on the QML side alone. Any comments? > >>> > > >>> > thanks, > >>> > Christian Sell > >>> > > >>> > _______________________________________________ > >>> > 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: > >>> > http://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: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >>> -- > >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > >> | (518) 881-4417 > >> ? > >> _______________________________________________ > >> 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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue May 16 11:24:18 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 16 May 2017 11:24:18 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: References: Message-ID: <20170516152418.GA11273@megas.kitware.com> On Tue, May 16, 2017 at 11:11:50 -0400, Aron Helser wrote: > Yes, I updated Autobahn to use the third-party update mechanism, and used > the cmake files that already existed. I never tested the 'make install' > functionality > with Python 3. I would expect the ParaView superbuild to do that, but I > don't ParaView does other things for its Python install rules, so I'm not surprised that VTK on its own is a bit different. Maybe ParaView *only* installs the `.py` files and after installation does the `.pyc` generation? > really know. I've not touched the vtk cmake infrastructure yet - I'll go > ask for help. > I don't see '__pycache__' handled anywhere in vtk/paraview .cmake files.... That's the problem ;) . Python3 now stores `.pyc`, `.pyo`, and other files under a `__pycache__` directory rather than right beside the `.py` files they are generated from. --Ben From sankhesh.jhaveri at kitware.com Tue May 16 11:26:35 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Tue, 16 May 2017 15:26:35 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> Message-ID: Hi Geoff, Chris, IMHO, there are two approaches to VTK+QtQuick: - Rendering the VTK scene to a QQuickFrameBufferObject. - Provides better integration with the QML render stack. - Since it is an indirect rendering approach, performance may suffer. - May require specializations for some VTK interactor styles and VTK widget interaction. - Rendering directly to the QML created OpenGL context using beforeRendering() and afterRendering() calls - Better performance as VTK is directly rendering to the FrameBuffer - Interactor styles and widget interaction would work out of the box - Does not fit within the QML stack as the VTK scene would either be an underlay or an overlay Note that in both these approaches, VTK rendering would need to be constrained to the QSGRenderThread and Qt events would have to be queued before being processed on the render thread. Considering that both these approaches have their own merits, demerits and constraints, maybe adding a compile time flag that lets you switch between direct and indirect rendering would help. As such, there is no ?correct? solution. Regarding queueing the events, I?d just sub-class QVTKInteractorAdapter and override ProcessEvent so that the event gets queued. One execution is in the render thread, the queued events should be processed by the interactor. One more thing as Geoff pointed out, since QML creates an OpenGL context, each VTK item in that context would be an independent vtkViewport. Without this, having multiple QML and VTK items in the same window would not be possible. Hope this helps. Sankhesh ? On Tue, May 16, 2017 at 10:14 AM wrote: > Hi Geoff, > > as I understand it, the blog post you linked to doesn't mention > multiple threads beyond the QML UI thread and the scenegraph render > thread. > > So far, I am using that approach with QQuickFrameBufferObject as > starting point and vtkExternalOpenGLRenderWindow for the VTK side, > which causes VTK to use QML's OpenGL context and thus render into the > FBO maintained by QQuickFrameBufferObject. That seems to work > flawlessly, as long as ALL rendering is kept on the scenegraph thread, > which is not always obvious to do at first, because VTK's API's don't > separate between reading event values and rendering them (e.g., > SetSlice(2) will internally set the current slice and then do a > Render()). > > But why maintain more threads? > > Anyway, please go ahead and explain your approach as detailed as > possible, I am all ears. > > regards, > Chris > > Zitat von Geoff Wright : > > > Hi guys, > > > > I would argue that for qml integration the best approach is for each vtk > > viewport to render into a texture on a dedicated thread, not the qml > > rendering thread. Qml then draws the resulting texture which is more in > > line with the Qt design intention ( see > > > http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ > > ) > > > > I have been using this approach for a couple of years in a high > performance > > real time application. The code is unfortunately proprietary but very > > happy to explain more about the approach. It would be great to add > support > > for this to VTK. > > > > For the interactor part I do what Sankesh said, defer the events and > apply > > them on the render thread of the particular vtk item. > > > > Regards, > > > > G > > > > > > > > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < > sankhesh.jhaveri at kitware.com> > > wrote: > > > >> Hi Christian, > >> > >> Doing all VTK rendering on the QML render thread is the right thing to > do. > >> As far as interaction is concerned, make sure that Qt events are queued > on > >> the main thread and processed when execution reaches the render thread. > >> > >> I have done some work on VTK and QtQuick integration that I?m planning > to > >> add to a VTK remote module. That way, it will be available as part of > VTK. > >> > >> Thanks, > >> Sankhesh > >> ? > >> > >> On Tue, May 16, 2017 at 4:57 AM wrote: > >> > >>> just for the record (nobody care about this subject?): > >>> > >>> I found that contrary to what I said I had NOT adhered to the > >>> principle established with protoype 1 while implementing protoype 2. > >>> Rather, I had directly called into the VTK interactor from the QML UI > >>> thread. And because the VTK interactors immediately go into rendering, > >>> all hell broke loose. > >>> > >>> After cleaning up example 2 according to the rule laid out earlier > >>> ("store event data in RenderDelegate, call update() on the QML item, > >>> pass the event to VTK inside RenderDelgate.Render()", all works well. > >>> > >>> What I would like to do is validate the solution against findings made > >>> elsewhere, and then establish the "canonical" way of integrating VTK > >>> with QML. As I said, there are some architectural quirks with the > >>> solution which I would also like to address. > >>> > >>> regards, > >>> Christian > >>> > >>> > >>> Zitat von c.sell at byterefinery.de: > >>> > >>> > Hello all, > >>> > > >>> > I am looking into the possibility of replacing the 3D rendering > >>> > engine in my Qt5 / QML based mobile tablet-oriented application with > >>> > VTK. What I need is a first class QtQuick integration (not a hack or > >>> > workaround) that is 100% stable in every context (not an unusual > >>> > requirement, I admit). To my amazement, nothing of that kind seems > >>> > to exist (correct me if I'm wrong). > >>> > > >>> > I went on to investigate what had been done so far and to implement > >>> > my first prototypes, using the QQuickFrameBufferObject approach. > >>> > From the very start this felt like an uphill battle, because VTK > >>> > seems to come from a Windowing background and is quite tightly > >>> > integrated with concepts that are not valid in a QML context. > >>> > > >>> > I'll describe my findings together with the 2 prototypical QML items > >>> > I implemented: > >>> > > >>> > 1st was an adaptation of the DICOM example which now runs as a QML > >>> > item. All user interaction is handled by QML and forwarded to VTK > >>> > (which is one thing that doesn't come naturally with VTK), and after > >>> > some non-elegant tweaking I was able to have the UI move from slice > >>> > to slice and re-render upon mouse wheel events as expected. The > >>> > problem here was, that QML insists on keeping mouse event handling > >>> > and OpenGL rendering on separate threads, with one "rendering > >>> > thread" dedicated to OpenGL. However, the pre-existing VTK > >>> > Interactors directly call Render() after reconfiguring the UI from > >>> > the mouse event data, which is an absolute QML No-Go. I had to > >>> > introduce a RenderDelegate that works somewhat like this: > >>> > > >>> > QML mouse event: > >>> > tell RenderDelegate about the event > >>> > call update() on the QML item, which triggers rer-endering on > >>> > the dedicated thread > >>> > on the QML rendering thread: > >>> > call Render() on the RenderWindow > >>> > inside the RenderDelegate, look at whether a mouse event is > >>> > pending, and call the corresponding VTK mouse handler > >>> > call the renderer's default Render() function while setting the > >>> > delegate's "Used" flag to false > >>> > > >>> > 2nd was a QML item that displays a model loaded from a 3ds file. My > >>> > goal here was to move the model around using mouse drag events. I > >>> > took the lessons learned from the first example, threw in a > >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First > >>> > thing I found was that I needed a specialized > >>> > RenderWindowInteractor, which I provided. When I realized that the > >>> > most important requirement for that class was to provide access to > >>> > timer functionality, I already got wary, as throwing around events > >>> > and doing stuff offline while on the QML rendering thread is never a > >>> > good idea. My fears came true when I finished wiring everything > >>> > together: I was able to move the model using the mouse, but after a > >>> > few moments things got whacky with error output written to the > >>> > console and finally a segemtation fault from deep inside VTK. > >>> > > >>> > I still need to investigate the second example, but would like to > >>> > synchronize with the community at this point in order to avoid > >>> > errors/misconceptions on my side, to seek help if possible and to > >>> > offer my contribution to the VTK code base once this becomes > >>> > functional. My first impression is that there are some issues that > >>> > lie on an architectural level and cannot be (elegantly) dealt with > >>> > on the QML side alone. Any comments? > >>> > > >>> > thanks, > >>> > Christian Sell > >>> > > >>> > _______________________________________________ > >>> > 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: > >>> > http://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: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >>> -- > >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > >> | (518) 881-4417 > >> ? > >> _______________________________________________ > >> 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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue May 16 11:29:22 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 16 May 2017 17:29:22 +0200 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget Message-ID: Today I tried porting our application from QVTKWidget to the new QVTKOpenGLWidget available in VTK master. The application works fine when running with the old QVTKWidget, but after porting to QVTKOpenGLWidget I get lots of: ERROR: In /buildbot/vtk8-builder/build/Rendering/OpenGL2/vtkTextureObject.cxx, line 2153 vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL errors detected 0 : (1282) Invalid operation and all our render windows appear black. I followed the advice in the QVTKOpenGLWidget and use QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); before constructing the QApplication, to set the correct surface format. Does this ring a bell to anyone? This is with: Ubuntu 16.04 Intel HD Graphics 4400 VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 Thanks in advance for any advice. We need to port to QVTKOpenGLWidget as soon as possible, to get proper support on retina screens. Cheers, Elvis From marcus.hanwell at kitware.com Tue May 16 11:43:25 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 16 May 2017 11:43:25 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: <20170516152418.GA11273@megas.kitware.com> References: <20170516152418.GA11273@megas.kitware.com> Message-ID: On Tue, May 16, 2017 at 11:24 AM, Ben Boeckel wrote: > On Tue, May 16, 2017 at 11:11:50 -0400, Aron Helser wrote: >> Yes, I updated Autobahn to use the third-party update mechanism, and used >> the cmake files that already existed. I never tested the 'make install' >> functionality >> with Python 3. I would expect the ParaView superbuild to do that, but I >> don't > > ParaView does other things for its Python install rules, so I'm not > surprised that VTK on its own is a bit different. Maybe ParaView *only* > installs the `.py` files and after installation does the `.pyc` > generation? I originally discovered this issue when doing a make install from ParaView with the web stuff turned on using Python 3. Perhaps this combination is not tested? > >> really know. I've not touched the vtk cmake infrastructure yet - I'll go >> ask for help. >> I don't see '__pycache__' handled anywhere in vtk/paraview .cmake files.... > > That's the problem ;) . Python3 now stores `.pyc`, `.pyo`, and other > files under a `__pycache__` directory rather than right beside the `.py` > files they are generated from. > Yes, and the third party appears to be missing this. I found it in building an updated ParaView dependency for Tomviz where we need ParaView built against Python 3 and using the web flags in order to do the export to a web viewer. If this isn't tested it would be nice to get a test added. I am out on travel right now, but can supply the flags for VTK and/or ParaView. It is a VTK issue that ParaView seems to inherit when turning on these modules recently ported to Python 3 (aside from the make install step). From utkarsh.ayachit at kitware.com Tue May 16 11:48:51 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 16 May 2017 11:48:51 -0400 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: References: Message-ID: Try running the `vtkGUISupportQtCxx-TestQVTKOpenGLWidget` test. Does it pass? If you can share the code how this is setup, we can see if something off. Also, try downloading ParaView 5.3 or later. Does it work on your system? Utkarsh On Tue, May 16, 2017 at 11:29 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > Today I tried porting our application from QVTKWidget to the new > QVTKOpenGLWidget available in VTK master. The application works fine > when running with the old QVTKWidget, but after porting to > QVTKOpenGLWidget I get lots of: > > ERROR: In /buildbot/vtk8-builder/build/Rendering/OpenGL2/ > vtkTextureObject.cxx, > line 2153 > vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL > errors detected > 0 : (1282) Invalid operation > > and all our render windows appear black. > > I followed the advice in the QVTKOpenGLWidget and use > > QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); > > before constructing the QApplication, to set the correct surface format. > > Does this ring a bell to anyone? > > This is with: > > Ubuntu 16.04 > Intel HD Graphics 4400 > VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 > > Thanks in advance for any advice. We need to port to QVTKOpenGLWidget > as soon as possible, to get proper support on retina screens. > > Cheers, > Elvis > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spir.robert at gmail.com Tue May 16 11:50:49 2017 From: spir.robert at gmail.com (=?iso-8859-2?B?UvNiZXJ0IKlwaXI=?=) Date: Tue, 16 May 2017 17:50:49 +0200 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: References: Message-ID: <003c01d2ce5c$30c62210$92526630$@gmail.com> Hi Elvis, I also tried porting from QVTKWidget to QVTKOpenGLWidget and I had to change the surfaceformat part to this: QSurfaceFormat surfaceFormat = QVTKOpenGLWidget::defaultFormat(); surfaceFormat.setSamples(0); QSurfaceFormat::setDefaultFormat(surfaceFormat); Otherwise I had black window. Robert -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Elvis Stansvik Sent: Tuesday, May 16, 2017 5:29 PM To: vtkdev Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget Today I tried porting our application from QVTKWidget to the new QVTKOpenGLWidget available in VTK master. The application works fine when running with the old QVTKWidget, but after porting to QVTKOpenGLWidget I get lots of: ERROR: In /buildbot/vtk8-builder/build/Rendering/OpenGL2/vtkTextureObject.cxx, line 2153 vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL errors detected 0 : (1282) Invalid operation and all our render windows appear black. I followed the advice in the QVTKOpenGLWidget and use QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); before constructing the QApplication, to set the correct surface format. Does this ring a bell to anyone? This is with: Ubuntu 16.04 Intel HD Graphics 4400 VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 Thanks in advance for any advice. We need to port to QVTKOpenGLWidget as soon as possible, to get proper support on retina screens. Cheers, Elvis _______________________________________________ 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: http://public.kitware.com/mailman/listinfo/vtk-developers From utkarsh.ayachit at kitware.com Tue May 16 11:53:55 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 16 May 2017 11:53:55 -0400 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: <003c01d2ce5c$30c62210$92526630$@gmail.com> References: <003c01d2ce5c$30c62210$92526630$@gmail.com> Message-ID: Another way to do the same is this: https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/Testing/Cxx/TestQVTKOpenGLWidget.cxx#L32-33 On Tue, May 16, 2017 at 11:50 AM, R?bert ?pir wrote: > Hi Elvis, > I also tried porting from QVTKWidget to QVTKOpenGLWidget and I had to > change > the surfaceformat part to this: > > QSurfaceFormat surfaceFormat = QVTKOpenGLWidget::defaultFormat(); > surfaceFormat.setSamples(0); > QSurfaceFormat::setDefaultFormat(surfaceFormat); > > Otherwise I had black window. > > Robert > > -----Original Message----- > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of > Elvis Stansvik > Sent: Tuesday, May 16, 2017 5:29 PM > To: vtkdev > Subject: [vtk-developers] glCopyTexImage2D errors + black windows when > porting QVTKWidget -> QVTKOpenGLWidget > > Today I tried porting our application from QVTKWidget to the new > QVTKOpenGLWidget available in VTK master. The application works fine when > running with the old QVTKWidget, but after porting to QVTKOpenGLWidget I > get > lots of: > > ERROR: In > /buildbot/vtk8-builder/build/Rendering/OpenGL2/vtkTextureObject.cxx, > line 2153 > vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL > errors detected > 0 : (1282) Invalid operation > > and all our render windows appear black. > > I followed the advice in the QVTKOpenGLWidget and use > > QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); > > before constructing the QApplication, to set the correct surface format. > > Does this ring a bell to anyone? > > This is with: > > Ubuntu 16.04 > Intel HD Graphics 4400 > VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 > > Thanks in advance for any advice. We need to port to QVTKOpenGLWidget as > soon as possible, to get proper support on retina screens. > > Cheers, > Elvis > _______________________________________________ > 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: > http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.sell at byterefinery.de Tue May 16 12:13:38 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Tue, 16 May 2017 16:13:38 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> Message-ID: <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> Hello all, @Geoff: are you saying that each pair of QML item / vtkRenderWindow has its own render thread? Is that something QML does? My goal is to have QML/VTK items behave as normal QML items, i.e., I could have a dozen items on my screen each rendering something different through VTK without influencing each other (apart from system performance). I expect that the approach I have taken so far will already fulfill this requirement. @Sankesh: I object to the compile time flag. IMO both approaches should be usable at the same time, e.g. by extending different superclasses. As you say, the "underlay or overlay" aspect breaks QML concepts and makes any item built according to this approach an "alien" in the QML crowd that always requires special attention. I'll look into QVTKInteractorAdapter - that sounds like seomething useful. Should have come across it earlier. @both: is there a chance that usable code will come out of this exchange any time soon? I for my part would at least publish my prototypical implementations somewhere (GitHub?), unless they become obsolete by something "official" regards, Chris Zitat von Geoff Wright : > Hi Chris, > > Sorry for the confusion, yes I am doing what you describe. The difference > may be that perhaps your app has only one viewport. In my case there are a > number of different viewports (aka vtkRenderWindow) each has its own qml > item and is each rendering on it's own thread. Plus the qml composition > thread which is managed by Qt. > > I was just making the point that this architecture let's you draw different > viewports in parallel provided that each one has its own mappers and actors. > > G > > > On Tue, May 16, 2017, 4:13 PM wrote: > >> Hi Geoff, >> >> as I understand it, the blog post you linked to doesn't mention >> multiple threads beyond the QML UI thread and the scenegraph render >> thread. >> >> So far, I am using that approach with QQuickFrameBufferObject as >> starting point and vtkExternalOpenGLRenderWindow for the VTK side, >> which causes VTK to use QML's OpenGL context and thus render into the >> FBO maintained by QQuickFrameBufferObject. That seems to work >> flawlessly, as long as ALL rendering is kept on the scenegraph thread, >> which is not always obvious to do at first, because VTK's API's don't >> separate between reading event values and rendering them (e.g., >> SetSlice(2) will internally set the current slice and then do a >> Render()). >> >> But why maintain more threads? >> >> Anyway, please go ahead and explain your approach as detailed as >> possible, I am all ears. >> >> regards, >> Chris >> >> Zitat von Geoff Wright : >> >> > Hi guys, >> > >> > I would argue that for qml integration the best approach is for each vtk >> > viewport to render into a texture on a dedicated thread, not the qml >> > rendering thread. Qml then draws the resulting texture which is more in >> > line with the Qt design intention ( see >> > >> http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ >> > ) >> > >> > I have been using this approach for a couple of years in a high >> performance >> > real time application. The code is unfortunately proprietary but very >> > happy to explain more about the approach. It would be great to add >> support >> > for this to VTK. >> > >> > For the interactor part I do what Sankesh said, defer the events and >> apply >> > them on the render thread of the particular vtk item. >> > >> > Regards, >> > >> > G >> > >> > >> > >> > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < >> sankhesh.jhaveri at kitware.com> >> > wrote: >> > >> >> Hi Christian, >> >> >> >> Doing all VTK rendering on the QML render thread is the right thing to >> do. >> >> As far as interaction is concerned, make sure that Qt events are queued >> on >> >> the main thread and processed when execution reaches the render thread. >> >> >> >> I have done some work on VTK and QtQuick integration that I?m planning >> to >> >> add to a VTK remote module. That way, it will be available as part of >> VTK. >> >> >> >> Thanks, >> >> Sankhesh >> >> ? >> >> >> >> On Tue, May 16, 2017 at 4:57 AM wrote: >> >> >> >>> just for the record (nobody care about this subject?): >> >>> >> >>> I found that contrary to what I said I had NOT adhered to the >> >>> principle established with protoype 1 while implementing protoype 2. >> >>> Rather, I had directly called into the VTK interactor from the QML UI >> >>> thread. And because the VTK interactors immediately go into rendering, >> >>> all hell broke loose. >> >>> >> >>> After cleaning up example 2 according to the rule laid out earlier >> >>> ("store event data in RenderDelegate, call update() on the QML item, >> >>> pass the event to VTK inside RenderDelgate.Render()", all works well. >> >>> >> >>> What I would like to do is validate the solution against findings made >> >>> elsewhere, and then establish the "canonical" way of integrating VTK >> >>> with QML. As I said, there are some architectural quirks with the >> >>> solution which I would also like to address. >> >>> >> >>> regards, >> >>> Christian >> >>> >> >>> >> >>> Zitat von c.sell at byterefinery.de: >> >>> >> >>> > Hello all, >> >>> > >> >>> > I am looking into the possibility of replacing the 3D rendering >> >>> > engine in my Qt5 / QML based mobile tablet-oriented application with >> >>> > VTK. What I need is a first class QtQuick integration (not a hack or >> >>> > workaround) that is 100% stable in every context (not an unusual >> >>> > requirement, I admit). To my amazement, nothing of that kind seems >> >>> > to exist (correct me if I'm wrong). >> >>> > >> >>> > I went on to investigate what had been done so far and to implement >> >>> > my first prototypes, using the QQuickFrameBufferObject approach. >> >>> > From the very start this felt like an uphill battle, because VTK >> >>> > seems to come from a Windowing background and is quite tightly >> >>> > integrated with concepts that are not valid in a QML context. >> >>> > >> >>> > I'll describe my findings together with the 2 prototypical QML items >> >>> > I implemented: >> >>> > >> >>> > 1st was an adaptation of the DICOM example which now runs as a QML >> >>> > item. All user interaction is handled by QML and forwarded to VTK >> >>> > (which is one thing that doesn't come naturally with VTK), and after >> >>> > some non-elegant tweaking I was able to have the UI move from slice >> >>> > to slice and re-render upon mouse wheel events as expected. The >> >>> > problem here was, that QML insists on keeping mouse event handling >> >>> > and OpenGL rendering on separate threads, with one "rendering >> >>> > thread" dedicated to OpenGL. However, the pre-existing VTK >> >>> > Interactors directly call Render() after reconfiguring the UI from >> >>> > the mouse event data, which is an absolute QML No-Go. I had to >> >>> > introduce a RenderDelegate that works somewhat like this: >> >>> > >> >>> > QML mouse event: >> >>> > tell RenderDelegate about the event >> >>> > call update() on the QML item, which triggers rer-endering on >> >>> > the dedicated thread >> >>> > on the QML rendering thread: >> >>> > call Render() on the RenderWindow >> >>> > inside the RenderDelegate, look at whether a mouse event is >> >>> > pending, and call the corresponding VTK mouse handler >> >>> > call the renderer's default Render() function while setting the >> >>> > delegate's "Used" flag to false >> >>> > >> >>> > 2nd was a QML item that displays a model loaded from a 3ds file. My >> >>> > goal here was to move the model around using mouse drag events. I >> >>> > took the lessons learned from the first example, threw in a >> >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First >> >>> > thing I found was that I needed a specialized >> >>> > RenderWindowInteractor, which I provided. When I realized that the >> >>> > most important requirement for that class was to provide access to >> >>> > timer functionality, I already got wary, as throwing around events >> >>> > and doing stuff offline while on the QML rendering thread is never a >> >>> > good idea. My fears came true when I finished wiring everything >> >>> > together: I was able to move the model using the mouse, but after a >> >>> > few moments things got whacky with error output written to the >> >>> > console and finally a segemtation fault from deep inside VTK. >> >>> > >> >>> > I still need to investigate the second example, but would like to >> >>> > synchronize with the community at this point in order to avoid >> >>> > errors/misconceptions on my side, to seek help if possible and to >> >>> > offer my contribution to the VTK code base once this becomes >> >>> > functional. My first impression is that there are some issues that >> >>> > lie on an architectural level and cannot be (elegantly) dealt with >> >>> > on the QML side alone. Any comments? >> >>> > >> >>> > thanks, >> >>> > Christian Sell >> >>> > >> >>> > _______________________________________________ >> >>> > 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: >> >>> > http://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: >> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>> >> >>> -- >> >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >> >> | (518) 881-4417 >> >> ? >> >> _______________________________________________ >> >> 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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> >> >> From elvis.stansvik at orexplore.com Tue May 16 12:28:02 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 16 May 2017 18:28:02 +0200 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: References: <003c01d2ce5c$30c62210$92526630$@gmail.com> Message-ID: Den 16 maj 2017 5:53 em skrev "Utkarsh Ayachit" : > > Another way to do the same is this: > > https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/Testing/Cxx/TestQVTKOpenGLWidget.cxx#L32-33 Thanks to both of you for your quick replies. On my way home now but will try your suggestions asap. If the test passes I'll try to do a minimal testcase with the problem. Regarding setting max samples to 0, does this mean I will no longer be able to use MSAA? I wasn't actually doing that in the old code (setting it to 0), just hadn't ported that part so it was commented when I ported to the new widget. But I was using MSAA at one point and it was working fine (samples set to 8). Will this no longer be possible with the new widget? Elvis > > On Tue, May 16, 2017 at 11:50 AM, R?bert ?pir wrote: >> >> Hi Elvis, >> I also tried porting from QVTKWidget to QVTKOpenGLWidget and I had to change >> the surfaceformat part to this: >> >> QSurfaceFormat surfaceFormat = QVTKOpenGLWidget::defaultFormat(); >> surfaceFormat.setSamples(0); >> QSurfaceFormat::setDefaultFormat(surfaceFormat); >> >> Otherwise I had black window. >> >> Robert >> >> -----Original Message----- >> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of >> Elvis Stansvik >> Sent: Tuesday, May 16, 2017 5:29 PM >> To: vtkdev >> Subject: [vtk-developers] glCopyTexImage2D errors + black windows when >> porting QVTKWidget -> QVTKOpenGLWidget >> >> Today I tried porting our application from QVTKWidget to the new >> QVTKOpenGLWidget available in VTK master. The application works fine when >> running with the old QVTKWidget, but after porting to QVTKOpenGLWidget I get >> lots of: >> >> ERROR: In >> /buildbot/vtk8-builder/build/Rendering/OpenGL2/vtkTextureObject.cxx, >> line 2153 >> vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL >> errors detected >> 0 : (1282) Invalid operation >> >> and all our render windows appear black. >> >> I followed the advice in the QVTKOpenGLWidget and use >> >> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >> >> before constructing the QApplication, to set the correct surface format. >> >> Does this ring a bell to anyone? >> >> This is with: >> >> Ubuntu 16.04 >> Intel HD Graphics 4400 >> VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 >> >> Thanks in advance for any advice. We need to port to QVTKOpenGLWidget as >> soon as possible, to get proper support on retina screens. >> >> Cheers, >> Elvis >> _______________________________________________ >> 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: >> http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue May 16 12:43:24 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 16 May 2017 12:43:24 -0400 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: References: <003c01d2ce5c$30c62210$92526630$@gmail.com> Message-ID: > > Regarding setting max samples to 0, does this mean I will no longer be > able to use MSAA? I wasn't actually doing that in the old code (setting it > to 0), just hadn't ported that part so it was commented when I ported to > the new widget. But I was using MSAA at one point and it was working fine > (samples set to 8). Will this no longer be possible with the new widget? > MSAA works fine with QVTKOpenGLWidget. We use it in ParaView for 2D chart views. It's worth also trying out the `vtkGUISupportQtCxx-TestQVTKOpenGLWidgetWithMSAA` test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spir.robert at gmail.com Tue May 16 13:01:52 2017 From: spir.robert at gmail.com (=?UTF-8?B?UsOzYmVydCDFoHBpcg==?=) Date: Tue, 16 May 2017 19:01:52 +0200 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: References: <003c01d2ce5c$30c62210$92526630$@gmail.com> Message-ID: <000901d2ce66$1dc93f80$595bbe80$@gmail.com> for me, msaa works for polydata but not for volume rendering. Volume rendering does not show with samples>0 I have entire black screen with msaa and FXAA With only FXAA, volume rendering works ok. From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] Sent: Tuesday, May 16, 2017 6:43 PM To: Elvis Stansvik Cc: vtkdev ; RobertS Subject: Re: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget Regarding setting max samples to 0, does this mean I will no longer be able to use MSAA? I wasn't actually doing that in the old code (setting it to 0), just hadn't ported that part so it was commented when I ported to the new widget. But I was using MSAA at one point and it was working fine (samples set to 8). Will this no longer be possible with the new widget? MSAA works fine with QVTKOpenGLWidget. We use it in ParaView for 2D chart views. It's worth also trying out the `vtkGUISupportQtCxx-TestQVTKOpenGLWidgetWithMSAA` test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue May 16 13:09:09 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 16 May 2017 13:09:09 -0400 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: <000901d2ce66$1dc93f80$595bbe80$@gmail.com> References: <003c01d2ce5c$30c62210$92526630$@gmail.com> <000901d2ce66$1dc93f80$595bbe80$@gmail.com> Message-ID: > for me, msaa works for polydata but not for volume rendering. Volume > rendering does not show with samples>0 > That points to a inability of the volume mapper to work with a MSAA capable FBO to render into. Please report this as a issue with details on which volume mapper you're using. Should be addressable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue May 16 13:58:09 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 16 May 2017 13:58:09 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: References: <20170516152418.GA11273@megas.kitware.com> Message-ID: <20170516175809.GB32636@rotor> On Tue, May 16, 2017 at 11:43:25 -0400, Marcus D. Hanwell wrote: > I originally discovered this issue when doing a make install from > ParaView with the web stuff turned on using Python 3. Perhaps this > combination is not tested? Ah, that is true. The superbuild is Python2-only right now. > Yes, and the third party appears to be missing this. I found it in > building an updated ParaView dependency for Tomviz where we need > ParaView built against Python 3 and using the web flags in order to do > the export to a web viewer. If this isn't tested it would be nice to > get a test added. > > I am out on travel right now, but can supply the flags for VTK and/or > ParaView. It is a VTK issue that ParaView seems to inherit when > turning on these modules recently ported to Python 3 (aside from the > make install step). Aron and I had some off-list messages and have found the culprit (vtk_module_python_module). I believe he is working on a fix. --Ben From aron.helser at kitware.com Tue May 16 22:15:28 2017 From: aron.helser at kitware.com (Aron Helser) Date: Tue, 16 May 2017 22:15:28 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: <20170516175809.GB32636@rotor> References: <20170516152418.GA11273@megas.kitware.com> <20170516175809.GB32636@rotor> Message-ID: I had to add a file glob to get the .pyc files, since they now include the interpreter and python version in the filename. Here's a working fix to vtk/CMake/vtkModuleMacrosPython.cmake. I'll submit a MR tomorrow. # add install rules. if (NOT _no_install AND NOT VTK_INSTALL_NO_RUNTIME) - install(FILES "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name}" - "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name_we}.pyc" - "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name_we}.pyo" - DESTINATION "${VTK_INSTALL_PYTHON_MODULE_DIR}" - COMPONENT "Runtime") + if(VTK_PYTHON_VERSION VERSION_LESS 3) + install(FILES "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name}" + "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name_we}.pyc" + "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name_we}.pyo" + DESTINATION "${VTK_INSTALL_PYTHON_MODULE_DIR}" + COMPONENT "Runtime") + else() + # python 3 uses a different directory for .pyc files, and .pyo files are gone. + install(FILES "${VTK_BUILD_PYTHON_MODULE_DIR}/${_name}" + DESTINATION "${VTK_INSTALL_PYTHON_MODULE_DIR}" + COMPONENT "Runtime") + file(GLOB file_matches "${VTK_BUILD_PYTHON_MODULE_DIR}/__pycache__/${_name_we}.*.pyc") + install(FILES ${file_matches} + DESTINATION "${VTK_INSTALL_PYTHON_MODULE_DIR}/__pycache__" + COMPONENT "Runtime") + endif() endif() Aron On Tue, May 16, 2017 at 1:58 PM, Ben Boeckel wrote: > On Tue, May 16, 2017 at 11:43:25 -0400, Marcus D. Hanwell wrote: > > I originally discovered this issue when doing a make install from > > ParaView with the web stuff turned on using Python 3. Perhaps this > > combination is not tested? > > Ah, that is true. The superbuild is Python2-only right now. > > > Yes, and the third party appears to be missing this. I found it in > > building an updated ParaView dependency for Tomviz where we need > > ParaView built against Python 3 and using the web flags in order to do > > the export to a web viewer. If this isn't tested it would be nice to > > get a test added. > > > > I am out on travel right now, but can supply the flags for VTK and/or > > ParaView. It is a VTK issue that ParaView seems to inherit when > > turning on these modules recently ported to Python 3 (aside from the > > make install step). > > Aron and I had some off-list messages and have found the culprit > (vtk_module_python_module). I believe he is working on a fix. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpwright at gmail.com Wed May 17 01:38:56 2017 From: gpwright at gmail.com (Geoff Wright) Date: Wed, 17 May 2017 05:38:56 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> Message-ID: Yes each vtk item has its own render thread that is why I would argue this approach is superior to the others since it scales with the number of cores. I followed the approach described here: http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html So basically inside each vtk qml item there is a thread drawing a vtk viewport into a texture, then the QSGRenderThread comes along and just does a single texture blit for each item (very cheap). The Qt main thread takes care of other event processing, models etc. This is sufficient if each item contains an independent scene (vtk pipeline). If you need to share state between two or more viewports then you need to be careful to control the timing of when any data objects may mutate since the vtk api is not inherently threadsafe. Does that make sense? G On Tue, May 16, 2017, 6:13 PM wrote: > Hello all, > > @Geoff: are you saying that each pair of QML item / vtkRenderWindow > has its own render thread? Is that something QML does? > > My goal is to have QML/VTK items behave as normal QML items, i.e., I > could have a dozen items on my screen each rendering something > different through VTK without influencing each other (apart from > system performance). I expect that the approach I have taken so far > will already fulfill this requirement. > > @Sankesh: I object to the compile time flag. IMO both approaches > should be usable at the same time, e.g. by extending different > superclasses. As you say, the "underlay or overlay" aspect breaks QML > concepts and makes any item built according to this approach an > "alien" in the QML crowd that always requires special attention. > > I'll look into QVTKInteractorAdapter - that sounds like seomething > useful. Should have come across it earlier. > > @both: is there a chance that usable code will come out of this > exchange any time soon? I for my part would at least publish my > prototypical implementations somewhere (GitHub?), unless they become > obsolete by something "official" > > regards, > Chris > > Zitat von Geoff Wright : > > > Hi Chris, > > > > Sorry for the confusion, yes I am doing what you describe. The > difference > > may be that perhaps your app has only one viewport. In my case there > are a > > number of different viewports (aka vtkRenderWindow) each has its own qml > > item and is each rendering on it's own thread. Plus the qml composition > > thread which is managed by Qt. > > > > I was just making the point that this architecture let's you draw > different > > viewports in parallel provided that each one has its own mappers and > actors. > > > > G > > > > > > On Tue, May 16, 2017, 4:13 PM wrote: > > > >> Hi Geoff, > >> > >> as I understand it, the blog post you linked to doesn't mention > >> multiple threads beyond the QML UI thread and the scenegraph render > >> thread. > >> > >> So far, I am using that approach with QQuickFrameBufferObject as > >> starting point and vtkExternalOpenGLRenderWindow for the VTK side, > >> which causes VTK to use QML's OpenGL context and thus render into the > >> FBO maintained by QQuickFrameBufferObject. That seems to work > >> flawlessly, as long as ALL rendering is kept on the scenegraph thread, > >> which is not always obvious to do at first, because VTK's API's don't > >> separate between reading event values and rendering them (e.g., > >> SetSlice(2) will internally set the current slice and then do a > >> Render()). > >> > >> But why maintain more threads? > >> > >> Anyway, please go ahead and explain your approach as detailed as > >> possible, I am all ears. > >> > >> regards, > >> Chris > >> > >> Zitat von Geoff Wright : > >> > >> > Hi guys, > >> > > >> > I would argue that for qml integration the best approach is for each > vtk > >> > viewport to render into a texture on a dedicated thread, not the qml > >> > rendering thread. Qml then draws the resulting texture which is more > in > >> > line with the Qt design intention ( see > >> > > >> > http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ > >> > ) > >> > > >> > I have been using this approach for a couple of years in a high > >> performance > >> > real time application. The code is unfortunately proprietary but very > >> > happy to explain more about the approach. It would be great to add > >> support > >> > for this to VTK. > >> > > >> > For the interactor part I do what Sankesh said, defer the events and > >> apply > >> > them on the render thread of the particular vtk item. > >> > > >> > Regards, > >> > > >> > G > >> > > >> > > >> > > >> > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < > >> sankhesh.jhaveri at kitware.com> > >> > wrote: > >> > > >> >> Hi Christian, > >> >> > >> >> Doing all VTK rendering on the QML render thread is the right thing > to > >> do. > >> >> As far as interaction is concerned, make sure that Qt events are > queued > >> on > >> >> the main thread and processed when execution reaches the render > thread. > >> >> > >> >> I have done some work on VTK and QtQuick integration that I?m > planning > >> to > >> >> add to a VTK remote module. That way, it will be available as part of > >> VTK. > >> >> > >> >> Thanks, > >> >> Sankhesh > >> >> ? > >> >> > >> >> On Tue, May 16, 2017 at 4:57 AM wrote: > >> >> > >> >>> just for the record (nobody care about this subject?): > >> >>> > >> >>> I found that contrary to what I said I had NOT adhered to the > >> >>> principle established with protoype 1 while implementing protoype 2. > >> >>> Rather, I had directly called into the VTK interactor from the QML > UI > >> >>> thread. And because the VTK interactors immediately go into > rendering, > >> >>> all hell broke loose. > >> >>> > >> >>> After cleaning up example 2 according to the rule laid out earlier > >> >>> ("store event data in RenderDelegate, call update() on the QML item, > >> >>> pass the event to VTK inside RenderDelgate.Render()", all works > well. > >> >>> > >> >>> What I would like to do is validate the solution against findings > made > >> >>> elsewhere, and then establish the "canonical" way of integrating VTK > >> >>> with QML. As I said, there are some architectural quirks with the > >> >>> solution which I would also like to address. > >> >>> > >> >>> regards, > >> >>> Christian > >> >>> > >> >>> > >> >>> Zitat von c.sell at byterefinery.de: > >> >>> > >> >>> > Hello all, > >> >>> > > >> >>> > I am looking into the possibility of replacing the 3D rendering > >> >>> > engine in my Qt5 / QML based mobile tablet-oriented application > with > >> >>> > VTK. What I need is a first class QtQuick integration (not a hack > or > >> >>> > workaround) that is 100% stable in every context (not an unusual > >> >>> > requirement, I admit). To my amazement, nothing of that kind seems > >> >>> > to exist (correct me if I'm wrong). > >> >>> > > >> >>> > I went on to investigate what had been done so far and to > implement > >> >>> > my first prototypes, using the QQuickFrameBufferObject approach. > >> >>> > From the very start this felt like an uphill battle, because VTK > >> >>> > seems to come from a Windowing background and is quite tightly > >> >>> > integrated with concepts that are not valid in a QML context. > >> >>> > > >> >>> > I'll describe my findings together with the 2 prototypical QML > items > >> >>> > I implemented: > >> >>> > > >> >>> > 1st was an adaptation of the DICOM example which now runs as a QML > >> >>> > item. All user interaction is handled by QML and forwarded to VTK > >> >>> > (which is one thing that doesn't come naturally with VTK), and > after > >> >>> > some non-elegant tweaking I was able to have the UI move from > slice > >> >>> > to slice and re-render upon mouse wheel events as expected. The > >> >>> > problem here was, that QML insists on keeping mouse event handling > >> >>> > and OpenGL rendering on separate threads, with one "rendering > >> >>> > thread" dedicated to OpenGL. However, the pre-existing VTK > >> >>> > Interactors directly call Render() after reconfiguring the UI from > >> >>> > the mouse event data, which is an absolute QML No-Go. I had to > >> >>> > introduce a RenderDelegate that works somewhat like this: > >> >>> > > >> >>> > QML mouse event: > >> >>> > tell RenderDelegate about the event > >> >>> > call update() on the QML item, which triggers rer-endering on > >> >>> > the dedicated thread > >> >>> > on the QML rendering thread: > >> >>> > call Render() on the RenderWindow > >> >>> > inside the RenderDelegate, look at whether a mouse event is > >> >>> > pending, and call the corresponding VTK mouse handler > >> >>> > call the renderer's default Render() function while setting > the > >> >>> > delegate's "Used" flag to false > >> >>> > > >> >>> > 2nd was a QML item that displays a model loaded from a 3ds file. > My > >> >>> > goal here was to move the model around using mouse drag events. I > >> >>> > took the lessons learned from the first example, threw in a > >> >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First > >> >>> > thing I found was that I needed a specialized > >> >>> > RenderWindowInteractor, which I provided. When I realized that the > >> >>> > most important requirement for that class was to provide access to > >> >>> > timer functionality, I already got wary, as throwing around events > >> >>> > and doing stuff offline while on the QML rendering thread is > never a > >> >>> > good idea. My fears came true when I finished wiring everything > >> >>> > together: I was able to move the model using the mouse, but after > a > >> >>> > few moments things got whacky with error output written to the > >> >>> > console and finally a segemtation fault from deep inside VTK. > >> >>> > > >> >>> > I still need to investigate the second example, but would like to > >> >>> > synchronize with the community at this point in order to avoid > >> >>> > errors/misconceptions on my side, to seek help if possible and to > >> >>> > offer my contribution to the VTK code base once this becomes > >> >>> > functional. My first impression is that there are some issues that > >> >>> > lie on an architectural level and cannot be (elegantly) dealt with > >> >>> > on the QML side alone. Any comments? > >> >>> > > >> >>> > thanks, > >> >>> > Christian Sell > >> >>> > > >> >>> > _______________________________________________ > >> >>> > 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: > >> >>> > http://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: > >> >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >> >>> > >> >>> -- > >> >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > >> >> | (518) 881-4417 > >> >> ? > >> >> _______________________________________________ > >> >> 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: > >> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> >> > >> >> > >> > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed May 17 03:41:38 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 17 May 2017 09:41:38 +0200 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: <003c01d2ce5c$30c62210$92526630$@gmail.com> References: <003c01d2ce5c$30c62210$92526630$@gmail.com> Message-ID: 2017-05-16 17:50 GMT+02:00 R?bert ?pir : > Hi Elvis, > I also tried porting from QVTKWidget to QVTKOpenGLWidget and I had to change > the surfaceformat part to this: > > QSurfaceFormat surfaceFormat = QVTKOpenGLWidget::defaultFormat(); > surfaceFormat.setSamples(0); > QSurfaceFormat::setDefaultFormat(surfaceFormat); > > Otherwise I had black window. Just a quick update regarding this workaround (I'm currently rebuilding VTK with testing enabled, to run the tests Utkarsh suggested): With the above workaround (setSamples(0)), I instead get "hollow" render windows where I can see through to the windows behind them. When I resize the window, I can sometimes see some hints of my actors in the render windows, but it's all very garbled. When building is finished, I'll get back with my results from running the vtkGUISupportQtCxx-TestQVTKOpenGLWidget test. Elvis > > Robert > > -----Original Message----- > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of > Elvis Stansvik > Sent: Tuesday, May 16, 2017 5:29 PM > To: vtkdev > Subject: [vtk-developers] glCopyTexImage2D errors + black windows when > porting QVTKWidget -> QVTKOpenGLWidget > > Today I tried porting our application from QVTKWidget to the new > QVTKOpenGLWidget available in VTK master. The application works fine when > running with the old QVTKWidget, but after porting to QVTKOpenGLWidget I get > lots of: > > ERROR: In > /buildbot/vtk8-builder/build/Rendering/OpenGL2/vtkTextureObject.cxx, > line 2153 > vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL > errors detected > 0 : (1282) Invalid operation > > and all our render windows appear black. > > I followed the advice in the QVTKOpenGLWidget and use > > QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); > > before constructing the QApplication, to set the correct surface format. > > Does this ring a bell to anyone? > > This is with: > > Ubuntu 16.04 > Intel HD Graphics 4400 > VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 > > Thanks in advance for any advice. We need to port to QVTKOpenGLWidget as > soon as possible, to get proper support on retina screens. > > Cheers, > Elvis > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Wed May 17 04:07:07 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 17 May 2017 10:07:07 +0200 Subject: [vtk-developers] glCopyTexImage2D errors + black windows when porting QVTKWidget -> QVTKOpenGLWidget In-Reply-To: References: <003c01d2ce5c$30c62210$92526630$@gmail.com> Message-ID: 2017-05-17 9:41 GMT+02:00 Elvis Stansvik : > 2017-05-16 17:50 GMT+02:00 R?bert ?pir : >> Hi Elvis, >> I also tried porting from QVTKWidget to QVTKOpenGLWidget and I had to change >> the surfaceformat part to this: >> >> QSurfaceFormat surfaceFormat = QVTKOpenGLWidget::defaultFormat(); >> surfaceFormat.setSamples(0); >> QSurfaceFormat::setDefaultFormat(surfaceFormat); >> >> Otherwise I had black window. > > Just a quick update regarding this workaround (I'm currently > rebuilding VTK with testing enabled, to run the tests Utkarsh > suggested): With the above workaround (setSamples(0)), I instead get > "hollow" render windows where I can see through to the windows behind > them. When I resize the window, I can sometimes see some hints of my > actors in the render windows, but it's all very garbled. > > When building is finished, I'll get back with my results from running > the vtkGUISupportQtCxx-TestQVTKOpenGLWidget test. Sorry all for the noise. During porting, I had left in some wonky workaround for QTBUG-40889 (fixed in Qt 5.6) that we had in place. It was messing with the paintEvent of our QVTKWidget subclass. After removing that workaround, rendering is back to normal and the new widget seems to work fine. Well... almost, because I still have some strange rendering issues compared to the old QVTKWidget, but I'll make separate posts about those once I've had a closer look. The vtkGUISupportQtCxx-TestQVTKOpenGLWidget is passing. Elvis > > Elvis > >> >> Robert >> >> -----Original Message----- >> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of >> Elvis Stansvik >> Sent: Tuesday, May 16, 2017 5:29 PM >> To: vtkdev >> Subject: [vtk-developers] glCopyTexImage2D errors + black windows when >> porting QVTKWidget -> QVTKOpenGLWidget >> >> Today I tried porting our application from QVTKWidget to the new >> QVTKOpenGLWidget available in VTK master. The application works fine when >> running with the old QVTKWidget, but after porting to QVTKOpenGLWidget I get >> lots of: >> >> ERROR: In >> /buildbot/vtk8-builder/build/Rendering/OpenGL2/vtkTextureObject.cxx, >> line 2153 >> vtkTextureObject (0x275acb0): failed at glCopyTexImage2D 6402 1 OpenGL >> errors detected >> 0 : (1282) Invalid operation >> >> and all our render windows appear black. >> >> I followed the advice in the QVTKOpenGLWidget and use >> >> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >> >> before constructing the QApplication, to set the correct surface format. >> >> Does this ring a bell to anyone? >> >> This is with: >> >> Ubuntu 16.04 >> Intel HD Graphics 4400 >> VTK master @ 97e306e4cdaab9b7b0b25d73da61e220391156b4 >> >> Thanks in advance for any advice. We need to port to QVTKOpenGLWidget as >> soon as possible, to get proper support on retina screens. >> >> Cheers, >> Elvis >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> From c.sell at byterefinery.de Wed May 17 04:09:07 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Wed, 17 May 2017 08:09:07 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> Message-ID: <20170517080907.Horde.gMGdDBGskRU8Z_mFOXJOz7t@webmail.byterefinery.de> ok, things are clearing up a little more now. You ARE creating a separate thread for each QML item, which gives us these threads: - QML GUI thread (where the events come from) - QML rendering thread (aka scenegraph rendering thread aka QSGRenderThread), of which theres is only one - a dedicated thread for each item (RenderThread class in the example) the example also uses a QSGSimpleTextureNode subclass that does the blit'ing together. All of that decoupled via QueuedConnections and events signalled here and there. Not an easy beast, that. What remains unclear is how you deal with user input. For example, if the user were to drag something around in the scene (and your app were to support that), where do the MouseMove events go? This is really the main crux in this discussion IMO. To sum up the architectural choices: a) render into FBO a1)- do all rendering on the scenegraph thread (exemplified in http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html) a2) render on a dedicated thread for each item (exemplified in http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html) b) render into the QML context directly (not sure about this. Is there a Qt example demonstrating the practicability?) b?) undetermined The user intaction part is undetermined for me at this point. I am trying to get something going using QVTKInteractorAdapter, but havent had luck so far. In terms of ready usable code that demonstrates QML/VTK integration (including interaction and all) I see nothing yet on the horizon. chris Zitat von Geoff Wright : > Yes each vtk item has its own render thread that is why I would argue this > approach is superior to the others since it scales with the number of cores. > > I followed the approach described here: > > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html > > So basically inside each vtk qml item there is a thread drawing a vtk > viewport into a texture, then the QSGRenderThread comes along and just does > a single texture blit for each item (very cheap). The Qt main thread takes > care of other event processing, models etc. > > This is sufficient if each item contains an independent scene (vtk > pipeline). If you need to share state between two or more viewports then > you need to be careful to control the timing of when any data objects may > mutate since the vtk api is not inherently threadsafe. > > Does that make sense? > > G > > > > On Tue, May 16, 2017, 6:13 PM wrote: > >> Hello all, >> >> @Geoff: are you saying that each pair of QML item / vtkRenderWindow >> has its own render thread? Is that something QML does? >> >> My goal is to have QML/VTK items behave as normal QML items, i.e., I >> could have a dozen items on my screen each rendering something >> different through VTK without influencing each other (apart from >> system performance). I expect that the approach I have taken so far >> will already fulfill this requirement. >> >> @Sankesh: I object to the compile time flag. IMO both approaches >> should be usable at the same time, e.g. by extending different >> superclasses. As you say, the "underlay or overlay" aspect breaks QML >> concepts and makes any item built according to this approach an >> "alien" in the QML crowd that always requires special attention. >> >> I'll look into QVTKInteractorAdapter - that sounds like seomething >> useful. Should have come across it earlier. >> >> @both: is there a chance that usable code will come out of this >> exchange any time soon? I for my part would at least publish my >> prototypical implementations somewhere (GitHub?), unless they become >> obsolete by something "official" >> >> regards, >> Chris >> >> Zitat von Geoff Wright : >> >> > Hi Chris, >> > >> > Sorry for the confusion, yes I am doing what you describe. The >> difference >> > may be that perhaps your app has only one viewport. In my case there >> are a >> > number of different viewports (aka vtkRenderWindow) each has its own qml >> > item and is each rendering on it's own thread. Plus the qml composition >> > thread which is managed by Qt. >> > >> > I was just making the point that this architecture let's you draw >> different >> > viewports in parallel provided that each one has its own mappers and >> actors. >> > >> > G >> > >> > >> > On Tue, May 16, 2017, 4:13 PM wrote: >> > >> >> Hi Geoff, >> >> >> >> as I understand it, the blog post you linked to doesn't mention >> >> multiple threads beyond the QML UI thread and the scenegraph render >> >> thread. >> >> >> >> So far, I am using that approach with QQuickFrameBufferObject as >> >> starting point and vtkExternalOpenGLRenderWindow for the VTK side, >> >> which causes VTK to use QML's OpenGL context and thus render into the >> >> FBO maintained by QQuickFrameBufferObject. That seems to work >> >> flawlessly, as long as ALL rendering is kept on the scenegraph thread, >> >> which is not always obvious to do at first, because VTK's API's don't >> >> separate between reading event values and rendering them (e.g., >> >> SetSlice(2) will internally set the current slice and then do a >> >> Render()). >> >> >> >> But why maintain more threads? >> >> >> >> Anyway, please go ahead and explain your approach as detailed as >> >> possible, I am all ears. >> >> >> >> regards, >> >> Chris >> >> >> >> Zitat von Geoff Wright : >> >> >> >> > Hi guys, >> >> > >> >> > I would argue that for qml integration the best approach is for each >> vtk >> >> > viewport to render into a texture on a dedicated thread, not the qml >> >> > rendering thread. Qml then draws the resulting texture which is more >> in >> >> > line with the Qt design intention ( see >> >> > >> >> >> http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ >> >> > ) >> >> > >> >> > I have been using this approach for a couple of years in a high >> >> performance >> >> > real time application. The code is unfortunately proprietary but very >> >> > happy to explain more about the approach. It would be great to add >> >> support >> >> > for this to VTK. >> >> > >> >> > For the interactor part I do what Sankesh said, defer the events and >> >> apply >> >> > them on the render thread of the particular vtk item. >> >> > >> >> > Regards, >> >> > >> >> > G >> >> > >> >> > >> >> > >> >> > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < >> >> sankhesh.jhaveri at kitware.com> >> >> > wrote: >> >> > >> >> >> Hi Christian, >> >> >> >> >> >> Doing all VTK rendering on the QML render thread is the right thing >> to >> >> do. >> >> >> As far as interaction is concerned, make sure that Qt events are >> queued >> >> on >> >> >> the main thread and processed when execution reaches the render >> thread. >> >> >> >> >> >> I have done some work on VTK and QtQuick integration that I?m >> planning >> >> to >> >> >> add to a VTK remote module. That way, it will be available as part of >> >> VTK. >> >> >> >> >> >> Thanks, >> >> >> Sankhesh >> >> >> ? >> >> >> >> >> >> On Tue, May 16, 2017 at 4:57 AM wrote: >> >> >> >> >> >>> just for the record (nobody care about this subject?): >> >> >>> >> >> >>> I found that contrary to what I said I had NOT adhered to the >> >> >>> principle established with protoype 1 while implementing protoype 2. >> >> >>> Rather, I had directly called into the VTK interactor from the QML >> UI >> >> >>> thread. And because the VTK interactors immediately go into >> rendering, >> >> >>> all hell broke loose. >> >> >>> >> >> >>> After cleaning up example 2 according to the rule laid out earlier >> >> >>> ("store event data in RenderDelegate, call update() on the QML item, >> >> >>> pass the event to VTK inside RenderDelgate.Render()", all works >> well. >> >> >>> >> >> >>> What I would like to do is validate the solution against findings >> made >> >> >>> elsewhere, and then establish the "canonical" way of integrating VTK >> >> >>> with QML. As I said, there are some architectural quirks with the >> >> >>> solution which I would also like to address. >> >> >>> >> >> >>> regards, >> >> >>> Christian >> >> >>> >> >> >>> >> >> >>> Zitat von c.sell at byterefinery.de: >> >> >>> >> >> >>> > Hello all, >> >> >>> > >> >> >>> > I am looking into the possibility of replacing the 3D rendering >> >> >>> > engine in my Qt5 / QML based mobile tablet-oriented application >> with >> >> >>> > VTK. What I need is a first class QtQuick integration (not a hack >> or >> >> >>> > workaround) that is 100% stable in every context (not an unusual >> >> >>> > requirement, I admit). To my amazement, nothing of that kind seems >> >> >>> > to exist (correct me if I'm wrong). >> >> >>> > >> >> >>> > I went on to investigate what had been done so far and to >> implement >> >> >>> > my first prototypes, using the QQuickFrameBufferObject approach. >> >> >>> > From the very start this felt like an uphill battle, because VTK >> >> >>> > seems to come from a Windowing background and is quite tightly >> >> >>> > integrated with concepts that are not valid in a QML context. >> >> >>> > >> >> >>> > I'll describe my findings together with the 2 prototypical QML >> items >> >> >>> > I implemented: >> >> >>> > >> >> >>> > 1st was an adaptation of the DICOM example which now runs as a QML >> >> >>> > item. All user interaction is handled by QML and forwarded to VTK >> >> >>> > (which is one thing that doesn't come naturally with VTK), and >> after >> >> >>> > some non-elegant tweaking I was able to have the UI move from >> slice >> >> >>> > to slice and re-render upon mouse wheel events as expected. The >> >> >>> > problem here was, that QML insists on keeping mouse event handling >> >> >>> > and OpenGL rendering on separate threads, with one "rendering >> >> >>> > thread" dedicated to OpenGL. However, the pre-existing VTK >> >> >>> > Interactors directly call Render() after reconfiguring the UI from >> >> >>> > the mouse event data, which is an absolute QML No-Go. I had to >> >> >>> > introduce a RenderDelegate that works somewhat like this: >> >> >>> > >> >> >>> > QML mouse event: >> >> >>> > tell RenderDelegate about the event >> >> >>> > call update() on the QML item, which triggers rer-endering on >> >> >>> > the dedicated thread >> >> >>> > on the QML rendering thread: >> >> >>> > call Render() on the RenderWindow >> >> >>> > inside the RenderDelegate, look at whether a mouse event is >> >> >>> > pending, and call the corresponding VTK mouse handler >> >> >>> > call the renderer's default Render() function while setting >> the >> >> >>> > delegate's "Used" flag to false >> >> >>> > >> >> >>> > 2nd was a QML item that displays a model loaded from a 3ds file. >> My >> >> >>> > goal here was to move the model around using mouse drag events. I >> >> >>> > took the lessons learned from the first example, threw in a >> >> >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First >> >> >>> > thing I found was that I needed a specialized >> >> >>> > RenderWindowInteractor, which I provided. When I realized that the >> >> >>> > most important requirement for that class was to provide access to >> >> >>> > timer functionality, I already got wary, as throwing around events >> >> >>> > and doing stuff offline while on the QML rendering thread is >> never a >> >> >>> > good idea. My fears came true when I finished wiring everything >> >> >>> > together: I was able to move the model using the mouse, but after >> a >> >> >>> > few moments things got whacky with error output written to the >> >> >>> > console and finally a segemtation fault from deep inside VTK. >> >> >>> > >> >> >>> > I still need to investigate the second example, but would like to >> >> >>> > synchronize with the community at this point in order to avoid >> >> >>> > errors/misconceptions on my side, to seek help if possible and to >> >> >>> > offer my contribution to the VTK code base once this becomes >> >> >>> > functional. My first impression is that there are some issues that >> >> >>> > lie on an architectural level and cannot be (elegantly) dealt with >> >> >>> > on the QML side alone. Any comments? >> >> >>> > >> >> >>> > thanks, >> >> >>> > Christian Sell >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > 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: >> >> >>> > http://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: >> >> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >>> >> >> >>> -- >> >> >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >> >> >> | (518) 881-4417 >> >> >> ? >> >> >> _______________________________________________ >> >> >> 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: >> >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From c.sell at byterefinery.de Wed May 17 04:14:56 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Wed, 17 May 2017 08:14:56 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170517080907.Horde.gMGdDBGskRU8Z_mFOXJOz7t@webmail.byterefinery.de> References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> <20170517080907.Horde.gMGdDBGskRU8Z_mFOXJOz7t@webmail.byterefinery.de> Message-ID: <20170517081456.Horde.SC6Gr0L2154_Vw6KKU6IVkc@webmail.byterefinery.de> I have to correct myself with regard to the "direct rendering" option. There is, of course, an example that demonstrates this (http://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html). I doubt whether this could be implemented in conjunction with thread-per-item, so it only adds one architectural option. I still think this is the least versatile and generic one, though. chris Zitat von c.sell at byterefinery.de: > ok, things are clearing up a little more now. You ARE creating a > separate thread for each QML item, which gives us these threads: > > - QML GUI thread (where the events come from) > - QML rendering thread (aka scenegraph rendering thread aka > QSGRenderThread), of which theres is only one > - a dedicated thread for each item (RenderThread class in the example) > > the example also uses a QSGSimpleTextureNode subclass that does the > blit'ing together. All of that decoupled via QueuedConnections and > events signalled here and there. Not an easy beast, that. > > What remains unclear is how you deal with user input. For example, > if the user were to drag something around in the scene (and your app > were to support that), where do the MouseMove events go? This is > really the main crux in this discussion IMO. > > To sum up the architectural choices: > > a) render into FBO > a1)- do all rendering on the scenegraph thread (exemplified in > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html) > > a2) render on a dedicated thread for each item (exemplified in > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html) > > b) render into the QML context directly (not sure about this. Is > there a Qt example demonstrating the practicability?) > b?) undetermined > > > The user intaction part is undetermined for me at this point. I am > trying to get something going using QVTKInteractorAdapter, but > havent had luck so far. > > In terms of ready usable code that demonstrates QML/VTK integration > (including interaction and all) I see nothing yet on the horizon. > > chris > > > > Zitat von Geoff Wright : > >> Yes each vtk item has its own render thread that is why I would argue this >> approach is superior to the others since it scales with the number of cores. >> >> I followed the approach described here: >> >> http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html >> >> So basically inside each vtk qml item there is a thread drawing a vtk >> viewport into a texture, then the QSGRenderThread comes along and just does >> a single texture blit for each item (very cheap). The Qt main thread takes >> care of other event processing, models etc. >> >> This is sufficient if each item contains an independent scene (vtk >> pipeline). If you need to share state between two or more viewports then >> you need to be careful to control the timing of when any data objects may >> mutate since the vtk api is not inherently threadsafe. >> >> Does that make sense? >> >> G >> >> >> >> On Tue, May 16, 2017, 6:13 PM wrote: >> >>> Hello all, >>> >>> @Geoff: are you saying that each pair of QML item / vtkRenderWindow >>> has its own render thread? Is that something QML does? >>> >>> My goal is to have QML/VTK items behave as normal QML items, i.e., I >>> could have a dozen items on my screen each rendering something >>> different through VTK without influencing each other (apart from >>> system performance). I expect that the approach I have taken so far >>> will already fulfill this requirement. >>> >>> @Sankesh: I object to the compile time flag. IMO both approaches >>> should be usable at the same time, e.g. by extending different >>> superclasses. As you say, the "underlay or overlay" aspect breaks QML >>> concepts and makes any item built according to this approach an >>> "alien" in the QML crowd that always requires special attention. >>> >>> I'll look into QVTKInteractorAdapter - that sounds like seomething >>> useful. Should have come across it earlier. >>> >>> @both: is there a chance that usable code will come out of this >>> exchange any time soon? I for my part would at least publish my >>> prototypical implementations somewhere (GitHub?), unless they become >>> obsolete by something "official" >>> >>> regards, >>> Chris >>> >>> Zitat von Geoff Wright : >>> >>>> Hi Chris, >>>> >>>> Sorry for the confusion, yes I am doing what you describe. The >>> difference >>>> may be that perhaps your app has only one viewport. In my case there >>> are a >>>> number of different viewports (aka vtkRenderWindow) each has its own qml >>>> item and is each rendering on it's own thread. Plus the qml composition >>>> thread which is managed by Qt. >>>> >>>> I was just making the point that this architecture let's you draw >>> different >>>> viewports in parallel provided that each one has its own mappers and >>> actors. >>>> >>>> G >>>> >>>> >>>> On Tue, May 16, 2017, 4:13 PM wrote: >>>> >>>>> Hi Geoff, >>>>> >>>>> as I understand it, the blog post you linked to doesn't mention >>>>> multiple threads beyond the QML UI thread and the scenegraph render >>>>> thread. >>>>> >>>>> So far, I am using that approach with QQuickFrameBufferObject as >>>>> starting point and vtkExternalOpenGLRenderWindow for the VTK side, >>>>> which causes VTK to use QML's OpenGL context and thus render into the >>>>> FBO maintained by QQuickFrameBufferObject. That seems to work >>>>> flawlessly, as long as ALL rendering is kept on the scenegraph thread, >>>>> which is not always obvious to do at first, because VTK's API's don't >>>>> separate between reading event values and rendering them (e.g., >>>>> SetSlice(2) will internally set the current slice and then do a >>>>> Render()). >>>>> >>>>> But why maintain more threads? >>>>> >>>>> Anyway, please go ahead and explain your approach as detailed as >>>>> possible, I am all ears. >>>>> >>>>> regards, >>>>> Chris >>>>> >>>>> Zitat von Geoff Wright : >>>>> >>>>> > Hi guys, >>>>> > >>>>> > I would argue that for qml integration the best approach is for each >>> vtk >>>>> > viewport to render into a texture on a dedicated thread, not the qml >>>>> > rendering thread. Qml then draws the resulting texture which is more >>> in >>>>> > line with the Qt design intention ( see >>>>> > >>>>> >>> http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ >>>>> > ) >>>>> > >>>>> > I have been using this approach for a couple of years in a high >>>>> performance >>>>> > real time application. The code is unfortunately proprietary but very >>>>> > happy to explain more about the approach. It would be great to add >>>>> support >>>>> > for this to VTK. >>>>> > >>>>> > For the interactor part I do what Sankesh said, defer the events and >>>>> apply >>>>> > them on the render thread of the particular vtk item. >>>>> > >>>>> > Regards, >>>>> > >>>>> > G >>>>> > >>>>> > >>>>> > >>>>> > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < >>>>> sankhesh.jhaveri at kitware.com> >>>>> > wrote: >>>>> > >>>>> >> Hi Christian, >>>>> >> >>>>> >> Doing all VTK rendering on the QML render thread is the right thing >>> to >>>>> do. >>>>> >> As far as interaction is concerned, make sure that Qt events are >>> queued >>>>> on >>>>> >> the main thread and processed when execution reaches the render >>> thread. >>>>> >> >>>>> >> I have done some work on VTK and QtQuick integration that I?m >>> planning >>>>> to >>>>> >> add to a VTK remote module. That way, it will be available as part of >>>>> VTK. >>>>> >> >>>>> >> Thanks, >>>>> >> Sankhesh >>>>> >> ? >>>>> >> >>>>> >> On Tue, May 16, 2017 at 4:57 AM wrote: >>>>> >> >>>>> >>> just for the record (nobody care about this subject?): >>>>> >>> >>>>> >>> I found that contrary to what I said I had NOT adhered to the >>>>> >>> principle established with protoype 1 while implementing protoype 2. >>>>> >>> Rather, I had directly called into the VTK interactor from the QML >>> UI >>>>> >>> thread. And because the VTK interactors immediately go into >>> rendering, >>>>> >>> all hell broke loose. >>>>> >>> >>>>> >>> After cleaning up example 2 according to the rule laid out earlier >>>>> >>> ("store event data in RenderDelegate, call update() on the QML item, >>>>> >>> pass the event to VTK inside RenderDelgate.Render()", all works >>> well. >>>>> >>> >>>>> >>> What I would like to do is validate the solution against findings >>> made >>>>> >>> elsewhere, and then establish the "canonical" way of integrating VTK >>>>> >>> with QML. As I said, there are some architectural quirks with the >>>>> >>> solution which I would also like to address. >>>>> >>> >>>>> >>> regards, >>>>> >>> Christian >>>>> >>> >>>>> >>> >>>>> >>> Zitat von c.sell at byterefinery.de: >>>>> >>> >>>>> >>> > Hello all, >>>>> >>> > >>>>> >>> > I am looking into the possibility of replacing the 3D rendering >>>>> >>> > engine in my Qt5 / QML based mobile tablet-oriented application >>> with >>>>> >>> > VTK. What I need is a first class QtQuick integration (not a hack >>> or >>>>> >>> > workaround) that is 100% stable in every context (not an unusual >>>>> >>> > requirement, I admit). To my amazement, nothing of that kind seems >>>>> >>> > to exist (correct me if I'm wrong). >>>>> >>> > >>>>> >>> > I went on to investigate what had been done so far and to >>> implement >>>>> >>> > my first prototypes, using the QQuickFrameBufferObject approach. >>>>> >>> > From the very start this felt like an uphill battle, because VTK >>>>> >>> > seems to come from a Windowing background and is quite tightly >>>>> >>> > integrated with concepts that are not valid in a QML context. >>>>> >>> > >>>>> >>> > I'll describe my findings together with the 2 prototypical QML >>> items >>>>> >>> > I implemented: >>>>> >>> > >>>>> >>> > 1st was an adaptation of the DICOM example which now runs as a QML >>>>> >>> > item. All user interaction is handled by QML and forwarded to VTK >>>>> >>> > (which is one thing that doesn't come naturally with VTK), and >>> after >>>>> >>> > some non-elegant tweaking I was able to have the UI move from >>> slice >>>>> >>> > to slice and re-render upon mouse wheel events as expected. The >>>>> >>> > problem here was, that QML insists on keeping mouse event handling >>>>> >>> > and OpenGL rendering on separate threads, with one "rendering >>>>> >>> > thread" dedicated to OpenGL. However, the pre-existing VTK >>>>> >>> > Interactors directly call Render() after reconfiguring the UI from >>>>> >>> > the mouse event data, which is an absolute QML No-Go. I had to >>>>> >>> > introduce a RenderDelegate that works somewhat like this: >>>>> >>> > >>>>> >>> > QML mouse event: >>>>> >>> > tell RenderDelegate about the event >>>>> >>> > call update() on the QML item, which triggers rer-endering on >>>>> >>> > the dedicated thread >>>>> >>> > on the QML rendering thread: >>>>> >>> > call Render() on the RenderWindow >>>>> >>> > inside the RenderDelegate, look at whether a mouse event is >>>>> >>> > pending, and call the corresponding VTK mouse handler >>>>> >>> > call the renderer's default Render() function while setting >>> the >>>>> >>> > delegate's "Used" flag to false >>>>> >>> > >>>>> >>> > 2nd was a QML item that displays a model loaded from a 3ds file. >>> My >>>>> >>> > goal here was to move the model around using mouse drag events. I >>>>> >>> > took the lessons learned from the first example, threw in a >>>>> >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First >>>>> >>> > thing I found was that I needed a specialized >>>>> >>> > RenderWindowInteractor, which I provided. When I realized that the >>>>> >>> > most important requirement for that class was to provide access to >>>>> >>> > timer functionality, I already got wary, as throwing around events >>>>> >>> > and doing stuff offline while on the QML rendering thread is >>> never a >>>>> >>> > good idea. My fears came true when I finished wiring everything >>>>> >>> > together: I was able to move the model using the mouse, but after >>> a >>>>> >>> > few moments things got whacky with error output written to the >>>>> >>> > console and finally a segemtation fault from deep inside VTK. >>>>> >>> > >>>>> >>> > I still need to investigate the second example, but would like to >>>>> >>> > synchronize with the community at this point in order to avoid >>>>> >>> > errors/misconceptions on my side, to seek help if possible and to >>>>> >>> > offer my contribution to the VTK code base once this becomes >>>>> >>> > functional. My first impression is that there are some issues that >>>>> >>> > lie on an architectural level and cannot be (elegantly) dealt with >>>>> >>> > on the QML side alone. Any comments? >>>>> >>> > >>>>> >>> > thanks, >>>>> >>> > Christian Sell >>>>> >>> > >>>>> >>> > _______________________________________________ >>>>> >>> > 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: >>>>> >>> > http://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: >>>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>> >>>>> >>> -- >>>>> >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >>>>> >> | (518) 881-4417 >>>>> >> ? >>>>> >> _______________________________________________ >>>>> >> 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: >>>>> >> http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers From gpwright at gmail.com Wed May 17 05:44:55 2017 From: gpwright at gmail.com (Geoff Wright) Date: Wed, 17 May 2017 09:44:55 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: <20170517081456.Horde.SC6Gr0L2154_Vw6KKU6IVkc@webmail.byterefinery.de> References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> <20170517080907.Horde.gMGdDBGskRU8Z_mFOXJOz7t@webmail.byterefinery.de> <20170517081456.Horde.SC6Gr0L2154_Vw6KKU6IVkc@webmail.byterefinery.de> Message-ID: Hi Chris, For the interactor there is a way to basically queue the event information you need e.g. from qmls onPressed and then pass it to an interactor that belongs to the particular viewport that was pressed/clicked so that it will be handled once that thread is being rendered. However, I found that I quickly wanted a more advanced interaction. For example if your vtk qml item is inside a qml Flickable you can easily do very nice interactions for touch such as rotational momentum on flick that continues after release. I am not sure of the latest touch interactor in vtk but when I was working on this a couple of years ago it was easier to handle all of the interactor part in QML (e.g. utilizing Flickable) and then pass info to the rendering thread that would directly mutate the camera, effectively making the vtkCamera a slave to some qml properties. However if vtk has caught up with momentum based touch interactors it may be worthwhile to use these. I am not caught up with what's been added to VTK in recent months. Another advantage of keeping the camera master state in QML is that you can use Qt animation framework easily (e.g. they recently added an orientation animation that can be useful for controlling a camera). I think it depends how complex are the user interactions that you are planning for. G On Wed, May 17, 2017, 10:15 AM wrote: > I have to correct myself with regard to the "direct rendering" option. > There is, of course, an example that demonstrates this > (http://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html). I > doubt whether this could be implemented in conjunction with > thread-per-item, so it only adds one architectural option. I still > think this is the least versatile and generic one, though. > > chris > > Zitat von c.sell at byterefinery.de: > > > ok, things are clearing up a little more now. You ARE creating a > > separate thread for each QML item, which gives us these threads: > > > > - QML GUI thread (where the events come from) > > - QML rendering thread (aka scenegraph rendering thread aka > > QSGRenderThread), of which theres is only one > > - a dedicated thread for each item (RenderThread class in the example) > > > > the example also uses a QSGSimpleTextureNode subclass that does the > > blit'ing together. All of that decoupled via QueuedConnections and > > events signalled here and there. Not an easy beast, that. > > > > What remains unclear is how you deal with user input. For example, > > if the user were to drag something around in the scene (and your app > > were to support that), where do the MouseMove events go? This is > > really the main crux in this discussion IMO. > > > > To sum up the architectural choices: > > > > a) render into FBO > > a1)- do all rendering on the scenegraph thread (exemplified in > > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html) > > > > a2) render on a dedicated thread for each item (exemplified in > > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html) > > > > b) render into the QML context directly (not sure about this. Is > > there a Qt example demonstrating the practicability?) > > b?) undetermined > > > > > > The user intaction part is undetermined for me at this point. I am > > trying to get something going using QVTKInteractorAdapter, but > > havent had luck so far. > > > > In terms of ready usable code that demonstrates QML/VTK integration > > (including interaction and all) I see nothing yet on the horizon. > > > > chris > > > > > > > > Zitat von Geoff Wright : > > > >> Yes each vtk item has its own render thread that is why I would argue > this > >> approach is superior to the others since it scales with the number of > cores. > >> > >> I followed the approach described here: > >> > >> http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html > >> > >> So basically inside each vtk qml item there is a thread drawing a vtk > >> viewport into a texture, then the QSGRenderThread comes along and just > does > >> a single texture blit for each item (very cheap). The Qt main thread > takes > >> care of other event processing, models etc. > >> > >> This is sufficient if each item contains an independent scene (vtk > >> pipeline). If you need to share state between two or more viewports > then > >> you need to be careful to control the timing of when any data objects > may > >> mutate since the vtk api is not inherently threadsafe. > >> > >> Does that make sense? > >> > >> G > >> > >> > >> > >> On Tue, May 16, 2017, 6:13 PM wrote: > >> > >>> Hello all, > >>> > >>> @Geoff: are you saying that each pair of QML item / vtkRenderWindow > >>> has its own render thread? Is that something QML does? > >>> > >>> My goal is to have QML/VTK items behave as normal QML items, i.e., I > >>> could have a dozen items on my screen each rendering something > >>> different through VTK without influencing each other (apart from > >>> system performance). I expect that the approach I have taken so far > >>> will already fulfill this requirement. > >>> > >>> @Sankesh: I object to the compile time flag. IMO both approaches > >>> should be usable at the same time, e.g. by extending different > >>> superclasses. As you say, the "underlay or overlay" aspect breaks QML > >>> concepts and makes any item built according to this approach an > >>> "alien" in the QML crowd that always requires special attention. > >>> > >>> I'll look into QVTKInteractorAdapter - that sounds like seomething > >>> useful. Should have come across it earlier. > >>> > >>> @both: is there a chance that usable code will come out of this > >>> exchange any time soon? I for my part would at least publish my > >>> prototypical implementations somewhere (GitHub?), unless they become > >>> obsolete by something "official" > >>> > >>> regards, > >>> Chris > >>> > >>> Zitat von Geoff Wright : > >>> > >>>> Hi Chris, > >>>> > >>>> Sorry for the confusion, yes I am doing what you describe. The > >>> difference > >>>> may be that perhaps your app has only one viewport. In my case there > >>> are a > >>>> number of different viewports (aka vtkRenderWindow) each has its own > qml > >>>> item and is each rendering on it's own thread. Plus the qml > composition > >>>> thread which is managed by Qt. > >>>> > >>>> I was just making the point that this architecture let's you draw > >>> different > >>>> viewports in parallel provided that each one has its own mappers and > >>> actors. > >>>> > >>>> G > >>>> > >>>> > >>>> On Tue, May 16, 2017, 4:13 PM wrote: > >>>> > >>>>> Hi Geoff, > >>>>> > >>>>> as I understand it, the blog post you linked to doesn't mention > >>>>> multiple threads beyond the QML UI thread and the scenegraph render > >>>>> thread. > >>>>> > >>>>> So far, I am using that approach with QQuickFrameBufferObject as > >>>>> starting point and vtkExternalOpenGLRenderWindow for the VTK side, > >>>>> which causes VTK to use QML's OpenGL context and thus render into the > >>>>> FBO maintained by QQuickFrameBufferObject. That seems to work > >>>>> flawlessly, as long as ALL rendering is kept on the scenegraph > thread, > >>>>> which is not always obvious to do at first, because VTK's API's don't > >>>>> separate between reading event values and rendering them (e.g., > >>>>> SetSlice(2) will internally set the current slice and then do a > >>>>> Render()). > >>>>> > >>>>> But why maintain more threads? > >>>>> > >>>>> Anyway, please go ahead and explain your approach as detailed as > >>>>> possible, I am all ears. > >>>>> > >>>>> regards, > >>>>> Chris > >>>>> > >>>>> Zitat von Geoff Wright : > >>>>> > >>>>> > Hi guys, > >>>>> > > >>>>> > I would argue that for qml integration the best approach is for > each > >>> vtk > >>>>> > viewport to render into a texture on a dedicated thread, not the > qml > >>>>> > rendering thread. Qml then draws the resulting texture which is > more > >>> in > >>>>> > line with the Qt design intention ( see > >>>>> > > >>>>> > >>> > http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ > >>>>> > ) > >>>>> > > >>>>> > I have been using this approach for a couple of years in a high > >>>>> performance > >>>>> > real time application. The code is unfortunately proprietary but > very > >>>>> > happy to explain more about the approach. It would be great to add > >>>>> support > >>>>> > for this to VTK. > >>>>> > > >>>>> > For the interactor part I do what Sankesh said, defer the events > and > >>>>> apply > >>>>> > them on the render thread of the particular vtk item. > >>>>> > > >>>>> > Regards, > >>>>> > > >>>>> > G > >>>>> > > >>>>> > > >>>>> > > >>>>> > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < > >>>>> sankhesh.jhaveri at kitware.com> > >>>>> > wrote: > >>>>> > > >>>>> >> Hi Christian, > >>>>> >> > >>>>> >> Doing all VTK rendering on the QML render thread is the right > thing > >>> to > >>>>> do. > >>>>> >> As far as interaction is concerned, make sure that Qt events are > >>> queued > >>>>> on > >>>>> >> the main thread and processed when execution reaches the render > >>> thread. > >>>>> >> > >>>>> >> I have done some work on VTK and QtQuick integration that I?m > >>> planning > >>>>> to > >>>>> >> add to a VTK remote module. That way, it will be available as > part of > >>>>> VTK. > >>>>> >> > >>>>> >> Thanks, > >>>>> >> Sankhesh > >>>>> >> ? > >>>>> >> > >>>>> >> On Tue, May 16, 2017 at 4:57 AM wrote: > >>>>> >> > >>>>> >>> just for the record (nobody care about this subject?): > >>>>> >>> > >>>>> >>> I found that contrary to what I said I had NOT adhered to the > >>>>> >>> principle established with protoype 1 while implementing > protoype 2. > >>>>> >>> Rather, I had directly called into the VTK interactor from the > QML > >>> UI > >>>>> >>> thread. And because the VTK interactors immediately go into > >>> rendering, > >>>>> >>> all hell broke loose. > >>>>> >>> > >>>>> >>> After cleaning up example 2 according to the rule laid out > earlier > >>>>> >>> ("store event data in RenderDelegate, call update() on the QML > item, > >>>>> >>> pass the event to VTK inside RenderDelgate.Render()", all works > >>> well. > >>>>> >>> > >>>>> >>> What I would like to do is validate the solution against findings > >>> made > >>>>> >>> elsewhere, and then establish the "canonical" way of integrating > VTK > >>>>> >>> with QML. As I said, there are some architectural quirks with the > >>>>> >>> solution which I would also like to address. > >>>>> >>> > >>>>> >>> regards, > >>>>> >>> Christian > >>>>> >>> > >>>>> >>> > >>>>> >>> Zitat von c.sell at byterefinery.de: > >>>>> >>> > >>>>> >>> > Hello all, > >>>>> >>> > > >>>>> >>> > I am looking into the possibility of replacing the 3D rendering > >>>>> >>> > engine in my Qt5 / QML based mobile tablet-oriented application > >>> with > >>>>> >>> > VTK. What I need is a first class QtQuick integration (not a > hack > >>> or > >>>>> >>> > workaround) that is 100% stable in every context (not an > unusual > >>>>> >>> > requirement, I admit). To my amazement, nothing of that kind > seems > >>>>> >>> > to exist (correct me if I'm wrong). > >>>>> >>> > > >>>>> >>> > I went on to investigate what had been done so far and to > >>> implement > >>>>> >>> > my first prototypes, using the QQuickFrameBufferObject > approach. > >>>>> >>> > From the very start this felt like an uphill battle, because > VTK > >>>>> >>> > seems to come from a Windowing background and is quite tightly > >>>>> >>> > integrated with concepts that are not valid in a QML context. > >>>>> >>> > > >>>>> >>> > I'll describe my findings together with the 2 prototypical QML > >>> items > >>>>> >>> > I implemented: > >>>>> >>> > > >>>>> >>> > 1st was an adaptation of the DICOM example which now runs as a > QML > >>>>> >>> > item. All user interaction is handled by QML and forwarded to > VTK > >>>>> >>> > (which is one thing that doesn't come naturally with VTK), and > >>> after > >>>>> >>> > some non-elegant tweaking I was able to have the UI move from > >>> slice > >>>>> >>> > to slice and re-render upon mouse wheel events as expected. The > >>>>> >>> > problem here was, that QML insists on keeping mouse event > handling > >>>>> >>> > and OpenGL rendering on separate threads, with one "rendering > >>>>> >>> > thread" dedicated to OpenGL. However, the pre-existing VTK > >>>>> >>> > Interactors directly call Render() after reconfiguring the UI > from > >>>>> >>> > the mouse event data, which is an absolute QML No-Go. I had to > >>>>> >>> > introduce a RenderDelegate that works somewhat like this: > >>>>> >>> > > >>>>> >>> > QML mouse event: > >>>>> >>> > tell RenderDelegate about the event > >>>>> >>> > call update() on the QML item, which triggers rer-endering > on > >>>>> >>> > the dedicated thread > >>>>> >>> > on the QML rendering thread: > >>>>> >>> > call Render() on the RenderWindow > >>>>> >>> > inside the RenderDelegate, look at whether a mouse event is > >>>>> >>> > pending, and call the corresponding VTK mouse handler > >>>>> >>> > call the renderer's default Render() function while setting > >>> the > >>>>> >>> > delegate's "Used" flag to false > >>>>> >>> > > >>>>> >>> > 2nd was a QML item that displays a model loaded from a 3ds > file. > >>> My > >>>>> >>> > goal here was to move the model around using mouse drag > events. I > >>>>> >>> > took the lessons learned from the first example, threw in a > >>>>> >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First > >>>>> >>> > thing I found was that I needed a specialized > >>>>> >>> > RenderWindowInteractor, which I provided. When I realized that > the > >>>>> >>> > most important requirement for that class was to provide > access to > >>>>> >>> > timer functionality, I already got wary, as throwing around > events > >>>>> >>> > and doing stuff offline while on the QML rendering thread is > >>> never a > >>>>> >>> > good idea. My fears came true when I finished wiring everything > >>>>> >>> > together: I was able to move the model using the mouse, but > after > >>> a > >>>>> >>> > few moments things got whacky with error output written to the > >>>>> >>> > console and finally a segemtation fault from deep inside VTK. > >>>>> >>> > > >>>>> >>> > I still need to investigate the second example, but would like > to > >>>>> >>> > synchronize with the community at this point in order to avoid > >>>>> >>> > errors/misconceptions on my side, to seek help if possible and > to > >>>>> >>> > offer my contribution to the VTK code base once this becomes > >>>>> >>> > functional. My first impression is that there are some issues > that > >>>>> >>> > lie on an architectural level and cannot be (elegantly) dealt > with > >>>>> >>> > on the QML side alone. Any comments? > >>>>> >>> > > >>>>> >>> > thanks, > >>>>> >>> > Christian Sell > >>>>> >>> > > >>>>> >>> > _______________________________________________ > >>>>> >>> > 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: > >>>>> >>> > http://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: > >>>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>>> >>> > >>>>> >>> -- > >>>>> >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > >>>>> >> | (518) 881-4417 > >>>>> >> ? > >>>>> >> _______________________________________________ > >>>>> >> 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: > >>>>> >> http://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: > > http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed May 17 11:04:31 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 17 May 2017 11:04:31 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: References: <20170516152418.GA11273@megas.kitware.com> <20170516175809.GB32636@rotor> Message-ID: <20170517150431.GB25196@megas.kitware.com> On Tue, May 16, 2017 at 22:15:28 -0400, Aron Helser wrote: > I had to add a file glob to get the .pyc files, since they now include the > interpreter and python version in the filename. But we have the version of Python we're using, so we could at least factor that bit out of the glob. I don't think we really support anything other than cpython either? --Ben From c.sell at byterefinery.de Thu May 18 03:55:21 2017 From: c.sell at byterefinery.de (c.sell at byterefinery.de) Date: Thu, 18 May 2017 07:55:21 +0000 Subject: [vtk-developers] VTK and Qt5 / QML In-Reply-To: References: <20170515131735.Horde.ZTMfgJqmHAGbykyxEsH8yNj@webmail.byterefinery.de> <20170516085724.Horde.4JmR7cLTSr7V4ZwR75uyH_z@webmail.byterefinery.de> <20170516141359.Horde.QF2zcue1oaAldgNHXUSPDYj@webmail.byterefinery.de> <20170516161338.Horde.-LpGtgPk3ZqUiJ-HNmTyCiL@webmail.byterefinery.de> <20170517080907.Horde.gMGdDBGskRU8Z_mFOXJOz7t@webmail.byterefinery.de> <20170517081456.Horde.SC6Gr0L2154_Vw6KKU6IVkc@webmail.byterefinery.de> Message-ID: <20170518075521.Horde.KfRfZr0cYwRwkoeeR4siDjH@webmail.byterefinery.de> ok, thanks for the exchange, I think I have a better understanding now. I have managed to get the code running with QVTKInteractor and siblings - it was a matter of instantiating an (Q-)object at the wrong time and thus on the wrong thread => no rendering. I may try the multi-threaded approach as well, and will publish the sample code on github once I am happy with it. chris Zitat von Geoff Wright : > Hi Chris, > > For the interactor there is a way to basically queue the event information > you need e.g. from qmls onPressed and then pass it to an interactor that > belongs to the particular viewport that was pressed/clicked so that it will > be handled once that thread is being rendered. > > However, I found that I quickly wanted a more advanced interaction. For > example if your vtk qml item is inside a qml Flickable you can easily do > very nice interactions for touch such as rotational momentum on flick that > continues after release. > > I am not sure of the latest touch interactor in vtk but when I was working > on this a couple of years ago it was easier to handle all of the interactor > part in QML (e.g. utilizing Flickable) and then pass info to the rendering > thread that would directly mutate the camera, effectively making the > vtkCamera a slave to some qml properties. > > However if vtk has caught up with momentum based touch interactors it may > be worthwhile to use these. I am not caught up with what's been added to > VTK in recent months. Another advantage of keeping the camera master state > in QML is that you can use Qt animation framework easily (e.g. they > recently added an orientation animation that can be useful for controlling > a camera). > > I think it depends how complex are the user interactions that you are > planning for. > > G > > > > > > On Wed, May 17, 2017, 10:15 AM wrote: > >> I have to correct myself with regard to the "direct rendering" option. >> There is, of course, an example that demonstrates this >> (http://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html). I >> doubt whether this could be implemented in conjunction with >> thread-per-item, so it only adds one architectural option. I still >> think this is the least versatile and generic one, though. >> >> chris >> >> Zitat von c.sell at byterefinery.de: >> >> > ok, things are clearing up a little more now. You ARE creating a >> > separate thread for each QML item, which gives us these threads: >> > >> > - QML GUI thread (where the events come from) >> > - QML rendering thread (aka scenegraph rendering thread aka >> > QSGRenderThread), of which theres is only one >> > - a dedicated thread for each item (RenderThread class in the example) >> > >> > the example also uses a QSGSimpleTextureNode subclass that does the >> > blit'ing together. All of that decoupled via QueuedConnections and >> > events signalled here and there. Not an easy beast, that. >> > >> > What remains unclear is how you deal with user input. For example, >> > if the user were to drag something around in the scene (and your app >> > were to support that), where do the MouseMove events go? This is >> > really the main crux in this discussion IMO. >> > >> > To sum up the architectural choices: >> > >> > a) render into FBO >> > a1)- do all rendering on the scenegraph thread (exemplified in >> > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html) >> > >> > a2) render on a dedicated thread for each item (exemplified in >> > http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html) >> > >> > b) render into the QML context directly (not sure about this. Is >> > there a Qt example demonstrating the practicability?) >> > b?) undetermined >> > >> > >> > The user intaction part is undetermined for me at this point. I am >> > trying to get something going using QVTKInteractorAdapter, but >> > havent had luck so far. >> > >> > In terms of ready usable code that demonstrates QML/VTK integration >> > (including interaction and all) I see nothing yet on the horizon. >> > >> > chris >> > >> > >> > >> > Zitat von Geoff Wright : >> > >> >> Yes each vtk item has its own render thread that is why I would argue >> this >> >> approach is superior to the others since it scales with the number of >> cores. >> >> >> >> I followed the approach described here: >> >> >> >> http://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html >> >> >> >> So basically inside each vtk qml item there is a thread drawing a vtk >> >> viewport into a texture, then the QSGRenderThread comes along and just >> does >> >> a single texture blit for each item (very cheap). The Qt main thread >> takes >> >> care of other event processing, models etc. >> >> >> >> This is sufficient if each item contains an independent scene (vtk >> >> pipeline). If you need to share state between two or more viewports >> then >> >> you need to be careful to control the timing of when any data objects >> may >> >> mutate since the vtk api is not inherently threadsafe. >> >> >> >> Does that make sense? >> >> >> >> G >> >> >> >> >> >> >> >> On Tue, May 16, 2017, 6:13 PM wrote: >> >> >> >>> Hello all, >> >>> >> >>> @Geoff: are you saying that each pair of QML item / vtkRenderWindow >> >>> has its own render thread? Is that something QML does? >> >>> >> >>> My goal is to have QML/VTK items behave as normal QML items, i.e., I >> >>> could have a dozen items on my screen each rendering something >> >>> different through VTK without influencing each other (apart from >> >>> system performance). I expect that the approach I have taken so far >> >>> will already fulfill this requirement. >> >>> >> >>> @Sankesh: I object to the compile time flag. IMO both approaches >> >>> should be usable at the same time, e.g. by extending different >> >>> superclasses. As you say, the "underlay or overlay" aspect breaks QML >> >>> concepts and makes any item built according to this approach an >> >>> "alien" in the QML crowd that always requires special attention. >> >>> >> >>> I'll look into QVTKInteractorAdapter - that sounds like seomething >> >>> useful. Should have come across it earlier. >> >>> >> >>> @both: is there a chance that usable code will come out of this >> >>> exchange any time soon? I for my part would at least publish my >> >>> prototypical implementations somewhere (GitHub?), unless they become >> >>> obsolete by something "official" >> >>> >> >>> regards, >> >>> Chris >> >>> >> >>> Zitat von Geoff Wright : >> >>> >> >>>> Hi Chris, >> >>>> >> >>>> Sorry for the confusion, yes I am doing what you describe. The >> >>> difference >> >>>> may be that perhaps your app has only one viewport. In my case there >> >>> are a >> >>>> number of different viewports (aka vtkRenderWindow) each has its own >> qml >> >>>> item and is each rendering on it's own thread. Plus the qml >> composition >> >>>> thread which is managed by Qt. >> >>>> >> >>>> I was just making the point that this architecture let's you draw >> >>> different >> >>>> viewports in parallel provided that each one has its own mappers and >> >>> actors. >> >>>> >> >>>> G >> >>>> >> >>>> >> >>>> On Tue, May 16, 2017, 4:13 PM wrote: >> >>>> >> >>>>> Hi Geoff, >> >>>>> >> >>>>> as I understand it, the blog post you linked to doesn't mention >> >>>>> multiple threads beyond the QML UI thread and the scenegraph render >> >>>>> thread. >> >>>>> >> >>>>> So far, I am using that approach with QQuickFrameBufferObject as >> >>>>> starting point and vtkExternalOpenGLRenderWindow for the VTK side, >> >>>>> which causes VTK to use QML's OpenGL context and thus render into the >> >>>>> FBO maintained by QQuickFrameBufferObject. That seems to work >> >>>>> flawlessly, as long as ALL rendering is kept on the scenegraph >> thread, >> >>>>> which is not always obvious to do at first, because VTK's API's don't >> >>>>> separate between reading event values and rendering them (e.g., >> >>>>> SetSlice(2) will internally set the current slice and then do a >> >>>>> Render()). >> >>>>> >> >>>>> But why maintain more threads? >> >>>>> >> >>>>> Anyway, please go ahead and explain your approach as detailed as >> >>>>> possible, I am all ears. >> >>>>> >> >>>>> regards, >> >>>>> Chris >> >>>>> >> >>>>> Zitat von Geoff Wright : >> >>>>> >> >>>>> > Hi guys, >> >>>>> > >> >>>>> > I would argue that for qml integration the best approach is for >> each >> >>> vtk >> >>>>> > viewport to render into a texture on a dedicated thread, not the >> qml >> >>>>> > rendering thread. Qml then draws the resulting texture which is >> more >> >>> in >> >>>>> > line with the Qt design intention ( see >> >>>>> > >> >>>>> >> >>> >> http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/ >> >>>>> > ) >> >>>>> > >> >>>>> > I have been using this approach for a couple of years in a high >> >>>>> performance >> >>>>> > real time application. The code is unfortunately proprietary but >> very >> >>>>> > happy to explain more about the approach. It would be great to add >> >>>>> support >> >>>>> > for this to VTK. >> >>>>> > >> >>>>> > For the interactor part I do what Sankesh said, defer the events >> and >> >>>>> apply >> >>>>> > them on the render thread of the particular vtk item. >> >>>>> > >> >>>>> > Regards, >> >>>>> > >> >>>>> > G >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri < >> >>>>> sankhesh.jhaveri at kitware.com> >> >>>>> > wrote: >> >>>>> > >> >>>>> >> Hi Christian, >> >>>>> >> >> >>>>> >> Doing all VTK rendering on the QML render thread is the right >> thing >> >>> to >> >>>>> do. >> >>>>> >> As far as interaction is concerned, make sure that Qt events are >> >>> queued >> >>>>> on >> >>>>> >> the main thread and processed when execution reaches the render >> >>> thread. >> >>>>> >> >> >>>>> >> I have done some work on VTK and QtQuick integration that I?m >> >>> planning >> >>>>> to >> >>>>> >> add to a VTK remote module. That way, it will be available as >> part of >> >>>>> VTK. >> >>>>> >> >> >>>>> >> Thanks, >> >>>>> >> Sankhesh >> >>>>> >> ? >> >>>>> >> >> >>>>> >> On Tue, May 16, 2017 at 4:57 AM wrote: >> >>>>> >> >> >>>>> >>> just for the record (nobody care about this subject?): >> >>>>> >>> >> >>>>> >>> I found that contrary to what I said I had NOT adhered to the >> >>>>> >>> principle established with protoype 1 while implementing >> protoype 2. >> >>>>> >>> Rather, I had directly called into the VTK interactor from the >> QML >> >>> UI >> >>>>> >>> thread. And because the VTK interactors immediately go into >> >>> rendering, >> >>>>> >>> all hell broke loose. >> >>>>> >>> >> >>>>> >>> After cleaning up example 2 according to the rule laid out >> earlier >> >>>>> >>> ("store event data in RenderDelegate, call update() on the QML >> item, >> >>>>> >>> pass the event to VTK inside RenderDelgate.Render()", all works >> >>> well. >> >>>>> >>> >> >>>>> >>> What I would like to do is validate the solution against findings >> >>> made >> >>>>> >>> elsewhere, and then establish the "canonical" way of integrating >> VTK >> >>>>> >>> with QML. As I said, there are some architectural quirks with the >> >>>>> >>> solution which I would also like to address. >> >>>>> >>> >> >>>>> >>> regards, >> >>>>> >>> Christian >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> Zitat von c.sell at byterefinery.de: >> >>>>> >>> >> >>>>> >>> > Hello all, >> >>>>> >>> > >> >>>>> >>> > I am looking into the possibility of replacing the 3D rendering >> >>>>> >>> > engine in my Qt5 / QML based mobile tablet-oriented application >> >>> with >> >>>>> >>> > VTK. What I need is a first class QtQuick integration (not a >> hack >> >>> or >> >>>>> >>> > workaround) that is 100% stable in every context (not an >> unusual >> >>>>> >>> > requirement, I admit). To my amazement, nothing of that kind >> seems >> >>>>> >>> > to exist (correct me if I'm wrong). >> >>>>> >>> > >> >>>>> >>> > I went on to investigate what had been done so far and to >> >>> implement >> >>>>> >>> > my first prototypes, using the QQuickFrameBufferObject >> approach. >> >>>>> >>> > From the very start this felt like an uphill battle, because >> VTK >> >>>>> >>> > seems to come from a Windowing background and is quite tightly >> >>>>> >>> > integrated with concepts that are not valid in a QML context. >> >>>>> >>> > >> >>>>> >>> > I'll describe my findings together with the 2 prototypical QML >> >>> items >> >>>>> >>> > I implemented: >> >>>>> >>> > >> >>>>> >>> > 1st was an adaptation of the DICOM example which now runs as a >> QML >> >>>>> >>> > item. All user interaction is handled by QML and forwarded to >> VTK >> >>>>> >>> > (which is one thing that doesn't come naturally with VTK), and >> >>> after >> >>>>> >>> > some non-elegant tweaking I was able to have the UI move from >> >>> slice >> >>>>> >>> > to slice and re-render upon mouse wheel events as expected. The >> >>>>> >>> > problem here was, that QML insists on keeping mouse event >> handling >> >>>>> >>> > and OpenGL rendering on separate threads, with one "rendering >> >>>>> >>> > thread" dedicated to OpenGL. However, the pre-existing VTK >> >>>>> >>> > Interactors directly call Render() after reconfiguring the UI >> from >> >>>>> >>> > the mouse event data, which is an absolute QML No-Go. I had to >> >>>>> >>> > introduce a RenderDelegate that works somewhat like this: >> >>>>> >>> > >> >>>>> >>> > QML mouse event: >> >>>>> >>> > tell RenderDelegate about the event >> >>>>> >>> > call update() on the QML item, which triggers rer-endering >> on >> >>>>> >>> > the dedicated thread >> >>>>> >>> > on the QML rendering thread: >> >>>>> >>> > call Render() on the RenderWindow >> >>>>> >>> > inside the RenderDelegate, look at whether a mouse event is >> >>>>> >>> > pending, and call the corresponding VTK mouse handler >> >>>>> >>> > call the renderer's default Render() function while setting >> >>> the >> >>>>> >>> > delegate's "Used" flag to false >> >>>>> >>> > >> >>>>> >>> > 2nd was a QML item that displays a model loaded from a 3ds >> file. >> >>> My >> >>>>> >>> > goal here was to move the model around using mouse drag >> events. I >> >>>>> >>> > took the lessons learned from the first example, threw in a >> >>>>> >>> > vtkInteractorStyleTrackballCamera and hoped for the best. First >> >>>>> >>> > thing I found was that I needed a specialized >> >>>>> >>> > RenderWindowInteractor, which I provided. When I realized that >> the >> >>>>> >>> > most important requirement for that class was to provide >> access to >> >>>>> >>> > timer functionality, I already got wary, as throwing around >> events >> >>>>> >>> > and doing stuff offline while on the QML rendering thread is >> >>> never a >> >>>>> >>> > good idea. My fears came true when I finished wiring everything >> >>>>> >>> > together: I was able to move the model using the mouse, but >> after >> >>> a >> >>>>> >>> > few moments things got whacky with error output written to the >> >>>>> >>> > console and finally a segemtation fault from deep inside VTK. >> >>>>> >>> > >> >>>>> >>> > I still need to investigate the second example, but would like >> to >> >>>>> >>> > synchronize with the community at this point in order to avoid >> >>>>> >>> > errors/misconceptions on my side, to seek help if possible and >> to >> >>>>> >>> > offer my contribution to the VTK code base once this becomes >> >>>>> >>> > functional. My first impression is that there are some issues >> that >> >>>>> >>> > lie on an architectural level and cannot be (elegantly) dealt >> with >> >>>>> >>> > on the QML side alone. Any comments? >> >>>>> >>> > >> >>>>> >>> > thanks, >> >>>>> >>> > Christian Sell >> >>>>> >>> > >> >>>>> >>> > _______________________________________________ >> >>>>> >>> > 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: >> >>>>> >>> > http://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: >> >>>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>>> >>> >> >>>>> >>> -- >> >>>>> >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >> >>>>> >> | (518) 881-4417 >> >>>>> >> ? >> >>>>> >> _______________________________________________ >> >>>>> >> 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: >> >>>>> >> http://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: >> > http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> From elvis.stansvik at orexplore.com Thu May 18 08:57:05 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 18 May 2017 14:57:05 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget Message-ID: I'm porting our program to the new QVTKOpenGLWidget. In one place, we're using a semi-transparent polygonal cube to show the selection of an area. We're doing volume rendering using vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal selection marker is enclosing the volume in the X/Y dimensions. See the attached linux_selection_correct.png for how this is supposed to look, and you'll understand what I mean. The light blue area is the selection marker. This has always worked fine, but after porting from QVTKWidget to QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and macOS (2013 MBP, intel iris). See the attached windows_nvidia_selection.png and macos_selection.png. The selection is visualized using vtkCubeSource -> vtkPolyDataMapper and a vtkActor configured like this: auto selectionColor = palette().color(QPalette::Highlight); m_selectionMarkerActor->SetMapper(selectionMarkerMapper); m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), selectionColor.greenF(), selectionColor.blueF()); m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); Any idea why the rendering looks so strange on Windows/nvidia and macOS/iris, respectively, when using the new widget class? We're using a recent VTK from Git master. We're doing the recommended QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); to set the default surface format before QApplication construction. In the particular QVTKOpenGLWidget used here, we modify the format with auto surfaceFormat = format(); surfaceFormat.setSamples(0); setFormat(surfaceFormat); to disable multisampling. Very grateful for any advise on how to solve this. Cheers, Elvis -------------- next part -------------- A non-text attachment was scrubbed... Name: linux_selection_correct.png Type: image/png Size: 21931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: windows_nvidia_selection.png Type: image/png Size: 19863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: macos_selection.png Type: image/png Size: 42982 bytes Desc: not available URL: From utkarsh.ayachit at kitware.com Thu May 18 09:59:12 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 18 May 2017 09:59:12 -0400 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: For now, try doing this: auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() surfaceFormat.setSamples(0); * surfaceFormat.setAlphaBufferSIze(0);* QSurfaceFormat::setDefaultFormat(surfaceFormat); Utkarsh On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > I'm porting our program to the new QVTKOpenGLWidget. > > In one place, we're using a semi-transparent polygonal cube to show > the selection of an area. We're doing volume rendering using > vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal > selection marker is enclosing the volume in the X/Y dimensions. > > See the attached linux_selection_correct.png for how this is supposed > to look, and you'll understand what I mean. The light blue area is the > selection marker. > > This has always worked fine, but after porting from QVTKWidget to > QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and > macOS (2013 MBP, intel iris). See the attached > windows_nvidia_selection.png and macos_selection.png. > > The selection is visualized using > > vtkCubeSource -> vtkPolyDataMapper > > and a vtkActor configured like this: > > auto selectionColor = palette().color(QPalette::Highlight); > > m_selectionMarkerActor->SetMapper(selectionMarkerMapper); > m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), > > selectionColor.greenF(), > > selectionColor.blueF()); > m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); > m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); > m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); > m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); > > Any idea why the rendering looks so strange on Windows/nvidia and > macOS/iris, respectively, when using the new widget class? > > We're using a recent VTK from Git master. > > We're doing the recommended > > QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); > > to set the default surface format before QApplication construction. > > In the particular QVTKOpenGLWidget used here, we modify the format with > > auto surfaceFormat = format(); > surfaceFormat.setSamples(0); > setFormat(surfaceFormat); > > to disable multisampling. > > Very grateful for any advise on how to solve this. > > Cheers, > Elvis > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu May 18 10:14:05 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 18 May 2017 16:14:05 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit : > For now, try doing this: > auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() > surfaceFormat.setSamples(0); > surfaceFormat.setAlphaBufferSIze(0); > QSurfaceFormat::setDefaultFormat(surfaceFormat); Thanks for the suggestion. I tried it out on the Mac, but it looks like it made no difference :/ Elvis > > > Utkarsh > > On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik > wrote: >> >> I'm porting our program to the new QVTKOpenGLWidget. >> >> In one place, we're using a semi-transparent polygonal cube to show >> the selection of an area. We're doing volume rendering using >> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal >> selection marker is enclosing the volume in the X/Y dimensions. >> >> See the attached linux_selection_correct.png for how this is supposed >> to look, and you'll understand what I mean. The light blue area is the >> selection marker. >> >> This has always worked fine, but after porting from QVTKWidget to >> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and >> macOS (2013 MBP, intel iris). See the attached >> windows_nvidia_selection.png and macos_selection.png. >> >> The selection is visualized using >> >> vtkCubeSource -> vtkPolyDataMapper >> >> and a vtkActor configured like this: >> >> auto selectionColor = palette().color(QPalette::Highlight); >> >> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); >> m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), >> >> selectionColor.greenF(), >> >> selectionColor.blueF()); >> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); >> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); >> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); >> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); >> >> Any idea why the rendering looks so strange on Windows/nvidia and >> macOS/iris, respectively, when using the new widget class? >> >> We're using a recent VTK from Git master. >> >> We're doing the recommended >> >> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >> >> to set the default surface format before QApplication construction. >> >> In the particular QVTKOpenGLWidget used here, we modify the format with >> >> auto surfaceFormat = format(); >> surfaceFormat.setSamples(0); >> setFormat(surfaceFormat); >> >> to disable multisampling. >> >> Very grateful for any advise on how to solve this. >> >> Cheers, >> Elvis >> >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > From utkarsh.ayachit at kitware.com Thu May 18 10:16:59 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 18 May 2017 10:16:59 -0400 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: Okay. In that case, it may be best if you can put together a small example to reproduce the issue so we can debug it here. Utkarsh On Thu, May 18, 2017 at 10:14 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit : > > For now, try doing this: > > auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() > > surfaceFormat.setSamples(0); > > surfaceFormat.setAlphaBufferSIze(0); > > QSurfaceFormat::setDefaultFormat(surfaceFormat); > > Thanks for the suggestion. I tried it out on the Mac, but it looks > like it made no difference :/ > > Elvis > > > > > > > Utkarsh > > > > On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik > > wrote: > >> > >> I'm porting our program to the new QVTKOpenGLWidget. > >> > >> In one place, we're using a semi-transparent polygonal cube to show > >> the selection of an area. We're doing volume rendering using > >> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal > >> selection marker is enclosing the volume in the X/Y dimensions. > >> > >> See the attached linux_selection_correct.png for how this is supposed > >> to look, and you'll understand what I mean. The light blue area is the > >> selection marker. > >> > >> This has always worked fine, but after porting from QVTKWidget to > >> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and > >> macOS (2013 MBP, intel iris). See the attached > >> windows_nvidia_selection.png and macos_selection.png. > >> > >> The selection is visualized using > >> > >> vtkCubeSource -> vtkPolyDataMapper > >> > >> and a vtkActor configured like this: > >> > >> auto selectionColor = palette().color(QPalette::Highlight); > >> > >> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); > >> m_selectionMarkerActor->GetProperty()->SetColor( > selectionColor.redF(), > >> > >> selectionColor.greenF(), > >> > >> selectionColor.blueF()); > >> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); > >> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); > >> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); > >> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); > >> > >> Any idea why the rendering looks so strange on Windows/nvidia and > >> macOS/iris, respectively, when using the new widget class? > >> > >> We're using a recent VTK from Git master. > >> > >> We're doing the recommended > >> > >> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget:: > defaultFormat()); > >> > >> to set the default surface format before QApplication construction. > >> > >> In the particular QVTKOpenGLWidget used here, we modify the format with > >> > >> auto surfaceFormat = format(); > >> surfaceFormat.setSamples(0); > >> setFormat(surfaceFormat); > >> > >> to disable multisampling. > >> > >> Very grateful for any advise on how to solve this. > >> > >> Cheers, > >> Elvis > >> > >> _______________________________________________ > >> 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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu May 18 10:47:36 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 18 May 2017 16:47:36 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-18 16:16 GMT+02:00 Utkarsh Ayachit : > Okay. In that case, it may be best if you can put together a small example > to reproduce the issue so we can debug it here. Yep, will do. Elvis > > Utkarsh > > On Thu, May 18, 2017 at 10:14 AM, Elvis Stansvik > wrote: >> >> 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit : >> > For now, try doing this: >> > auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() >> > surfaceFormat.setSamples(0); >> > surfaceFormat.setAlphaBufferSIze(0); >> > QSurfaceFormat::setDefaultFormat(surfaceFormat); >> >> Thanks for the suggestion. I tried it out on the Mac, but it looks >> like it made no difference :/ >> >> Elvis >> >> > >> > >> > Utkarsh >> > >> > On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik >> > wrote: >> >> >> >> I'm porting our program to the new QVTKOpenGLWidget. >> >> >> >> In one place, we're using a semi-transparent polygonal cube to show >> >> the selection of an area. We're doing volume rendering using >> >> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal >> >> selection marker is enclosing the volume in the X/Y dimensions. >> >> >> >> See the attached linux_selection_correct.png for how this is supposed >> >> to look, and you'll understand what I mean. The light blue area is the >> >> selection marker. >> >> >> >> This has always worked fine, but after porting from QVTKWidget to >> >> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and >> >> macOS (2013 MBP, intel iris). See the attached >> >> windows_nvidia_selection.png and macos_selection.png. >> >> >> >> The selection is visualized using >> >> >> >> vtkCubeSource -> vtkPolyDataMapper >> >> >> >> and a vtkActor configured like this: >> >> >> >> auto selectionColor = palette().color(QPalette::Highlight); >> >> >> >> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); >> >> >> >> m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), >> >> >> >> selectionColor.greenF(), >> >> >> >> selectionColor.blueF()); >> >> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); >> >> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); >> >> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); >> >> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); >> >> >> >> Any idea why the rendering looks so strange on Windows/nvidia and >> >> macOS/iris, respectively, when using the new widget class? >> >> >> >> We're using a recent VTK from Git master. >> >> >> >> We're doing the recommended >> >> >> >> >> >> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >> >> >> >> to set the default surface format before QApplication construction. >> >> >> >> In the particular QVTKOpenGLWidget used here, we modify the format with >> >> >> >> auto surfaceFormat = format(); >> >> surfaceFormat.setSamples(0); >> >> setFormat(surfaceFormat); >> >> >> >> to disable multisampling. >> >> >> >> Very grateful for any advise on how to solve this. >> >> >> >> Cheers, >> >> Elvis >> >> >> >> _______________________________________________ >> >> 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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> > > > From marcus.hanwell at kitware.com Thu May 18 11:46:40 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 18 May 2017 11:46:40 -0400 Subject: [vtk-developers] VTK, Python 3 and the six module - install error on six.pyc In-Reply-To: <20170517150431.GB25196@megas.kitware.com> References: <20170516152418.GA11273@megas.kitware.com> <20170516175809.GB32636@rotor> <20170517150431.GB25196@megas.kitware.com> Message-ID: On Wed, May 17, 2017 at 11:04 AM, Ben Boeckel wrote: > On Tue, May 16, 2017 at 22:15:28 -0400, Aron Helser wrote: >> I had to add a file glob to get the .pyc files, since they now include the >> interpreter and python version in the filename. > > But we have the version of Python we're using, so we could at least > factor that bit out of the glob. I don't think we really support > anything other than cpython either? > I am not sure I see the benefit of narrowing it down further, but I would be happy to test a merge request out once ready. We can't build Tomviz with ParaView/VTK as it stands right now, so I am eager to see this regression resolved for installation. Thanks, Marcus From bill.lorensen at gmail.com Thu May 18 14:13:12 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 18 May 2017 14:13:12 -0400 Subject: [vtk-developers] UPDATE: Static pages for VTKExamples Message-ID: Looks like using github pages is a good solution to host the new VTK Examples (formerly VTK Wiki Examples). I have decommissioned the gitlab site (https://gitlab.kitware.com/lorensen/VTKExamples) I'm still cleaning up some documentation. Please take a look at: https://lorensen.github.io/VTKExamples If you want to add an example or fix documentation please look at this page: https://lorensen.github.io/VTKExamples/site/Instructions/ForDevelopers/ Bill -- Unpaid intern in BillsBasement at noware dot com From elvis.stansvik at orexplore.com Mon May 22 05:31:36 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 22 May 2017 11:31:36 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-18 16:47 GMT+02:00 Elvis Stansvik : > 2017-05-18 16:16 GMT+02:00 Utkarsh Ayachit : >> Okay. In that case, it may be best if you can put together a small example >> to reproduce the issue so we can debug it here. > > Yep, will do. I've not been able to reproduce exactly the issue I was seeing with a small test case, and now I've annoyingly enough lost access to the Windows machine I was testing on (may regain access to it later). However, the following test case shows an issue (even on my Linux main dev machine) which I suspect may be related. When running with a "plain" vtkRenderWindow, the rendering looks normal, but when running with QVTKOpenGLWidget, I can see through to the window behind the application. See the attached screenshot showing what I mean. Run the test case with just "./TestCase" for "plain" VTK rendering, and with "./TestCase blah" to use QVTKOpenGLWidget. You'll have to rotate the camera a little for the problem to appear. Any idea why this is happening? It looks similar to the issue I was having on macOS / Windows (nvidia) in that the windows behind the application become visible, but apart from that, the color of the poly data is correct (as opposed to the issue I was having on macOS / Windows (nvidia)). Elvis main.cpp: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); defaultFormat.setSamples(0); QSurfaceFormat::setDefaultFormat(defaultFormat); QApplication app(argc, argv); // Set up volume rendering vtkNew colorFunction; colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); vtkNew opacityFunction; opacityFunction->AddPoint(0.0, 0.0); opacityFunction->AddPoint(1.0, 1.0); vtkNew imageData; imageData->SetExtent(0, 200, 0, 200, 0, 200); imageData->AllocateScalars(VTK_FLOAT, 1); std::fill_n(static_cast(imageData->GetScalarPointer()), 8000000, 0.01); vtkNew volumeMapper; volumeMapper->SetInputData(imageData.Get()); vtkNew volumeProperty; volumeProperty->SetScalarOpacity(opacityFunction.Get()); volumeProperty->SetColor(colorFunction.Get()); volumeProperty->ShadeOff(); vtkNew volume; volume->SetMapper(volumeMapper.Get()); volume->SetProperty(volumeProperty.Get()); // Set up poly cube rendering vtkNew cubeSource; cubeSource->SetBounds(-20, 220, 100, 150, -20, 220); vtkNew cubeMapper; cubeMapper->SetInputConnection(cubeSource->GetOutputPort()); vtkNew cubeActor; cubeActor->SetMapper(cubeMapper.Get()); cubeActor->GetProperty()->SetColor(0.0, 0.0, 1.0); cubeActor->GetProperty()->SetOpacity(0.1); cubeActor->GetProperty()->SetAmbient(1.0); cubeActor->GetProperty()->SetDiffuse(0.0); cubeActor->GetProperty()->SetSpecular(0.0); // Set up renderer vtkNew renderer; renderer->AddActor(cubeActor.Get()); renderer->AddVolume(volume.Get()); renderer->SetBackground(1.0, 1.0, 1.0); if (argc > 1) { // Show with QVTKOpenGLWidget vtkNew window; window->AddRenderer(renderer.Get()); auto widget = new QVTKOpenGLWidget(); widget->SetRenderWindow(window.Get()); widget->show(); return app.exec(); } else { // Show with plain VTK vtkNew window; window->AddRenderer(renderer.Get()); vtkNew interactor; interactor->SetRenderWindow(window.Get()); interactor->Start(); return 0; } } CMakeLists.txt: cmake_minimum_required(VERSION 3.1) project(TestCase) find_package(VTK 7.1 COMPONENTS vtkCommonCore vtkCommonDataModel vtkCommonExecutionModel vtkCommonMath vtkFiltersSources vtkGUISupportQt vtkInteractionStyle vtkRenderingCore vtkRenderingOpenGL2 vtkRenderingVolume vtkRenderingVolumeOpenGL2 REQUIRED ) find_package(Qt5Widgets REQUIRED) add_executable(TestCase main.cpp) target_link_libraries(TestCase PUBLIC vtkCommonCore vtkCommonDataModel vtkCommonExecutionModel vtkCommonMath vtkFiltersSources vtkGUISupportQt vtkInteractionStyle vtkRenderingCore vtkRenderingOpenGL2 vtkRenderingVolume vtkRenderingVolumeOpenGL2 Qt5::Widgets ) target_include_directories(TestCase PUBLIC ${VTK_INCLUDE_DIRS} ) target_compile_definitions(TestCase PUBLIC ${VTK_DEFINITIONS} ) set_target_properties(TestCase PROPERTIES CXX_STANDARD 14 CXX_STANDARD_REQUIRED ON ) > > Elvis > >> >> Utkarsh >> >> On Thu, May 18, 2017 at 10:14 AM, Elvis Stansvik >> wrote: >>> >>> 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit : >>> > For now, try doing this: >>> > auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() >>> > surfaceFormat.setSamples(0); >>> > surfaceFormat.setAlphaBufferSIze(0); >>> > QSurfaceFormat::setDefaultFormat(surfaceFormat); >>> >>> Thanks for the suggestion. I tried it out on the Mac, but it looks >>> like it made no difference :/ >>> >>> Elvis >>> >>> > >>> > >>> > Utkarsh >>> > >>> > On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik >>> > wrote: >>> >> >>> >> I'm porting our program to the new QVTKOpenGLWidget. >>> >> >>> >> In one place, we're using a semi-transparent polygonal cube to show >>> >> the selection of an area. We're doing volume rendering using >>> >> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal >>> >> selection marker is enclosing the volume in the X/Y dimensions. >>> >> >>> >> See the attached linux_selection_correct.png for how this is supposed >>> >> to look, and you'll understand what I mean. The light blue area is the >>> >> selection marker. >>> >> >>> >> This has always worked fine, but after porting from QVTKWidget to >>> >> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and >>> >> macOS (2013 MBP, intel iris). See the attached >>> >> windows_nvidia_selection.png and macos_selection.png. >>> >> >>> >> The selection is visualized using >>> >> >>> >> vtkCubeSource -> vtkPolyDataMapper >>> >> >>> >> and a vtkActor configured like this: >>> >> >>> >> auto selectionColor = palette().color(QPalette::Highlight); >>> >> >>> >> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); >>> >> >>> >> m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), >>> >> >>> >> selectionColor.greenF(), >>> >> >>> >> selectionColor.blueF()); >>> >> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); >>> >> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); >>> >> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); >>> >> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); >>> >> >>> >> Any idea why the rendering looks so strange on Windows/nvidia and >>> >> macOS/iris, respectively, when using the new widget class? >>> >> >>> >> We're using a recent VTK from Git master. >>> >> >>> >> We're doing the recommended >>> >> >>> >> >>> >> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >>> >> >>> >> to set the default surface format before QApplication construction. >>> >> >>> >> In the particular QVTKOpenGLWidget used here, we modify the format with >>> >> >>> >> auto surfaceFormat = format(); >>> >> surfaceFormat.setSamples(0); >>> >> setFormat(surfaceFormat); >>> >> >>> >> to disable multisampling. >>> >> >>> >> Very grateful for any advise on how to solve this. >>> >> >>> >> Cheers, >>> >> Elvis >>> >> >>> >> _______________________________________________ >>> >> 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: >>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>> >> >>> > >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: testcase-plain.png Type: image/png Size: 27870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testcase-qvtkopenglwidget.png Type: image/png Size: 28581 bytes Desc: not available URL: From elvis.stansvik at orexplore.com Mon May 22 07:39:26 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 22 May 2017 13:39:26 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-18 16:14 GMT+02:00 Elvis Stansvik : > 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit : >> For now, try doing this: >> auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() >> surfaceFormat.setSamples(0); >> surfaceFormat.setAlphaBufferSIze(0); >> QSurfaceFormat::setDefaultFormat(surfaceFormat); > > Thanks for the suggestion. I tried it out on the Mac, but it looks > like it made no difference :/ I'm really sorry, this must have been a PEBKAC from me, because now that I tried it again, it actually does solve the problem (!). I must have made some mistake first time I tried it. Rendering on the Mac is now correct. I will have to wait until I get access to the Windows/nVidia machine again to confirm that it solves it there too, but I'm hopeful that it does. (Note: I sent off a couple of e-mails earlier today with some screenshots from the Mac, that ended up in the moderation queue due to the screenshots being > 1000 KB). Many thanks for this tip Utkarsh. Elvis > > Elvis > >> >> >> Utkarsh >> >> On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik >> wrote: >>> >>> I'm porting our program to the new QVTKOpenGLWidget. >>> >>> In one place, we're using a semi-transparent polygonal cube to show >>> the selection of an area. We're doing volume rendering using >>> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal >>> selection marker is enclosing the volume in the X/Y dimensions. >>> >>> See the attached linux_selection_correct.png for how this is supposed >>> to look, and you'll understand what I mean. The light blue area is the >>> selection marker. >>> >>> This has always worked fine, but after porting from QVTKWidget to >>> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and >>> macOS (2013 MBP, intel iris). See the attached >>> windows_nvidia_selection.png and macos_selection.png. >>> >>> The selection is visualized using >>> >>> vtkCubeSource -> vtkPolyDataMapper >>> >>> and a vtkActor configured like this: >>> >>> auto selectionColor = palette().color(QPalette::Highlight); >>> >>> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); >>> m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), >>> >>> selectionColor.greenF(), >>> >>> selectionColor.blueF()); >>> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); >>> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); >>> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); >>> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); >>> >>> Any idea why the rendering looks so strange on Windows/nvidia and >>> macOS/iris, respectively, when using the new widget class? >>> >>> We're using a recent VTK from Git master. >>> >>> We're doing the recommended >>> >>> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >>> >>> to set the default surface format before QApplication construction. >>> >>> In the particular QVTKOpenGLWidget used here, we modify the format with >>> >>> auto surfaceFormat = format(); >>> surfaceFormat.setSamples(0); >>> setFormat(surfaceFormat); >>> >>> to disable multisampling. >>> >>> Very grateful for any advise on how to solve this. >>> >>> Cheers, >>> Elvis >>> >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >> From elvis.stansvik at orexplore.com Mon May 22 08:47:56 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 22 May 2017 14:47:56 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-22 13:39 GMT+02:00 Elvis Stansvik : > 2017-05-18 16:14 GMT+02:00 Elvis Stansvik : >> 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit : >>> For now, try doing this: >>> auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() >>> surfaceFormat.setSamples(0); >>> surfaceFormat.setAlphaBufferSIze(0); >>> QSurfaceFormat::setDefaultFormat(surfaceFormat); >> >> Thanks for the suggestion. I tried it out on the Mac, but it looks >> like it made no difference :/ > > I'm really sorry, this must have been a PEBKAC from me, because now > that I tried it again, it actually does solve the problem (!). I must > have made some mistake first time I tried it. > > Rendering on the Mac is now correct. I will have to wait until I get > access to the Windows/nVidia machine again to confirm that it solves > it there too, but I'm hopeful that it does. > > (Note: I sent off a couple of e-mails earlier today with some > screenshots from the Mac, that ended up in the moderation queue due to > the screenshots being > 1000 KB). > > Many thanks for this tip Utkarsh. As a side note: I found this in the source code for ITK-SNAP [1]: // Starting with Qt 5.6, the OpenGL implementation uses OpenGL 2.0 // In this version of OpenGL, transparency is handled differently and // looks wrong. QSurfaceFormat gl_fmt; gl_fmt.setMajorVersion(argdata.opengl_major); gl_fmt.setMinorVersion(argdata.opengl_minor); /* gl_fmt.setSwapBehavior(QSurfaceFormat::DoubleBuffer); gl_fmt.setRedBufferSize(1); gl_fmt.setGreenBufferSize(1); gl_fmt.setBlueBufferSize(1); gl_fmt.setDepthBufferSize(1); gl_fmt.setStencilBufferSize(0); gl_fmt.setAlphaBufferSize(0); */ I'm guessing the comment is referring to the same issue I saw. Note the commented setAlphaBufferSize(0). So is setting the GL version explicitly like this the proper workaround? Elvis [1] https://github.com/pyushkevich/itksnap/blob/master/GUI/Qt/main.cxx#L572-L574 > > Elvis > >> >> Elvis >> >>> >>> >>> Utkarsh >>> >>> On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik >>> wrote: >>>> >>>> I'm porting our program to the new QVTKOpenGLWidget. >>>> >>>> In one place, we're using a semi-transparent polygonal cube to show >>>> the selection of an area. We're doing volume rendering using >>>> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal >>>> selection marker is enclosing the volume in the X/Y dimensions. >>>> >>>> See the attached linux_selection_correct.png for how this is supposed >>>> to look, and you'll understand what I mean. The light blue area is the >>>> selection marker. >>>> >>>> This has always worked fine, but after porting from QVTKWidget to >>>> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and >>>> macOS (2013 MBP, intel iris). See the attached >>>> windows_nvidia_selection.png and macos_selection.png. >>>> >>>> The selection is visualized using >>>> >>>> vtkCubeSource -> vtkPolyDataMapper >>>> >>>> and a vtkActor configured like this: >>>> >>>> auto selectionColor = palette().color(QPalette::Highlight); >>>> >>>> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); >>>> m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), >>>> >>>> selectionColor.greenF(), >>>> >>>> selectionColor.blueF()); >>>> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); >>>> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); >>>> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); >>>> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); >>>> >>>> Any idea why the rendering looks so strange on Windows/nvidia and >>>> macOS/iris, respectively, when using the new widget class? >>>> >>>> We're using a recent VTK from Git master. >>>> >>>> We're doing the recommended >>>> >>>> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >>>> >>>> to set the default surface format before QApplication construction. >>>> >>>> In the particular QVTKOpenGLWidget used here, we modify the format with >>>> >>>> auto surfaceFormat = format(); >>>> surfaceFormat.setSamples(0); >>>> setFormat(surfaceFormat); >>>> >>>> to disable multisampling. >>>> >>>> Very grateful for any advise on how to solve this. >>>> >>>> Cheers, >>>> Elvis >>>> >>>> _______________________________________________ >>>> 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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>> From sankhesh.jhaveri at kitware.com Mon May 22 09:03:01 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Mon, 22 May 2017 13:03:01 +0000 Subject: [vtk-developers] Announce: vtk 8.0.0.rc1 ready for testing Message-ID: The VTK maintenance team is happy to announce that VTK 8.0 has entered the release candidate stage. You can find the source, data and documentation tarballs here: http://www.vtk.org/download/#candidate Take a look at the VTK wiki for a complete list of API changes in v8.0.0 over the previous version. Please try this version of VTK and report any issues to the list or the bug tracker so that we can try to address them before the VTK 8.0.0 final. Kindly set the 8.0 milestone on the issues and merge requests to ensure that they are tracked during the remainder of the release process. The official release notes will be available when VTK final is released in the next few weeks. In the meantime, here is a preview of the significant differences over VTK 7.1.0: - VTK now allows use of some C++11 features and compiler optimizations. Take a look at the VTK Software Process document to see all the VTK C++11 features. This also means, beginning version 8.0.0, VTK requires a C++11 capable compiler to compile. - VTK-m , a toolkit providing specialized algorithms and data processing features for modern multi-threaded processors and HPC systems is now a part of VTK. And many other improvements and bug fixes across the code-base. We hope you enjoy this release of VTK! As always, contact Kitware and the mailing lists for assistance. Thanks, VTK Maintenance Team ? -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From domibel at debian.org Mon May 22 10:05:18 2017 From: domibel at debian.org (Dominique Belhachemi) Date: Mon, 22 May 2017 10:05:18 -0400 Subject: [vtk-developers] Announce: vtk 8.0.0.rc1 ready for testing In-Reply-To: References: Message-ID: On Mon, May 22, 2017 at 9:03 AM, Sankhesh Jhaveri < sankhesh.jhaveri at kitware.com> wrote: > > - > > VTK-m , a toolkit providing specialized algorithms > and data processing features for modern multi-threaded processors and HPC > systems is now a part of VTK. > > What does this mean? Are you merging the repositories? -Dominique -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon May 22 10:16:29 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 22 May 2017 10:16:29 -0400 Subject: [vtk-developers] Announce: vtk 8.0.0.rc1 ready for testing In-Reply-To: References: Message-ID: For the 8.0 release, filters that use VTK-m are isolated to the Accelerators folder, and require an external VTK-m. On Mon, May 22, 2017 at 10:05 AM, Dominique Belhachemi wrote: > On Mon, May 22, 2017 at 9:03 AM, Sankhesh Jhaveri < > sankhesh.jhaveri at kitware.com> wrote: > > >> >> - >> >> VTK-m , a toolkit providing specialized algorithms >> and data processing features for modern multi-threaded processors and HPC >> systems is now a part of VTK. >> >> > What does this mean? Are you merging the repositories? > > -Dominique > > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon May 22 10:25:49 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 22 May 2017 10:25:49 -0400 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: Elvis, I am not sure what the ITK-SNAP thing is. No, I don't think setting required opengl version is the way to go. If I am following all your emails correctly, then the latest state is that my suggestion works on mac and you're going to confirm on Windows next. If problems persist, it would be immensely helpful if you have an example that does the "highlight" e.g. modify TestQVTKOpenGLWidget.cxx[1] to add an actor for the "thing". That way I have a easy test case to reproduce your issue and then debug it. Utkarsh [1] https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/Testing/Cxx/TestQVTKOpenGLWidget.cxx On Mon, May 22, 2017 at 8:47 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-22 13:39 GMT+02:00 Elvis Stansvik : > > 2017-05-18 16:14 GMT+02:00 Elvis Stansvik > : > >> 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit >: > >>> For now, try doing this: > >>> auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() > >>> surfaceFormat.setSamples(0); > >>> surfaceFormat.setAlphaBufferSIze(0); > >>> QSurfaceFormat::setDefaultFormat(surfaceFormat); > >> > >> Thanks for the suggestion. I tried it out on the Mac, but it looks > >> like it made no difference :/ > > > > I'm really sorry, this must have been a PEBKAC from me, because now > > that I tried it again, it actually does solve the problem (!). I must > > have made some mistake first time I tried it. > > > > Rendering on the Mac is now correct. I will have to wait until I get > > access to the Windows/nVidia machine again to confirm that it solves > > it there too, but I'm hopeful that it does. > > > > (Note: I sent off a couple of e-mails earlier today with some > > screenshots from the Mac, that ended up in the moderation queue due to > > the screenshots being > 1000 KB). > > > > Many thanks for this tip Utkarsh. > > As a side note: I found this in the source code for ITK-SNAP [1]: > > // Starting with Qt 5.6, the OpenGL implementation uses OpenGL 2.0 > // In this version of OpenGL, transparency is handled differently and > // looks wrong. > QSurfaceFormat gl_fmt; > gl_fmt.setMajorVersion(argdata.opengl_major); > gl_fmt.setMinorVersion(argdata.opengl_minor); > /* > gl_fmt.setSwapBehavior(QSurfaceFormat::DoubleBuffer); > gl_fmt.setRedBufferSize(1); > gl_fmt.setGreenBufferSize(1); > gl_fmt.setBlueBufferSize(1); > gl_fmt.setDepthBufferSize(1); > gl_fmt.setStencilBufferSize(0); > gl_fmt.setAlphaBufferSize(0); > */ > > I'm guessing the comment is referring to the same issue I saw. Note > the commented setAlphaBufferSize(0). So is setting the GL version > explicitly like this the proper workaround? > > Elvis > > [1] https://github.com/pyushkevich/itksnap/blob/ > master/GUI/Qt/main.cxx#L572-L574 > > > > > Elvis > > > >> > >> Elvis > >> > >>> > >>> > >>> Utkarsh > >>> > >>> On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik > >>> wrote: > >>>> > >>>> I'm porting our program to the new QVTKOpenGLWidget. > >>>> > >>>> In one place, we're using a semi-transparent polygonal cube to show > >>>> the selection of an area. We're doing volume rendering using > >>>> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal > >>>> selection marker is enclosing the volume in the X/Y dimensions. > >>>> > >>>> See the attached linux_selection_correct.png for how this is supposed > >>>> to look, and you'll understand what I mean. The light blue area is the > >>>> selection marker. > >>>> > >>>> This has always worked fine, but after porting from QVTKWidget to > >>>> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and > >>>> macOS (2013 MBP, intel iris). See the attached > >>>> windows_nvidia_selection.png and macos_selection.png. > >>>> > >>>> The selection is visualized using > >>>> > >>>> vtkCubeSource -> vtkPolyDataMapper > >>>> > >>>> and a vtkActor configured like this: > >>>> > >>>> auto selectionColor = palette().color(QPalette::Highlight); > >>>> > >>>> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); > >>>> m_selectionMarkerActor->GetProperty()->SetColor( > selectionColor.redF(), > >>>> > >>>> selectionColor.greenF(), > >>>> > >>>> selectionColor.blueF()); > >>>> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); > >>>> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); > >>>> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); > >>>> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); > >>>> > >>>> Any idea why the rendering looks so strange on Windows/nvidia and > >>>> macOS/iris, respectively, when using the new widget class? > >>>> > >>>> We're using a recent VTK from Git master. > >>>> > >>>> We're doing the recommended > >>>> > >>>> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget:: > defaultFormat()); > >>>> > >>>> to set the default surface format before QApplication construction. > >>>> > >>>> In the particular QVTKOpenGLWidget used here, we modify the format > with > >>>> > >>>> auto surfaceFormat = format(); > >>>> surfaceFormat.setSamples(0); > >>>> setFormat(surfaceFormat); > >>>> > >>>> to disable multisampling. > >>>> > >>>> Very grateful for any advise on how to solve this. > >>>> > >>>> Cheers, > >>>> Elvis > >>>> > >>>> _______________________________________________ > >>>> 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: > >>>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>> > >>>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Mon May 22 10:31:21 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 22 May 2017 16:31:21 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-22 16:25 GMT+02:00 Utkarsh Ayachit : > Elvis, > > I am not sure what the ITK-SNAP thing is. No, I don't think setting required > opengl version is the way to go. > > If I am following all your emails correctly, then the latest state is that > my suggestion works on mac and you're going to confirm on Windows next. Yes, that's correct. Sorry that my e-mails got a bit disorganized! > > If problems persist, it would be immensely helpful if you have an example > that does the "highlight" e.g. modify TestQVTKOpenGLWidget.cxx[1] to add an > actor for the "thing". That way I have a easy test case to reproduce your > issue and then debug it. The test case I sent was just that. The vtkCubeSource/vtkPolyDataMapper in the test case was meant to mimic the highlight/selection I have in our real application. Right now I'm debugging some rendering problems on Windows 7 (intel) that seems to have come from applying your setAlphaBufferSize(0) solution (not sure yet). As soon as I get access to the Windows 8.1 machine with nVidia graphics again, I'll try to confirm that the workaround works there (like it did on macOS). Elvis > > Utkarsh > > [1] > https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/Testing/Cxx/TestQVTKOpenGLWidget.cxx > > > On Mon, May 22, 2017 at 8:47 AM, Elvis Stansvik > wrote: >> >> 2017-05-22 13:39 GMT+02:00 Elvis Stansvik : >> > 2017-05-18 16:14 GMT+02:00 Elvis Stansvik >> > : >> >> 2017-05-18 15:59 GMT+02:00 Utkarsh Ayachit >> >> : >> >>> For now, try doing this: >> >>> auto surfaceFormat = QVTKOpenGLWidget::defaultFormat() >> >>> surfaceFormat.setSamples(0); >> >>> surfaceFormat.setAlphaBufferSIze(0); >> >>> QSurfaceFormat::setDefaultFormat(surfaceFormat); >> >> >> >> Thanks for the suggestion. I tried it out on the Mac, but it looks >> >> like it made no difference :/ >> > >> > I'm really sorry, this must have been a PEBKAC from me, because now >> > that I tried it again, it actually does solve the problem (!). I must >> > have made some mistake first time I tried it. >> > >> > Rendering on the Mac is now correct. I will have to wait until I get >> > access to the Windows/nVidia machine again to confirm that it solves >> > it there too, but I'm hopeful that it does. >> > >> > (Note: I sent off a couple of e-mails earlier today with some >> > screenshots from the Mac, that ended up in the moderation queue due to >> > the screenshots being > 1000 KB). >> > >> > Many thanks for this tip Utkarsh. >> >> As a side note: I found this in the source code for ITK-SNAP [1]: >> >> // Starting with Qt 5.6, the OpenGL implementation uses OpenGL 2.0 >> // In this version of OpenGL, transparency is handled differently and >> // looks wrong. >> QSurfaceFormat gl_fmt; >> gl_fmt.setMajorVersion(argdata.opengl_major); >> gl_fmt.setMinorVersion(argdata.opengl_minor); >> /* >> gl_fmt.setSwapBehavior(QSurfaceFormat::DoubleBuffer); >> gl_fmt.setRedBufferSize(1); >> gl_fmt.setGreenBufferSize(1); >> gl_fmt.setBlueBufferSize(1); >> gl_fmt.setDepthBufferSize(1); >> gl_fmt.setStencilBufferSize(0); >> gl_fmt.setAlphaBufferSize(0); >> */ >> >> I'm guessing the comment is referring to the same issue I saw. Note >> the commented setAlphaBufferSize(0). So is setting the GL version >> explicitly like this the proper workaround? >> >> Elvis >> >> [1] >> https://github.com/pyushkevich/itksnap/blob/master/GUI/Qt/main.cxx#L572-L574 >> >> > >> > Elvis >> > >> >> >> >> Elvis >> >> >> >>> >> >>> >> >>> Utkarsh >> >>> >> >>> On Thu, May 18, 2017 at 8:57 AM, Elvis Stansvik >> >>> wrote: >> >>>> >> >>>> I'm porting our program to the new QVTKOpenGLWidget. >> >>>> >> >>>> In one place, we're using a semi-transparent polygonal cube to show >> >>>> the selection of an area. We're doing volume rendering using >> >>>> vtkGPUVolumeRayCastMapper in the same renderer, and the polygonal >> >>>> selection marker is enclosing the volume in the X/Y dimensions. >> >>>> >> >>>> See the attached linux_selection_correct.png for how this is supposed >> >>>> to look, and you'll understand what I mean. The light blue area is >> >>>> the >> >>>> selection marker. >> >>>> >> >>>> This has always worked fine, but after porting from QVTKWidget to >> >>>> QVTKOpenGLWidget, the rendering looks strange on Windows (nvidia) and >> >>>> macOS (2013 MBP, intel iris). See the attached >> >>>> windows_nvidia_selection.png and macos_selection.png. >> >>>> >> >>>> The selection is visualized using >> >>>> >> >>>> vtkCubeSource -> vtkPolyDataMapper >> >>>> >> >>>> and a vtkActor configured like this: >> >>>> >> >>>> auto selectionColor = palette().color(QPalette::Highlight); >> >>>> >> >>>> m_selectionMarkerActor->SetMapper(selectionMarkerMapper); >> >>>> >> >>>> m_selectionMarkerActor->GetProperty()->SetColor(selectionColor.redF(), >> >>>> >> >>>> selectionColor.greenF(), >> >>>> >> >>>> selectionColor.blueF()); >> >>>> m_selectionMarkerActor->GetProperty()->SetOpacity(0.1); >> >>>> m_selectionMarkerActor->GetProperty()->SetAmbient(1.0); >> >>>> m_selectionMarkerActor->GetProperty()->SetDiffuse(0.0); >> >>>> m_selectionMarkerActor->GetProperty()->SetSpecular(0.0); >> >>>> >> >>>> Any idea why the rendering looks so strange on Windows/nvidia and >> >>>> macOS/iris, respectively, when using the new widget class? >> >>>> >> >>>> We're using a recent VTK from Git master. >> >>>> >> >>>> We're doing the recommended >> >>>> >> >>>> >> >>>> QSurfaceFormat::setDefaultFormat(QVTKOpenGLWidget::defaultFormat()); >> >>>> >> >>>> to set the default surface format before QApplication construction. >> >>>> >> >>>> In the particular QVTKOpenGLWidget used here, we modify the format >> >>>> with >> >>>> >> >>>> auto surfaceFormat = format(); >> >>>> surfaceFormat.setSamples(0); >> >>>> setFormat(surfaceFormat); >> >>>> >> >>>> to disable multisampling. >> >>>> >> >>>> Very grateful for any advise on how to solve this. >> >>>> >> >>>> Cheers, >> >>>> Elvis >> >>>> >> >>>> _______________________________________________ >> >>>> 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: >> >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>> >> >>>> >> >>> > > From utkarsh.ayachit at kitware.com Mon May 22 10:43:12 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 22 May 2017 10:43:12 -0400 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: > > The test case I sent was just that. > Sorry, it got lost in my inbox. found it :). Attached is another patch. This tries a different approach to addressing the alpha issue. Leaving the QSurfaceFormat unchanged, can you try the attached patch and tell me how it goes? It's a patch for VTK. Thanks, Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.patch Type: text/x-patch Size: 2081 bytes Desc: not available URL: From elvis.stansvik at orexplore.com Mon May 22 10:56:22 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 22 May 2017 16:56:22 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-22 16:43 GMT+02:00 Utkarsh Ayachit : >> The test case I sent was just that. > > > Sorry, it got lost in my inbox. found it :). > > Attached is another patch. This tries a different approach to addressing the > alpha issue. Leaving the QSurfaceFormat unchanged, can you try the attached > patch and tell me how it goes? It's a patch for VTK. Ah, thanks. I'll give it a go tomorrow. I'm just about to leave the office. (Just to be clear: I'm not 100% sure that the setAlphaBufferSize(0) thing is what is causing me trouble on Win 7 at the moment, since I've made other changes as well. The problem I'm having on Win 7 now is that our volume rendering is not showing up, but it may be caused by other things.) Elvis > > Thanks, > Utkarsh From robert.maynard at kitware.com Mon May 22 11:36:44 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 22 May 2017 11:36:44 -0400 Subject: [vtk-developers] VTK now allows C++11 Message-ID: Since the start of 2017 we have incrementally updated VTK to require a C++11 compiler. Now with the feedback completed on what C++11 features VTK should allow, I am happy to announce that a subset of C++11 can now be used in VTK. If you haven't been following the previous announcements, we have updated the VTK Software Process document to explicitly state what C++11 features VTK will allow (read at https://goo.gl/kSr28x). -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue May 23 05:10:54 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 23 May 2017 11:10:54 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-23 11:04 GMT+02:00 Elvis Stansvik : > Hi all, > > In porting to QVTKOpenGLWidget, I can't get volumes rendered using > vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD > 4600). They show up fine on Linux. They also show up fine on Windows 7 > if using a plain VTK render window. I've tried turning off > multisampling with setSamples(0) on the default QSurfaceFormat. > > The below test case illustrates the issue. See the attached > screenshots from running "TestCase" (left) and "TestCase 1" (right). > The former uses a plain render window while the latter uses the new > QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain > VTK rendering works fine, but the QVTKOpenGLWidget one is not showing > the volume. > > Versions used: > > Kubuntu Linux 16.04 > VTK 8.0.0.rc1, OpenGL2 > Qt 5.5.1 > > Windows 7 > VTK 8.0.0.rc1, OpenGL2 > Qt 5.6.2 I forgot to say: On the Windows 7 machine, it's an Intel HD4600, on the Linux machine it's an Intel HD4400. Elvis > > Any ideas what the problem might be? > > I can provide a standalone .zip distribution of my build of the test > case if you want. > > Note that this issue is orthogonal to the alpha issue I reported and > got solved in my other thread. > > Many thanks in advance, > Elvis > > > main.cpp: > > #include > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #include > > #include > > int main(int argc, char *argv[]) > { > auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); > defaultFormat.setSamples(0); > QSurfaceFormat::setDefaultFormat(defaultFormat); > > QApplication app(argc, argv); > > // Set up volume rendering > vtkNew colorFunction; > colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > > vtkNew opacityFunction; > opacityFunction->AddPoint(0.0, 0.0); > opacityFunction->AddPoint(1.0, 1.0); > > vtkNew imageData; > imageData->SetExtent(0, 200, 0, 200, 0, 200); > imageData->AllocateScalars(VTK_FLOAT, 1); > std::fill_n(static_cast(imageData->GetScalarPointer()), > 8000000, 0.01); > > vtkNew volumeMapper; > volumeMapper->SetInputData(imageData.Get()); > > vtkNew volumeProperty; > volumeProperty->SetScalarOpacity(opacityFunction.Get()); > volumeProperty->SetColor(colorFunction.Get()); > volumeProperty->ShadeOff(); > > vtkNew volume; > volume->SetMapper(volumeMapper.Get()); > volume->SetProperty(volumeProperty.Get()); > > vtkNew renderer; > renderer->AddVolume(volume.Get()); > renderer->SetBackground(1.0, 1.0, 1.0); > > if (argc > 1) { > // Render with QVTKOpenGLWidget > vtkNew window; > window->AddRenderer(renderer.Get()); > > auto widget = new QVTKOpenGLWidget(); > widget->SetRenderWindow(window.Get()); > widget->show(); > > return app.exec(); > } else { > // Render with "plain" render window / interactor > vtkNew window; > window->AddRenderer(renderer.Get()); > > vtkNew interactor; > interactor->SetRenderWindow(window.Get()); > interactor->Start(); > > return 0; > } > } > > > CMakeLists.txt: > > cmake_minimum_required(VERSION 3.1) > > project(TestCase) > > find_package(VTK 8.0 COMPONENTS > vtkCommonCore > vtkCommonDataModel > vtkCommonExecutionModel > vtkCommonMath > vtkFiltersSources > vtkGUISupportQt > vtkInteractionStyle > vtkRenderingCore > vtkRenderingOpenGL2 > vtkRenderingVolume > vtkRenderingVolumeOpenGL2 > REQUIRED > ) > > find_package(Qt5Widgets REQUIRED) > > add_executable(TestCase main.cpp) > > target_link_libraries(TestCase PUBLIC > vtkCommonCore > vtkCommonDataModel > vtkCommonExecutionModel > vtkCommonMath > vtkFiltersSources > vtkGUISupportQt > vtkInteractionStyle > vtkRenderingCore > vtkRenderingOpenGL2 > vtkRenderingVolume > vtkRenderingVolumeOpenGL2 > Qt5::Widgets > ) > > target_include_directories(TestCase PUBLIC > ${VTK_INCLUDE_DIRS} > ) > > target_compile_definitions(TestCase PUBLIC > ${VTK_DEFINITIONS} > ) > > set_target_properties(TestCase PROPERTIES > CXX_STANDARD 14 > CXX_STANDARD_REQUIRED ON > ) From elvis.stansvik at orexplore.com Tue May 23 05:35:04 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 23 May 2017 11:35:04 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-22 16:43 GMT+02:00 Utkarsh Ayachit : >> The test case I sent was just that. > > > Sorry, it got lost in my inbox. found it :). > > Attached is another patch. This tries a different approach to addressing the > alpha issue. Leaving the QSurfaceFormat unchanged, can you try the attached > patch and tell me how it goes? It's a patch for VTK. I applied the patch to the VTK 8.0.0.rc1 I'm using on the Mac, and can confirm that this fixes the problem: I no longer have to use setAlphaBufferSize(0) on the QSurfaceFormat to avoid the alpha problem. Thanks! I still haven't gotten back the Win 8.1/nVidia machine, so I haven't been able to verify the setAlphaBufferSize(0) fix nor this patch there yet. But I feel confident that the issue I saw there (shown in the screenshots in my first main) was the same as on the Mac, so is probably solved. The issue I'm having on Windows 7/intel now (volumes not showing) is orthogonal to this alpha issue, and I made a separate post about that. Thanks a lot for the assistance Utkarsh! Elvis > > Thanks, > Utkarsh From elvis.stansvik at orexplore.com Tue May 23 06:50:20 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 23 May 2017 12:50:20 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 Message-ID: Hi all, In porting to QVTKOpenGLWidget, I can't get volumes rendered using vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD 4600). They show up fine on Linux. They also show up fine on Windows 7 if using a plain VTK render window. I've tried turning off multisampling with setSamples(0) on the default QSurfaceFormat. The below test case illustrates the issue. See the attached screenshots from running "TestCase" (left) and "TestCase 1" (right). The former uses a plain render window while the latter uses the new QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain VTK rendering works fine, but the QVTKOpenGLWidget one is not showing the volume. Versions used: Kubuntu Linux 16.04 VTK 8.0.0.rc1, OpenGL2 Qt 5.5.1 Windows 7 VTK 8.0.0.rc1, OpenGL2 Qt 5.6.2 Any ideas what the problem might be? I can provide a standalone .zip distribution of my build of the test case if you want. Note that this issue is orthogonal to the alpha issue I reported and got solved in my other thread. Many thanks in advance, Elvis main.cpp: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); defaultFormat.setSamples(0); QSurfaceFormat::setDefaultFormat(defaultFormat); QApplication app(argc, argv); // Set up volume rendering vtkNew colorFunction; colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); vtkNew opacityFunction; opacityFunction->AddPoint(0.0, 0.0); opacityFunction->AddPoint(1.0, 1.0); vtkNew imageData; imageData->SetExtent(0, 200, 0, 200, 0, 200); imageData->AllocateScalars(VTK_FLOAT, 1); std::fill_n(static_cast(imageData->GetScalarPointer()), 8000000, 0.01); vtkNew volumeMapper; volumeMapper->SetInputData(imageData.Get()); vtkNew volumeProperty; volumeProperty->SetScalarOpacity(opacityFunction.Get()); volumeProperty->SetColor(colorFunction.Get()); volumeProperty->ShadeOff(); vtkNew volume; volume->SetMapper(volumeMapper.Get()); volume->SetProperty(volumeProperty.Get()); vtkNew renderer; renderer->AddVolume(volume.Get()); renderer->SetBackground(1.0, 1.0, 1.0); if (argc > 1) { // Render with QVTKOpenGLWidget vtkNew window; window->AddRenderer(renderer.Get()); auto widget = new QVTKOpenGLWidget(); widget->SetRenderWindow(window.Get()); widget->show(); return app.exec(); } else { // Render with "plain" render window / interactor vtkNew window; window->AddRenderer(renderer.Get()); vtkNew interactor; interactor->SetRenderWindow(window.Get()); interactor->Start(); return 0; } } CMakeLists.txt: cmake_minimum_required(VERSION 3.1) project(TestCase) find_package(VTK 8.0 COMPONENTS vtkCommonCore vtkCommonDataModel vtkCommonExecutionModel vtkCommonMath vtkFiltersSources vtkGUISupportQt vtkInteractionStyle vtkRenderingCore vtkRenderingOpenGL2 vtkRenderingVolume vtkRenderingVolumeOpenGL2 REQUIRED ) find_package(Qt5Widgets REQUIRED) add_executable(TestCase main.cpp) target_link_libraries(TestCase PUBLIC vtkCommonCore vtkCommonDataModel vtkCommonExecutionModel vtkCommonMath vtkFiltersSources vtkGUISupportQt vtkInteractionStyle vtkRenderingCore vtkRenderingOpenGL2 vtkRenderingVolume vtkRenderingVolumeOpenGL2 Qt5::Widgets ) target_include_directories(TestCase PUBLIC ${VTK_INCLUDE_DIRS} ) target_compile_definitions(TestCase PUBLIC ${VTK_DEFINITIONS} ) set_target_properties(TestCase PROPERTIES CXX_STANDARD 14 CXX_STANDARD_REQUIRED ON ) -------------- next part -------------- A non-text attachment was scrubbed... Name: voltestcase-linux-vtk8rc1-qt55.png Type: image/png Size: 346918 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: voltestcase-win7-vtk8rc1-qt56.png Type: image/png Size: 167329 bytes Desc: not available URL: From sankhesh.jhaveri at kitware.com Tue May 23 09:41:59 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Tue, 23 May 2017 13:41:59 +0000 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Hi Elvis, Could you try downloading the ParaView nightly binary and test volume rendering there? You can use the wavelet source for a test dataset. ParaView uses the QVTKOpenGLWidget and it would be a good test before diving into the code. Thanks, Sankhesh ? On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik wrote: > Hi all, > > In porting to QVTKOpenGLWidget, I can't get volumes rendered using > vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD > 4600). They show up fine on Linux. They also show up fine on Windows 7 > if using a plain VTK render window. I've tried turning off > multisampling with setSamples(0) on the default QSurfaceFormat. > > The below test case illustrates the issue. See the attached > screenshots from running "TestCase" (left) and "TestCase 1" (right). > The former uses a plain render window while the latter uses the new > QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain > VTK rendering works fine, but the QVTKOpenGLWidget one is not showing > the volume. > > Versions used: > > Kubuntu Linux 16.04 > VTK 8.0.0.rc1, OpenGL2 > Qt 5.5.1 > > Windows 7 > VTK 8.0.0.rc1, OpenGL2 > Qt 5.6.2 > > Any ideas what the problem might be? > > I can provide a standalone .zip distribution of my build of the test > case if you want. > > Note that this issue is orthogonal to the alpha issue I reported and > got solved in my other thread. > > Many thanks in advance, > Elvis > > > main.cpp: > > #include > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #include > > #include > > int main(int argc, char *argv[]) > { > auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); > defaultFormat.setSamples(0); > QSurfaceFormat::setDefaultFormat(defaultFormat); > > QApplication app(argc, argv); > > // Set up volume rendering > vtkNew colorFunction; > colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > > vtkNew opacityFunction; > opacityFunction->AddPoint(0.0, 0.0); > opacityFunction->AddPoint(1.0, 1.0); > > vtkNew imageData; > imageData->SetExtent(0, 200, 0, 200, 0, 200); > imageData->AllocateScalars(VTK_FLOAT, 1); > std::fill_n(static_cast(imageData->GetScalarPointer()), > 8000000, 0.01); > > vtkNew volumeMapper; > volumeMapper->SetInputData(imageData.Get()); > > vtkNew volumeProperty; > volumeProperty->SetScalarOpacity(opacityFunction.Get()); > volumeProperty->SetColor(colorFunction.Get()); > volumeProperty->ShadeOff(); > > vtkNew volume; > volume->SetMapper(volumeMapper.Get()); > volume->SetProperty(volumeProperty.Get()); > > vtkNew renderer; > renderer->AddVolume(volume.Get()); > renderer->SetBackground(1.0, 1.0, 1.0); > > if (argc > 1) { > // Render with QVTKOpenGLWidget > vtkNew window; > window->AddRenderer(renderer.Get()); > > auto widget = new QVTKOpenGLWidget(); > widget->SetRenderWindow(window.Get()); > widget->show(); > > return app.exec(); > } else { > // Render with "plain" render window / interactor > vtkNew window; > window->AddRenderer(renderer.Get()); > > vtkNew interactor; > interactor->SetRenderWindow(window.Get()); > interactor->Start(); > > return 0; > } > } > > > CMakeLists.txt: > > cmake_minimum_required(VERSION 3.1) > > project(TestCase) > > find_package(VTK 8.0 COMPONENTS > vtkCommonCore > vtkCommonDataModel > vtkCommonExecutionModel > vtkCommonMath > vtkFiltersSources > vtkGUISupportQt > vtkInteractionStyle > vtkRenderingCore > vtkRenderingOpenGL2 > vtkRenderingVolume > vtkRenderingVolumeOpenGL2 > REQUIRED > ) > > find_package(Qt5Widgets REQUIRED) > > add_executable(TestCase main.cpp) > > target_link_libraries(TestCase PUBLIC > vtkCommonCore > vtkCommonDataModel > vtkCommonExecutionModel > vtkCommonMath > vtkFiltersSources > vtkGUISupportQt > vtkInteractionStyle > vtkRenderingCore > vtkRenderingOpenGL2 > vtkRenderingVolume > vtkRenderingVolumeOpenGL2 > Qt5::Widgets > ) > > target_include_directories(TestCase PUBLIC > ${VTK_INCLUDE_DIRS} > ) > > target_compile_definitions(TestCase PUBLIC > ${VTK_DEFINITIONS} > ) > > set_target_properties(TestCase PROPERTIES > CXX_STANDARD 14 > CXX_STANDARD_REQUIRED ON > ) > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue May 23 10:51:31 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 23 May 2017 16:51:31 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri : > Hi Elvis, > > Could you try downloading the ParaView nightly binary and test volume > rendering there? You can use the wavelet source for a test dataset. ParaView > uses the QVTKOpenGLWidget and it would be a good test before diving into the > code. Ah yes, will do tomorrow (on my way home). Elvis > > Thanks, > Sankhesh > > > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > wrote: >> >> Hi all, >> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD >> 4600). They show up fine on Linux. They also show up fine on Windows 7 >> if using a plain VTK render window. I've tried turning off >> multisampling with setSamples(0) on the default QSurfaceFormat. >> >> The below test case illustrates the issue. See the attached >> screenshots from running "TestCase" (left) and "TestCase 1" (right). >> The former uses a plain render window while the latter uses the new >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain >> VTK rendering works fine, but the QVTKOpenGLWidget one is not showing >> the volume. >> >> Versions used: >> >> Kubuntu Linux 16.04 >> VTK 8.0.0.rc1, OpenGL2 >> Qt 5.5.1 >> >> Windows 7 >> VTK 8.0.0.rc1, OpenGL2 >> Qt 5.6.2 >> >> Any ideas what the problem might be? >> >> I can provide a standalone .zip distribution of my build of the test >> case if you want. >> >> Note that this issue is orthogonal to the alpha issue I reported and >> got solved in my other thread. >> >> Many thanks in advance, >> Elvis >> >> >> main.cpp: >> >> #include >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #include >> >> #include >> >> int main(int argc, char *argv[]) >> { >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >> defaultFormat.setSamples(0); >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> QApplication app(argc, argv); >> >> // Set up volume rendering >> vtkNew colorFunction; >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> vtkNew opacityFunction; >> opacityFunction->AddPoint(0.0, 0.0); >> opacityFunction->AddPoint(1.0, 1.0); >> >> vtkNew imageData; >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> imageData->AllocateScalars(VTK_FLOAT, 1); >> std::fill_n(static_cast(imageData->GetScalarPointer()), >> 8000000, 0.01); >> >> vtkNew volumeMapper; >> volumeMapper->SetInputData(imageData.Get()); >> >> vtkNew volumeProperty; >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> volumeProperty->SetColor(colorFunction.Get()); >> volumeProperty->ShadeOff(); >> >> vtkNew volume; >> volume->SetMapper(volumeMapper.Get()); >> volume->SetProperty(volumeProperty.Get()); >> >> vtkNew renderer; >> renderer->AddVolume(volume.Get()); >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> if (argc > 1) { >> // Render with QVTKOpenGLWidget >> vtkNew window; >> window->AddRenderer(renderer.Get()); >> >> auto widget = new QVTKOpenGLWidget(); >> widget->SetRenderWindow(window.Get()); >> widget->show(); >> >> return app.exec(); >> } else { >> // Render with "plain" render window / interactor >> vtkNew window; >> window->AddRenderer(renderer.Get()); >> >> vtkNew interactor; >> interactor->SetRenderWindow(window.Get()); >> interactor->Start(); >> >> return 0; >> } >> } >> >> >> CMakeLists.txt: >> >> cmake_minimum_required(VERSION 3.1) >> >> project(TestCase) >> >> find_package(VTK 8.0 COMPONENTS >> vtkCommonCore >> vtkCommonDataModel >> vtkCommonExecutionModel >> vtkCommonMath >> vtkFiltersSources >> vtkGUISupportQt >> vtkInteractionStyle >> vtkRenderingCore >> vtkRenderingOpenGL2 >> vtkRenderingVolume >> vtkRenderingVolumeOpenGL2 >> REQUIRED >> ) >> >> find_package(Qt5Widgets REQUIRED) >> >> add_executable(TestCase main.cpp) >> >> target_link_libraries(TestCase PUBLIC >> vtkCommonCore >> vtkCommonDataModel >> vtkCommonExecutionModel >> vtkCommonMath >> vtkFiltersSources >> vtkGUISupportQt >> vtkInteractionStyle >> vtkRenderingCore >> vtkRenderingOpenGL2 >> vtkRenderingVolume >> vtkRenderingVolumeOpenGL2 >> Qt5::Widgets >> ) >> >> target_include_directories(TestCase PUBLIC >> ${VTK_INCLUDE_DIRS} >> ) >> >> target_compile_definitions(TestCase PUBLIC >> ${VTK_DEFINITIONS} >> ) >> >> set_target_properties(TestCase PROPERTIES >> CXX_STANDARD 14 >> CXX_STANDARD_REQUIRED ON >> ) >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- > > Sankhesh Jhaveri > > Sr. Research & Development Engineer | Kitware | (518) 881-4417 From ken.martin at kitware.com Tue May 23 13:54:34 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 23 May 2017 13:54:34 -0400 Subject: [vtk-developers] ExternalData issue Message-ID: CMake Error at /home/kitware/dashboards/buildbot/vtk-eeloo-linux-shared-release_extdeps_java_mpi_python_python3_qt_qt5_tbb_tcl/source/CMake/ExternalData.cmake:1005 (message): Object MD5=96f64e5101ed9f660d67418d71705dcc not found at: http://midas3.kitware.com/midas/api/rest?method=midas.bitstream.download&checksum=96f64e5101ed9f660d67418d71705dcc&algorithm=MD5 (wrong hash MD5=a0a85923331d4faa2ba6ff130a19d946) http://www.vtk.org/files/ExternalData/MD5/96f64e5101ed9f660d67418d71705dcc ("HTTP response code said error") Call Stack (most recent call first): /home/kitware/dashboards/buildbot/vtk-eeloo-linux-shared-release_extdeps_java_mpi_python_python3_qt_qt5_tbb_tcl/source/CMake/ExternalData.cmake:1027 (_ExternalData_download_object) I have tried twice now and the buildbots do not seem to find the file though gitlab-push seems to be uploading it. Anyone know how to make this work? -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 brad.king at kitware.com Tue May 23 14:05:29 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 23 May 2017 14:05:29 -0400 Subject: [vtk-developers] ExternalData issue In-Reply-To: References: Message-ID: <5cb24c3e-8112-ea7c-b9c6-042e796849ad@kitware.com> On 05/23/2017 01:54 PM, Ken Martin wrote: > I have tried twice now and the buildbots do not seem to find the > file though gitlab-push seems to be uploading it. I don't see this object anywhere that indicates the push made it to gitlab. What output from gitlab-push indicates that the data are being pushed? Are you doing this from the same machine/repo/checkout on which you ran CMake after adding the data? See discussion here: https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md#discussion for details of what happens to the data. -Brad From ken.martin at kitware.com Tue May 23 14:30:32 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 23 May 2017 14:30:32 -0400 Subject: [vtk-developers] ExternalData issue In-Reply-To: <5cb24c3e-8112-ea7c-b9c6-042e796849ad@kitware.com> References: <5cb24c3e-8112-ea7c-b9c6-042e796849ad@kitware.com> Message-ID: On Tue, May 23, 2017 at 2:05 PM, Brad King wrote: > On 05/23/2017 01:54 PM, Ken Martin wrote: > > I have tried twice now and the buildbots do not seem to find the > > file though gitlab-push seems to be uploading it. > > I don't see this object anywhere that indicates the push made it to gitlab. > What output from gitlab-push indicates that the data are being pushed? > > I see the normal output I expect to see which is some stuff during cmake configure, then some more stuff during ninja and then I suspect some other stuff during git commit/push all related to this process. If there is a log file or something I can send you that but I saw the normal stuff I expected to see and no big red errors that I noticed. > Are you doing this from the same machine/repo/checkout on which > you ran CMake after adding the data? > > Yes > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 shawn.waldon at kitware.com Tue May 23 15:51:36 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 23 May 2017 15:51:36 -0400 Subject: [vtk-developers] ANN: Removing unmaintained modules vtkFiltersStatisticsGnuR and vtkFiltersMatlab Message-ID: Hi all, The vtkFiltersStatisticsGnuR and vtkFiltersMatlab modules in VTK currently do not have a maintainer and are untested. Does anyone use these? We are planning to remove these modules from VTK itself as they depend on code with non-permissive licenses and are unmaintained. If you are a user of one of these modules and would like to see it continue, it should be made into a remote module and someone will have to volunteer to maintain it. More information about remote modules can be found here [1]. Shawn [1]: http://www.vtk.org/Wiki/VTK/Remote_Modules -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed May 24 08:02:09 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 24 May 2017 08:02:09 -0400 Subject: [vtk-developers] ExternalData issue In-Reply-To: References: <5cb24c3e-8112-ea7c-b9c6-042e796849ad@kitware.com> Message-ID: To follow up, Brad had an idea that it could be the git auto CRLF translation causing an issue. The issue was on a text file so the md5 may have been created with CRLF then git auto translates to UNIX line endings before uploading the file and the md5 no longer matches. On Tue, May 23, 2017 at 2:30 PM, Ken Martin wrote: > > > On Tue, May 23, 2017 at 2:05 PM, Brad King wrote: > >> On 05/23/2017 01:54 PM, Ken Martin wrote: >> > I have tried twice now and the buildbots do not seem to find the >> > file though gitlab-push seems to be uploading it. >> >> I don't see this object anywhere that indicates the push made it to >> gitlab. >> What output from gitlab-push indicates that the data are being pushed? >> >> > I see the normal output I expect to see which is some stuff during cmake > configure, then some more stuff during ninja and then I suspect some other > stuff during git commit/push all related to this process. If there is a log > file or something I can send you that but I saw the normal stuff I expected > to see and no big red errors that I noticed. > > > >> Are you doing this from the same machine/repo/checkout on which >> you ran CMake after adding the data? >> >> > Yes > > >> >> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 elvis.stansvik at orexplore.com Wed May 24 08:18:53 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 24 May 2017 14:18:53 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri : > Hi Elvis, > > Could you try downloading the ParaView nightly binary and test volume > rendering there? You can use the wavelet source for a test dataset. ParaView > uses the QVTKOpenGLWidget and it would be a good test before diving into the > code. I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 64-bit, and the problem is the same as in my minimal test case. The volume won't show up. It does show up if I switch to the software based ray cast mapper (but not with GPU or smart, which I guess both result in the GPU one being used). Please tell me if there's anything else I can do to help debugging. There are no errors printed when I run my test case. Elvis > > Thanks, > Sankhesh > > > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > wrote: >> >> Hi all, >> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD >> 4600). They show up fine on Linux. They also show up fine on Windows 7 >> if using a plain VTK render window. I've tried turning off >> multisampling with setSamples(0) on the default QSurfaceFormat. >> >> The below test case illustrates the issue. See the attached >> screenshots from running "TestCase" (left) and "TestCase 1" (right). >> The former uses a plain render window while the latter uses the new >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain >> VTK rendering works fine, but the QVTKOpenGLWidget one is not showing >> the volume. >> >> Versions used: >> >> Kubuntu Linux 16.04 >> VTK 8.0.0.rc1, OpenGL2 >> Qt 5.5.1 >> >> Windows 7 >> VTK 8.0.0.rc1, OpenGL2 >> Qt 5.6.2 >> >> Any ideas what the problem might be? >> >> I can provide a standalone .zip distribution of my build of the test >> case if you want. >> >> Note that this issue is orthogonal to the alpha issue I reported and >> got solved in my other thread. >> >> Many thanks in advance, >> Elvis >> >> >> main.cpp: >> >> #include >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #include >> >> #include >> >> int main(int argc, char *argv[]) >> { >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >> defaultFormat.setSamples(0); >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> QApplication app(argc, argv); >> >> // Set up volume rendering >> vtkNew colorFunction; >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> vtkNew opacityFunction; >> opacityFunction->AddPoint(0.0, 0.0); >> opacityFunction->AddPoint(1.0, 1.0); >> >> vtkNew imageData; >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> imageData->AllocateScalars(VTK_FLOAT, 1); >> std::fill_n(static_cast(imageData->GetScalarPointer()), >> 8000000, 0.01); >> >> vtkNew volumeMapper; >> volumeMapper->SetInputData(imageData.Get()); >> >> vtkNew volumeProperty; >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> volumeProperty->SetColor(colorFunction.Get()); >> volumeProperty->ShadeOff(); >> >> vtkNew volume; >> volume->SetMapper(volumeMapper.Get()); >> volume->SetProperty(volumeProperty.Get()); >> >> vtkNew renderer; >> renderer->AddVolume(volume.Get()); >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> if (argc > 1) { >> // Render with QVTKOpenGLWidget >> vtkNew window; >> window->AddRenderer(renderer.Get()); >> >> auto widget = new QVTKOpenGLWidget(); >> widget->SetRenderWindow(window.Get()); >> widget->show(); >> >> return app.exec(); >> } else { >> // Render with "plain" render window / interactor >> vtkNew window; >> window->AddRenderer(renderer.Get()); >> >> vtkNew interactor; >> interactor->SetRenderWindow(window.Get()); >> interactor->Start(); >> >> return 0; >> } >> } >> >> >> CMakeLists.txt: >> >> cmake_minimum_required(VERSION 3.1) >> >> project(TestCase) >> >> find_package(VTK 8.0 COMPONENTS >> vtkCommonCore >> vtkCommonDataModel >> vtkCommonExecutionModel >> vtkCommonMath >> vtkFiltersSources >> vtkGUISupportQt >> vtkInteractionStyle >> vtkRenderingCore >> vtkRenderingOpenGL2 >> vtkRenderingVolume >> vtkRenderingVolumeOpenGL2 >> REQUIRED >> ) >> >> find_package(Qt5Widgets REQUIRED) >> >> add_executable(TestCase main.cpp) >> >> target_link_libraries(TestCase PUBLIC >> vtkCommonCore >> vtkCommonDataModel >> vtkCommonExecutionModel >> vtkCommonMath >> vtkFiltersSources >> vtkGUISupportQt >> vtkInteractionStyle >> vtkRenderingCore >> vtkRenderingOpenGL2 >> vtkRenderingVolume >> vtkRenderingVolumeOpenGL2 >> Qt5::Widgets >> ) >> >> target_include_directories(TestCase PUBLIC >> ${VTK_INCLUDE_DIRS} >> ) >> >> target_compile_definitions(TestCase PUBLIC >> ${VTK_DEFINITIONS} >> ) >> >> set_target_properties(TestCase PROPERTIES >> CXX_STANDARD 14 >> CXX_STANDARD_REQUIRED ON >> ) >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- > > Sankhesh Jhaveri > > Sr. Research & Development Engineer | Kitware | (518) 881-4417 From sankhesh.jhaveri at kitware.com Wed May 24 12:16:05 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Wed, 24 May 2017 16:16:05 +0000 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Okay thanks. I?ll take a look. ? On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik wrote: > 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >: > > Hi Elvis, > > > > Could you try downloading the ParaView nightly binary and test volume > > rendering there? You can use the wavelet source for a test dataset. > ParaView > > uses the QVTKOpenGLWidget and it would be a good test before diving into > the > > code. > > I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 > 64-bit, and the problem is the same as in my minimal test case. The > volume won't show up. > > It does show up if I switch to the software based ray cast mapper (but > not with GPU or smart, which I guess both result in the GPU one being > used). > > Please tell me if there's anything else I can do to help debugging. > There are no errors printed when I run my test case. > > Elvis > > > > > Thanks, > > Sankhesh > > > > > > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > > wrote: > >> > >> Hi all, > >> > >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using > >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD > >> 4600). They show up fine on Linux. They also show up fine on Windows 7 > >> if using a plain VTK render window. I've tried turning off > >> multisampling with setSamples(0) on the default QSurfaceFormat. > >> > >> The below test case illustrates the issue. See the attached > >> screenshots from running "TestCase" (left) and "TestCase 1" (right). > >> The former uses a plain render window while the latter uses the new > >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain > >> VTK rendering works fine, but the QVTKOpenGLWidget one is not showing > >> the volume. > >> > >> Versions used: > >> > >> Kubuntu Linux 16.04 > >> VTK 8.0.0.rc1, OpenGL2 > >> Qt 5.5.1 > >> > >> Windows 7 > >> VTK 8.0.0.rc1, OpenGL2 > >> Qt 5.6.2 > >> > >> Any ideas what the problem might be? > >> > >> I can provide a standalone .zip distribution of my build of the test > >> case if you want. > >> > >> Note that this issue is orthogonal to the alpha issue I reported and > >> got solved in my other thread. > >> > >> Many thanks in advance, > >> Elvis > >> > >> > >> main.cpp: > >> > >> #include > >> > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> #include > >> > >> #include > >> > >> #include > >> > >> int main(int argc, char *argv[]) > >> { > >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); > >> defaultFormat.setSamples(0); > >> QSurfaceFormat::setDefaultFormat(defaultFormat); > >> > >> QApplication app(argc, argv); > >> > >> // Set up volume rendering > >> vtkNew colorFunction; > >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > >> > >> vtkNew opacityFunction; > >> opacityFunction->AddPoint(0.0, 0.0); > >> opacityFunction->AddPoint(1.0, 1.0); > >> > >> vtkNew imageData; > >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >> imageData->AllocateScalars(VTK_FLOAT, 1); > >> std::fill_n(static_cast(imageData->GetScalarPointer()), > >> 8000000, 0.01); > >> > >> vtkNew volumeMapper; > >> volumeMapper->SetInputData(imageData.Get()); > >> > >> vtkNew volumeProperty; > >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); > >> volumeProperty->SetColor(colorFunction.Get()); > >> volumeProperty->ShadeOff(); > >> > >> vtkNew volume; > >> volume->SetMapper(volumeMapper.Get()); > >> volume->SetProperty(volumeProperty.Get()); > >> > >> vtkNew renderer; > >> renderer->AddVolume(volume.Get()); > >> renderer->SetBackground(1.0, 1.0, 1.0); > >> > >> if (argc > 1) { > >> // Render with QVTKOpenGLWidget > >> vtkNew window; > >> window->AddRenderer(renderer.Get()); > >> > >> auto widget = new QVTKOpenGLWidget(); > >> widget->SetRenderWindow(window.Get()); > >> widget->show(); > >> > >> return app.exec(); > >> } else { > >> // Render with "plain" render window / interactor > >> vtkNew window; > >> window->AddRenderer(renderer.Get()); > >> > >> vtkNew interactor; > >> interactor->SetRenderWindow(window.Get()); > >> interactor->Start(); > >> > >> return 0; > >> } > >> } > >> > >> > >> CMakeLists.txt: > >> > >> cmake_minimum_required(VERSION 3.1) > >> > >> project(TestCase) > >> > >> find_package(VTK 8.0 COMPONENTS > >> vtkCommonCore > >> vtkCommonDataModel > >> vtkCommonExecutionModel > >> vtkCommonMath > >> vtkFiltersSources > >> vtkGUISupportQt > >> vtkInteractionStyle > >> vtkRenderingCore > >> vtkRenderingOpenGL2 > >> vtkRenderingVolume > >> vtkRenderingVolumeOpenGL2 > >> REQUIRED > >> ) > >> > >> find_package(Qt5Widgets REQUIRED) > >> > >> add_executable(TestCase main.cpp) > >> > >> target_link_libraries(TestCase PUBLIC > >> vtkCommonCore > >> vtkCommonDataModel > >> vtkCommonExecutionModel > >> vtkCommonMath > >> vtkFiltersSources > >> vtkGUISupportQt > >> vtkInteractionStyle > >> vtkRenderingCore > >> vtkRenderingOpenGL2 > >> vtkRenderingVolume > >> vtkRenderingVolumeOpenGL2 > >> Qt5::Widgets > >> ) > >> > >> target_include_directories(TestCase PUBLIC > >> ${VTK_INCLUDE_DIRS} > >> ) > >> > >> target_compile_definitions(TestCase PUBLIC > >> ${VTK_DEFINITIONS} > >> ) > >> > >> set_target_properties(TestCase PROPERTIES > >> CXX_STANDARD 14 > >> CXX_STANDARD_REQUIRED ON > >> ) > >> _______________________________________________ > >> 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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > -- > > > > Sankhesh Jhaveri > > > > Sr. Research & Development Engineer | Kitware | (518) 881-4417 > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed May 24 13:22:52 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 24 May 2017 13:22:52 -0400 Subject: [vtk-developers] ExternalData issue In-Reply-To: References: <5cb24c3e-8112-ea7c-b9c6-042e796849ad@kitware.com> Message-ID: <25f404c7-4d7b-4c28-7a8d-76449110213c@kitware.com> On 05/24/2017 08:02 AM, Ken Martin wrote: > Brad had an idea that it could be the git auto CRLF translation Here is a fix: https://gitlab.kitware.com/vtk/vtk/merge_requests/2874 -Brad From sankhesh.jhaveri at kitware.com Wed May 24 16:20:03 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Wed, 24 May 2017 20:20:03 +0000 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Hi Elvis, Unfortunately, I wasn?t able to reproduce this issue. :( I don?t have a Windows machine with an Intel graphics card but tried ParaView on a couple of Windows machines as well as a Mac (with an Intel HD5600). Worked fine. At this point, I am inclined to think that the graphics drivers on your Windows machine may need updating. ? On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri < sankhesh.jhaveri at kitware.com> wrote: > Okay thanks. > > I?ll take a look. > ? > > On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik < > elvis.stansvik at orexplore.com> wrote: > >> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >: >> > Hi Elvis, >> > >> > Could you try downloading the ParaView nightly binary and test volume >> > rendering there? You can use the wavelet source for a test dataset. >> ParaView >> > uses the QVTKOpenGLWidget and it would be a good test before diving >> into the >> > code. >> >> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >> 64-bit, and the problem is the same as in my minimal test case. The >> volume won't show up. >> >> It does show up if I switch to the software based ray cast mapper (but >> not with GPU or smart, which I guess both result in the GPU one being >> used). >> >> Please tell me if there's anything else I can do to help debugging. >> There are no errors printed when I run my test case. >> >> Elvis >> >> > >> > Thanks, >> > Sankhesh >> > >> > >> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> > wrote: >> >> >> >> Hi all, >> >> >> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD >> >> 4600). They show up fine on Linux. They also show up fine on Windows 7 >> >> if using a plain VTK render window. I've tried turning off >> >> multisampling with setSamples(0) on the default QSurfaceFormat. >> >> >> >> The below test case illustrates the issue. See the attached >> >> screenshots from running "TestCase" (left) and "TestCase 1" (right). >> >> The former uses a plain render window while the latter uses the new >> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain >> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not showing >> >> the volume. >> >> >> >> Versions used: >> >> >> >> Kubuntu Linux 16.04 >> >> VTK 8.0.0.rc1, OpenGL2 >> >> Qt 5.5.1 >> >> >> >> Windows 7 >> >> VTK 8.0.0.rc1, OpenGL2 >> >> Qt 5.6.2 >> >> >> >> Any ideas what the problem might be? >> >> >> >> I can provide a standalone .zip distribution of my build of the test >> >> case if you want. >> >> >> >> Note that this issue is orthogonal to the alpha issue I reported and >> >> got solved in my other thread. >> >> >> >> Many thanks in advance, >> >> Elvis >> >> >> >> >> >> main.cpp: >> >> >> >> #include >> >> >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> #include >> >> >> >> #include >> >> >> >> #include >> >> >> >> int main(int argc, char *argv[]) >> >> { >> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >> >> defaultFormat.setSamples(0); >> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> >> >> QApplication app(argc, argv); >> >> >> >> // Set up volume rendering >> >> vtkNew colorFunction; >> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> >> >> vtkNew opacityFunction; >> >> opacityFunction->AddPoint(0.0, 0.0); >> >> opacityFunction->AddPoint(1.0, 1.0); >> >> >> >> vtkNew imageData; >> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >> std::fill_n(static_cast(imageData->GetScalarPointer()), >> >> 8000000, 0.01); >> >> >> >> vtkNew volumeMapper; >> >> volumeMapper->SetInputData(imageData.Get()); >> >> >> >> vtkNew volumeProperty; >> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >> volumeProperty->SetColor(colorFunction.Get()); >> >> volumeProperty->ShadeOff(); >> >> >> >> vtkNew volume; >> >> volume->SetMapper(volumeMapper.Get()); >> >> volume->SetProperty(volumeProperty.Get()); >> >> >> >> vtkNew renderer; >> >> renderer->AddVolume(volume.Get()); >> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> >> >> if (argc > 1) { >> >> // Render with QVTKOpenGLWidget >> >> vtkNew window; >> >> window->AddRenderer(renderer.Get()); >> >> >> >> auto widget = new QVTKOpenGLWidget(); >> >> widget->SetRenderWindow(window.Get()); >> >> widget->show(); >> >> >> >> return app.exec(); >> >> } else { >> >> // Render with "plain" render window / interactor >> >> vtkNew window; >> >> window->AddRenderer(renderer.Get()); >> >> >> >> vtkNew interactor; >> >> interactor->SetRenderWindow(window.Get()); >> >> interactor->Start(); >> >> >> >> return 0; >> >> } >> >> } >> >> >> >> >> >> CMakeLists.txt: >> >> >> >> cmake_minimum_required(VERSION 3.1) >> >> >> >> project(TestCase) >> >> >> >> find_package(VTK 8.0 COMPONENTS >> >> vtkCommonCore >> >> vtkCommonDataModel >> >> vtkCommonExecutionModel >> >> vtkCommonMath >> >> vtkFiltersSources >> >> vtkGUISupportQt >> >> vtkInteractionStyle >> >> vtkRenderingCore >> >> vtkRenderingOpenGL2 >> >> vtkRenderingVolume >> >> vtkRenderingVolumeOpenGL2 >> >> REQUIRED >> >> ) >> >> >> >> find_package(Qt5Widgets REQUIRED) >> >> >> >> add_executable(TestCase main.cpp) >> >> >> >> target_link_libraries(TestCase PUBLIC >> >> vtkCommonCore >> >> vtkCommonDataModel >> >> vtkCommonExecutionModel >> >> vtkCommonMath >> >> vtkFiltersSources >> >> vtkGUISupportQt >> >> vtkInteractionStyle >> >> vtkRenderingCore >> >> vtkRenderingOpenGL2 >> >> vtkRenderingVolume >> >> vtkRenderingVolumeOpenGL2 >> >> Qt5::Widgets >> >> ) >> >> >> >> target_include_directories(TestCase PUBLIC >> >> ${VTK_INCLUDE_DIRS} >> >> ) >> >> >> >> target_compile_definitions(TestCase PUBLIC >> >> ${VTK_DEFINITIONS} >> >> ) >> >> >> >> set_target_properties(TestCase PROPERTIES >> >> CXX_STANDARD 14 >> >> CXX_STANDARD_REQUIRED ON >> >> ) >> >> _______________________________________________ >> >> 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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -- >> > >> > Sankhesh Jhaveri >> > >> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> > -- > Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > | (518) 881-4417 > ? > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed May 24 16:49:13 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 24 May 2017 22:49:13 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri : > Hi Elvis, > > Unfortunately, I wasn?t able to reproduce this issue. :( > > I don?t have a Windows machine with an Intel graphics card but tried > ParaView on a couple of Windows machines as well as a Mac (with an Intel > HD5600). Worked fine. Alright. Call for help then: Anyone else have a Windows 7 machine with Intel graphics? Would be great if someone could reproduce. I could put up my build of the test case as a self-contained .zip, to make it easy to test. > > At this point, I am inclined to think that the graphics drivers on your > Windows machine may need updating. Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that suggest that the drivers are capable enough, and that the problem is somehow in QVTKOpenGLWidget (or QOpenGLWidget)? Elvis > > > On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > wrote: >> >> Okay thanks. >> >> I?ll take a look. >> >> >> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> wrote: >>> >>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>> : >>> > Hi Elvis, >>> > >>> > Could you try downloading the ParaView nightly binary and test volume >>> > rendering there? You can use the wavelet source for a test dataset. >>> > ParaView >>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>> > into the >>> > code. >>> >>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>> 64-bit, and the problem is the same as in my minimal test case. The >>> volume won't show up. >>> >>> It does show up if I switch to the software based ray cast mapper (but >>> not with GPU or smart, which I guess both result in the GPU one being >>> used). >>> >>> Please tell me if there's anything else I can do to help debugging. >>> There are no errors printed when I run my test case. >>> >>> Elvis >>> >>> > >>> > Thanks, >>> > Sankhesh >>> > >>> > >>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>> > wrote: >>> >> >>> >> Hi all, >>> >> >>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD >>> >> 4600). They show up fine on Linux. They also show up fine on Windows 7 >>> >> if using a plain VTK render window. I've tried turning off >>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>> >> >>> >> The below test case illustrates the issue. See the attached >>> >> screenshots from running "TestCase" (left) and "TestCase 1" (right). >>> >> The former uses a plain render window while the latter uses the new >>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain >>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not showing >>> >> the volume. >>> >> >>> >> Versions used: >>> >> >>> >> Kubuntu Linux 16.04 >>> >> VTK 8.0.0.rc1, OpenGL2 >>> >> Qt 5.5.1 >>> >> >>> >> Windows 7 >>> >> VTK 8.0.0.rc1, OpenGL2 >>> >> Qt 5.6.2 >>> >> >>> >> Any ideas what the problem might be? >>> >> >>> >> I can provide a standalone .zip distribution of my build of the test >>> >> case if you want. >>> >> >>> >> Note that this issue is orthogonal to the alpha issue I reported and >>> >> got solved in my other thread. >>> >> >>> >> Many thanks in advance, >>> >> Elvis >>> >> >>> >> >>> >> main.cpp: >>> >> >>> >> #include >>> >> >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> #include >>> >> >>> >> #include >>> >> >>> >> #include >>> >> >>> >> int main(int argc, char *argv[]) >>> >> { >>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>> >> defaultFormat.setSamples(0); >>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>> >> >>> >> QApplication app(argc, argv); >>> >> >>> >> // Set up volume rendering >>> >> vtkNew colorFunction; >>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>> >> >>> >> vtkNew opacityFunction; >>> >> opacityFunction->AddPoint(0.0, 0.0); >>> >> opacityFunction->AddPoint(1.0, 1.0); >>> >> >>> >> vtkNew imageData; >>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>> >> std::fill_n(static_cast(imageData->GetScalarPointer()), >>> >> 8000000, 0.01); >>> >> >>> >> vtkNew volumeMapper; >>> >> volumeMapper->SetInputData(imageData.Get()); >>> >> >>> >> vtkNew volumeProperty; >>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>> >> volumeProperty->SetColor(colorFunction.Get()); >>> >> volumeProperty->ShadeOff(); >>> >> >>> >> vtkNew volume; >>> >> volume->SetMapper(volumeMapper.Get()); >>> >> volume->SetProperty(volumeProperty.Get()); >>> >> >>> >> vtkNew renderer; >>> >> renderer->AddVolume(volume.Get()); >>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>> >> >>> >> if (argc > 1) { >>> >> // Render with QVTKOpenGLWidget >>> >> vtkNew window; >>> >> window->AddRenderer(renderer.Get()); >>> >> >>> >> auto widget = new QVTKOpenGLWidget(); >>> >> widget->SetRenderWindow(window.Get()); >>> >> widget->show(); >>> >> >>> >> return app.exec(); >>> >> } else { >>> >> // Render with "plain" render window / interactor >>> >> vtkNew window; >>> >> window->AddRenderer(renderer.Get()); >>> >> >>> >> vtkNew interactor; >>> >> interactor->SetRenderWindow(window.Get()); >>> >> interactor->Start(); >>> >> >>> >> return 0; >>> >> } >>> >> } >>> >> >>> >> >>> >> CMakeLists.txt: >>> >> >>> >> cmake_minimum_required(VERSION 3.1) >>> >> >>> >> project(TestCase) >>> >> >>> >> find_package(VTK 8.0 COMPONENTS >>> >> vtkCommonCore >>> >> vtkCommonDataModel >>> >> vtkCommonExecutionModel >>> >> vtkCommonMath >>> >> vtkFiltersSources >>> >> vtkGUISupportQt >>> >> vtkInteractionStyle >>> >> vtkRenderingCore >>> >> vtkRenderingOpenGL2 >>> >> vtkRenderingVolume >>> >> vtkRenderingVolumeOpenGL2 >>> >> REQUIRED >>> >> ) >>> >> >>> >> find_package(Qt5Widgets REQUIRED) >>> >> >>> >> add_executable(TestCase main.cpp) >>> >> >>> >> target_link_libraries(TestCase PUBLIC >>> >> vtkCommonCore >>> >> vtkCommonDataModel >>> >> vtkCommonExecutionModel >>> >> vtkCommonMath >>> >> vtkFiltersSources >>> >> vtkGUISupportQt >>> >> vtkInteractionStyle >>> >> vtkRenderingCore >>> >> vtkRenderingOpenGL2 >>> >> vtkRenderingVolume >>> >> vtkRenderingVolumeOpenGL2 >>> >> Qt5::Widgets >>> >> ) >>> >> >>> >> target_include_directories(TestCase PUBLIC >>> >> ${VTK_INCLUDE_DIRS} >>> >> ) >>> >> >>> >> target_compile_definitions(TestCase PUBLIC >>> >> ${VTK_DEFINITIONS} >>> >> ) >>> >> >>> >> set_target_properties(TestCase PROPERTIES >>> >> CXX_STANDARD 14 >>> >> CXX_STANDARD_REQUIRED ON >>> >> ) >>> >> _______________________________________________ >>> >> 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: >>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>> > -- >>> > >>> > Sankhesh Jhaveri >>> > >>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >> -- >> >> Sankhesh Jhaveri >> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > > -- > > Sankhesh Jhaveri > > Sr. Research & Development Engineer | Kitware | (518) 881-4417 From elvis.stansvik at orexplore.com Wed May 24 17:02:31 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 24 May 2017 23:02:31 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri : >> Hi Elvis, >> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >> I don?t have a Windows machine with an Intel graphics card but tried >> ParaView on a couple of se Windows machines as well as a Mac (with an Intel >> HD5600). Worked fine. > > Alright. Call for help then: Anyone else have a Windows 7 machine with > Intel graphics? Would be great if someone could reproduce. Forgot to say: Thanks a lot for trying to reproduce Sankhesh. I've now put up the compiled self-contained test case here: http://dose.se/~estan/voltestcase-inst.zip (18 MB) If anyone with Windows (preferably Windows 7 if possible) + Intel graphics could try running this test case with "TestCase 1" and see if the volume shows up, that would be great. (Running the test case with argc > 2 will make it use QVTKOpenGLWidget, and is where I'm having trouble). Elvis > > I could put up my build of the test case as a self-contained .zip, to > make it easy to test. > >> >> At this point, I am inclined to think that the graphics drivers on your >> Windows machine may need updating. > > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that > suggest that the drivers are capable enough, and that the problem is > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > > Elvis > >> >> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> wrote: >>> >>> Okay thanks. >>> >>> I?ll take a look. >>> >>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>> wrote: >>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>>> : >>>> > Hi Elvis, >>>> > >>>> > Could you try downloading the ParaView nightly binary and test volume >>>> > rendering there? You can use the wavelet source for a test dataset. >>>> > ParaView >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>>> > into the >>>> > code. >>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>>> 64-bit, and the problem is the same as in my minimal test case. The >>>> volume won't show up. >>>> >>>> It does show up if I switch to the software based ray cast mapper (but >>>> not with GPU or smart, which I guess both result in the GPU one being >>>> used). >>>> >>>> Please tell me if there's anything else I can do to help debugging. >>>> There are no errors printed when I run my test case. >>>> >>>> Elvis >>>> >>>> > >>>> > Thanks, >>>> > Sankhesh >>>> > >>>> > >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>>> > wrote: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics (HD >>>> >> 4600). They show up fine on Linux. They also show up fine on Windows 7 >>>> >> if using a plain VTK render window. I've tried turning off >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>>> >> >>>> >> The below test case illustrates the issue. See the attached >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" (right). >>>> >> The former uses a plain render window while the latter uses the new >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not showing >>>> >> the volume. >>>> >> >>>> >> Versions used: >>>> >> >>>> >> Kubuntu Linux 16.04 >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>> >> Qt 5.5.1 >>>> >> >>>> >> Windows 7 >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>> >> Qt 5.6.2 >>>> >> >>>> >> Any ideas what the problem might be? >>>> >> >>>> >> I can provide a standalone .zip distribution of my build of the test >>>> >> case if you want. >>>> >> >>>> >> Note that this issue is orthogonal to the alpha issue I reported and >>>> >> got solved in my other thread. >>>> >> >>>> >> Many thanks in advance, >>>> >> Elvis >>>> >> >>>> >> >>>> >> main.cpp: >>>> >> >>>> >> #include >>>> >> >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> #include >>>> >> >>>> >> #include >>>> >> >>>> >> #include >>>> >> >>>> >> int main(int argc, char *argv[]) >>>> >> { >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>>> >> defaultFormat.setSamples(0); >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>>> >> >>>> >> QApplication app(argc, argv); >>>> >> >>>> >> // Set up volume rendering >>>> >> vtkNew colorFunction; >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>>> >> >>>> >> vtkNew opacityFunction; >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>>> >> >>>> >> vtkNew imageData; >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>>> >> std::fill_n(static_cast(imageData->GetScalarPointer()), >>>> >> 8000000, 0.01); >>>> >> >>>> >> vtkNew volumeMapper; >>>> >> volumeMapper->SetInputData(imageData.Get()); >>>> >> >>>> >> vtkNew volumeProperty; >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>>> >> volumeProperty->ShadeOff(); >>>> >> >>>> >> vtkNew volume; >>>> >> volume->SetMapper(volumeMapper.Get()); >>>> >> volume->SetProperty(volumeProperty.Get()); >>>> >> >>>> >> vtkNew renderer; >>>> >> renderer->AddVolume(volume.Get()); >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>>> >> >>>> >> if (argc > 1) { >>>> >> // Render with QVTKOpenGLWidget >>>> >> vtkNew window; >>>> >> window->AddRenderer(renderer.Get()); >>>> >> >>>> >> auto widget = new QVTKOpenGLWidget(); >>>> >> widget->SetRenderWindow(window.Get()); >>>> >> widget->show(); >>>> >> >>>> >> return app.exec(); >>>> >> } else { >>>> >> // Render with "plain" render window / interactor >>>> >> vtkNew window; >>>> >> window->AddRenderer(renderer.Get()); >>>> >> >>>> >> vtkNew interactor; >>>> >> interactor->SetRenderWindow(window.Get()); >>>> >> interactor->Start(); >>>> >> >>>> >> return 0; >>>> >> } >>>> >> } >>>> >> >>>> >> >>>> >> CMakeLists.txt: >>>> >> >>>> >> cmake_minimum_required(VERSION 3.1) >>>> >> >>>> >> project(TestCase) >>>> >> >>>> >> find_package(VTK 8.0 COMPONENTS >>>> >> vtkCommonCore >>>> >> vtkCommonDataModel >>>> >> vtkCommonExecutionModel >>>> >> vtkCommonMath >>>> >> vtkFiltersSources >>>> >> vtkGUISupportQt >>>> >> vtkInteractionStyle >>>> >> vtkRenderingCore >>>> >> vtkRenderingOpenGL2 >>>> >> vtkRenderingVolume >>>> >> vtkRenderingVolumeOpenGL2 >>>> >> REQUIRED >>>> >> ) >>>> >> >>>> >> find_package(Qt5Widgets REQUIRED) >>>> >> >>>> >> add_executable(TestCase main.cpp) >>>> >> >>>> >> target_link_libraries(TestCase PUBLIC >>>> >> vtkCommonCore >>>> >> vtkCommonDataModel >>>> >> vtkCommonExecutionModel >>>> >> vtkCommonMath >>>> >> vtkFiltersSources >>>> >> vtkGUISupportQt >>>> >> vtkInteractionStyle >>>> >> vtkRenderingCore >>>> >> vtkRenderingOpenGL2 >>>> >> vtkRenderingVolume >>>> >> vtkRenderingVolumeOpenGL2 >>>> >> Qt5::Widgets >>>> >> ) >>>> >> >>>> >> target_include_directories(TestCase PUBLIC >>>> >> ${VTK_INCLUDE_DIRS} >>>> >> ) >>>> >> >>>> >> target_compile_definitions(TestCase PUBLIC >>>> >> ${VTK_DEFINITIONS} >>>> >> ) >>>> >> >>>> >> set_target_properties(TestCase PROPERTIES >>>> >> CXX_STANDARD 14 >>>> >> CXX_STANDARD_REQUIRED ON >>>> >> ) >>>> >> _______________________________________________ >>>> >> 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: >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >> >>>> > -- >>>> > >>>> > Sankhesh Jhaveri >>>> > >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>> >>> -- >>> >>> Sankhesh Jhaveri >>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >> -- >> >> Sankhesh Jhaveri >> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 From aron.helser at kitware.com Thu May 25 10:22:55 2017 From: aron.helser at kitware.com (Aron Helser) Date: Thu, 25 May 2017 10:22:55 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Hi Elvis, I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both intel and nvidia graphics. With your test case, I'm able to see the volume running either with Intel or nVidia, so it doesn't repro for me. I've got Intel HD530 graphics, with driver version 21.20.16.4627 Sorry, Aron On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : > > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri < > sankhesh.jhaveri at kitware.com>: > >> Hi Elvis, > >> > >> Unfortunately, I wasn?t able to reproduce this issue. :( > >> > >> I don?t have a Windows machine with an Intel graphics card but tried > >> ParaView on a couple of se Windows machines as well as a Mac (with an > Intel > >> HD5600). Worked fine. > > > > Alright. Call for help then: Anyone else have a Windows 7 machine with > > Intel graphics? Would be great if someone could reproduce. > > Forgot to say: Thanks a lot for trying to reproduce Sankhesh. > > I've now put up the compiled self-contained test case here: > > http://dose.se/~estan/voltestcase-inst.zip (18 MB) > > If anyone with Windows (preferably Windows 7 if possible) + Intel > graphics could try running this test case with "TestCase 1" and see if > the volume shows up, that would be great. > > (Running the test case with argc > 2 will make it use > QVTKOpenGLWidget, and is where I'm having trouble). > > Elvis > > > > > I could put up my build of the test case as a self-contained .zip, to > > make it easy to test. > > > >> > >> At this point, I am inclined to think that the graphics drivers on your > >> Windows machine may need updating. > > > > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a > > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that > > suggest that the drivers are capable enough, and that the problem is > > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > > > > Elvis > > > >> > >> > >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > >> wrote: > >>> > >>> Okay thanks. > >>> > >>> I?ll take a look. > >>> > >>> > >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik > >>> wrote: > >>>> > >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >>>> : > >>>> > Hi Elvis, > >>>> > > >>>> > Could you try downloading the ParaView nightly binary and test > volume > >>>> > rendering there? You can use the wavelet source for a test dataset. > >>>> > ParaView > >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving > >>>> > into the > >>>> > code. > >>>> > >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 > >>>> 64-bit, and the problem is the same as in my minimal test case. The > >>>> volume won't show up. > >>>> > >>>> It does show up if I switch to the software based ray cast mapper (but > >>>> not with GPU or smart, which I guess both result in the GPU one being > >>>> used). > >>>> > >>>> Please tell me if there's anything else I can do to help debugging. > >>>> There are no errors printed when I run my test case. > >>>> > >>>> Elvis > >>>> > >>>> > > >>>> > Thanks, > >>>> > Sankhesh > >>>> > > >>>> > > >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > >>>> > wrote: > >>>> >> > >>>> >> Hi all, > >>>> >> > >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using > >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics > (HD > >>>> >> 4600). They show up fine on Linux. They also show up fine on > Windows 7 > >>>> >> if using a plain VTK render window. I've tried turning off > >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. > >>>> >> > >>>> >> The below test case illustrates the issue. See the attached > >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" > (right). > >>>> >> The former uses a plain render window while the latter uses the new > >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the plain > >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not > showing > >>>> >> the volume. > >>>> >> > >>>> >> Versions used: > >>>> >> > >>>> >> Kubuntu Linux 16.04 > >>>> >> VTK 8.0.0.rc1, OpenGL2 > >>>> >> Qt 5.5.1 > >>>> >> > >>>> >> Windows 7 > >>>> >> VTK 8.0.0.rc1, OpenGL2 > >>>> >> Qt 5.6.2 > >>>> >> > >>>> >> Any ideas what the problem might be? > >>>> >> > >>>> >> I can provide a standalone .zip distribution of my build of the > test > >>>> >> case if you want. > >>>> >> > >>>> >> Note that this issue is orthogonal to the alpha issue I reported > and > >>>> >> got solved in my other thread. > >>>> >> > >>>> >> Many thanks in advance, > >>>> >> Elvis > >>>> >> > >>>> >> > >>>> >> main.cpp: > >>>> >> > >>>> >> #include > >>>> >> > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> #include > >>>> >> > >>>> >> #include > >>>> >> > >>>> >> #include > >>>> >> > >>>> >> int main(int argc, char *argv[]) > >>>> >> { > >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); > >>>> >> defaultFormat.setSamples(0); > >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); > >>>> >> > >>>> >> QApplication app(argc, argv); > >>>> >> > >>>> >> // Set up volume rendering > >>>> >> vtkNew colorFunction; > >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > >>>> >> > >>>> >> vtkNew opacityFunction; > >>>> >> opacityFunction->AddPoint(0.0, 0.0); > >>>> >> opacityFunction->AddPoint(1.0, 1.0); > >>>> >> > >>>> >> vtkNew imageData; > >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); > >>>> >> std::fill_n(static_cast(imageData-> > GetScalarPointer()), > >>>> >> 8000000, 0.01); > >>>> >> > >>>> >> vtkNew volumeMapper; > >>>> >> volumeMapper->SetInputData(imageData.Get()); > >>>> >> > >>>> >> vtkNew volumeProperty; > >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); > >>>> >> volumeProperty->SetColor(colorFunction.Get()); > >>>> >> volumeProperty->ShadeOff(); > >>>> >> > >>>> >> vtkNew volume; > >>>> >> volume->SetMapper(volumeMapper.Get()); > >>>> >> volume->SetProperty(volumeProperty.Get()); > >>>> >> > >>>> >> vtkNew renderer; > >>>> >> renderer->AddVolume(volume.Get()); > >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); > >>>> >> > >>>> >> if (argc > 1) { > >>>> >> // Render with QVTKOpenGLWidget > >>>> >> vtkNew window; > >>>> >> window->AddRenderer(renderer.Get()); > >>>> >> > >>>> >> auto widget = new QVTKOpenGLWidget(); > >>>> >> widget->SetRenderWindow(window.Get()); > >>>> >> widget->show(); > >>>> >> > >>>> >> return app.exec(); > >>>> >> } else { > >>>> >> // Render with "plain" render window / interactor > >>>> >> vtkNew window; > >>>> >> window->AddRenderer(renderer.Get()); > >>>> >> > >>>> >> vtkNew interactor; > >>>> >> interactor->SetRenderWindow(window.Get()); > >>>> >> interactor->Start(); > >>>> >> > >>>> >> return 0; > >>>> >> } > >>>> >> } > >>>> >> > >>>> >> > >>>> >> CMakeLists.txt: > >>>> >> > >>>> >> cmake_minimum_required(VERSION 3.1) > >>>> >> > >>>> >> project(TestCase) > >>>> >> > >>>> >> find_package(VTK 8.0 COMPONENTS > >>>> >> vtkCommonCore > >>>> >> vtkCommonDataModel > >>>> >> vtkCommonExecutionModel > >>>> >> vtkCommonMath > >>>> >> vtkFiltersSources > >>>> >> vtkGUISupportQt > >>>> >> vtkInteractionStyle > >>>> >> vtkRenderingCore > >>>> >> vtkRenderingOpenGL2 > >>>> >> vtkRenderingVolume > >>>> >> vtkRenderingVolumeOpenGL2 > >>>> >> REQUIRED > >>>> >> ) > >>>> >> > >>>> >> find_package(Qt5Widgets REQUIRED) > >>>> >> > >>>> >> add_executable(TestCase main.cpp) > >>>> >> > >>>> >> target_link_libraries(TestCase PUBLIC > >>>> >> vtkCommonCore > >>>> >> vtkCommonDataModel > >>>> >> vtkCommonExecutionModel > >>>> >> vtkCommonMath > >>>> >> vtkFiltersSources > >>>> >> vtkGUISupportQt > >>>> >> vtkInteractionStyle > >>>> >> vtkRenderingCore > >>>> >> vtkRenderingOpenGL2 > >>>> >> vtkRenderingVolume > >>>> >> vtkRenderingVolumeOpenGL2 > >>>> >> Qt5::Widgets > >>>> >> ) > >>>> >> > >>>> >> target_include_directories(TestCase PUBLIC > >>>> >> ${VTK_INCLUDE_DIRS} > >>>> >> ) > >>>> >> > >>>> >> target_compile_definitions(TestCase PUBLIC > >>>> >> ${VTK_DEFINITIONS} > >>>> >> ) > >>>> >> > >>>> >> set_target_properties(TestCase PROPERTIES > >>>> >> CXX_STANDARD 14 > >>>> >> CXX_STANDARD_REQUIRED ON > >>>> >> ) > >>>> >> _______________________________________________ > >>>> >> 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: > >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>> >> > >>>> > -- > >>>> > > >>>> > Sankhesh Jhaveri > >>>> > > >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >>> > >>> -- > >>> > >>> Sankhesh Jhaveri > >>> > >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >> > >> -- > >> > >> Sankhesh Jhaveri > >> > >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu May 25 11:02:01 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 25 May 2017 17:02:01 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-25 16:22 GMT+02:00 Aron Helser : > Hi Elvis, > I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both > intel and nvidia graphics. > With your test case, I'm able to see the volume running either with Intel or > nVidia, so it doesn't repro for me. > I've got Intel HD530 graphics, with driver version 21.20.16.4627 > Sorry, > Aron Alright, bugger. Thanks for testing though! I won't be at the office until Monday again, but when I'm back I'll try experimenting with different driver versions. Elvis > > On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik > wrote: >> >> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : >> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> > : >> >> Hi Elvis, >> >> >> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >> >> >> I don?t have a Windows machine with an Intel graphics card but tried >> >> ParaView on a couple of se Windows machines as well as a Mac (with an >> >> Intel >> >> HD5600). Worked fine. >> > >> > Alright. Call for help then: Anyone else have a Windows 7 machine with >> > Intel graphics? Would be great if someone could reproduce. >> >> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >> I've now put up the compiled self-contained test case here: >> >> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >> If anyone with Windows (preferably Windows 7 if possible) + Intel >> graphics could try running this test case with "TestCase 1" and see if >> the volume shows up, that would be great. >> >> (Running the test case with argc > 2 will make it use >> QVTKOpenGLWidget, and is where I'm having trouble). >> >> Elvis >> >> > >> > I could put up my build of the test case as a self-contained .zip, to >> > make it easy to test. >> > >> >> >> >> At this point, I am inclined to think that the graphics drivers on your >> >> Windows machine may need updating. >> > >> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a >> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >> > suggest that the drivers are capable enough, and that the problem is >> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> > >> > Elvis >> > >> >> >> >> >> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >> wrote: >> >>> >> >>> Okay thanks. >> >>> >> >>> I?ll take a look. >> >>> >> >>> >> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >>> wrote: >> >>>> >> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >>>> : >> >>>> > Hi Elvis, >> >>>> > >> >>>> > Could you try downloading the ParaView nightly binary and test >> >>>> > volume >> >>>> > rendering there? You can use the wavelet source for a test dataset. >> >>>> > ParaView >> >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >> >>>> > into the >> >>>> > code. >> >>>> >> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >> >>>> 64-bit, and the problem is the same as in my minimal test case. The >> >>>> volume won't show up. >> >>>> >> >>>> It does show up if I switch to the software based ray cast mapper >> >>>> (but >> >>>> not with GPU or smart, which I guess both result in the GPU one being >> >>>> used). >> >>>> >> >>>> Please tell me if there's anything else I can do to help debugging. >> >>>> There are no errors printed when I run my test case. >> >>>> >> >>>> Elvis >> >>>> >> >>>> > >> >>>> > Thanks, >> >>>> > Sankhesh >> >>>> > >> >>>> > >> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >>>> > wrote: >> >>>> >> >> >>>> >> Hi all, >> >>>> >> >> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics >> >>>> >> (HD >> >>>> >> 4600). They show up fine on Linux. They also show up fine on >> >>>> >> Windows 7 >> >>>> >> if using a plain VTK render window. I've tried turning off >> >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >> >>>> >> >> >>>> >> The below test case illustrates the issue. See the attached >> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >> >>>> >> (right). >> >>>> >> The former uses a plain render window while the latter uses the >> >>>> >> new >> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >> >>>> >> plain >> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >> >>>> >> showing >> >>>> >> the volume. >> >>>> >> >> >>>> >> Versions used: >> >>>> >> >> >>>> >> Kubuntu Linux 16.04 >> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>> >> Qt 5.5.1 >> >>>> >> >> >>>> >> Windows 7 >> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>> >> Qt 5.6.2 >> >>>> >> >> >>>> >> Any ideas what the problem might be? >> >>>> >> >> >>>> >> I can provide a standalone .zip distribution of my build of the >> >>>> >> test >> >>>> >> case if you want. >> >>>> >> >> >>>> >> Note that this issue is orthogonal to the alpha issue I reported >> >>>> >> and >> >>>> >> got solved in my other thread. >> >>>> >> >> >>>> >> Many thanks in advance, >> >>>> >> Elvis >> >>>> >> >> >>>> >> >> >>>> >> main.cpp: >> >>>> >> >> >>>> >> #include >> >>>> >> >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> #include >> >>>> >> >> >>>> >> #include >> >>>> >> >> >>>> >> #include >> >>>> >> >> >>>> >> int main(int argc, char *argv[]) >> >>>> >> { >> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >> >>>> >> defaultFormat.setSamples(0); >> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >>>> >> >> >>>> >> QApplication app(argc, argv); >> >>>> >> >> >>>> >> // Set up volume rendering >> >>>> >> vtkNew colorFunction; >> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >>>> >> >> >>>> >> vtkNew opacityFunction; >> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >>>> >> >> >>>> >> vtkNew imageData; >> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >>>> >> std::fill_n(static_cast> >>>> >> *>(imageData->GetScalarPointer()), >> >>>> >> 8000000, 0.01); >> >>>> >> >> >>>> >> vtkNew volumeMapper; >> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >>>> >> >> >>>> >> vtkNew volumeProperty; >> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >>>> >> volumeProperty->ShadeOff(); >> >>>> >> >> >>>> >> vtkNew volume; >> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >>>> >> >> >>>> >> vtkNew renderer; >> >>>> >> renderer->AddVolume(volume.Get()); >> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >>>> >> >> >>>> >> if (argc > 1) { >> >>>> >> // Render with QVTKOpenGLWidget >> >>>> >> vtkNew window; >> >>>> >> window->AddRenderer(renderer.Get()); >> >>>> >> >> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >>>> >> widget->SetRenderWindow(window.Get()); >> >>>> >> widget->show(); >> >>>> >> >> >>>> >> return app.exec(); >> >>>> >> } else { >> >>>> >> // Render with "plain" render window / interactor >> >>>> >> vtkNew window; >> >>>> >> window->AddRenderer(renderer.Get()); >> >>>> >> >> >>>> >> vtkNew interactor; >> >>>> >> interactor->SetRenderWindow(window.Get()); >> >>>> >> interactor->Start(); >> >>>> >> >> >>>> >> return 0; >> >>>> >> } >> >>>> >> } >> >>>> >> >> >>>> >> >> >>>> >> CMakeLists.txt: >> >>>> >> >> >>>> >> cmake_minimum_required(VERSION 3.1) >> >>>> >> >> >>>> >> project(TestCase) >> >>>> >> >> >>>> >> find_package(VTK 8.0 COMPONENTS >> >>>> >> vtkCommonCore >> >>>> >> vtkCommonDataModel >> >>>> >> vtkCommonExecutionModel >> >>>> >> vtkCommonMath >> >>>> >> vtkFiltersSources >> >>>> >> vtkGUISupportQt >> >>>> >> vtkInteractionStyle >> >>>> >> vtkRenderingCore >> >>>> >> vtkRenderingOpenGL2 >> >>>> >> vtkRenderingVolume >> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>> >> REQUIRED >> >>>> >> ) >> >>>> >> >> >>>> >> find_package(Qt5Widgets REQUIRED) >> >>>> >> >> >>>> >> add_executable(TestCase main.cpp) >> >>>> >> >> >>>> >> target_link_libraries(TestCase PUBLIC >> >>>> >> vtkCommonCore >> >>>> >> vtkCommonDataModel >> >>>> >> vtkCommonExecutionModel >> >>>> >> vtkCommonMath >> >>>> >> vtkFiltersSources >> >>>> >> vtkGUISupportQt >> >>>> >> vtkInteractionStyle >> >>>> >> vtkRenderingCore >> >>>> >> vtkRenderingOpenGL2 >> >>>> >> vtkRenderingVolume >> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>> >> Qt5::Widgets >> >>>> >> ) >> >>>> >> >> >>>> >> target_include_directories(TestCase PUBLIC >> >>>> >> ${VTK_INCLUDE_DIRS} >> >>>> >> ) >> >>>> >> >> >>>> >> target_compile_definitions(TestCase PUBLIC >> >>>> >> ${VTK_DEFINITIONS} >> >>>> >> ) >> >>>> >> >> >>>> >> set_target_properties(TestCase PROPERTIES >> >>>> >> CXX_STANDARD 14 >> >>>> >> CXX_STANDARD_REQUIRED ON >> >>>> >> ) >> >>>> >> _______________________________________________ >> >>>> >> 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: >> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>> >> >> >>>> > -- >> >>>> > >> >>>> > Sankhesh Jhaveri >> >>>> > >> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>> >> >>> -- >> >>> >> >>> Sankhesh Jhaveri >> >>> >> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >> >> >> -- >> >> >> >> Sankhesh Jhaveri >> >> >> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > From DLRdave at aol.com Thu May 25 12:14:04 2017 From: DLRdave at aol.com (David Cole) Date: Thu, 25 May 2017 12:14:04 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I get your TestCase app window with nothing but an empty (white) client region. An app we have built against VTK 6.2-ish with the old OpenGL using VolumeSmartMapper works fine on this very same machine. Another data point... D On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik wrote: > 2017-05-25 16:22 GMT+02:00 Aron Helser : >> Hi Elvis, >> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both >> intel and nvidia graphics. >> With your test case, I'm able to see the volume running either with Intel or >> nVidia, so it doesn't repro for me. >> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> Sorry, >> Aron > > Alright, bugger. Thanks for testing though! > > I won't be at the office until Monday again, but when I'm back I'll > try experimenting with different driver versions. > > Elvis > >> >> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> wrote: >>> >>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : >>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>> > : >>> >> Hi Elvis, >>> >> >>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>> >> >>> >> I don?t have a Windows machine with an Intel graphics card but tried >>> >> ParaView on a couple of se Windows machines as well as a Mac (with an >>> >> Intel >>> >> HD5600). Worked fine. >>> > >>> > Alright. Call for help then: Anyone else have a Windows 7 machine with >>> > Intel graphics? Would be great if someone could reproduce. >>> >>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>> >>> I've now put up the compiled self-contained test case here: >>> >>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>> >>> If anyone with Windows (preferably Windows 7 if possible) + Intel >>> graphics could try running this test case with "TestCase 1" and see if >>> the volume shows up, that would be great. >>> >>> (Running the test case with argc > 2 will make it use >>> QVTKOpenGLWidget, and is where I'm having trouble). >>> >>> Elvis >>> >>> > >>> > I could put up my build of the test case as a self-contained .zip, to >>> > make it easy to test. >>> > >>> >> >>> >> At this point, I am inclined to think that the graphics drivers on your >>> >> Windows machine may need updating. >>> > >>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a >>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >>> > suggest that the drivers are capable enough, and that the problem is >>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>> > >>> > Elvis >>> > >>> >> >>> >> >>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>> >> wrote: >>> >>> >>> >>> Okay thanks. >>> >>> >>> >>> I?ll take a look. >>> >>> >>> >>> >>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>> >>> wrote: >>> >>>> >>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>> >>>> : >>> >>>> > Hi Elvis, >>> >>>> > >>> >>>> > Could you try downloading the ParaView nightly binary and test >>> >>>> > volume >>> >>>> > rendering there? You can use the wavelet source for a test dataset. >>> >>>> > ParaView >>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>> >>>> > into the >>> >>>> > code. >>> >>>> >>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>> >>>> 64-bit, and the problem is the same as in my minimal test case. The >>> >>>> volume won't show up. >>> >>>> >>> >>>> It does show up if I switch to the software based ray cast mapper >>> >>>> (but >>> >>>> not with GPU or smart, which I guess both result in the GPU one being >>> >>>> used). >>> >>>> >>> >>>> Please tell me if there's anything else I can do to help debugging. >>> >>>> There are no errors printed when I run my test case. >>> >>>> >>> >>>> Elvis >>> >>>> >>> >>>> > >>> >>>> > Thanks, >>> >>>> > Sankhesh >>> >>>> > >>> >>>> > >>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>> >>>> > wrote: >>> >>>> >> >>> >>>> >> Hi all, >>> >>>> >> >>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics >>> >>>> >> (HD >>> >>>> >> 4600). They show up fine on Linux. They also show up fine on >>> >>>> >> Windows 7 >>> >>>> >> if using a plain VTK render window. I've tried turning off >>> >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>> >>>> >> >>> >>>> >> The below test case illustrates the issue. See the attached >>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >>> >>>> >> (right). >>> >>>> >> The former uses a plain render window while the latter uses the >>> >>>> >> new >>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >>> >>>> >> plain >>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >>> >>>> >> showing >>> >>>> >> the volume. >>> >>>> >> >>> >>>> >> Versions used: >>> >>>> >> >>> >>>> >> Kubuntu Linux 16.04 >>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>> >>>> >> Qt 5.5.1 >>> >>>> >> >>> >>>> >> Windows 7 >>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>> >>>> >> Qt 5.6.2 >>> >>>> >> >>> >>>> >> Any ideas what the problem might be? >>> >>>> >> >>> >>>> >> I can provide a standalone .zip distribution of my build of the >>> >>>> >> test >>> >>>> >> case if you want. >>> >>>> >> >>> >>>> >> Note that this issue is orthogonal to the alpha issue I reported >>> >>>> >> and >>> >>>> >> got solved in my other thread. >>> >>>> >> >>> >>>> >> Many thanks in advance, >>> >>>> >> Elvis >>> >>>> >> >>> >>>> >> >>> >>>> >> main.cpp: >>> >>>> >> >>> >>>> >> #include >>> >>>> >> >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> #include >>> >>>> >> >>> >>>> >> #include >>> >>>> >> >>> >>>> >> #include >>> >>>> >> >>> >>>> >> int main(int argc, char *argv[]) >>> >>>> >> { >>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>> >>>> >> defaultFormat.setSamples(0); >>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>> >>>> >> >>> >>>> >> QApplication app(argc, argv); >>> >>>> >> >>> >>>> >> // Set up volume rendering >>> >>>> >> vtkNew colorFunction; >>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>> >>>> >> >>> >>>> >> vtkNew opacityFunction; >>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>> >>>> >> >>> >>>> >> vtkNew imageData; >>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>> >>>> >> std::fill_n(static_cast>> >>>> >> *>(imageData->GetScalarPointer()), >>> >>>> >> 8000000, 0.01); >>> >>>> >> >>> >>>> >> vtkNew volumeMapper; >>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>> >>>> >> >>> >>>> >> vtkNew volumeProperty; >>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>> >>>> >> volumeProperty->ShadeOff(); >>> >>>> >> >>> >>>> >> vtkNew volume; >>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>> >>>> >> >>> >>>> >> vtkNew renderer; >>> >>>> >> renderer->AddVolume(volume.Get()); >>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>> >>>> >> >>> >>>> >> if (argc > 1) { >>> >>>> >> // Render with QVTKOpenGLWidget >>> >>>> >> vtkNew window; >>> >>>> >> window->AddRenderer(renderer.Get()); >>> >>>> >> >>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>> >>>> >> widget->SetRenderWindow(window.Get()); >>> >>>> >> widget->show(); >>> >>>> >> >>> >>>> >> return app.exec(); >>> >>>> >> } else { >>> >>>> >> // Render with "plain" render window / interactor >>> >>>> >> vtkNew window; >>> >>>> >> window->AddRenderer(renderer.Get()); >>> >>>> >> >>> >>>> >> vtkNew interactor; >>> >>>> >> interactor->SetRenderWindow(window.Get()); >>> >>>> >> interactor->Start(); >>> >>>> >> >>> >>>> >> return 0; >>> >>>> >> } >>> >>>> >> } >>> >>>> >> >>> >>>> >> >>> >>>> >> CMakeLists.txt: >>> >>>> >> >>> >>>> >> cmake_minimum_required(VERSION 3.1) >>> >>>> >> >>> >>>> >> project(TestCase) >>> >>>> >> >>> >>>> >> find_package(VTK 8.0 COMPONENTS >>> >>>> >> vtkCommonCore >>> >>>> >> vtkCommonDataModel >>> >>>> >> vtkCommonExecutionModel >>> >>>> >> vtkCommonMath >>> >>>> >> vtkFiltersSources >>> >>>> >> vtkGUISupportQt >>> >>>> >> vtkInteractionStyle >>> >>>> >> vtkRenderingCore >>> >>>> >> vtkRenderingOpenGL2 >>> >>>> >> vtkRenderingVolume >>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >>>> >> REQUIRED >>> >>>> >> ) >>> >>>> >> >>> >>>> >> find_package(Qt5Widgets REQUIRED) >>> >>>> >> >>> >>>> >> add_executable(TestCase main.cpp) >>> >>>> >> >>> >>>> >> target_link_libraries(TestCase PUBLIC >>> >>>> >> vtkCommonCore >>> >>>> >> vtkCommonDataModel >>> >>>> >> vtkCommonExecutionModel >>> >>>> >> vtkCommonMath >>> >>>> >> vtkFiltersSources >>> >>>> >> vtkGUISupportQt >>> >>>> >> vtkInteractionStyle >>> >>>> >> vtkRenderingCore >>> >>>> >> vtkRenderingOpenGL2 >>> >>>> >> vtkRenderingVolume >>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >>>> >> Qt5::Widgets >>> >>>> >> ) >>> >>>> >> >>> >>>> >> target_include_directories(TestCase PUBLIC >>> >>>> >> ${VTK_INCLUDE_DIRS} >>> >>>> >> ) >>> >>>> >> >>> >>>> >> target_compile_definitions(TestCase PUBLIC >>> >>>> >> ${VTK_DEFINITIONS} >>> >>>> >> ) >>> >>>> >> >>> >>>> >> set_target_properties(TestCase PROPERTIES >>> >>>> >> CXX_STANDARD 14 >>> >>>> >> CXX_STANDARD_REQUIRED ON >>> >>>> >> ) >>> >>>> >> _______________________________________________ >>> >>>> >> 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: >>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>>> >> >>> >>>> > -- >>> >>>> > >>> >>>> > Sankhesh Jhaveri >>> >>>> > >>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>> >>> >>> >>> -- >>> >>> >>> >>> Sankhesh Jhaveri >>> >>> >>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>> >> >>> >> -- >>> >> >>> >> Sankhesh Jhaveri >>> >> >>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>> _______________________________________________ >>> 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: >>> http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Thu May 25 14:35:45 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 25 May 2017 20:35:45 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-25 18:14 GMT+02:00 David Cole : > Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, > with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I > get your TestCase app window with nothing but an empty (white) client > region. > > An app we have built against VTK 6.2-ish with the old OpenGL using > VolumeSmartMapper works fine on this very same machine. > > Another data point... Finally a reproduction, I was beginning to despair :) Thanks a lot David. And just to make sure, Aron, did you run the test case as "TestCase 1", with a parameter? That's the crucial thing, as otherwise it'll just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not QVTKOpenGLWidget), and not exhibit the problem. Elvis > > > D > > > > > On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik > wrote: >> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>> Hi Elvis, >>> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both >>> intel and nvidia graphics. >>> With your test case, I'm able to see the volume running either with Intel or >>> nVidia, so it doesn't repro for me. >>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >>> Sorry, >>> Aron >> >> Alright, bugger. Thanks for testing though! >> >> I won't be at the office until Monday again, but when I'm back I'll >> try experimenting with different driver versions. >> >> Elvis >> >>> >>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>> wrote: >>>> >>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : >>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>>> > : >>>> >> Hi Elvis, >>>> >> >>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>>> >> >>>> >> I don?t have a Windows machine with an Intel graphics card but tried >>>> >> ParaView on a couple of se Windows machines as well as a Mac (with an >>>> >> Intel >>>> >> HD5600). Worked fine. >>>> > >>>> > Alright. Call for help then: Anyone else have a Windows 7 machine with >>>> > Intel graphics? Would be great if someone could reproduce. >>>> >>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>>> >>>> I've now put up the compiled self-contained test case here: >>>> >>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>>> >>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >>>> graphics could try running this test case with "TestCase 1" and see if >>>> the volume shows up, that would be great. >>>> >>>> (Running the test case with argc > 2 will make it use >>>> QVTKOpenGLWidget, and is where I'm having trouble). >>>> >>>> Elvis >>>> >>>> > >>>> > I could put up my build of the test case as a self-contained .zip, to >>>> > make it easy to test. >>>> > >>>> >> >>>> >> At this point, I am inclined to think that the graphics drivers on your >>>> >> Windows machine may need updating. >>>> > >>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a >>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >>>> > suggest that the drivers are capable enough, and that the problem is >>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>>> > >>>> > Elvis >>>> > >>>> >> >>>> >> >>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>>> >> wrote: >>>> >>> >>>> >>> Okay thanks. >>>> >>> >>>> >>> I?ll take a look. >>>> >>> >>>> >>> >>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>>> >>> wrote: >>>> >>>> >>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>>> >>>> : >>>> >>>> > Hi Elvis, >>>> >>>> > >>>> >>>> > Could you try downloading the ParaView nightly binary and test >>>> >>>> > volume >>>> >>>> > rendering there? You can use the wavelet source for a test dataset. >>>> >>>> > ParaView >>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>>> >>>> > into the >>>> >>>> > code. >>>> >>>> >>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>>> >>>> 64-bit, and the problem is the same as in my minimal test case. The >>>> >>>> volume won't show up. >>>> >>>> >>>> >>>> It does show up if I switch to the software based ray cast mapper >>>> >>>> (but >>>> >>>> not with GPU or smart, which I guess both result in the GPU one being >>>> >>>> used). >>>> >>>> >>>> >>>> Please tell me if there's anything else I can do to help debugging. >>>> >>>> There are no errors printed when I run my test case. >>>> >>>> >>>> >>>> Elvis >>>> >>>> >>>> >>>> > >>>> >>>> > Thanks, >>>> >>>> > Sankhesh >>>> >>>> > >>>> >>>> > >>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>>> >>>> > wrote: >>>> >>>> >> >>>> >>>> >> Hi all, >>>> >>>> >> >>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics >>>> >>>> >> (HD >>>> >>>> >> 4600). They show up fine on Linux. They also show up fine on >>>> >>>> >> Windows 7 >>>> >>>> >> if using a plain VTK render window. I've tried turning off >>>> >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>>> >>>> >> >>>> >>>> >> The below test case illustrates the issue. See the attached >>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >>>> >>>> >> (right). >>>> >>>> >> The former uses a plain render window while the latter uses the >>>> >>>> >> new >>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >>>> >>>> >> plain >>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >>>> >>>> >> showing >>>> >>>> >> the volume. >>>> >>>> >> >>>> >>>> >> Versions used: >>>> >>>> >> >>>> >>>> >> Kubuntu Linux 16.04 >>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>> >>>> >> Qt 5.5.1 >>>> >>>> >> >>>> >>>> >> Windows 7 >>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>> >>>> >> Qt 5.6.2 >>>> >>>> >> >>>> >>>> >> Any ideas what the problem might be? >>>> >>>> >> >>>> >>>> >> I can provide a standalone .zip distribution of my build of the >>>> >>>> >> test >>>> >>>> >> case if you want. >>>> >>>> >> >>>> >>>> >> Note that this issue is orthogonal to the alpha issue I reported >>>> >>>> >> and >>>> >>>> >> got solved in my other thread. >>>> >>>> >> >>>> >>>> >> Many thanks in advance, >>>> >>>> >> Elvis >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> main.cpp: >>>> >>>> >> >>>> >>>> >> #include >>>> >>>> >> >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> #include >>>> >>>> >> >>>> >>>> >> #include >>>> >>>> >> >>>> >>>> >> #include >>>> >>>> >> >>>> >>>> >> int main(int argc, char *argv[]) >>>> >>>> >> { >>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>>> >>>> >> defaultFormat.setSamples(0); >>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>>> >>>> >> >>>> >>>> >> QApplication app(argc, argv); >>>> >>>> >> >>>> >>>> >> // Set up volume rendering >>>> >>>> >> vtkNew colorFunction; >>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>>> >>>> >> >>>> >>>> >> vtkNew opacityFunction; >>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>>> >>>> >> >>>> >>>> >> vtkNew imageData; >>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>>> >>>> >> std::fill_n(static_cast>>> >>>> >> *>(imageData->GetScalarPointer()), >>>> >>>> >> 8000000, 0.01); >>>> >>>> >> >>>> >>>> >> vtkNew volumeMapper; >>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>>> >>>> >> >>>> >>>> >> vtkNew volumeProperty; >>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>>> >>>> >> volumeProperty->ShadeOff(); >>>> >>>> >> >>>> >>>> >> vtkNew volume; >>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>>> >>>> >> >>>> >>>> >> vtkNew renderer; >>>> >>>> >> renderer->AddVolume(volume.Get()); >>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>>> >>>> >> >>>> >>>> >> if (argc > 1) { >>>> >>>> >> // Render with QVTKOpenGLWidget >>>> >>>> >> vtkNew window; >>>> >>>> >> window->AddRenderer(renderer.Get()); >>>> >>>> >> >>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>>> >>>> >> widget->SetRenderWindow(window.Get()); >>>> >>>> >> widget->show(); >>>> >>>> >> >>>> >>>> >> return app.exec(); >>>> >>>> >> } else { >>>> >>>> >> // Render with "plain" render window / interactor >>>> >>>> >> vtkNew window; >>>> >>>> >> window->AddRenderer(renderer.Get()); >>>> >>>> >> >>>> >>>> >> vtkNew interactor; >>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>>> >>>> >> interactor->Start(); >>>> >>>> >> >>>> >>>> >> return 0; >>>> >>>> >> } >>>> >>>> >> } >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> CMakeLists.txt: >>>> >>>> >> >>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>>> >>>> >> >>>> >>>> >> project(TestCase) >>>> >>>> >> >>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>>> >>>> >> vtkCommonCore >>>> >>>> >> vtkCommonDataModel >>>> >>>> >> vtkCommonExecutionModel >>>> >>>> >> vtkCommonMath >>>> >>>> >> vtkFiltersSources >>>> >>>> >> vtkGUISupportQt >>>> >>>> >> vtkInteractionStyle >>>> >>>> >> vtkRenderingCore >>>> >>>> >> vtkRenderingOpenGL2 >>>> >>>> >> vtkRenderingVolume >>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>> >>>> >> REQUIRED >>>> >>>> >> ) >>>> >>>> >> >>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>>> >>>> >> >>>> >>>> >> add_executable(TestCase main.cpp) >>>> >>>> >> >>>> >>>> >> target_link_libraries(TestCase PUBLIC >>>> >>>> >> vtkCommonCore >>>> >>>> >> vtkCommonDataModel >>>> >>>> >> vtkCommonExecutionModel >>>> >>>> >> vtkCommonMath >>>> >>>> >> vtkFiltersSources >>>> >>>> >> vtkGUISupportQt >>>> >>>> >> vtkInteractionStyle >>>> >>>> >> vtkRenderingCore >>>> >>>> >> vtkRenderingOpenGL2 >>>> >>>> >> vtkRenderingVolume >>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>> >>>> >> Qt5::Widgets >>>> >>>> >> ) >>>> >>>> >> >>>> >>>> >> target_include_directories(TestCase PUBLIC >>>> >>>> >> ${VTK_INCLUDE_DIRS} >>>> >>>> >> ) >>>> >>>> >> >>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>>> >>>> >> ${VTK_DEFINITIONS} >>>> >>>> >> ) >>>> >>>> >> >>>> >>>> >> set_target_properties(TestCase PROPERTIES >>>> >>>> >> CXX_STANDARD 14 >>>> >>>> >> CXX_STANDARD_REQUIRED ON >>>> >>>> >> ) >>>> >>>> >> _______________________________________________ >>>> >>>> >> 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: >>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >> >>>> >>>> > -- >>>> >>>> > >>>> >>>> > Sankhesh Jhaveri >>>> >>>> > >>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>> >>> >>>> >>> -- >>>> >>> >>>> >>> Sankhesh Jhaveri >>>> >>> >>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>> >> >>>> >> -- >>>> >> >>>> >> Sankhesh Jhaveri >>>> >> >>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>> _______________________________________________ >>>> 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: >>>> http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> From aron.helser at kitware.com Thu May 25 15:09:53 2017 From: aron.helser at kitware.com (Aron Helser) Date: Thu, 25 May 2017 15:09:53 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: No I did not, but I just tried it again, adding the "1" argument, and I still get no repro. Running either with Intel or nvidia shows the volume just fine. On Thu, May 25, 2017 at 2:35 PM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-25 18:14 GMT+02:00 David Cole : > > Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, > > with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I > > get your TestCase app window with nothing but an empty (white) client > > region. > > > > An app we have built against VTK 6.2-ish with the old OpenGL using > > VolumeSmartMapper works fine on this very same machine. > > > > Another data point... > > Finally a reproduction, I was beginning to despair :) Thanks a lot David. > > And just to make sure, Aron, did you run the test case as "TestCase > 1", with a parameter? That's the crucial thing, as otherwise it'll > just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not > QVTKOpenGLWidget), and not exhibit the problem. > > Elvis > > > > > > > D > > > > > > > > > > On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik > > wrote: > >> 2017-05-25 16:22 GMT+02:00 Aron Helser : > >>> Hi Elvis, > >>> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - > both > >>> intel and nvidia graphics. > >>> With your test case, I'm able to see the volume running either with > Intel or > >>> nVidia, so it doesn't repro for me. > >>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 > >>> Sorry, > >>> Aron > >> > >> Alright, bugger. Thanks for testing though! > >> > >> I won't be at the office until Monday again, but when I'm back I'll > >> try experimenting with different driver versions. > >> > >> Elvis > >> > >>> > >>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik > >>> wrote: > >>>> > >>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik < > elvis.stansvik at orexplore.com>: > >>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri > >>>> > : > >>>> >> Hi Elvis, > >>>> >> > >>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( > >>>> >> > >>>> >> I don?t have a Windows machine with an Intel graphics card but > tried > >>>> >> ParaView on a couple of se Windows machines as well as a Mac (with > an > >>>> >> Intel > >>>> >> HD5600). Worked fine. > >>>> > > >>>> > Alright. Call for help then: Anyone else have a Windows 7 machine > with > >>>> > Intel graphics? Would be great if someone could reproduce. > >>>> > >>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. > >>>> > >>>> I've now put up the compiled self-contained test case here: > >>>> > >>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) > >>>> > >>>> If anyone with Windows (preferably Windows 7 if possible) + Intel > >>>> graphics could try running this test case with "TestCase 1" and see if > >>>> the volume shows up, that would be great. > >>>> > >>>> (Running the test case with argc > 2 will make it use > >>>> QVTKOpenGLWidget, and is where I'm having trouble). > >>>> > >>>> Elvis > >>>> > >>>> > > >>>> > I could put up my build of the test case as a self-contained .zip, > to > >>>> > make it easy to test. > >>>> > > >>>> >> > >>>> >> At this point, I am inclined to think that the graphics drivers on > your > >>>> >> Windows machine may need updating. > >>>> > > >>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use > a > >>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that > >>>> > suggest that the drivers are capable enough, and that the problem is > >>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > >>>> > > >>>> > Elvis > >>>> > > >>>> >> > >>>> >> > >>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > >>>> >> wrote: > >>>> >>> > >>>> >>> Okay thanks. > >>>> >>> > >>>> >>> I?ll take a look. > >>>> >>> > >>>> >>> > >>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik > >>>> >>> wrote: > >>>> >>>> > >>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >>>> >>>> : > >>>> >>>> > Hi Elvis, > >>>> >>>> > > >>>> >>>> > Could you try downloading the ParaView nightly binary and test > >>>> >>>> > volume > >>>> >>>> > rendering there? You can use the wavelet source for a test > dataset. > >>>> >>>> > ParaView > >>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before > diving > >>>> >>>> > into the > >>>> >>>> > code. > >>>> >>>> > >>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 > >>>> >>>> 64-bit, and the problem is the same as in my minimal test case. > The > >>>> >>>> volume won't show up. > >>>> >>>> > >>>> >>>> It does show up if I switch to the software based ray cast mapper > >>>> >>>> (but > >>>> >>>> not with GPU or smart, which I guess both result in the GPU one > being > >>>> >>>> used). > >>>> >>>> > >>>> >>>> Please tell me if there's anything else I can do to help > debugging. > >>>> >>>> There are no errors printed when I run my test case. > >>>> >>>> > >>>> >>>> Elvis > >>>> >>>> > >>>> >>>> > > >>>> >>>> > Thanks, > >>>> >>>> > Sankhesh > >>>> >>>> > > >>>> >>>> > > >>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > >>>> >>>> > wrote: > >>>> >>>> >> > >>>> >>>> >> Hi all, > >>>> >>>> >> > >>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered > using > >>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel > graphics > >>>> >>>> >> (HD > >>>> >>>> >> 4600). They show up fine on Linux. They also show up fine on > >>>> >>>> >> Windows 7 > >>>> >>>> >> if using a plain VTK render window. I've tried turning off > >>>> >>>> >> multisampling with setSamples(0) on the default > QSurfaceFormat. > >>>> >>>> >> > >>>> >>>> >> The below test case illustrates the issue. See the attached > >>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" > >>>> >>>> >> (right). > >>>> >>>> >> The former uses a plain render window while the latter uses > the > >>>> >>>> >> new > >>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the > >>>> >>>> >> plain > >>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not > >>>> >>>> >> showing > >>>> >>>> >> the volume. > >>>> >>>> >> > >>>> >>>> >> Versions used: > >>>> >>>> >> > >>>> >>>> >> Kubuntu Linux 16.04 > >>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >>>> >>>> >> Qt 5.5.1 > >>>> >>>> >> > >>>> >>>> >> Windows 7 > >>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >>>> >>>> >> Qt 5.6.2 > >>>> >>>> >> > >>>> >>>> >> Any ideas what the problem might be? > >>>> >>>> >> > >>>> >>>> >> I can provide a standalone .zip distribution of my build of > the > >>>> >>>> >> test > >>>> >>>> >> case if you want. > >>>> >>>> >> > >>>> >>>> >> Note that this issue is orthogonal to the alpha issue I > reported > >>>> >>>> >> and > >>>> >>>> >> got solved in my other thread. > >>>> >>>> >> > >>>> >>>> >> Many thanks in advance, > >>>> >>>> >> Elvis > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> main.cpp: > >>>> >>>> >> > >>>> >>>> >> #include > >>>> >>>> >> > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> #include > >>>> >>>> >> > >>>> >>>> >> #include > >>>> >>>> >> > >>>> >>>> >> #include > >>>> >>>> >> > >>>> >>>> >> int main(int argc, char *argv[]) > >>>> >>>> >> { > >>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); > >>>> >>>> >> defaultFormat.setSamples(0); > >>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); > >>>> >>>> >> > >>>> >>>> >> QApplication app(argc, argv); > >>>> >>>> >> > >>>> >>>> >> // Set up volume rendering > >>>> >>>> >> vtkNew colorFunction; > >>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > >>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > >>>> >>>> >> > >>>> >>>> >> vtkNew opacityFunction; > >>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); > >>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); > >>>> >>>> >> > >>>> >>>> >> vtkNew imageData; > >>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); > >>>> >>>> >> std::fill_n(static_cast >>>> >>>> >> *>(imageData->GetScalarPointer()), > >>>> >>>> >> 8000000, 0.01); > >>>> >>>> >> > >>>> >>>> >> vtkNew volumeMapper; > >>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); > >>>> >>>> >> > >>>> >>>> >> vtkNew volumeProperty; > >>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); > >>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); > >>>> >>>> >> volumeProperty->ShadeOff(); > >>>> >>>> >> > >>>> >>>> >> vtkNew volume; > >>>> >>>> >> volume->SetMapper(volumeMapper.Get()); > >>>> >>>> >> volume->SetProperty(volumeProperty.Get()); > >>>> >>>> >> > >>>> >>>> >> vtkNew renderer; > >>>> >>>> >> renderer->AddVolume(volume.Get()); > >>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); > >>>> >>>> >> > >>>> >>>> >> if (argc > 1) { > >>>> >>>> >> // Render with QVTKOpenGLWidget > >>>> >>>> >> vtkNew window; > >>>> >>>> >> window->AddRenderer(renderer.Get()); > >>>> >>>> >> > >>>> >>>> >> auto widget = new QVTKOpenGLWidget(); > >>>> >>>> >> widget->SetRenderWindow(window.Get()); > >>>> >>>> >> widget->show(); > >>>> >>>> >> > >>>> >>>> >> return app.exec(); > >>>> >>>> >> } else { > >>>> >>>> >> // Render with "plain" render window / interactor > >>>> >>>> >> vtkNew window; > >>>> >>>> >> window->AddRenderer(renderer.Get()); > >>>> >>>> >> > >>>> >>>> >> vtkNew interactor; > >>>> >>>> >> interactor->SetRenderWindow(window.Get()); > >>>> >>>> >> interactor->Start(); > >>>> >>>> >> > >>>> >>>> >> return 0; > >>>> >>>> >> } > >>>> >>>> >> } > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> CMakeLists.txt: > >>>> >>>> >> > >>>> >>>> >> cmake_minimum_required(VERSION 3.1) > >>>> >>>> >> > >>>> >>>> >> project(TestCase) > >>>> >>>> >> > >>>> >>>> >> find_package(VTK 8.0 COMPONENTS > >>>> >>>> >> vtkCommonCore > >>>> >>>> >> vtkCommonDataModel > >>>> >>>> >> vtkCommonExecutionModel > >>>> >>>> >> vtkCommonMath > >>>> >>>> >> vtkFiltersSources > >>>> >>>> >> vtkGUISupportQt > >>>> >>>> >> vtkInteractionStyle > >>>> >>>> >> vtkRenderingCore > >>>> >>>> >> vtkRenderingOpenGL2 > >>>> >>>> >> vtkRenderingVolume > >>>> >>>> >> vtkRenderingVolumeOpenGL2 > >>>> >>>> >> REQUIRED > >>>> >>>> >> ) > >>>> >>>> >> > >>>> >>>> >> find_package(Qt5Widgets REQUIRED) > >>>> >>>> >> > >>>> >>>> >> add_executable(TestCase main.cpp) > >>>> >>>> >> > >>>> >>>> >> target_link_libraries(TestCase PUBLIC > >>>> >>>> >> vtkCommonCore > >>>> >>>> >> vtkCommonDataModel > >>>> >>>> >> vtkCommonExecutionModel > >>>> >>>> >> vtkCommonMath > >>>> >>>> >> vtkFiltersSources > >>>> >>>> >> vtkGUISupportQt > >>>> >>>> >> vtkInteractionStyle > >>>> >>>> >> vtkRenderingCore > >>>> >>>> >> vtkRenderingOpenGL2 > >>>> >>>> >> vtkRenderingVolume > >>>> >>>> >> vtkRenderingVolumeOpenGL2 > >>>> >>>> >> Qt5::Widgets > >>>> >>>> >> ) > >>>> >>>> >> > >>>> >>>> >> target_include_directories(TestCase PUBLIC > >>>> >>>> >> ${VTK_INCLUDE_DIRS} > >>>> >>>> >> ) > >>>> >>>> >> > >>>> >>>> >> target_compile_definitions(TestCase PUBLIC > >>>> >>>> >> ${VTK_DEFINITIONS} > >>>> >>>> >> ) > >>>> >>>> >> > >>>> >>>> >> set_target_properties(TestCase PROPERTIES > >>>> >>>> >> CXX_STANDARD 14 > >>>> >>>> >> CXX_STANDARD_REQUIRED ON > >>>> >>>> >> ) > >>>> >>>> >> _______________________________________________ > >>>> >>>> >> 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: > >>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>> >>>> >> > >>>> >>>> > -- > >>>> >>>> > > >>>> >>>> > Sankhesh Jhaveri > >>>> >>>> > > >>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >>>> >>> > >>>> >>> -- > >>>> >>> > >>>> >>> Sankhesh Jhaveri > >>>> >>> > >>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >>>> >> > >>>> >> -- > >>>> >> > >>>> >> Sankhesh Jhaveri > >>>> >> > >>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >>>> _______________________________________________ > >>>> 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: > >>>> http://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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu May 25 17:01:48 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 25 May 2017 23:01:48 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-25 21:09 GMT+02:00 Aron Helser : > No I did not, but I just tried it again, adding the "1" argument, and I > still get no repro. Running either with Intel or nvidia shows the volume > just fine. Alright, thanks for double-checking. Elvis > > On Thu, May 25, 2017 at 2:35 PM, Elvis Stansvik > wrote: >> >> 2017-05-25 18:14 GMT+02:00 David Cole : >> > Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> > with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I >> > get your TestCase app window with nothing but an empty (white) client >> > region. >> > >> > An app we have built against VTK 6.2-ish with the old OpenGL using >> > VolumeSmartMapper works fine on this very same machine. >> > >> > Another data point... >> >> Finally a reproduction, I was beginning to despair :) Thanks a lot David. >> >> And just to make sure, Aron, did you run the test case as "TestCase >> 1", with a parameter? That's the crucial thing, as otherwise it'll >> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> QVTKOpenGLWidget), and not exhibit the problem. >> >> Elvis >> >> > >> > >> > D >> > >> > >> > >> > >> > On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> > wrote: >> >> 2017-05-25 16:22 GMT+02:00 Aron Helser : >> >>> Hi Elvis, >> >>> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - >> >>> both >> >>> intel and nvidia graphics. >> >>> With your test case, I'm able to see the volume running either with >> >>> Intel or >> >>> nVidia, so it doesn't repro for me. >> >>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> >>> Sorry, >> >>> Aron >> >> >> >> Alright, bugger. Thanks for testing though! >> >> >> >> I won't be at the office until Monday again, but when I'm back I'll >> >> try experimenting with different driver versions. >> >> >> >> Elvis >> >> >> >>> >> >>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >>> wrote: >> >>>> >> >>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >>>> : >> >>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >>>> > : >> >>>> >> Hi Elvis, >> >>>> >> >> >>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >>>> >> >> >>>> >> I don?t have a Windows machine with an Intel graphics card but >> >>>> >> tried >> >>>> >> ParaView on a couple of se Windows machines as well as a Mac (with >> >>>> >> an >> >>>> >> Intel >> >>>> >> HD5600). Worked fine. >> >>>> > >> >>>> > Alright. Call for help then: Anyone else have a Windows 7 machine >> >>>> > with >> >>>> > Intel graphics? Would be great if someone could reproduce. >> >>>> >> >>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >>>> >> >>>> I've now put up the compiled self-contained test case here: >> >>>> >> >>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >>>> >> >>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >> >>>> graphics could try running this test case with "TestCase 1" and see >> >>>> if >> >>>> the volume shows up, that would be great. >> >>>> >> >>>> (Running the test case with argc > 2 will make it use >> >>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >>>> >> >>>> Elvis >> >>>> >> >>>> > >> >>>> > I could put up my build of the test case as a self-contained .zip, >> >>>> > to >> >>>> > make it easy to test. >> >>>> > >> >>>> >> >> >>>> >> At this point, I am inclined to think that the graphics drivers on >> >>>> >> your >> >>>> >> Windows machine may need updating. >> >>>> > >> >>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use >> >>>> > a >> >>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >> >>>> > suggest that the drivers are capable enough, and that the problem >> >>>> > is >> >>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >>>> > >> >>>> > Elvis >> >>>> > >> >>>> >> >> >>>> >> >> >>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >>>> >> wrote: >> >>>> >>> >> >>>> >>> Okay thanks. >> >>>> >>> >> >>>> >>> I?ll take a look. >> >>>> >>> >> >>>> >>> >> >>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >>>> >>> wrote: >> >>>> >>>> >> >>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >>>> >>>> : >> >>>> >>>> > Hi Elvis, >> >>>> >>>> > >> >>>> >>>> > Could you try downloading the ParaView nightly binary and test >> >>>> >>>> > volume >> >>>> >>>> > rendering there? You can use the wavelet source for a test >> >>>> >>>> > dataset. >> >>>> >>>> > ParaView >> >>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before >> >>>> >>>> > diving >> >>>> >>>> > into the >> >>>> >>>> > code. >> >>>> >>>> >> >>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >> >>>> >>>> 64-bit, and the problem is the same as in my minimal test case. >> >>>> >>>> The >> >>>> >>>> volume won't show up. >> >>>> >>>> >> >>>> >>>> It does show up if I switch to the software based ray cast >> >>>> >>>> mapper >> >>>> >>>> (but >> >>>> >>>> not with GPU or smart, which I guess both result in the GPU one >> >>>> >>>> being >> >>>> >>>> used). >> >>>> >>>> >> >>>> >>>> Please tell me if there's anything else I can do to help >> >>>> >>>> debugging. >> >>>> >>>> There are no errors printed when I run my test case. >> >>>> >>>> >> >>>> >>>> Elvis >> >>>> >>>> >> >>>> >>>> > >> >>>> >>>> > Thanks, >> >>>> >>>> > Sankhesh >> >>>> >>>> > >> >>>> >>>> > >> >>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >>>> >>>> > wrote: >> >>>> >>>> >> >> >>>> >>>> >> Hi all, >> >>>> >>>> >> >> >>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered >> >>>> >>>> >> using >> >>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel >> >>>> >>>> >> graphics >> >>>> >>>> >> (HD >> >>>> >>>> >> 4600). They show up fine on Linux. They also show up fine on >> >>>> >>>> >> Windows 7 >> >>>> >>>> >> if using a plain VTK render window. I've tried turning off >> >>>> >>>> >> multisampling with setSamples(0) on the default >> >>>> >>>> >> QSurfaceFormat. >> >>>> >>>> >> >> >>>> >>>> >> The below test case illustrates the issue. See the attached >> >>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >> >>>> >>>> >> (right). >> >>>> >>>> >> The former uses a plain render window while the latter uses >> >>>> >>>> >> the >> >>>> >>>> >> new >> >>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >> >>>> >>>> >> plain >> >>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >> >>>> >>>> >> showing >> >>>> >>>> >> the volume. >> >>>> >>>> >> >> >>>> >>>> >> Versions used: >> >>>> >>>> >> >> >>>> >>>> >> Kubuntu Linux 16.04 >> >>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>> >>>> >> Qt 5.5.1 >> >>>> >>>> >> >> >>>> >>>> >> Windows 7 >> >>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>> >>>> >> Qt 5.6.2 >> >>>> >>>> >> >> >>>> >>>> >> Any ideas what the problem might be? >> >>>> >>>> >> >> >>>> >>>> >> I can provide a standalone .zip distribution of my build of >> >>>> >>>> >> the >> >>>> >>>> >> test >> >>>> >>>> >> case if you want. >> >>>> >>>> >> >> >>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >> >>>> >>>> >> reported >> >>>> >>>> >> and >> >>>> >>>> >> got solved in my other thread. >> >>>> >>>> >> >> >>>> >>>> >> Many thanks in advance, >> >>>> >>>> >> Elvis >> >>>> >>>> >> >> >>>> >>>> >> >> >>>> >>>> >> main.cpp: >> >>>> >>>> >> >> >>>> >>>> >> #include >> >>>> >>>> >> >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> #include >> >>>> >>>> >> >> >>>> >>>> >> #include >> >>>> >>>> >> >> >>>> >>>> >> #include >> >>>> >>>> >> >> >>>> >>>> >> int main(int argc, char *argv[]) >> >>>> >>>> >> { >> >>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >> >>>> >>>> >> defaultFormat.setSamples(0); >> >>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >>>> >>>> >> >> >>>> >>>> >> QApplication app(argc, argv); >> >>>> >>>> >> >> >>>> >>>> >> // Set up volume rendering >> >>>> >>>> >> vtkNew colorFunction; >> >>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew opacityFunction; >> >>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew imageData; >> >>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >>>> >>>> >> std::fill_n(static_cast> >>>> >>>> >> *>(imageData->GetScalarPointer()), >> >>>> >>>> >> 8000000, 0.01); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew volumeMapper; >> >>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew volumeProperty; >> >>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >>>> >>>> >> volumeProperty->ShadeOff(); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew volume; >> >>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew renderer; >> >>>> >>>> >> renderer->AddVolume(volume.Get()); >> >>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >>>> >>>> >> >> >>>> >>>> >> if (argc > 1) { >> >>>> >>>> >> // Render with QVTKOpenGLWidget >> >>>> >>>> >> vtkNew window; >> >>>> >>>> >> window->AddRenderer(renderer.Get()); >> >>>> >>>> >> >> >>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >>>> >>>> >> widget->show(); >> >>>> >>>> >> >> >>>> >>>> >> return app.exec(); >> >>>> >>>> >> } else { >> >>>> >>>> >> // Render with "plain" render window / interactor >> >>>> >>>> >> vtkNew window; >> >>>> >>>> >> window->AddRenderer(renderer.Get()); >> >>>> >>>> >> >> >>>> >>>> >> vtkNew interactor; >> >>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >>>> >>>> >> interactor->Start(); >> >>>> >>>> >> >> >>>> >>>> >> return 0; >> >>>> >>>> >> } >> >>>> >>>> >> } >> >>>> >>>> >> >> >>>> >>>> >> >> >>>> >>>> >> CMakeLists.txt: >> >>>> >>>> >> >> >>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >>>> >>>> >> >> >>>> >>>> >> project(TestCase) >> >>>> >>>> >> >> >>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >>>> >>>> >> vtkCommonCore >> >>>> >>>> >> vtkCommonDataModel >> >>>> >>>> >> vtkCommonExecutionModel >> >>>> >>>> >> vtkCommonMath >> >>>> >>>> >> vtkFiltersSources >> >>>> >>>> >> vtkGUISupportQt >> >>>> >>>> >> vtkInteractionStyle >> >>>> >>>> >> vtkRenderingCore >> >>>> >>>> >> vtkRenderingOpenGL2 >> >>>> >>>> >> vtkRenderingVolume >> >>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>> >>>> >> REQUIRED >> >>>> >>>> >> ) >> >>>> >>>> >> >> >>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >>>> >>>> >> >> >>>> >>>> >> add_executable(TestCase main.cpp) >> >>>> >>>> >> >> >>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >>>> >>>> >> vtkCommonCore >> >>>> >>>> >> vtkCommonDataModel >> >>>> >>>> >> vtkCommonExecutionModel >> >>>> >>>> >> vtkCommonMath >> >>>> >>>> >> vtkFiltersSources >> >>>> >>>> >> vtkGUISupportQt >> >>>> >>>> >> vtkInteractionStyle >> >>>> >>>> >> vtkRenderingCore >> >>>> >>>> >> vtkRenderingOpenGL2 >> >>>> >>>> >> vtkRenderingVolume >> >>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>> >>>> >> Qt5::Widgets >> >>>> >>>> >> ) >> >>>> >>>> >> >> >>>> >>>> >> target_include_directories(TestCase PUBLIC >> >>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >>>> >>>> >> ) >> >>>> >>>> >> >> >>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >>>> >>>> >> ${VTK_DEFINITIONS} >> >>>> >>>> >> ) >> >>>> >>>> >> >> >>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >>>> >>>> >> CXX_STANDARD 14 >> >>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >>>> >>>> >> ) >> >>>> >>>> >> _______________________________________________ >> >>>> >>>> >> 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: >> >>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>> >>>> >> >> >>>> >>>> > -- >> >>>> >>>> > >> >>>> >>>> > Sankhesh Jhaveri >> >>>> >>>> > >> >>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>> >>> >> >>>> >>> -- >> >>>> >>> >> >>>> >>> Sankhesh Jhaveri >> >>>> >>> >> >>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>> >> >> >>>> >> -- >> >>>> >> >> >>>> >> Sankhesh Jhaveri >> >>>> >> >> >>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>> _______________________________________________ >> >>>> 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: >> >>>> http://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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > From elvis.stansvik at orexplore.com Thu May 25 17:11:32 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 25 May 2017 23:11:32 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-25 20:35 GMT+02:00 Elvis Stansvik : > 2017-05-25 18:14 GMT+02:00 David Cole : >> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I >> get your TestCase app window with nothing but an empty (white) client >> region. >> >> An app we have built against VTK 6.2-ish with the old OpenGL using >> VolumeSmartMapper works fine on this very same machine. >> >> Another data point... Just one more thing David, did you try also running the example without any argument on this machine? (That would make it use a regular vtkRenderWindow/vtkRenderWindowInteractor). It would be interesting to know if the volume shows up then. That would confirm that the machine can show volumes using VTK 8+OpenGL2 backend, just not with QVTKOpenGLWidget, so would strengthen my theory that it has something to do with the new QVTKOpenGLWidget. Elvis > > Finally a reproduction, I was beginning to despair :) Thanks a lot David. > > And just to make sure, Aron, did you run the test case as "TestCase > 1", with a parameter? That's the crucial thing, as otherwise it'll > just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not > QVTKOpenGLWidget), and not exhibit the problem. > > Elvis > >> >> >> D >> >> >> >> >> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> wrote: >>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>>> Hi Elvis, >>>> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both >>>> intel and nvidia graphics. >>>> With your test case, I'm able to see the volume running either with Intel or >>>> nVidia, so it doesn't repro for me. >>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >>>> Sorry, >>>> Aron >>> >>> Alright, bugger. Thanks for testing though! >>> >>> I won't be at the office until Monday again, but when I'm back I'll >>> try experimenting with different driver versions. >>> >>> Elvis >>> >>>> >>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>>> wrote: >>>>> >>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : >>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>>>> > : >>>>> >> Hi Elvis, >>>>> >> >>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>>>> >> >>>>> >> I don?t have a Windows machine with an Intel graphics card but tried >>>>> >> ParaView on a couple of se Windows machines as well as a Mac (with an >>>>> >> Intel >>>>> >> HD5600). Worked fine. >>>>> > >>>>> > Alright. Call for help then: Anyone else have a Windows 7 machine with >>>>> > Intel graphics? Would be great if someone could reproduce. >>>>> >>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>>>> >>>>> I've now put up the compiled self-contained test case here: >>>>> >>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>>>> >>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >>>>> graphics could try running this test case with "TestCase 1" and see if >>>>> the volume shows up, that would be great. >>>>> >>>>> (Running the test case with argc > 2 will make it use >>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>>>> >>>>> Elvis >>>>> >>>>> > >>>>> > I could put up my build of the test case as a self-contained .zip, to >>>>> > make it easy to test. >>>>> > >>>>> >> >>>>> >> At this point, I am inclined to think that the graphics drivers on your >>>>> >> Windows machine may need updating. >>>>> > >>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a >>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >>>>> > suggest that the drivers are capable enough, and that the problem is >>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>>>> > >>>>> > Elvis >>>>> > >>>>> >> >>>>> >> >>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>>>> >> wrote: >>>>> >>> >>>>> >>> Okay thanks. >>>>> >>> >>>>> >>> I?ll take a look. >>>>> >>> >>>>> >>> >>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>>>> >>> wrote: >>>>> >>>> >>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>>>> >>>> : >>>>> >>>> > Hi Elvis, >>>>> >>>> > >>>>> >>>> > Could you try downloading the ParaView nightly binary and test >>>>> >>>> > volume >>>>> >>>> > rendering there? You can use the wavelet source for a test dataset. >>>>> >>>> > ParaView >>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>>>> >>>> > into the >>>>> >>>> > code. >>>>> >>>> >>>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>>>> >>>> 64-bit, and the problem is the same as in my minimal test case. The >>>>> >>>> volume won't show up. >>>>> >>>> >>>>> >>>> It does show up if I switch to the software based ray cast mapper >>>>> >>>> (but >>>>> >>>> not with GPU or smart, which I guess both result in the GPU one being >>>>> >>>> used). >>>>> >>>> >>>>> >>>> Please tell me if there's anything else I can do to help debugging. >>>>> >>>> There are no errors printed when I run my test case. >>>>> >>>> >>>>> >>>> Elvis >>>>> >>>> >>>>> >>>> > >>>>> >>>> > Thanks, >>>>> >>>> > Sankhesh >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>>>> >>>> > wrote: >>>>> >>>> >> >>>>> >>>> >> Hi all, >>>>> >>>> >> >>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics >>>>> >>>> >> (HD >>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine on >>>>> >>>> >> Windows 7 >>>>> >>>> >> if using a plain VTK render window. I've tried turning off >>>>> >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>>>> >>>> >> >>>>> >>>> >> The below test case illustrates the issue. See the attached >>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >>>>> >>>> >> (right). >>>>> >>>> >> The former uses a plain render window while the latter uses the >>>>> >>>> >> new >>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >>>>> >>>> >> plain >>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >>>>> >>>> >> showing >>>>> >>>> >> the volume. >>>>> >>>> >> >>>>> >>>> >> Versions used: >>>>> >>>> >> >>>>> >>>> >> Kubuntu Linux 16.04 >>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>>> >>>> >> Qt 5.5.1 >>>>> >>>> >> >>>>> >>>> >> Windows 7 >>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>>> >>>> >> Qt 5.6.2 >>>>> >>>> >> >>>>> >>>> >> Any ideas what the problem might be? >>>>> >>>> >> >>>>> >>>> >> I can provide a standalone .zip distribution of my build of the >>>>> >>>> >> test >>>>> >>>> >> case if you want. >>>>> >>>> >> >>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I reported >>>>> >>>> >> and >>>>> >>>> >> got solved in my other thread. >>>>> >>>> >> >>>>> >>>> >> Many thanks in advance, >>>>> >>>> >> Elvis >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> main.cpp: >>>>> >>>> >> >>>>> >>>> >> #include >>>>> >>>> >> >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> #include >>>>> >>>> >> >>>>> >>>> >> #include >>>>> >>>> >> >>>>> >>>> >> #include >>>>> >>>> >> >>>>> >>>> >> int main(int argc, char *argv[]) >>>>> >>>> >> { >>>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>>>> >>>> >> defaultFormat.setSamples(0); >>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>>>> >>>> >> >>>>> >>>> >> QApplication app(argc, argv); >>>>> >>>> >> >>>>> >>>> >> // Set up volume rendering >>>>> >>>> >> vtkNew colorFunction; >>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>>>> >>>> >> >>>>> >>>> >> vtkNew opacityFunction; >>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>>>> >>>> >> >>>>> >>>> >> vtkNew imageData; >>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>>>> >>>> >> std::fill_n(static_cast>>>> >>>> >> *>(imageData->GetScalarPointer()), >>>>> >>>> >> 8000000, 0.01); >>>>> >>>> >> >>>>> >>>> >> vtkNew volumeMapper; >>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>>>> >>>> >> >>>>> >>>> >> vtkNew volumeProperty; >>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>>>> >>>> >> volumeProperty->ShadeOff(); >>>>> >>>> >> >>>>> >>>> >> vtkNew volume; >>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>>>> >>>> >> >>>>> >>>> >> vtkNew renderer; >>>>> >>>> >> renderer->AddVolume(volume.Get()); >>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>>>> >>>> >> >>>>> >>>> >> if (argc > 1) { >>>>> >>>> >> // Render with QVTKOpenGLWidget >>>>> >>>> >> vtkNew window; >>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>>> >>>> >> >>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>>>> >>>> >> widget->show(); >>>>> >>>> >> >>>>> >>>> >> return app.exec(); >>>>> >>>> >> } else { >>>>> >>>> >> // Render with "plain" render window / interactor >>>>> >>>> >> vtkNew window; >>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>>> >>>> >> >>>>> >>>> >> vtkNew interactor; >>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>>>> >>>> >> interactor->Start(); >>>>> >>>> >> >>>>> >>>> >> return 0; >>>>> >>>> >> } >>>>> >>>> >> } >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> CMakeLists.txt: >>>>> >>>> >> >>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>>>> >>>> >> >>>>> >>>> >> project(TestCase) >>>>> >>>> >> >>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>>>> >>>> >> vtkCommonCore >>>>> >>>> >> vtkCommonDataModel >>>>> >>>> >> vtkCommonExecutionModel >>>>> >>>> >> vtkCommonMath >>>>> >>>> >> vtkFiltersSources >>>>> >>>> >> vtkGUISupportQt >>>>> >>>> >> vtkInteractionStyle >>>>> >>>> >> vtkRenderingCore >>>>> >>>> >> vtkRenderingOpenGL2 >>>>> >>>> >> vtkRenderingVolume >>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>>> >>>> >> REQUIRED >>>>> >>>> >> ) >>>>> >>>> >> >>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>>>> >>>> >> >>>>> >>>> >> add_executable(TestCase main.cpp) >>>>> >>>> >> >>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>>>> >>>> >> vtkCommonCore >>>>> >>>> >> vtkCommonDataModel >>>>> >>>> >> vtkCommonExecutionModel >>>>> >>>> >> vtkCommonMath >>>>> >>>> >> vtkFiltersSources >>>>> >>>> >> vtkGUISupportQt >>>>> >>>> >> vtkInteractionStyle >>>>> >>>> >> vtkRenderingCore >>>>> >>>> >> vtkRenderingOpenGL2 >>>>> >>>> >> vtkRenderingVolume >>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>>> >>>> >> Qt5::Widgets >>>>> >>>> >> ) >>>>> >>>> >> >>>>> >>>> >> target_include_directories(TestCase PUBLIC >>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>>>> >>>> >> ) >>>>> >>>> >> >>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>>>> >>>> >> ${VTK_DEFINITIONS} >>>>> >>>> >> ) >>>>> >>>> >> >>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>>>> >>>> >> CXX_STANDARD 14 >>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>>>> >>>> >> ) >>>>> >>>> >> _______________________________________________ >>>>> >>>> >> 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: >>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>> >> >>>>> >>>> > -- >>>>> >>>> > >>>>> >>>> > Sankhesh Jhaveri >>>>> >>>> > >>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>> >>> >>>>> >>> -- >>>>> >>> >>>>> >>> Sankhesh Jhaveri >>>>> >>> >>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>> >> >>>>> >> -- >>>>> >> >>>>> >> Sankhesh Jhaveri >>>>> >> >>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>> _______________________________________________ >>>>> 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: >>>>> http://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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> From DLRdave at aol.com Thu May 25 17:37:22 2017 From: DLRdave at aol.com (David Cole) Date: Thu, 25 May 2017 17:37:22 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Yes, I ran it both ways. It works when run without the argument in the plain VTK render window, and it is broken (shows nothing) when run with an argument. Seems like it's definitely related to older Intel drivers on Windows. Not sure if there is an updated driver available for my machine. Hesitant to try changing/updating it for other reasons, and sorry, can't sacrifice this machine's current state for the purpose of testing this out... D On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik wrote: > 2017-05-25 20:35 GMT+02:00 Elvis Stansvik : >> 2017-05-25 18:14 GMT+02:00 David Cole : >>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >>> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I >>> get your TestCase app window with nothing but an empty (white) client >>> region. >>> >>> An app we have built against VTK 6.2-ish with the old OpenGL using >>> VolumeSmartMapper works fine on this very same machine. >>> >>> Another data point... > > Just one more thing David, did you try also running the example > without any argument on this machine? (That would make it use a > regular vtkRenderWindow/vtkRenderWindowInteractor). It would be > interesting to know if the volume shows up then. That would confirm > that the machine can show volumes using VTK 8+OpenGL2 backend, just > not with QVTKOpenGLWidget, so would strengthen my theory that it has > something to do with the new QVTKOpenGLWidget. > > Elvis > >> >> Finally a reproduction, I was beginning to despair :) Thanks a lot David. >> >> And just to make sure, Aron, did you run the test case as "TestCase >> 1", with a parameter? That's the crucial thing, as otherwise it'll >> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> QVTKOpenGLWidget), and not exhibit the problem. >> >> Elvis >> >>> >>> >>> D >>> >>> >>> >>> >>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >>> wrote: >>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>>>> Hi Elvis, >>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both >>>>> intel and nvidia graphics. >>>>> With your test case, I'm able to see the volume running either with Intel or >>>>> nVidia, so it doesn't repro for me. >>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >>>>> Sorry, >>>>> Aron >>>> >>>> Alright, bugger. Thanks for testing though! >>>> >>>> I won't be at the office until Monday again, but when I'm back I'll >>>> try experimenting with different driver versions. >>>> >>>> Elvis >>>> >>>>> >>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>>>> wrote: >>>>>> >>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : >>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>>>>> > : >>>>>> >> Hi Elvis, >>>>>> >> >>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>>>>> >> >>>>>> >> I don?t have a Windows machine with an Intel graphics card but tried >>>>>> >> ParaView on a couple of se Windows machines as well as a Mac (with an >>>>>> >> Intel >>>>>> >> HD5600). Worked fine. >>>>>> > >>>>>> > Alright. Call for help then: Anyone else have a Windows 7 machine with >>>>>> > Intel graphics? Would be great if someone could reproduce. >>>>>> >>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>>>>> >>>>>> I've now put up the compiled self-contained test case here: >>>>>> >>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>>>>> >>>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >>>>>> graphics could try running this test case with "TestCase 1" and see if >>>>>> the volume shows up, that would be great. >>>>>> >>>>>> (Running the test case with argc > 2 will make it use >>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>>>>> >>>>>> Elvis >>>>>> >>>>>> > >>>>>> > I could put up my build of the test case as a self-contained .zip, to >>>>>> > make it easy to test. >>>>>> > >>>>>> >> >>>>>> >> At this point, I am inclined to think that the graphics drivers on your >>>>>> >> Windows machine may need updating. >>>>>> > >>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a >>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >>>>>> > suggest that the drivers are capable enough, and that the problem is >>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>>>>> > >>>>>> > Elvis >>>>>> > >>>>>> >> >>>>>> >> >>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>>>>> >> wrote: >>>>>> >>> >>>>>> >>> Okay thanks. >>>>>> >>> >>>>>> >>> I?ll take a look. >>>>>> >>> >>>>>> >>> >>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>>>>> >>> wrote: >>>>>> >>>> >>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>>>>> >>>> : >>>>>> >>>> > Hi Elvis, >>>>>> >>>> > >>>>>> >>>> > Could you try downloading the ParaView nightly binary and test >>>>>> >>>> > volume >>>>>> >>>> > rendering there? You can use the wavelet source for a test dataset. >>>>>> >>>> > ParaView >>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>>>>> >>>> > into the >>>>>> >>>> > code. >>>>>> >>>> >>>>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>>>>> >>>> 64-bit, and the problem is the same as in my minimal test case. The >>>>>> >>>> volume won't show up. >>>>>> >>>> >>>>>> >>>> It does show up if I switch to the software based ray cast mapper >>>>>> >>>> (but >>>>>> >>>> not with GPU or smart, which I guess both result in the GPU one being >>>>>> >>>> used). >>>>>> >>>> >>>>>> >>>> Please tell me if there's anything else I can do to help debugging. >>>>>> >>>> There are no errors printed when I run my test case. >>>>>> >>>> >>>>>> >>>> Elvis >>>>>> >>>> >>>>>> >>>> > >>>>>> >>>> > Thanks, >>>>>> >>>> > Sankhesh >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>>>>> >>>> > wrote: >>>>>> >>>> >> >>>>>> >>>> >> Hi all, >>>>>> >>>> >> >>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics >>>>>> >>>> >> (HD >>>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine on >>>>>> >>>> >> Windows 7 >>>>>> >>>> >> if using a plain VTK render window. I've tried turning off >>>>>> >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>>>>> >>>> >> >>>>>> >>>> >> The below test case illustrates the issue. See the attached >>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >>>>>> >>>> >> (right). >>>>>> >>>> >> The former uses a plain render window while the latter uses the >>>>>> >>>> >> new >>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >>>>>> >>>> >> plain >>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >>>>>> >>>> >> showing >>>>>> >>>> >> the volume. >>>>>> >>>> >> >>>>>> >>>> >> Versions used: >>>>>> >>>> >> >>>>>> >>>> >> Kubuntu Linux 16.04 >>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>>>> >>>> >> Qt 5.5.1 >>>>>> >>>> >> >>>>>> >>>> >> Windows 7 >>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>>>> >>>> >> Qt 5.6.2 >>>>>> >>>> >> >>>>>> >>>> >> Any ideas what the problem might be? >>>>>> >>>> >> >>>>>> >>>> >> I can provide a standalone .zip distribution of my build of the >>>>>> >>>> >> test >>>>>> >>>> >> case if you want. >>>>>> >>>> >> >>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I reported >>>>>> >>>> >> and >>>>>> >>>> >> got solved in my other thread. >>>>>> >>>> >> >>>>>> >>>> >> Many thanks in advance, >>>>>> >>>> >> Elvis >>>>>> >>>> >> >>>>>> >>>> >> >>>>>> >>>> >> main.cpp: >>>>>> >>>> >> >>>>>> >>>> >> #include >>>>>> >>>> >> >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> #include >>>>>> >>>> >> >>>>>> >>>> >> #include >>>>>> >>>> >> >>>>>> >>>> >> #include >>>>>> >>>> >> >>>>>> >>>> >> int main(int argc, char *argv[]) >>>>>> >>>> >> { >>>>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>>>>> >>>> >> defaultFormat.setSamples(0); >>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>>>>> >>>> >> >>>>>> >>>> >> QApplication app(argc, argv); >>>>>> >>>> >> >>>>>> >>>> >> // Set up volume rendering >>>>>> >>>> >> vtkNew colorFunction; >>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew opacityFunction; >>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew imageData; >>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>>>>> >>>> >> std::fill_n(static_cast>>>>> >>>> >> *>(imageData->GetScalarPointer()), >>>>>> >>>> >> 8000000, 0.01); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew volumeMapper; >>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew volumeProperty; >>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>>>>> >>>> >> volumeProperty->ShadeOff(); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew volume; >>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew renderer; >>>>>> >>>> >> renderer->AddVolume(volume.Get()); >>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>>>>> >>>> >> >>>>>> >>>> >> if (argc > 1) { >>>>>> >>>> >> // Render with QVTKOpenGLWidget >>>>>> >>>> >> vtkNew window; >>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>>>> >>>> >> >>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>>>>> >>>> >> widget->show(); >>>>>> >>>> >> >>>>>> >>>> >> return app.exec(); >>>>>> >>>> >> } else { >>>>>> >>>> >> // Render with "plain" render window / interactor >>>>>> >>>> >> vtkNew window; >>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>>>> >>>> >> >>>>>> >>>> >> vtkNew interactor; >>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>>>>> >>>> >> interactor->Start(); >>>>>> >>>> >> >>>>>> >>>> >> return 0; >>>>>> >>>> >> } >>>>>> >>>> >> } >>>>>> >>>> >> >>>>>> >>>> >> >>>>>> >>>> >> CMakeLists.txt: >>>>>> >>>> >> >>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>>>>> >>>> >> >>>>>> >>>> >> project(TestCase) >>>>>> >>>> >> >>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>>>>> >>>> >> vtkCommonCore >>>>>> >>>> >> vtkCommonDataModel >>>>>> >>>> >> vtkCommonExecutionModel >>>>>> >>>> >> vtkCommonMath >>>>>> >>>> >> vtkFiltersSources >>>>>> >>>> >> vtkGUISupportQt >>>>>> >>>> >> vtkInteractionStyle >>>>>> >>>> >> vtkRenderingCore >>>>>> >>>> >> vtkRenderingOpenGL2 >>>>>> >>>> >> vtkRenderingVolume >>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>>>> >>>> >> REQUIRED >>>>>> >>>> >> ) >>>>>> >>>> >> >>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>>>>> >>>> >> >>>>>> >>>> >> add_executable(TestCase main.cpp) >>>>>> >>>> >> >>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>>>>> >>>> >> vtkCommonCore >>>>>> >>>> >> vtkCommonDataModel >>>>>> >>>> >> vtkCommonExecutionModel >>>>>> >>>> >> vtkCommonMath >>>>>> >>>> >> vtkFiltersSources >>>>>> >>>> >> vtkGUISupportQt >>>>>> >>>> >> vtkInteractionStyle >>>>>> >>>> >> vtkRenderingCore >>>>>> >>>> >> vtkRenderingOpenGL2 >>>>>> >>>> >> vtkRenderingVolume >>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>>>> >>>> >> Qt5::Widgets >>>>>> >>>> >> ) >>>>>> >>>> >> >>>>>> >>>> >> target_include_directories(TestCase PUBLIC >>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>>>>> >>>> >> ) >>>>>> >>>> >> >>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>>>>> >>>> >> ${VTK_DEFINITIONS} >>>>>> >>>> >> ) >>>>>> >>>> >> >>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>>>>> >>>> >> CXX_STANDARD 14 >>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>>>>> >>>> >> ) >>>>>> >>>> >> _______________________________________________ >>>>>> >>>> >> 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: >>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>> >> >>>>>> >>>> > -- >>>>>> >>>> > >>>>>> >>>> > Sankhesh Jhaveri >>>>>> >>>> > >>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>>> >>> >>>>>> >>> -- >>>>>> >>> >>>>>> >>> Sankhesh Jhaveri >>>>>> >>> >>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>>> >> >>>>>> >> -- >>>>>> >> >>>>>> >> Sankhesh Jhaveri >>>>>> >> >>>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>>> _______________________________________________ >>>>>> 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: >>>>>> http://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: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> From elvis.stansvik at orexplore.com Thu May 25 19:44:11 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 26 May 2017 01:44:11 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-25 23:37 GMT+02:00 David Cole : > Yes, I ran it both ways. > > It works when run without the argument in the plain VTK render window, > and it is broken (shows nothing) when run with an argument. Alright, that's good. Then we're seeing the same thing. > Seems like it's definitely related to older Intel drivers on Windows. Yes, probably. > Not sure if there is an updated driver available for my machine. > Hesitant to try changing/updating it for other reasons, and sorry, > can't sacrifice this machine's current state for the purpose of > testing this out... No worries, I'm free to do as I please with the one I have, so I'll do some experimenting with different drivers when I'm back on Monday. Thanks to everyone trying this out. Elvis > > > D > > > > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik > wrote: >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik : >>> 2017-05-25 18:14 GMT+02:00 David Cole : >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >>>> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I >>>> get your TestCase app window with nothing but an empty (white) client >>>> region. >>>> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >>>> VolumeSmartMapper works fine on this very same machine. >>>> >>>> Another data point... >> >> Just one more thing David, did you try also running the example >> without any argument on this machine? (That would make it use a >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> interesting to know if the volume shows up then. That would confirm >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >> something to do with the new QVTKOpenGLWidget. >> >> Elvis >> >>> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot David. >>> >>> And just to make sure, Aron, did you run the test case as "TestCase >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >>> QVTKOpenGLWidget), and not exhibit the problem. >>> >>> Elvis >>> >>>> >>>> >>>> D >>>> >>>> >>>> >>>> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >>>> wrote: >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>>>>> Hi Elvis, >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus setup - both >>>>>> intel and nvidia graphics. >>>>>> With your test case, I'm able to see the volume running either with Intel or >>>>>> nVidia, so it doesn't repro for me. >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >>>>>> Sorry, >>>>>> Aron >>>>> >>>>> Alright, bugger. Thanks for testing though! >>>>> >>>>> I won't be at the office until Monday again, but when I'm back I'll >>>>> try experimenting with different driver versions. >>>>> >>>>> Elvis >>>>> >>>>>> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>>>>> wrote: >>>>>>> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik : >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>>>>>> > : >>>>>>> >> Hi Elvis, >>>>>>> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>>>>>> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card but tried >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac (with an >>>>>>> >> Intel >>>>>>> >> HD5600). Worked fine. >>>>>>> > >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 machine with >>>>>>> > Intel graphics? Would be great if someone could reproduce. >>>>>>> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>>>>>> >>>>>>> I've now put up the compiled self-contained test case here: >>>>>>> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>>>>>> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >>>>>>> graphics could try running this test case with "TestCase 1" and see if >>>>>>> the volume shows up, that would be great. >>>>>>> >>>>>>> (Running the test case with argc > 2 will make it use >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>>>>>> >>>>>>> Elvis >>>>>>> >>>>>>> > >>>>>>> > I could put up my build of the test case as a self-contained .zip, to >>>>>>> > make it easy to test. >>>>>>> > >>>>>>> >> >>>>>>> >> At this point, I am inclined to think that the graphics drivers on your >>>>>>> >> Windows machine may need updating. >>>>>>> > >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just use a >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >>>>>>> > suggest that the drivers are capable enough, and that the problem is >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>>>>>> > >>>>>>> > Elvis >>>>>>> > >>>>>>> >> >>>>>>> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>>>>>> >> wrote: >>>>>>> >>> >>>>>>> >>> Okay thanks. >>>>>>> >>> >>>>>>> >>> I?ll take a look. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>>>>>> >>> wrote: >>>>>>> >>>> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>>>>>> >>>> : >>>>>>> >>>> > Hi Elvis, >>>>>>> >>>> > >>>>>>> >>>> > Could you try downloading the ParaView nightly binary and test >>>>>>> >>>> > volume >>>>>>> >>>> > rendering there? You can use the wavelet source for a test dataset. >>>>>>> >>>> > ParaView >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test before diving >>>>>>> >>>> > into the >>>>>>> >>>> > code. >>>>>>> >>>> >>>>>>> >>>> I tried the wavelet example with Paraview 5.4.0-RC1-125-g435b603 >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test case. The >>>>>>> >>>> volume won't show up. >>>>>>> >>>> >>>>>>> >>>> It does show up if I switch to the software based ray cast mapper >>>>>>> >>>> (but >>>>>>> >>>> not with GPU or smart, which I guess both result in the GPU one being >>>>>>> >>>> used). >>>>>>> >>>> >>>>>>> >>>> Please tell me if there's anything else I can do to help debugging. >>>>>>> >>>> There are no errors printed when I run my test case. >>>>>>> >>>> >>>>>>> >>>> Elvis >>>>>>> >>>> >>>>>>> >>>> > >>>>>>> >>>> > Thanks, >>>>>>> >>>> > Sankhesh >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>>>>>> >>>> > wrote: >>>>>>> >>>> >> >>>>>>> >>>> >> Hi all, >>>>>>> >>>> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes rendered using >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel graphics >>>>>>> >>>> >> (HD >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine on >>>>>>> >>>> >> Windows 7 >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning off >>>>>>> >>>> >> multisampling with setSamples(0) on the default QSurfaceFormat. >>>>>>> >>>> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the attached >>>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" >>>>>>> >>>> >> (right). >>>>>>> >>>> >> The former uses a plain render window while the latter uses the >>>>>>> >>>> >> new >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, the >>>>>>> >>>> >> plain >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is not >>>>>>> >>>> >> showing >>>>>>> >>>> >> the volume. >>>>>>> >>>> >> >>>>>>> >>>> >> Versions used: >>>>>>> >>>> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>>>>> >>>> >> Qt 5.5.1 >>>>>>> >>>> >> >>>>>>> >>>> >> Windows 7 >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>>>>>> >>>> >> Qt 5.6.2 >>>>>>> >>>> >> >>>>>>> >>>> >> Any ideas what the problem might be? >>>>>>> >>>> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my build of the >>>>>>> >>>> >> test >>>>>>> >>>> >> case if you want. >>>>>>> >>>> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I reported >>>>>>> >>>> >> and >>>>>>> >>>> >> got solved in my other thread. >>>>>>> >>>> >> >>>>>>> >>>> >> Many thanks in advance, >>>>>>> >>>> >> Elvis >>>>>>> >>>> >> >>>>>>> >>>> >> >>>>>>> >>>> >> main.cpp: >>>>>>> >>>> >> >>>>>>> >>>> >> #include >>>>>>> >>>> >> >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> #include >>>>>>> >>>> >> >>>>>>> >>>> >> #include >>>>>>> >>>> >> >>>>>>> >>>> >> #include >>>>>>> >>>> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >>>>>>> >>>> >> { >>>>>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >>>>>>> >>>> >> defaultFormat.setSamples(0); >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>>>>>> >>>> >> >>>>>>> >>>> >> QApplication app(argc, argv); >>>>>>> >>>> >> >>>>>>> >>>> >> // Set up volume rendering >>>>>>> >>>> >> vtkNew colorFunction; >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew opacityFunction; >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew imageData; >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>>>>>> >>>> >> std::fill_n(static_cast>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >>>>>>> >>>> >> 8000000, 0.01); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew volumeMapper; >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew volumeProperty; >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>>>>>> >>>> >> volumeProperty->ShadeOff(); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew volume; >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew renderer; >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>>>>>> >>>> >> >>>>>>> >>>> >> if (argc > 1) { >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >>>>>>> >>>> >> vtkNew window; >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>>>>> >>>> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>>>>>> >>>> >> widget->show(); >>>>>>> >>>> >> >>>>>>> >>>> >> return app.exec(); >>>>>>> >>>> >> } else { >>>>>>> >>>> >> // Render with "plain" render window / interactor >>>>>>> >>>> >> vtkNew window; >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>>>>> >>>> >> >>>>>>> >>>> >> vtkNew interactor; >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>>>>>> >>>> >> interactor->Start(); >>>>>>> >>>> >> >>>>>>> >>>> >> return 0; >>>>>>> >>>> >> } >>>>>>> >>>> >> } >>>>>>> >>>> >> >>>>>>> >>>> >> >>>>>>> >>>> >> CMakeLists.txt: >>>>>>> >>>> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>>>>>> >>>> >> >>>>>>> >>>> >> project(TestCase) >>>>>>> >>>> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>>>>>> >>>> >> vtkCommonCore >>>>>>> >>>> >> vtkCommonDataModel >>>>>>> >>>> >> vtkCommonExecutionModel >>>>>>> >>>> >> vtkCommonMath >>>>>>> >>>> >> vtkFiltersSources >>>>>>> >>>> >> vtkGUISupportQt >>>>>>> >>>> >> vtkInteractionStyle >>>>>>> >>>> >> vtkRenderingCore >>>>>>> >>>> >> vtkRenderingOpenGL2 >>>>>>> >>>> >> vtkRenderingVolume >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>>>>> >>>> >> REQUIRED >>>>>>> >>>> >> ) >>>>>>> >>>> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>>>>>> >>>> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >>>>>>> >>>> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>>>>>> >>>> >> vtkCommonCore >>>>>>> >>>> >> vtkCommonDataModel >>>>>>> >>>> >> vtkCommonExecutionModel >>>>>>> >>>> >> vtkCommonMath >>>>>>> >>>> >> vtkFiltersSources >>>>>>> >>>> >> vtkGUISupportQt >>>>>>> >>>> >> vtkInteractionStyle >>>>>>> >>>> >> vtkRenderingCore >>>>>>> >>>> >> vtkRenderingOpenGL2 >>>>>>> >>>> >> vtkRenderingVolume >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>>>>> >>>> >> Qt5::Widgets >>>>>>> >>>> >> ) >>>>>>> >>>> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>>>>>> >>>> >> ) >>>>>>> >>>> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>>>>>> >>>> >> ${VTK_DEFINITIONS} >>>>>>> >>>> >> ) >>>>>>> >>>> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>>>>>> >>>> >> CXX_STANDARD 14 >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>>>>>> >>>> >> ) >>>>>>> >>>> >> _______________________________________________ >>>>>>> >>>> >> 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: >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>> >>>> >> >>>>>>> >>>> > -- >>>>>>> >>>> > >>>>>>> >>>> > Sankhesh Jhaveri >>>>>>> >>>> > >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> >>>>>>> >>> Sankhesh Jhaveri >>>>>>> >>> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>>>> >> >>>>>>> >> -- >>>>>>> >> >>>>>>> >> Sankhesh Jhaveri >>>>>>> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>>>>>> _______________________________________________ >>>>>>> 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: >>>>>>> http://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: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> From ken.martin at kitware.com Thu May 25 20:24:21 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 25 May 2017 20:24:21 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is a Qt bug we already bumped into with Mesa. They have what looks to me like some odd bad logic on windows for creating a context where they will not give you a core context later than the latest compatibility context they can get. For some vendors that is fine but for others they only offer Comp contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed that the issue would go away. I believe Ben filed a bug report with them (Qt) when he bumped into this when using Mesa on Windows. On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-25 23:37 GMT+02:00 David Cole : > > Yes, I ran it both ways. > > > > It works when run without the argument in the plain VTK render window, > > and it is broken (shows nothing) when run with an argument. > > Alright, that's good. Then we're seeing the same thing. > > > Seems like it's definitely related to older Intel drivers on Windows. > > Yes, probably. > > > Not sure if there is an updated driver available for my machine. > > Hesitant to try changing/updating it for other reasons, and sorry, > > can't sacrifice this machine's current state for the purpose of > > testing this out... > > No worries, I'm free to do as I please with the one I have, so I'll do > some experimenting with different drivers when I'm back on Monday. > > Thanks to everyone trying this out. > > Elvis > > > > > > > D > > > > > > > > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik > > wrote: > >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >: > >>> 2017-05-25 18:14 GMT+02:00 David Cole : > >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, > >>>> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. I > >>>> get your TestCase app window with nothing but an empty (white) client > >>>> region. > >>>> > >>>> An app we have built against VTK 6.2-ish with the old OpenGL using > >>>> VolumeSmartMapper works fine on this very same machine. > >>>> > >>>> Another data point... > >> > >> Just one more thing David, did you try also running the example > >> without any argument on this machine? (That would make it use a > >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be > >> interesting to know if the volume shows up then. That would confirm > >> that the machine can show volumes using VTK 8+OpenGL2 backend, just > >> not with QVTKOpenGLWidget, so would strengthen my theory that it has > >> something to do with the new QVTKOpenGLWidget. > >> > >> Elvis > >> > >>> > >>> Finally a reproduction, I was beginning to despair :) Thanks a lot > David. > >>> > >>> And just to make sure, Aron, did you run the test case as "TestCase > >>> 1", with a parameter? That's the crucial thing, as otherwise it'll > >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not > >>> QVTKOpenGLWidget), and not exhibit the problem. > >>> > >>> Elvis > >>> > >>>> > >>>> > >>>> D > >>>> > >>>> > >>>> > >>>> > >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik > >>>> wrote: > >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : > >>>>>> Hi Elvis, > >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus > setup - both > >>>>>> intel and nvidia graphics. > >>>>>> With your test case, I'm able to see the volume running either with > Intel or > >>>>>> nVidia, so it doesn't repro for me. > >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 > >>>>>> Sorry, > >>>>>> Aron > >>>>> > >>>>> Alright, bugger. Thanks for testing though! > >>>>> > >>>>> I won't be at the office until Monday again, but when I'm back I'll > >>>>> try experimenting with different driver versions. > >>>>> > >>>>> Elvis > >>>>> > >>>>>> > >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik > >>>>>> wrote: > >>>>>>> > >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik < > elvis.stansvik at orexplore.com>: > >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri > >>>>>>> > : > >>>>>>> >> Hi Elvis, > >>>>>>> >> > >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( > >>>>>>> >> > >>>>>>> >> I don?t have a Windows machine with an Intel graphics card but > tried > >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac > (with an > >>>>>>> >> Intel > >>>>>>> >> HD5600). Worked fine. > >>>>>>> > > >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 > machine with > >>>>>>> > Intel graphics? Would be great if someone could reproduce. > >>>>>>> > >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. > >>>>>>> > >>>>>>> I've now put up the compiled self-contained test case here: > >>>>>>> > >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) > >>>>>>> > >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel > >>>>>>> graphics could try running this test case with "TestCase 1" and > see if > >>>>>>> the volume shows up, that would be great. > >>>>>>> > >>>>>>> (Running the test case with argc > 2 will make it use > >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). > >>>>>>> > >>>>>>> Elvis > >>>>>>> > >>>>>>> > > >>>>>>> > I could put up my build of the test case as a self-contained > .zip, to > >>>>>>> > make it easy to test. > >>>>>>> > > >>>>>>> >> > >>>>>>> >> At this point, I am inclined to think that the graphics drivers > on your > >>>>>>> >> Windows machine may need updating. > >>>>>>> > > >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just > use a > >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that > >>>>>>> > suggest that the drivers are capable enough, and that the > problem is > >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > >>>>>>> > > >>>>>>> > Elvis > >>>>>>> > > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > >>>>>>> >> wrote: > >>>>>>> >>> > >>>>>>> >>> Okay thanks. > >>>>>>> >>> > >>>>>>> >>> I?ll take a look. > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik > >>>>>>> >>> wrote: > >>>>>>> >>>> > >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >>>>>>> >>>> : > >>>>>>> >>>> > Hi Elvis, > >>>>>>> >>>> > > >>>>>>> >>>> > Could you try downloading the ParaView nightly binary and > test > >>>>>>> >>>> > volume > >>>>>>> >>>> > rendering there? You can use the wavelet source for a test > dataset. > >>>>>>> >>>> > ParaView > >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test > before diving > >>>>>>> >>>> > into the > >>>>>>> >>>> > code. > >>>>>>> >>>> > >>>>>>> >>>> I tried the wavelet example with Paraview > 5.4.0-RC1-125-g435b603 > >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test > case. The > >>>>>>> >>>> volume won't show up. > >>>>>>> >>>> > >>>>>>> >>>> It does show up if I switch to the software based ray cast > mapper > >>>>>>> >>>> (but > >>>>>>> >>>> not with GPU or smart, which I guess both result in the GPU > one being > >>>>>>> >>>> used). > >>>>>>> >>>> > >>>>>>> >>>> Please tell me if there's anything else I can do to help > debugging. > >>>>>>> >>>> There are no errors printed when I run my test case. > >>>>>>> >>>> > >>>>>>> >>>> Elvis > >>>>>>> >>>> > >>>>>>> >>>> > > >>>>>>> >>>> > Thanks, > >>>>>>> >>>> > Sankhesh > >>>>>>> >>>> > > >>>>>>> >>>> > > >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > >>>>>>> >>>> > wrote: > >>>>>>> >>>> >> > >>>>>>> >>>> >> Hi all, > >>>>>>> >>>> >> > >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes > rendered using > >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel > graphics > >>>>>>> >>>> >> (HD > >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine > on > >>>>>>> >>>> >> Windows 7 > >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning off > >>>>>>> >>>> >> multisampling with setSamples(0) on the default > QSurfaceFormat. > >>>>>>> >>>> >> > >>>>>>> >>>> >> The below test case illustrates the issue. See the attached > >>>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase 1" > >>>>>>> >>>> >> (right). > >>>>>>> >>>> >> The former uses a plain render window while the latter > uses the > >>>>>>> >>>> >> new > >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, > the > >>>>>>> >>>> >> plain > >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is > not > >>>>>>> >>>> >> showing > >>>>>>> >>>> >> the volume. > >>>>>>> >>>> >> > >>>>>>> >>>> >> Versions used: > >>>>>>> >>>> >> > >>>>>>> >>>> >> Kubuntu Linux 16.04 > >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >>>>>>> >>>> >> Qt 5.5.1 > >>>>>>> >>>> >> > >>>>>>> >>>> >> Windows 7 > >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >>>>>>> >>>> >> Qt 5.6.2 > >>>>>>> >>>> >> > >>>>>>> >>>> >> Any ideas what the problem might be? > >>>>>>> >>>> >> > >>>>>>> >>>> >> I can provide a standalone .zip distribution of my build > of the > >>>>>>> >>>> >> test > >>>>>>> >>>> >> case if you want. > >>>>>>> >>>> >> > >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I > reported > >>>>>>> >>>> >> and > >>>>>>> >>>> >> got solved in my other thread. > >>>>>>> >>>> >> > >>>>>>> >>>> >> Many thanks in advance, > >>>>>>> >>>> >> Elvis > >>>>>>> >>>> >> > >>>>>>> >>>> >> > >>>>>>> >>>> >> main.cpp: > >>>>>>> >>>> >> > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> > >>>>>>> >>>> >> #include > >>>>>>> >>>> >> > >>>>>>> >>>> >> int main(int argc, char *argv[]) > >>>>>>> >>>> >> { > >>>>>>> >>>> >> auto defaultFormat = QVTKOpenGLWidget:: > defaultFormat(); > >>>>>>> >>>> >> defaultFormat.setSamples(0); > >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); > >>>>>>> >>>> >> > >>>>>>> >>>> >> QApplication app(argc, argv); > >>>>>>> >>>> >> > >>>>>>> >>>> >> // Set up volume rendering > >>>>>>> >>>> >> vtkNew colorFunction; > >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew opacityFunction; > >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); > >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew imageData; > >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); > >>>>>>> >>>> >> std::fill_n(static_cast >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), > >>>>>>> >>>> >> 8000000, 0.01); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew volumeMapper; > >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew volumeProperty; > >>>>>>> >>>> >> volumeProperty->SetScalarOpacity( > opacityFunction.Get()); > >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); > >>>>>>> >>>> >> volumeProperty->ShadeOff(); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew volume; > >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); > >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew renderer; > >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); > >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); > >>>>>>> >>>> >> > >>>>>>> >>>> >> if (argc > 1) { > >>>>>>> >>>> >> // Render with QVTKOpenGLWidget > >>>>>>> >>>> >> vtkNew window; > >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >>>>>>> >>>> >> > >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); > >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); > >>>>>>> >>>> >> widget->show(); > >>>>>>> >>>> >> > >>>>>>> >>>> >> return app.exec(); > >>>>>>> >>>> >> } else { > >>>>>>> >>>> >> // Render with "plain" render window / interactor > >>>>>>> >>>> >> vtkNew window; > >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >>>>>>> >>>> >> > >>>>>>> >>>> >> vtkNew interactor; > >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); > >>>>>>> >>>> >> interactor->Start(); > >>>>>>> >>>> >> > >>>>>>> >>>> >> return 0; > >>>>>>> >>>> >> } > >>>>>>> >>>> >> } > >>>>>>> >>>> >> > >>>>>>> >>>> >> > >>>>>>> >>>> >> CMakeLists.txt: > >>>>>>> >>>> >> > >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) > >>>>>>> >>>> >> > >>>>>>> >>>> >> project(TestCase) > >>>>>>> >>>> >> > >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS > >>>>>>> >>>> >> vtkCommonCore > >>>>>>> >>>> >> vtkCommonDataModel > >>>>>>> >>>> >> vtkCommonExecutionModel > >>>>>>> >>>> >> vtkCommonMath > >>>>>>> >>>> >> vtkFiltersSources > >>>>>>> >>>> >> vtkGUISupportQt > >>>>>>> >>>> >> vtkInteractionStyle > >>>>>>> >>>> >> vtkRenderingCore > >>>>>>> >>>> >> vtkRenderingOpenGL2 > >>>>>>> >>>> >> vtkRenderingVolume > >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >>>>>>> >>>> >> REQUIRED > >>>>>>> >>>> >> ) > >>>>>>> >>>> >> > >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) > >>>>>>> >>>> >> > >>>>>>> >>>> >> add_executable(TestCase main.cpp) > >>>>>>> >>>> >> > >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC > >>>>>>> >>>> >> vtkCommonCore > >>>>>>> >>>> >> vtkCommonDataModel > >>>>>>> >>>> >> vtkCommonExecutionModel > >>>>>>> >>>> >> vtkCommonMath > >>>>>>> >>>> >> vtkFiltersSources > >>>>>>> >>>> >> vtkGUISupportQt > >>>>>>> >>>> >> vtkInteractionStyle > >>>>>>> >>>> >> vtkRenderingCore > >>>>>>> >>>> >> vtkRenderingOpenGL2 > >>>>>>> >>>> >> vtkRenderingVolume > >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >>>>>>> >>>> >> Qt5::Widgets > >>>>>>> >>>> >> ) > >>>>>>> >>>> >> > >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC > >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} > >>>>>>> >>>> >> ) > >>>>>>> >>>> >> > >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC > >>>>>>> >>>> >> ${VTK_DEFINITIONS} > >>>>>>> >>>> >> ) > >>>>>>> >>>> >> > >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES > >>>>>>> >>>> >> CXX_STANDARD 14 > >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON > >>>>>>> >>>> >> ) > >>>>>>> >>>> >> _______________________________________________ > >>>>>>> >>>> >> 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: > >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >>>>>>> >>>> >> > >>>>>>> >>>> > -- > >>>>>>> >>>> > > >>>>>>> >>>> > Sankhesh Jhaveri > >>>>>>> >>>> > > >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) > 881-4417 > >>>>>>> >>> > >>>>>>> >>> -- > >>>>>>> >>> > >>>>>>> >>> Sankhesh Jhaveri > >>>>>>> >>> > >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >>>>>>> >> > >>>>>>> >> -- > >>>>>>> >> > >>>>>>> >> Sankhesh Jhaveri > >>>>>>> >> > >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 > >>>>>>> _______________________________________________ > >>>>>>> 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: > >>>>>>> http://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: > >>>>> http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 cory.quammen at kitware.com Thu May 25 23:37:43 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 25 May 2017 23:37:43 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: I'm guessing this ParaView issue I reported is related: https://gitlab.kitware.com/paraview/paraview/issues/17461 On Thu, May 25, 2017 at 8:24 PM, Ken Martin wrote: > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is a > Qt bug we already bumped into with Mesa. They have what looks to me like > some odd bad logic on windows for creating a context where they will not > give you a core context later than the latest compatibility context they can > get. For some vendors that is fine but for others they only offer Comp > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed > that the issue would go away. I believe Ben filed a bug report with them > (Qt) when he bumped into this when using Mesa on Windows. > > > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik > wrote: >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> > Yes, I ran it both ways. >> > >> > It works when run without the argument in the plain VTK render window, >> > and it is broken (shows nothing) when run with an argument. >> >> Alright, that's good. Then we're seeing the same thing. >> >> > Seems like it's definitely related to older Intel drivers on Windows. >> >> Yes, probably. >> >> > Not sure if there is an updated driver available for my machine. >> > Hesitant to try changing/updating it for other reasons, and sorry, >> > can't sacrifice this machine's current state for the purpose of >> > testing this out... >> >> No worries, I'm free to do as I please with the one I have, so I'll do >> some experimenting with different drivers when I'm back on Monday. >> >> Thanks to everyone trying this out. >> >> Elvis >> >> > >> > >> > D >> > >> > >> > >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> > wrote: >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> : >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> >>>> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. >> >>>> I >> >>>> get your TestCase app window with nothing but an empty (white) client >> >>>> region. >> >>>> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >> >>>> VolumeSmartMapper works fine on this very same machine. >> >>>> >> >>>> Another data point... >> >> >> >> Just one more thing David, did you try also running the example >> >> without any argument on this machine? (That would make it use a >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> >> interesting to know if the volume shows up then. That would confirm >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> Elvis >> >> >> >>> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >> >>> David. >> >>> >> >>> And just to make sure, Aron, did you run the test case as "TestCase >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >>> >> >>> Elvis >> >>> >> >>>> >> >>>> >> >>>> D >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >>>> wrote: >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >> >>>>>> Hi Elvis, >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >> >>>>>> setup - both >> >>>>>> intel and nvidia graphics. >> >>>>>> With your test case, I'm able to see the volume running either with >> >>>>>> Intel or >> >>>>>> nVidia, so it doesn't repro for me. >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> >>>>>> Sorry, >> >>>>>> Aron >> >>>>> >> >>>>> Alright, bugger. Thanks for testing though! >> >>>>> >> >>>>> I won't be at the office until Monday again, but when I'm back I'll >> >>>>> try experimenting with different driver versions. >> >>>>> >> >>>>> Elvis >> >>>>> >> >>>>>> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >>>>>>> : >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >>>>>>> > : >> >>>>>>> >> Hi Elvis, >> >>>>>>> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >>>>>>> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card but >> >>>>>>> >> tried >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >> >>>>>>> >> (with an >> >>>>>>> >> Intel >> >>>>>>> >> HD5600). Worked fine. >> >>>>>>> > >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >> >>>>>>> > machine with >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >> >>>>>>> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >>>>>>> >> >>>>>>> I've now put up the compiled self-contained test case here: >> >>>>>>> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >>>>>>> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >> >>>>>>> graphics could try running this test case with "TestCase 1" and >> >>>>>>> see if >> >>>>>>> the volume shows up, that would be great. >> >>>>>>> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >>>>>>> >> >>>>>>> Elvis >> >>>>>>> >> >>>>>>> > >> >>>>>>> > I could put up my build of the test case as a self-contained >> >>>>>>> > .zip, to >> >>>>>>> > make it easy to test. >> >>>>>>> > >> >>>>>>> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics drivers >> >>>>>>> >> on your >> >>>>>>> >> Windows machine may need updating. >> >>>>>>> > >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just >> >>>>>>> > use a >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >> >>>>>>> > suggest that the drivers are capable enough, and that the >> >>>>>>> > problem is >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >>>>>>> > >> >>>>>>> > Elvis >> >>>>>>> > >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >>>>>>> >> wrote: >> >>>>>>> >>> >> >>>>>>> >>> Okay thanks. >> >>>>>>> >>> >> >>>>>>> >>> I?ll take a look. >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >>>>>>> >>> wrote: >> >>>>>>> >>>> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >>>>>>> >>>> : >> >>>>>>> >>>> > Hi Elvis, >> >>>>>>> >>>> > >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary and >> >>>>>>> >>>> > test >> >>>>>>> >>>> > volume >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a test >> >>>>>>> >>>> > dataset. >> >>>>>>> >>>> > ParaView >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >> >>>>>>> >>>> > before diving >> >>>>>>> >>>> > into the >> >>>>>>> >>>> > code. >> >>>>>>> >>>> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >> >>>>>>> >>>> case. The >> >>>>>>> >>>> volume won't show up. >> >>>>>>> >>>> >> >>>>>>> >>>> It does show up if I switch to the software based ray cast >> >>>>>>> >>>> mapper >> >>>>>>> >>>> (but >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the GPU >> >>>>>>> >>>> one being >> >>>>>>> >>>> used). >> >>>>>>> >>>> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help >> >>>>>>> >>>> debugging. >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >>>>>>> >>>> >> >>>>>>> >>>> Elvis >> >>>>>>> >>>> >> >>>>>>> >>>> > >> >>>>>>> >>>> > Thanks, >> >>>>>>> >>>> > Sankhesh >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >>>>>>> >>>> > wrote: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Hi all, >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >> >>>>>>> >>>> >> rendered using >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel >> >>>>>>> >>>> >> graphics >> >>>>>>> >>>> >> (HD >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine >> >>>>>>> >>>> >> on >> >>>>>>> >>>> >> Windows 7 >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning off >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >>>>>>> >>>> >> QSurfaceFormat. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >> >>>>>>> >>>> >> attached >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase >> >>>>>>> >>>> >> 1" >> >>>>>>> >>>> >> (right). >> >>>>>>> >>>> >> The former uses a plain render window while the latter >> >>>>>>> >>>> >> uses the >> >>>>>>> >>>> >> new >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, >> >>>>>>> >>>> >> the >> >>>>>>> >>>> >> plain >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is >> >>>>>>> >>>> >> not >> >>>>>>> >>>> >> showing >> >>>>>>> >>>> >> the volume. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Versions used: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>>>>> >>>> >> Qt 5.5.1 >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Windows 7 >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>>>>> >>>> >> Qt 5.6.2 >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my build >> >>>>>>> >>>> >> of the >> >>>>>>> >>>> >> test >> >>>>>>> >>>> >> case if you want. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >> >>>>>>> >>>> >> reported >> >>>>>>> >>>> >> and >> >>>>>>> >>>> >> got solved in my other thread. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >>>>>>> >>>> >> Elvis >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> main.cpp: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >>>>>>> >>>> >> { >> >>>>>>> >>>> >> auto defaultFormat = >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >>>>>>> >>>> >> vtkNew colorFunction; >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >>>>>>> >>>> >> std::fill_n(static_cast> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >>>>>>> >>>> >> 8000000, 0.01); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew volumeMapper; >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew volume; >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >>>>>>> >>>> >> vtkNew window; >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >>>>>>> >>>> >> widget->show(); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> return app.exec(); >> >>>>>>> >>>> >> } else { >> >>>>>>> >>>> >> // Render with "plain" render window / interactor >> >>>>>>> >>>> >> vtkNew window; >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew interactor; >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >>>>>>> >>>> >> interactor->Start(); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> return 0; >> >>>>>>> >>>> >> } >> >>>>>>> >>>> >> } >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> project(TestCase) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >>>>>>> >>>> >> vtkCommonCore >> >>>>>>> >>>> >> vtkCommonDataModel >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >>>>>>> >>>> >> vtkCommonMath >> >>>>>>> >>>> >> vtkFiltersSources >> >>>>>>> >>>> >> vtkGUISupportQt >> >>>>>>> >>>> >> vtkInteractionStyle >> >>>>>>> >>>> >> vtkRenderingCore >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >>>>>>> >>>> >> vtkRenderingVolume >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>>>>> >>>> >> REQUIRED >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >>>>>>> >>>> >> vtkCommonCore >> >>>>>>> >>>> >> vtkCommonDataModel >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >>>>>>> >>>> >> vtkCommonMath >> >>>>>>> >>>> >> vtkFiltersSources >> >>>>>>> >>>> >> vtkGUISupportQt >> >>>>>>> >>>> >> vtkInteractionStyle >> >>>>>>> >>>> >> vtkRenderingCore >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >>>>>>> >>>> >> vtkRenderingVolume >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>>>>> >>>> >> Qt5::Widgets >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> _______________________________________________ >> >>>>>>> >>>> >> 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: >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>>>>> >>>> >> >> >>>>>>> >>>> > -- >> >>>>>>> >>>> > >> >>>>>>> >>>> > Sankhesh Jhaveri >> >>>>>>> >>>> > >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >> >>>>>>> >>>> > 881-4417 >> >>>>>>> >>> >> >>>>>>> >>> -- >> >>>>>>> >>> >> >>>>>>> >>> Sankhesh Jhaveri >> >>>>>>> >>> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>>>>> >> >> >>>>>>> >> -- >> >>>>>>> >> >> >>>>>>> >> Sankhesh Jhaveri >> >>>>>>> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>>>>> _______________________________________________ >> >>>>>>> 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: >> >>>>>>> http://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: >> >>>>> http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. From suharev at roentgenprom.ru Fri May 26 04:09:12 2017 From: suharev at roentgenprom.ru (xVict) Date: Fri, 26 May 2017 01:09:12 -0700 (MST) Subject: [vtk-developers] qtgraphicsview example crash with OpenGL2 In-Reply-To: References: Message-ID: <1495786152804-5743423.post@n5.nabble.com> Sorry, Reply post again. I have same situation for VTK 7.1.1 stable QT5.5.1 1 0000000000000000() *2 vtkRenderingOpenGL2-7.1_d.dll!vtkOpenGLRenderWindow::OpenGLInitState() 3 vtkGUISupportQtOpenGL-7.1_d.dll!QVTKGraphicsItem::Start() 4 vtkGUISupportQtOpenGL-7.1_d.dll!QVTKGraphicsItem::qt_static_metacall(QObject * _o=0x000000000409e600, QMetaObject::Call _c=InvokeMetaMethod, int _id=0x00000002, void * * _a=0x0000000000317428) 5 Qt5Cored.dll!QMetaObject::activate(QObject * sender=0x0000000005ff20e0, int signalOffset=0x00000003, int local_signal_index=0x00000000, void * * argv=0x0000000000317428) 6 Qt5Cored.dll!QMetaObject::activate(QObject * sender=0x0000000005ff20e0, const QMetaObject * m=0x000007fee70a4c88, int local_signal_index=0x00000000, void * * argv=0x0000000000317428) {,,vtkglew-7.1_d.dll}__glewBlendFuncSeparate 0x0000000000000000 void (unsigned int, unsigned int, unsigned int, unsigned int) * The vtkglew is not initialized. I add call to consructor GraphicsView in GraphicsView.hpp(34): mWidget->GetRenderWindow()->OpenGLInit(); //<--------- init glew After it sample worked. But i don't now how to correct. Thank you all. -- View this message in context: http://vtk.1045678.n5.nabble.com/qtgraphicsview-example-crash-with-OpenGL2-tp5737916p5743423.html Sent from the VTK - Dev mailing list archive at Nabble.com. From elvis.stansvik at orexplore.com Fri May 26 04:32:36 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 26 May 2017 10:32:36 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-26 2:24 GMT+02:00 Ken Martin : > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is a > Qt bug we already bumped into with Mesa. They have what looks to me like > some odd bad logic on windows for creating a context where they will not > give you a core context later than the latest compatibility context they can > get. For some vendors that is fine but for others they only offer Comp > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed > that the issue would go away. I believe Ben filed a bug report with them > (Qt) when he bumped into this when using Mesa on Windows. Ah yes, that could definitely be it. I found Ben's bug: https://bugreports.qt.io/browse/QTBUG-60742 The affected version is listed as 5.8.0, but I'm having trouble on 5.6.2, so I guess the bad logic is there as well. So let's hope for a fix in Qt then. But in the meantime, is there anything you can think if that I could do to work around it? I really want our application to work on these kinds of machines (the one I have was picked as a sort of a baseline for us wrt to requirements). In the bug report Ben mentions hacking around it with MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not using Mesa. Elvis > > > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik > wrote: >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> > Yes, I ran it both ways. >> > >> > It works when run without the argument in the plain VTK render window, >> > and it is broken (shows nothing) when run with an argument. >> >> Alright, that's good. Then we're seeing the same thing. >> >> > Seems like it's definitely related to older Intel drivers on Windows. >> >> Yes, probably. >> >> > Not sure if there is an updated driver available for my machine. >> > Hesitant to try changing/updating it for other reasons, and sorry, >> > can't sacrifice this machine's current state for the purpose of >> > testing this out... >> >> No worries, I'm free to do as I please with the one I have, so I'll do >> some experimenting with different drivers when I'm back on Monday. >> >> Thanks to everyone trying this out. >> >> Elvis >> >> > >> > >> > D >> > >> > >> > >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> > wrote: >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> : >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> >>>> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. >> >>>> I >> >>>> get your TestCase app window with nothing but an empty (white) client >> >>>> region. >> >>>> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >> >>>> VolumeSmartMapper works fine on this very same machine. >> >>>> >> >>>> Another data point... >> >> >> >> Just one more thing David, did you try also running the example >> >> without any argument on this machine? (That would make it use a >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> >> interesting to know if the volume shows up then. That would confirm >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> Elvis >> >> >> >>> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >> >>> David. >> >>> >> >>> And just to make sure, Aron, did you run the test case as "TestCase >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >>> >> >>> Elvis >> >>> >> >>>> >> >>>> >> >>>> D >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >>>> wrote: >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >> >>>>>> Hi Elvis, >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >> >>>>>> setup - both >> >>>>>> intel and nvidia graphics. >> >>>>>> With your test case, I'm able to see the volume running either with >> >>>>>> Intel or >> >>>>>> nVidia, so it doesn't repro for me. >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> >>>>>> Sorry, >> >>>>>> Aron >> >>>>> >> >>>>> Alright, bugger. Thanks for testing though! >> >>>>> >> >>>>> I won't be at the office until Monday again, but when I'm back I'll >> >>>>> try experimenting with different driver versions. >> >>>>> >> >>>>> Elvis >> >>>>> >> >>>>>> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >>>>>>> : >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >>>>>>> > : >> >>>>>>> >> Hi Elvis, >> >>>>>>> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >>>>>>> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card but >> >>>>>>> >> tried >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >> >>>>>>> >> (with an >> >>>>>>> >> Intel >> >>>>>>> >> HD5600). Worked fine. >> >>>>>>> > >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >> >>>>>>> > machine with >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >> >>>>>>> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >>>>>>> >> >>>>>>> I've now put up the compiled self-contained test case here: >> >>>>>>> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >>>>>>> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >> >>>>>>> graphics could try running this test case with "TestCase 1" and >> >>>>>>> see if >> >>>>>>> the volume shows up, that would be great. >> >>>>>>> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >>>>>>> >> >>>>>>> Elvis >> >>>>>>> >> >>>>>>> > >> >>>>>>> > I could put up my build of the test case as a self-contained >> >>>>>>> > .zip, to >> >>>>>>> > make it easy to test. >> >>>>>>> > >> >>>>>>> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics drivers >> >>>>>>> >> on your >> >>>>>>> >> Windows machine may need updating. >> >>>>>>> > >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just >> >>>>>>> > use a >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >> >>>>>>> > suggest that the drivers are capable enough, and that the >> >>>>>>> > problem is >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >>>>>>> > >> >>>>>>> > Elvis >> >>>>>>> > >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >>>>>>> >> wrote: >> >>>>>>> >>> >> >>>>>>> >>> Okay thanks. >> >>>>>>> >>> >> >>>>>>> >>> I?ll take a look. >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >>>>>>> >>> wrote: >> >>>>>>> >>>> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >>>>>>> >>>> : >> >>>>>>> >>>> > Hi Elvis, >> >>>>>>> >>>> > >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary and >> >>>>>>> >>>> > test >> >>>>>>> >>>> > volume >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a test >> >>>>>>> >>>> > dataset. >> >>>>>>> >>>> > ParaView >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >> >>>>>>> >>>> > before diving >> >>>>>>> >>>> > into the >> >>>>>>> >>>> > code. >> >>>>>>> >>>> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >> >>>>>>> >>>> case. The >> >>>>>>> >>>> volume won't show up. >> >>>>>>> >>>> >> >>>>>>> >>>> It does show up if I switch to the software based ray cast >> >>>>>>> >>>> mapper >> >>>>>>> >>>> (but >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the GPU >> >>>>>>> >>>> one being >> >>>>>>> >>>> used). >> >>>>>>> >>>> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help >> >>>>>>> >>>> debugging. >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >>>>>>> >>>> >> >>>>>>> >>>> Elvis >> >>>>>>> >>>> >> >>>>>>> >>>> > >> >>>>>>> >>>> > Thanks, >> >>>>>>> >>>> > Sankhesh >> >>>>>>> >>>> > >> >>>>>>> >>>> > >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >>>>>>> >>>> > wrote: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Hi all, >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >> >>>>>>> >>>> >> rendered using >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel >> >>>>>>> >>>> >> graphics >> >>>>>>> >>>> >> (HD >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine >> >>>>>>> >>>> >> on >> >>>>>>> >>>> >> Windows 7 >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning off >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >>>>>>> >>>> >> QSurfaceFormat. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >> >>>>>>> >>>> >> attached >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase >> >>>>>>> >>>> >> 1" >> >>>>>>> >>>> >> (right). >> >>>>>>> >>>> >> The former uses a plain render window while the latter >> >>>>>>> >>>> >> uses the >> >>>>>>> >>>> >> new >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, >> >>>>>>> >>>> >> the >> >>>>>>> >>>> >> plain >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is >> >>>>>>> >>>> >> not >> >>>>>>> >>>> >> showing >> >>>>>>> >>>> >> the volume. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Versions used: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>>>>> >>>> >> Qt 5.5.1 >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Windows 7 >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >>>>>>> >>>> >> Qt 5.6.2 >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my build >> >>>>>>> >>>> >> of the >> >>>>>>> >>>> >> test >> >>>>>>> >>>> >> case if you want. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >> >>>>>>> >>>> >> reported >> >>>>>>> >>>> >> and >> >>>>>>> >>>> >> got solved in my other thread. >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >>>>>>> >>>> >> Elvis >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> main.cpp: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> #include >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >>>>>>> >>>> >> { >> >>>>>>> >>>> >> auto defaultFormat = >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >>>>>>> >>>> >> vtkNew colorFunction; >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >>>>>>> >>>> >> std::fill_n(static_cast> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >>>>>>> >>>> >> 8000000, 0.01); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew volumeMapper; >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew volume; >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >>>>>>> >>>> >> vtkNew window; >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >>>>>>> >>>> >> widget->show(); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> return app.exec(); >> >>>>>>> >>>> >> } else { >> >>>>>>> >>>> >> // Render with "plain" render window / interactor >> >>>>>>> >>>> >> vtkNew window; >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> vtkNew interactor; >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >>>>>>> >>>> >> interactor->Start(); >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> return 0; >> >>>>>>> >>>> >> } >> >>>>>>> >>>> >> } >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> project(TestCase) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >>>>>>> >>>> >> vtkCommonCore >> >>>>>>> >>>> >> vtkCommonDataModel >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >>>>>>> >>>> >> vtkCommonMath >> >>>>>>> >>>> >> vtkFiltersSources >> >>>>>>> >>>> >> vtkGUISupportQt >> >>>>>>> >>>> >> vtkInteractionStyle >> >>>>>>> >>>> >> vtkRenderingCore >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >>>>>>> >>>> >> vtkRenderingVolume >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>>>>> >>>> >> REQUIRED >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >>>>>>> >>>> >> vtkCommonCore >> >>>>>>> >>>> >> vtkCommonDataModel >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >>>>>>> >>>> >> vtkCommonMath >> >>>>>>> >>>> >> vtkFiltersSources >> >>>>>>> >>>> >> vtkGUISupportQt >> >>>>>>> >>>> >> vtkInteractionStyle >> >>>>>>> >>>> >> vtkRenderingCore >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >>>>>>> >>>> >> vtkRenderingVolume >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >>>>>>> >>>> >> Qt5::Widgets >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >>>>>>> >>>> >> ) >> >>>>>>> >>>> >> _______________________________________________ >> >>>>>>> >>>> >> 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: >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>>>>>> >>>> >> >> >>>>>>> >>>> > -- >> >>>>>>> >>>> > >> >>>>>>> >>>> > Sankhesh Jhaveri >> >>>>>>> >>>> > >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >> >>>>>>> >>>> > 881-4417 >> >>>>>>> >>> >> >>>>>>> >>> -- >> >>>>>>> >>> >> >>>>>>> >>> Sankhesh Jhaveri >> >>>>>>> >>> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>>>>> >> >> >>>>>>> >> -- >> >>>>>>> >> >> >>>>>>> >> Sankhesh Jhaveri >> >>>>>>> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >> >>>>>>> _______________________________________________ >> >>>>>>> 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: >> >>>>>>> http://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: >> >>>>> http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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. From elvis.stansvik at orexplore.com Fri May 26 04:43:57 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 26 May 2017 10:43:57 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-26 5:37 GMT+02:00 Cory Quammen : > I'm guessing this ParaView issue I reported is related: > https://gitlab.kitware.com/paraview/paraview/issues/17461 Thanks, subscribed to that one as well, in case it's the same issue. Elvis > > On Thu, May 25, 2017 at 8:24 PM, Ken Martin wrote: >> I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is a >> Qt bug we already bumped into with Mesa. They have what looks to me like >> some odd bad logic on windows for creating a context where they will not >> give you a core context later than the latest compatibility context they can >> get. For some vendors that is fine but for others they only offer Comp >> contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support >> OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed >> that the issue would go away. I believe Ben filed a bug report with them >> (Qt) when he bumped into this when using Mesa on Windows. >> >> >> On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >> wrote: >>> >>> 2017-05-25 23:37 GMT+02:00 David Cole : >>> > Yes, I ran it both ways. >>> > >>> > It works when run without the argument in the plain VTK render window, >>> > and it is broken (shows nothing) when run with an argument. >>> >>> Alright, that's good. Then we're seeing the same thing. >>> >>> > Seems like it's definitely related to older Intel drivers on Windows. >>> >>> Yes, probably. >>> >>> > Not sure if there is an updated driver available for my machine. >>> > Hesitant to try changing/updating it for other reasons, and sorry, >>> > can't sacrifice this machine's current state for the purpose of >>> > testing this out... >>> >>> No worries, I'm free to do as I please with the one I have, so I'll do >>> some experimenting with different drivers when I'm back on Monday. >>> >>> Thanks to everyone trying this out. >>> >>> Elvis >>> >>> > >>> > >>> > D >>> > >>> > >>> > >>> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >>> > wrote: >>> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >>> >> : >>> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >>> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >>> >>>> with an Intel HD Graphics 4000 running driver version 10.18.10.3316. >>> >>>> I >>> >>>> get your TestCase app window with nothing but an empty (white) client >>> >>>> region. >>> >>>> >>> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >>> >>>> VolumeSmartMapper works fine on this very same machine. >>> >>>> >>> >>>> Another data point... >>> >> >>> >> Just one more thing David, did you try also running the example >>> >> without any argument on this machine? (That would make it use a >>> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >>> >> interesting to know if the volume shows up then. That would confirm >>> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >>> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >>> >> something to do with the new QVTKOpenGLWidget. >>> >> >>> >> Elvis >>> >> >>> >>> >>> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >>> >>> David. >>> >>> >>> >>> And just to make sure, Aron, did you run the test case as "TestCase >>> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >>> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >>> >>> QVTKOpenGLWidget), and not exhibit the problem. >>> >>> >>> >>> Elvis >>> >>> >>> >>>> >>> >>>> >>> >>>> D >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >>> >>>> wrote: >>> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>> >>>>>> Hi Elvis, >>> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >>> >>>>>> setup - both >>> >>>>>> intel and nvidia graphics. >>> >>>>>> With your test case, I'm able to see the volume running either with >>> >>>>>> Intel or >>> >>>>>> nVidia, so it doesn't repro for me. >>> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >>> >>>>>> Sorry, >>> >>>>>> Aron >>> >>>>> >>> >>>>> Alright, bugger. Thanks for testing though! >>> >>>>> >>> >>>>> I won't be at the office until Monday again, but when I'm back I'll >>> >>>>> try experimenting with different driver versions. >>> >>>>> >>> >>>>> Elvis >>> >>>>> >>> >>>>>> >>> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>> >>>>>> wrote: >>> >>>>>>> >>> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >>> >>>>>>> : >>> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>> >>>>>>> > : >>> >>>>>>> >> Hi Elvis, >>> >>>>>>> >> >>> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>> >>>>>>> >> >>> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card but >>> >>>>>>> >> tried >>> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >>> >>>>>>> >> (with an >>> >>>>>>> >> Intel >>> >>>>>>> >> HD5600). Worked fine. >>> >>>>>>> > >>> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >>> >>>>>>> > machine with >>> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >>> >>>>>>> >>> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>> >>>>>>> >>> >>>>>>> I've now put up the compiled self-contained test case here: >>> >>>>>>> >>> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>> >>>>>>> >>> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + Intel >>> >>>>>>> graphics could try running this test case with "TestCase 1" and >>> >>>>>>> see if >>> >>>>>>> the volume shows up, that would be great. >>> >>>>>>> >>> >>>>>>> (Running the test case with argc > 2 will make it use >>> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>> >>>>>>> >>> >>>>>>> Elvis >>> >>>>>>> >>> >>>>>>> > >>> >>>>>>> > I could put up my build of the test case as a self-contained >>> >>>>>>> > .zip, to >>> >>>>>>> > make it easy to test. >>> >>>>>>> > >>> >>>>>>> >> >>> >>>>>>> >> At this point, I am inclined to think that the graphics drivers >>> >>>>>>> >> on your >>> >>>>>>> >> Windows machine may need updating. >>> >>>>>>> > >>> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and just >>> >>>>>>> > use a >>> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't that >>> >>>>>>> > suggest that the drivers are capable enough, and that the >>> >>>>>>> > problem is >>> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>> >>>>>>> > >>> >>>>>>> > Elvis >>> >>>>>>> > >>> >>>>>>> >> >>> >>>>>>> >> >>> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>> >>>>>>> >> wrote: >>> >>>>>>> >>> >>> >>>>>>> >>> Okay thanks. >>> >>>>>>> >>> >>> >>>>>>> >>> I?ll take a look. >>> >>>>>>> >>> >>> >>>>>>> >>> >>> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>> >>>>>>> >>> wrote: >>> >>>>>>> >>>> >>> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>> >>>>>>> >>>> : >>> >>>>>>> >>>> > Hi Elvis, >>> >>>>>>> >>>> > >>> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary and >>> >>>>>>> >>>> > test >>> >>>>>>> >>>> > volume >>> >>>>>>> >>>> > rendering there? You can use the wavelet source for a test >>> >>>>>>> >>>> > dataset. >>> >>>>>>> >>>> > ParaView >>> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >>> >>>>>>> >>>> > before diving >>> >>>>>>> >>>> > into the >>> >>>>>>> >>>> > code. >>> >>>>>>> >>>> >>> >>>>>>> >>>> I tried the wavelet example with Paraview >>> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >>> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >>> >>>>>>> >>>> case. The >>> >>>>>>> >>>> volume won't show up. >>> >>>>>>> >>>> >>> >>>>>>> >>>> It does show up if I switch to the software based ray cast >>> >>>>>>> >>>> mapper >>> >>>>>>> >>>> (but >>> >>>>>>> >>>> not with GPU or smart, which I guess both result in the GPU >>> >>>>>>> >>>> one being >>> >>>>>>> >>>> used). >>> >>>>>>> >>>> >>> >>>>>>> >>>> Please tell me if there's anything else I can do to help >>> >>>>>>> >>>> debugging. >>> >>>>>>> >>>> There are no errors printed when I run my test case. >>> >>>>>>> >>>> >>> >>>>>>> >>>> Elvis >>> >>>>>>> >>>> >>> >>>>>>> >>>> > >>> >>>>>>> >>>> > Thanks, >>> >>>>>>> >>>> > Sankhesh >>> >>>>>>> >>>> > >>> >>>>>>> >>>> > >>> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>> >>>>>>> >>>> > wrote: >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Hi all, >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >>> >>>>>>> >>>> >> rendered using >>> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel >>> >>>>>>> >>>> >> graphics >>> >>>>>>> >>>> >> (HD >>> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up fine >>> >>>>>>> >>>> >> on >>> >>>>>>> >>>> >> Windows 7 >>> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning off >>> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >>> >>>>>>> >>>> >> QSurfaceFormat. >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> The below test case illustrates the issue. See the >>> >>>>>>> >>>> >> attached >>> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase >>> >>>>>>> >>>> >> 1" >>> >>>>>>> >>>> >> (right). >>> >>>>>>> >>>> >> The former uses a plain render window while the latter >>> >>>>>>> >>>> >> uses the >>> >>>>>>> >>>> >> new >>> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 screenshot, >>> >>>>>>> >>>> >> the >>> >>>>>>> >>>> >> plain >>> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one is >>> >>>>>>> >>>> >> not >>> >>>>>>> >>>> >> showing >>> >>>>>>> >>>> >> the volume. >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Versions used: >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Kubuntu Linux 16.04 >>> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>> >>>>>>> >>>> >> Qt 5.5.1 >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Windows 7 >>> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>> >>>>>>> >>>> >> Qt 5.6.2 >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Any ideas what the problem might be? >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my build >>> >>>>>>> >>>> >> of the >>> >>>>>>> >>>> >> test >>> >>>>>>> >>>> >> case if you want. >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >>> >>>>>>> >>>> >> reported >>> >>>>>>> >>>> >> and >>> >>>>>>> >>>> >> got solved in my other thread. >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> Many thanks in advance, >>> >>>>>>> >>>> >> Elvis >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> main.cpp: >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> #include >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> int main(int argc, char *argv[]) >>> >>>>>>> >>>> >> { >>> >>>>>>> >>>> >> auto defaultFormat = >>> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >>> >>>>>>> >>>> >> defaultFormat.setSamples(0); >>> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> QApplication app(argc, argv); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> // Set up volume rendering >>> >>>>>>> >>>> >> vtkNew colorFunction; >>> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew opacityFunction; >>> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew imageData; >>> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>> >>>>>>> >>>> >> std::fill_n(static_cast>> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >>> >>>>>>> >>>> >> 8000000, 0.01); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew volumeMapper; >>> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew volumeProperty; >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew volume; >>> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew renderer; >>> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >>> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> if (argc > 1) { >>> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >>> >>>>>>> >>>> >> vtkNew window; >>> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>> >>>>>>> >>>> >> widget->show(); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> return app.exec(); >>> >>>>>>> >>>> >> } else { >>> >>>>>>> >>>> >> // Render with "plain" render window / interactor >>> >>>>>>> >>>> >> vtkNew window; >>> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> vtkNew interactor; >>> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>> >>>>>>> >>>> >> interactor->Start(); >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> return 0; >>> >>>>>>> >>>> >> } >>> >>>>>>> >>>> >> } >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> CMakeLists.txt: >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> project(TestCase) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>> >>>>>>> >>>> >> vtkCommonCore >>> >>>>>>> >>>> >> vtkCommonDataModel >>> >>>>>>> >>>> >> vtkCommonExecutionModel >>> >>>>>>> >>>> >> vtkCommonMath >>> >>>>>>> >>>> >> vtkFiltersSources >>> >>>>>>> >>>> >> vtkGUISupportQt >>> >>>>>>> >>>> >> vtkInteractionStyle >>> >>>>>>> >>>> >> vtkRenderingCore >>> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>> >>>>>>> >>>> >> vtkRenderingVolume >>> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >>>>>>> >>>> >> REQUIRED >>> >>>>>>> >>>> >> ) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>> >>>>>>> >>>> >> vtkCommonCore >>> >>>>>>> >>>> >> vtkCommonDataModel >>> >>>>>>> >>>> >> vtkCommonExecutionModel >>> >>>>>>> >>>> >> vtkCommonMath >>> >>>>>>> >>>> >> vtkFiltersSources >>> >>>>>>> >>>> >> vtkGUISupportQt >>> >>>>>>> >>>> >> vtkInteractionStyle >>> >>>>>>> >>>> >> vtkRenderingCore >>> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>> >>>>>>> >>>> >> vtkRenderingVolume >>> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >>>>>>> >>>> >> Qt5::Widgets >>> >>>>>>> >>>> >> ) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >>> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>> >>>>>>> >>>> >> ) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >>> >>>>>>> >>>> >> ) >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>> >>>>>>> >>>> >> CXX_STANDARD 14 >>> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>> >>>>>>> >>>> >> ) >>> >>>>>>> >>>> >> _______________________________________________ >>> >>>>>>> >>>> >> 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: >>> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>>>>>> >>>> >> >>> >>>>>>> >>>> > -- >>> >>>>>>> >>>> > >>> >>>>>>> >>>> > Sankhesh Jhaveri >>> >>>>>>> >>>> > >>> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >>> >>>>>>> >>>> > 881-4417 >>> >>>>>>> >>> >>> >>>>>>> >>> -- >>> >>>>>>> >>> >>> >>>>>>> >>> Sankhesh Jhaveri >>> >>>>>>> >>> >>> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>> >>>>>>> >> >>> >>>>>>> >> -- >>> >>>>>>> >> >>> >>>>>>> >> Sankhesh Jhaveri >>> >>>>>>> >> >>> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) 881-4417 >>> >>>>>>> _______________________________________________ >>> >>>>>>> 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: >>> >>>>>>> http://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: >>> >>>>> http://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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. From elvis.stansvik at orexplore.com Fri May 26 06:39:16 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 26 May 2017 12:39:16 +0200 Subject: [vtk-developers] Strange renderering with mixed polydata/volume with QVTKOpenGLWidget In-Reply-To: References: Message-ID: 2017-05-23 11:35 GMT+02:00 Elvis Stansvik : > 2017-05-22 16:43 GMT+02:00 Utkarsh Ayachit : >>> The test case I sent was just that. >> >> >> Sorry, it got lost in my inbox. found it :). >> >> Attached is another patch. This tries a different approach to addressing the >> alpha issue. Leaving the QSurfaceFormat unchanged, can you try the attached >> patch and tell me how it goes? It's a patch for VTK. > > I applied the patch to the VTK 8.0.0.rc1 I'm using on the Mac, and can > confirm that this fixes the problem: I no longer have to use > setAlphaBufferSize(0) on the QSurfaceFormat to avoid the alpha > problem. Thanks! Will this go into rc2? Elvis > > I still haven't gotten back the Win 8.1/nVidia machine, so I haven't > been able to verify the setAlphaBufferSize(0) fix nor this patch there > yet. But I feel confident that the issue I saw there (shown in the > screenshots in my first main) was the same as on the Mac, so is > probably solved. > > The issue I'm having on Windows 7/intel now (volumes not showing) is > orthogonal to this alpha issue, and I made a separate post about that. > > Thanks a lot for the assistance Utkarsh! > > Elvis > >> >> Thanks, >> Utkarsh From elvis.stansvik at orexplore.com Fri May 26 06:52:06 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 26 May 2017 12:52:06 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display Message-ID: Hi all, We're using vtkColorTransferFunctionItem vtkColorTransferControlPointsItem vtkCompositeTransferFunctionItem vtkCompositeControlPointsItem in a vtkChartXY for editing of color/opacity transfer functions, similar I believe to what ParaView does. I noticed on a retina Mac that interaction seems off. Clicking one place seems to lead to a response at the wrong point in the editor. Some experimenting later, it seems that I can click in the upper half of the composite editor (which we use for opacity), and I get a response at the corresponding place in the lower half of it. Anyone seen this and know if there's something I can do about it? It's a showstopper for our application on Mac. In the color editor (the vtkColorTransferFunctionItem / vtkColorTransferControlPointsItem pair), I can't get a response at all :/ Grateful for any tips from people using these classes on retina Mac. We're using VTK 8.0.0.rc1. Elvis From ken.martin at kitware.com Fri May 26 08:35:40 2017 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 26 May 2017 08:35:40 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: If you have a build of QT I think you could change https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 const int requestedVersion = qMin((format.majorVersion() << 8) + format.minorVersion(), staticContext.defaultFormat.version); to be const int requestedVersion = (format.majorVersion() << 8) + format.minorVersion()); and it would fix it for VTK/ParaView. Not sure if it has any other consequences for Qt or if it would hit some different issue though. Qt on windows does some tricky stuff to support OpenGL/Angle/ES2. On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-26 2:24 GMT+02:00 Ken Martin : > > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is > a > > Qt bug we already bumped into with Mesa. They have what looks to me like > > some odd bad logic on windows for creating a context where they will not > > give you a core context later than the latest compatibility context they > can > > get. For some vendors that is fine but for others they only offer Comp > > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support > > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed > > that the issue would go away. I believe Ben filed a bug report with them > > (Qt) when he bumped into this when using Mesa on Windows. > > Ah yes, that could definitely be it. I found Ben's bug: > > https://bugreports.qt.io/browse/QTBUG-60742 > > The affected version is listed as 5.8.0, but I'm having trouble on > 5.6.2, so I guess the bad logic is there as well. > > So let's hope for a fix in Qt then. But in the meantime, is there > anything you can think if that I could do to work around it? I really > want our application to work on these kinds of machines (the one I > have was picked as a sort of a baseline for us wrt to requirements). > > In the bug report Ben mentions hacking around it with > MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not > using Mesa. > > Elvis > > > > > > > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik > > wrote: > >> > >> 2017-05-25 23:37 GMT+02:00 David Cole : > >> > Yes, I ran it both ways. > >> > > >> > It works when run without the argument in the plain VTK render window, > >> > and it is broken (shows nothing) when run with an argument. > >> > >> Alright, that's good. Then we're seeing the same thing. > >> > >> > Seems like it's definitely related to older Intel drivers on Windows. > >> > >> Yes, probably. > >> > >> > Not sure if there is an updated driver available for my machine. > >> > Hesitant to try changing/updating it for other reasons, and sorry, > >> > can't sacrifice this machine's current state for the purpose of > >> > testing this out... > >> > >> No worries, I'm free to do as I please with the one I have, so I'll do > >> some experimenting with different drivers when I'm back on Monday. > >> > >> Thanks to everyone trying this out. > >> > >> Elvis > >> > >> > > >> > > >> > D > >> > > >> > > >> > > >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik > >> > wrote: > >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik > >> >> : > >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : > >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, > >> >>>> with an Intel HD Graphics 4000 running driver version > 10.18.10.3316. > >> >>>> I > >> >>>> get your TestCase app window with nothing but an empty (white) > client > >> >>>> region. > >> >>>> > >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using > >> >>>> VolumeSmartMapper works fine on this very same machine. > >> >>>> > >> >>>> Another data point... > >> >> > >> >> Just one more thing David, did you try also running the example > >> >> without any argument on this machine? (That would make it use a > >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be > >> >> interesting to know if the volume shows up then. That would confirm > >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just > >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has > >> >> something to do with the new QVTKOpenGLWidget. > >> >> > >> >> Elvis > >> >> > >> >>> > >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot > >> >>> David. > >> >>> > >> >>> And just to make sure, Aron, did you run the test case as "TestCase > >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll > >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not > >> >>> QVTKOpenGLWidget), and not exhibit the problem. > >> >>> > >> >>> Elvis > >> >>> > >> >>>> > >> >>>> > >> >>>> D > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik > >> >>>> wrote: > >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : > >> >>>>>> Hi Elvis, > >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus > >> >>>>>> setup - both > >> >>>>>> intel and nvidia graphics. > >> >>>>>> With your test case, I'm able to see the volume running either > with > >> >>>>>> Intel or > >> >>>>>> nVidia, so it doesn't repro for me. > >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 > >> >>>>>> Sorry, > >> >>>>>> Aron > >> >>>>> > >> >>>>> Alright, bugger. Thanks for testing though! > >> >>>>> > >> >>>>> I won't be at the office until Monday again, but when I'm back > I'll > >> >>>>> try experimenting with different driver versions. > >> >>>>> > >> >>>>> Elvis > >> >>>>> > >> >>>>>> > >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik > >> >>>>>> wrote: > >> >>>>>>> > >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik > >> >>>>>>> : > >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri > >> >>>>>>> > : > >> >>>>>>> >> Hi Elvis, > >> >>>>>>> >> > >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( > >> >>>>>>> >> > >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card > but > >> >>>>>>> >> tried > >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac > >> >>>>>>> >> (with an > >> >>>>>>> >> Intel > >> >>>>>>> >> HD5600). Worked fine. > >> >>>>>>> > > >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 > >> >>>>>>> > machine with > >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. > >> >>>>>>> > >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. > >> >>>>>>> > >> >>>>>>> I've now put up the compiled self-contained test case here: > >> >>>>>>> > >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) > >> >>>>>>> > >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + > Intel > >> >>>>>>> graphics could try running this test case with "TestCase 1" and > >> >>>>>>> see if > >> >>>>>>> the volume shows up, that would be great. > >> >>>>>>> > >> >>>>>>> (Running the test case with argc > 2 will make it use > >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). > >> >>>>>>> > >> >>>>>>> Elvis > >> >>>>>>> > >> >>>>>>> > > >> >>>>>>> > I could put up my build of the test case as a self-contained > >> >>>>>>> > .zip, to > >> >>>>>>> > make it easy to test. > >> >>>>>>> > > >> >>>>>>> >> > >> >>>>>>> >> At this point, I am inclined to think that the graphics > drivers > >> >>>>>>> >> on your > >> >>>>>>> >> Windows machine may need updating. > >> >>>>>>> > > >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and > just > >> >>>>>>> > use a > >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't > that > >> >>>>>>> > suggest that the drivers are capable enough, and that the > >> >>>>>>> > problem is > >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > >> >>>>>>> > > >> >>>>>>> > Elvis > >> >>>>>>> > > >> >>>>>>> >> > >> >>>>>>> >> > >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > >> >>>>>>> >> wrote: > >> >>>>>>> >>> > >> >>>>>>> >>> Okay thanks. > >> >>>>>>> >>> > >> >>>>>>> >>> I?ll take a look. > >> >>>>>>> >>> > >> >>>>>>> >>> > >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik > >> >>>>>>> >>> wrote: > >> >>>>>>> >>>> > >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >> >>>>>>> >>>> : > >> >>>>>>> >>>> > Hi Elvis, > >> >>>>>>> >>>> > > >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary and > >> >>>>>>> >>>> > test > >> >>>>>>> >>>> > volume > >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a > test > >> >>>>>>> >>>> > dataset. > >> >>>>>>> >>>> > ParaView > >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test > >> >>>>>>> >>>> > before diving > >> >>>>>>> >>>> > into the > >> >>>>>>> >>>> > code. > >> >>>>>>> >>>> > >> >>>>>>> >>>> I tried the wavelet example with Paraview > >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 > >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test > >> >>>>>>> >>>> case. The > >> >>>>>>> >>>> volume won't show up. > >> >>>>>>> >>>> > >> >>>>>>> >>>> It does show up if I switch to the software based ray cast > >> >>>>>>> >>>> mapper > >> >>>>>>> >>>> (but > >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the GPU > >> >>>>>>> >>>> one being > >> >>>>>>> >>>> used). > >> >>>>>>> >>>> > >> >>>>>>> >>>> Please tell me if there's anything else I can do to help > >> >>>>>>> >>>> debugging. > >> >>>>>>> >>>> There are no errors printed when I run my test case. > >> >>>>>>> >>>> > >> >>>>>>> >>>> Elvis > >> >>>>>>> >>>> > >> >>>>>>> >>>> > > >> >>>>>>> >>>> > Thanks, > >> >>>>>>> >>>> > Sankhesh > >> >>>>>>> >>>> > > >> >>>>>>> >>>> > > >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > >> >>>>>>> >>>> > wrote: > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Hi all, > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes > >> >>>>>>> >>>> >> rendered using > >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, Intel > >> >>>>>>> >>>> >> graphics > >> >>>>>>> >>>> >> (HD > >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up > fine > >> >>>>>>> >>>> >> on > >> >>>>>>> >>>> >> Windows 7 > >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning > off > >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default > >> >>>>>>> >>>> >> QSurfaceFormat. > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> The below test case illustrates the issue. See the > >> >>>>>>> >>>> >> attached > >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and "TestCase > >> >>>>>>> >>>> >> 1" > >> >>>>>>> >>>> >> (right). > >> >>>>>>> >>>> >> The former uses a plain render window while the latter > >> >>>>>>> >>>> >> uses the > >> >>>>>>> >>>> >> new > >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 > screenshot, > >> >>>>>>> >>>> >> the > >> >>>>>>> >>>> >> plain > >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one > is > >> >>>>>>> >>>> >> not > >> >>>>>>> >>>> >> showing > >> >>>>>>> >>>> >> the volume. > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Versions used: > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Kubuntu Linux 16.04 > >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >> >>>>>>> >>>> >> Qt 5.5.1 > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Windows 7 > >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >> >>>>>>> >>>> >> Qt 5.6.2 > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Any ideas what the problem might be? > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my build > >> >>>>>>> >>>> >> of the > >> >>>>>>> >>>> >> test > >> >>>>>>> >>>> >> case if you want. > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I > >> >>>>>>> >>>> >> reported > >> >>>>>>> >>>> >> and > >> >>>>>>> >>>> >> got solved in my other thread. > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> Many thanks in advance, > >> >>>>>>> >>>> >> Elvis > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> main.cpp: > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> #include > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> int main(int argc, char *argv[]) > >> >>>>>>> >>>> >> { > >> >>>>>>> >>>> >> auto defaultFormat = > >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); > >> >>>>>>> >>>> >> defaultFormat.setSamples(0); > >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> QApplication app(argc, argv); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> // Set up volume rendering > >> >>>>>>> >>>> >> vtkNew colorFunction; > >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew opacityFunction; > >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); > >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew imageData; > >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); > >> >>>>>>> >>>> >> std::fill_n(static_cast >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), > >> >>>>>>> >>>> >> 8000000, 0.01); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew volumeMapper; > >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew volumeProperty; > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity( > opacityFunction.Get()); > >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); > >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew volume; > >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); > >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew renderer; > >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); > >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> if (argc > 1) { > >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget > >> >>>>>>> >>>> >> vtkNew window; > >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); > >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); > >> >>>>>>> >>>> >> widget->show(); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> return app.exec(); > >> >>>>>>> >>>> >> } else { > >> >>>>>>> >>>> >> // Render with "plain" render window / > interactor > >> >>>>>>> >>>> >> vtkNew window; > >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> vtkNew interactor; > >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); > >> >>>>>>> >>>> >> interactor->Start(); > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> return 0; > >> >>>>>>> >>>> >> } > >> >>>>>>> >>>> >> } > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> CMakeLists.txt: > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> project(TestCase) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS > >> >>>>>>> >>>> >> vtkCommonCore > >> >>>>>>> >>>> >> vtkCommonDataModel > >> >>>>>>> >>>> >> vtkCommonExecutionModel > >> >>>>>>> >>>> >> vtkCommonMath > >> >>>>>>> >>>> >> vtkFiltersSources > >> >>>>>>> >>>> >> vtkGUISupportQt > >> >>>>>>> >>>> >> vtkInteractionStyle > >> >>>>>>> >>>> >> vtkRenderingCore > >> >>>>>>> >>>> >> vtkRenderingOpenGL2 > >> >>>>>>> >>>> >> vtkRenderingVolume > >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >> >>>>>>> >>>> >> REQUIRED > >> >>>>>>> >>>> >> ) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC > >> >>>>>>> >>>> >> vtkCommonCore > >> >>>>>>> >>>> >> vtkCommonDataModel > >> >>>>>>> >>>> >> vtkCommonExecutionModel > >> >>>>>>> >>>> >> vtkCommonMath > >> >>>>>>> >>>> >> vtkFiltersSources > >> >>>>>>> >>>> >> vtkGUISupportQt > >> >>>>>>> >>>> >> vtkInteractionStyle > >> >>>>>>> >>>> >> vtkRenderingCore > >> >>>>>>> >>>> >> vtkRenderingOpenGL2 > >> >>>>>>> >>>> >> vtkRenderingVolume > >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >> >>>>>>> >>>> >> Qt5::Widgets > >> >>>>>>> >>>> >> ) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC > >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} > >> >>>>>>> >>>> >> ) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC > >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} > >> >>>>>>> >>>> >> ) > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES > >> >>>>>>> >>>> >> CXX_STANDARD 14 > >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON > >> >>>>>>> >>>> >> ) > >> >>>>>>> >>>> >> _______________________________________________ > >> >>>>>>> >>>> >> 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: > >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk- > developers > >> >>>>>>> >>>> >> > >> >>>>>>> >>>> > -- > >> >>>>>>> >>>> > > >> >>>>>>> >>>> > Sankhesh Jhaveri > >> >>>>>>> >>>> > > >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) > >> >>>>>>> >>>> > 881-4417 > >> >>>>>>> >>> > >> >>>>>>> >>> -- > >> >>>>>>> >>> > >> >>>>>>> >>> Sankhesh Jhaveri > >> >>>>>>> >>> > >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) > 881-4417 > >> >>>>>>> >> > >> >>>>>>> >> -- > >> >>>>>>> >> > >> >>>>>>> >> Sankhesh Jhaveri > >> >>>>>>> >> > >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) > 881-4417 > >> >>>>>>> _______________________________________________ > >> >>>>>>> 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: > >> >>>>>>> http://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: > >> >>>>> http://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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > > > 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. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 elvis.stansvik at orexplore.com Fri May 26 08:55:57 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 26 May 2017 14:55:57 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-26 14:35 GMT+02:00 Ken Martin : > If you have a build of QT I think you could change > > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 > > const int requestedVersion = qMin((format.majorVersion() << 8) + > format.minorVersion(), > staticContext.defaultFormat.version); > > to be > > const int requestedVersion = (format.majorVersion() << 8) + > format.minorVersion()); > > and it would fix it for VTK/ParaView. Not sure if it has any other > consequences for Qt or if it would hit some different issue though. Qt on > windows does some tricky stuff to support OpenGL/Angle/ES2. Ah, thanks for the pointer. Using Qt from installer ATM, but if it comes to that, now I know where to look should I build from source and try to patch it. Elvis > > > > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik > wrote: >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin : >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is >> > a >> > Qt bug we already bumped into with Mesa. They have what looks to me like >> > some odd bad logic on windows for creating a context where they will not >> > give you a core context later than the latest compatibility context they >> > can >> > get. For some vendors that is fine but for others they only offer Comp >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed >> > that the issue would go away. I believe Ben filed a bug report with them >> > (Qt) when he bumped into this when using Mesa on Windows. >> >> Ah yes, that could definitely be it. I found Ben's bug: >> >> https://bugreports.qt.io/browse/QTBUG-60742 >> >> The affected version is listed as 5.8.0, but I'm having trouble on >> 5.6.2, so I guess the bad logic is there as well. >> >> So let's hope for a fix in Qt then. But in the meantime, is there >> anything you can think if that I could do to work around it? I really >> want our application to work on these kinds of machines (the one I >> have was picked as a sort of a baseline for us wrt to requirements). >> >> In the bug report Ben mentions hacking around it with >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >> using Mesa. >> >> Elvis >> >> > >> > >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >> > wrote: >> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> >> > Yes, I ran it both ways. >> >> > >> >> > It works when run without the argument in the plain VTK render >> >> > window, >> >> > and it is broken (shows nothing) when run with an argument. >> >> >> >> Alright, that's good. Then we're seeing the same thing. >> >> >> >> > Seems like it's definitely related to older Intel drivers on Windows. >> >> >> >> Yes, probably. >> >> >> >> > Not sure if there is an updated driver available for my machine. >> >> > Hesitant to try changing/updating it for other reasons, and sorry, >> >> > can't sacrifice this machine's current state for the purpose of >> >> > testing this out... >> >> >> >> No worries, I'm free to do as I please with the one I have, so I'll do >> >> some experimenting with different drivers when I'm back on Monday. >> >> >> >> Thanks to everyone trying this out. >> >> >> >> Elvis >> >> >> >> > >> >> > >> >> > D >> >> > >> >> > >> >> > >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> >> > wrote: >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> >> : >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> >> >>>> with an Intel HD Graphics 4000 running driver version >> >> >>>> 10.18.10.3316. >> >> >>>> I >> >> >>>> get your TestCase app window with nothing but an empty (white) >> >> >>>> client >> >> >>>> region. >> >> >>>> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >> >> >>>> VolumeSmartMapper works fine on this very same machine. >> >> >>>> >> >> >>>> Another data point... >> >> >> >> >> >> Just one more thing David, did you try also running the example >> >> >> without any argument on this machine? (That would make it use a >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> >> >> interesting to know if the volume shows up then. That would confirm >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >> >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> >> >> Elvis >> >> >> >> >> >>> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >> >> >>> David. >> >> >>> >> >> >>> And just to make sure, Aron, did you run the test case as "TestCase >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >> >>> >> >> >>> Elvis >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> D >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >> >>>> wrote: >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >> >> >>>>>> Hi Elvis, >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >> >> >>>>>> setup - both >> >> >>>>>> intel and nvidia graphics. >> >> >>>>>> With your test case, I'm able to see the volume running either >> >> >>>>>> with >> >> >>>>>> Intel or >> >> >>>>>> nVidia, so it doesn't repro for me. >> >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> >> >>>>>> Sorry, >> >> >>>>>> Aron >> >> >>>>> >> >> >>>>> Alright, bugger. Thanks for testing though! >> >> >>>>> >> >> >>>>> I won't be at the office until Monday again, but when I'm back >> >> >>>>> I'll >> >> >>>>> try experimenting with different driver versions. >> >> >>>>> >> >> >>>>> Elvis >> >> >>>>> >> >> >>>>>> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >> >>>>>>> : >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >> >>>>>>> > : >> >> >>>>>>> >> Hi Elvis, >> >> >>>>>>> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >> >>>>>>> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card >> >> >>>>>>> >> but >> >> >>>>>>> >> tried >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >> >> >>>>>>> >> (with an >> >> >>>>>>> >> Intel >> >> >>>>>>> >> HD5600). Worked fine. >> >> >>>>>>> > >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >> >> >>>>>>> > machine with >> >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >> >> >>>>>>> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >> >>>>>>> >> >> >>>>>>> I've now put up the compiled self-contained test case here: >> >> >>>>>>> >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >> >>>>>>> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + >> >> >>>>>>> Intel >> >> >>>>>>> graphics could try running this test case with "TestCase 1" and >> >> >>>>>>> see if >> >> >>>>>>> the volume shows up, that would be great. >> >> >>>>>>> >> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >> >>>>>>> >> >> >>>>>>> Elvis >> >> >>>>>>> >> >> >>>>>>> > >> >> >>>>>>> > I could put up my build of the test case as a self-contained >> >> >>>>>>> > .zip, to >> >> >>>>>>> > make it easy to test. >> >> >>>>>>> > >> >> >>>>>>> >> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics >> >> >>>>>>> >> drivers >> >> >>>>>>> >> on your >> >> >>>>>>> >> Windows machine may need updating. >> >> >>>>>>> > >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and >> >> >>>>>>> > just >> >> >>>>>>> > use a >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't >> >> >>>>>>> > that >> >> >>>>>>> > suggest that the drivers are capable enough, and that the >> >> >>>>>>> > problem is >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >> >>>>>>> > >> >> >>>>>>> > Elvis >> >> >>>>>>> > >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >> >>>>>>> >> wrote: >> >> >>>>>>> >>> >> >> >>>>>>> >>> Okay thanks. >> >> >>>>>>> >>> >> >> >>>>>>> >>> I?ll take a look. >> >> >>>>>>> >>> >> >> >>>>>>> >>> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >> >>>>>>> >>> wrote: >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >> >>>>>>> >>>> : >> >> >>>>>>> >>>> > Hi Elvis, >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary >> >> >>>>>>> >>>> > and >> >> >>>>>>> >>>> > test >> >> >>>>>>> >>>> > volume >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a >> >> >>>>>>> >>>> > test >> >> >>>>>>> >>>> > dataset. >> >> >>>>>>> >>>> > ParaView >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >> >> >>>>>>> >>>> > before diving >> >> >>>>>>> >>>> > into the >> >> >>>>>>> >>>> > code. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >> >> >>>>>>> >>>> case. The >> >> >>>>>>> >>>> volume won't show up. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> It does show up if I switch to the software based ray cast >> >> >>>>>>> >>>> mapper >> >> >>>>>>> >>>> (but >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the >> >> >>>>>>> >>>> GPU >> >> >>>>>>> >>>> one being >> >> >>>>>>> >>>> used). >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help >> >> >>>>>>> >>>> debugging. >> >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> Elvis >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Thanks, >> >> >>>>>>> >>>> > Sankhesh >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >> >>>>>>> >>>> > wrote: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Hi all, >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >> >> >>>>>>> >>>> >> rendered using >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, >> >> >>>>>>> >>>> >> Intel >> >> >>>>>>> >>>> >> graphics >> >> >>>>>>> >>>> >> (HD >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up >> >> >>>>>>> >>>> >> fine >> >> >>>>>>> >>>> >> on >> >> >>>>>>> >>>> >> Windows 7 >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning >> >> >>>>>>> >>>> >> off >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >> >>>>>>> >>>> >> QSurfaceFormat. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >> >> >>>>>>> >>>> >> attached >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and >> >> >>>>>>> >>>> >> "TestCase >> >> >>>>>>> >>>> >> 1" >> >> >>>>>>> >>>> >> (right). >> >> >>>>>>> >>>> >> The former uses a plain render window while the latter >> >> >>>>>>> >>>> >> uses the >> >> >>>>>>> >>>> >> new >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 >> >> >>>>>>> >>>> >> screenshot, >> >> >>>>>>> >>>> >> the >> >> >>>>>>> >>>> >> plain >> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one >> >> >>>>>>> >>>> >> is >> >> >>>>>>> >>>> >> not >> >> >>>>>>> >>>> >> showing >> >> >>>>>>> >>>> >> the volume. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Versions used: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >>>>>>> >>>> >> Qt 5.5.1 >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >>>>>>> >>>> >> Qt 5.6.2 >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my >> >> >>>>>>> >>>> >> build >> >> >>>>>>> >>>> >> of the >> >> >>>>>>> >>>> >> test >> >> >>>>>>> >>>> >> case if you want. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >> >> >>>>>>> >>>> >> reported >> >> >>>>>>> >>>> >> and >> >> >>>>>>> >>>> >> got solved in my other thread. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >> >>>>>>> >>>> >> Elvis >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> main.cpp: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >> >>>>>>> >>>> >> { >> >> >>>>>>> >>>> >> auto defaultFormat = >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >> >>>>>>> >>>> >> vtkNew colorFunction; >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >> >>>>>>> >>>> >> std::fill_n(static_cast> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >> >>>>>>> >>>> >> 8000000, 0.01); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volumeMapper; >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volume; >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >> >>>>>>> >>>> >> vtkNew window; >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >> >>>>>>> >>>> >> widget->show(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> return app.exec(); >> >> >>>>>>> >>>> >> } else { >> >> >>>>>>> >>>> >> // Render with "plain" render window / >> >> >>>>>>> >>>> >> interactor >> >> >>>>>>> >>>> >> vtkNew window; >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew interactor; >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >> >>>>>>> >>>> >> interactor->Start(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> return 0; >> >> >>>>>>> >>>> >> } >> >> >>>>>>> >>>> >> } >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> project(TestCase) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >>>>>>> >>>> >> REQUIRED >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >>>>>>> >>>> >> Qt5::Widgets >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> _______________________________________________ >> >> >>>>>>> >>>> >> 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: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> > -- >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Sankhesh Jhaveri >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >>>> > 881-4417 >> >> >>>>>>> >>> >> >> >>>>>>> >>> -- >> >> >>>>>>> >>> >> >> >>>>>>> >>> Sankhesh Jhaveri >> >> >>>>>>> >>> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >>> 881-4417 >> >> >>>>>>> >> >> >> >>>>>>> >> -- >> >> >>>>>>> >> >> >> >>>>>>> >> Sankhesh Jhaveri >> >> >>>>>>> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >> 881-4417 >> >> >>>>>>> _______________________________________________ >> >> >>>>>>> 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: >> >> >>>>>>> http://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: >> >> >>>>> http://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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > >> > >> > >> > -- >> > Ken Martin PhD >> > Distinguished Engineer >> > Kitware Inc. >> > 28 Corporate Drive >> > Clifton Park NY 12065 >> > >> > 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. > > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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. From elvis.stansvik at orexplore.com Sun May 28 11:30:37 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sun, 28 May 2017 17:30:37 +0200 Subject: [vtk-developers] Should VTK targets have INTERFACE_{INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS} set? Message-ID: Hi all, When linking against a VTK module through an imported target, e.g find_package(VTK 8.0.0 REQUIRED COMPONENTS vtkCommonCore) ... target_link_libraries(myapp vtkCommonCore) I must still manually make sure I use target_include_directories(myapp PUBLIC ${VTK_INCLUDE_DIRS}) ... target_compile_definitions(myapp PUBLIC ${VTK_DEFINITIONS}) to get the include directories and definitions. This is in contrast to e.g. Qt's CMake files, which makes sure targets have INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS set on its targets. For example, QtSvg (from Qt5SvgConfig.cmake): set_property(TARGET Qt5::Svg PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${_Qt5Svg_OWN_INCLUDE_DIRS}) set_property(TARGET Qt5::Svg PROPERTY INTERFACE_COMPILE_DEFINITIONS QT_SVG_LIB) Now, this is not really a bit inconvenience, I just have to make sure to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS}. However, I recently started using the libclang-based include-what-you-use tool [1] to help sanitize my header inclusions. The tool will make suggestions such as (taking a Qt header as example here): /home/estan/orexplore/insight/src/model/HoleLoader.cpp should add these lines: #include // for QFileInfo I noticed that for a VTK header, it'll instead suggest e.g: /home/estan/orexplore/insight/src/model/Hole.cpp should add these lines: #include "vtkSmartPointer.h" // for vtkSmartPointer Notice the "" instead of <>. I dug into include-what-you-use to find out why this is happening, and it's because on the compile line, the Qt include directories are given with -isystem, while the VTK include directories are given with -I, and -isystem vs -I is what the tool uses (for lack of other information) to determine whether to suggest the inclusion with <> or with "". I believe that maybe the -I flags added for VTK would become -isystem, if they were brought in through the INTERFACE_INCLUDE_DIRECTORIES mechanism, same as Qt. So all this lead me to two questions regarding VTK: 1. Should VTK's installed CMake files perhaps make sure INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_INCLUDE_DEFINITIONS are set on its exported targets? 2. If not, anyone know if there's something that could be done to make the flags end up as -isystem flags instead of -I when using ${VTK_INCLUDE_DIRS}? Cheers, Elvis [1] https://github.com/include-what-you-use/include-what-you-use From elvis.stansvik at orexplore.com Sun May 28 11:53:45 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sun, 28 May 2017 17:53:45 +0200 Subject: [vtk-developers] Should VTK targets have INTERFACE_{INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS} set? In-Reply-To: References: Message-ID: 2017-05-28 17:30 GMT+02:00 Elvis Stansvik : > Hi all, > > When linking against a VTK module through an imported target, e.g > > find_package(VTK 8.0.0 REQUIRED COMPONENTS vtkCommonCore) > ... > target_link_libraries(myapp vtkCommonCore) > > I must still manually make sure I use > > target_include_directories(myapp PUBLIC ${VTK_INCLUDE_DIRS}) > ... > target_compile_definitions(myapp PUBLIC ${VTK_DEFINITIONS}) > > to get the include directories and definitions. > > This is in contrast to e.g. Qt's CMake files, which makes sure targets > have INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS > set on its targets. For example, QtSvg (from Qt5SvgConfig.cmake): > > set_property(TARGET Qt5::Svg PROPERTY > INTERFACE_INCLUDE_DIRECTORIES ${_Qt5Svg_OWN_INCLUDE_DIRS}) > set_property(TARGET Qt5::Svg PROPERTY > INTERFACE_COMPILE_DEFINITIONS QT_SVG_LIB) > > Now, this is not really a bit inconvenience, I just have to make sure > to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS}. > > However, I recently started using the libclang-based > include-what-you-use tool [1] to help sanitize my header inclusions. > The tool will make suggestions such as (taking a Qt header as example > here): > > /home/estan/orexplore/insight/src/model/HoleLoader.cpp should add these lines: > #include // for QFileInfo > > I noticed that for a VTK header, it'll instead suggest e.g: > > /home/estan/orexplore/insight/src/model/Hole.cpp should add these lines: > #include "vtkSmartPointer.h" // for vtkSmartPointer > > Notice the "" instead of <>. > > I dug into include-what-you-use to find out why this is happening, and > it's because on the compile line, the Qt include directories are given > with -isystem, while the VTK include directories are given with -I, > and -isystem vs -I is what the tool uses (for lack of other > information) to determine whether to suggest the inclusion with <> or > with "". > > I believe that maybe the -I flags added for VTK would become -isystem, > if they were brought in through the INTERFACE_INCLUDE_DIRECTORIES > mechanism, same as Qt. > > So all this lead me to two questions regarding VTK: > > 1. Should VTK's installed CMake files perhaps make sure > INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_INCLUDE_DEFINITIONS are > set on its exported targets? > > 2. If not, anyone know if there's something that could be done to make > the flags end up as -isystem flags instead of -I when using > ${VTK_INCLUDE_DIRS}? Disregard this question: I realized that I could simply use SYSTEM in my target_include_directories(...) to make CMake treat it as a system include directory, which makes it use -isystem on compilers that support it. So then it's only question 1 left. I think it would be nice to have INTERFACE_{INCLUDE_DIRECTORIES,DEFINITIONS} set on the targets, just to avoid having to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS} manually. Elvis > > Cheers, > Elvis > > [1] https://github.com/include-what-you-use/include-what-you-use From elvis.stansvik at orexplore.com Mon May 29 04:49:28 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 10:49:28 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: Message-ID: 2017-05-26 12:52 GMT+02:00 Elvis Stansvik : > Hi all, > > We're using > > vtkColorTransferFunctionItem > vtkColorTransferControlPointsItem > > vtkCompositeTransferFunctionItem > vtkCompositeControlPointsItem > > in a vtkChartXY for editing of color/opacity transfer functions, > similar I believe to what ParaView does. > > I noticed on a retina Mac that interaction seems off. Clicking one > place seems to lead to a response at the wrong point in the editor. > > Some experimenting later, it seems that I can click in the upper half > of the composite editor (which we use for opacity), and I get a > response at the corresponding place in the lower half of it. > > Anyone seen this and know if there's something I can do about it? It's > a showstopper for our application on Mac. > > In the color editor (the vtkColorTransferFunctionItem / > vtkColorTransferControlPointsItem pair), I can't get a response at all > :/ > > Grateful for any tips from people using these classes on retina Mac. > > We're using VTK 8.0.0.rc1. I tried PV 5.4-RC3 on the Mac, and there the editors work alright, so I must be doing something wrong. I'll have a look at the PV code to see what I'm missing (pointers welcome). Elvis > > Elvis From elvis.stansvik at orexplore.com Mon May 29 05:40:06 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 11:40:06 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: Message-ID: 2017-05-29 10:49 GMT+02:00 Elvis Stansvik : > 2017-05-26 12:52 GMT+02:00 Elvis Stansvik : >> Hi all, >> >> We're using >> >> vtkColorTransferFunctionItem >> vtkColorTransferControlPointsItem >> >> vtkCompositeTransferFunctionItem >> vtkCompositeControlPointsItem >> >> in a vtkChartXY for editing of color/opacity transfer functions, >> similar I believe to what ParaView does. >> >> I noticed on a retina Mac that interaction seems off. Clicking one >> place seems to lead to a response at the wrong point in the editor. >> >> Some experimenting later, it seems that I can click in the upper half >> of the composite editor (which we use for opacity), and I get a >> response at the corresponding place in the lower half of it. >> >> Anyone seen this and know if there's something I can do about it? It's >> a showstopper for our application on Mac. >> >> In the color editor (the vtkColorTransferFunctionItem / >> vtkColorTransferControlPointsItem pair), I can't get a response at all >> :/ >> >> Grateful for any tips from people using these classes on retina Mac. >> >> We're using VTK 8.0.0.rc1. > > I tried PV 5.4-RC3 on the Mac, and there the editors work alright, so > I must be doing something wrong. > > I'll have a look at the PV code to see what I'm missing (pointers welcome). Hm, the only thing I can see that PV was doing differently is calling setEnableHiDPI(true). I tried doing this myself. That made the text in the chart the correct size (it was wrong before), but I'm still having the strange mouse click offset problem (the click is registered in the wrong place). Any ideas? Elvis > > Elvis > >> >> Elvis From elvis.stansvik at orexplore.com Mon May 29 05:42:54 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 11:42:54 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: Message-ID: 2017-05-29 11:40 GMT+02:00 Elvis Stansvik : > 2017-05-29 10:49 GMT+02:00 Elvis Stansvik : >> 2017-05-26 12:52 GMT+02:00 Elvis Stansvik : >>> Hi all, >>> >>> We're using >>> >>> vtkColorTransferFunctionItem >>> vtkColorTransferControlPointsItem >>> >>> vtkCompositeTransferFunctionItem >>> vtkCompositeControlPointsItem >>> >>> in a vtkChartXY for editing of color/opacity transfer functions, >>> similar I believe to what ParaView does. >>> >>> I noticed on a retina Mac that interaction seems off. Clicking one >>> place seems to lead to a response at the wrong point in the editor. >>> >>> Some experimenting later, it seems that I can click in the upper half >>> of the composite editor (which we use for opacity), and I get a >>> response at the corresponding place in the lower half of it. >>> >>> Anyone seen this and know if there's something I can do about it? It's >>> a showstopper for our application on Mac. >>> >>> In the color editor (the vtkColorTransferFunctionItem / >>> vtkColorTransferControlPointsItem pair), I can't get a response at all >>> :/ >>> >>> Grateful for any tips from people using these classes on retina Mac. >>> >>> We're using VTK 8.0.0.rc1. >> >> I tried PV 5.4-RC3 on the Mac, and there the editors work alright, so >> I must be doing something wrong. >> >> I'll have a look at the PV code to see what I'm missing (pointers welcome). > > Hm, the only thing I can see that PV was doing differently is calling > setEnableHiDPI(true). > > I tried doing this myself. That made the text in the chart the correct > size (it was wrong before), but I'm still having the strange mouse > click offset problem (the click is registered in the wrong place). > > Any ideas? Ah, if I just resize the widget holding these editors a little, the behavior is correct from then on. So it must be some initialization problem, the editors are confused about their size on first show somehow. I'm sure I'll figure this out now, sorry for the noise. Elvis > > Elvis > >> >> Elvis >> >>> >>> Elvis From sebastien.jourdain at kitware.com Mon May 29 09:26:21 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Mon, 29 May 2017 07:26:21 -0600 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: Message-ID: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> You need to set the size on the interactor. > On May 29, 2017, at 03:42, Elvis Stansvik wrote: > > 2017-05-29 11:40 GMT+02:00 Elvis Stansvik : >> 2017-05-29 10:49 GMT+02:00 Elvis Stansvik : >>> 2017-05-26 12:52 GMT+02:00 Elvis Stansvik : >>>> Hi all, >>>> >>>> We're using >>>> >>>> vtkColorTransferFunctionItem >>>> vtkColorTransferControlPointsItem >>>> >>>> vtkCompositeTransferFunctionItem >>>> vtkCompositeControlPointsItem >>>> >>>> in a vtkChartXY for editing of color/opacity transfer functions, >>>> similar I believe to what ParaView does. >>>> >>>> I noticed on a retina Mac that interaction seems off. Clicking one >>>> place seems to lead to a response at the wrong point in the editor. >>>> >>>> Some experimenting later, it seems that I can click in the upper half >>>> of the composite editor (which we use for opacity), and I get a >>>> response at the corresponding place in the lower half of it. >>>> >>>> Anyone seen this and know if there's something I can do about it? It's >>>> a showstopper for our application on Mac. >>>> >>>> In the color editor (the vtkColorTransferFunctionItem / >>>> vtkColorTransferControlPointsItem pair), I can't get a response at all >>>> :/ >>>> >>>> Grateful for any tips from people using these classes on retina Mac. >>>> >>>> We're using VTK 8.0.0.rc1. >>> >>> I tried PV 5.4-RC3 on the Mac, and there the editors work alright, so >>> I must be doing something wrong. >>> >>> I'll have a look at the PV code to see what I'm missing (pointers welcome). >> >> Hm, the only thing I can see that PV was doing differently is calling >> setEnableHiDPI(true). >> >> I tried doing this myself. That made the text in the chart the correct >> size (it was wrong before), but I'm still having the strange mouse >> click offset problem (the click is registered in the wrong place). >> >> Any ideas? > > Ah, if I just resize the widget holding these editors a little, the > behavior is correct from then on. > > So it must be some initialization problem, the editors are confused > about their size on first show somehow. > > I'm sure I'll figure this out now, sorry for the noise. > > Elvis > >> >> Elvis >> >>> >>> Elvis >>> >>>> >>>> Elvis > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Mon May 29 09:32:06 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 15:32:06 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain : > You need to set the size on the interactor. Ah, how do I do that? (sorry for being a bit dumb) I've been scouring over the PV code, and I can't see that it does anything special with its interactor. It seems to just hook it up: https://gitlab.kitware.com/paraview/paraview/blob/master/Qt/Components/pqTransferFunctionWidget.cxx#L207 Elvis > >> On May 29, 2017, at 03:42, Elvis Stansvik wrote: >> >> 2017-05-29 11:40 GMT+02:00 Elvis Stansvik : >>> 2017-05-29 10:49 GMT+02:00 Elvis Stansvik : >>>> 2017-05-26 12:52 GMT+02:00 Elvis Stansvik : >>>>> Hi all, >>>>> >>>>> We're using >>>>> >>>>> vtkColorTransferFunctionItem >>>>> vtkColorTransferControlPointsItem >>>>> >>>>> vtkCompositeTransferFunctionItem >>>>> vtkCompositeControlPointsItem >>>>> >>>>> in a vtkChartXY for editing of color/opacity transfer functions, >>>>> similar I believe to what ParaView does. >>>>> >>>>> I noticed on a retina Mac that interaction seems off. Clicking one >>>>> place seems to lead to a response at the wrong point in the editor. >>>>> >>>>> Some experimenting later, it seems that I can click in the upper half >>>>> of the composite editor (which we use for opacity), and I get a >>>>> response at the corresponding place in the lower half of it. >>>>> >>>>> Anyone seen this and know if there's something I can do about it? It's >>>>> a showstopper for our application on Mac. >>>>> >>>>> In the color editor (the vtkColorTransferFunctionItem / >>>>> vtkColorTransferControlPointsItem pair), I can't get a response at all >>>>> :/ >>>>> >>>>> Grateful for any tips from people using these classes on retina Mac. >>>>> >>>>> We're using VTK 8.0.0.rc1. >>>> >>>> I tried PV 5.4-RC3 on the Mac, and there the editors work alright, so >>>> I must be doing something wrong. >>>> >>>> I'll have a look at the PV code to see what I'm missing (pointers welcome). >>> >>> Hm, the only thing I can see that PV was doing differently is calling >>> setEnableHiDPI(true). >>> >>> I tried doing this myself. That made the text in the chart the correct >>> size (it was wrong before), but I'm still having the strange mouse >>> click offset problem (the click is registered in the wrong place). >>> >>> Any ideas? >> >> Ah, if I just resize the widget holding these editors a little, the >> behavior is correct from then on. >> >> So it must be some initialization problem, the editors are confused >> about their size on first show somehow. >> >> I'm sure I'll figure this out now, sorry for the noise. >> >> Elvis >> >>> >>> Elvis >>> >>>> >>>> Elvis >>>> >>>>> >>>>> Elvis >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> From sebastien.jourdain at kitware.com Mon May 29 09:51:03 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Mon, 29 May 2017 07:51:03 -0600 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: <118B4729-0373-4734-B738-4CC45B9E6877@kitware.com> I don't know (didn't look) but it is that way for the vtkRenderWindow too. > On May 29, 2017, at 07:32, Elvis Stansvik wrote: > > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain : >> You need to set the size on the interactor. > > Ah, how do I do that? (sorry for being a bit dumb) > > I've been scouring over the PV code, and I can't see that it does > anything special with its interactor. It seems to just hook it up: > > https://gitlab.kitware.com/paraview/paraview/blob/master/Qt/Components/pqTransferFunctionWidget.cxx#L207 > > Elvis > >> >>> On May 29, 2017, at 03:42, Elvis Stansvik wrote: >>> >>> 2017-05-29 11:40 GMT+02:00 Elvis Stansvik : >>>> 2017-05-29 10:49 GMT+02:00 Elvis Stansvik : >>>>> 2017-05-26 12:52 GMT+02:00 Elvis Stansvik : >>>>>> Hi all, >>>>>> >>>>>> We're using >>>>>> >>>>>> vtkColorTransferFunctionItem >>>>>> vtkColorTransferControlPointsItem >>>>>> >>>>>> vtkCompositeTransferFunctionItem >>>>>> vtkCompositeControlPointsItem >>>>>> >>>>>> in a vtkChartXY for editing of color/opacity transfer functions, >>>>>> similar I believe to what ParaView does. >>>>>> >>>>>> I noticed on a retina Mac that interaction seems off. Clicking one >>>>>> place seems to lead to a response at the wrong point in the editor. >>>>>> >>>>>> Some experimenting later, it seems that I can click in the upper half >>>>>> of the composite editor (which we use for opacity), and I get a >>>>>> response at the corresponding place in the lower half of it. >>>>>> >>>>>> Anyone seen this and know if there's something I can do about it? It's >>>>>> a showstopper for our application on Mac. >>>>>> >>>>>> In the color editor (the vtkColorTransferFunctionItem / >>>>>> vtkColorTransferControlPointsItem pair), I can't get a response at all >>>>>> :/ >>>>>> >>>>>> Grateful for any tips from people using these classes on retina Mac. >>>>>> >>>>>> We're using VTK 8.0.0.rc1. >>>>> >>>>> I tried PV 5.4-RC3 on the Mac, and there the editors work alright, so >>>>> I must be doing something wrong. >>>>> >>>>> I'll have a look at the PV code to see what I'm missing (pointers welcome). >>>> >>>> Hm, the only thing I can see that PV was doing differently is calling >>>> setEnableHiDPI(true). >>>> >>>> I tried doing this myself. That made the text in the chart the correct >>>> size (it was wrong before), but I'm still having the strange mouse >>>> click offset problem (the click is registered in the wrong place). >>>> >>>> Any ideas? >>> >>> Ah, if I just resize the widget holding these editors a little, the >>> behavior is correct from then on. >>> >>> So it must be some initialization problem, the editors are confused >>> about their size on first show somehow. >>> >>> I'm sure I'll figure this out now, sorry for the noise. >>> >>> Elvis >>> >>>> >>>> Elvis >>>> >>>>> >>>>> Elvis >>>>> >>>>>> >>>>>> Elvis >>> _______________________________________________ >>> 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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> From marcus.hanwell at kitware.com Mon May 29 11:06:57 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 29 May 2017 11:06:57 -0400 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik wrote: > > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain : > > You need to set the size on the interactor. > > Ah, how do I do that? (sorry for being a bit dumb) > > I've been scouring over the PV code, and I can't see that it does > anything special with its interactor. It seems to just hook it up: > I assume you are using QVTKOpenGLWidget, we use this directly in Tomviz for a few charts that control color/opacity too. This should be handled in the QVTKOpenGLWidget, but it is possible an initialization bug has crept in. I have noticed that ParaView often doesn't see this issues as much due to resizing Qt widgets several times on startup, I will see if I can get some time to test the latest Tomviz (we had this working, but I haven't been tracking VTK master as closely these last few weeks). From utkarsh.ayachit at kitware.com Mon May 29 11:34:28 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 29 May 2017 11:34:28 -0400 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: I suspect there's a bug in Qt when it comes to reparenting QOpenGLWidget. I can reproduce an issue with ParaView on linux when I simply undock the Color Map Editor and then redock it. The Color/Opacity widgets stay black. Looking at the code, I see this [1] happens when the dock widget is docked back into the main window. As expected the OpenGL context is destroyed, and QVTKOpenGLWIdget correctly does the cleanup. But the QVTKOpenGLWidget never gets a follow on paintGL call (unless I mouse over to resize the dock panel manually). Thus QVTKOpenGLWidget new repaints into the newly minted OpenGLContext/FBO resulting in a black widget. Utkarsh [1] https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qopenglwidget.cpp.html#1418 On Mon, May 29, 2017 at 11:06 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik > wrote: > > > > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain < > sebastien.jourdain at kitware.com>: > > > You need to set the size on the interactor. > > > > Ah, how do I do that? (sorry for being a bit dumb) > > > > I've been scouring over the PV code, and I can't see that it does > > anything special with its interactor. It seems to just hook it up: > > > I assume you are using QVTKOpenGLWidget, we use this directly in > Tomviz for a few charts that control color/opacity too. This should be > handled in the QVTKOpenGLWidget, but it is possible an initialization > bug has crept in. I have noticed that ParaView often doesn't see this > issues as much due to resizing Qt widgets several times on startup, I > will see if I can get some time to test the latest Tomviz (we had this > working, but I haven't been tracking VTK master as closely these last > few weeks). > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Mon May 29 11:35:50 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 17:35:50 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: 2017-05-29 17:06 GMT+02:00 Marcus D. Hanwell : > On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik > wrote: >> >> 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain : >> > You need to set the size on the interactor. >> >> Ah, how do I do that? (sorry for being a bit dumb) >> >> I've been scouring over the PV code, and I can't see that it does >> anything special with its interactor. It seems to just hook it up: >> > I assume you are using QVTKOpenGLWidget, we use this directly in > Tomviz for a few charts that control color/opacity too. This should be > handled in the QVTKOpenGLWidget, but it is possible an initialization > bug has crept in. I have noticed that ParaView often doesn't see this > issues as much due to resizing Qt widgets several times on startup, I > will see if I can get some time to test the latest Tomviz (we had this > working, but I haven't been tracking VTK master as closely these last > few weeks). Yep, using QVTKOpenGLWidget. Ah yes, I was able to do some findings (gotto go home now though): My situation is that the color/opacity editors are initially hidden, and I only show them in response to a user checking a checkbox. If in in my two widgets, I reimplement showEvent(..) and add GetInteractor()->UpdateSize(width() * window()->windowHandle()->devicePixelRatio(), height() * window()->windowHandle()->devicePixelRatio()); GetInteractor()->InvokeEvent(vtkCommand::ConfigureEvent, NULL); then it seems I get correct interactor size when showing them for the first time. Not sure if some machinery in vtkCocoaRenderWindow is insufficient. It seems to do the above in response to NSViewFrameDidChangeNotification. Elvis From marcus.hanwell at kitware.com Mon May 29 11:38:43 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 29 May 2017 11:38:43 -0400 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: On Mon, May 29, 2017 at 11:35 AM, Elvis Stansvik wrote: > 2017-05-29 17:06 GMT+02:00 Marcus D. Hanwell : >> On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik >> wrote: >>> >>> 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain : >>> > You need to set the size on the interactor. >>> >>> Ah, how do I do that? (sorry for being a bit dumb) >>> >>> I've been scouring over the PV code, and I can't see that it does >>> anything special with its interactor. It seems to just hook it up: >>> >> I assume you are using QVTKOpenGLWidget, we use this directly in >> Tomviz for a few charts that control color/opacity too. This should be >> handled in the QVTKOpenGLWidget, but it is possible an initialization >> bug has crept in. I have noticed that ParaView often doesn't see this >> issues as much due to resizing Qt widgets several times on startup, I >> will see if I can get some time to test the latest Tomviz (we had this >> working, but I haven't been tracking VTK master as closely these last >> few weeks). > > Yep, using QVTKOpenGLWidget. > > Ah yes, I was able to do some findings (gotto go home now though): > > My situation is that the color/opacity editors are initially hidden, > and I only show them in response to a user checking a checkbox. > > If in in my two widgets, I reimplement showEvent(..) and add > > GetInteractor()->UpdateSize(width() * > window()->windowHandle()->devicePixelRatio(), > height() * window()->windowHandle()->devicePixelRatio()); > GetInteractor()->InvokeEvent(vtkCommand::ConfigureEvent, NULL); > > then it seems I get correct interactor size when showing them for the > first time. > > Not sure if some machinery in vtkCocoaRenderWindow is insufficient. It > seems to do the above in response to NSViewFrameDidChangeNotification. > I think ensuring this happens in showEvent could be a good addition, this might catch some situations we are missing. From elvis.stansvik at orexplore.com Mon May 29 11:39:22 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 17:39:22 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: 2017-05-29 17:34 GMT+02:00 Utkarsh Ayachit : > I suspect there's a bug in Qt when it comes to reparenting QOpenGLWidget. I > can reproduce an issue with ParaView on linux when I simply undock the Color > Map Editor and then redock it. The Color/Opacity widgets stay black. Looking > at the code, I see this [1] happens when the dock widget is docked back into > the main window. As expected the OpenGL context is destroyed, and > QVTKOpenGLWIdget correctly does the cleanup. But the QVTKOpenGLWidget never > gets a follow on paintGL call (unless I mouse over to resize the dock panel > manually). Thus QVTKOpenGLWidget new repaints into the newly minted > OpenGLContext/FBO resulting in a black widget. Ah, in my case I don't think there's reparenting involved though. My problem was that the interactor's size was never updated to cover the render window when it was initially shown (I think), see my other mail just now. Gotto head home, but will debug more tomorrow. Elvis > > Utkarsh > > [1] > https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qopenglwidget.cpp.html#1418 > > > On Mon, May 29, 2017 at 11:06 AM, Marcus D. Hanwell > wrote: >> >> On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik >> wrote: >> > >> > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain >> > : >> > > You need to set the size on the interactor. >> > >> > Ah, how do I do that? (sorry for being a bit dumb) >> > >> > I've been scouring over the PV code, and I can't see that it does >> > anything special with its interactor. It seems to just hook it up: >> > >> I assume you are using QVTKOpenGLWidget, we use this directly in >> Tomviz for a few charts that control color/opacity too. This should be >> handled in the QVTKOpenGLWidget, but it is possible an initialization >> bug has crept in. I have noticed that ParaView often doesn't see this >> issues as much due to resizing Qt widgets several times on startup, I >> will see if I can get some time to test the latest Tomviz (we had this >> working, but I haven't been tracking VTK master as closely these last >> few weeks). >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > From utkarsh.ayachit at kitware.com Mon May 29 12:40:04 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 29 May 2017 12:40:04 -0400 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: Here's a commit that hopefully removes the need for your `showEvent` override. https://gitlab.kitware.com/vtk/vtk/merge_requests/2885 Can you give it a try please? Thanks Utkarsh On Mon, May 29, 2017 at 11:39 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-29 17:34 GMT+02:00 Utkarsh Ayachit : > > I suspect there's a bug in Qt when it comes to reparenting > QOpenGLWidget. I > > can reproduce an issue with ParaView on linux when I simply undock the > Color > > Map Editor and then redock it. The Color/Opacity widgets stay black. > Looking > > at the code, I see this [1] happens when the dock widget is docked back > into > > the main window. As expected the OpenGL context is destroyed, and > > QVTKOpenGLWIdget correctly does the cleanup. But the QVTKOpenGLWidget > never > > gets a follow on paintGL call (unless I mouse over to resize the dock > panel > > manually). Thus QVTKOpenGLWidget new repaints into the newly minted > > OpenGLContext/FBO resulting in a black widget. > > Ah, in my case I don't think there's reparenting involved though. > > My problem was that the interactor's size was never updated to cover > the render window when it was initially shown (I think), see my other > mail just now. > > Gotto head home, but will debug more tomorrow. > > Elvis > > > > > Utkarsh > > > > [1] > > https://code.woboq.org/qt5/qtbase/src/widgets/kernel/ > qopenglwidget.cpp.html#1418 > > > > > > On Mon, May 29, 2017 at 11:06 AM, Marcus D. Hanwell > > wrote: > >> > >> On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik > >> wrote: > >> > > >> > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain > >> > : > >> > > You need to set the size on the interactor. > >> > > >> > Ah, how do I do that? (sorry for being a bit dumb) > >> > > >> > I've been scouring over the PV code, and I can't see that it does > >> > anything special with its interactor. It seems to just hook it up: > >> > > >> I assume you are using QVTKOpenGLWidget, we use this directly in > >> Tomviz for a few charts that control color/opacity too. This should be > >> handled in the QVTKOpenGLWidget, but it is possible an initialization > >> bug has crept in. I have noticed that ParaView often doesn't see this > >> issues as much due to resizing Qt widgets several times on startup, I > >> will see if I can get some time to test the latest Tomviz (we had this > >> working, but I haven't been tracking VTK master as closely these last > >> few weeks). > >> _______________________________________________ > >> 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: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Mon May 29 13:03:23 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 29 May 2017 19:03:23 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: 2017-05-29 18:40 GMT+02:00 Utkarsh Ayachit : > Here's a commit that hopefully removes the need for your `showEvent` > override. > https://gitlab.kitware.com/vtk/vtk/merge_requests/2885 Whoa, you whipped that up as I was on the bus home, excellent :) Sounds like that is the proper fix. I'll test it tomorrow when I'm back at the Mac at work. Elvis > > Can you give it a try please? > > Thanks > Utkarsh > > On Mon, May 29, 2017 at 11:39 AM, Elvis Stansvik > wrote: >> >> 2017-05-29 17:34 GMT+02:00 Utkarsh Ayachit : >> > I suspect there's a bug in Qt when it comes to reparenting >> > QOpenGLWidget. I >> > can reproduce an issue with ParaView on linux when I simply undock the >> > Color >> > Map Editor and then redock it. The Color/Opacity widgets stay black. >> > Looking >> > at the code, I see this [1] happens when the dock widget is docked back >> > into >> > the main window. As expected the OpenGL context is destroyed, and >> > QVTKOpenGLWIdget correctly does the cleanup. But the QVTKOpenGLWidget >> > never >> > gets a follow on paintGL call (unless I mouse over to resize the dock >> > panel >> > manually). Thus QVTKOpenGLWidget new repaints into the newly minted >> > OpenGLContext/FBO resulting in a black widget. >> >> Ah, in my case I don't think there's reparenting involved though. >> >> My problem was that the interactor's size was never updated to cover >> the render window when it was initially shown (I think), see my other >> mail just now. >> >> Gotto head home, but will debug more tomorrow. >> >> Elvis >> >> > >> > Utkarsh >> > >> > [1] >> > >> > https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qopenglwidget.cpp.html#1418 >> > >> > >> > On Mon, May 29, 2017 at 11:06 AM, Marcus D. Hanwell >> > wrote: >> >> >> >> On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik >> >> wrote: >> >> > >> >> > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain >> >> > : >> >> > > You need to set the size on the interactor. >> >> > >> >> > Ah, how do I do that? (sorry for being a bit dumb) >> >> > >> >> > I've been scouring over the PV code, and I can't see that it does >> >> > anything special with its interactor. It seems to just hook it up: >> >> > >> >> I assume you are using QVTKOpenGLWidget, we use this directly in >> >> Tomviz for a few charts that control color/opacity too. This should be >> >> handled in the QVTKOpenGLWidget, but it is possible an initialization >> >> bug has crept in. I have noticed that ParaView often doesn't see this >> >> issues as much due to resizing Qt widgets several times on startup, I >> >> will see if I can get some time to test the latest Tomviz (we had this >> >> working, but I haven't been tracking VTK master as closely these last >> >> few weeks). >> >> _______________________________________________ >> >> 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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > From elvis.stansvik at orexplore.com Tue May 30 03:10:24 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 30 May 2017 09:10:24 +0200 Subject: [vtk-developers] Interaction with color/opacity editors in vtkChartXY broken on retina display In-Reply-To: References: <321E1BCB-2217-4FA1-B2CD-EE8BE6D6704D@kitware.com> Message-ID: 2017-05-29 18:40 GMT+02:00 Utkarsh Ayachit : > Here's a commit that hopefully removes the need for your `showEvent` > override. > https://gitlab.kitware.com/vtk/vtk/merge_requests/2885 > > Can you give it a try please? That fixes it indeed. Thanks! +2 Elvis > > Thanks > Utkarsh > > On Mon, May 29, 2017 at 11:39 AM, Elvis Stansvik > wrote: >> >> 2017-05-29 17:34 GMT+02:00 Utkarsh Ayachit : >> > I suspect there's a bug in Qt when it comes to reparenting >> > QOpenGLWidget. I >> > can reproduce an issue with ParaView on linux when I simply undock the >> > Color >> > Map Editor and then redock it. The Color/Opacity widgets stay black. >> > Looking >> > at the code, I see this [1] happens when the dock widget is docked back >> > into >> > the main window. As expected the OpenGL context is destroyed, and >> > QVTKOpenGLWIdget correctly does the cleanup. But the QVTKOpenGLWidget >> > never >> > gets a follow on paintGL call (unless I mouse over to resize the dock >> > panel >> > manually). Thus QVTKOpenGLWidget new repaints into the newly minted >> > OpenGLContext/FBO resulting in a black widget. >> >> Ah, in my case I don't think there's reparenting involved though. >> >> My problem was that the interactor's size was never updated to cover >> the render window when it was initially shown (I think), see my other >> mail just now. >> >> Gotto head home, but will debug more tomorrow. >> >> Elvis >> >> > >> > Utkarsh >> > >> > [1] >> > >> > https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qopenglwidget.cpp.html#1418 >> > >> > >> > On Mon, May 29, 2017 at 11:06 AM, Marcus D. Hanwell >> > wrote: >> >> >> >> On Mon, May 29, 2017 at 9:32 AM, Elvis Stansvik >> >> wrote: >> >> > >> >> > 2017-05-29 15:26 GMT+02:00 Sebastien Jourdain >> >> > : >> >> > > You need to set the size on the interactor. >> >> > >> >> > Ah, how do I do that? (sorry for being a bit dumb) >> >> > >> >> > I've been scouring over the PV code, and I can't see that it does >> >> > anything special with its interactor. It seems to just hook it up: >> >> > >> >> I assume you are using QVTKOpenGLWidget, we use this directly in >> >> Tomviz for a few charts that control color/opacity too. This should be >> >> handled in the QVTKOpenGLWidget, but it is possible an initialization >> >> bug has crept in. I have noticed that ParaView often doesn't see this >> >> issues as much due to resizing Qt widgets several times on startup, I >> >> will see if I can get some time to test the latest Tomviz (we had this >> >> working, but I haven't been tracking VTK master as closely these last >> >> few weeks). >> >> _______________________________________________ >> >> 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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > From ken.martin at kitware.com Tue May 30 08:10:08 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 30 May 2017 08:10:08 -0400 Subject: [vtk-developers] Karego broken Message-ID: Something broke karego nightly submissions last Tuesday and they are still broken. The configure error is CMake Error at CMake/vtkModuleMacros.cmake:559 (target_compile_features): The compiler feature "cxx_override" is not known to CXX compiler "GNU" version 4.6.3. Call Stack (most recent call first): CMake/vtkModuleMacros.cmake:661 (vtk_add_library) Common/Core/CMakeLists.txt:726 (vtk_module_library) Ring a bell with anyone? -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 robert.maynard at kitware.com Tue May 30 08:18:54 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 30 May 2017 08:18:54 -0400 Subject: [vtk-developers] Karego broken In-Reply-To: References: Message-ID: Hi Ken, This was caused by the changes required to explicitly require a C++11 compiler. The compiler on Karego is too old, so we need to either upgrade the compiler to GCC 4.8 or we need to move the builds to a new machine. On Tue, May 30, 2017 at 8:10 AM, Ken Martin wrote: > Something broke karego nightly submissions last Tuesday and they are still > broken. The configure error is > > CMake Error at CMake/vtkModuleMacros.cmake:559 (target_compile_features): > The compiler feature "cxx_override" is not known to CXX compiler > > "GNU" > > version 4.6.3. > Call Stack (most recent call first): > CMake/vtkModuleMacros.cmake:661 (vtk_add_library) > Common/Core/CMakeLists.txt:726 (vtk_module_library) > > > Ring a bell with anyone? > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue May 30 08:50:19 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 30 May 2017 14:50:19 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-26 14:35 GMT+02:00 Ken Martin : > If you have a build of QT I think you could change > > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 > > const int requestedVersion = qMin((format.majorVersion() << 8) + > format.minorVersion(), > staticContext.defaultFormat.version); > > to be > > const int requestedVersion = (format.majorVersion() << 8) + > format.minorVersion()); > > and it would fix it for VTK/ParaView. Not sure if it has any other > consequences for Qt or if it would hit some different issue though. Qt on > windows does some tricky stuff to support OpenGL/Angle/ES2. > Today I tried first updating the Intel driver from 9.18.10.3272 (which the laptop came preinstalled with) to 10.18.10.4425, which is the latest vendor:ified version from Lenovo for this laptop (Thinkpad E540), but it didn't change anything. I then tried uninstalling the Lenovo one, to let me install the generic driver from Intel. The Intel driver update utility offered up 15.something, but in the end 10.18.14.4578 was what I got. And no luck, still the problem with volumes silently not showing up. So if your analysis is correct Ben, which it probably is, it's a real PITA since it means I'll have to patch and build Qt to get our program to work on these Intel laptops running Windows. Anyone know if there's anything VTK or our application could do to work around this bad logic in the Qt context initialization? It would be a lot less trouble to re-build VTK, since I'm already building that (naturally). Elvis > > > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik > wrote: >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin : >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is >> > a >> > Qt bug we already bumped into with Mesa. They have what looks to me like >> > some odd bad logic on windows for creating a context where they will not >> > give you a core context later than the latest compatibility context they >> > can >> > get. For some vendors that is fine but for others they only offer Comp >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed >> > that the issue would go away. I believe Ben filed a bug report with them >> > (Qt) when he bumped into this when using Mesa on Windows. >> >> Ah yes, that could definitely be it. I found Ben's bug: >> >> https://bugreports.qt.io/browse/QTBUG-60742 >> >> The affected version is listed as 5.8.0, but I'm having trouble on >> 5.6.2, so I guess the bad logic is there as well. >> >> So let's hope for a fix in Qt then. But in the meantime, is there >> anything you can think if that I could do to work around it? I really >> want our application to work on these kinds of machines (the one I >> have was picked as a sort of a baseline for us wrt to requirements). >> >> In the bug report Ben mentions hacking around it with >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >> using Mesa. >> >> Elvis >> >> > >> > >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >> > wrote: >> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> >> > Yes, I ran it both ways. >> >> > >> >> > It works when run without the argument in the plain VTK render >> >> > window, >> >> > and it is broken (shows nothing) when run with an argument. >> >> >> >> Alright, that's good. Then we're seeing the same thing. >> >> >> >> > Seems like it's definitely related to older Intel drivers on Windows. >> >> >> >> Yes, probably. >> >> >> >> > Not sure if there is an updated driver available for my machine. >> >> > Hesitant to try changing/updating it for other reasons, and sorry, >> >> > can't sacrifice this machine's current state for the purpose of >> >> > testing this out... >> >> >> >> No worries, I'm free to do as I please with the one I have, so I'll do >> >> some experimenting with different drivers when I'm back on Monday. >> >> >> >> Thanks to everyone trying this out. >> >> >> >> Elvis >> >> >> >> > >> >> > >> >> > D >> >> > >> >> > >> >> > >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> >> > wrote: >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> >> : >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> >> >>>> with an Intel HD Graphics 4000 running driver version >> >> >>>> 10.18.10.3316. >> >> >>>> I >> >> >>>> get your TestCase app window with nothing but an empty (white) >> >> >>>> client >> >> >>>> region. >> >> >>>> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >> >> >>>> VolumeSmartMapper works fine on this very same machine. >> >> >>>> >> >> >>>> Another data point... >> >> >> >> >> >> Just one more thing David, did you try also running the example >> >> >> without any argument on this machine? (That would make it use a >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> >> >> interesting to know if the volume shows up then. That would confirm >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >> >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> >> >> Elvis >> >> >> >> >> >>> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >> >> >>> David. >> >> >>> >> >> >>> And just to make sure, Aron, did you run the test case as "TestCase >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >> >>> >> >> >>> Elvis >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> D >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >> >>>> wrote: >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >> >> >>>>>> Hi Elvis, >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >> >> >>>>>> setup - both >> >> >>>>>> intel and nvidia graphics. >> >> >>>>>> With your test case, I'm able to see the volume running either >> >> >>>>>> with >> >> >>>>>> Intel or >> >> >>>>>> nVidia, so it doesn't repro for me. >> >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> >> >>>>>> Sorry, >> >> >>>>>> Aron >> >> >>>>> >> >> >>>>> Alright, bugger. Thanks for testing though! >> >> >>>>> >> >> >>>>> I won't be at the office until Monday again, but when I'm back >> >> >>>>> I'll >> >> >>>>> try experimenting with different driver versions. >> >> >>>>> >> >> >>>>> Elvis >> >> >>>>> >> >> >>>>>> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >> >>>>>>> : >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >> >>>>>>> > : >> >> >>>>>>> >> Hi Elvis, >> >> >>>>>>> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >> >>>>>>> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card >> >> >>>>>>> >> but >> >> >>>>>>> >> tried >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >> >> >>>>>>> >> (with an >> >> >>>>>>> >> Intel >> >> >>>>>>> >> HD5600). Worked fine. >> >> >>>>>>> > >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >> >> >>>>>>> > machine with >> >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >> >> >>>>>>> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >> >>>>>>> >> >> >>>>>>> I've now put up the compiled self-contained test case here: >> >> >>>>>>> >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >> >>>>>>> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + >> >> >>>>>>> Intel >> >> >>>>>>> graphics could try running this test case with "TestCase 1" and >> >> >>>>>>> see if >> >> >>>>>>> the volume shows up, that would be great. >> >> >>>>>>> >> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >> >>>>>>> >> >> >>>>>>> Elvis >> >> >>>>>>> >> >> >>>>>>> > >> >> >>>>>>> > I could put up my build of the test case as a self-contained >> >> >>>>>>> > .zip, to >> >> >>>>>>> > make it easy to test. >> >> >>>>>>> > >> >> >>>>>>> >> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics >> >> >>>>>>> >> drivers >> >> >>>>>>> >> on your >> >> >>>>>>> >> Windows machine may need updating. >> >> >>>>>>> > >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and >> >> >>>>>>> > just >> >> >>>>>>> > use a >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't >> >> >>>>>>> > that >> >> >>>>>>> > suggest that the drivers are capable enough, and that the >> >> >>>>>>> > problem is >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >> >>>>>>> > >> >> >>>>>>> > Elvis >> >> >>>>>>> > >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >> >>>>>>> >> wrote: >> >> >>>>>>> >>> >> >> >>>>>>> >>> Okay thanks. >> >> >>>>>>> >>> >> >> >>>>>>> >>> I?ll take a look. >> >> >>>>>>> >>> >> >> >>>>>>> >>> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >> >>>>>>> >>> wrote: >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >> >>>>>>> >>>> : >> >> >>>>>>> >>>> > Hi Elvis, >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary >> >> >>>>>>> >>>> > and >> >> >>>>>>> >>>> > test >> >> >>>>>>> >>>> > volume >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a >> >> >>>>>>> >>>> > test >> >> >>>>>>> >>>> > dataset. >> >> >>>>>>> >>>> > ParaView >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >> >> >>>>>>> >>>> > before diving >> >> >>>>>>> >>>> > into the >> >> >>>>>>> >>>> > code. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >> >> >>>>>>> >>>> case. The >> >> >>>>>>> >>>> volume won't show up. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> It does show up if I switch to the software based ray cast >> >> >>>>>>> >>>> mapper >> >> >>>>>>> >>>> (but >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the >> >> >>>>>>> >>>> GPU >> >> >>>>>>> >>>> one being >> >> >>>>>>> >>>> used). >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help >> >> >>>>>>> >>>> debugging. >> >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> Elvis >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Thanks, >> >> >>>>>>> >>>> > Sankhesh >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >> >>>>>>> >>>> > wrote: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Hi all, >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >> >> >>>>>>> >>>> >> rendered using >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, >> >> >>>>>>> >>>> >> Intel >> >> >>>>>>> >>>> >> graphics >> >> >>>>>>> >>>> >> (HD >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up >> >> >>>>>>> >>>> >> fine >> >> >>>>>>> >>>> >> on >> >> >>>>>>> >>>> >> Windows 7 >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning >> >> >>>>>>> >>>> >> off >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >> >>>>>>> >>>> >> QSurfaceFormat. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >> >> >>>>>>> >>>> >> attached >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and >> >> >>>>>>> >>>> >> "TestCase >> >> >>>>>>> >>>> >> 1" >> >> >>>>>>> >>>> >> (right). >> >> >>>>>>> >>>> >> The former uses a plain render window while the latter >> >> >>>>>>> >>>> >> uses the >> >> >>>>>>> >>>> >> new >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 >> >> >>>>>>> >>>> >> screenshot, >> >> >>>>>>> >>>> >> the >> >> >>>>>>> >>>> >> plain >> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one >> >> >>>>>>> >>>> >> is >> >> >>>>>>> >>>> >> not >> >> >>>>>>> >>>> >> showing >> >> >>>>>>> >>>> >> the volume. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Versions used: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >>>>>>> >>>> >> Qt 5.5.1 >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >>>>>>> >>>> >> Qt 5.6.2 >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my >> >> >>>>>>> >>>> >> build >> >> >>>>>>> >>>> >> of the >> >> >>>>>>> >>>> >> test >> >> >>>>>>> >>>> >> case if you want. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >> >> >>>>>>> >>>> >> reported >> >> >>>>>>> >>>> >> and >> >> >>>>>>> >>>> >> got solved in my other thread. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >> >>>>>>> >>>> >> Elvis >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> main.cpp: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >> >>>>>>> >>>> >> { >> >> >>>>>>> >>>> >> auto defaultFormat = >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >> >>>>>>> >>>> >> vtkNew colorFunction; >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >> >>>>>>> >>>> >> std::fill_n(static_cast> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >> >>>>>>> >>>> >> 8000000, 0.01); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volumeMapper; >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volume; >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >> >>>>>>> >>>> >> vtkNew window; >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >> >>>>>>> >>>> >> widget->show(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> return app.exec(); >> >> >>>>>>> >>>> >> } else { >> >> >>>>>>> >>>> >> // Render with "plain" render window / >> >> >>>>>>> >>>> >> interactor >> >> >>>>>>> >>>> >> vtkNew window; >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew interactor; >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >> >>>>>>> >>>> >> interactor->Start(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> return 0; >> >> >>>>>>> >>>> >> } >> >> >>>>>>> >>>> >> } >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> project(TestCase) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >>>>>>> >>>> >> REQUIRED >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >>>>>>> >>>> >> Qt5::Widgets >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> _______________________________________________ >> >> >>>>>>> >>>> >> 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: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> > -- >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Sankhesh Jhaveri >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >>>> > 881-4417 >> >> >>>>>>> >>> >> >> >>>>>>> >>> -- >> >> >>>>>>> >>> >> >> >>>>>>> >>> Sankhesh Jhaveri >> >> >>>>>>> >>> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >>> 881-4417 >> >> >>>>>>> >> >> >> >>>>>>> >> -- >> >> >>>>>>> >> >> >> >>>>>>> >> Sankhesh Jhaveri >> >> >>>>>>> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >> 881-4417 >> >> >>>>>>> _______________________________________________ >> >> >>>>>>> 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: >> >> >>>>>>> http://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: >> >> >>>>> http://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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > >> > >> > >> > -- >> > Ken Martin PhD >> > Distinguished Engineer >> > Kitware Inc. >> > 28 Corporate Drive >> > Clifton Park NY 12065 >> > >> > 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. > > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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. From elvis.stansvik at orexplore.com Tue May 30 08:51:26 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 30 May 2017 14:51:26 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-30 14:50 GMT+02:00 Elvis Stansvik : > 2017-05-26 14:35 GMT+02:00 Ken Martin : >> If you have a build of QT I think you could change >> >> https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 >> >> const int requestedVersion = qMin((format.majorVersion() << 8) + >> format.minorVersion(), >> staticContext.defaultFormat.version); >> >> to be >> >> const int requestedVersion = (format.majorVersion() << 8) + >> format.minorVersion()); >> >> and it would fix it for VTK/ParaView. Not sure if it has any other >> consequences for Qt or if it would hit some different issue though. Qt on >> windows does some tricky stuff to support OpenGL/Angle/ES2. >> > > Today I tried first updating the Intel driver from 9.18.10.3272 (which > the laptop came preinstalled with) to 10.18.10.4425, which is the > latest vendor:ified version from Lenovo for this laptop (Thinkpad > E540), but it didn't change anything. > > I then tried uninstalling the Lenovo one, to let me install the > generic driver from Intel. The Intel driver update utility offered up > 15.something, but in the end 10.18.14.4578 was what I got. And no > luck, still the problem with volumes silently not showing up. > > So if your analysis is correct Ben, which it probably is, it's a real s/Ben/Ken/ > PITA since it means I'll have to patch and build Qt to get our program > to work on these Intel laptops running Windows. > > Anyone know if there's anything VTK or our application could do to > work around this bad logic in the Qt context initialization? It would > be a lot less trouble to re-build VTK, since I'm already building that > (naturally). > > Elvis > >> >> >> On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik >> wrote: >>> >>> 2017-05-26 2:24 GMT+02:00 Ken Martin : >>> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is >>> > a >>> > Qt bug we already bumped into with Mesa. They have what looks to me like >>> > some odd bad logic on windows for creating a context where they will not >>> > give you a core context later than the latest compatibility context they >>> > can >>> > get. For some vendors that is fine but for others they only offer Comp >>> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support >>> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed >>> > that the issue would go away. I believe Ben filed a bug report with them >>> > (Qt) when he bumped into this when using Mesa on Windows. >>> >>> Ah yes, that could definitely be it. I found Ben's bug: >>> >>> https://bugreports.qt.io/browse/QTBUG-60742 >>> >>> The affected version is listed as 5.8.0, but I'm having trouble on >>> 5.6.2, so I guess the bad logic is there as well. >>> >>> So let's hope for a fix in Qt then. But in the meantime, is there >>> anything you can think if that I could do to work around it? I really >>> want our application to work on these kinds of machines (the one I >>> have was picked as a sort of a baseline for us wrt to requirements). >>> >>> In the bug report Ben mentions hacking around it with >>> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >>> using Mesa. >>> >>> Elvis >>> >>> > >>> > >>> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >>> > wrote: >>> >> >>> >> 2017-05-25 23:37 GMT+02:00 David Cole : >>> >> > Yes, I ran it both ways. >>> >> > >>> >> > It works when run without the argument in the plain VTK render >>> >> > window, >>> >> > and it is broken (shows nothing) when run with an argument. >>> >> >>> >> Alright, that's good. Then we're seeing the same thing. >>> >> >>> >> > Seems like it's definitely related to older Intel drivers on Windows. >>> >> >>> >> Yes, probably. >>> >> >>> >> > Not sure if there is an updated driver available for my machine. >>> >> > Hesitant to try changing/updating it for other reasons, and sorry, >>> >> > can't sacrifice this machine's current state for the purpose of >>> >> > testing this out... >>> >> >>> >> No worries, I'm free to do as I please with the one I have, so I'll do >>> >> some experimenting with different drivers when I'm back on Monday. >>> >> >>> >> Thanks to everyone trying this out. >>> >> >>> >> Elvis >>> >> >>> >> > >>> >> > >>> >> > D >>> >> > >>> >> > >>> >> > >>> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >>> >> > wrote: >>> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >>> >> >> : >>> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >>> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >>> >> >>>> with an Intel HD Graphics 4000 running driver version >>> >> >>>> 10.18.10.3316. >>> >> >>>> I >>> >> >>>> get your TestCase app window with nothing but an empty (white) >>> >> >>>> client >>> >> >>>> region. >>> >> >>>> >>> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >>> >> >>>> VolumeSmartMapper works fine on this very same machine. >>> >> >>>> >>> >> >>>> Another data point... >>> >> >> >>> >> >> Just one more thing David, did you try also running the example >>> >> >> without any argument on this machine? (That would make it use a >>> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >>> >> >> interesting to know if the volume shows up then. That would confirm >>> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >>> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >>> >> >> something to do with the new QVTKOpenGLWidget. >>> >> >> >>> >> >> Elvis >>> >> >> >>> >> >>> >>> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >>> >> >>> David. >>> >> >>> >>> >> >>> And just to make sure, Aron, did you run the test case as "TestCase >>> >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >>> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >>> >> >>> QVTKOpenGLWidget), and not exhibit the problem. >>> >> >>> >>> >> >>> Elvis >>> >> >>> >>> >> >>>> >>> >> >>>> >>> >> >>>> D >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >>> >> >>>> wrote: >>> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>> >> >>>>>> Hi Elvis, >>> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >>> >> >>>>>> setup - both >>> >> >>>>>> intel and nvidia graphics. >>> >> >>>>>> With your test case, I'm able to see the volume running either >>> >> >>>>>> with >>> >> >>>>>> Intel or >>> >> >>>>>> nVidia, so it doesn't repro for me. >>> >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >>> >> >>>>>> Sorry, >>> >> >>>>>> Aron >>> >> >>>>> >>> >> >>>>> Alright, bugger. Thanks for testing though! >>> >> >>>>> >>> >> >>>>> I won't be at the office until Monday again, but when I'm back >>> >> >>>>> I'll >>> >> >>>>> try experimenting with different driver versions. >>> >> >>>>> >>> >> >>>>> Elvis >>> >> >>>>> >>> >> >>>>>> >>> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>> >> >>>>>> wrote: >>> >> >>>>>>> >>> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >>> >> >>>>>>> : >>> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>> >> >>>>>>> > : >>> >> >>>>>>> >> Hi Elvis, >>> >> >>>>>>> >> >>> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >>> >> >>>>>>> >> >>> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card >>> >> >>>>>>> >> but >>> >> >>>>>>> >> tried >>> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >>> >> >>>>>>> >> (with an >>> >> >>>>>>> >> Intel >>> >> >>>>>>> >> HD5600). Worked fine. >>> >> >>>>>>> > >>> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >>> >> >>>>>>> > machine with >>> >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >>> >> >>>>>>> >>> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>> >> >>>>>>> >>> >> >>>>>>> I've now put up the compiled self-contained test case here: >>> >> >>>>>>> >>> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>> >> >>>>>>> >>> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + >>> >> >>>>>>> Intel >>> >> >>>>>>> graphics could try running this test case with "TestCase 1" and >>> >> >>>>>>> see if >>> >> >>>>>>> the volume shows up, that would be great. >>> >> >>>>>>> >>> >> >>>>>>> (Running the test case with argc > 2 will make it use >>> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>> >> >>>>>>> >>> >> >>>>>>> Elvis >>> >> >>>>>>> >>> >> >>>>>>> > >>> >> >>>>>>> > I could put up my build of the test case as a self-contained >>> >> >>>>>>> > .zip, to >>> >> >>>>>>> > make it easy to test. >>> >> >>>>>>> > >>> >> >>>>>>> >> >>> >> >>>>>>> >> At this point, I am inclined to think that the graphics >>> >> >>>>>>> >> drivers >>> >> >>>>>>> >> on your >>> >> >>>>>>> >> Windows machine may need updating. >>> >> >>>>>>> > >>> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and >>> >> >>>>>>> > just >>> >> >>>>>>> > use a >>> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't >>> >> >>>>>>> > that >>> >> >>>>>>> > suggest that the drivers are capable enough, and that the >>> >> >>>>>>> > problem is >>> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>> >> >>>>>>> > >>> >> >>>>>>> > Elvis >>> >> >>>>>>> > >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>> >> >>>>>>> >> wrote: >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> Okay thanks. >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> I?ll take a look. >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>> >> >>>>>>> >>> wrote: >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>> >> >>>>>>> >>>> : >>> >> >>>>>>> >>>> > Hi Elvis, >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary >>> >> >>>>>>> >>>> > and >>> >> >>>>>>> >>>> > test >>> >> >>>>>>> >>>> > volume >>> >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a >>> >> >>>>>>> >>>> > test >>> >> >>>>>>> >>>> > dataset. >>> >> >>>>>>> >>>> > ParaView >>> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >>> >> >>>>>>> >>>> > before diving >>> >> >>>>>>> >>>> > into the >>> >> >>>>>>> >>>> > code. >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> I tried the wavelet example with Paraview >>> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >>> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >>> >> >>>>>>> >>>> case. The >>> >> >>>>>>> >>>> volume won't show up. >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> It does show up if I switch to the software based ray cast >>> >> >>>>>>> >>>> mapper >>> >> >>>>>>> >>>> (but >>> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the >>> >> >>>>>>> >>>> GPU >>> >> >>>>>>> >>>> one being >>> >> >>>>>>> >>>> used). >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help >>> >> >>>>>>> >>>> debugging. >>> >> >>>>>>> >>>> There are no errors printed when I run my test case. >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> Elvis >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Thanks, >>> >> >>>>>>> >>>> > Sankhesh >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>> >> >>>>>>> >>>> > wrote: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Hi all, >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >>> >> >>>>>>> >>>> >> rendered using >>> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, >>> >> >>>>>>> >>>> >> Intel >>> >> >>>>>>> >>>> >> graphics >>> >> >>>>>>> >>>> >> (HD >>> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up >>> >> >>>>>>> >>>> >> fine >>> >> >>>>>>> >>>> >> on >>> >> >>>>>>> >>>> >> Windows 7 >>> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning >>> >> >>>>>>> >>>> >> off >>> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >>> >> >>>>>>> >>>> >> QSurfaceFormat. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >>> >> >>>>>>> >>>> >> attached >>> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and >>> >> >>>>>>> >>>> >> "TestCase >>> >> >>>>>>> >>>> >> 1" >>> >> >>>>>>> >>>> >> (right). >>> >> >>>>>>> >>>> >> The former uses a plain render window while the latter >>> >> >>>>>>> >>>> >> uses the >>> >> >>>>>>> >>>> >> new >>> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 >>> >> >>>>>>> >>>> >> screenshot, >>> >> >>>>>>> >>>> >> the >>> >> >>>>>>> >>>> >> plain >>> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one >>> >> >>>>>>> >>>> >> is >>> >> >>>>>>> >>>> >> not >>> >> >>>>>>> >>>> >> showing >>> >> >>>>>>> >>>> >> the volume. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Versions used: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >>> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>> >> >>>>>>> >>>> >> Qt 5.5.1 >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Windows 7 >>> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >>> >> >>>>>>> >>>> >> Qt 5.6.2 >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Any ideas what the problem might be? >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my >>> >> >>>>>>> >>>> >> build >>> >> >>>>>>> >>>> >> of the >>> >> >>>>>>> >>>> >> test >>> >> >>>>>>> >>>> >> case if you want. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >>> >> >>>>>>> >>>> >> reported >>> >> >>>>>>> >>>> >> and >>> >> >>>>>>> >>>> >> got solved in my other thread. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Many thanks in advance, >>> >> >>>>>>> >>>> >> Elvis >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> main.cpp: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >>> >> >>>>>>> >>>> >> { >>> >> >>>>>>> >>>> >> auto defaultFormat = >>> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >>> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >>> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> QApplication app(argc, argv); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> // Set up volume rendering >>> >> >>>>>>> >>>> >> vtkNew colorFunction; >>> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew opacityFunction; >>> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew imageData; >>> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>> >> >>>>>>> >>>> >> std::fill_n(static_cast>> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >>> >> >>>>>>> >>>> >> 8000000, 0.01); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew volumeMapper; >>> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew volumeProperty; >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew volume; >>> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew renderer; >>> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >>> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> if (argc > 1) { >>> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >>> >> >>>>>>> >>>> >> vtkNew window; >>> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>> >> >>>>>>> >>>> >> widget->show(); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> return app.exec(); >>> >> >>>>>>> >>>> >> } else { >>> >> >>>>>>> >>>> >> // Render with "plain" render window / >>> >> >>>>>>> >>>> >> interactor >>> >> >>>>>>> >>>> >> vtkNew window; >>> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew interactor; >>> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>> >> >>>>>>> >>>> >> interactor->Start(); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> return 0; >>> >> >>>>>>> >>>> >> } >>> >> >>>>>>> >>>> >> } >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> CMakeLists.txt: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> project(TestCase) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>> >> >>>>>>> >>>> >> vtkCommonCore >>> >> >>>>>>> >>>> >> vtkCommonDataModel >>> >> >>>>>>> >>>> >> vtkCommonExecutionModel >>> >> >>>>>>> >>>> >> vtkCommonMath >>> >> >>>>>>> >>>> >> vtkFiltersSources >>> >> >>>>>>> >>>> >> vtkGUISupportQt >>> >> >>>>>>> >>>> >> vtkInteractionStyle >>> >> >>>>>>> >>>> >> vtkRenderingCore >>> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>> >> >>>>>>> >>>> >> vtkRenderingVolume >>> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >> >>>>>>> >>>> >> REQUIRED >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>> >> >>>>>>> >>>> >> vtkCommonCore >>> >> >>>>>>> >>>> >> vtkCommonDataModel >>> >> >>>>>>> >>>> >> vtkCommonExecutionModel >>> >> >>>>>>> >>>> >> vtkCommonMath >>> >> >>>>>>> >>>> >> vtkFiltersSources >>> >> >>>>>>> >>>> >> vtkGUISupportQt >>> >> >>>>>>> >>>> >> vtkInteractionStyle >>> >> >>>>>>> >>>> >> vtkRenderingCore >>> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>> >> >>>>>>> >>>> >> vtkRenderingVolume >>> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >> >>>>>>> >>>> >> Qt5::Widgets >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >>> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>> >> >>>>>>> >>>> >> CXX_STANDARD 14 >>> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> _______________________________________________ >>> >> >>>>>>> >>>> >> 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: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> > -- >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Sankhesh Jhaveri >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >>> >> >>>>>>> >>>> > 881-4417 >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> -- >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> Sankhesh Jhaveri >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >>> >> >>>>>>> >>> 881-4417 >>> >> >>>>>>> >> >>> >> >>>>>>> >> -- >>> >> >>>>>>> >> >>> >> >>>>>>> >> Sankhesh Jhaveri >>> >> >>>>>>> >> >>> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >>> >> >>>>>>> >> 881-4417 >>> >> >>>>>>> _______________________________________________ >>> >> >>>>>>> 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: >>> >> >>>>>>> http://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: >>> >> >>>>> http://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: >>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>> > >>> > >>> > >>> > -- >>> > Ken Martin PhD >>> > Distinguished Engineer >>> > Kitware Inc. >>> > 28 Corporate Drive >>> > Clifton Park NY 12065 >>> > >>> > 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. >> >> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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. From robert.maynard at kitware.com Tue May 30 09:59:05 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 30 May 2017 09:59:05 -0400 Subject: [vtk-developers] Should VTK targets have INTERFACE_{INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS} set? In-Reply-To: References: Message-ID: Hi Elvis, The VTK module system was developed to support versions of CMake that didn't support INTERFACE_ properties and all the other nice features of Modern CMake. Now that VTK requires CMake 3.3+ it would be possible to update the module system to provide this support. I believe that other developers are interested in this effort, but I am not aware of an explicit timeline. On Sun, May 28, 2017 at 11:53 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-28 17:30 GMT+02:00 Elvis Stansvik : > > Hi all, > > > > When linking against a VTK module through an imported target, e.g > > > > find_package(VTK 8.0.0 REQUIRED COMPONENTS vtkCommonCore) > > ... > > target_link_libraries(myapp vtkCommonCore) > > > > I must still manually make sure I use > > > > target_include_directories(myapp PUBLIC ${VTK_INCLUDE_DIRS}) > > ... > > target_compile_definitions(myapp PUBLIC ${VTK_DEFINITIONS}) > > > > to get the include directories and definitions. > > > > This is in contrast to e.g. Qt's CMake files, which makes sure targets > > have INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS > > set on its targets. For example, QtSvg (from Qt5SvgConfig.cmake): > > > > set_property(TARGET Qt5::Svg PROPERTY > > INTERFACE_INCLUDE_DIRECTORIES ${_Qt5Svg_OWN_INCLUDE_DIRS}) > > set_property(TARGET Qt5::Svg PROPERTY > > INTERFACE_COMPILE_DEFINITIONS QT_SVG_LIB) > > > > Now, this is not really a bit inconvenience, I just have to make sure > > to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS}. > > > > However, I recently started using the libclang-based > > include-what-you-use tool [1] to help sanitize my header inclusions. > > The tool will make suggestions such as (taking a Qt header as example > > here): > > > > /home/estan/orexplore/insight/src/model/HoleLoader.cpp should add these > lines: > > #include // for QFileInfo > > > > I noticed that for a VTK header, it'll instead suggest e.g: > > > > /home/estan/orexplore/insight/src/model/Hole.cpp should add these lines: > > #include "vtkSmartPointer.h" // for vtkSmartPointer > > > > Notice the "" instead of <>. > > > > I dug into include-what-you-use to find out why this is happening, and > > it's because on the compile line, the Qt include directories are given > > with -isystem, while the VTK include directories are given with -I, > > and -isystem vs -I is what the tool uses (for lack of other > > information) to determine whether to suggest the inclusion with <> or > > with "". > > > > I believe that maybe the -I flags added for VTK would become -isystem, > > if they were brought in through the INTERFACE_INCLUDE_DIRECTORIES > > mechanism, same as Qt. > > > > So all this lead me to two questions regarding VTK: > > > > 1. Should VTK's installed CMake files perhaps make sure > > INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_INCLUDE_DEFINITIONS are > > set on its exported targets? > > > > 2. If not, anyone know if there's something that could be done to make > > the flags end up as -isystem flags instead of -I when using > > ${VTK_INCLUDE_DIRS}? > > Disregard this question: I realized that I could simply use SYSTEM in > my target_include_directories(...) to make CMake treat it as a system > include directory, which makes it use -isystem on compilers that > support it. > > So then it's only question 1 left. I think it would be nice to have > INTERFACE_{INCLUDE_DIRECTORIES,DEFINITIONS} set on the targets, just > to avoid having to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS} > manually. > > Elvis > > > > > Cheers, > > Elvis > > > > [1] https://github.com/include-what-you-use/include-what-you-use > _______________________________________________ > 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Tue May 30 10:01:55 2017 From: lasso at queensu.ca (Andras Lasso) Date: Tue, 30 May 2017 14:01:55 +0000 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: If you need to build Qt on Windows, you may find Jc's qt-easy-build script useful (https://github.com/jcfr/qt-easy-build). You download the qt-easy-build repository and copy-paste a single line in a terminal window. Andras -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Elvis Stansvik Sent: Tuesday, May 30, 2017 8:51 AM To: Ken Martin Cc: vtkdev Subject: Re: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 2017-05-30 14:50 GMT+02:00 Elvis Stansvik : > 2017-05-26 14:35 GMT+02:00 Ken Martin : >> If you have a build of QT I think you could change >> >> https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/q >> windowsglcontext.cpp#L730 >> >> const int requestedVersion = qMin((format.majorVersion() << 8) + >> format.minorVersion(), staticContext.defaultFormat.version); >> >> to be >> >> const int requestedVersion = (format.majorVersion() << 8) + >> format.minorVersion()); >> >> and it would fix it for VTK/ParaView. Not sure if it has any other >> consequences for Qt or if it would hit some different issue though. >> Qt on windows does some tricky stuff to support OpenGL/Angle/ES2. >> > > Today I tried first updating the Intel driver from 9.18.10.3272 (which > the laptop came preinstalled with) to 10.18.10.4425, which is the > latest vendor:ified version from Lenovo for this laptop (Thinkpad > E540), but it didn't change anything. > > I then tried uninstalling the Lenovo one, to let me install the > generic driver from Intel. The Intel driver update utility offered up > 15.something, but in the end 10.18.14.4578 was what I got. And no > luck, still the problem with volumes silently not showing up. > > So if your analysis is correct Ben, which it probably is, it's a real s/Ben/Ken/ > PITA since it means I'll have to patch and build Qt to get our program > to work on these Intel laptops running Windows. > > Anyone know if there's anything VTK or our application could do to > work around this bad logic in the Qt context initialization? It would > be a lot less trouble to re-build VTK, since I'm already building that > (naturally). > > Elvis > >> >> >> On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik >> wrote: >>> >>> 2017-05-26 2:24 GMT+02:00 Ken Martin : >>> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure >>> > it is a Qt bug we already bumped into with Mesa. They have what >>> > looks to me like some odd bad logic on windows for creating a >>> > context where they will not give you a core context later than the >>> > latest compatibility context they can get. For some vendors that >>> > is fine but for others they only offer Comp contexts up to 2.1 or >>> > 3.0 but not 3.2. So while the driver may support OpenGL 4 in Core >>> > mode, Qt restricts you to 3.0. I suspect if they fixed that the >>> > issue would go away. I believe Ben filed a bug report with them >>> > (Qt) when he bumped into this when using Mesa on Windows. >>> >>> Ah yes, that could definitely be it. I found Ben's bug: >>> >>> https://bugreports.qt.io/browse/QTBUG-60742 >>> >>> The affected version is listed as 5.8.0, but I'm having trouble on >>> 5.6.2, so I guess the bad logic is there as well. >>> >>> So let's hope for a fix in Qt then. But in the meantime, is there >>> anything you can think if that I could do to work around it? I >>> really want our application to work on these kinds of machines (the >>> one I have was picked as a sort of a baseline for us wrt to requirements). >>> >>> In the bug report Ben mentions hacking around it with >>> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >>> using Mesa. >>> >>> Elvis >>> >>> > >>> > >>> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >>> > wrote: >>> >> >>> >> 2017-05-25 23:37 GMT+02:00 David Cole : >>> >> > Yes, I ran it both ways. >>> >> > >>> >> > It works when run without the argument in the plain VTK render >>> >> > window, and it is broken (shows nothing) when run with an >>> >> > argument. >>> >> >>> >> Alright, that's good. Then we're seeing the same thing. >>> >> >>> >> > Seems like it's definitely related to older Intel drivers on Windows. >>> >> >>> >> Yes, probably. >>> >> >>> >> > Not sure if there is an updated driver available for my machine. >>> >> > Hesitant to try changing/updating it for other reasons, and >>> >> > sorry, can't sacrifice this machine's current state for the >>> >> > purpose of testing this out... >>> >> >>> >> No worries, I'm free to do as I please with the one I have, so >>> >> I'll do some experimenting with different drivers when I'm back on Monday. >>> >> >>> >> Thanks to everyone trying this out. >>> >> >>> >> Elvis >>> >> >>> >> > >>> >> > >>> >> > D >>> >> > >>> >> > >>> >> > >>> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >>> >> > wrote: >>> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >>> >> >> : >>> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >>> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, >>> >> >>>> Windows 8.1, with an Intel HD Graphics 4000 running driver >>> >> >>>> version 10.18.10.3316. >>> >> >>>> I >>> >> >>>> get your TestCase app window with nothing but an empty >>> >> >>>> (white) client region. >>> >> >>>> >>> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL >>> >> >>>> using VolumeSmartMapper works fine on this very same machine. >>> >> >>>> >>> >> >>>> Another data point... >>> >> >> >>> >> >> Just one more thing David, did you try also running the >>> >> >> example without any argument on this machine? (That would make >>> >> >> it use a regular vtkRenderWindow/vtkRenderWindowInteractor). >>> >> >> It would be interesting to know if the volume shows up then. >>> >> >> That would confirm that the machine can show volumes using VTK >>> >> >> 8+OpenGL2 backend, just not with QVTKOpenGLWidget, so would >>> >> >> strengthen my theory that it has something to do with the new QVTKOpenGLWidget. >>> >> >> >>> >> >> Elvis >>> >> >> >>> >> >>> >>> >> >>> Finally a reproduction, I was beginning to despair :) Thanks >>> >> >>> a lot David. >>> >> >>> >>> >> >>> And just to make sure, Aron, did you run the test case as >>> >> >>> "TestCase 1", with a parameter? That's the crucial thing, as >>> >> >>> otherwise it'll just use a regular >>> >> >>> vtkRenderWindow/vtkRenderWindowInteractor (not QVTKOpenGLWidget), and not exhibit the problem. >>> >> >>> >>> >> >>> Elvis >>> >> >>> >>> >> >>>> >>> >> >>>> >>> >> >>>> D >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >>> >> >>>> wrote: >>> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>> >> >>>>>> Hi Elvis, >>> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an >>> >> >>>>>> Optimus setup - both intel and nvidia graphics. >>> >> >>>>>> With your test case, I'm able to see the volume running >>> >> >>>>>> either with Intel or nVidia, so it doesn't repro for me. >>> >> >>>>>> I've got Intel HD530 graphics, with driver version >>> >> >>>>>> 21.20.16.4627 Sorry, Aron >>> >> >>>>> >>> >> >>>>> Alright, bugger. Thanks for testing though! >>> >> >>>>> >>> >> >>>>> I won't be at the office until Monday again, but when I'm >>> >> >>>>> back I'll try experimenting with different driver versions. >>> >> >>>>> >>> >> >>>>> Elvis >>> >> >>>>> >>> >> >>>>>> >>> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>> >> >>>>>> wrote: >>> >> >>>>>>> >>> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >>> >> >>>>>>> : >>> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>> >> >>>>>>> > : >>> >> >>>>>>> >> Hi Elvis, >>> >> >>>>>>> >> >>> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. >>> >> >>>>>>> >> :( >>> >> >>>>>>> >> >>> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics >>> >> >>>>>>> >> card but tried ParaView on a couple of se Windows >>> >> >>>>>>> >> machines as well as a Mac (with an Intel HD5600). >>> >> >>>>>>> >> Worked fine. >>> >> >>>>>>> > >>> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows >>> >> >>>>>>> > 7 machine with Intel graphics? Would be great if >>> >> >>>>>>> > someone could reproduce. >>> >> >>>>>>> >>> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>> >> >>>>>>> >>> >> >>>>>>> I've now put up the compiled self-contained test case here: >>> >> >>>>>>> >>> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>> >> >>>>>>> >>> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) >>> >> >>>>>>> + Intel graphics could try running this test case with >>> >> >>>>>>> "TestCase 1" and see if the volume shows up, that would >>> >> >>>>>>> be great. >>> >> >>>>>>> >>> >> >>>>>>> (Running the test case with argc > 2 will make it use >>> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>> >> >>>>>>> >>> >> >>>>>>> Elvis >>> >> >>>>>>> >>> >> >>>>>>> > >>> >> >>>>>>> > I could put up my build of the test case as a >>> >> >>>>>>> > self-contained .zip, to make it easy to test. >>> >> >>>>>>> > >>> >> >>>>>>> >> >>> >> >>>>>>> >> At this point, I am inclined to think that the >>> >> >>>>>>> >> graphics drivers on your Windows machine may need >>> >> >>>>>>> >> updating. >>> >> >>>>>>> > >>> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, >>> >> >>>>>>> > and just use a plain vtkRenderWindow + >>> >> >>>>>>> > vtkRenderWindowInteractor. Wouldn't that suggest that >>> >> >>>>>>> > the drivers are capable enough, and that the problem is >>> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>> >> >>>>>>> > >>> >> >>>>>>> > Elvis >>> >> >>>>>>> > >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>> >> >>>>>>> >> wrote: >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> Okay thanks. >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> I?ll take a look. >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>> >> >>>>>>> >>> wrote: >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>> >> >>>>>>> >>>> : >>> >> >>>>>>> >>>> > Hi Elvis, >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly >>> >> >>>>>>> >>>> > binary and test volume rendering there? You can >>> >> >>>>>>> >>>> > use the wavelet source for a test dataset. >>> >> >>>>>>> >>>> > ParaView >>> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good >>> >> >>>>>>> >>>> > test before diving into the code. >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> I tried the wavelet example with Paraview >>> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 64-bit, and the problem is >>> >> >>>>>>> >>>> the same as in my minimal test case. The volume >>> >> >>>>>>> >>>> won't show up. >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> It does show up if I switch to the software based >>> >> >>>>>>> >>>> ray cast mapper (but not with GPU or smart, which I >>> >> >>>>>>> >>>> guess both result in the GPU one being used). >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> Please tell me if there's anything else I can do to >>> >> >>>>>>> >>>> help debugging. >>> >> >>>>>>> >>>> There are no errors printed when I run my test case. >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> Elvis >>> >> >>>>>>> >>>> >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Thanks, >>> >> >>>>>>> >>>> > Sankhesh >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>> >> >>>>>>> >>>> > wrote: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Hi all, >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get >>> >> >>>>>>> >>>> >> volumes rendered using vtkGPUVolumeRayCastMapper >>> >> >>>>>>> >>>> >> to show up on Windows 7, Intel graphics (HD >>> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show >>> >> >>>>>>> >>>> >> up fine on Windows 7 if using a plain VTK render >>> >> >>>>>>> >>>> >> window. I've tried turning off multisampling with >>> >> >>>>>>> >>>> >> setSamples(0) on the default QSurfaceFormat. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> The below test case illustrates the issue. See >>> >> >>>>>>> >>>> >> the attached screenshots from running "TestCase" >>> >> >>>>>>> >>>> >> (left) and "TestCase 1" >>> >> >>>>>>> >>>> >> (right). >>> >> >>>>>>> >>>> >> The former uses a plain render window while the >>> >> >>>>>>> >>>> >> latter uses the new QVTKOpenGLWidget. Notice how >>> >> >>>>>>> >>>> >> in the Windows 7 screenshot, the plain VTK >>> >> >>>>>>> >>>> >> rendering works fine, but the QVTKOpenGLWidget >>> >> >>>>>>> >>>> >> one is not showing the volume. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Versions used: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 VTK 8.0.0.rc1, OpenGL2 Qt >>> >> >>>>>>> >>>> >> 5.5.1 >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Windows 7 >>> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 Qt 5.6.2 >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Any ideas what the problem might be? >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of >>> >> >>>>>>> >>>> >> my build of the test case if you want. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha >>> >> >>>>>>> >>>> >> issue I reported and got solved in my other >>> >> >>>>>>> >>>> >> thread. >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> Many thanks in advance, Elvis >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> main.cpp: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> #include >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >>> >> >>>>>>> >>>> >> { >>> >> >>>>>>> >>>> >> auto defaultFormat = >>> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >>> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >>> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> QApplication app(argc, argv); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> // Set up volume rendering >>> >> >>>>>>> >>>> >> vtkNew colorFunction; >>> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew opacityFunction; >>> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew imageData; >>> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>> >> >>>>>>> >>>> >> std::fill_n(static_cast>> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >>> >> >>>>>>> >>>> >> 8000000, 0.01); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew volumeMapper; >>> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew volumeProperty; >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew volume; >>> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew renderer; >>> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >>> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> if (argc > 1) { >>> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >>> >> >>>>>>> >>>> >> vtkNew window; >>> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>> >> >>>>>>> >>>> >> widget->show(); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> return app.exec(); >>> >> >>>>>>> >>>> >> } else { >>> >> >>>>>>> >>>> >> // Render with "plain" render window / >>> >> >>>>>>> >>>> >> interactor >>> >> >>>>>>> >>>> >> vtkNew window; >>> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> vtkNew interactor; >>> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>> >> >>>>>>> >>>> >> interactor->Start(); >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> return 0; >>> >> >>>>>>> >>>> >> } >>> >> >>>>>>> >>>> >> } >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> CMakeLists.txt: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> project(TestCase) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>> >> >>>>>>> >>>> >> vtkCommonCore >>> >> >>>>>>> >>>> >> vtkCommonDataModel >>> >> >>>>>>> >>>> >> vtkCommonExecutionModel >>> >> >>>>>>> >>>> >> vtkCommonMath >>> >> >>>>>>> >>>> >> vtkFiltersSources >>> >> >>>>>>> >>>> >> vtkGUISupportQt >>> >> >>>>>>> >>>> >> vtkInteractionStyle >>> >> >>>>>>> >>>> >> vtkRenderingCore >>> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>> >> >>>>>>> >>>> >> vtkRenderingVolume >>> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >> >>>>>>> >>>> >> REQUIRED >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>> >> >>>>>>> >>>> >> vtkCommonCore >>> >> >>>>>>> >>>> >> vtkCommonDataModel >>> >> >>>>>>> >>>> >> vtkCommonExecutionModel >>> >> >>>>>>> >>>> >> vtkCommonMath >>> >> >>>>>>> >>>> >> vtkFiltersSources >>> >> >>>>>>> >>>> >> vtkGUISupportQt >>> >> >>>>>>> >>>> >> vtkInteractionStyle >>> >> >>>>>>> >>>> >> vtkRenderingCore >>> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>> >> >>>>>>> >>>> >> vtkRenderingVolume >>> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>> >> >>>>>>> >>>> >> Qt5::Widgets >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >>> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>> >> >>>>>>> >>>> >> CXX_STANDARD 14 >>> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>> >> >>>>>>> >>>> >> ) >>> >> >>>>>>> >>>> >> _______________________________________________ >>> >> >>>>>>> >>>> >> 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: >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>>>>>> >>>> >> >>> >> >>>>>>> >>>> > -- >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Sankhesh Jhaveri >>> >> >>>>>>> >>>> > >>> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >>> >> >>>>>>> >>>> > 881-4417 >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> -- >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> Sankhesh Jhaveri >>> >> >>>>>>> >>> >>> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >>> >> >>>>>>> >>> 881-4417 >>> >> >>>>>>> >> >>> >> >>>>>>> >> -- >>> >> >>>>>>> >> >>> >> >>>>>>> >> Sankhesh Jhaveri >>> >> >>>>>>> >> >>> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >>> >> >>>>>>> >> 881-4417 >>> >> >>>>>>> _______________________________________________ >>> >> >>>>>>> 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: >>> >> >>>>>>> http://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: >>> >> >>>>> http://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: >>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >>> > >>> > >>> > >>> > -- >>> > Ken Martin PhD >>> > Distinguished Engineer >>> > Kitware Inc. >>> > 28 Corporate Drive >>> > Clifton Park NY 12065 >>> > >>> > 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. >> >> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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: http://public.kitware.com/mailman/listinfo/vtk-developers From elvis.stansvik at orexplore.com Tue May 30 10:08:16 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 30 May 2017 16:08:16 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-30 16:01 GMT+02:00 Andras Lasso : > If you need to build Qt on Windows, you may find Jc's qt-easy-build script useful (https://github.com/jcfr/qt-easy-build). You download the qt-easy-build repository and copy-paste a single line in a terminal window. Ah, thanks for the pointer. I'm sure I'd manage a manual build, though it was a while since I did one. It's just that I like running the pre-built ones since I they receive the widest testing. But if there's really no way around it, I'll probably do a build. Would be really nice if this was fixed in Qt though. I hope that the Qt devs will see it as a problem and rethink. Ken: You said you could reproduce in PV on your 4600, do you know if there's a PV bug report about it? Maybe it helps to link that in the Qt bug report, to give it some more weight. Elvis > > Andras > > -----Original Message----- > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Elvis Stansvik > Sent: Tuesday, May 30, 2017 8:51 AM > To: Ken Martin > Cc: vtkdev > Subject: Re: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 > > 2017-05-30 14:50 GMT+02:00 Elvis Stansvik : >> 2017-05-26 14:35 GMT+02:00 Ken Martin : >>> If you have a build of QT I think you could change >>> >>> https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/q >>> windowsglcontext.cpp#L730 >>> >>> const int requestedVersion = qMin((format.majorVersion() << 8) + >>> format.minorVersion(), staticContext.defaultFormat.version); >>> >>> to be >>> >>> const int requestedVersion = (format.majorVersion() << 8) + >>> format.minorVersion()); >>> >>> and it would fix it for VTK/ParaView. Not sure if it has any other >>> consequences for Qt or if it would hit some different issue though. >>> Qt on windows does some tricky stuff to support OpenGL/Angle/ES2. >>> >> >> Today I tried first updating the Intel driver from 9.18.10.3272 (which >> the laptop came preinstalled with) to 10.18.10.4425, which is the >> latest vendor:ified version from Lenovo for this laptop (Thinkpad >> E540), but it didn't change anything. >> >> I then tried uninstalling the Lenovo one, to let me install the >> generic driver from Intel. The Intel driver update utility offered up >> 15.something, but in the end 10.18.14.4578 was what I got. And no >> luck, still the problem with volumes silently not showing up. >> >> So if your analysis is correct Ben, which it probably is, it's a real > > s/Ben/Ken/ > >> PITA since it means I'll have to patch and build Qt to get our program >> to work on these Intel laptops running Windows. >> >> Anyone know if there's anything VTK or our application could do to >> work around this bad logic in the Qt context initialization? It would >> be a lot less trouble to re-build VTK, since I'm already building that >> (naturally). >> >> Elvis >> >>> >>> >>> On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik >>> wrote: >>>> >>>> 2017-05-26 2:24 GMT+02:00 Ken Martin : >>>> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure >>>> > it is a Qt bug we already bumped into with Mesa. They have what >>>> > looks to me like some odd bad logic on windows for creating a >>>> > context where they will not give you a core context later than the >>>> > latest compatibility context they can get. For some vendors that >>>> > is fine but for others they only offer Comp contexts up to 2.1 or >>>> > 3.0 but not 3.2. So while the driver may support OpenGL 4 in Core >>>> > mode, Qt restricts you to 3.0. I suspect if they fixed that the >>>> > issue would go away. I believe Ben filed a bug report with them >>>> > (Qt) when he bumped into this when using Mesa on Windows. >>>> >>>> Ah yes, that could definitely be it. I found Ben's bug: >>>> >>>> https://bugreports.qt.io/browse/QTBUG-60742 >>>> >>>> The affected version is listed as 5.8.0, but I'm having trouble on >>>> 5.6.2, so I guess the bad logic is there as well. >>>> >>>> So let's hope for a fix in Qt then. But in the meantime, is there >>>> anything you can think if that I could do to work around it? I >>>> really want our application to work on these kinds of machines (the >>>> one I have was picked as a sort of a baseline for us wrt to requirements). >>>> >>>> In the bug report Ben mentions hacking around it with >>>> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >>>> using Mesa. >>>> >>>> Elvis >>>> >>>> > >>>> > >>>> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >>>> > wrote: >>>> >> >>>> >> 2017-05-25 23:37 GMT+02:00 David Cole : >>>> >> > Yes, I ran it both ways. >>>> >> > >>>> >> > It works when run without the argument in the plain VTK render >>>> >> > window, and it is broken (shows nothing) when run with an >>>> >> > argument. >>>> >> >>>> >> Alright, that's good. Then we're seeing the same thing. >>>> >> >>>> >> > Seems like it's definitely related to older Intel drivers on Windows. >>>> >> >>>> >> Yes, probably. >>>> >> >>>> >> > Not sure if there is an updated driver available for my machine. >>>> >> > Hesitant to try changing/updating it for other reasons, and >>>> >> > sorry, can't sacrifice this machine's current state for the >>>> >> > purpose of testing this out... >>>> >> >>>> >> No worries, I'm free to do as I please with the one I have, so >>>> >> I'll do some experimenting with different drivers when I'm back on Monday. >>>> >> >>>> >> Thanks to everyone trying this out. >>>> >> >>>> >> Elvis >>>> >> >>>> >> > >>>> >> > >>>> >> > D >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >>>> >> > wrote: >>>> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >>>> >> >> : >>>> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >>>> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, >>>> >> >>>> Windows 8.1, with an Intel HD Graphics 4000 running driver >>>> >> >>>> version 10.18.10.3316. >>>> >> >>>> I >>>> >> >>>> get your TestCase app window with nothing but an empty >>>> >> >>>> (white) client region. >>>> >> >>>> >>>> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL >>>> >> >>>> using VolumeSmartMapper works fine on this very same machine. >>>> >> >>>> >>>> >> >>>> Another data point... >>>> >> >> >>>> >> >> Just one more thing David, did you try also running the >>>> >> >> example without any argument on this machine? (That would make >>>> >> >> it use a regular vtkRenderWindow/vtkRenderWindowInteractor). >>>> >> >> It would be interesting to know if the volume shows up then. >>>> >> >> That would confirm that the machine can show volumes using VTK >>>> >> >> 8+OpenGL2 backend, just not with QVTKOpenGLWidget, so would >>>> >> >> strengthen my theory that it has something to do with the new QVTKOpenGLWidget. >>>> >> >> >>>> >> >> Elvis >>>> >> >> >>>> >> >>> >>>> >> >>> Finally a reproduction, I was beginning to despair :) Thanks >>>> >> >>> a lot David. >>>> >> >>> >>>> >> >>> And just to make sure, Aron, did you run the test case as >>>> >> >>> "TestCase 1", with a parameter? That's the crucial thing, as >>>> >> >>> otherwise it'll just use a regular >>>> >> >>> vtkRenderWindow/vtkRenderWindowInteractor (not QVTKOpenGLWidget), and not exhibit the problem. >>>> >> >>> >>>> >> >>> Elvis >>>> >> >>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> D >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >>>> >> >>>> wrote: >>>> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >>>> >> >>>>>> Hi Elvis, >>>> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an >>>> >> >>>>>> Optimus setup - both intel and nvidia graphics. >>>> >> >>>>>> With your test case, I'm able to see the volume running >>>> >> >>>>>> either with Intel or nVidia, so it doesn't repro for me. >>>> >> >>>>>> I've got Intel HD530 graphics, with driver version >>>> >> >>>>>> 21.20.16.4627 Sorry, Aron >>>> >> >>>>> >>>> >> >>>>> Alright, bugger. Thanks for testing though! >>>> >> >>>>> >>>> >> >>>>> I won't be at the office until Monday again, but when I'm >>>> >> >>>>> back I'll try experimenting with different driver versions. >>>> >> >>>>> >>>> >> >>>>> Elvis >>>> >> >>>>> >>>> >> >>>>>> >>>> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >>>> >> >>>>>> wrote: >>>> >> >>>>>>> >>>> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >>>> >> >>>>>>> : >>>> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >>>> >> >>>>>>> > : >>>> >> >>>>>>> >> Hi Elvis, >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. >>>> >> >>>>>>> >> :( >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics >>>> >> >>>>>>> >> card but tried ParaView on a couple of se Windows >>>> >> >>>>>>> >> machines as well as a Mac (with an Intel HD5600). >>>> >> >>>>>>> >> Worked fine. >>>> >> >>>>>>> > >>>> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows >>>> >> >>>>>>> > 7 machine with Intel graphics? Would be great if >>>> >> >>>>>>> > someone could reproduce. >>>> >> >>>>>>> >>>> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >>>> >> >>>>>>> >>>> >> >>>>>>> I've now put up the compiled self-contained test case here: >>>> >> >>>>>>> >>>> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >>>> >> >>>>>>> >>>> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) >>>> >> >>>>>>> + Intel graphics could try running this test case with >>>> >> >>>>>>> "TestCase 1" and see if the volume shows up, that would >>>> >> >>>>>>> be great. >>>> >> >>>>>>> >>>> >> >>>>>>> (Running the test case with argc > 2 will make it use >>>> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >>>> >> >>>>>>> >>>> >> >>>>>>> Elvis >>>> >> >>>>>>> >>>> >> >>>>>>> > >>>> >> >>>>>>> > I could put up my build of the test case as a >>>> >> >>>>>>> > self-contained .zip, to make it easy to test. >>>> >> >>>>>>> > >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> At this point, I am inclined to think that the >>>> >> >>>>>>> >> graphics drivers on your Windows machine may need >>>> >> >>>>>>> >> updating. >>>> >> >>>>>>> > >>>> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, >>>> >> >>>>>>> > and just use a plain vtkRenderWindow + >>>> >> >>>>>>> > vtkRenderWindowInteractor. Wouldn't that suggest that >>>> >> >>>>>>> > the drivers are capable enough, and that the problem is >>>> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >>>> >> >>>>>>> > >>>> >> >>>>>>> > Elvis >>>> >> >>>>>>> > >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >>>> >> >>>>>>> >> wrote: >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> Okay thanks. >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> I?ll take a look. >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >>>> >> >>>>>>> >>> wrote: >>>> >> >>>>>>> >>>> >>>> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >>>> >> >>>>>>> >>>> : >>>> >> >>>>>>> >>>> > Hi Elvis, >>>> >> >>>>>>> >>>> > >>>> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly >>>> >> >>>>>>> >>>> > binary and test volume rendering there? You can >>>> >> >>>>>>> >>>> > use the wavelet source for a test dataset. >>>> >> >>>>>>> >>>> > ParaView >>>> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good >>>> >> >>>>>>> >>>> > test before diving into the code. >>>> >> >>>>>>> >>>> >>>> >> >>>>>>> >>>> I tried the wavelet example with Paraview >>>> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 64-bit, and the problem is >>>> >> >>>>>>> >>>> the same as in my minimal test case. The volume >>>> >> >>>>>>> >>>> won't show up. >>>> >> >>>>>>> >>>> >>>> >> >>>>>>> >>>> It does show up if I switch to the software based >>>> >> >>>>>>> >>>> ray cast mapper (but not with GPU or smart, which I >>>> >> >>>>>>> >>>> guess both result in the GPU one being used). >>>> >> >>>>>>> >>>> >>>> >> >>>>>>> >>>> Please tell me if there's anything else I can do to >>>> >> >>>>>>> >>>> help debugging. >>>> >> >>>>>>> >>>> There are no errors printed when I run my test case. >>>> >> >>>>>>> >>>> >>>> >> >>>>>>> >>>> Elvis >>>> >> >>>>>>> >>>> >>>> >> >>>>>>> >>>> > >>>> >> >>>>>>> >>>> > Thanks, >>>> >> >>>>>>> >>>> > Sankhesh >>>> >> >>>>>>> >>>> > >>>> >> >>>>>>> >>>> > >>>> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >>>> >> >>>>>>> >>>> > wrote: >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Hi all, >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get >>>> >> >>>>>>> >>>> >> volumes rendered using vtkGPUVolumeRayCastMapper >>>> >> >>>>>>> >>>> >> to show up on Windows 7, Intel graphics (HD >>>> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show >>>> >> >>>>>>> >>>> >> up fine on Windows 7 if using a plain VTK render >>>> >> >>>>>>> >>>> >> window. I've tried turning off multisampling with >>>> >> >>>>>>> >>>> >> setSamples(0) on the default QSurfaceFormat. >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> The below test case illustrates the issue. See >>>> >> >>>>>>> >>>> >> the attached screenshots from running "TestCase" >>>> >> >>>>>>> >>>> >> (left) and "TestCase 1" >>>> >> >>>>>>> >>>> >> (right). >>>> >> >>>>>>> >>>> >> The former uses a plain render window while the >>>> >> >>>>>>> >>>> >> latter uses the new QVTKOpenGLWidget. Notice how >>>> >> >>>>>>> >>>> >> in the Windows 7 screenshot, the plain VTK >>>> >> >>>>>>> >>>> >> rendering works fine, but the QVTKOpenGLWidget >>>> >> >>>>>>> >>>> >> one is not showing the volume. >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Versions used: >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 VTK 8.0.0.rc1, OpenGL2 Qt >>>> >> >>>>>>> >>>> >> 5.5.1 >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Windows 7 >>>> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 Qt 5.6.2 >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Any ideas what the problem might be? >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of >>>> >> >>>>>>> >>>> >> my build of the test case if you want. >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha >>>> >> >>>>>>> >>>> >> issue I reported and got solved in my other >>>> >> >>>>>>> >>>> >> thread. >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> Many thanks in advance, Elvis >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> main.cpp: >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> #include >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >>>> >> >>>>>>> >>>> >> { >>>> >> >>>>>>> >>>> >> auto defaultFormat = >>>> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >>>> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >>>> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> QApplication app(argc, argv); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> // Set up volume rendering >>>> >> >>>>>>> >>>> >> vtkNew colorFunction; >>>> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >>>> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew opacityFunction; >>>> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >>>> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew imageData; >>>> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >>>> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >>>> >> >>>>>>> >>>> >> std::fill_n(static_cast>>> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >>>> >> >>>>>>> >>>> >> 8000000, 0.01); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew volumeMapper; >>>> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew volumeProperty; >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >>>> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >>>> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew volume; >>>> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >>>> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew renderer; >>>> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >>>> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> if (argc > 1) { >>>> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >>>> >> >>>>>>> >>>> >> vtkNew window; >>>> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >>>> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >>>> >> >>>>>>> >>>> >> widget->show(); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> return app.exec(); >>>> >> >>>>>>> >>>> >> } else { >>>> >> >>>>>>> >>>> >> // Render with "plain" render window / >>>> >> >>>>>>> >>>> >> interactor >>>> >> >>>>>>> >>>> >> vtkNew window; >>>> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> vtkNew interactor; >>>> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >>>> >> >>>>>>> >>>> >> interactor->Start(); >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> return 0; >>>> >> >>>>>>> >>>> >> } >>>> >> >>>>>>> >>>> >> } >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> CMakeLists.txt: >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> project(TestCase) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >>>> >> >>>>>>> >>>> >> vtkCommonCore >>>> >> >>>>>>> >>>> >> vtkCommonDataModel >>>> >> >>>>>>> >>>> >> vtkCommonExecutionModel >>>> >> >>>>>>> >>>> >> vtkCommonMath >>>> >> >>>>>>> >>>> >> vtkFiltersSources >>>> >> >>>>>>> >>>> >> vtkGUISupportQt >>>> >> >>>>>>> >>>> >> vtkInteractionStyle >>>> >> >>>>>>> >>>> >> vtkRenderingCore >>>> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>>> >> >>>>>>> >>>> >> vtkRenderingVolume >>>> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>> >> >>>>>>> >>>> >> REQUIRED >>>> >> >>>>>>> >>>> >> ) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >>>> >> >>>>>>> >>>> >> vtkCommonCore >>>> >> >>>>>>> >>>> >> vtkCommonDataModel >>>> >> >>>>>>> >>>> >> vtkCommonExecutionModel >>>> >> >>>>>>> >>>> >> vtkCommonMath >>>> >> >>>>>>> >>>> >> vtkFiltersSources >>>> >> >>>>>>> >>>> >> vtkGUISupportQt >>>> >> >>>>>>> >>>> >> vtkInteractionStyle >>>> >> >>>>>>> >>>> >> vtkRenderingCore >>>> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >>>> >> >>>>>>> >>>> >> vtkRenderingVolume >>>> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >>>> >> >>>>>>> >>>> >> Qt5::Widgets >>>> >> >>>>>>> >>>> >> ) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >>>> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >>>> >> >>>>>>> >>>> >> ) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >>>> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >>>> >> >>>>>>> >>>> >> ) >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >>>> >> >>>>>>> >>>> >> CXX_STANDARD 14 >>>> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >>>> >> >>>>>>> >>>> >> ) >>>> >> >>>>>>> >>>> >> _______________________________________________ >>>> >> >>>>>>> >>>> >> 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: >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >> >>>>>>> >>>> >> >>>> >> >>>>>>> >>>> > -- >>>> >> >>>>>>> >>>> > >>>> >> >>>>>>> >>>> > Sankhesh Jhaveri >>>> >> >>>>>>> >>>> > >>>> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >>>> >> >>>>>>> >>>> > 881-4417 >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> -- >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> Sankhesh Jhaveri >>>> >> >>>>>>> >>> >>>> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >>>> >> >>>>>>> >>> 881-4417 >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> -- >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> Sankhesh Jhaveri >>>> >> >>>>>>> >> >>>> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >>>> >> >>>>>>> >> 881-4417 >>>> >> >>>>>>> _______________________________________________ >>>> >> >>>>>>> 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: >>>> >> >>>>>>> http://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: >>>> >> >>>>> http://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: >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Ken Martin PhD >>>> > Distinguished Engineer >>>> > Kitware Inc. >>>> > 28 Corporate Drive >>>> > Clifton Park NY 12065 >>>> > >>>> > 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. >>> >>> >>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> >>> 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: > http://public.kitware.com/mailman/listinfo/vtk-developers > From elvis.stansvik at orexplore.com Tue May 30 10:15:19 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 30 May 2017 16:15:19 +0200 Subject: [vtk-developers] Should VTK targets have INTERFACE_{INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS} set? In-Reply-To: References: Message-ID: 2017-05-30 15:59 GMT+02:00 Robert Maynard : > Hi Elvis, > > The VTK module system was developed to support versions of CMake that didn't > support INTERFACE_ properties and all the other nice features of Modern > CMake. Now that VTK requires CMake 3.3+ it would be possible to update the > module system to provide this support. I believe that other developers are > interested in this effort, but I am not aware of an explicit timeline. Ah right, I realized afterwards that older CMake support might be the reason. Did not know about the minimum version bump, but that sounds promising then. Thanks, Elvis > > On Sun, May 28, 2017 at 11:53 AM, Elvis Stansvik > wrote: >> >> 2017-05-28 17:30 GMT+02:00 Elvis Stansvik : >> > Hi all, >> > >> > When linking against a VTK module through an imported target, e.g >> > >> > find_package(VTK 8.0.0 REQUIRED COMPONENTS vtkCommonCore) >> > ... >> > target_link_libraries(myapp vtkCommonCore) >> > >> > I must still manually make sure I use >> > >> > target_include_directories(myapp PUBLIC ${VTK_INCLUDE_DIRS}) >> > ... >> > target_compile_definitions(myapp PUBLIC ${VTK_DEFINITIONS}) >> > >> > to get the include directories and definitions. >> > >> > This is in contrast to e.g. Qt's CMake files, which makes sure targets >> > have INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS >> > set on its targets. For example, QtSvg (from Qt5SvgConfig.cmake): >> > >> > set_property(TARGET Qt5::Svg PROPERTY >> > INTERFACE_INCLUDE_DIRECTORIES ${_Qt5Svg_OWN_INCLUDE_DIRS}) >> > set_property(TARGET Qt5::Svg PROPERTY >> > INTERFACE_COMPILE_DEFINITIONS QT_SVG_LIB) >> > >> > Now, this is not really a bit inconvenience, I just have to make sure >> > to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS}. >> > >> > However, I recently started using the libclang-based >> > include-what-you-use tool [1] to help sanitize my header inclusions. >> > The tool will make suggestions such as (taking a Qt header as example >> > here): >> > >> > /home/estan/orexplore/insight/src/model/HoleLoader.cpp should add these >> > lines: >> > #include // for QFileInfo >> > >> > I noticed that for a VTK header, it'll instead suggest e.g: >> > >> > /home/estan/orexplore/insight/src/model/Hole.cpp should add these lines: >> > #include "vtkSmartPointer.h" // for vtkSmartPointer >> > >> > Notice the "" instead of <>. >> > >> > I dug into include-what-you-use to find out why this is happening, and >> > it's because on the compile line, the Qt include directories are given >> > with -isystem, while the VTK include directories are given with -I, >> > and -isystem vs -I is what the tool uses (for lack of other >> > information) to determine whether to suggest the inclusion with <> or >> > with "". >> > >> > I believe that maybe the -I flags added for VTK would become -isystem, >> > if they were brought in through the INTERFACE_INCLUDE_DIRECTORIES >> > mechanism, same as Qt. >> > >> > So all this lead me to two questions regarding VTK: >> > >> > 1. Should VTK's installed CMake files perhaps make sure >> > INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_INCLUDE_DEFINITIONS are >> > set on its exported targets? >> > >> > 2. If not, anyone know if there's something that could be done to make >> > the flags end up as -isystem flags instead of -I when using >> > ${VTK_INCLUDE_DIRS}? >> >> Disregard this question: I realized that I could simply use SYSTEM in >> my target_include_directories(...) to make CMake treat it as a system >> include directory, which makes it use -isystem on compilers that >> support it. >> >> So then it's only question 1 left. I think it would be nice to have >> INTERFACE_{INCLUDE_DIRECTORIES,DEFINITIONS} set on the targets, just >> to avoid having to add ${VTK_INCLUDE_DIRS} and ${VTK_DEFINITIONS} >> manually. >> >> Elvis >> >> > >> > Cheers, >> > Elvis >> > >> > [1] https://github.com/include-what-you-use/include-what-you-use >> _______________________________________________ >> 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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > From dave.demarle at kitware.com Tue May 30 10:16:42 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 30 May 2017 10:16:42 -0400 Subject: [vtk-developers] Karego broken In-Reply-To: References: Message-ID: I'll see about updating the compiler as a stop gap to restore VTK's coverage, valgrind and oxygen submissions. The machine is rather old though we'll move those somewhere else afterward. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, May 30, 2017 at 8:18 AM, Robert Maynard wrote: > Hi Ken, > > This was caused by the changes required to explicitly require a C++11 > compiler. The compiler on Karego is too old, so we need to either upgrade > the compiler to GCC 4.8 or we need to move the builds to a new machine. > > On Tue, May 30, 2017 at 8:10 AM, Ken Martin > wrote: > >> Something broke karego nightly submissions last Tuesday and they are >> still broken. The configure error is >> >> CMake Error at CMake/vtkModuleMacros.cmake:559 (target_compile_features): >> The compiler feature "cxx_override" is not known to CXX compiler >> >> "GNU" >> >> version 4.6.3. >> Call Stack (most recent call first): >> CMake/vtkModuleMacros.cmake:661 (vtk_add_library) >> Common/Core/CMakeLists.txt:726 (vtk_module_library) >> >> >> Ring a bell with anyone? >> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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: >> http://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: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue May 30 12:42:03 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 30 May 2017 12:42:03 -0400 Subject: [vtk-developers] Need someone to review a fix in FindCell Message-ID: So with some help from Rapha?l Bresson we've tracked down an error in ProbeFilter and vtkPointSet::FindCell. As find cell is a fairly core method it would be good for someone to review the fixes that can be found here: https://gitlab.kitware.com/vtk/vtk/merge_requests/2816 FindCell isn't my normal stretch of highway, but I know some of you out there do spend time in that part of the code so hopefully it will be more clear to you. Thanks Ken -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 dave.demarle at kitware.com Tue May 30 13:41:54 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 30 May 2017 13:41:54 -0400 Subject: [vtk-developers] Karego broken In-Reply-To: References: Message-ID: The machine had 4.6.3. Now it has and uses by default 4.8.1 on it. We'll see if that works tonight. If not I'll try 5.4.1 tomorrow. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, May 30, 2017 at 10:16 AM, David E DeMarle wrote: > I'll see about updating the compiler as a stop gap to restore VTK's > coverage, valgrind and oxygen submissions. > The machine is rather old though we'll move those somewhere else afterward. > > > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 <(518)%20881-4909> > > On Tue, May 30, 2017 at 8:18 AM, Robert Maynard < > robert.maynard at kitware.com> wrote: > >> Hi Ken, >> >> This was caused by the changes required to explicitly require a C++11 >> compiler. The compiler on Karego is too old, so we need to either upgrade >> the compiler to GCC 4.8 or we need to move the builds to a new machine. >> >> On Tue, May 30, 2017 at 8:10 AM, Ken Martin >> wrote: >> >>> Something broke karego nightly submissions last Tuesday and they are >>> still broken. The configure error is >>> >>> CMake Error at CMake/vtkModuleMacros.cmake:559 (target_compile_features): >>> The compiler feature "cxx_override" is not known to CXX compiler >>> >>> "GNU" >>> >>> version 4.6.3. >>> Call Stack (most recent call first): >>> CMake/vtkModuleMacros.cmake:661 (vtk_add_library) >>> Common/Core/CMakeLists.txt:726 (vtk_module_library) >>> >>> >>> Ring a bell with anyone? >>> >>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> >>> 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: >>> http://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: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue May 30 14:09:35 2017 From: sean at rogue-research.com (Sean McBride) Date: Tue, 30 May 2017 14:09:35 -0400 Subject: [vtk-developers] Need someone to review a fix in FindCell In-Reply-To: References: Message-ID: <20170530180935.846853023@mail.rogue-research.com> On Tue, 30 May 2017 12:42:03 -0400, Ken Martin said: >So with some help from Rapha?l Bresson we've tracked down an error in >ProbeFilter and vtkPointSet::FindCell. As find cell is a fairly core >method it would be good for someone to review the fixes that can be found >here: > >https://gitlab.kitware.com/vtk/vtk/merge_requests/2816 > >FindCell isn't my normal stretch of highway, but I know some of you out >there do spend time in that part of the code so hopefully it will be more >clear to you. This gives me d?j? vu... ah, here it is: Sean From dave.demarle at kitware.com Wed May 31 10:14:01 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 31 May 2017 10:14:01 -0400 Subject: [vtk-developers] Karego broken In-Reply-To: References: Message-ID: Added a new valgrind suppression. Hopefully all will be well on karego-at tomorrow. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, May 30, 2017 at 1:41 PM, David E DeMarle wrote: > The machine had 4.6.3. Now it has and uses by default 4.8.1 on it. We'll > see if that works tonight. If not I'll try 5.4.1 tomorrow. > > > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 <(518)%20881-4909> > > On Tue, May 30, 2017 at 10:16 AM, David E DeMarle < > dave.demarle at kitware.com> wrote: > >> I'll see about updating the compiler as a stop gap to restore VTK's >> coverage, valgrind and oxygen submissions. >> The machine is rather old though we'll move those somewhere else >> afterward. >> >> >> >> David E DeMarle >> Kitware, Inc. >> Principal Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 <(518)%20881-4909> >> >> On Tue, May 30, 2017 at 8:18 AM, Robert Maynard < >> robert.maynard at kitware.com> wrote: >> >>> Hi Ken, >>> >>> This was caused by the changes required to explicitly require a C++11 >>> compiler. The compiler on Karego is too old, so we need to either upgrade >>> the compiler to GCC 4.8 or we need to move the builds to a new machine. >>> >>> On Tue, May 30, 2017 at 8:10 AM, Ken Martin >>> wrote: >>> >>>> Something broke karego nightly submissions last Tuesday and they are >>>> still broken. The configure error is >>>> >>>> CMake Error at CMake/vtkModuleMacros.cmake:559 (target_compile_features): >>>> The compiler feature "cxx_override" is not known to CXX compiler >>>> >>>> "GNU" >>>> >>>> version 4.6.3. >>>> Call Stack (most recent call first): >>>> CMake/vtkModuleMacros.cmake:661 (vtk_add_library) >>>> Common/Core/CMakeLists.txt:726 (vtk_module_library) >>>> >>>> >>>> Ring a bell with anyone? >>>> >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Distinguished Engineer >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Clifton Park NY 12065 >>>> >>>> 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: >>>> http://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: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed May 31 11:27:11 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 31 May 2017 17:27:11 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-26 14:35 GMT+02:00 Ken Martin : > If you have a build of QT I think you could change > > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 > > const int requestedVersion = qMin((format.majorVersion() << 8) + > format.minorVersion(), > staticContext.defaultFormat.version); > > to be > > const int requestedVersion = (format.majorVersion() << 8) + > format.minorVersion()); > > and it would fix it for VTK/ParaView. Not sure if it has any other > consequences for Qt or if it would hit some different issue though. Qt on > windows does some tricky stuff to support OpenGL/Angle/ES2. I patched Qt (5.6 branch) like this and tried again, but no luck :( Volumes still not showing up.. ..and thinking about it, could this really have been the problem I was seeing? If Qt wrongly gave back a lower-versioned context (because of it's questionable logic), as described in the Qt bug report, then wouldn't VTK error out from the failure to obtain the version it requested? In my case, there's no output/error at all from VTK. It's just that the volumes won't show up. Another render window where I just have a vtkChartXY does show up fine. It's only the volume rendering that isn't working. Would be interesting if others who could reproduce could try patching their Qt like this to see if it solves it. Elvis > > > > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik > wrote: >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin : >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it is >> > a >> > Qt bug we already bumped into with Mesa. They have what looks to me like >> > some odd bad logic on windows for creating a context where they will not >> > give you a core context later than the latest compatibility context they >> > can >> > get. For some vendors that is fine but for others they only offer Comp >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they fixed >> > that the issue would go away. I believe Ben filed a bug report with them >> > (Qt) when he bumped into this when using Mesa on Windows. >> >> Ah yes, that could definitely be it. I found Ben's bug: >> >> https://bugreports.qt.io/browse/QTBUG-60742 >> >> The affected version is listed as 5.8.0, but I'm having trouble on >> 5.6.2, so I guess the bad logic is there as well. >> >> So let's hope for a fix in Qt then. But in the meantime, is there >> anything you can think if that I could do to work around it? I really >> want our application to work on these kinds of machines (the one I >> have was picked as a sort of a baseline for us wrt to requirements). >> >> In the bug report Ben mentions hacking around it with >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >> using Mesa. >> >> Elvis >> >> > >> > >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >> > wrote: >> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> >> > Yes, I ran it both ways. >> >> > >> >> > It works when run without the argument in the plain VTK render >> >> > window, >> >> > and it is broken (shows nothing) when run with an argument. >> >> >> >> Alright, that's good. Then we're seeing the same thing. >> >> >> >> > Seems like it's definitely related to older Intel drivers on Windows. >> >> >> >> Yes, probably. >> >> >> >> > Not sure if there is an updated driver available for my machine. >> >> > Hesitant to try changing/updating it for other reasons, and sorry, >> >> > can't sacrifice this machine's current state for the purpose of >> >> > testing this out... >> >> >> >> No worries, I'm free to do as I please with the one I have, so I'll do >> >> some experimenting with different drivers when I'm back on Monday. >> >> >> >> Thanks to everyone trying this out. >> >> >> >> Elvis >> >> >> >> > >> >> > >> >> > D >> >> > >> >> > >> >> > >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> >> > wrote: >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> >> : >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows 8.1, >> >> >>>> with an Intel HD Graphics 4000 running driver version >> >> >>>> 10.18.10.3316. >> >> >>>> I >> >> >>>> get your TestCase app window with nothing but an empty (white) >> >> >>>> client >> >> >>>> region. >> >> >>>> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL using >> >> >>>> VolumeSmartMapper works fine on this very same machine. >> >> >>>> >> >> >>>> Another data point... >> >> >> >> >> >> Just one more thing David, did you try also running the example >> >> >> without any argument on this machine? (That would make it use a >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> >> >> interesting to know if the volume shows up then. That would confirm >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, just >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it has >> >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> >> >> Elvis >> >> >> >> >> >>> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a lot >> >> >>> David. >> >> >>> >> >> >>> And just to make sure, Aron, did you run the test case as "TestCase >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise it'll >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor (not >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >> >>> >> >> >>> Elvis >> >> >>> >> >> >>>> >> >> >>>> >> >> >>>> D >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >> >>>> wrote: >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser : >> >> >>>>>> Hi Elvis, >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus >> >> >>>>>> setup - both >> >> >>>>>> intel and nvidia graphics. >> >> >>>>>> With your test case, I'm able to see the volume running either >> >> >>>>>> with >> >> >>>>>> Intel or >> >> >>>>>> nVidia, so it doesn't repro for me. >> >> >>>>>> I've got Intel HD530 graphics, with driver version 21.20.16.4627 >> >> >>>>>> Sorry, >> >> >>>>>> Aron >> >> >>>>> >> >> >>>>> Alright, bugger. Thanks for testing though! >> >> >>>>> >> >> >>>>> I won't be at the office until Monday again, but when I'm back >> >> >>>>> I'll >> >> >>>>> try experimenting with different driver versions. >> >> >>>>> >> >> >>>>> Elvis >> >> >>>>> >> >> >>>>>> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >> >>>>>>> : >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >> >>>>>>> > : >> >> >>>>>>> >> Hi Elvis, >> >> >>>>>>> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >> >>>>>>> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card >> >> >>>>>>> >> but >> >> >>>>>>> >> tried >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a Mac >> >> >>>>>>> >> (with an >> >> >>>>>>> >> Intel >> >> >>>>>>> >> HD5600). Worked fine. >> >> >>>>>>> > >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >> >> >>>>>>> > machine with >> >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >> >> >>>>>>> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. >> >> >>>>>>> >> >> >>>>>>> I've now put up the compiled self-contained test case here: >> >> >>>>>>> >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >> >>>>>>> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + >> >> >>>>>>> Intel >> >> >>>>>>> graphics could try running this test case with "TestCase 1" and >> >> >>>>>>> see if >> >> >>>>>>> the volume shows up, that would be great. >> >> >>>>>>> >> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >> >>>>>>> >> >> >>>>>>> Elvis >> >> >>>>>>> >> >> >>>>>>> > >> >> >>>>>>> > I could put up my build of the test case as a self-contained >> >> >>>>>>> > .zip, to >> >> >>>>>>> > make it easy to test. >> >> >>>>>>> > >> >> >>>>>>> >> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics >> >> >>>>>>> >> drivers >> >> >>>>>>> >> on your >> >> >>>>>>> >> Windows machine may need updating. >> >> >>>>>>> > >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and >> >> >>>>>>> > just >> >> >>>>>>> > use a >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't >> >> >>>>>>> > that >> >> >>>>>>> > suggest that the drivers are capable enough, and that the >> >> >>>>>>> > problem is >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >> >>>>>>> > >> >> >>>>>>> > Elvis >> >> >>>>>>> > >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >> >>>>>>> >> wrote: >> >> >>>>>>> >>> >> >> >>>>>>> >>> Okay thanks. >> >> >>>>>>> >>> >> >> >>>>>>> >>> I?ll take a look. >> >> >>>>>>> >>> >> >> >>>>>>> >>> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >> >>>>>>> >>> wrote: >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >> >>>>>>> >>>> : >> >> >>>>>>> >>>> > Hi Elvis, >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary >> >> >>>>>>> >>>> > and >> >> >>>>>>> >>>> > test >> >> >>>>>>> >>>> > volume >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a >> >> >>>>>>> >>>> > test >> >> >>>>>>> >>>> > dataset. >> >> >>>>>>> >>>> > ParaView >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >> >> >>>>>>> >>>> > before diving >> >> >>>>>>> >>>> > into the >> >> >>>>>>> >>>> > code. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal test >> >> >>>>>>> >>>> case. The >> >> >>>>>>> >>>> volume won't show up. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> It does show up if I switch to the software based ray cast >> >> >>>>>>> >>>> mapper >> >> >>>>>>> >>>> (but >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the >> >> >>>>>>> >>>> GPU >> >> >>>>>>> >>>> one being >> >> >>>>>>> >>>> used). >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help >> >> >>>>>>> >>>> debugging. >> >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> Elvis >> >> >>>>>>> >>>> >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Thanks, >> >> >>>>>>> >>>> > Sankhesh >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >> >>>>>>> >>>> > wrote: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Hi all, >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >> >> >>>>>>> >>>> >> rendered using >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, >> >> >>>>>>> >>>> >> Intel >> >> >>>>>>> >>>> >> graphics >> >> >>>>>>> >>>> >> (HD >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up >> >> >>>>>>> >>>> >> fine >> >> >>>>>>> >>>> >> on >> >> >>>>>>> >>>> >> Windows 7 >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried turning >> >> >>>>>>> >>>> >> off >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >> >>>>>>> >>>> >> QSurfaceFormat. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >> >> >>>>>>> >>>> >> attached >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and >> >> >>>>>>> >>>> >> "TestCase >> >> >>>>>>> >>>> >> 1" >> >> >>>>>>> >>>> >> (right). >> >> >>>>>>> >>>> >> The former uses a plain render window while the latter >> >> >>>>>>> >>>> >> uses the >> >> >>>>>>> >>>> >> new >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 >> >> >>>>>>> >>>> >> screenshot, >> >> >>>>>>> >>>> >> the >> >> >>>>>>> >>>> >> plain >> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget one >> >> >>>>>>> >>>> >> is >> >> >>>>>>> >>>> >> not >> >> >>>>>>> >>>> >> showing >> >> >>>>>>> >>>> >> the volume. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Versions used: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >>>>>>> >>>> >> Qt 5.5.1 >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >>>>>>> >>>> >> Qt 5.6.2 >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my >> >> >>>>>>> >>>> >> build >> >> >>>>>>> >>>> >> of the >> >> >>>>>>> >>>> >> test >> >> >>>>>>> >>>> >> case if you want. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha issue I >> >> >>>>>>> >>>> >> reported >> >> >>>>>>> >>>> >> and >> >> >>>>>>> >>>> >> got solved in my other thread. >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >> >>>>>>> >>>> >> Elvis >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> main.cpp: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> #include >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >> >>>>>>> >>>> >> { >> >> >>>>>>> >>>> >> auto defaultFormat = >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >> >>>>>>> >>>> >> vtkNew colorFunction; >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >> >>>>>>> >>>> >> std::fill_n(static_cast> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >> >>>>>>> >>>> >> 8000000, 0.01); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volumeMapper; >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew volume; >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >> >>>>>>> >>>> >> vtkNew window; >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >> >>>>>>> >>>> >> widget->show(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> return app.exec(); >> >> >>>>>>> >>>> >> } else { >> >> >>>>>>> >>>> >> // Render with "plain" render window / >> >> >>>>>>> >>>> >> interactor >> >> >>>>>>> >>>> >> vtkNew window; >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> vtkNew interactor; >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >> >>>>>>> >>>> >> interactor->Start(); >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> return 0; >> >> >>>>>>> >>>> >> } >> >> >>>>>>> >>>> >> } >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> project(TestCase) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >>>>>>> >>>> >> REQUIRED >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >>>>>>> >>>> >> Qt5::Widgets >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >> >>>>>>> >>>> >> ) >> >> >>>>>>> >>>> >> _______________________________________________ >> >> >>>>>>> >>>> >> 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: >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> > -- >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Sankhesh Jhaveri >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >>>> > 881-4417 >> >> >>>>>>> >>> >> >> >>>>>>> >>> -- >> >> >>>>>>> >>> >> >> >>>>>>> >>> Sankhesh Jhaveri >> >> >>>>>>> >>> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >>> 881-4417 >> >> >>>>>>> >> >> >> >>>>>>> >> -- >> >> >>>>>>> >> >> >> >>>>>>> >> Sankhesh Jhaveri >> >> >>>>>>> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >> >> >>>>>>> >> 881-4417 >> >> >>>>>>> _______________________________________________ >> >> >>>>>>> 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: >> >> >>>>>>> http://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: >> >> >>>>> http://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: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > >> > >> > >> > -- >> > Ken Martin PhD >> > Distinguished Engineer >> > Kitware Inc. >> > 28 Corporate Drive >> > Clifton Park NY 12065 >> > >> > 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. > > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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. From ken.martin at kitware.com Wed May 31 12:53:24 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 31 May 2017 12:53:24 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: If it is only VolumeRendering then it may be you are requesting Multisamples. What happens if you turn that off? On Wed, May 31, 2017 at 11:27 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-26 14:35 GMT+02:00 Ken Martin : > > If you have a build of QT I think you could change > > > > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/ > qwindowsglcontext.cpp#L730 > > > > const int requestedVersion = qMin((format.majorVersion() << 8) + > > format.minorVersion(), > > staticContext.defaultFormat.version); > > > > to be > > > > const int requestedVersion = (format.majorVersion() << 8) + > > format.minorVersion()); > > > > and it would fix it for VTK/ParaView. Not sure if it has any other > > consequences for Qt or if it would hit some different issue though. Qt on > > windows does some tricky stuff to support OpenGL/Angle/ES2. > > I patched Qt (5.6 branch) like this and tried again, but no luck :( > Volumes still not showing up.. > > ..and thinking about it, could this really have been the problem I was > seeing? If Qt wrongly gave back a lower-versioned context (because of > it's questionable logic), as described in the Qt bug report, then > wouldn't VTK error out from the failure to obtain the version it > requested? In my case, there's no output/error at all from VTK. It's > just that the volumes won't show up. > > Another render window where I just have a vtkChartXY does show up > fine. It's only the volume rendering that isn't working. > > Would be interesting if others who could reproduce could try patching > their Qt like this to see if it solves it. > > Elvis > > > > > > > > > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik > > wrote: > >> > >> 2017-05-26 2:24 GMT+02:00 Ken Martin : > >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it > is > >> > a > >> > Qt bug we already bumped into with Mesa. They have what looks to me > like > >> > some odd bad logic on windows for creating a context where they will > not > >> > give you a core context later than the latest compatibility context > they > >> > can > >> > get. For some vendors that is fine but for others they only offer Comp > >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may support > >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they > fixed > >> > that the issue would go away. I believe Ben filed a bug report with > them > >> > (Qt) when he bumped into this when using Mesa on Windows. > >> > >> Ah yes, that could definitely be it. I found Ben's bug: > >> > >> https://bugreports.qt.io/browse/QTBUG-60742 > >> > >> The affected version is listed as 5.8.0, but I'm having trouble on > >> 5.6.2, so I guess the bad logic is there as well. > >> > >> So let's hope for a fix in Qt then. But in the meantime, is there > >> anything you can think if that I could do to work around it? I really > >> want our application to work on these kinds of machines (the one I > >> have was picked as a sort of a baseline for us wrt to requirements). > >> > >> In the bug report Ben mentions hacking around it with > >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not > >> using Mesa. > >> > >> Elvis > >> > >> > > >> > > >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik > >> > wrote: > >> >> > >> >> 2017-05-25 23:37 GMT+02:00 David Cole : > >> >> > Yes, I ran it both ways. > >> >> > > >> >> > It works when run without the argument in the plain VTK render > >> >> > window, > >> >> > and it is broken (shows nothing) when run with an argument. > >> >> > >> >> Alright, that's good. Then we're seeing the same thing. > >> >> > >> >> > Seems like it's definitely related to older Intel drivers on > Windows. > >> >> > >> >> Yes, probably. > >> >> > >> >> > Not sure if there is an updated driver available for my machine. > >> >> > Hesitant to try changing/updating it for other reasons, and sorry, > >> >> > can't sacrifice this machine's current state for the purpose of > >> >> > testing this out... > >> >> > >> >> No worries, I'm free to do as I please with the one I have, so I'll > do > >> >> some experimenting with different drivers when I'm back on Monday. > >> >> > >> >> Thanks to everyone trying this out. > >> >> > >> >> Elvis > >> >> > >> >> > > >> >> > > >> >> > D > >> >> > > >> >> > > >> >> > > >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik > >> >> > wrote: > >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik > >> >> >> : > >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : > >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows > 8.1, > >> >> >>>> with an Intel HD Graphics 4000 running driver version > >> >> >>>> 10.18.10.3316. > >> >> >>>> I > >> >> >>>> get your TestCase app window with nothing but an empty (white) > >> >> >>>> client > >> >> >>>> region. > >> >> >>>> > >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL > using > >> >> >>>> VolumeSmartMapper works fine on this very same machine. > >> >> >>>> > >> >> >>>> Another data point... > >> >> >> > >> >> >> Just one more thing David, did you try also running the example > >> >> >> without any argument on this machine? (That would make it use a > >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be > >> >> >> interesting to know if the volume shows up then. That would > confirm > >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, > just > >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it > has > >> >> >> something to do with the new QVTKOpenGLWidget. > >> >> >> > >> >> >> Elvis > >> >> >> > >> >> >>> > >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a > lot > >> >> >>> David. > >> >> >>> > >> >> >>> And just to make sure, Aron, did you run the test case as > "TestCase > >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise > it'll > >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor > (not > >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. > >> >> >>> > >> >> >>> Elvis > >> >> >>> > >> >> >>>> > >> >> >>>> > >> >> >>>> D > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik > >> >> >>>> wrote: > >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser < > aron.helser at kitware.com>: > >> >> >>>>>> Hi Elvis, > >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an Optimus > >> >> >>>>>> setup - both > >> >> >>>>>> intel and nvidia graphics. > >> >> >>>>>> With your test case, I'm able to see the volume running either > >> >> >>>>>> with > >> >> >>>>>> Intel or > >> >> >>>>>> nVidia, so it doesn't repro for me. > >> >> >>>>>> I've got Intel HD530 graphics, with driver version > 21.20.16.4627 > >> >> >>>>>> Sorry, > >> >> >>>>>> Aron > >> >> >>>>> > >> >> >>>>> Alright, bugger. Thanks for testing though! > >> >> >>>>> > >> >> >>>>> I won't be at the office until Monday again, but when I'm back > >> >> >>>>> I'll > >> >> >>>>> try experimenting with different driver versions. > >> >> >>>>> > >> >> >>>>> Elvis > >> >> >>>>> > >> >> >>>>>> > >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik > >> >> >>>>>> wrote: > >> >> >>>>>>> > >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik > >> >> >>>>>>> : > >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri > >> >> >>>>>>> > : > >> >> >>>>>>> >> Hi Elvis, > >> >> >>>>>>> >> > >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( > >> >> >>>>>>> >> > >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics card > >> >> >>>>>>> >> but > >> >> >>>>>>> >> tried > >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a > Mac > >> >> >>>>>>> >> (with an > >> >> >>>>>>> >> Intel > >> >> >>>>>>> >> HD5600). Worked fine. > >> >> >>>>>>> > > >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 > >> >> >>>>>>> > machine with > >> >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. > >> >> >>>>>>> > >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce Sankhesh. > >> >> >>>>>>> > >> >> >>>>>>> I've now put up the compiled self-contained test case here: > >> >> >>>>>>> > >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) > >> >> >>>>>>> > >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + > >> >> >>>>>>> Intel > >> >> >>>>>>> graphics could try running this test case with "TestCase 1" > and > >> >> >>>>>>> see if > >> >> >>>>>>> the volume shows up, that would be great. > >> >> >>>>>>> > >> >> >>>>>>> (Running the test case with argc > 2 will make it use > >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). > >> >> >>>>>>> > >> >> >>>>>>> Elvis > >> >> >>>>>>> > >> >> >>>>>>> > > >> >> >>>>>>> > I could put up my build of the test case as a > self-contained > >> >> >>>>>>> > .zip, to > >> >> >>>>>>> > make it easy to test. > >> >> >>>>>>> > > >> >> >>>>>>> >> > >> >> >>>>>>> >> At this point, I am inclined to think that the graphics > >> >> >>>>>>> >> drivers > >> >> >>>>>>> >> on your > >> >> >>>>>>> >> Windows machine may need updating. > >> >> >>>>>>> > > >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and > >> >> >>>>>>> > just > >> >> >>>>>>> > use a > >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. Wouldn't > >> >> >>>>>>> > that > >> >> >>>>>>> > suggest that the drivers are capable enough, and that the > >> >> >>>>>>> > problem is > >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > >> >> >>>>>>> > > >> >> >>>>>>> > Elvis > >> >> >>>>>>> > > >> >> >>>>>>> >> > >> >> >>>>>>> >> > >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > >> >> >>>>>>> >> wrote: > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> Okay thanks. > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> I?ll take a look. > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik > >> >> >>>>>>> >>> wrote: > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >> >> >>>>>>> >>>> : > >> >> >>>>>>> >>>> > Hi Elvis, > >> >> >>>>>>> >>>> > > >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary > >> >> >>>>>>> >>>> > and > >> >> >>>>>>> >>>> > test > >> >> >>>>>>> >>>> > volume > >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a > >> >> >>>>>>> >>>> > test > >> >> >>>>>>> >>>> > dataset. > >> >> >>>>>>> >>>> > ParaView > >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test > >> >> >>>>>>> >>>> > before diving > >> >> >>>>>>> >>>> > into the > >> >> >>>>>>> >>>> > code. > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> I tried the wavelet example with Paraview > >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 > >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal > test > >> >> >>>>>>> >>>> case. The > >> >> >>>>>>> >>>> volume won't show up. > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> It does show up if I switch to the software based ray > cast > >> >> >>>>>>> >>>> mapper > >> >> >>>>>>> >>>> (but > >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the > >> >> >>>>>>> >>>> GPU > >> >> >>>>>>> >>>> one being > >> >> >>>>>>> >>>> used). > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to help > >> >> >>>>>>> >>>> debugging. > >> >> >>>>>>> >>>> There are no errors printed when I run my test case. > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> Elvis > >> >> >>>>>>> >>>> > >> >> >>>>>>> >>>> > > >> >> >>>>>>> >>>> > Thanks, > >> >> >>>>>>> >>>> > Sankhesh > >> >> >>>>>>> >>>> > > >> >> >>>>>>> >>>> > > >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > >> >> >>>>>>> >>>> > wrote: > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Hi all, > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes > >> >> >>>>>>> >>>> >> rendered using > >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, > >> >> >>>>>>> >>>> >> Intel > >> >> >>>>>>> >>>> >> graphics > >> >> >>>>>>> >>>> >> (HD > >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up > >> >> >>>>>>> >>>> >> fine > >> >> >>>>>>> >>>> >> on > >> >> >>>>>>> >>>> >> Windows 7 > >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried > turning > >> >> >>>>>>> >>>> >> off > >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default > >> >> >>>>>>> >>>> >> QSurfaceFormat. > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the > >> >> >>>>>>> >>>> >> attached > >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and > >> >> >>>>>>> >>>> >> "TestCase > >> >> >>>>>>> >>>> >> 1" > >> >> >>>>>>> >>>> >> (right). > >> >> >>>>>>> >>>> >> The former uses a plain render window while the > latter > >> >> >>>>>>> >>>> >> uses the > >> >> >>>>>>> >>>> >> new > >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 > >> >> >>>>>>> >>>> >> screenshot, > >> >> >>>>>>> >>>> >> the > >> >> >>>>>>> >>>> >> plain > >> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget > one > >> >> >>>>>>> >>>> >> is > >> >> >>>>>>> >>>> >> not > >> >> >>>>>>> >>>> >> showing > >> >> >>>>>>> >>>> >> the volume. > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Versions used: > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 > >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >> >> >>>>>>> >>>> >> Qt 5.5.1 > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Windows 7 > >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >> >> >>>>>>> >>>> >> Qt 5.6.2 > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Any ideas what the problem might be? > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my > >> >> >>>>>>> >>>> >> build > >> >> >>>>>>> >>>> >> of the > >> >> >>>>>>> >>>> >> test > >> >> >>>>>>> >>>> >> case if you want. > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha > issue I > >> >> >>>>>>> >>>> >> reported > >> >> >>>>>>> >>>> >> and > >> >> >>>>>>> >>>> >> got solved in my other thread. > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> Many thanks in advance, > >> >> >>>>>>> >>>> >> Elvis > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> main.cpp: > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> #include > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) > >> >> >>>>>>> >>>> >> { > >> >> >>>>>>> >>>> >> auto defaultFormat = > >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); > >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); > >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> QApplication app(argc, argv); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> // Set up volume rendering > >> >> >>>>>>> >>>> >> vtkNew colorFunction; > >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); > >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew opacityFunction; > >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); > >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew imageData; > >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); > >> >> >>>>>>> >>>> >> std::fill_n(static_cast >> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), > >> >> >>>>>>> >>>> >> 8000000, 0.01); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew volumeMapper; > >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew volumeProperty; > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity( > opacityFunction.Get()); > >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); > >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew volume; > >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); > >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew renderer; > >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); > >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> if (argc > 1) { > >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget > >> >> >>>>>>> >>>> >> vtkNew window; > >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); > >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); > >> >> >>>>>>> >>>> >> widget->show(); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> return app.exec(); > >> >> >>>>>>> >>>> >> } else { > >> >> >>>>>>> >>>> >> // Render with "plain" render window / > >> >> >>>>>>> >>>> >> interactor > >> >> >>>>>>> >>>> >> vtkNew window; > >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> vtkNew > interactor; > >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); > >> >> >>>>>>> >>>> >> interactor->Start(); > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> return 0; > >> >> >>>>>>> >>>> >> } > >> >> >>>>>>> >>>> >> } > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> CMakeLists.txt: > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> project(TestCase) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS > >> >> >>>>>>> >>>> >> vtkCommonCore > >> >> >>>>>>> >>>> >> vtkCommonDataModel > >> >> >>>>>>> >>>> >> vtkCommonExecutionModel > >> >> >>>>>>> >>>> >> vtkCommonMath > >> >> >>>>>>> >>>> >> vtkFiltersSources > >> >> >>>>>>> >>>> >> vtkGUISupportQt > >> >> >>>>>>> >>>> >> vtkInteractionStyle > >> >> >>>>>>> >>>> >> vtkRenderingCore > >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 > >> >> >>>>>>> >>>> >> vtkRenderingVolume > >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >> >> >>>>>>> >>>> >> REQUIRED > >> >> >>>>>>> >>>> >> ) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC > >> >> >>>>>>> >>>> >> vtkCommonCore > >> >> >>>>>>> >>>> >> vtkCommonDataModel > >> >> >>>>>>> >>>> >> vtkCommonExecutionModel > >> >> >>>>>>> >>>> >> vtkCommonMath > >> >> >>>>>>> >>>> >> vtkFiltersSources > >> >> >>>>>>> >>>> >> vtkGUISupportQt > >> >> >>>>>>> >>>> >> vtkInteractionStyle > >> >> >>>>>>> >>>> >> vtkRenderingCore > >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 > >> >> >>>>>>> >>>> >> vtkRenderingVolume > >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >> >> >>>>>>> >>>> >> Qt5::Widgets > >> >> >>>>>>> >>>> >> ) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC > >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} > >> >> >>>>>>> >>>> >> ) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC > >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} > >> >> >>>>>>> >>>> >> ) > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES > >> >> >>>>>>> >>>> >> CXX_STANDARD 14 > >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON > >> >> >>>>>>> >>>> >> ) > >> >> >>>>>>> >>>> >> _______________________________________________ > >> >> >>>>>>> >>>> >> 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: > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk- > developers > >> >> >>>>>>> >>>> >> > >> >> >>>>>>> >>>> > -- > >> >> >>>>>>> >>>> > > >> >> >>>>>>> >>>> > Sankhesh Jhaveri > >> >> >>>>>>> >>>> > > >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) > >> >> >>>>>>> >>>> > 881-4417 > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> -- > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> Sankhesh Jhaveri > >> >> >>>>>>> >>> > >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) > >> >> >>>>>>> >>> 881-4417 > >> >> >>>>>>> >> > >> >> >>>>>>> >> -- > >> >> >>>>>>> >> > >> >> >>>>>>> >> Sankhesh Jhaveri > >> >> >>>>>>> >> > >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) > >> >> >>>>>>> >> 881-4417 > >> >> >>>>>>> _______________________________________________ > >> >> >>>>>>> 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: > >> >> >>>>>>> http://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: > >> >> >>>>> http://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: > >> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> >> > >> > > >> > > >> > > >> > -- > >> > Ken Martin PhD > >> > Distinguished Engineer > >> > Kitware Inc. > >> > 28 Corporate Drive > >> > Clifton Park NY 12065 > >> > > >> > 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. > > > > > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > > > 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. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 elvis.stansvik at orexplore.com Wed May 31 14:55:49 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 31 May 2017 20:55:49 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-31 18:53 GMT+02:00 Ken Martin : > If it is only VolumeRendering then it may be you are requesting > Multisamples. What happens if you turn that off? Multisamples is turned off (see my test case in my initial mail): auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); defaultFormat.setSamples(0); QSurfaceFormat::setDefaultFormat(defaultFormat); It would be great if you could try the test case out on the 4600 system where you said you had problems with PV 5.4. I think it would help in narrowing down the issue. Make sure you run it with a parameter (e.g. "TestCase 1"), so that it uses QVTKOpenGLWidget and not a plain render window/interactor. Elvis > > On Wed, May 31, 2017 at 11:27 AM, Elvis Stansvik > wrote: >> >> 2017-05-26 14:35 GMT+02:00 Ken Martin : >> > If you have a build of QT I think you could change >> > >> > >> > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 >> > >> > const int requestedVersion = qMin((format.majorVersion() << 8) + >> > format.minorVersion(), >> > staticContext.defaultFormat.version); >> > >> > to be >> > >> > const int requestedVersion = (format.majorVersion() << 8) + >> > format.minorVersion()); >> > >> > and it would fix it for VTK/ParaView. Not sure if it has any other >> > consequences for Qt or if it would hit some different issue though. Qt >> > on >> > windows does some tricky stuff to support OpenGL/Angle/ES2. >> >> I patched Qt (5.6 branch) like this and tried again, but no luck :( >> Volumes still not showing up.. >> >> ..and thinking about it, could this really have been the problem I was >> seeing? If Qt wrongly gave back a lower-versioned context (because of >> it's questionable logic), as described in the Qt bug report, then >> wouldn't VTK error out from the failure to obtain the version it >> requested? In my case, there's no output/error at all from VTK. It's >> just that the volumes won't show up. >> >> Another render window where I just have a vtkChartXY does show up >> fine. It's only the volume rendering that isn't working. >> >> Would be interesting if others who could reproduce could try patching >> their Qt like this to see if it solves it. >> >> Elvis >> >> > >> > >> > >> > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik >> > wrote: >> >> >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin : >> >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure it >> >> > is >> >> > a >> >> > Qt bug we already bumped into with Mesa. They have what looks to me >> >> > like >> >> > some odd bad logic on windows for creating a context where they will >> >> > not >> >> > give you a core context later than the latest compatibility context >> >> > they >> >> > can >> >> > get. For some vendors that is fine but for others they only offer >> >> > Comp >> >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may >> >> > support >> >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they >> >> > fixed >> >> > that the issue would go away. I believe Ben filed a bug report with >> >> > them >> >> > (Qt) when he bumped into this when using Mesa on Windows. >> >> >> >> Ah yes, that could definitely be it. I found Ben's bug: >> >> >> >> https://bugreports.qt.io/browse/QTBUG-60742 >> >> >> >> The affected version is listed as 5.8.0, but I'm having trouble on >> >> 5.6.2, so I guess the bad logic is there as well. >> >> >> >> So let's hope for a fix in Qt then. But in the meantime, is there >> >> anything you can think if that I could do to work around it? I really >> >> want our application to work on these kinds of machines (the one I >> >> have was picked as a sort of a baseline for us wrt to requirements). >> >> >> >> In the bug report Ben mentions hacking around it with >> >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >> >> using Mesa. >> >> >> >> Elvis >> >> >> >> > >> >> > >> >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >> >> > wrote: >> >> >> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> >> >> > Yes, I ran it both ways. >> >> >> > >> >> >> > It works when run without the argument in the plain VTK render >> >> >> > window, >> >> >> > and it is broken (shows nothing) when run with an argument. >> >> >> >> >> >> Alright, that's good. Then we're seeing the same thing. >> >> >> >> >> >> > Seems like it's definitely related to older Intel drivers on >> >> >> > Windows. >> >> >> >> >> >> Yes, probably. >> >> >> >> >> >> > Not sure if there is an updated driver available for my machine. >> >> >> > Hesitant to try changing/updating it for other reasons, and sorry, >> >> >> > can't sacrifice this machine's current state for the purpose of >> >> >> > testing this out... >> >> >> >> >> >> No worries, I'm free to do as I please with the one I have, so I'll >> >> >> do >> >> >> some experimenting with different drivers when I'm back on Monday. >> >> >> >> >> >> Thanks to everyone trying this out. >> >> >> >> >> >> Elvis >> >> >> >> >> >> > >> >> >> > >> >> >> > D >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> >> >> > wrote: >> >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> >> >> : >> >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows >> >> >> >>>> 8.1, >> >> >> >>>> with an Intel HD Graphics 4000 running driver version >> >> >> >>>> 10.18.10.3316. >> >> >> >>>> I >> >> >> >>>> get your TestCase app window with nothing but an empty (white) >> >> >> >>>> client >> >> >> >>>> region. >> >> >> >>>> >> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL >> >> >> >>>> using >> >> >> >>>> VolumeSmartMapper works fine on this very same machine. >> >> >> >>>> >> >> >> >>>> Another data point... >> >> >> >> >> >> >> >> Just one more thing David, did you try also running the example >> >> >> >> without any argument on this machine? (That would make it use a >> >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would be >> >> >> >> interesting to know if the volume shows up then. That would >> >> >> >> confirm >> >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, >> >> >> >> just >> >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that it >> >> >> >> has >> >> >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> >> >> >> >> Elvis >> >> >> >> >> >> >> >>> >> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a >> >> >> >>> lot >> >> >> >>> David. >> >> >> >>> >> >> >> >>> And just to make sure, Aron, did you run the test case as >> >> >> >>> "TestCase >> >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise >> >> >> >>> it'll >> >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor >> >> >> >>> (not >> >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >> >> >>> >> >> >> >>> Elvis >> >> >> >>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> D >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >> >> >>>> wrote: >> >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser >> >> >> >>>>> : >> >> >> >>>>>> Hi Elvis, >> >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an >> >> >> >>>>>> Optimus >> >> >> >>>>>> setup - both >> >> >> >>>>>> intel and nvidia graphics. >> >> >> >>>>>> With your test case, I'm able to see the volume running >> >> >> >>>>>> either >> >> >> >>>>>> with >> >> >> >>>>>> Intel or >> >> >> >>>>>> nVidia, so it doesn't repro for me. >> >> >> >>>>>> I've got Intel HD530 graphics, with driver version >> >> >> >>>>>> 21.20.16.4627 >> >> >> >>>>>> Sorry, >> >> >> >>>>>> Aron >> >> >> >>>>> >> >> >> >>>>> Alright, bugger. Thanks for testing though! >> >> >> >>>>> >> >> >> >>>>> I won't be at the office until Monday again, but when I'm back >> >> >> >>>>> I'll >> >> >> >>>>> try experimenting with different driver versions. >> >> >> >>>>> >> >> >> >>>>> Elvis >> >> >> >>>>> >> >> >> >>>>>> >> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >> >> >>>>>> wrote: >> >> >> >>>>>>> >> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >> >> >>>>>>> : >> >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >> >> >>>>>>> > : >> >> >> >>>>>>> >> Hi Elvis, >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. :( >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics >> >> >> >>>>>>> >> card >> >> >> >>>>>>> >> but >> >> >> >>>>>>> >> tried >> >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as a >> >> >> >>>>>>> >> Mac >> >> >> >>>>>>> >> (with an >> >> >> >>>>>>> >> Intel >> >> >> >>>>>>> >> HD5600). Worked fine. >> >> >> >>>>>>> > >> >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows 7 >> >> >> >>>>>>> > machine with >> >> >> >>>>>>> > Intel graphics? Would be great if someone could reproduce. >> >> >> >>>>>>> >> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce >> >> >> >>>>>>> Sankhesh. >> >> >> >>>>>>> >> >> >> >>>>>>> I've now put up the compiled self-contained test case here: >> >> >> >>>>>>> >> >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >> >> >>>>>>> >> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) + >> >> >> >>>>>>> Intel >> >> >> >>>>>>> graphics could try running this test case with "TestCase 1" >> >> >> >>>>>>> and >> >> >> >>>>>>> see if >> >> >> >>>>>>> the volume shows up, that would be great. >> >> >> >>>>>>> >> >> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >> >> >>>>>>> >> >> >> >>>>>>> Elvis >> >> >> >>>>>>> >> >> >> >>>>>>> > >> >> >> >>>>>>> > I could put up my build of the test case as a >> >> >> >>>>>>> > self-contained >> >> >> >>>>>>> > .zip, to >> >> >> >>>>>>> > make it easy to test. >> >> >> >>>>>>> > >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics >> >> >> >>>>>>> >> drivers >> >> >> >>>>>>> >> on your >> >> >> >>>>>>> >> Windows machine may need updating. >> >> >> >>>>>>> > >> >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, and >> >> >> >>>>>>> > just >> >> >> >>>>>>> > use a >> >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. >> >> >> >>>>>>> > Wouldn't >> >> >> >>>>>>> > that >> >> >> >>>>>>> > suggest that the drivers are capable enough, and that the >> >> >> >>>>>>> > problem is >> >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >> >> >>>>>>> > >> >> >> >>>>>>> > Elvis >> >> >> >>>>>>> > >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >> >> >>>>>>> >> wrote: >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> Okay thanks. >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> I?ll take a look. >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >> >> >>>>>>> >>> wrote: >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >> >> >>>>>>> >>>> : >> >> >> >>>>>>> >>>> > Hi Elvis, >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly binary >> >> >> >>>>>>> >>>> > and >> >> >> >>>>>>> >>>> > test >> >> >> >>>>>>> >>>> > volume >> >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source for a >> >> >> >>>>>>> >>>> > test >> >> >> >>>>>>> >>>> > dataset. >> >> >> >>>>>>> >>>> > ParaView >> >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good test >> >> >> >>>>>>> >>>> > before diving >> >> >> >>>>>>> >>>> > into the >> >> >> >>>>>>> >>>> > code. >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal >> >> >> >>>>>>> >>>> test >> >> >> >>>>>>> >>>> case. The >> >> >> >>>>>>> >>>> volume won't show up. >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> It does show up if I switch to the software based ray >> >> >> >>>>>>> >>>> cast >> >> >> >>>>>>> >>>> mapper >> >> >> >>>>>>> >>>> (but >> >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in the >> >> >> >>>>>>> >>>> GPU >> >> >> >>>>>>> >>>> one being >> >> >> >>>>>>> >>>> used). >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to >> >> >> >>>>>>> >>>> help >> >> >> >>>>>>> >>>> debugging. >> >> >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> Elvis >> >> >> >>>>>>> >>>> >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > Thanks, >> >> >> >>>>>>> >>>> > Sankhesh >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >> >> >>>>>>> >>>> > wrote: >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Hi all, >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get volumes >> >> >> >>>>>>> >>>> >> rendered using >> >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, >> >> >> >>>>>>> >>>> >> Intel >> >> >> >>>>>>> >>>> >> graphics >> >> >> >>>>>>> >>>> >> (HD >> >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show up >> >> >> >>>>>>> >>>> >> fine >> >> >> >>>>>>> >>>> >> on >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried >> >> >> >>>>>>> >>>> >> turning >> >> >> >>>>>>> >>>> >> off >> >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >> >> >>>>>>> >>>> >> QSurfaceFormat. >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the >> >> >> >>>>>>> >>>> >> attached >> >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and >> >> >> >>>>>>> >>>> >> "TestCase >> >> >> >>>>>>> >>>> >> 1" >> >> >> >>>>>>> >>>> >> (right). >> >> >> >>>>>>> >>>> >> The former uses a plain render window while the >> >> >> >>>>>>> >>>> >> latter >> >> >> >>>>>>> >>>> >> uses the >> >> >> >>>>>>> >>>> >> new >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 >> >> >> >>>>>>> >>>> >> screenshot, >> >> >> >>>>>>> >>>> >> the >> >> >> >>>>>>> >>>> >> plain >> >> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget >> >> >> >>>>>>> >>>> >> one >> >> >> >>>>>>> >>>> >> is >> >> >> >>>>>>> >>>> >> not >> >> >> >>>>>>> >>>> >> showing >> >> >> >>>>>>> >>>> >> the volume. >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Versions used: >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >> >>>>>>> >>>> >> Qt 5.5.1 >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >> >>>>>>> >>>> >> Qt 5.6.2 >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my >> >> >> >>>>>>> >>>> >> build >> >> >> >>>>>>> >>>> >> of the >> >> >> >>>>>>> >>>> >> test >> >> >> >>>>>>> >>>> >> case if you want. >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha >> >> >> >>>>>>> >>>> >> issue I >> >> >> >>>>>>> >>>> >> reported >> >> >> >>>>>>> >>>> >> and >> >> >> >>>>>>> >>>> >> got solved in my other thread. >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >> >> >>>>>>> >>>> >> Elvis >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> main.cpp: >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >> >> >>>>>>> >>>> >> { >> >> >> >>>>>>> >>>> >> auto defaultFormat = >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >> >> >>>>>>> >>>> >> vtkNew colorFunction; >> >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0); >> >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >> >> >>>>>>> >>>> >> std::fill_n(static_cast> >> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >> >> >>>>>>> >>>> >> 8000000, 0.01); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew volumeMapper; >> >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew volume; >> >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >> >> >>>>>>> >>>> >> vtkNew window; >> >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >> >> >>>>>>> >>>> >> widget->show(); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> return app.exec(); >> >> >> >>>>>>> >>>> >> } else { >> >> >> >>>>>>> >>>> >> // Render with "plain" render window / >> >> >> >>>>>>> >>>> >> interactor >> >> >> >>>>>>> >>>> >> vtkNew window; >> >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> vtkNew >> >> >> >>>>>>> >>>> >> interactor; >> >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >> >> >>>>>>> >>>> >> interactor->Start(); >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> return 0; >> >> >> >>>>>>> >>>> >> } >> >> >> >>>>>>> >>>> >> } >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> project(TestCase) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >> >>>>>>> >>>> >> REQUIRED >> >> >> >>>>>>> >>>> >> ) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >> >>>>>>> >>>> >> Qt5::Widgets >> >> >> >>>>>>> >>>> >> ) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >> >> >>>>>>> >>>> >> ) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >> >> >>>>>>> >>>> >> ) >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >> >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >> >> >>>>>>> >>>> >> ) >> >> >> >>>>>>> >>>> >> _______________________________________________ >> >> >> >>>>>>> >>>> >> 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: >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> > -- >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > Sankhesh Jhaveri >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | (518) >> >> >> >>>>>>> >>>> > 881-4417 >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> -- >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> Sankhesh Jhaveri >> >> >> >>>>>>> >>> >> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >> >> >> >>>>>>> >>> 881-4417 >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> -- >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> Sankhesh Jhaveri >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >> >> >> >>>>>>> >> 881-4417 >> >> >> >>>>>>> _______________________________________________ >> >> >> >>>>>>> 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: >> >> >> >>>>>>> http://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: >> >> >> >>>>> http://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: >> >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Ken Martin PhD >> >> > Distinguished Engineer >> >> > Kitware Inc. >> >> > 28 Corporate Drive >> >> > Clifton Park NY 12065 >> >> > >> >> > 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. >> > >> > >> > >> > >> > -- >> > Ken Martin PhD >> > Distinguished Engineer >> > Kitware Inc. >> > 28 Corporate Drive >> > Clifton Park NY 12065 >> > >> > 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. > > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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. From ken.martin at kitware.com Wed May 31 15:06:16 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 31 May 2017 15:06:16 -0400 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: Are you setting window->SetMultisamples(0) as well early on? On Wed, May 31, 2017 at 2:55 PM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-05-31 18:53 GMT+02:00 Ken Martin : > > If it is only VolumeRendering then it may be you are requesting > > Multisamples. What happens if you turn that off? > > Multisamples is turned off (see my test case in my initial mail): > > auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); > defaultFormat.setSamples(0); > QSurfaceFormat::setDefaultFormat(defaultFormat); > > It would be great if you could try the test case out on the 4600 > system where you said you had problems with PV 5.4. I think it would > help in narrowing down the issue. > > Make sure you run it with a parameter (e.g. "TestCase 1"), so that it > uses QVTKOpenGLWidget and not a plain render window/interactor. > > Elvis > > > > > On Wed, May 31, 2017 at 11:27 AM, Elvis Stansvik > > wrote: > >> > >> 2017-05-26 14:35 GMT+02:00 Ken Martin : > >> > If you have a build of QT I think you could change > >> > > >> > > >> > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/ > qwindowsglcontext.cpp#L730 > >> > > >> > const int requestedVersion = qMin((format.majorVersion() << 8) + > >> > format.minorVersion(), > >> > staticContext.defaultFormat.version); > >> > > >> > to be > >> > > >> > const int requestedVersion = (format.majorVersion() << 8) + > >> > format.minorVersion()); > >> > > >> > and it would fix it for VTK/ParaView. Not sure if it has any other > >> > consequences for Qt or if it would hit some different issue though. Qt > >> > on > >> > windows does some tricky stuff to support OpenGL/Angle/ES2. > >> > >> I patched Qt (5.6 branch) like this and tried again, but no luck :( > >> Volumes still not showing up.. > >> > >> ..and thinking about it, could this really have been the problem I was > >> seeing? If Qt wrongly gave back a lower-versioned context (because of > >> it's questionable logic), as described in the Qt bug report, then > >> wouldn't VTK error out from the failure to obtain the version it > >> requested? In my case, there's no output/error at all from VTK. It's > >> just that the volumes won't show up. > >> > >> Another render window where I just have a vtkChartXY does show up > >> fine. It's only the volume rendering that isn't working. > >> > >> Would be interesting if others who could reproduce could try patching > >> their Qt like this to see if it solves it. > >> > >> Elvis > >> > >> > > >> > > >> > > >> > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik > >> > wrote: > >> >> > >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin : > >> >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure > it > >> >> > is > >> >> > a > >> >> > Qt bug we already bumped into with Mesa. They have what looks to me > >> >> > like > >> >> > some odd bad logic on windows for creating a context where they > will > >> >> > not > >> >> > give you a core context later than the latest compatibility context > >> >> > they > >> >> > can > >> >> > get. For some vendors that is fine but for others they only offer > >> >> > Comp > >> >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may > >> >> > support > >> >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they > >> >> > fixed > >> >> > that the issue would go away. I believe Ben filed a bug report with > >> >> > them > >> >> > (Qt) when he bumped into this when using Mesa on Windows. > >> >> > >> >> Ah yes, that could definitely be it. I found Ben's bug: > >> >> > >> >> https://bugreports.qt.io/browse/QTBUG-60742 > >> >> > >> >> The affected version is listed as 5.8.0, but I'm having trouble on > >> >> 5.6.2, so I guess the bad logic is there as well. > >> >> > >> >> So let's hope for a fix in Qt then. But in the meantime, is there > >> >> anything you can think if that I could do to work around it? I really > >> >> want our application to work on these kinds of machines (the one I > >> >> have was picked as a sort of a baseline for us wrt to requirements). > >> >> > >> >> In the bug report Ben mentions hacking around it with > >> >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not > >> >> using Mesa. > >> >> > >> >> Elvis > >> >> > >> >> > > >> >> > > >> >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik > >> >> > wrote: > >> >> >> > >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole : > >> >> >> > Yes, I ran it both ways. > >> >> >> > > >> >> >> > It works when run without the argument in the plain VTK render > >> >> >> > window, > >> >> >> > and it is broken (shows nothing) when run with an argument. > >> >> >> > >> >> >> Alright, that's good. Then we're seeing the same thing. > >> >> >> > >> >> >> > Seems like it's definitely related to older Intel drivers on > >> >> >> > Windows. > >> >> >> > >> >> >> Yes, probably. > >> >> >> > >> >> >> > Not sure if there is an updated driver available for my machine. > >> >> >> > Hesitant to try changing/updating it for other reasons, and > sorry, > >> >> >> > can't sacrifice this machine's current state for the purpose of > >> >> >> > testing this out... > >> >> >> > >> >> >> No worries, I'm free to do as I please with the one I have, so > I'll > >> >> >> do > >> >> >> some experimenting with different drivers when I'm back on Monday. > >> >> >> > >> >> >> Thanks to everyone trying this out. > >> >> >> > >> >> >> Elvis > >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > D > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik > >> >> >> > wrote: > >> >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik > >> >> >> >> : > >> >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : > >> >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, Windows > >> >> >> >>>> 8.1, > >> >> >> >>>> with an Intel HD Graphics 4000 running driver version > >> >> >> >>>> 10.18.10.3316. > >> >> >> >>>> I > >> >> >> >>>> get your TestCase app window with nothing but an empty > (white) > >> >> >> >>>> client > >> >> >> >>>> region. > >> >> >> >>>> > >> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL > >> >> >> >>>> using > >> >> >> >>>> VolumeSmartMapper works fine on this very same machine. > >> >> >> >>>> > >> >> >> >>>> Another data point... > >> >> >> >> > >> >> >> >> Just one more thing David, did you try also running the example > >> >> >> >> without any argument on this machine? (That would make it use a > >> >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would > be > >> >> >> >> interesting to know if the volume shows up then. That would > >> >> >> >> confirm > >> >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, > >> >> >> >> just > >> >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that > it > >> >> >> >> has > >> >> >> >> something to do with the new QVTKOpenGLWidget. > >> >> >> >> > >> >> >> >> Elvis > >> >> >> >> > >> >> >> >>> > >> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks a > >> >> >> >>> lot > >> >> >> >>> David. > >> >> >> >>> > >> >> >> >>> And just to make sure, Aron, did you run the test case as > >> >> >> >>> "TestCase > >> >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise > >> >> >> >>> it'll > >> >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor > >> >> >> >>> (not > >> >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. > >> >> >> >>> > >> >> >> >>> Elvis > >> >> >> >>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> D > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik > >> >> >> >>>> wrote: > >> >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser > >> >> >> >>>>> : > >> >> >> >>>>>> Hi Elvis, > >> >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an > >> >> >> >>>>>> Optimus > >> >> >> >>>>>> setup - both > >> >> >> >>>>>> intel and nvidia graphics. > >> >> >> >>>>>> With your test case, I'm able to see the volume running > >> >> >> >>>>>> either > >> >> >> >>>>>> with > >> >> >> >>>>>> Intel or > >> >> >> >>>>>> nVidia, so it doesn't repro for me. > >> >> >> >>>>>> I've got Intel HD530 graphics, with driver version > >> >> >> >>>>>> 21.20.16.4627 > >> >> >> >>>>>> Sorry, > >> >> >> >>>>>> Aron > >> >> >> >>>>> > >> >> >> >>>>> Alright, bugger. Thanks for testing though! > >> >> >> >>>>> > >> >> >> >>>>> I won't be at the office until Monday again, but when I'm > back > >> >> >> >>>>> I'll > >> >> >> >>>>> try experimenting with different driver versions. > >> >> >> >>>>> > >> >> >> >>>>> Elvis > >> >> >> >>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik > >> >> >> >>>>>> wrote: > >> >> >> >>>>>>> > >> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik > >> >> >> >>>>>>> : > >> >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri > >> >> >> >>>>>>> > : > >> >> >> >>>>>>> >> Hi Elvis, > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. > :( > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics > >> >> >> >>>>>>> >> card > >> >> >> >>>>>>> >> but > >> >> >> >>>>>>> >> tried > >> >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as > a > >> >> >> >>>>>>> >> Mac > >> >> >> >>>>>>> >> (with an > >> >> >> >>>>>>> >> Intel > >> >> >> >>>>>>> >> HD5600). Worked fine. > >> >> >> >>>>>>> > > >> >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows > 7 > >> >> >> >>>>>>> > machine with > >> >> >> >>>>>>> > Intel graphics? Would be great if someone could > reproduce. > >> >> >> >>>>>>> > >> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce > >> >> >> >>>>>>> Sankhesh. > >> >> >> >>>>>>> > >> >> >> >>>>>>> I've now put up the compiled self-contained test case > here: > >> >> >> >>>>>>> > >> >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) > >> >> >> >>>>>>> > >> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) > + > >> >> >> >>>>>>> Intel > >> >> >> >>>>>>> graphics could try running this test case with "TestCase > 1" > >> >> >> >>>>>>> and > >> >> >> >>>>>>> see if > >> >> >> >>>>>>> the volume shows up, that would be great. > >> >> >> >>>>>>> > >> >> >> >>>>>>> (Running the test case with argc > 2 will make it use > >> >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). > >> >> >> >>>>>>> > >> >> >> >>>>>>> Elvis > >> >> >> >>>>>>> > >> >> >> >>>>>>> > > >> >> >> >>>>>>> > I could put up my build of the test case as a > >> >> >> >>>>>>> > self-contained > >> >> >> >>>>>>> > .zip, to > >> >> >> >>>>>>> > make it easy to test. > >> >> >> >>>>>>> > > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> At this point, I am inclined to think that the graphics > >> >> >> >>>>>>> >> drivers > >> >> >> >>>>>>> >> on your > >> >> >> >>>>>>> >> Windows machine may need updating. > >> >> >> >>>>>>> > > >> >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, > and > >> >> >> >>>>>>> > just > >> >> >> >>>>>>> > use a > >> >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. > >> >> >> >>>>>>> > Wouldn't > >> >> >> >>>>>>> > that > >> >> >> >>>>>>> > suggest that the drivers are capable enough, and that > the > >> >> >> >>>>>>> > problem is > >> >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? > >> >> >> >>>>>>> > > >> >> >> >>>>>>> > Elvis > >> >> >> >>>>>>> > > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri > >> >> >> >>>>>>> >> wrote: > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> Okay thanks. > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> I?ll take a look. > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik > >> >> >> >>>>>>> >>> wrote: > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri > >> >> >> >>>>>>> >>>> : > >> >> >> >>>>>>> >>>> > Hi Elvis, > >> >> >> >>>>>>> >>>> > > >> >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly > binary > >> >> >> >>>>>>> >>>> > and > >> >> >> >>>>>>> >>>> > test > >> >> >> >>>>>>> >>>> > volume > >> >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source > for a > >> >> >> >>>>>>> >>>> > test > >> >> >> >>>>>>> >>>> > dataset. > >> >> >> >>>>>>> >>>> > ParaView > >> >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good > test > >> >> >> >>>>>>> >>>> > before diving > >> >> >> >>>>>>> >>>> > into the > >> >> >> >>>>>>> >>>> > code. > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview > >> >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 > >> >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal > >> >> >> >>>>>>> >>>> test > >> >> >> >>>>>>> >>>> case. The > >> >> >> >>>>>>> >>>> volume won't show up. > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> It does show up if I switch to the software based ray > >> >> >> >>>>>>> >>>> cast > >> >> >> >>>>>>> >>>> mapper > >> >> >> >>>>>>> >>>> (but > >> >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in > the > >> >> >> >>>>>>> >>>> GPU > >> >> >> >>>>>>> >>>> one being > >> >> >> >>>>>>> >>>> used). > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to > >> >> >> >>>>>>> >>>> help > >> >> >> >>>>>>> >>>> debugging. > >> >> >> >>>>>>> >>>> There are no errors printed when I run my test case. > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> Elvis > >> >> >> >>>>>>> >>>> > >> >> >> >>>>>>> >>>> > > >> >> >> >>>>>>> >>>> > Thanks, > >> >> >> >>>>>>> >>>> > Sankhesh > >> >> >> >>>>>>> >>>> > > >> >> >> >>>>>>> >>>> > > >> >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik > >> >> >> >>>>>>> >>>> > wrote: > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Hi all, > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get > volumes > >> >> >> >>>>>>> >>>> >> rendered using > >> >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows 7, > >> >> >> >>>>>>> >>>> >> Intel > >> >> >> >>>>>>> >>>> >> graphics > >> >> >> >>>>>>> >>>> >> (HD > >> >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show > up > >> >> >> >>>>>>> >>>> >> fine > >> >> >> >>>>>>> >>>> >> on > >> >> >> >>>>>>> >>>> >> Windows 7 > >> >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried > >> >> >> >>>>>>> >>>> >> turning > >> >> >> >>>>>>> >>>> >> off > >> >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default > >> >> >> >>>>>>> >>>> >> QSurfaceFormat. > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See the > >> >> >> >>>>>>> >>>> >> attached > >> >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and > >> >> >> >>>>>>> >>>> >> "TestCase > >> >> >> >>>>>>> >>>> >> 1" > >> >> >> >>>>>>> >>>> >> (right). > >> >> >> >>>>>>> >>>> >> The former uses a plain render window while the > >> >> >> >>>>>>> >>>> >> latter > >> >> >> >>>>>>> >>>> >> uses the > >> >> >> >>>>>>> >>>> >> new > >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 > >> >> >> >>>>>>> >>>> >> screenshot, > >> >> >> >>>>>>> >>>> >> the > >> >> >> >>>>>>> >>>> >> plain > >> >> >> >>>>>>> >>>> >> VTK rendering works fine, but the QVTKOpenGLWidget > >> >> >> >>>>>>> >>>> >> one > >> >> >> >>>>>>> >>>> >> is > >> >> >> >>>>>>> >>>> >> not > >> >> >> >>>>>>> >>>> >> showing > >> >> >> >>>>>>> >>>> >> the volume. > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Versions used: > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 > >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >> >> >> >>>>>>> >>>> >> Qt 5.5.1 > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Windows 7 > >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 > >> >> >> >>>>>>> >>>> >> Qt 5.6.2 > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of my > >> >> >> >>>>>>> >>>> >> build > >> >> >> >>>>>>> >>>> >> of the > >> >> >> >>>>>>> >>>> >> test > >> >> >> >>>>>>> >>>> >> case if you want. > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha > >> >> >> >>>>>>> >>>> >> issue I > >> >> >> >>>>>>> >>>> >> reported > >> >> >> >>>>>>> >>>> >> and > >> >> >> >>>>>>> >>>> >> got solved in my other thread. > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> Many thanks in advance, > >> >> >> >>>>>>> >>>> >> Elvis > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> main.cpp: > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> #include > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) > >> >> >> >>>>>>> >>>> >> { > >> >> >> >>>>>>> >>>> >> auto defaultFormat = > >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); > >> >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); > >> >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat( > defaultFormat); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> // Set up volume rendering > >> >> >> >>>>>>> >>>> >> vtkNew > colorFunction; > >> >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, > 0.0); > >> >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, > 0.0); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; > >> >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); > >> >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew imageData; > >> >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); > >> >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); > >> >> >> >>>>>>> >>>> >> std::fill_n(static_cast >> >> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), > >> >> >> >>>>>>> >>>> >> 8000000, 0.01); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew > volumeMapper; > >> >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity( > opacityFunction.Get()); > >> >> >> >>>>>>> >>>> >> volumeProperty->SetColor( > colorFunction.Get()); > >> >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew volume; > >> >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); > >> >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew renderer; > >> >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); > >> >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> if (argc > 1) { > >> >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget > >> >> >> >>>>>>> >>>> >> vtkNew > window; > >> >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); > >> >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); > >> >> >> >>>>>>> >>>> >> widget->show(); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> return app.exec(); > >> >> >> >>>>>>> >>>> >> } else { > >> >> >> >>>>>>> >>>> >> // Render with "plain" render window / > >> >> >> >>>>>>> >>>> >> interactor > >> >> >> >>>>>>> >>>> >> vtkNew window; > >> >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> vtkNew > >> >> >> >>>>>>> >>>> >> interactor; > >> >> >> >>>>>>> >>>> >> interactor->SetRenderWindow( > window.Get()); > >> >> >> >>>>>>> >>>> >> interactor->Start(); > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> return 0; > >> >> >> >>>>>>> >>>> >> } > >> >> >> >>>>>>> >>>> >> } > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> CMakeLists.txt: > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> project(TestCase) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS > >> >> >> >>>>>>> >>>> >> vtkCommonCore > >> >> >> >>>>>>> >>>> >> vtkCommonDataModel > >> >> >> >>>>>>> >>>> >> vtkCommonExecutionModel > >> >> >> >>>>>>> >>>> >> vtkCommonMath > >> >> >> >>>>>>> >>>> >> vtkFiltersSources > >> >> >> >>>>>>> >>>> >> vtkGUISupportQt > >> >> >> >>>>>>> >>>> >> vtkInteractionStyle > >> >> >> >>>>>>> >>>> >> vtkRenderingCore > >> >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 > >> >> >> >>>>>>> >>>> >> vtkRenderingVolume > >> >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >> >> >> >>>>>>> >>>> >> REQUIRED > >> >> >> >>>>>>> >>>> >> ) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC > >> >> >> >>>>>>> >>>> >> vtkCommonCore > >> >> >> >>>>>>> >>>> >> vtkCommonDataModel > >> >> >> >>>>>>> >>>> >> vtkCommonExecutionModel > >> >> >> >>>>>>> >>>> >> vtkCommonMath > >> >> >> >>>>>>> >>>> >> vtkFiltersSources > >> >> >> >>>>>>> >>>> >> vtkGUISupportQt > >> >> >> >>>>>>> >>>> >> vtkInteractionStyle > >> >> >> >>>>>>> >>>> >> vtkRenderingCore > >> >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 > >> >> >> >>>>>>> >>>> >> vtkRenderingVolume > >> >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 > >> >> >> >>>>>>> >>>> >> Qt5::Widgets > >> >> >> >>>>>>> >>>> >> ) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC > >> >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} > >> >> >> >>>>>>> >>>> >> ) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC > >> >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} > >> >> >> >>>>>>> >>>> >> ) > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES > >> >> >> >>>>>>> >>>> >> CXX_STANDARD 14 > >> >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON > >> >> >> >>>>>>> >>>> >> ) > >> >> >> >>>>>>> >>>> >> _______________________________________________ > >> >> >> >>>>>>> >>>> >> 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: > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk- > developers > >> >> >> >>>>>>> >>>> >> > >> >> >> >>>>>>> >>>> > -- > >> >> >> >>>>>>> >>>> > > >> >> >> >>>>>>> >>>> > Sankhesh Jhaveri > >> >> >> >>>>>>> >>>> > > >> >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | > (518) > >> >> >> >>>>>>> >>>> > 881-4417 > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> -- > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> Sankhesh Jhaveri > >> >> >> >>>>>>> >>> > >> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) > >> >> >> >>>>>>> >>> 881-4417 > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> -- > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> Sankhesh Jhaveri > >> >> >> >>>>>>> >> > >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) > >> >> >> >>>>>>> >> 881-4417 > >> >> >> >>>>>>> _______________________________________________ > >> >> >> >>>>>>> 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: > >> >> >> >>>>>>> http://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: > >> >> >> >>>>> http://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: > >> >> >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Ken Martin PhD > >> >> > Distinguished Engineer > >> >> > Kitware Inc. > >> >> > 28 Corporate Drive > >> >> > Clifton Park NY 12065 > >> >> > > >> >> > 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. > >> > > >> > > >> > > >> > > >> > -- > >> > Ken Martin PhD > >> > Distinguished Engineer > >> > Kitware Inc. > >> > 28 Corporate Drive > >> > Clifton Park NY 12065 > >> > > >> > 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. > > > > > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > > > 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. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 elvis.stansvik at orexplore.com Wed May 31 15:18:04 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 31 May 2017 21:18:04 +0200 Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with QVTKOpenGLWidget in 8.0.0.rc1 In-Reply-To: References: Message-ID: 2017-05-31 21:06 GMT+02:00 Ken Martin : > Are you setting window->SetMultisamples(0) as well early on? Hm, that I am not. I'll give that a try when I'm back at the office tomorrow. Elvis > > On Wed, May 31, 2017 at 2:55 PM, Elvis Stansvik > wrote: >> >> 2017-05-31 18:53 GMT+02:00 Ken Martin : >> > If it is only VolumeRendering then it may be you are requesting >> > Multisamples. What happens if you turn that off? >> >> Multisamples is turned off (see my test case in my initial mail): >> >> auto defaultFormat = QVTKOpenGLWidget::defaultFormat(); >> defaultFormat.setSamples(0); >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> It would be great if you could try the test case out on the 4600 >> system where you said you had problems with PV 5.4. I think it would >> help in narrowing down the issue. >> >> Make sure you run it with a parameter (e.g. "TestCase 1"), so that it >> uses QVTKOpenGLWidget and not a plain render window/interactor. >> >> Elvis >> >> > >> > On Wed, May 31, 2017 at 11:27 AM, Elvis Stansvik >> > wrote: >> >> >> >> 2017-05-26 14:35 GMT+02:00 Ken Martin : >> >> > If you have a build of QT I think you could change >> >> > >> >> > >> >> > >> >> > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730 >> >> > >> >> > const int requestedVersion = qMin((format.majorVersion() << 8) + >> >> > format.minorVersion(), >> >> > staticContext.defaultFormat.version); >> >> > >> >> > to be >> >> > >> >> > const int requestedVersion = (format.majorVersion() << 8) + >> >> > format.minorVersion()); >> >> > >> >> > and it would fix it for VTK/ParaView. Not sure if it has any other >> >> > consequences for Qt or if it would hit some different issue though. >> >> > Qt >> >> > on >> >> > windows does some tricky stuff to support OpenGL/Angle/ES2. >> >> >> >> I patched Qt (5.6 branch) like this and tried again, but no luck :( >> >> Volumes still not showing up.. >> >> >> >> ..and thinking about it, could this really have been the problem I was >> >> seeing? If Qt wrongly gave back a lower-versioned context (because of >> >> it's questionable logic), as described in the Qt bug report, then >> >> wouldn't VTK error out from the failure to obtain the version it >> >> requested? In my case, there's no output/error at all from VTK. It's >> >> just that the volumes won't show up. >> >> >> >> Another render window where I just have a vtkChartXY does show up >> >> fine. It's only the volume rendering that isn't working. >> >> >> >> Would be interesting if others who could reproduce could try patching >> >> their Qt like this to see if it solves it. >> >> >> >> Elvis >> >> >> >> > >> >> > >> >> > >> >> > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik >> >> > wrote: >> >> >> >> >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin : >> >> >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure >> >> >> > it >> >> >> > is >> >> >> > a >> >> >> > Qt bug we already bumped into with Mesa. They have what looks to >> >> >> > me >> >> >> > like >> >> >> > some odd bad logic on windows for creating a context where they >> >> >> > will >> >> >> > not >> >> >> > give you a core context later than the latest compatibility >> >> >> > context >> >> >> > they >> >> >> > can >> >> >> > get. For some vendors that is fine but for others they only offer >> >> >> > Comp >> >> >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may >> >> >> > support >> >> >> > OpenGL 4 in Core mode, Qt restricts you to 3.0. I suspect if they >> >> >> > fixed >> >> >> > that the issue would go away. I believe Ben filed a bug report >> >> >> > with >> >> >> > them >> >> >> > (Qt) when he bumped into this when using Mesa on Windows. >> >> >> >> >> >> Ah yes, that could definitely be it. I found Ben's bug: >> >> >> >> >> >> https://bugreports.qt.io/browse/QTBUG-60742 >> >> >> >> >> >> The affected version is listed as 5.8.0, but I'm having trouble on >> >> >> 5.6.2, so I guess the bad logic is there as well. >> >> >> >> >> >> So let's hope for a fix in Qt then. But in the meantime, is there >> >> >> anything you can think if that I could do to work around it? I >> >> >> really >> >> >> want our application to work on these kinds of machines (the one I >> >> >> have was picked as a sort of a baseline for us wrt to requirements). >> >> >> >> >> >> In the bug report Ben mentions hacking around it with >> >> >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not >> >> >> using Mesa. >> >> >> >> >> >> Elvis >> >> >> >> >> >> > >> >> >> > >> >> >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik >> >> >> > wrote: >> >> >> >> >> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole : >> >> >> >> > Yes, I ran it both ways. >> >> >> >> > >> >> >> >> > It works when run without the argument in the plain VTK render >> >> >> >> > window, >> >> >> >> > and it is broken (shows nothing) when run with an argument. >> >> >> >> >> >> >> >> Alright, that's good. Then we're seeing the same thing. >> >> >> >> >> >> >> >> > Seems like it's definitely related to older Intel drivers on >> >> >> >> > Windows. >> >> >> >> >> >> >> >> Yes, probably. >> >> >> >> >> >> >> >> > Not sure if there is an updated driver available for my >> >> >> >> > machine. >> >> >> >> > Hesitant to try changing/updating it for other reasons, and >> >> >> >> > sorry, >> >> >> >> > can't sacrifice this machine's current state for the purpose of >> >> >> >> > testing this out... >> >> >> >> >> >> >> >> No worries, I'm free to do as I please with the one I have, so >> >> >> >> I'll >> >> >> >> do >> >> >> >> some experimenting with different drivers when I'm back on >> >> >> >> Monday. >> >> >> >> >> >> >> >> Thanks to everyone trying this out. >> >> >> >> >> >> >> >> Elvis >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > D >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik >> >> >> >> > wrote: >> >> >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik >> >> >> >> >> : >> >> >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole : >> >> >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop, >> >> >> >> >>>> Windows >> >> >> >> >>>> 8.1, >> >> >> >> >>>> with an Intel HD Graphics 4000 running driver version >> >> >> >> >>>> 10.18.10.3316. >> >> >> >> >>>> I >> >> >> >> >>>> get your TestCase app window with nothing but an empty >> >> >> >> >>>> (white) >> >> >> >> >>>> client >> >> >> >> >>>> region. >> >> >> >> >>>> >> >> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL >> >> >> >> >>>> using >> >> >> >> >>>> VolumeSmartMapper works fine on this very same machine. >> >> >> >> >>>> >> >> >> >> >>>> Another data point... >> >> >> >> >> >> >> >> >> >> Just one more thing David, did you try also running the >> >> >> >> >> example >> >> >> >> >> without any argument on this machine? (That would make it use >> >> >> >> >> a >> >> >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would >> >> >> >> >> be >> >> >> >> >> interesting to know if the volume shows up then. That would >> >> >> >> >> confirm >> >> >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend, >> >> >> >> >> just >> >> >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that >> >> >> >> >> it >> >> >> >> >> has >> >> >> >> >> something to do with the new QVTKOpenGLWidget. >> >> >> >> >> >> >> >> >> >> Elvis >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks >> >> >> >> >>> a >> >> >> >> >>> lot >> >> >> >> >>> David. >> >> >> >> >>> >> >> >> >> >>> And just to make sure, Aron, did you run the test case as >> >> >> >> >>> "TestCase >> >> >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise >> >> >> >> >>> it'll >> >> >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor >> >> >> >> >>> (not >> >> >> >> >>> QVTKOpenGLWidget), and not exhibit the problem. >> >> >> >> >>> >> >> >> >> >>> Elvis >> >> >> >> >>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> D >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik >> >> >> >> >>>> wrote: >> >> >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser >> >> >> >> >>>>> : >> >> >> >> >>>>>> Hi Elvis, >> >> >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an >> >> >> >> >>>>>> Optimus >> >> >> >> >>>>>> setup - both >> >> >> >> >>>>>> intel and nvidia graphics. >> >> >> >> >>>>>> With your test case, I'm able to see the volume running >> >> >> >> >>>>>> either >> >> >> >> >>>>>> with >> >> >> >> >>>>>> Intel or >> >> >> >> >>>>>> nVidia, so it doesn't repro for me. >> >> >> >> >>>>>> I've got Intel HD530 graphics, with driver version >> >> >> >> >>>>>> 21.20.16.4627 >> >> >> >> >>>>>> Sorry, >> >> >> >> >>>>>> Aron >> >> >> >> >>>>> >> >> >> >> >>>>> Alright, bugger. Thanks for testing though! >> >> >> >> >>>>> >> >> >> >> >>>>> I won't be at the office until Monday again, but when I'm >> >> >> >> >>>>> back >> >> >> >> >>>>> I'll >> >> >> >> >>>>> try experimenting with different driver versions. >> >> >> >> >>>>> >> >> >> >> >>>>> Elvis >> >> >> >> >>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik >> >> >> >> >>>>>> wrote: >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik >> >> >> >> >>>>>>> : >> >> >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri >> >> >> >> >>>>>>> > : >> >> >> >> >>>>>>> >> Hi Elvis, >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue. >> >> >> >> >>>>>>> >> :( >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics >> >> >> >> >>>>>>> >> card >> >> >> >> >>>>>>> >> but >> >> >> >> >>>>>>> >> tried >> >> >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as >> >> >> >> >>>>>>> >> a >> >> >> >> >>>>>>> >> Mac >> >> >> >> >>>>>>> >> (with an >> >> >> >> >>>>>>> >> Intel >> >> >> >> >>>>>>> >> HD5600). Worked fine. >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows >> >> >> >> >>>>>>> > 7 >> >> >> >> >>>>>>> > machine with >> >> >> >> >>>>>>> > Intel graphics? Would be great if someone could >> >> >> >> >>>>>>> > reproduce. >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce >> >> >> >> >>>>>>> Sankhesh. >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> I've now put up the compiled self-contained test case >> >> >> >> >>>>>>> here: >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> http://dose.se/~estan/voltestcase-inst.zip (18 MB) >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible) >> >> >> >> >>>>>>> + >> >> >> >> >>>>>>> Intel >> >> >> >> >>>>>>> graphics could try running this test case with "TestCase >> >> >> >> >>>>>>> 1" >> >> >> >> >>>>>>> and >> >> >> >> >>>>>>> see if >> >> >> >> >>>>>>> the volume shows up, that would be great. >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> (Running the test case with argc > 2 will make it use >> >> >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble). >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Elvis >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> > I could put up my build of the test case as a >> >> >> >> >>>>>>> > self-contained >> >> >> >> >>>>>>> > .zip, to >> >> >> >> >>>>>>> > make it easy to test. >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> At this point, I am inclined to think that the >> >> >> >> >>>>>>> >> graphics >> >> >> >> >>>>>>> >> drivers >> >> >> >> >>>>>>> >> on your >> >> >> >> >>>>>>> >> Windows machine may need updating. >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget, >> >> >> >> >>>>>>> > and >> >> >> >> >>>>>>> > just >> >> >> >> >>>>>>> > use a >> >> >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor. >> >> >> >> >>>>>>> > Wouldn't >> >> >> >> >>>>>>> > that >> >> >> >> >>>>>>> > suggest that the drivers are capable enough, and that >> >> >> >> >>>>>>> > the >> >> >> >> >>>>>>> > problem is >> >> >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)? >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> > Elvis >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri >> >> >> >> >>>>>>> >> wrote: >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> Okay thanks. >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> I?ll take a look. >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik >> >> >> >> >>>>>>> >>> wrote: >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri >> >> >> >> >>>>>>> >>>> : >> >> >> >> >>>>>>> >>>> > Hi Elvis, >> >> >> >> >>>>>>> >>>> > >> >> >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly >> >> >> >> >>>>>>> >>>> > binary >> >> >> >> >>>>>>> >>>> > and >> >> >> >> >>>>>>> >>>> > test >> >> >> >> >>>>>>> >>>> > volume >> >> >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source >> >> >> >> >>>>>>> >>>> > for a >> >> >> >> >>>>>>> >>>> > test >> >> >> >> >>>>>>> >>>> > dataset. >> >> >> >> >>>>>>> >>>> > ParaView >> >> >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good >> >> >> >> >>>>>>> >>>> > test >> >> >> >> >>>>>>> >>>> > before diving >> >> >> >> >>>>>>> >>>> > into the >> >> >> >> >>>>>>> >>>> > code. >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview >> >> >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603 >> >> >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal >> >> >> >> >>>>>>> >>>> test >> >> >> >> >>>>>>> >>>> case. The >> >> >> >> >>>>>>> >>>> volume won't show up. >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> It does show up if I switch to the software based >> >> >> >> >>>>>>> >>>> ray >> >> >> >> >>>>>>> >>>> cast >> >> >> >> >>>>>>> >>>> mapper >> >> >> >> >>>>>>> >>>> (but >> >> >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in >> >> >> >> >>>>>>> >>>> the >> >> >> >> >>>>>>> >>>> GPU >> >> >> >> >>>>>>> >>>> one being >> >> >> >> >>>>>>> >>>> used). >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to >> >> >> >> >>>>>>> >>>> help >> >> >> >> >>>>>>> >>>> debugging. >> >> >> >> >>>>>>> >>>> There are no errors printed when I run my test case. >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> Elvis >> >> >> >> >>>>>>> >>>> >> >> >> >> >>>>>>> >>>> > >> >> >> >> >>>>>>> >>>> > Thanks, >> >> >> >> >>>>>>> >>>> > Sankhesh >> >> >> >> >>>>>>> >>>> > >> >> >> >> >>>>>>> >>>> > >> >> >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik >> >> >> >> >>>>>>> >>>> > wrote: >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Hi all, >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get >> >> >> >> >>>>>>> >>>> >> volumes >> >> >> >> >>>>>>> >>>> >> rendered using >> >> >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows >> >> >> >> >>>>>>> >>>> >> 7, >> >> >> >> >>>>>>> >>>> >> Intel >> >> >> >> >>>>>>> >>>> >> graphics >> >> >> >> >>>>>>> >>>> >> (HD >> >> >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show >> >> >> >> >>>>>>> >>>> >> up >> >> >> >> >>>>>>> >>>> >> fine >> >> >> >> >>>>>>> >>>> >> on >> >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried >> >> >> >> >>>>>>> >>>> >> turning >> >> >> >> >>>>>>> >>>> >> off >> >> >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default >> >> >> >> >>>>>>> >>>> >> QSurfaceFormat. >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See >> >> >> >> >>>>>>> >>>> >> the >> >> >> >> >>>>>>> >>>> >> attached >> >> >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and >> >> >> >> >>>>>>> >>>> >> "TestCase >> >> >> >> >>>>>>> >>>> >> 1" >> >> >> >> >>>>>>> >>>> >> (right). >> >> >> >> >>>>>>> >>>> >> The former uses a plain render window while the >> >> >> >> >>>>>>> >>>> >> latter >> >> >> >> >>>>>>> >>>> >> uses the >> >> >> >> >>>>>>> >>>> >> new >> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7 >> >> >> >> >>>>>>> >>>> >> screenshot, >> >> >> >> >>>>>>> >>>> >> the >> >> >> >> >>>>>>> >>>> >> plain >> >> >> >> >>>>>>> >>>> >> VTK rendering works fine, but the >> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget >> >> >> >> >>>>>>> >>>> >> one >> >> >> >> >>>>>>> >>>> >> is >> >> >> >> >>>>>>> >>>> >> not >> >> >> >> >>>>>>> >>>> >> showing >> >> >> >> >>>>>>> >>>> >> the volume. >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Versions used: >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04 >> >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >> >> >>>>>>> >>>> >> Qt 5.5.1 >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Windows 7 >> >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2 >> >> >> >> >>>>>>> >>>> >> Qt 5.6.2 >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be? >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of >> >> >> >> >>>>>>> >>>> >> my >> >> >> >> >>>>>>> >>>> >> build >> >> >> >> >>>>>>> >>>> >> of the >> >> >> >> >>>>>>> >>>> >> test >> >> >> >> >>>>>>> >>>> >> case if you want. >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha >> >> >> >> >>>>>>> >>>> >> issue I >> >> >> >> >>>>>>> >>>> >> reported >> >> >> >> >>>>>>> >>>> >> and >> >> >> >> >>>>>>> >>>> >> got solved in my other thread. >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> Many thanks in advance, >> >> >> >> >>>>>>> >>>> >> Elvis >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> main.cpp: >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> #include >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[]) >> >> >> >> >>>>>>> >>>> >> { >> >> >> >> >>>>>>> >>>> >> auto defaultFormat = >> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat(); >> >> >> >> >>>>>>> >>>> >> defaultFormat.setSamples(0); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> QApplication app(argc, argv); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> // Set up volume rendering >> >> >> >> >>>>>>> >>>> >> vtkNew >> >> >> >> >>>>>>> >>>> >> colorFunction; >> >> >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(0.0, 0.0, 0.0, >> >> >> >> >>>>>>> >>>> >> 0.0); >> >> >> >> >>>>>>> >>>> >> colorFunction->AddRGBPoint(1.0, 0.0, 0.0, >> >> >> >> >>>>>>> >>>> >> 0.0); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew opacityFunction; >> >> >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(0.0, 0.0); >> >> >> >> >>>>>>> >>>> >> opacityFunction->AddPoint(1.0, 1.0); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew imageData; >> >> >> >> >>>>>>> >>>> >> imageData->SetExtent(0, 200, 0, 200, 0, 200); >> >> >> >> >>>>>>> >>>> >> imageData->AllocateScalars(VTK_FLOAT, 1); >> >> >> >> >>>>>>> >>>> >> std::fill_n(static_cast> >> >> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()), >> >> >> >> >>>>>>> >>>> >> 8000000, 0.01); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew >> >> >> >> >>>>>>> >>>> >> volumeMapper; >> >> >> >> >>>>>>> >>>> >> volumeMapper->SetInputData(imageData.Get()); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew volumeProperty; >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get()); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get()); >> >> >> >> >>>>>>> >>>> >> volumeProperty->ShadeOff(); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew volume; >> >> >> >> >>>>>>> >>>> >> volume->SetMapper(volumeMapper.Get()); >> >> >> >> >>>>>>> >>>> >> volume->SetProperty(volumeProperty.Get()); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew renderer; >> >> >> >> >>>>>>> >>>> >> renderer->AddVolume(volume.Get()); >> >> >> >> >>>>>>> >>>> >> renderer->SetBackground(1.0, 1.0, 1.0); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> if (argc > 1) { >> >> >> >> >>>>>>> >>>> >> // Render with QVTKOpenGLWidget >> >> >> >> >>>>>>> >>>> >> vtkNew >> >> >> >> >>>>>>> >>>> >> window; >> >> >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> auto widget = new QVTKOpenGLWidget(); >> >> >> >> >>>>>>> >>>> >> widget->SetRenderWindow(window.Get()); >> >> >> >> >>>>>>> >>>> >> widget->show(); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> return app.exec(); >> >> >> >> >>>>>>> >>>> >> } else { >> >> >> >> >>>>>>> >>>> >> // Render with "plain" render window / >> >> >> >> >>>>>>> >>>> >> interactor >> >> >> >> >>>>>>> >>>> >> vtkNew window; >> >> >> >> >>>>>>> >>>> >> window->AddRenderer(renderer.Get()); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> vtkNew >> >> >> >> >>>>>>> >>>> >> interactor; >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get()); >> >> >> >> >>>>>>> >>>> >> interactor->Start(); >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> return 0; >> >> >> >> >>>>>>> >>>> >> } >> >> >> >> >>>>>>> >>>> >> } >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> CMakeLists.txt: >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> project(TestCase) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS >> >> >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >> >> >>>>>>> >>>> >> REQUIRED >> >> >> >> >>>>>>> >>>> >> ) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC >> >> >> >> >>>>>>> >>>> >> vtkCommonCore >> >> >> >> >>>>>>> >>>> >> vtkCommonDataModel >> >> >> >> >>>>>>> >>>> >> vtkCommonExecutionModel >> >> >> >> >>>>>>> >>>> >> vtkCommonMath >> >> >> >> >>>>>>> >>>> >> vtkFiltersSources >> >> >> >> >>>>>>> >>>> >> vtkGUISupportQt >> >> >> >> >>>>>>> >>>> >> vtkInteractionStyle >> >> >> >> >>>>>>> >>>> >> vtkRenderingCore >> >> >> >> >>>>>>> >>>> >> vtkRenderingOpenGL2 >> >> >> >> >>>>>>> >>>> >> vtkRenderingVolume >> >> >> >> >>>>>>> >>>> >> vtkRenderingVolumeOpenGL2 >> >> >> >> >>>>>>> >>>> >> Qt5::Widgets >> >> >> >> >>>>>>> >>>> >> ) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC >> >> >> >> >>>>>>> >>>> >> ${VTK_INCLUDE_DIRS} >> >> >> >> >>>>>>> >>>> >> ) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC >> >> >> >> >>>>>>> >>>> >> ${VTK_DEFINITIONS} >> >> >> >> >>>>>>> >>>> >> ) >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES >> >> >> >> >>>>>>> >>>> >> CXX_STANDARD 14 >> >> >> >> >>>>>>> >>>> >> CXX_STANDARD_REQUIRED ON >> >> >> >> >>>>>>> >>>> >> ) >> >> >> >> >>>>>>> >>>> >> _______________________________________________ >> >> >> >> >>>>>>> >>>> >> 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: >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >>>>>>> >>>> >> >> >> >> >> >>>>>>> >>>> > -- >> >> >> >> >>>>>>> >>>> > >> >> >> >> >>>>>>> >>>> > Sankhesh Jhaveri >> >> >> >> >>>>>>> >>>> > >> >> >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware | >> >> >> >> >>>>>>> >>>> > (518) >> >> >> >> >>>>>>> >>>> > 881-4417 >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> -- >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> Sankhesh Jhaveri >> >> >> >> >>>>>>> >>> >> >> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518) >> >> >> >> >>>>>>> >>> 881-4417 >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> -- >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> Sankhesh Jhaveri >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518) >> >> >> >> >>>>>>> >> 881-4417 >> >> >> >> >>>>>>> _______________________________________________ >> >> >> >> >>>>>>> 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: >> >> >> >> >>>>>>> http://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: >> >> >> >> >>>>> http://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: >> >> >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Ken Martin PhD >> >> >> > Distinguished Engineer >> >> >> > Kitware Inc. >> >> >> > 28 Corporate Drive >> >> >> > Clifton Park NY 12065 >> >> >> > >> >> >> > 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. >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Ken Martin PhD >> >> > Distinguished Engineer >> >> > Kitware Inc. >> >> > 28 Corporate Drive >> >> > Clifton Park NY 12065 >> >> > >> >> > 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. >> > >> > >> > >> > >> > -- >> > Ken Martin PhD >> > Distinguished Engineer >> > Kitware Inc. >> > 28 Corporate Drive >> > Clifton Park NY 12065 >> > >> > 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. > > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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.