From aashish.chaudhary at kitware.com Mon Nov 2 08:02:32 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 2 Nov 2015 08:02:32 -0500 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: Hi Simon, I found the reason behind the appeared performance you were getting. We have this code in volume rendering that when you interact changes the sampling distance and in the newer code we were too conservative compare to the last version. That's why you were getting better quality when you move your mouse but lower frame rates. I pushed a branch in VTK to address the issue. Would it be possible for you to build Paraview with VTK master? It may take 3-4 days or longer for Paraview's VTK to get updated. Thanks, Aashish On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Hi Simon, > > I am just finishing up a ParaView5 related parallel volume rendering bug > (pushing a branch today to VTK). This is next on my list. > > - Aashish > > On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT > wrote: > >> Hello Aashish >> >> Did you get a chance to try to load the dataset on Windows ? >> Can I do anything to help you investigate ? Should I feel a bug, that may >> act as a reminder ? >> Have a nice day >> Simon >> >> >> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> Thanks Simon. This is really strange since we are not seeing it on Mac >>> and Linux (but both has dedicated cards). >>> >>> I will look into it soon. >>> >>> - aashish >>> >>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Ok, thank you very much fort digging into this. >>>> I've done some test and I believe I can see a similar slowdown >>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>> graphics. >>>> Good luck in the investigation, I you need more details, do not >>>> hesitate to ask >>>> Simon >>>> >>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> Ah, thanks. I will get back to you on this since on Linux I don't any >>>>> issue so it has to be Windows specific thing. >>>>> >>>>> - Aashish >>>>> >>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> I tried with that one from yesterday and today's version >>>>>> (4.4.0-209-gc399648) >>>>>> >>>>>> Thanks, >>>>>> Simon >>>>>> >>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> And when did you download this version? ParaView-latest-Qt4-OpenGL2- >>>>>>> Windows-64bit.exe >>>>>>> >>>>>>> Thanks, >>>>>>> Aashish >>>>>>> >>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> Yes, I tried with and without the shading. Without shading enabled, >>>>>>>> the new Opengl2 is also slower when zoomed in (in the described condition). >>>>>>>> With shading enabled, the difference in speed between the two version seems >>>>>>>> even bigger. >>>>>>>> I got the version from the nightly build download section of >>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>> results. >>>>>>>> >>>>>>>> About the FPS, it is difficult to give an exact number, because it >>>>>>>> depends of the condition (zoomed or not etc...) but yes, this is the idea. >>>>>>>> In our software, I've exposed the frame rate using this example : >>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>> example), with the same mapper parameters >>>>>>>> >>>>>>>> Thanks >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>> >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>> >>>>>>>>> 1) Did you try without the shading and see how the performance >>>>>>>>> compares? >>>>>>>>> >>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this one >>>>>>>>> from (ParaView download page or did you built yourself?) >>>>>>>>> >>>>>>>>> Also, so on your system the old mapper is running 30FPS and the >>>>>>>>> new one at 15-20 FPS as per your summary. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> - Aashish >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello Aashish, >>>>>>>>>> >>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>> I agree the performance is still quite good with the new backend, >>>>>>>>>> and I also get something like 15/20 fps on windows on an HD screen. But >>>>>>>>>> when compared to the old one, and in some condition (when zoomed >>>>>>>>>> especially), it looks really slower to me >>>>>>>>>> The two tested version are : >>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 backend. >>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and Nvidia >>>>>>>>>> Quadro K420 >>>>>>>>>> >>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>> - Load the above dataset on each >>>>>>>>>> - Select volume rendering >>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>> - Set the view direction to +Y >>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>> >>>>>>>>>> And start interacting ... >>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate in >>>>>>>>>> Paraview, but the new version seems really twice slower in these >>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>> interactivity is better. >>>>>>>>>> Shading enable or not does not change much >>>>>>>>>> >>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play with >>>>>>>>>> this with the old backend to fine tune the interactivity, although what's >>>>>>>>>> really inside was never clear to me >>>>>>>>>> >>>>>>>>>> I hope that there is enough information for you to reproduce >>>>>>>>>> this, do not hesitate to ask for some more information. >>>>>>>>>> >>>>>>>>>> Thanks a lot for your help >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>> >>>>>>>>>>> Dear Simon, >>>>>>>>>>> >>>>>>>>>>> Checking again. Wondering if you can provide some more detail on >>>>>>>>>>> the binary you are using and whether or not without shading the rendering >>>>>>>>>>> performance comparable to older version. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Simon, >>>>>>>>>>>> >>>>>>>>>>>> I used your dataset on paraview master as of today on my Linux >>>>>>>>>>>> box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about 15-20 >>>>>>>>>>>> FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>> >>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>> >>>>>>>>>>>> NOTE: You might get multiple emails because of the attachment >>>>>>>>>>>> size issue. Sorry about that. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short element >>>>>>>>>>>>>> (you can find the dataset here : >>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). So I >>>>>>>>>>>>>> think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>> The new mapper does bring low resolution, but when compared >>>>>>>>>>>>>> to the old one, it seems less "low resolution" during interaction than the >>>>>>>>>>>>>> old one >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Right, so that's why its not a exact comparison. What happens >>>>>>>>>>>>> is that depending on what is interactive, (you can set the desired update >>>>>>>>>>>>> rate in VTK, not exposed in ParaView I believe), it will do interactive >>>>>>>>>>>>> but with higher resolution (smaller sample distance). If they both have >>>>>>>>>>>>> the same sample distance, then the new mapper should out perform the old >>>>>>>>>>>>> one, however, there is another thing we need to consider here which is >>>>>>>>>>>>> shading. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Can you disable the shading and see if now they both (opengl1 >>>>>>>>>>>>> and 2) equally better? We already pushed a fix for it but not sure if that >>>>>>>>>>>>> you have in your build. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe the >>>>>>>>>>>>>> GPURenderDemo used with this dataset is enough to highlight the slow down. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Simon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with shading >>>>>>>>>>>>>>> that was causing the slow performance a while back. I don't remember if >>>>>>>>>>>>>>> that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the data >>>>>>>>>>>>>>>> type you might be using >>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The performance >>>>>>>>>>>>>>>> we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new mapper >>>>>>>>>>>>>>>> is bringing low resolution when you interact with the volume (and whether >>>>>>>>>>>>>>>> or not it happens with old mapper). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you compare the >>>>>>>>>>>>>>>>> latest 4.4 OpenGL2 build with the classic 4.4 build while volume rendering >>>>>>>>>>>>>>>>> a big enough volume (512^3) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>> claims that the new GPU volume rendering implementation >>>>>>>>>>>>>>>>> should be faster than the old one, is there some more detailed explanation >>>>>>>>>>>>>>>>> somewhere ? Are there some important parameters that can make the >>>>>>>>>>>>>>>>> difference ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with the >>>>>>>>>>>>>>>>> new backend ! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>> Inc. * >>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>>> * >>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>> * >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>> * >>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Nov 2 10:32:14 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 2 Nov 2015 10:32:14 -0500 Subject: [vtk-developers] Scissor in vtkOpenGLCamera In-Reply-To: References: Message-ID: Okay, I will push a API at the vtkOpenGL Camera level sometime today/tomorrow unless someone objects here. Thanks, On Thu, Oct 29, 2015 at 5:18 PM, Antonella Cascitelli wrote: > To summarize I need to render a small part of the whole scene as Roi > Region Of Interest (ROI) in order to render a rectangle around an object > without altering its geometry and prospective. > Il 29 ott 2015 8:23 PM, "Aashish Chaudhary" > ha scritto: > >> On Thu, Oct 29, 2015 at 3:15 PM, Antonella Cascitelli < >> lenlen1982 at gmail.com> wrote: >> >>> Thank you, but I'm trying to render only a smaller part of image instead >>> the whole image to save computational time. >>> >> >> If that's the case, why not have a smaller viewport? I may be missing >> something here. >> >> >>> I have just modified vtkOpenGLCamera the call to glScissor with my >>> custom arguments and It works... is it possible to expose a patch that >>> allow a custom glScissor setting? What I have done is a dirty workaround, >>> which would be the right class to add this new public method? >>> >> >> Hmm..not sure if that would be easy unless we just add an API to the >> vtkOpenGLCamera. I would be okay with the later option but wondering what >> others has to say on this. >> >> - Aashish >> >> >>> >>> 2015-10-29 19:52 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> You can achieve this by creating two renderers and then for the second >>>> one just a smaller viewport (on top of the first one). I am assuming that >>>> you are showing two images / data at the same time. >>>> >>>> There is no API (as far as I know) to help you with this task. >>>> >>>> On Thu, Oct 29, 2015 at 2:45 PM, Antonella Cascitelli < >>>> lenlen1982 at gmail.com> wrote: >>>> >>>>> Hi, >>>>> is it possible set the glScissor in vtk? >>>>> i.e. in vtkOpenGLCamera: >>>>> >>>>> glViewport(lowerLeft[0], lowerLeft[1], usize, vsize); >>>>> glEnable(GL_SCISSOR_TEST); >>>>> glScissor(lowerLeft[0], lowerLeft[1], usize, vsize); >>>>> >>>>> so seems that the scissor area is always the same of the viewport. >>>>> I want to render only a small rectangle area in the viewport like >>>>> using scissor with opengl. >>>>> >>>>> Thanks >>>>> >>>>> Antonella >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: >>>>> http://markmail.org/search/?q=vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Nov 2 16:58:09 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 2 Nov 2015 16:58:09 -0500 Subject: [vtk-developers] [BUILDBOT] Blog post on Do: test features Message-ID: <20151102215809.GA30249@megas.khq.kitware.com> Hi, I've created a blog post about the new Buildbot features here: http://kitware.com/blog/home/post/984 This describes the new Do: test feature and also has some examples which can be used to help buildbot get results for your branches more quickly. Also, the old "@buildbot test" commands are now officially deprecated for the buildbot.kitware.com instance; warning messages should start showing up tomorrow. The plan is to disable it there at the end of the month. Thanks, --Ben From aashish.chaudhary at kitware.com Tue Nov 3 13:44:34 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 3 Nov 2015 13:44:34 -0500 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: Hi Simon, the branch has been merged into VTK master. I am not sure when Paraview is going to update the VTK, but you can do it manually if needed. We are also going to run our bench marking again to be sure since recently lot many changes went into the VTK / volume rendering. Please feel free to ping me again if it does not solve your issue. Looking forward to your feedback. - Aashish On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Hi Simon, > > I found the reason behind the appeared performance you were getting. We > have this code in volume rendering that when you interact changes the > sampling distance and in the newer code we were too conservative compare to > the last version. That's why you were getting better quality when you move > your mouse but lower frame rates. I pushed a branch in VTK to address the > issue. Would it be possible for you to build Paraview with VTK master? It > may take 3-4 days or longer for Paraview's VTK to get updated. > > Thanks, > Aashish > > On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> Hi Simon, >> >> I am just finishing up a ParaView5 related parallel volume rendering bug >> (pushing a branch today to VTK). This is next on my list. >> >> - Aashish >> >> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >> simon.esneault at gmail.com> wrote: >> >>> Hello Aashish >>> >>> Did you get a chance to try to load the dataset on Windows ? >>> Can I do anything to help you investigate ? Should I feel a bug, that >>> may act as a reminder ? >>> Have a nice day >>> Simon >>> >>> >>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> Thanks Simon. This is really strange since we are not seeing it on Mac >>>> and Linux (but both has dedicated cards). >>>> >>>> I will look into it soon. >>>> >>>> - aashish >>>> >>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Ok, thank you very much fort digging into this. >>>>> I've done some test and I believe I can see a similar slowdown >>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>> graphics. >>>>> Good luck in the investigation, I you need more details, do not >>>>> hesitate to ask >>>>> Simon >>>>> >>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> Ah, thanks. I will get back to you on this since on Linux I don't any >>>>>> issue so it has to be Windows specific thing. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> I tried with that one from yesterday and today's version >>>>>>> (4.4.0-209-gc399648) >>>>>>> >>>>>>> Thanks, >>>>>>> Simon >>>>>>> >>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com>: >>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> And when did you download this version? >>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Aashish >>>>>>>> >>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>> version seems even bigger. >>>>>>>>> I got the version from the nightly build download section of >>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>> results. >>>>>>>>> >>>>>>>>> About the FPS, it is difficult to give an exact number, because it >>>>>>>>> depends of the condition (zoomed or not etc...) but yes, this is the idea. >>>>>>>>> In our software, I've exposed the frame rate using this example : >>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>>> example), with the same mapper parameters >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>> >>>>>>>>>> Hi Simon, >>>>>>>>>> >>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>> >>>>>>>>>> 1) Did you try without the shading and see how the performance >>>>>>>>>> compares? >>>>>>>>>> >>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this one >>>>>>>>>> from (ParaView download page or did you built yourself?) >>>>>>>>>> >>>>>>>>>> Also, so on your system the old mapper is running 30FPS and the >>>>>>>>>> new one at 15-20 FPS as per your summary. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> - Aashish >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello Aashish, >>>>>>>>>>> >>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>> The two tested version are : >>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 backend. >>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and Nvidia >>>>>>>>>>> Quadro K420 >>>>>>>>>>> >>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>> - Select volume rendering >>>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>> >>>>>>>>>>> And start interacting ... >>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate in >>>>>>>>>>> Paraview, but the new version seems really twice slower in these >>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>> interactivity is better. >>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>> >>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play with >>>>>>>>>>> this with the old backend to fine tune the interactivity, although what's >>>>>>>>>>> really inside was never clear to me >>>>>>>>>>> >>>>>>>>>>> I hope that there is enough information for you to reproduce >>>>>>>>>>> this, do not hesitate to ask for some more information. >>>>>>>>>>> >>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>> >>>>>>>>>>>> Dear Simon, >>>>>>>>>>>> >>>>>>>>>>>> Checking again. Wondering if you can provide some more detail >>>>>>>>>>>> on the binary you are using and whether or not without shading the >>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Simon, >>>>>>>>>>>>> >>>>>>>>>>>>> I used your dataset on paraview master as of today on my Linux >>>>>>>>>>>>> box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about 15-20 >>>>>>>>>>>>> FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>> >>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>>> >>>>>>>>>>>>> NOTE: You might get multiple emails because of the attachment >>>>>>>>>>>>> size issue. Sorry about that. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short element >>>>>>>>>>>>>>> (you can find the dataset here : >>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). So I >>>>>>>>>>>>>>> think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>> The new mapper does bring low resolution, but when compared >>>>>>>>>>>>>>> to the old one, it seems less "low resolution" during interaction than the >>>>>>>>>>>>>>> old one >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What happens >>>>>>>>>>>>>> is that depending on what is interactive, (you can set the desired update >>>>>>>>>>>>>> rate in VTK, not exposed in ParaView I believe), it will do interactive >>>>>>>>>>>>>> but with higher resolution (smaller sample distance). If they both have >>>>>>>>>>>>>> the same sample distance, then the new mapper should out perform the old >>>>>>>>>>>>>> one, however, there is another thing we need to consider here which is >>>>>>>>>>>>>> shading. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you disable the shading and see if now they both (opengl1 >>>>>>>>>>>>>> and 2) equally better? We already pushed a fix for it but not sure if that >>>>>>>>>>>>>> you have in your build. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe the >>>>>>>>>>>>>>> GPURenderDemo used with this dataset is enough to highlight the slow down. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with shading >>>>>>>>>>>>>>>> that was causing the slow performance a while back. I don't remember if >>>>>>>>>>>>>>>> that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the data >>>>>>>>>>>>>>>>> type you might be using >>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The performance >>>>>>>>>>>>>>>>> we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you compare >>>>>>>>>>>>>>>>>> the latest 4.4 OpenGL2 build with the classic 4.4 build while volume >>>>>>>>>>>>>>>>>> rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering implementation >>>>>>>>>>>>>>>>>> should be faster than the old one, is there some more detailed explanation >>>>>>>>>>>>>>>>>> somewhere ? Are there some important parameters that can make the >>>>>>>>>>>>>>>>>> difference ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with the >>>>>>>>>>>>>>>>>> new backend ! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>> * >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>> Inc. * >>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>>> * >>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>> * >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> Simon Esneault >>>>>>>>>>> Rennes, France >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>> * >>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>> * >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Wed Nov 4 11:07:32 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 4 Nov 2015 11:07:32 -0500 Subject: [vtk-developers] dejagore rebooted Message-ID: Hi, We just rebooted dejagore, one of the expected buildbot machine. All video memory was occupied and because of that tests were timing out on it. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupiter.hce at gmail.com Thu Nov 5 05:54:00 2015 From: jupiter.hce at gmail.com (jupiter) Date: Thu, 5 Nov 2015 21:54:00 +1100 Subject: [vtk-developers] Build GUI support on version 6.3.0 Message-ID: Hi, On version 5.10.1, the GUI support is added by VTK_USE_QT and VTK_USE_GUISUPPORT. Both parameters are no longer works on version 6.3.0 and I can no longer get QVTKWidget.h. How can I build the vtk 6.3.0 to get gui support? Thank you. Kind regards, - j -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Thu Nov 5 08:53:01 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 5 Nov 2015 08:53:01 -0500 Subject: [vtk-developers] Build GUI support on version 6.3.0 In-Reply-To: References: Message-ID: VTK_Group_Qt should be set to ON. You may also have to set QT_QMAKE_EXECUTABLE if qmake is not found automatically. Cory On Thu, Nov 5, 2015 at 5:54 AM, jupiter wrote: > Hi, > > On version 5.10.1, the GUI support is added by VTK_USE_QT and > VTK_USE_GUISUPPORT. Both parameters are no longer works on version 6.3.0 > and I can no longer get QVTKWidget.h. How can I build the vtk 6.3.0 to get > gui support? > > Thank you. > > Kind regards, > > - j > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Nov 5 11:14:37 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 5 Nov 2015 11:14:37 -0500 Subject: [vtk-developers] Known build failures Message-ID: Hi all, To keep everyone in the loop: currently we have known build failures on the buildbot machine megas with the current master related to a jsoncpp update. There is a branch up to fix these: https://gitlab.kitware.com/vtk/vtk/merge_requests/877 Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From hahnse at ornl.gov Thu Nov 5 11:49:22 2015 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Thu, 5 Nov 2015 16:49:22 +0000 Subject: [vtk-developers] merge requests for vtkCutter Message-ID: We often use the ParaView Slice View to visualize a vtStructuredGrid. I profiled changing the slice position and found two small changes that improve the response time. I submitted both as merge requests ( https://gitlab.kitware.com/vtk/vtk/merge_requests/878 https://gitlab.kitware.com/vtk/vtk/merge_requests/879 ). Both include small examples showing the improvement. Best, Steven From zack.galbreath at kitware.com Thu Nov 5 14:50:13 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Thu, 5 Nov 2015 14:50:13 -0500 Subject: [vtk-developers] test the new CDash Message-ID: This past weekend I attempted to roll out a new version of CDash's index.php page. It ended up performing too slowly and causing some user's browsers to freeze up, particularly for VTK. Since then I've spent some time trying to improve its performance. I'd appreciate feedback on how my latest version behaves for you: http://testing.cdash.org/index.php?project=VTK http://testing.cdash.org/index.php?project=Insight You'll notice that each group only shows 10 builds at a time by default. In addition to helping the page render more quickly, this change also makes it easier to scroll to the bottom of the page where coverage & dynamic analysis data reside. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Nov 5 15:09:41 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 5 Nov 2015 15:09:41 -0500 Subject: [vtk-developers] [ITK-dev] test the new CDash In-Reply-To: References: Message-ID: It's fast for me on the browser that had trouble last weekend. On Thu, Nov 5, 2015 at 2:50 PM, Zack Galbreath wrote: > This past weekend I attempted to roll out a new version of CDash's index.php > page. It ended up performing too slowly and causing some user's browsers to > freeze up, particularly for VTK. Since then I've spent some time trying to > improve its performance. > > I'd appreciate feedback on how my latest version behaves for you: > > http://testing.cdash.org/index.php?project=VTK > http://testing.cdash.org/index.php?project=Insight > > You'll notice that each group only shows 10 builds at a time by default. In > addition to helping the page render more quickly, this change also makes it > easier to scroll to the bottom of the page where coverage & dynamic analysis > data reside. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/insight-developers > -- Unpaid intern in BillsBasement at noware dot com From matt.mccormick at kitware.com Thu Nov 5 15:16:13 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 5 Nov 2015 15:16:13 -0500 Subject: [vtk-developers] [ITK-dev] test the new CDash In-Reply-To: References: Message-ID: +1, much faster now. Thank for the improvements! Could the number of items displayed be made persistent across page visits? I also noticed that going to the "Last" set is blank. Thanks, Matt On Thu, Nov 5, 2015 at 3:09 PM, Bill Lorensen wrote: > It's fast for me on the browser that had trouble last weekend. > > > On Thu, Nov 5, 2015 at 2:50 PM, Zack Galbreath > wrote: >> This past weekend I attempted to roll out a new version of CDash's index.php >> page. It ended up performing too slowly and causing some user's browsers to >> freeze up, particularly for VTK. Since then I've spent some time trying to >> improve its performance. >> >> I'd appreciate feedback on how my latest version behaves for you: >> >> http://testing.cdash.org/index.php?project=VTK >> http://testing.cdash.org/index.php?project=Insight >> >> You'll notice that each group only shows 10 builds at a time by default. In >> addition to helping the page render more quickly, this change also makes it >> easier to scroll to the bottom of the page where coverage & dynamic analysis >> data reside. >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/insight-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 > From zack.galbreath at kitware.com Thu Nov 5 15:46:06 2015 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Thu, 5 Nov 2015 15:46:06 -0500 Subject: [vtk-developers] [ITK-dev] test the new CDash In-Reply-To: References: Message-ID: On Thu, Nov 5, 2015 at 3:16 PM, Matt McCormick wrote: > Could the number of items displayed be made persistent across page > visits? Good suggestion. I also noticed that going to the "Last" set is blank. > I see that now too, on the "Expected Nightly" section of the ITK dashboard. I'll make sure to resolve both of these issues before pushing these changes to open.cdash.org. Thanks for the feedback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Thu Nov 5 21:43:15 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 5 Nov 2015 21:43:15 -0500 Subject: [vtk-developers] Build GUI support on version 6.3.0 In-Reply-To: References: Message-ID: You're welcome :-) On Thu, Nov 5, 2015 at 7:19 PM, jupiter wrote: > Thanks Cory, that works. > > Cheers. > > - j > > On Fri, Nov 6, 2015 at 12:53 AM, Cory Quammen > wrote: > >> VTK_Group_Qt should be set to ON. You may also have to set >> QT_QMAKE_EXECUTABLE if qmake is not found automatically. >> >> Cory >> >> On Thu, Nov 5, 2015 at 5:54 AM, jupiter wrote: >> >>> Hi, >>> >>> On version 5.10.1, the GUI support is added by VTK_USE_QT and >>> VTK_USE_GUISUPPORT. Both parameters are no longer works on version 6.3.0 >>> and I can no longer get QVTKWidget.h. How can I build the vtk 6.3.0 to get >>> gui support? >>> >>> Thank you. >>> >>> Kind regards, >>> >>> - j >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the 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 >> R&D Engineer >> Kitware, Inc. >> > > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupiter.hce at gmail.com Thu Nov 5 22:36:22 2015 From: jupiter.hce at gmail.com (jupiter) Date: Fri, 6 Nov 2015 14:36:22 +1100 Subject: [vtk-developers] QVTKWidget.h errors Message-ID: Hi, I am building FSL where the FSL VTK API apparently based on old version of VTK where the SetInput() is used. I don't want to touch the FSL VTK API files, so I built the VTK 5.10.1 with gcc version 4.4.7 and qt version 4.6.2, then I was building the FSL based on VTK version 5.10.1 and QVTKWidget.h seems broken. Does VTK 5.10.1 need a specific version of gcc or qt? Please advise how to fix it. FSL/fsl5.0.8/src/fslview/src/fslview/vtkwidget.cpp:75: /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:141: error: ISO C++ forbids declaration of ?QPaintEngine? with no type /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:141: error: ?QPaintEngine? declared as a ?virtual? field /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:141: error: expected ?;? before ?*? token /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:158: error: expected primary-expression before ?void? /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:158: error: ISO C++ forbids declaration of ?Q_SIGNALS? with no type /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:158: error: expected ?;? before ?void? /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:169: error: expected ?:? before ?Q_SLOTS? /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:176: error: expected primary-expression before ?void? /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:176: error: ISO C++ forbids declaration of ?Q_SLOTS? with no type /usr/local/vtk/5.10.1/include/vtk-5.10/QVTKWidget.h:176: error: expected ?;? before ?void? Thank you. Kind regards, - j -------------- next part -------------- An HTML attachment was scrubbed... URL: From marek.pecha at vsb.cz Fri Nov 6 07:39:42 2015 From: marek.pecha at vsb.cz (Marek Pecha) Date: Fri, 6 Nov 2015 13:39:42 +0100 Subject: [vtk-developers] Multiple vtkImageData to vtkDiscreteMarchingCubes Message-ID: <1680B470-2DC4-42C7-B4A2-8479AD519FFE@vsb.cz> Hello VTK team, I try to solve a next problem. I try to visualize a medical mesh by vtkDiscreteMarchingCubes from DICOM files but I combine your the best of best visualization toolkit and OpenCV for preprocessing. Here is my approach: 1. I read medical DICOM files by VTK 2. I convert vtkImageData to cv::Mat 3. .... doing something interest ... 4. I convert cv::Mat to vtkImageData (source code is below) bool PnLabImportOpenCVMat2VtkImageData(cv::Mat &src, vtkSmartPointer dest) { assert(src.data != NULL); vtkSmartPointer importer; importer = vtkSmartPointer::New(); if (dest) { importer->SetOutput(dest); } importer->SetDataSpacing(1, 1, 1); importer->SetDataOrigin(0, 0, 0); importer->SetWholeExtent(0, src.cols - 1, 0, src.rows - 1, 0, 0); importer->SetDataScalarTypeToDouble(); importer->SetNumberOfScalarComponents(1); importer->SetImportVoidPointer(src.data); importer->Update(); return (true); } //[end-function] ImportOpenCVMat2VtkImageData 5. I add vtkImageData to vtkImageCacheFilter vtkSmartPointer discrete_cubes; vtkSmartPointer vtk_img_data; vtkSmartPointer vtk_multiple_data; vtk_multiple_data = vtkSmartPointer::New(); discrete_cubes = vtkSmartPointer::New(); for(int i=0; i < slices.size(); i++) { vtk_img_data = vtkSmartPointer::New(); PnLabImportOpenCVMat2VtkImageData(*slices[i], vtk_img_data); vtk_multiple_data->AddInputData(vtk_img_data); } vtk_multiple_data->Update(); discrete_cubes->SetInputData(vtk_multiple_data->GetOutput()); discrete_cubes->GenerateValues(1, 1, 1); discrete_cubes->Update(); But after vtk_multiple_data->Update(); I got error message ERROR: In /Users/mari/ProgramsToBuild/VTK-6.3.0/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx, line 720 vtkCachedStreamingDemandDrivenPipeline (0x7f89d8c02b60): Input port 0 of algorithm vtkImageCacheFilter(0x7f89d8c02400) has 20 connections but is not repeatable. I don't know what I'm doing wrong. Please can you help me? Thank you Mari -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Fri Nov 6 09:46:01 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Fri, 6 Nov 2015 09:46:01 -0500 Subject: [vtk-developers] Pull requests for VTK on github Message-ID: Folks, There are a couple of pull requests on github. https://github.com/Kitware/VTK/pulls Is it possible to disable pull requests on github and redirect people to gitlab? Some Googling suggests you can't disable pull requests. Thanks, Cory -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Fri Nov 6 09:53:11 2015 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Fri, 6 Nov 2015 14:53:11 +0000 Subject: [vtk-developers] Pull requests for VTK on github Message-ID: I did a google search on providing an auto-response to github pull requests and came up with this: https://github.com/blog/144-pull-request-auto-responder It looks like you can set up the github repository to send an automatic response to anyone who tries to submit a pull request at github that this is the wrong way to contribute to VTK and to point them to information on the proper way contribute to VTK. -Ken From: vtk-developers > on behalf of Cory Quammen > Date: Friday, November 6, 2015 at 7:46 AM To: VTK Developers > Subject: [EXTERNAL] [vtk-developers] Pull requests for VTK on github Folks, There are a couple of pull requests on github. https://github.com/Kitware/VTK/pulls Is it possible to disable pull requests on github and redirect people to gitlab? Some Googling suggests you can't disable pull requests. Thanks, Cory -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Nov 6 10:04:38 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 06 Nov 2015 10:04:38 -0500 Subject: [vtk-developers] Pull requests for VTK on github In-Reply-To: References: Message-ID: <563CC186.7090204@kitware.com> On 11/06/2015 09:53 AM, Moreland, Kenneth wrote: > I did a google search on providing an auto-response to github pull requests and came up with this: > > https://github.com/blog/144-pull-request-auto-responder That no longer exists AFAIK. The only thing we can do is hope people read CONTRIBUTING.md and if not close the PR with a link to it. The latter step could perhaps be scripted with enough work using webhooks. -Brad From saeedbakhshmand at gmail.com Fri Nov 6 12:24:18 2015 From: saeedbakhshmand at gmail.com (Saeed Mahdizadeh Bakhshmand) Date: Fri, 6 Nov 2015 12:24:18 -0500 Subject: [vtk-developers] How to change opacity/visibility of polyline In-Reply-To: References: Message-ID: Hello Mathieu, Thanks for your response, And this output should be saved into an vtkUnstructuredGrid or there is a better way to copy data from selection? Best, Saeed On Fri, Oct 30, 2015 at 3:03 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hello > > No, but you can extract the cells you want to see, and display the output. > > Mathieu > > Mathieu Westphal > > On Thu, Oct 29, 2015 at 11:19 PM, Saeed Mahdizadeh Bakhshmand < > saeedbakhshmand at gmail.com> wrote: > >> Hello, >> >> Is there any way to toggle visibility of each line of a vtkpolydata (or >> vtkpolyline) independently? >> >> Best, >> Saeed >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 lenlen1982 at gmail.com Sat Nov 7 12:16:39 2015 From: lenlen1982 at gmail.com (Antonella Cascitelli) Date: Sat, 7 Nov 2015 18:16:39 +0100 Subject: [vtk-developers] Scissor in vtkOpenGLCamera In-Reply-To: References: Message-ID: Hi, I have prepared a merge request in the gitlab repository, here the link: https://gitlab.kitware.com/vtk/vtk/merge_requests/882 Let me know if it's okay! Thanks 2015-11-02 16:32 GMT+01:00 Aashish Chaudhary : > Okay, I will push a API at the vtkOpenGL Camera level sometime > today/tomorrow unless someone objects here. > > Thanks, > > > On Thu, Oct 29, 2015 at 5:18 PM, Antonella Cascitelli < > lenlen1982 at gmail.com> wrote: > >> To summarize I need to render a small part of the whole scene as Roi >> Region Of Interest (ROI) in order to render a rectangle around an object >> without altering its geometry and prospective. >> Il 29 ott 2015 8:23 PM, "Aashish Chaudhary" < >> aashish.chaudhary at kitware.com> ha scritto: >> >>> On Thu, Oct 29, 2015 at 3:15 PM, Antonella Cascitelli < >>> lenlen1982 at gmail.com> wrote: >>> >>>> Thank you, but I'm trying to render only a smaller part of image >>>> instead the whole image to save computational time. >>>> >>> >>> If that's the case, why not have a smaller viewport? I may be missing >>> something here. >>> >>> >>>> I have just modified vtkOpenGLCamera the call to glScissor with my >>>> custom arguments and It works... is it possible to expose a patch that >>>> allow a custom glScissor setting? What I have done is a dirty workaround, >>>> which would be the right class to add this new public method? >>>> >>> >>> Hmm..not sure if that would be easy unless we just add an API to the >>> vtkOpenGLCamera. I would be okay with the later option but wondering what >>> others has to say on this. >>> >>> - Aashish >>> >>> >>>> >>>> 2015-10-29 19:52 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> You can achieve this by creating two renderers and then for the second >>>>> one just a smaller viewport (on top of the first one). I am assuming that >>>>> you are showing two images / data at the same time. >>>>> >>>>> There is no API (as far as I know) to help you with this task. >>>>> >>>>> On Thu, Oct 29, 2015 at 2:45 PM, Antonella Cascitelli < >>>>> lenlen1982 at gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> is it possible set the glScissor in vtk? >>>>>> i.e. in vtkOpenGLCamera: >>>>>> >>>>>> glViewport(lowerLeft[0], lowerLeft[1], usize, vsize); >>>>>> glEnable(GL_SCISSOR_TEST); >>>>>> glScissor(lowerLeft[0], lowerLeft[1], usize, vsize); >>>>>> >>>>>> so seems that the scissor area is always the same of the viewport. >>>>>> I want to render only a small rectangle area in the viewport like >>>>>> using scissor with opengl. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Antonella >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the list archives at: >>>>>> http://markmail.org/search/?q=vtk-developers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Mon Nov 9 07:42:38 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Mon, 9 Nov 2015 13:42:38 +0100 Subject: [vtk-developers] MouseWheel event pending missing on windows wrt X11 Message-ID: Hi, I have a patch to include the MouseWheel event in the ones returned by vtkWin32OpenGLRenderWindow::GetEventPending, in order to allow the interuption of rendering in the same way as a mouse click. I was looking at the code in vtkXOpenGLRenderWindow to report it here as well, but i think it is already doing it, since it check the ButtonPress event (in vtkXOpenGLRenderWindowPredProc line 1406), that includes the mouse wheel event (the event has a subinfo indicating the corresponding button: left, middle, right, wheelForward, wheelBackward). So before pushing a branch on GitLab, could anyone with access to a X platform or with good knowledge of this code can confirm this behaviour? Thanks, Xabi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Mon Nov 9 10:47:10 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 9 Nov 2015 10:47:10 -0500 Subject: [vtk-developers] Failing test on dejagore Message-ID: Hi Ken, We have one test failing on the dejagore buildbot machine on master. You can see the failure here [1]. Can you take a look and tell me what you think of this failure? If it is a bad valid image I can add the new one. Thanks, Shawn [1]: https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=617819ae-build131-[linux-shared-release%2Bgcc%2Bmpi%2Bpython%2Bqt]&compare3=61&showfeed=0&value2=20151107T221531 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Nov 9 10:50:32 2015 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 9 Nov 2015 10:50:32 -0500 Subject: [vtk-developers] Failing test on dejagore In-Reply-To: References: Message-ID: <76496e6454efaecadbdc519b9064f701@mail.gmail.com> Sure but I have a fairly large backlog so it will be a while before I can get to it - Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) 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:* Shawn Waldon [mailto:shawn.waldon at kitware.com] *Sent:* Monday, November 9, 2015 10:47 AM *To:* Ken Martin; VTK Developers *Subject:* Failing test on dejagore Hi Ken, We have one test failing on the dejagore buildbot machine on master. You can see the failure here [1]. Can you take a look and tell me what you think of this failure? If it is a bad valid image I can add the new one. Thanks, Shawn [1]: https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=617819ae-build131-[linux-shared-release%2Bgcc%2Bmpi%2Bpython%2Bqt]&compare3=61&showfeed=0&value2=20151107T221531 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Nov 9 10:54:22 2015 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 9 Nov 2015 10:54:22 -0500 Subject: [vtk-developers] Failing test on dejagore In-Reply-To: 76496e6454efaecadbdc519b9064f701@mail.gmail.com References: 76496e6454efaecadbdc519b9064f701@mail.gmail.com Message-ID: <3f33ea649a748e696a99846f5bf0dda2@mail.gmail.com> I take that back, I did look into it quickly. I am guessing it is an X-windows timing issue as the problem is that the window is not remapped quickly enough or something like that. The test could be ?fixed? by not resizing the window I suppose, or adding a couple more renders into the mix to give it more time to resize. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) 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 [mailto:ken.martin at kitware.com] *Sent:* Monday, November 9, 2015 10:51 AM *To:* Shawn Waldon; 'VTK Developers' *Subject:* RE: Failing test on dejagore Sure but I have a fairly large backlog so it will be a while before I can get to it - Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) 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:* Shawn Waldon [mailto:shawn.waldon at kitware.com ] *Sent:* Monday, November 9, 2015 10:47 AM *To:* Ken Martin; VTK Developers *Subject:* Failing test on dejagore Hi Ken, We have one test failing on the dejagore buildbot machine on master. You can see the failure here [1]. Can you take a look and tell me what you think of this failure? If it is a bad valid image I can add the new one. Thanks, Shawn [1]: https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=617819ae-build131-[linux-shared-release%2Bgcc%2Bmpi%2Bpython%2Bqt]&compare3=61&showfeed=0&value2=20151107T221531 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Mon Nov 9 11:03:35 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Mon, 9 Nov 2015 17:03:35 +0100 Subject: [vtk-developers] Mouse wheel action only if mouse is in window Message-ID: Hi, For my own vtk version, I have a vtkWin32RenderWindowInteractor patch to send the mouse wheel events only if the mouse is in the window (concretely, a check of this->MouseInWindow in OnMouseWheelForward and OnMouseWheelBackward...). It is mainly to avoid a window to be inadvertently "modified" when we think it is the one currently under the mouse cursor that will be. After a quick search, i found this for Windows guidelines: https://msdn.microsoft.com/en-us/library/dn742466.aspx where it is stated : " *Make the mouse wheel affect the control, pane, or window that the pointer is currently over.* Doing so avoids unintended results. " which is the behaviour of most of the windows applications. I was wondering if you would be interested in having this patch. Let me know what you think. Xabi -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Nov 9 11:22:57 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 9 Nov 2015 11:22:57 -0500 Subject: [vtk-developers] Failing test on dejagore In-Reply-To: References: Message-ID: It is failing because ERROR's are reported. Our recent patch now causes tests to fail if ERROR is detected in the output stream. https://gitlab.kitware.com/vtk/vtk/merge_requests/861 On Mon, Nov 9, 2015 at 10:47 AM, Shawn Waldon wrote: > Hi Ken, > > We have one test failing on the dejagore buildbot machine on master. You > can see the failure here [1]. Can you take a look and tell me what you > think of this failure? If it is a bad valid image I can add the new one. > > Thanks, > Shawn > > [1]: > https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=617819ae-build131-[linux-shared-release%2Bgcc%2Bmpi%2Bpython%2Bqt]&compare3=61&showfeed=0&value2=20151107T221531 > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 Nov 9 11:40:09 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 9 Nov 2015 11:40:09 -0500 Subject: [vtk-developers] Failing test on dejagore In-Reply-To: References: Message-ID: It is also failing the image test. On Mon, Nov 9, 2015 at 11:22 AM, Bill Lorensen wrote: > It is failing because ERROR's are reported. Our recent patch now > causes tests to fail if ERROR is detected in the output stream. > > https://gitlab.kitware.com/vtk/vtk/merge_requests/861 > > > On Mon, Nov 9, 2015 at 10:47 AM, Shawn Waldon wrote: >> Hi Ken, >> >> We have one test failing on the dejagore buildbot machine on master. You >> can see the failure here [1]. Can you take a look and tell me what you >> think of this failure? If it is a bad valid image I can add the new one. >> >> Thanks, >> Shawn >> >> [1]: >> https://open.cdash.org/queryTests.php?compare1=65&value3=Failed&filtercount=3&field3=status%2Fstring&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=617819ae-build131-[linux-shared-release%2Bgcc%2Bmpi%2Bpython%2Bqt]&compare3=61&showfeed=0&value2=20151107T221531 >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 From bill.lorensen at gmail.com Mon Nov 9 12:35:59 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 9 Nov 2015 12:35:59 -0500 Subject: [vtk-developers] No valgrind for opengl2 Message-ID: Folks, Ubuntu-valgrind is testing opegl. There is no valgrind for opengl2. I noticed this when looking at an opengl2 test that had an obvious memory leak. Bill From dave.demarle at kitware.com Mon Nov 9 12:59:22 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 9 Nov 2015 12:59:22 -0500 Subject: [vtk-developers] No valgrind for opengl2 In-Reply-To: References: Message-ID: Thanks for the heads up Bill. My plan is to update the OS and setup valgrind w OpenGLNew on dashlin1 (a much newer/faster machine than karego-at). This is unlikely to happen before SC15 is over two weeks from now however. Ping me again if it is not setup in a month or so. cheers David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Nov 9, 2015 at 12:35 PM, Bill Lorensen wrote: > Folks, > > Ubuntu-valgrind is testing opegl. There is no valgrind for opengl2. > > I noticed this when looking at an opengl2 test that had an obvious memory > leak. > > 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: From bill.lorensen at gmail.com Mon Nov 9 13:02:45 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 9 Nov 2015 13:02:45 -0500 Subject: [vtk-developers] No valgrind for opengl2 In-Reply-To: References: Message-ID: Sounds good. Thanks, Bill On Mon, Nov 9, 2015 at 12:59 PM, David E DeMarle wrote: > Thanks for the heads up Bill. > > My plan is to update the OS and setup valgrind w OpenGLNew on dashlin1 (a > much newer/faster machine than karego-at). > > This is unlikely to happen before SC15 is over two weeks from now however. > Ping me again if it is not setup in a month or so. > > cheers > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Mon, Nov 9, 2015 at 12:35 PM, Bill Lorensen > wrote: >> >> Folks, >> >> Ubuntu-valgrind is testing opegl. There is no valgrind for opengl2. >> >> I noticed this when looking at an opengl2 test that had an obvious memory >> leak. >> >> 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 >> > -- Unpaid intern in BillsBasement at noware dot com From schuyler.kylstra at kitware.com Tue Nov 10 15:43:08 2015 From: schuyler.kylstra at kitware.com (Schuyler Kylstra) Date: Tue, 10 Nov 2015 15:43:08 -0500 Subject: [vtk-developers] MySQL module not exported by v6.3.0 Message-ID: Hi developers, I'm working on a project that uses vtk as part of a superbuild. I'm currently pulling the repo at the tag v6.3.0 and I'm running into a problem. The FindMySQL.cmake file is not getting placed in the install folder for some reason. I've looked through the build files and I can't find an option to install the file. Is this a known issue/is there a way to fix this? -- Schuyler Kylstra -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Nov 11 10:00:32 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 11 Nov 2015 10:00:32 -0500 Subject: [vtk-developers] Buildbot builds changed to use OpenGL2 In-Reply-To: <20151026181334.GA11728@megas.khq.kitware.com> References: <20151026155457.162131033@mail.rogue-research.com> <20151026160920.1032078160@mail.rogue-research.com> <20151026165319.GA20678@megas.khq.kitware.com> <20151026165729.1798306454@mail.rogue-research.com> <20151026181334.GA11728@megas.khq.kitware.com> Message-ID: <20151111150032.1905614795@mail.rogue-research.com> On Mon, 26 Oct 2015 14:13:34 -0400, Ben Boeckel said: >> >These have been renamed to use "+opengl1" rather than "+opengl2". Or are >> >you referring to nightly dashboards (buildbot certainly never used >> >uppercase at least)? >> >> I'm referring to dashboard entries like: >> >> kensmacbook.Kitware OpenGL2 >> >> dash1win7.kitware Win32-vs11-OpenGL2 >> >> kens_ipad.kitware iOS OpenGL2 ES 2.0 >> >> RogueResearch14 Mac10.11-clang-dbg-OpenGL2-x86_64 >> >> Especially my own submissions. If OpenGL2 is now assumed/default, >> should I (and others) remove "OpenGL2" and instead name others >> "OpenGL1"? > >I think that makes sense, yes. Let me know the new names and I'll update >CDash's expected set. Ben, I've renamed all my submissions accordingly. Most are OpenGL1 since that's what we're currently using in our app. Can you update the expected list please? Now I'll look at greening them up... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From burlen.loring at gmail.com Wed Nov 11 12:04:37 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Wed, 11 Nov 2015 09:04:37 -0800 Subject: [vtk-developers] vtkDepthSortPolyData modernization Message-ID: <56437525.8040107@gmail.com> Hi All, Would anyone be willing to review this patch? https://gitlab.kitware.com/vtk/vtk/merge_requests/844 I was profiling VisIt and noticed that vtkDepthSortPolyData (in spite of its limitations it is used by VisIt for transparent rendering) made use of qsort and about 1/2 the time was spent by qsort. std::sort is known to be faster because of the possibility of the compiler to inline the comparisons. Updating qsort to std::sort seemed like an easy way to make it faster. As I worked the profiler pointed out a number of other fairly easy things to improve and overall the class is now ~3x faster for two of the modes and ~2x faster for the other. I enumerated the changes in the commit message and have added a cxx test to improve the test coverage. If you have the time, please take a look, and let me know if you have any feedback on it. Thanks Burlen From ben.boeckel at kitware.com Wed Nov 11 13:53:34 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 11 Nov 2015 13:53:34 -0500 Subject: [vtk-developers] Buildbot builds changed to use OpenGL2 In-Reply-To: <20151111150032.1905614795@mail.rogue-research.com> References: <20151026155457.162131033@mail.rogue-research.com> <20151026160920.1032078160@mail.rogue-research.com> <20151026165319.GA20678@megas.khq.kitware.com> <20151026165729.1798306454@mail.rogue-research.com> <20151026181334.GA11728@megas.khq.kitware.com> <20151111150032.1905614795@mail.rogue-research.com> Message-ID: <20151111185334.GA3519@megas.khq.kitware.com> On Wed, Nov 11, 2015 at 10:00:32 -0500, Sean McBride wrote: > I've renamed all my submissions accordingly. Most are OpenGL1 since > that's what we're currently using in our app. Can you update the > expected list please? Now I'll look at greening them up... Updated. Thanks, --Ben From will.schroeder at kitware.com Thu Nov 12 07:48:02 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 12 Nov 2015 07:48:02 -0500 Subject: [vtk-developers] Gentle introduction to vtkSMPTools and vision for parallel computing including VTK-m In-Reply-To: References: Message-ID: Work is continuing using vtkSMPTools and on VTK-m . Here is a another quick update focused on vtkSMPTools-related work. + vtkCheckerboardSplatter is in and I have not heard complaints so far. + vtkSpanSpace can be used to accelerated unstructured isocontouring. It builds the space in parallel. + vtkFlyingEdges3D/2D was presented at the recent LDAV workshop at IEEE Vis 2015. A draft of the paper is here . + We pushed a vtkFlyingEdgesPlaneCutter to process volumes. It is running ~30-40x faster than the previous vtkSynchronizedTemplatesCutter3D (when using my 8-thread Windows development laptop). + A new vtkStaticPointLocator has just been pushed (Merge Request #898). It's about 6-12x faster (to build the locator) than vtkPointLocator, and even faster if you take into account the cost to delete the locator instance (again on my 8-thread system and very large data). + There is a vtkSMPTools::Sort() available that is a drop-in replacement for std::sort. We are slowly adding and testing these classes/capabilities into VTK classes that use them; and major flagship applications like ParaView , Slicer , and TomViz . If you are not doing so already, we recommend that you start developing with threading in mind (using both vtkSMPTools and VTK-m which is ripening nicely BTW). Make sure to build optimized code as the templated C++ needs this to realize full performance. Also any feedback that you can provide regarding usage and issues is welcome. On the list for current and future development: + vtkCellDataToPointData + Variants of vtkFlyingEdgesPlaneCutter for other structured data forms + Variants of Flying Edges for: clipping and cutting structured data forms + Variants of Flying Edges for: vtkDiscreteMarchingCubes (i.e., contouring label maps, IMO one of the most useful and least publicized classes in VTK written by Bill Lorensen and Jim Miller.) + Faster quadric clustering + Threaded, unstructured grid contouring using vtkSpanSpace, etc. + Replacing std::sort() with vtkSMPTools::Sort() + vtkShepardMethod filter + Replacing vtkPointLocator with vtkStaticPointLocator where it makes sense (If anyone out there wants to tackle one of these over the holiday season I am happy to work with you. Give yourself and your loved ones the gift of coding :-)) Best, W On Sat, Jun 13, 2015 at 12:56 PM, David Gobbi wrote: > I grepped the code to see how many classes directly use the old > vtkMultiThreader for SMP. It's an amazingly small number, because > multithreading was nicely consolidated into base classes like > vtkThreadedImageAlgorithm and vtkStreamer: > > Common/ExecutionModel/vtkThreadedImageAlgorithm.cxx (base class) > Filters/FlowPaths/vtkStreamer.cxx (base class) > Filters/Hybrid/vtkImplicitModeller.cxx > Rendering/Core/vtkImageMapper3D.cxx > Rendering/Volume/vtkEncodedGradientEstimator.cxx (base class) > Rendering/Volume/vtkFixedPointVolumeRayCastMapper.cxx > Rendering/Volume/vtkUnstructuredGridVolumeRayCastMapper.cxx > Rendering/Volume/vtkVolumeRayCastMapper.cxx > > http://www.vtk.org/Wiki/VTK/Replacing_vtkMultiThreader_with_vtkSMPTools > > Our GSoC student has been doing a great job updating the > vtkThreadedImageAlgorithm to use vtkSMPTools. I'll tackle the ImageMapper, > since it's one of my own classes, and I might be able to take a look at the > implicit modeller. > > - David > > > On Sat, Jun 13, 2015 at 6:28 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> FYI- There is a lot of recent work going on in VTK to address parallel >> computing, ranging from multi-core, shared memory approaches (vtkSMPTools) >> to GPU's and co-processors (VTK-m), to rewriting algorithms for parallel >> computation. Here's a high-level introduction. >> >> http://www.kitware.com/blog/home/post/915 >> >> There's a ton of work to do so if you are interested let's start some >> threads (no pun intended) and coordinate our efforts. >> >> W >> > > -- William J. Schroeder, PhD Kitware, Inc. 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 xabivtk at gmail.com Thu Nov 12 08:33:52 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Thu, 12 Nov 2015 14:33:52 +0100 Subject: [vtk-developers] vtkImageData::GetDimensions not setting member variable anymore Message-ID: Hi, I see in the code of vtkImageData::GetDimensions(int dims[3]) that the "Dimensions" member variable is not computed anymore since commit 4345f286e7fbffe0d8734ade60824556cb1b3d3d , for thread safe reasons. I can understand the reason for this change if it can not be done otherway, but i think the documentation of the method should be updated, since it is curently : "Dimensions are computed from Extents during this call." It is true for the int *GetDimensions() implementation but not this one anymore. Cheers, Xabi -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Thu Nov 12 08:48:12 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 12 Nov 2015 08:48:12 -0500 Subject: [vtk-developers] vtkImageData::GetDimensions not setting member variable anymore In-Reply-To: References: Message-ID: That sounds reasonable to me. On Thu, Nov 12, 2015 at 8:33 AM, Xabi Riobe wrote: > Hi, > > I see in the code of vtkImageData::GetDimensions(int dims[3]) that the > "Dimensions" member variable is not computed anymore since commit > 4345f286e7fbffe0d8734ade60824556cb1b3d3d > , > for thread safe reasons. > > I can understand the reason for this change if it can not be done > otherway, but i think the documentation of the method should be updated, > since it is curently : > "Dimensions are computed from Extents during this call." > > It is true for the int *GetDimensions() implementation but not this one > anymore. > > Cheers, > Xabi > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Nov 12 11:16:22 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 12 Nov 2015 11:16:22 -0500 Subject: [vtk-developers] Python-related dashboard build errors with new clang Message-ID: <20151112161622.1274692523@mail.rogue-research.com> Hi all, A few days ago I updated clang on some of my buildbots and now get this: This seems to be because a Python header is doing an evil redefinition: /usr/include/python2.7/pyport.h:731:9: note: macro 'toupper' defined here #define toupper(c) towupper(btowc(c)) ^ My guess is toupper was a #define with older clang, and is now a function with newer clang. Googling finds this has been discussed years ago: I'm hoping one of you have seen this before or have some idea of how to fix it... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From joachim.pouderoux at kitware.com Thu Nov 12 11:33:21 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 12 Nov 2015 17:33:21 +0100 Subject: [vtk-developers] announce: Advanced VTK/ParaView Training - December 15 and 16, 2015, Lyon, France Message-ID: Kitware will be holding VTK and ParaView training courses respectively on December 15 and 16 in Lyon, France. Please visit our web site for more information and registration details at: VTK: http://training.kitware.fr/browse/92 ParaView: http://training.kitware.fr/browse/95 Note that the courses will be taught in English. If you have any question, please contact us at: formations at kitware.fr Thank you, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Nov 12 11:47:27 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 12 Nov 2015 11:47:27 -0500 Subject: [vtk-developers] heads up - vtk 7.0 branch is coming soon Message-ID: Hey everybody. We are getting ready to start the vtk 7 release cycle. The biggest new features in my mind are the switch over to the new OpenGL2 backend and the introduction of Python3 support. So, we are going to clean up the dashboards now and branch in about three weeks. If you are a developer who is striving to complete features that you need in the next release, please let us know on the vtkdev's list. If you are a user and some specific bug is bringing you down, please also let us know on the vtkusers's list. In either case if the feature is important and reachable we can hold of a week or two before branching. See you on the other side, David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Nov 12 11:50:25 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 12 Nov 2015 09:50:25 -0700 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: <20151112161622.1274692523@mail.rogue-research.com> References: <20151112161622.1274692523@mail.rogue-research.com> Message-ID: Hi Sean, I haven't seen it (still using Xcode 6.1), but I can guess at a fix. The VTK classes never include Python.h directly, they always include "vtkPython.h" which already has a bunch of fixes for issues like this one. To fix in vtkPython.h, an "#undef toupper" will have to be added after "#include " (with checks for the clang version). - David On Thu, Nov 12, 2015 at 9:16 AM, Sean McBride wrote: > Hi all, > > A few days ago I updated clang on some of my buildbots and now get this: > > > > This seems to be because a Python header is doing an evil redefinition: > > /usr/include/python2.7/pyport.h:731:9: note: macro 'toupper' defined here > #define toupper(c) towupper(btowc(c)) > ^ > > My guess is toupper was a #define with older clang, and is now a function > with newer clang. > > Googling finds this has been discussed years ago: > > > I'm hoping one of you have seen this before or have some idea of how to > fix it... > > Cheers, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Nov 12 12:02:41 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 12 Nov 2015 12:02:41 -0500 Subject: [vtk-developers] heads up - vtk 7.0 branch is coming soon In-Reply-To: References: Message-ID: <20151112170241.GA32578@megas.khq.kitware.com> On Thu, Nov 12, 2015 at 11:47:27 -0500, David E DeMarle wrote: > So, we are going to clean up the dashboards now and branch in about three > weeks. If you are a developer who is striving to complete features that you > need in the next release, please let us know on the vtkdev's list. If you > are a user and some specific bug is bringing you down, please also let us > know on the vtkusers's list. In either case if the feature is important and > reachable we can hold of a week or two before branching. For developers, there are also the milestone for merge requests in gitlab. I've bumped out the date to the 3rd of December. Please add branches you feel should go into VTK 7 to the milestone. --Ben From ben.boeckel at kitware.com Thu Nov 12 12:04:04 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 12 Nov 2015 12:04:04 -0500 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: References: <20151112161622.1274692523@mail.rogue-research.com> Message-ID: <20151112170404.GB32578@megas.khq.kitware.com> On Thu, Nov 12, 2015 at 09:50:25 -0700, David Gobbi wrote: > I haven't seen it (still using Xcode 6.1), but I can guess at a fix. > > The VTK classes never include Python.h directly, they always > include "vtkPython.h" which already has a bunch of fixes for > issues like this one. > > To fix in vtkPython.h, an "#undef toupper" will have to be added > after "#include " (with checks for the clang version). Why not just: #ifdef toupper #undef toupper #endif ? --Ben From simon.esneault at gmail.com Thu Nov 12 12:12:14 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Thu, 12 Nov 2015 18:12:14 +0100 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: Hello Aashish, Sorry for the late reply, I was busy last week. Thanks for the update, and your work on this topic. Yes I have seen that your change have been merged concerning the ReductionFactor. Nevertheless, I am still getting a smaller frame rate with the new backend. To highlight this, please find attached a very simple application that loads a volume ( https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does volume rendering while displaying the frame rate. This is pretty much what we show to the user in our application, and in this condition, on my machine the FPS are around 25 with the opengl1 backend , and 15 with the new backend , from this week VTK master It is very simple to test, just need change the VTK_DIR to an OpenGL1 or OpenGL2 build, and place the volume.mhd and raw in the execution path. Also you will find attached a small text file that summarizes the test that have been done here. I think the real reason why it appears slower with the OGL2 version is that we try to have control on the "MaximalImageSampleDistance". If I remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get the same frame rate with each backend. BUT, the new backend does decimate a lot more the volume, leading to a very blurred image during rendering, and that's not what we want :/ Again, thanks for paying attention to this problem, I hope this little application and test case can help you to adjust the parameters... Simon PS : I did not get a chance to check the difference on Paraview, but I believe the result will be the same as the attached example is really simple. 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary : > Hi Simon, > > the branch has been merged into VTK master. I am not sure when Paraview is > going to update the VTK, but you can do it manually if needed. We are also > going to run our bench marking again to be sure since recently lot many > changes went into the VTK / volume rendering. Please feel free to ping me > again if it does not solve your issue. > > Looking forward to your feedback. > > - Aashish > > On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> Hi Simon, >> >> I found the reason behind the appeared performance you were getting. We >> have this code in volume rendering that when you interact changes the >> sampling distance and in the newer code we were too conservative compare to >> the last version. That's why you were getting better quality when you move >> your mouse but lower frame rates. I pushed a branch in VTK to address the >> issue. Would it be possible for you to build Paraview with VTK master? It >> may take 3-4 days or longer for Paraview's VTK to get updated. >> >> Thanks, >> Aashish >> >> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >> aashish.chaudhary at kitware.com> wrote: >> >>> Hi Simon, >>> >>> I am just finishing up a ParaView5 related parallel volume rendering bug >>> (pushing a branch today to VTK). This is next on my list. >>> >>> - Aashish >>> >>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Hello Aashish >>>> >>>> Did you get a chance to try to load the dataset on Windows ? >>>> Can I do anything to help you investigate ? Should I feel a bug, that >>>> may act as a reminder ? >>>> Have a nice day >>>> Simon >>>> >>>> >>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> Thanks Simon. This is really strange since we are not seeing it on Mac >>>>> and Linux (but both has dedicated cards). >>>>> >>>>> I will look into it soon. >>>>> >>>>> - aashish >>>>> >>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> Ok, thank you very much fort digging into this. >>>>>> I've done some test and I believe I can see a similar slowdown >>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>> graphics. >>>>>> Good luck in the investigation, I you need more details, do not >>>>>> hesitate to ask >>>>>> Simon >>>>>> >>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> Ah, thanks. I will get back to you on this since on Linux I don't >>>>>>> any issue so it has to be Windows specific thing. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> I tried with that one from yesterday and today's version >>>>>>>> (4.4.0-209-gc399648) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Simon >>>>>>>> >>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> And when did you download this version? >>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Aashish >>>>>>>>> >>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>> version seems even bigger. >>>>>>>>>> I got the version from the nightly build download section of >>>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>> results. >>>>>>>>>> >>>>>>>>>> About the FPS, it is difficult to give an exact number, because >>>>>>>>>> it depends of the condition (zoomed or not etc...) but yes, this is the >>>>>>>>>> idea. >>>>>>>>>> In our software, I've exposed the frame rate using this example : >>>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>>>> example), with the same mapper parameters >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>> >>>>>>>>>>> Hi Simon, >>>>>>>>>>> >>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>> >>>>>>>>>>> 1) Did you try without the shading and see how the performance >>>>>>>>>>> compares? >>>>>>>>>>> >>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this one >>>>>>>>>>> from (ParaView download page or did you built yourself?) >>>>>>>>>>> >>>>>>>>>>> Also, so on your system the old mapper is running 30FPS and the >>>>>>>>>>> new one at 15-20 FPS as per your summary. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> - Aashish >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>> The two tested version are : >>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 backend. >>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and Nvidia >>>>>>>>>>>> Quadro K420 >>>>>>>>>>>> >>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>> >>>>>>>>>>>> And start interacting ... >>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate in >>>>>>>>>>>> Paraview, but the new version seems really twice slower in these >>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>> interactivity is better. >>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>> >>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play with >>>>>>>>>>>> this with the old backend to fine tune the interactivity, although what's >>>>>>>>>>>> really inside was never clear to me >>>>>>>>>>>> >>>>>>>>>>>> I hope that there is enough information for you to reproduce >>>>>>>>>>>> this, do not hesitate to ask for some more information. >>>>>>>>>>>> >>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>> >>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>> >>>>>>>>>>>>> Checking again. Wondering if you can provide some more detail >>>>>>>>>>>>> on the binary you are using and whether or not without shading the >>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I used your dataset on paraview master as of today on my >>>>>>>>>>>>>> Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about >>>>>>>>>>>>>> 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>>>> >>>>>>>>>>>>>> NOTE: You might get multiple emails because of the attachment >>>>>>>>>>>>>> size issue. Sorry about that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short element >>>>>>>>>>>>>>>> (you can find the dataset here : >>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). So >>>>>>>>>>>>>>>> I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when compared >>>>>>>>>>>>>>>> to the old one, it seems less "low resolution" during interaction than the >>>>>>>>>>>>>>>> old one >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe the >>>>>>>>>>>>>>>> GPURenderDemo used with this dataset is enough to highlight the slow down. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with shading >>>>>>>>>>>>>>>>> that was causing the slow performance a while back. I don't remember if >>>>>>>>>>>>>>>>> that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the data >>>>>>>>>>>>>>>>>> type you might be using >>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The performance >>>>>>>>>>>>>>>>>> we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you compare >>>>>>>>>>>>>>>>>>> the latest 4.4 OpenGL2 build with the classic 4.4 build while volume >>>>>>>>>>>>>>>>>>> rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering implementation >>>>>>>>>>>>>>>>>>> should be faster than the old one, is there some more detailed explanation >>>>>>>>>>>>>>>>>>> somewhere ? Are there some important parameters that can make the >>>>>>>>>>>>>>>>>>> difference ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with the >>>>>>>>>>>>>>>>>>> new backend ! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>> * >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>> Inc. * >>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> Simon Esneault >>>>>>>>>>>> Rennes, France >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>> * >>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required( VERSION 2.8.5 FATAL_ERROR ) project( VolumeRenderingBenchmark ) find_package( VTK REQUIRED ) include( ${VTK_USE_FILE} ) if( VTK_RENDERING_BACKEND STREQUAL "OpenGL2" ) message( STATUS "Using new OpenGL2 backend" ) add_definitions( -DVTK_WAS_BUILT_WITH_OPENGL2 ) else() message( STATUS "Using old OpenGL1 backend" ) endif() add_executable( VolumeRenderingBenchmark MACOSX_BUNDLE VolumeRenderingBenchmark.cxx ) target_link_libraries( VolumeRenderingBenchmark ${VTK_LIBRARIES} ) -------------- next part -------------- #include "vtkCallbackCommand.h" #include "vtkCamera.h" #include "vtkColorTransferFunction.h" #include "vtkGPUVolumeRaycastMapper.h" #include "vtkImageData.h" #include "vtkImageResample.h" #include "vtkInteractorStyle.h" #include "vtkInteractorStyleTrackballCamera.h" #include "vtkMath.h" #include "vtkMetaImageReader.h" #include "vtkPiecewiseFunction.h" #include "vtkRenderWindow.h" #include "vtkRenderWindowInteractor.h" #include "vtkRenderer.h" #include "vtkTextActor.h" #include "vtkTextProperty.h" #include "vtkVolume.h" #include "vtkVolumeProperty.h" #include #include // Helper class for the FPS callback class vtkFPSCallback : public vtkCommand{ protected: vtkTextActor* m_fps_text_actor; std::vector m_vec_fps; std::vector m_vec_total_fps; double m_fps; public: static vtkFPSCallback *New(){ return new vtkFPSCallback; } vtkFPSCallback() : m_fps( 0. ){} void SetTextActor( vtkTextActor* a_actor ){ m_fps_text_actor = a_actor; } void Execute( vtkObject* a_caller, unsigned long vtkNotUsed( a_event ), void *a_call_data ){ vtkRenderer* l_renderer = static_cast( a_caller ); double l_time = l_renderer->GetLastRenderTimeInSeconds(); double l_fps = static_cast( 1.0 / l_time ); m_vec_fps.push_back( l_fps ); m_vec_total_fps.push_back( l_fps ); if( m_vec_fps.size() == 10 ){ // compute mean m_fps = std::accumulate( m_vec_fps.begin(), m_vec_fps.end(), 0. ) / 10.; // manual round m_fps = (double)( (int)( m_fps*100. ) ) / 100.; m_vec_fps.clear(); } std::ostringstream l_oss; #ifdef VTK_WAS_BUILT_WITH_OPENGL2 l_oss << "OpenGL2 : "; #else l_oss << "OpenGL1 : "; #endif l_oss << m_fps; l_oss << " FPS"; m_fps_text_actor->SetInput( l_oss.str().c_str() ); } double getMeanFPS(){ return std::accumulate( m_vec_total_fps.begin(), m_vec_total_fps.end(), 0. ) / m_vec_total_fps.size(); } }; int main( int argc, char *argv[] ){ // Read volume vtkMetaImageReader* l_reader = vtkMetaImageReader::New(); l_reader->SetFileName( "volume.mhd" ); l_reader->Update(); // reduce to 80 Megavoxels double l_nb_voxels = l_reader->GetOutput()->GetNumberOfPoints(); double l_target = 80000000; double l_ratio = std::pow( l_target / l_nb_voxels, 1. / 3. ); vtkImageResample* l_resample = vtkImageResample::New(); l_resample->SetInputConnection( l_reader->GetOutputPort() ); l_resample->SetInterpolationModeToLinear(); for( int i = 0; i < 3; i++ ) l_resample->SetAxisMagnificationFactor( i, l_ratio ); // Setup rendering stuff vtkRenderer* l_renderer = vtkRenderer::New(); l_renderer->SetBackground( 0.3, 0.3, 0.3 ); vtkRenderWindow* l_render_windows = vtkRenderWindow::New(); l_render_windows->AddRenderer( l_renderer ); l_render_windows->SetSize( 900, 900 ); vtkInteractorStyleTrackballCamera* l_trackball = vtkInteractorStyleTrackballCamera::New(); vtkRenderWindowInteractor* l_iren = vtkRenderWindowInteractor::New(); l_iren->SetInteractorStyle( l_trackball ); l_iren->SetRenderWindow( l_render_windows ); l_iren->GetInteractorStyle()->SetDefaultRenderer( l_renderer ); l_iren->SetDesiredUpdateRate( 25 ); // Make sure we have an opengl context l_render_windows->Render(); // Setup GPU volume raycast mapper vtkGPUVolumeRayCastMapper* l_gpu_mapper = vtkGPUVolumeRayCastMapper::New(); l_gpu_mapper->SetMaxMemoryInBytes( std::pow( 1024, 3 ) ); l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); l_gpu_mapper->SetInputConnection( l_resample->GetOutputPort() ); // Setup Volume property // Window/Level double wl = 260; double ww = 270; // Color function vtkColorTransferFunction* l_color = vtkColorTransferFunction::New(); l_color->SetColorSpaceToRGB(); l_color->AddRGBPoint( wl - ww / 2, 0, 0, 0 ); l_color->AddRGBPoint( wl - ww / 2 + 94 * ( ww / 255.0 ), 1., 21. / 255.0, 27. / 255.0 ); l_color->AddRGBPoint( wl - ww / 2 + 147 * ( ww / 255.0 ), 1., 176. / 255.0, 9. / 255.0 ); l_color->AddRGBPoint( wl - ww / 2 + 201 * ( ww / 255.0 ), 1., 241. / 255.0, 39. / 255.0 ); l_color->AddRGBPoint( wl - ww / 2 + 255 * ( ww / 255.0 ), 1, 1, 1. ); l_color->Build(); // Opacity function vtkPiecewiseFunction* l_opacity = vtkPiecewiseFunction::New(); l_opacity->AddPoint( wl - ww / 2, 0 ); l_opacity->AddPoint( wl + ww / 2, 1 ); // Volume property, light, shading vtkVolumeProperty* l_volume_property = vtkVolumeProperty::New(); l_volume_property->SetColor( l_color ); l_volume_property->SetScalarOpacity( l_opacity ); l_volume_property->SetInterpolationTypeToLinear(); l_volume_property->ShadeOn(); l_volume_property->SetAmbient( 0.15 ); l_volume_property->SetDiffuse( 0.8 ); l_volume_property->SetSpecular( 0.25 ); l_volume_property->SetSpecularPower( 40 ); // Put everything together vtkVolume* l_volume = vtkVolume::New(); l_volume->SetProperty( l_volume_property ); l_volume->SetMapper( l_gpu_mapper ); // setup text actor : vtkTextActor* l_text_actor = vtkTextActor::New(); l_text_actor->GetPositionCoordinate()->SetCoordinateSystemToNormalizedViewport(); l_text_actor->GetPositionCoordinate()->SetValue( 0.01, 0.99 ); l_text_actor->GetTextProperty()->SetJustificationToLeft(); l_text_actor->GetTextProperty()->SetVerticalJustificationToTop(); l_text_actor->GetTextProperty()->SetFontSize( 17 ); #ifdef VTK_WAS_BUILT_WITH_OPENGL2 l_text_actor->SetInput( "OpenGL2 : 0 FPS" ); #else l_text_actor->SetInput( "OpenGL1 : 0 FPS" ); #endif l_renderer->AddActor( l_text_actor ); // setup fps callback vtkFPSCallback* l_callback = vtkFPSCallback::New(); l_callback->SetTextActor( l_text_actor ); l_renderer->AddObserver( vtkCommand::EndEvent, l_callback ); l_renderer->AddVolume( l_volume ); // Adjust camera position l_renderer->GetActiveCamera()->SetParallelProjection( false ); l_renderer->GetActiveCamera()->SetViewUp( 0, 0, 1 ); double l_distance = 1000; double l_center[ 3 ], l_pos[3]; l_reader->GetOutput()->GetCenter( l_center ); l_reader->GetOutput()->GetCenter( l_pos ); l_pos[ 1 ] -= l_distance; double l_cam_angle = atan( ( l_center[ 2 ] * 2. ) / ( l_distance * 2. ) ) * 360.0 / vtkMath::Pi(); l_renderer->GetActiveCamera()->SetFocalPoint( l_center ); l_renderer->GetActiveCamera()->SetPosition( l_pos ); l_renderer->GetActiveCamera()->SetViewAngle( l_cam_angle + 1 ); l_renderer->GetActiveCamera()->SetClippingRange( 0.01, 10000 ); // Go rendering ! l_iren->Start(); std::cout << l_callback->getMeanFPS() << std::endl; // Memory cleanup l_reader->Delete(); l_resample->Delete(); l_renderer->Delete(); l_render_windows->Delete(); l_trackball->Delete(); l_iren->Delete(); l_gpu_mapper->Delete(); l_color->Delete(); l_opacity->Delete(); l_volume_property->Delete(); l_volume->Delete(); l_text_actor->Delete(); l_callback->Delete(); } -------------- next part -------------- Benchmark results with MaximumImageSample set to 2.0 Windows 7 | Xeon E3-1220 | 16GB RAM | Nvidia Quadro K420 - OGL1: 25.29 FPS - OGL2: 12.36 FPS Windows 7 | Xeon X5690 | 48GB RAM | NVidia Quadro K620 - OGL1: 26.46 FPS - OGL2: 29.50 FPS From david.gobbi at gmail.com Thu Nov 12 12:17:05 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 12 Nov 2015 10:17:05 -0700 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: <20151112170404.GB32578@megas.khq.kitware.com> References: <20151112161622.1274692523@mail.rogue-research.com> <20151112170404.GB32578@megas.khq.kitware.com> Message-ID: On Thu, Nov 12, 2015 at 10:04 AM, Ben Boeckel wrote: > On Thu, Nov 12, 2015 at 09:50:25 -0700, David Gobbi wrote: > > I haven't seen it (still using Xcode 6.1), but I can guess at a fix. > > > > The VTK classes never include Python.h directly, they always > > include "vtkPython.h" which already has a bunch of fixes for > > issues like this one. > > > > To fix in vtkPython.h, an "#undef toupper" will have to be added > > after "#include " (with checks for the clang version). > > Why not just: > > #ifdef toupper > #undef toupper > #endif The python devs were nice enough to let us know exactly when they do the #define: // undo the "#define toupper" in pyport.h #ifdef _PY_PORT_CTYPE_UTF8_ISSUE #undef toupper #endif - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Nov 12 12:20:20 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 12 Nov 2015 10:20:20 -0700 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: References: <20151112161622.1274692523@mail.rogue-research.com> <20151112170404.GB32578@megas.khq.kitware.com> Message-ID: On Thu, Nov 12, 2015 at 10:17 AM, David Gobbi wrote: > On Thu, Nov 12, 2015 at 10:04 AM, Ben Boeckel > wrote: > >> On Thu, Nov 12, 2015 at 09:50:25 -0700, David Gobbi wrote: >> > I haven't seen it (still using Xcode 6.1), but I can guess at a fix. >> > >> > The VTK classes never include Python.h directly, they always >> > include "vtkPython.h" which already has a bunch of fixes for >> > issues like this one. >> > >> > To fix in vtkPython.h, an "#undef toupper" will have to be added >> > after "#include " (with checks for the clang version). >> >> Why not just: >> >> #ifdef toupper >> #undef toupper >> #endif > > > The python devs were nice enough to let us know exactly when they > do the #define: > > // undo the "#define toupper" in pyport.h > #ifdef _PY_PORT_CTYPE_UTF8_ISSUE > #undef toupper > #endif > Actually all of these should be undef'd: // undo some macro defs in pyport.h #ifdef _PY_PORT_CTYPE_UTF8_ISSUE #undef isalnum #undef isalpha #undef islower #undef isspace #undef isupper #undef tolower #undef toupper #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Thu Nov 12 12:31:05 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Thu, 12 Nov 2015 12:31:05 -0500 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: On Thu, Nov 12, 2015 at 12:12 PM, Simon ESNEAULT wrote: > Hello Aashish, > > Sorry for the late reply, I was busy last week. > > Thanks for the update, and your work on this topic. > Yes I have seen that your change have been merged concerning the > ReductionFactor. Nevertheless, I am still getting a smaller frame rate with > the new backend. To highlight this, please find attached a very simple > application that loads a volume ( > https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does volume > rendering while displaying the frame rate. This is pretty much what we show > to the user in our application, and in this condition, on my machine the > FPS are around 25 with the opengl1 backend > , and 15 with the new > backend , from this > week VTK master > It is very simple to test, just need change the VTK_DIR to an OpenGL1 or > OpenGL2 build, and place the volume.mhd and raw in the execution path. > Also you will find attached a small text file that summarizes the test > that have been done here. > No problem, thanks for the update. Please see my comments below: > > I think the real reason why it appears slower with the OGL2 version is > that we try to have control on the "MaximalImageSampleDistance". If I > remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get > the same frame rate with each backend. BUT, the new backend does decimate a > lot more the volume, leading to a very blurred image during rendering, and > that's not what we want :/ > Aha, this is very useful since this parameters does affecting the reduction factor. I will try your code; one quick question when the new backend decimates a lot (by removing the SetMaximumImageSampleDistance), does it get any faster than the old version? I am going to try it on my Mac and Linux laptop and report back (mostly tomorrow since I am away today). > > Again, thanks for paying attention to this problem, I hope this little > application and test case can help you to adjust the parameters... > Thanks for your help. I am glad you are testing my latest changes. - Best, Aashish > > > Simon > > PS : I did not get a chance to check the difference on Paraview, but I > believe the result will be the same as the attached example is really > simple. > > 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> Hi Simon, >> >> the branch has been merged into VTK master. I am not sure when Paraview >> is going to update the VTK, but you can do it manually if needed. We are >> also going to run our bench marking again to be sure since recently lot >> many changes went into the VTK / volume rendering. Please feel free to ping >> me again if it does not solve your issue. >> >> Looking forward to your feedback. >> >> - Aashish >> >> On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < >> aashish.chaudhary at kitware.com> wrote: >> >>> Hi Simon, >>> >>> I found the reason behind the appeared performance you were getting. We >>> have this code in volume rendering that when you interact changes the >>> sampling distance and in the newer code we were too conservative compare to >>> the last version. That's why you were getting better quality when you move >>> your mouse but lower frame rates. I pushed a branch in VTK to address the >>> issue. Would it be possible for you to build Paraview with VTK master? It >>> may take 3-4 days or longer for Paraview's VTK to get updated. >>> >>> Thanks, >>> Aashish >>> >>> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >>> aashish.chaudhary at kitware.com> wrote: >>> >>>> Hi Simon, >>>> >>>> I am just finishing up a ParaView5 related parallel volume rendering >>>> bug (pushing a branch today to VTK). This is next on my list. >>>> >>>> - Aashish >>>> >>>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Hello Aashish >>>>> >>>>> Did you get a chance to try to load the dataset on Windows ? >>>>> Can I do anything to help you investigate ? Should I feel a bug, that >>>>> may act as a reminder ? >>>>> Have a nice day >>>>> Simon >>>>> >>>>> >>>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> Thanks Simon. This is really strange since we are not seeing it on >>>>>> Mac and Linux (but both has dedicated cards). >>>>>> >>>>>> I will look into it soon. >>>>>> >>>>>> - aashish >>>>>> >>>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> Ok, thank you very much fort digging into this. >>>>>>> I've done some test and I believe I can see a similar slowdown >>>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>>> graphics. >>>>>>> Good luck in the investigation, I you need more details, do not >>>>>>> hesitate to ask >>>>>>> Simon >>>>>>> >>>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com>: >>>>>>> >>>>>>>> Ah, thanks. I will get back to you on this since on Linux I don't >>>>>>>> any issue so it has to be Windows specific thing. >>>>>>>> >>>>>>>> - Aashish >>>>>>>> >>>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> I tried with that one from yesterday and today's version >>>>>>>>> (4.4.0-209-gc399648) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> And when did you download this version? >>>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Aashish >>>>>>>>>> >>>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>>> version seems even bigger. >>>>>>>>>>> I got the version from the nightly build download section of >>>>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>>> results. >>>>>>>>>>> >>>>>>>>>>> About the FPS, it is difficult to give an exact number, because >>>>>>>>>>> it depends of the condition (zoomed or not etc...) but yes, this is the >>>>>>>>>>> idea. >>>>>>>>>>> In our software, I've exposed the frame rate using this example >>>>>>>>>>> : http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>>>>> example), with the same mapper parameters >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>> >>>>>>>>>>>> Hi Simon, >>>>>>>>>>>> >>>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>>> >>>>>>>>>>>> 1) Did you try without the shading and see how the performance >>>>>>>>>>>> compares? >>>>>>>>>>>> >>>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this one >>>>>>>>>>>> from (ParaView download page or did you built yourself?) >>>>>>>>>>>> >>>>>>>>>>>> Also, so on your system the old mapper is running 30FPS and the >>>>>>>>>>>> new one at 15-20 FPS as per your summary. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> - Aashish >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>>> The two tested version are : >>>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 backend. >>>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and Nvidia >>>>>>>>>>>>> Quadro K420 >>>>>>>>>>>>> >>>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>>> >>>>>>>>>>>>> And start interacting ... >>>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate in >>>>>>>>>>>>> Paraview, but the new version seems really twice slower in these >>>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>>> interactivity is better. >>>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>>> >>>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play with >>>>>>>>>>>>> this with the old backend to fine tune the interactivity, although what's >>>>>>>>>>>>> really inside was never clear to me >>>>>>>>>>>>> >>>>>>>>>>>>> I hope that there is enough information for you to reproduce >>>>>>>>>>>>> this, do not hesitate to ask for some more information. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>>> Simon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Checking again. Wondering if you can provide some more detail >>>>>>>>>>>>>> on the binary you are using and whether or not without shading the >>>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I used your dataset on paraview master as of today on my >>>>>>>>>>>>>>> Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about >>>>>>>>>>>>>>> 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NOTE: You might get multiple emails because of the >>>>>>>>>>>>>>> attachment size issue. Sorry about that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short >>>>>>>>>>>>>>>>> element (you can find the dataset here : >>>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). So >>>>>>>>>>>>>>>>> I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when >>>>>>>>>>>>>>>>> compared to the old one, it seems less "low resolution" during interaction >>>>>>>>>>>>>>>>> than the old one >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe >>>>>>>>>>>>>>>>> the GPURenderDemo used with this dataset is enough to highlight the slow >>>>>>>>>>>>>>>>> down. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with shading >>>>>>>>>>>>>>>>>> that was causing the slow performance a while back. I don't remember if >>>>>>>>>>>>>>>>>> that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the >>>>>>>>>>>>>>>>>>> data type you might be using >>>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The >>>>>>>>>>>>>>>>>>> performance we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you compare >>>>>>>>>>>>>>>>>>>> the latest 4.4 OpenGL2 build with the classic 4.4 build while volume >>>>>>>>>>>>>>>>>>>> rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering implementation >>>>>>>>>>>>>>>>>>>> should be faster than the old one, is there some more detailed explanation >>>>>>>>>>>>>>>>>>>> somewhere ? Are there some important parameters that can make the >>>>>>>>>>>>>>>>>>>> difference ? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with >>>>>>>>>>>>>>>>>>>> the new backend ! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>> * >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>>> * >>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>> * >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> Simon Esneault >>>>>>>>>>> Rennes, France >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>> * >>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>> * >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Thu Nov 12 12:34:29 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Thu, 12 Nov 2015 12:34:29 -0500 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: On Thu, Nov 12, 2015 at 12:31 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > > > On Thu, Nov 12, 2015 at 12:12 PM, Simon ESNEAULT > wrote: > >> Hello Aashish, >> >> Sorry for the late reply, I was busy last week. >> >> Thanks for the update, and your work on this topic. >> Yes I have seen that your change have been merged concerning the >> ReductionFactor. Nevertheless, I am still getting a smaller frame rate with >> the new backend. To highlight this, please find attached a very simple >> application that loads a volume ( >> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does volume >> rendering while displaying the frame rate. This is pretty much what we show >> to the user in our application, and in this condition, on my machine the >> FPS are around 25 with the opengl1 backend >> , and 15 with the >> new backend , from >> this week VTK master >> It is very simple to test, just need change the VTK_DIR to an OpenGL1 or >> OpenGL2 build, and place the volume.mhd and raw in the execution path. >> Also you will find attached a small text file that summarizes the test >> that have been done here. >> > > No problem, thanks for the update. Please see my comments below: > >> >> I think the real reason why it appears slower with the OGL2 version is >> that we try to have control on the "MaximalImageSampleDistance". If I >> remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get >> the same frame rate with each backend. BUT, the new backend does decimate a >> lot more the volume, leading to a very blurred image during rendering, and >> that's not what we want :/ >> > > Aha, this is very useful since this parameters does affecting the > reduction factor. I will try your code; one quick question when the new > backend decimates a lot (by removing the SetMaximumImageSampleDistance), > does it get any faster than the old version? I am going to try it on my Mac > and Linux laptop and report back (mostly tomorrow since I am away today). > >> >> Never mind, I see that you have that in your result file. It seems it does get faster but more blurry. Would it be possible for you to do one more test? Can you set a fix sample distance (pick any) for new and the old mapper and set AutoAdjustSampleDistance to OFF and capture some performance numbers? In that way we know exactly if something more fundamental is causing the slowness. The whole reduction factor math is based on approximate stuff so that will vary between two mappers. - Aashish > Again, thanks for paying attention to this problem, I hope this little >> application and test case can help you to adjust the parameters... >> > > Thanks for your help. I am glad you are testing my latest changes. > > - Best, Aashish > >> >> >> Simon >> >> PS : I did not get a chance to check the difference on Paraview, but I >> believe the result will be the same as the attached example is really >> simple. >> >> 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> Hi Simon, >>> >>> the branch has been merged into VTK master. I am not sure when Paraview >>> is going to update the VTK, but you can do it manually if needed. We are >>> also going to run our bench marking again to be sure since recently lot >>> many changes went into the VTK / volume rendering. Please feel free to ping >>> me again if it does not solve your issue. >>> >>> Looking forward to your feedback. >>> >>> - Aashish >>> >>> On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < >>> aashish.chaudhary at kitware.com> wrote: >>> >>>> Hi Simon, >>>> >>>> I found the reason behind the appeared performance you were getting. We >>>> have this code in volume rendering that when you interact changes the >>>> sampling distance and in the newer code we were too conservative compare to >>>> the last version. That's why you were getting better quality when you move >>>> your mouse but lower frame rates. I pushed a branch in VTK to address the >>>> issue. Would it be possible for you to build Paraview with VTK master? It >>>> may take 3-4 days or longer for Paraview's VTK to get updated. >>>> >>>> Thanks, >>>> Aashish >>>> >>>> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com> wrote: >>>> >>>>> Hi Simon, >>>>> >>>>> I am just finishing up a ParaView5 related parallel volume rendering >>>>> bug (pushing a branch today to VTK). This is next on my list. >>>>> >>>>> - Aashish >>>>> >>>>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> Hello Aashish >>>>>> >>>>>> Did you get a chance to try to load the dataset on Windows ? >>>>>> Can I do anything to help you investigate ? Should I feel a bug, that >>>>>> may act as a reminder ? >>>>>> Have a nice day >>>>>> Simon >>>>>> >>>>>> >>>>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> Thanks Simon. This is really strange since we are not seeing it on >>>>>>> Mac and Linux (but both has dedicated cards). >>>>>>> >>>>>>> I will look into it soon. >>>>>>> >>>>>>> - aashish >>>>>>> >>>>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> Ok, thank you very much fort digging into this. >>>>>>>> I've done some test and I believe I can see a similar slowdown >>>>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>>>> graphics. >>>>>>>> Good luck in the investigation, I you need more details, do not >>>>>>>> hesitate to ask >>>>>>>> Simon >>>>>>>> >>>>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>> >>>>>>>>> Ah, thanks. I will get back to you on this since on Linux I don't >>>>>>>>> any issue so it has to be Windows specific thing. >>>>>>>>> >>>>>>>>> - Aashish >>>>>>>>> >>>>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I tried with that one from yesterday and today's version >>>>>>>>>> (4.4.0-209-gc399648) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> And when did you download this version? >>>>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Aashish >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>>>> version seems even bigger. >>>>>>>>>>>> I got the version from the nightly build download section of >>>>>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>>>> results. >>>>>>>>>>>> >>>>>>>>>>>> About the FPS, it is difficult to give an exact number, because >>>>>>>>>>>> it depends of the condition (zoomed or not etc...) but yes, this is the >>>>>>>>>>>> idea. >>>>>>>>>>>> In our software, I've exposed the frame rate using this example >>>>>>>>>>>> : http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>>>>>> example), with the same mapper parameters >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>> >>>>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Did you try without the shading and see how the performance >>>>>>>>>>>>> compares? >>>>>>>>>>>>> >>>>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this one >>>>>>>>>>>>> from (ParaView download page or did you built yourself?) >>>>>>>>>>>>> >>>>>>>>>>>>> Also, so on your system the old mapper is running 30FPS and >>>>>>>>>>>>> the new one at 15-20 FPS as per your summary. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> - Aashish >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>>>> The two tested version are : >>>>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 >>>>>>>>>>>>>> backend. >>>>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and Nvidia >>>>>>>>>>>>>> Quadro K420 >>>>>>>>>>>>>> >>>>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>>>> >>>>>>>>>>>>>> And start interacting ... >>>>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate in >>>>>>>>>>>>>> Paraview, but the new version seems really twice slower in these >>>>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>>>> interactivity is better. >>>>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play with >>>>>>>>>>>>>> this with the old backend to fine tune the interactivity, although what's >>>>>>>>>>>>>> really inside was never clear to me >>>>>>>>>>>>>> >>>>>>>>>>>>>> I hope that there is enough information for you to reproduce >>>>>>>>>>>>>> this, do not hesitate to ask for some more information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>>>> Simon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Checking again. Wondering if you can provide some more >>>>>>>>>>>>>>> detail on the binary you are using and whether or not without shading the >>>>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I used your dataset on paraview master as of today on my >>>>>>>>>>>>>>>> Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about >>>>>>>>>>>>>>>> 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> NOTE: You might get multiple emails because of the >>>>>>>>>>>>>>>> attachment size issue. Sorry about that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short >>>>>>>>>>>>>>>>>> element (you can find the dataset here : >>>>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). >>>>>>>>>>>>>>>>>> So I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when >>>>>>>>>>>>>>>>>> compared to the old one, it seems less "low resolution" during interaction >>>>>>>>>>>>>>>>>> than the old one >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe >>>>>>>>>>>>>>>>>> the GPURenderDemo used with this dataset is enough to highlight the slow >>>>>>>>>>>>>>>>>> down. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with shading >>>>>>>>>>>>>>>>>>> that was causing the slow performance a while back. I don't remember if >>>>>>>>>>>>>>>>>>> that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the >>>>>>>>>>>>>>>>>>>> data type you might be using >>>>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The >>>>>>>>>>>>>>>>>>>> performance we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you compare >>>>>>>>>>>>>>>>>>>>> the latest 4.4 OpenGL2 build with the classic 4.4 build while volume >>>>>>>>>>>>>>>>>>>>> rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering >>>>>>>>>>>>>>>>>>>>> implementation should be faster than the old one, is there some more >>>>>>>>>>>>>>>>>>>>> detailed explanation somewhere ? Are there some important parameters that >>>>>>>>>>>>>>>>>>>>> can make the difference ? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with >>>>>>>>>>>>>>>>>>>>> the new backend ! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>> Inc. * >>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> Simon Esneault >>>>>>>>>>>> Rennes, France >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>> * >>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Nov 12 12:43:32 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 12 Nov 2015 12:43:32 -0500 Subject: [vtk-developers] vtkDepthSortPolyData modernization In-Reply-To: <56437525.8040107@gmail.com> References: <56437525.8040107@gmail.com> Message-ID: Hi Burlen, We are quite swamped by SC preparations this week. I'll be happy to take a look after SC. Best, -berk On Wed, Nov 11, 2015 at 12:04 PM, Burlen Loring wrote: > Hi All, > > Would anyone be willing to review this patch? > https://gitlab.kitware.com/vtk/vtk/merge_requests/844 > > I was profiling VisIt and noticed that vtkDepthSortPolyData (in spite of > its limitations it is used by VisIt for transparent rendering) made use of > qsort and about 1/2 the time was spent by qsort. std::sort is known to be > faster because of the possibility of the compiler to inline the > comparisons. Updating qsort to std::sort seemed like an easy way to make it > faster. As I worked the profiler pointed out a number of other fairly easy > things to improve and overall the class is now ~3x faster for two of the > modes and ~2x faster for the other. I enumerated the changes in the commit > message and have added a cxx test to improve the test coverage. > > If you have the time, please take a look, and let me know if you have any > feedback on it. > > Thanks > Burlen > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 burlen.loring at gmail.com Thu Nov 12 13:09:29 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Thu, 12 Nov 2015 10:09:29 -0800 Subject: [vtk-developers] vtkDepthSortPolyData modernization In-Reply-To: References: <56437525.8040107@gmail.com> Message-ID: <5644D5D9.6000404@gmail.com> Hi Berk, Thanks & have a good trip. Burlen On 11/12/2015 09:43 AM, Berk Geveci wrote: > Hi Burlen, > > We are quite swamped by SC preparations this week. I'll be happy to > take a look after SC. > > Best, > -berk > > On Wed, Nov 11, 2015 at 12:04 PM, Burlen Loring > > wrote: > > Hi All, > > Would anyone be willing to review this patch? > https://gitlab.kitware.com/vtk/vtk/merge_requests/844 > > I was profiling VisIt and noticed that vtkDepthSortPolyData (in > spite of its limitations it is used by VisIt for transparent > rendering) made use of qsort and about 1/2 the time was spent by > qsort. std::sort is known to be faster because of the possibility > of the compiler to inline the comparisons. Updating qsort to > std::sort seemed like an easy way to make it faster. As I worked > the profiler pointed out a number of other fairly easy things to > improve and overall the class is now ~3x faster for two of the > modes and ~2x faster for the other. I enumerated the changes in > the commit message and have added a cxx test to improve the test > coverage. > > If you have the time, please take a look, and let me know if you > have any feedback on it. > > Thanks > Burlen > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 will.schroeder at kitware.com Thu Nov 12 13:20:10 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 12 Nov 2015 13:20:10 -0500 Subject: [vtk-developers] vtkDepthSortPolyData modernization In-Reply-To: <56437525.8040107@gmail.com> References: <56437525.8040107@gmail.com> Message-ID: Burlen I would use vtkSMPTools::Sort(). Under the hood it uses std::sort when VTK is built in VTK_SMP_IMPLEMENTATION_TYPE=Sequential mode (default). But when built with VTK_SMP_IMPLEMENTATION_TYPE=TBB, etc. you'll see significant parallelization benefits. W On Wed, Nov 11, 2015 at 12:04 PM, Burlen Loring wrote: > Hi All, > > Would anyone be willing to review this patch? > https://gitlab.kitware.com/vtk/vtk/merge_requests/844 > > I was profiling VisIt and noticed that vtkDepthSortPolyData (in spite of > its limitations it is used by VisIt for transparent rendering) made use of > qsort and about 1/2 the time was spent by qsort. std::sort is known to be > faster because of the possibility of the compiler to inline the > comparisons. Updating qsort to std::sort seemed like an easy way to make it > faster. As I worked the profiler pointed out a number of other fairly easy > things to improve and overall the class is now ~3x faster for two of the > modes and ~2x faster for the other. I enumerated the changes in the commit > message and have added a cxx test to improve the test coverage. > > If you have the time, please take a look, and let me know if you have any > feedback on it. > > Thanks > Burlen > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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. 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 david.gobbi at gmail.com Thu Nov 12 13:22:29 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 12 Nov 2015 11:22:29 -0700 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: References: <20151112161622.1274692523@mail.rogue-research.com> <20151112170404.GB32578@megas.khq.kitware.com> Message-ID: Hi Sean, Can you take a look to see if the following patch fixes the issue? It's based on the 6.3 release branch for obvious reasons. https://gitlab.kitware.com/vtk/vtk/merge_requests/906 - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Nov 13 04:03:06 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 13 Nov 2015 10:03:06 +0100 Subject: [vtk-developers] How to change opacity/visibility of polyline In-Reply-To: References: Message-ID: You can then use the extractSurface filter to recover a polydata if needed. Mathieu Mathieu Westphal On Fri, Nov 6, 2015 at 6:24 PM, Saeed Mahdizadeh Bakhshmand < saeedbakhshmand at gmail.com> wrote: > Hello Mathieu, > > Thanks for your response, And this output should be saved into an > vtkUnstructuredGrid or there is a better way to copy data from selection? > > Best, > Saeed > > On Fri, Oct 30, 2015 at 3:03 AM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> Hello >> >> No, but you can extract the cells you want to see, and display the output. >> >> Mathieu >> >> Mathieu Westphal >> >> On Thu, Oct 29, 2015 at 11:19 PM, Saeed Mahdizadeh Bakhshmand < >> saeedbakhshmand at gmail.com> wrote: >> >>> Hello, >>> >>> Is there any way to toggle visibility of each line of a vtkpolydata (or >>> vtkpolyline) independently? >>> >>> Best, >>> Saeed >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the 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 Fri Nov 13 07:59:39 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 13 Nov 2015 05:59:39 -0700 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: References: <20151112161622.1274692523@mail.rogue-research.com> <20151112170404.GB32578@megas.khq.kitware.com> Message-ID: On Thu, Nov 12, 2015 at 11:22 AM, David Gobbi wrote: > Hi Sean, > > Can you take a look to see if the following patch fixes the issue? > It's based on the 6.3 release branch for obvious reasons. > > https://gitlab.kitware.com/vtk/vtk/merge_requests/906 > Dashboard looks good. Ben, can you merge this into release-6.3? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Fri Nov 13 09:57:05 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 13 Nov 2015 15:57:05 +0100 Subject: [vtk-developers] Crash when reading LSDyna d3plot file Message-ID: Hello All, I'm getting a crash when trying to load a d3plot file coming from LSDyna R8, using the vtkLSDynaReader class. Attached is a very simple code that reproduces the problem (at least here on Windows 7, VTK 6.3). It is written to be used with these dataset : https://www.dropbox.com/s/2gzah0d8d2dpvlt/d3plot.zip?dl=0 It may come from our dataset it self, because when I change the line : l_reader->SetFileName( "./our.d3plot" ); by the line l_reader->SetFileName( "./hemi_draw.d3plot" ); The hemi_draw dataset loads just fine (it is coming from the VTKLargeData git repository) Or maybe the problem comes from my code, because ParaView is able to load the dataset ... Any clue ? Any d3plot expert around ? Thanks Simon -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required( VERSION 2.8.5 FATAL_ERROR ) project( LSDynaReader ) find_package( VTK REQUIRED ) include( ${VTK_USE_FILE} ) add_executable( LSDynaReader MACOSX_BUNDLE LSDynaReader.cxx ) target_link_libraries( LSDynaReader ${VTK_LIBRARIES} ) -------------- next part -------------- #include "vtkActor.h" #include "vtkCompositeDataGeometryFilter.h" #include "vtkLSDynaReader.h" #include "vtkNew.h" #include "vtkPolyDataMapper.h" #include "vtkRenderer.h" #include "vtkRenderWindow.h" #include "vtkRenderWindowInteractor.h" int main( int argc, char *argv[] ){ vtkNew l_reader; l_reader->SetFileName( "./our.d3plot" ); //l_reader->SetFileName( "./hemi_draw.d3plot" ); l_reader->Update(); vtkNew l_composite_filter; l_composite_filter->SetInputConnection( l_reader->GetOutputPort() ); vtkNew l_mapper; l_mapper->SetInputConnection( l_composite_filter->GetOutputPort() ); vtkNew l_actor; l_actor->SetMapper( l_mapper.GetPointer() ); vtkNew l_render_window; vtkNew l_renderer; vtkNew l_iren; l_render_window->AddRenderer( l_renderer.GetPointer() ); l_iren->SetRenderWindow( l_render_window.GetPointer() ); l_renderer->AddActor( l_actor.GetPointer() ); l_iren->Start(); } From simon.esneault at gmail.com Fri Nov 13 10:43:38 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 13 Nov 2015 16:43:38 +0100 Subject: [vtk-developers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper Message-ID: Hi All, All vtkTextActor are rendered blurred when using with vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the new rendering backend. Here are some snapshots : - OpenGL1 - OpenGL2 Attached some code that reproduces the problem, to be used with this volume. Visible on OSX and Windows to our knowledge, probably on more OS. The text is rendered properly when used with the old backend or when using a vtkGPUVolumeRayCastMapper instead of the vtkFixedPointVolumeRayCastMapper. Shall I feel a bug, is this a known issue ? Thanks, Simon -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #include "vtkCallbackCommand.h" #include "vtkCamera.h" #include "vtkColorTransferFunction.h" #include "vtkFixedPointVolumeRayCastMapper.h" #include "vtkImageData.h" #include "vtkImageResample.h" #include "vtkInteractorStyle.h" #include "vtkInteractorStyleTrackballCamera.h" #include "vtkMath.h" #include "vtkMetaImageReader.h" #include "vtkPiecewiseFunction.h" #include "vtkRenderWindow.h" #include "vtkRenderWindowInteractor.h" #include "vtkRenderer.h" #include "vtkTextActor.h" #include "vtkTextProperty.h" #include "vtkVolume.h" #include "vtkVolumeProperty.h" int main( int argc, char *argv[] ){ // Read volume vtkMetaImageReader* l_reader = vtkMetaImageReader::New(); l_reader->SetFileName( "volume.mhd" ); l_reader->Update(); // reduce to 10 Megavoxels double l_ratio = std::pow( 10000000. / l_reader->GetOutput()->GetNumberOfPoints(), 1. / 3. ); vtkImageResample* l_resample = vtkImageResample::New(); l_resample->SetInputConnection( l_reader->GetOutputPort() ); l_resample->SetInterpolationModeToLinear(); for( int i = 0; i < 3; i++ ) l_resample->SetAxisMagnificationFactor( i, l_ratio ); // Setup rendering stuff vtkRenderer* l_renderer = vtkRenderer::New(); l_renderer->SetBackground( 0.3, 0.3, 0.3 ); vtkRenderWindow* l_render_windows = vtkRenderWindow::New(); l_render_windows->AddRenderer( l_renderer ); l_render_windows->SetSize( 900, 900 ); vtkInteractorStyleTrackballCamera* l_trackball = vtkInteractorStyleTrackballCamera::New(); vtkRenderWindowInteractor* l_iren = vtkRenderWindowInteractor::New(); l_iren->SetInteractorStyle( l_trackball ); l_iren->SetRenderWindow( l_render_windows ); l_iren->GetInteractorStyle()->SetDefaultRenderer( l_renderer ); // Make sure we have an opengl context l_render_windows->Render(); // Setup GPU volume raycast mapper vtkFixedPointVolumeRayCastMapper* l_gpu_mapper = vtkFixedPointVolumeRayCastMapper::New(); l_gpu_mapper->SetInputConnection( l_resample->GetOutputPort() ); // Setup Volume property double wl = 260; double ww = 270; // Color function vtkColorTransferFunction* l_color = vtkColorTransferFunction::New(); l_color->SetColorSpaceToRGB(); l_color->AddRGBPoint( wl - ww / 2, 0, 0, 0 ); l_color->AddRGBPoint( wl - ww / 2 + 94 * ( ww / 255.0 ), 1., 21. / 255.0, 27. / 255.0 ); l_color->AddRGBPoint( wl - ww / 2 + 147 * ( ww / 255.0 ), 1., 176. / 255.0, 9. / 255.0 ); l_color->AddRGBPoint( wl - ww / 2 + 201 * ( ww / 255.0 ), 1., 241. / 255.0, 39. / 255.0 ); l_color->AddRGBPoint( wl - ww / 2 + 255 * ( ww / 255.0 ), 1, 1, 1. ); l_color->Build(); // Opacity function vtkPiecewiseFunction* l_opacity = vtkPiecewiseFunction::New(); l_opacity->AddPoint( wl - ww / 2, 0 ); l_opacity->AddPoint( wl + ww / 2, 1 ); // Volume property, light, shading vtkVolumeProperty* l_volume_property = vtkVolumeProperty::New(); l_volume_property->SetColor( l_color ); l_volume_property->SetScalarOpacity( l_opacity ); l_volume_property->SetInterpolationTypeToLinear(); l_volume_property->ShadeOn(); l_volume_property->SetDiffuse( 0.8 ); // Put everything together vtkVolume* l_volume = vtkVolume::New(); l_volume->SetProperty( l_volume_property ); l_volume->SetMapper( l_gpu_mapper ); // setup text actor : vtkTextActor* l_text_actor = vtkTextActor::New(); l_text_actor->GetPositionCoordinate()->SetCoordinateSystemToNormalizedViewport(); l_text_actor->GetPositionCoordinate()->SetValue( 0.01, 0.99 ); l_text_actor->GetTextProperty()->SetJustificationToLeft(); l_text_actor->GetTextProperty()->SetVerticalJustificationToTop(); l_text_actor->GetTextProperty()->SetFontSize( 30 ); #ifdef VTK_WAS_BUILT_WITH_OPENGL2 l_text_actor->SetInput( "OpenGL2 !!!!" ); #else l_text_actor->SetInput( "OpenGL1 !!!!" ); #endif l_renderer->AddActor( l_text_actor ); l_renderer->AddVolume( l_volume ); // Adjust camera position l_renderer->GetActiveCamera()->SetViewUp( 0, 0, 1 ); double l_distance = 1000; double l_center[ 3 ], l_pos[ 3 ]; l_reader->GetOutput()->GetCenter( l_center ); l_reader->GetOutput()->GetCenter( l_pos ); l_pos[ 1 ] -= l_distance; double l_cam_angle = atan( ( l_center[ 2 ] * 2. ) / ( l_distance * 2. ) ) * 360.0 / vtkMath::Pi(); l_renderer->GetActiveCamera()->SetFocalPoint( l_center ); l_renderer->GetActiveCamera()->SetPosition( l_pos ); l_renderer->GetActiveCamera()->SetViewAngle( l_cam_angle + 1 ); l_renderer->GetActiveCamera()->SetClippingRange( 0.01, 10000 ); // Go rendering ! l_iren->Start(); // Memory cleanup l_reader->Delete(); l_resample->Delete(); l_renderer->Delete(); l_render_windows->Delete(); l_trackball->Delete(); l_iren->Delete(); l_gpu_mapper->Delete(); l_color->Delete(); l_opacity->Delete(); l_volume_property->Delete(); l_volume->Delete(); l_text_actor->Delete(); } -------------- next part -------------- cmake_minimum_required( VERSION 2.8.5 FATAL_ERROR ) project( BlurredText ) find_package( VTK REQUIRED ) include( ${VTK_USE_FILE} ) if( VTK_RENDERING_BACKEND STREQUAL "OpenGL2" ) message( STATUS "Using new OpenGL2 backend" ) add_definitions( -DVTK_WAS_BUILT_WITH_OPENGL2 ) else() message( STATUS "Using old OpenGL1 backend" ) endif() add_executable( BlurredText MACOSX_BUNDLE BlurredText.cxx ) target_link_libraries( BlurredText ${VTK_LIBRARIES} ) From simon.esneault at gmail.com Fri Nov 13 10:57:17 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 13 Nov 2015 16:57:17 +0100 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: Hello Aashish, I've run some quick tests on my computer, and when disabling the automatic adjustment, both of the volume rendering technique seems to deliver the same performance, with some random Fixed sample distance. I will run some more test on the other computer that we've got here, just to be sure. And also on some mac. And report them to you :) Is there something else that I can do to help on this problem ? Simon 2015-11-12 18:34 GMT+01:00 Aashish Chaudhary : > > > On Thu, Nov 12, 2015 at 12:31 PM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> >> >> On Thu, Nov 12, 2015 at 12:12 PM, Simon ESNEAULT < >> simon.esneault at gmail.com> wrote: >> >>> Hello Aashish, >>> >>> Sorry for the late reply, I was busy last week. >>> >>> Thanks for the update, and your work on this topic. >>> Yes I have seen that your change have been merged concerning the >>> ReductionFactor. Nevertheless, I am still getting a smaller frame rate with >>> the new backend. To highlight this, please find attached a very simple >>> application that loads a volume ( >>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does volume >>> rendering while displaying the frame rate. This is pretty much what we show >>> to the user in our application, and in this condition, on my machine the >>> FPS are around 25 with the opengl1 backend >>> , and 15 with the >>> new backend , from >>> this week VTK master >>> It is very simple to test, just need change the VTK_DIR to an OpenGL1 or >>> OpenGL2 build, and place the volume.mhd and raw in the execution path. >>> Also you will find attached a small text file that summarizes the test >>> that have been done here. >>> >> >> No problem, thanks for the update. Please see my comments below: >> >>> >>> I think the real reason why it appears slower with the OGL2 version is >>> that we try to have control on the "MaximalImageSampleDistance". If I >>> remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get >>> the same frame rate with each backend. BUT, the new backend does decimate a >>> lot more the volume, leading to a very blurred image during rendering, and >>> that's not what we want :/ >>> >> >> Aha, this is very useful since this parameters does affecting the >> reduction factor. I will try your code; one quick question when the new >> backend decimates a lot (by removing the SetMaximumImageSampleDistance), >> does it get any faster than the old version? I am going to try it on my Mac >> and Linux laptop and report back (mostly tomorrow since I am away today). >> >>> >>> > Never mind, I see that you have that in your result file. It seems it does > get faster but more blurry. Would it be possible for you to do one more > test? Can you set a fix sample distance (pick any) for new and the old > mapper and set AutoAdjustSampleDistance to OFF and capture some performance > numbers? In that way we know exactly if something more fundamental is > causing the slowness. The whole reduction factor math is based on > approximate stuff so that will vary between two mappers. > > - Aashish > > >> Again, thanks for paying attention to this problem, I hope this little >>> application and test case can help you to adjust the parameters... >>> >> >> Thanks for your help. I am glad you are testing my latest changes. >> >> - Best, Aashish >> >>> >>> >>> Simon >>> >>> PS : I did not get a chance to check the difference on Paraview, but I >>> believe the result will be the same as the attached example is really >>> simple. >>> >>> 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> Hi Simon, >>>> >>>> the branch has been merged into VTK master. I am not sure when Paraview >>>> is going to update the VTK, but you can do it manually if needed. We are >>>> also going to run our bench marking again to be sure since recently lot >>>> many changes went into the VTK / volume rendering. Please feel free to ping >>>> me again if it does not solve your issue. >>>> >>>> Looking forward to your feedback. >>>> >>>> - Aashish >>>> >>>> On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com> wrote: >>>> >>>>> Hi Simon, >>>>> >>>>> I found the reason behind the appeared performance you were getting. >>>>> We have this code in volume rendering that when you interact changes the >>>>> sampling distance and in the newer code we were too conservative compare to >>>>> the last version. That's why you were getting better quality when you move >>>>> your mouse but lower frame rates. I pushed a branch in VTK to address the >>>>> issue. Would it be possible for you to build Paraview with VTK master? It >>>>> may take 3-4 days or longer for Paraview's VTK to get updated. >>>>> >>>>> Thanks, >>>>> Aashish >>>>> >>>>> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com> wrote: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> I am just finishing up a ParaView5 related parallel volume rendering >>>>>> bug (pushing a branch today to VTK). This is next on my list. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> Hello Aashish >>>>>>> >>>>>>> Did you get a chance to try to load the dataset on Windows ? >>>>>>> Can I do anything to help you investigate ? Should I feel a bug, >>>>>>> that may act as a reminder ? >>>>>>> Have a nice day >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com>: >>>>>>> >>>>>>>> Thanks Simon. This is really strange since we are not seeing it on >>>>>>>> Mac and Linux (but both has dedicated cards). >>>>>>>> >>>>>>>> I will look into it soon. >>>>>>>> >>>>>>>> - aashish >>>>>>>> >>>>>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> Ok, thank you very much fort digging into this. >>>>>>>>> I've done some test and I believe I can see a similar slowdown >>>>>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>>>>> graphics. >>>>>>>>> Good luck in the investigation, I you need more details, do not >>>>>>>>> hesitate to ask >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>> >>>>>>>>>> Ah, thanks. I will get back to you on this since on Linux I don't >>>>>>>>>> any issue so it has to be Windows specific thing. >>>>>>>>>> >>>>>>>>>> - Aashish >>>>>>>>>> >>>>>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I tried with that one from yesterday and today's version >>>>>>>>>>> (4.4.0-209-gc399648) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> And when did you download this version? >>>>>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Aashish >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>>>>> version seems even bigger. >>>>>>>>>>>>> I got the version from the nightly build download section of >>>>>>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>>>>> results. >>>>>>>>>>>>> >>>>>>>>>>>>> About the FPS, it is difficult to give an exact number, >>>>>>>>>>>>> because it depends of the condition (zoomed or not etc...) but yes, this is >>>>>>>>>>>>> the idea. >>>>>>>>>>>>> In our software, I've exposed the frame rate using this >>>>>>>>>>>>> example : >>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>>>>>>> example), with the same mapper parameters >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Simon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) Did you try without the shading and see how the >>>>>>>>>>>>>> performance compares? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this >>>>>>>>>>>>>> one from (ParaView download page or did you built yourself?) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, so on your system the old mapper is running 30FPS and >>>>>>>>>>>>>> the new one at 15-20 FPS as per your summary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>>>>> The two tested version are : >>>>>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 >>>>>>>>>>>>>>> backend. >>>>>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and Nvidia >>>>>>>>>>>>>>> Quadro K420 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And start interacting ... >>>>>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate in >>>>>>>>>>>>>>> Paraview, but the new version seems really twice slower in these >>>>>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>>>>> interactivity is better. >>>>>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play >>>>>>>>>>>>>>> with this with the old backend to fine tune the interactivity, although >>>>>>>>>>>>>>> what's really inside was never clear to me >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I hope that there is enough information for you to reproduce >>>>>>>>>>>>>>> this, do not hesitate to ask for some more information. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Checking again. Wondering if you can provide some more >>>>>>>>>>>>>>>> detail on the binary you are using and whether or not without shading the >>>>>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I used your dataset on paraview master as of today on my >>>>>>>>>>>>>>>>> Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about >>>>>>>>>>>>>>>>> 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> NOTE: You might get multiple emails because of the >>>>>>>>>>>>>>>>> attachment size issue. Sorry about that. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short >>>>>>>>>>>>>>>>>>> element (you can find the dataset here : >>>>>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). >>>>>>>>>>>>>>>>>>> So I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when >>>>>>>>>>>>>>>>>>> compared to the old one, it seems less "low resolution" during interaction >>>>>>>>>>>>>>>>>>> than the old one >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe >>>>>>>>>>>>>>>>>>> the GPURenderDemo used with this dataset is enough to highlight the slow >>>>>>>>>>>>>>>>>>> down. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with >>>>>>>>>>>>>>>>>>>> shading that was causing the slow performance a while back. I don't >>>>>>>>>>>>>>>>>>>> remember if that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the >>>>>>>>>>>>>>>>>>>>> data type you might be using >>>>>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The >>>>>>>>>>>>>>>>>>>>> performance we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you >>>>>>>>>>>>>>>>>>>>>> compare the latest 4.4 OpenGL2 build with the classic 4.4 build while >>>>>>>>>>>>>>>>>>>>>> volume rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering >>>>>>>>>>>>>>>>>>>>>> implementation should be faster than the old one, is there some more >>>>>>>>>>>>>>>>>>>>>> detailed explanation somewhere ? Are there some important parameters that >>>>>>>>>>>>>>>>>>>>>> can make the difference ? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with >>>>>>>>>>>>>>>>>>>>>> the new backend ! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>> * >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>>> * >>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>> * >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> Simon Esneault >>>>>>>>>>> Rennes, France >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>> * >>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>> * >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Nov 13 11:02:39 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 13 Nov 2015 11:02:39 -0500 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: On Fri, Nov 13, 2015 at 10:57 AM, Simon ESNEAULT wrote: > Hello Aashish, > > I've run some quick tests on my computer, and when disabling the automatic > adjustment, both of the volume rendering technique seems to deliver the > same performance, with some random Fixed sample distance. I will run some > more test on the other computer that we've got here, just to be sure. And > also on some mac. And report them to you :) > This is very helpful and sort of confirms my theory the the code in question is the reduction factor computation. The logic is changed between the old mapper and the new mapper. I will look again to make them consistent but it won't be exactly the same since the old mapper code to me was not making the the right choices and was broken for the new mapper. Actually, initially we had the exact same code and it was running into issues since the new mapper was faster and hence breaking some of the assumptions the old mapper was making. > > Is there something else that I can do to help on this problem ? > Not at the moment. You helped a lot, the code and the data is really helpful. I will report back early next week again and will request you to try again. Thanks for your patience. - Aashish > > > Simon > > > 2015-11-12 18:34 GMT+01:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> >> >> On Thu, Nov 12, 2015 at 12:31 PM, Aashish Chaudhary < >> aashish.chaudhary at kitware.com> wrote: >> >>> >>> >>> On Thu, Nov 12, 2015 at 12:12 PM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Hello Aashish, >>>> >>>> Sorry for the late reply, I was busy last week. >>>> >>>> Thanks for the update, and your work on this topic. >>>> Yes I have seen that your change have been merged concerning the >>>> ReductionFactor. Nevertheless, I am still getting a smaller frame rate with >>>> the new backend. To highlight this, please find attached a very simple >>>> application that loads a volume ( >>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does volume >>>> rendering while displaying the frame rate. This is pretty much what we show >>>> to the user in our application, and in this condition, on my machine the >>>> FPS are around 25 with the opengl1 backend >>>> , and 15 with the >>>> new backend , from >>>> this week VTK master >>>> It is very simple to test, just need change the VTK_DIR to an OpenGL1 >>>> or OpenGL2 build, and place the volume.mhd and raw in the execution path. >>>> Also you will find attached a small text file that summarizes the test >>>> that have been done here. >>>> >>> >>> No problem, thanks for the update. Please see my comments below: >>> >>>> >>>> I think the real reason why it appears slower with the OGL2 version is >>>> that we try to have control on the "MaximalImageSampleDistance". If I >>>> remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get >>>> the same frame rate with each backend. BUT, the new backend does decimate a >>>> lot more the volume, leading to a very blurred image during rendering, and >>>> that's not what we want :/ >>>> >>> >>> Aha, this is very useful since this parameters does affecting the >>> reduction factor. I will try your code; one quick question when the new >>> backend decimates a lot (by removing the SetMaximumImageSampleDistance), >>> does it get any faster than the old version? I am going to try it on my Mac >>> and Linux laptop and report back (mostly tomorrow since I am away today). >>> >>>> >>>> >> Never mind, I see that you have that in your result file. It seems it >> does get faster but more blurry. Would it be possible for you to do one >> more test? Can you set a fix sample distance (pick any) for new and the old >> mapper and set AutoAdjustSampleDistance to OFF and capture some performance >> numbers? In that way we know exactly if something more fundamental is >> causing the slowness. The whole reduction factor math is based on >> approximate stuff so that will vary between two mappers. >> >> - Aashish >> >> >>> Again, thanks for paying attention to this problem, I hope this little >>>> application and test case can help you to adjust the parameters... >>>> >>> >>> Thanks for your help. I am glad you are testing my latest changes. >>> >>> - Best, Aashish >>> >>>> >>>> >>>> Simon >>>> >>>> PS : I did not get a chance to check the difference on Paraview, but I >>>> believe the result will be the same as the attached example is really >>>> simple. >>>> >>>> 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> Hi Simon, >>>>> >>>>> the branch has been merged into VTK master. I am not sure when >>>>> Paraview is going to update the VTK, but you can do it manually if needed. >>>>> We are also going to run our bench marking again to be sure since recently >>>>> lot many changes went into the VTK / volume rendering. Please feel free to >>>>> ping me again if it does not solve your issue. >>>>> >>>>> Looking forward to your feedback. >>>>> >>>>> - Aashish >>>>> >>>>> On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com> wrote: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> I found the reason behind the appeared performance you were getting. >>>>>> We have this code in volume rendering that when you interact changes the >>>>>> sampling distance and in the newer code we were too conservative compare to >>>>>> the last version. That's why you were getting better quality when you move >>>>>> your mouse but lower frame rates. I pushed a branch in VTK to address the >>>>>> issue. Would it be possible for you to build Paraview with VTK master? It >>>>>> may take 3-4 days or longer for Paraview's VTK to get updated. >>>>>> >>>>>> Thanks, >>>>>> Aashish >>>>>> >>>>>> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> I am just finishing up a ParaView5 related parallel volume rendering >>>>>>> bug (pushing a branch today to VTK). This is next on my list. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> Hello Aashish >>>>>>>> >>>>>>>> Did you get a chance to try to load the dataset on Windows ? >>>>>>>> Can I do anything to help you investigate ? Should I feel a bug, >>>>>>>> that may act as a reminder ? >>>>>>>> Have a nice day >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>> >>>>>>>>> Thanks Simon. This is really strange since we are not seeing it on >>>>>>>>> Mac and Linux (but both has dedicated cards). >>>>>>>>> >>>>>>>>> I will look into it soon. >>>>>>>>> >>>>>>>>> - aashish >>>>>>>>> >>>>>>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Ok, thank you very much fort digging into this. >>>>>>>>>> I've done some test and I believe I can see a similar slowdown >>>>>>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>>>>>> graphics. >>>>>>>>>> Good luck in the investigation, I you need more details, do not >>>>>>>>>> hesitate to ask >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>> >>>>>>>>>>> Ah, thanks. I will get back to you on this since on Linux I >>>>>>>>>>> don't any issue so it has to be Windows specific thing. >>>>>>>>>>> >>>>>>>>>>> - Aashish >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I tried with that one from yesterday and today's version >>>>>>>>>>>> (4.4.0-209-gc399648) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> And when did you download this version? >>>>>>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Aashish >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>>>>>> version seems even bigger. >>>>>>>>>>>>>> I got the version from the nightly build download section of >>>>>>>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>>>>>> results. >>>>>>>>>>>>>> >>>>>>>>>>>>>> About the FPS, it is difficult to give an exact number, >>>>>>>>>>>>>> because it depends of the condition (zoomed or not etc...) but yes, this is >>>>>>>>>>>>>> the idea. >>>>>>>>>>>>>> In our software, I've exposed the frame rate using this >>>>>>>>>>>>>> example : >>>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>>>>>> And the frame rate is around 15/20 for the first backend, and >>>>>>>>>>>>>> around 6/8 for the new backend, on the same dataset (the one provided for >>>>>>>>>>>>>> example), with the same mapper parameters >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Simon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) Did you try without the shading and see how the >>>>>>>>>>>>>>> performance compares? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this >>>>>>>>>>>>>>> one from (ParaView download page or did you built yourself?) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, so on your system the old mapper is running 30FPS and >>>>>>>>>>>>>>> the new one at 15-20 FPS as per your summary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>>>>>> The two tested version are : >>>>>>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 >>>>>>>>>>>>>>>> backend. >>>>>>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and >>>>>>>>>>>>>>>> Nvidia Quadro K420 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>>>>>> - Adjust the transfer function data range to [100-750] (the >>>>>>>>>>>>>>>> default "Cool to Warm" is fine) >>>>>>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And start interacting ... >>>>>>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate >>>>>>>>>>>>>>>> in Paraview, but the new version seems really twice slower in these >>>>>>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>>>>>> interactivity is better. >>>>>>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play >>>>>>>>>>>>>>>> with this with the old backend to fine tune the interactivity, although >>>>>>>>>>>>>>>> what's really inside was never clear to me >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I hope that there is enough information for you to >>>>>>>>>>>>>>>> reproduce this, do not hesitate to ask for some more information. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Checking again. Wondering if you can provide some more >>>>>>>>>>>>>>>>> detail on the binary you are using and whether or not without shading the >>>>>>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I used your dataset on paraview master as of today on my >>>>>>>>>>>>>>>>>> Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about >>>>>>>>>>>>>>>>>> 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked the >>>>>>>>>>>>>>>>>> shading performance fix was in 4.4 but not in RC's. I don't have access to >>>>>>>>>>>>>>>>>> Windows box right away but I will try there too. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> NOTE: You might get multiple emails because of the >>>>>>>>>>>>>>>>>> attachment size issue. Sorry about that. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short >>>>>>>>>>>>>>>>>>>> element (you can find the dataset here : >>>>>>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). >>>>>>>>>>>>>>>>>>>> So I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when >>>>>>>>>>>>>>>>>>>> compared to the old one, it seems less "low resolution" during interaction >>>>>>>>>>>>>>>>>>>> than the old one >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I believe >>>>>>>>>>>>>>>>>>>> the GPURenderDemo used with this dataset is enough to highlight the slow >>>>>>>>>>>>>>>>>>>> down. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with >>>>>>>>>>>>>>>>>>>>> shading that was causing the slow performance a while back. I don't >>>>>>>>>>>>>>>>>>>>> remember if that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the >>>>>>>>>>>>>>>>>>>>>> data type you might be using >>>>>>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The >>>>>>>>>>>>>>>>>>>>>> performance we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you >>>>>>>>>>>>>>>>>>>>>>> compare the latest 4.4 OpenGL2 build with the classic 4.4 build while >>>>>>>>>>>>>>>>>>>>>>> volume rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering >>>>>>>>>>>>>>>>>>>>>>> implementation should be faster than the old one, is there some more >>>>>>>>>>>>>>>>>>>>>>> detailed explanation somewhere ? Are there some important parameters that >>>>>>>>>>>>>>>>>>>>>>> can make the difference ? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster with >>>>>>>>>>>>>>>>>>>>>>> the new backend ! >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>> Inc. * >>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> Simon Esneault >>>>>>>>>>>> Rennes, France >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>> * >>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Fri Nov 13 12:00:15 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Fri, 13 Nov 2015 09:00:15 -0800 Subject: [vtk-developers] vtkDepthSortPolyData modernization In-Reply-To: References: <56437525.8040107@gmail.com> Message-ID: <5646171F.1020809@gmail.com> Hi Will, Your recent post mentioning changing std::sort to vtkSMPTools::Sort() had me thinking about that, and also about giving the gift of code. In the algorithm there are 3 distinct parts, computing the depths, sorting, and building the output. Each of of those could be parallelized. I'm willing to try it. Thanks for the suggestion! Burlen On 11/12/2015 10:20 AM, Will Schroeder wrote: > Burlen I would use vtkSMPTools::Sort(). Under the hood it uses > std::sort when VTK is built in VTK_SMP_IMPLEMENTATION_TYPE=Sequential > mode (default). But when built with VTK_SMP_IMPLEMENTATION_TYPE=TBB, > etc. you'll see significant parallelization benefits. > > W > > On Wed, Nov 11, 2015 at 12:04 PM, Burlen Loring > > wrote: > > Hi All, > > Would anyone be willing to review this patch? > https://gitlab.kitware.com/vtk/vtk/merge_requests/844 > > I was profiling VisIt and noticed that vtkDepthSortPolyData (in > spite of its limitations it is used by VisIt for transparent > rendering) made use of qsort and about 1/2 the time was spent by > qsort. std::sort is known to be faster because of the possibility > of the compiler to inline the comparisons. Updating qsort to > std::sort seemed like an easy way to make it faster. As I worked > the profiler pointed out a number of other fairly easy things to > improve and overall the class is now ~3x faster for two of the > modes and ~2x faster for the other. I enumerated the changes in > the commit message and have added a cxx test to improve the test > coverage. > > If you have the time, please take a look, and let me know if you > have any feedback on it. > > Thanks > Burlen > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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. > 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 lenlen1982 at gmail.com Fri Nov 13 12:30:52 2015 From: lenlen1982 at gmail.com (Antonella Cascitelli) Date: Fri, 13 Nov 2015 18:30:52 +0100 Subject: [vtk-developers] vtkImageActor attribute Message-ID: Hi all, is it possible expose (with a getter method) the vtkImageActor attribute of the vtkTextActor3D? Thanks -- Antonella -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Nov 13 12:48:47 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 13 Nov 2015 12:48:47 -0500 Subject: [vtk-developers] vtkDepthSortPolyData modernization In-Reply-To: <5646171F.1020809@gmail.com> References: <56437525.8040107@gmail.com> <5646171F.1020809@gmail.com> Message-ID: Go for it you'll never go back ;-) -- Sent from mobile phone please excuse typos and terseness On Nov 13, 2015 12:00 PM, "Burlen Loring" wrote: > Hi Will, > > Your recent post mentioning changing std::sort to vtkSMPTools::Sort() had > me thinking about that, and also about giving the gift of code. In the > algorithm there are 3 distinct parts, computing the depths, sorting, and > building the output. Each of of those could be parallelized. I'm willing to > try it. Thanks for the suggestion! > > Burlen > > On 11/12/2015 10:20 AM, Will Schroeder wrote: > > Burlen I would use vtkSMPTools::Sort(). Under the hood it uses std::sort > when VTK is built in VTK_SMP_IMPLEMENTATION_TYPE=Sequential mode (default). > But when built with VTK_SMP_IMPLEMENTATION_TYPE=TBB, etc. you'll see > significant parallelization benefits. > > W > > On Wed, Nov 11, 2015 at 12:04 PM, Burlen Loring > wrote: > >> Hi All, >> >> Would anyone be willing to review this patch? >> https://gitlab.kitware.com/vtk/vtk/merge_requests/844 >> >> I was profiling VisIt and noticed that vtkDepthSortPolyData (in spite of >> its limitations it is used by VisIt for transparent rendering) made use of >> qsort and about 1/2 the time was spent by qsort. std::sort is known to be >> faster because of the possibility of the compiler to inline the >> comparisons. Updating qsort to std::sort seemed like an easy way to make it >> faster. As I worked the profiler pointed out a number of other fairly easy >> things to improve and overall the class is now ~3x faster for two of the >> modes and ~2x faster for the other. I enumerated the changes in the commit >> message and have added a cxx test to improve the test coverage. >> >> If you have the time, please take a look, and let me know if you have any >> feedback on it. >> >> Thanks >> Burlen >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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. > 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 Fri Nov 13 16:21:34 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 13 Nov 2015 16:21:34 -0500 Subject: [vtk-developers] Python-related dashboard build errors with new clang In-Reply-To: References: <20151112161622.1274692523@mail.rogue-research.com> <20151112170404.GB32578@megas.khq.kitware.com> Message-ID: <20151113212134.GA11577@megas.khq.kitware.com> On Fri, Nov 13, 2015 at 05:59:39 -0700, David Gobbi wrote: > Dashboard looks good. Ben, can you merge this into release-6.3? Done. Thanks. --Ben From simon.esneault at gmail.com Mon Nov 16 06:08:44 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Mon, 16 Nov 2015 12:08:44 +0100 Subject: [vtk-developers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Hello, Trying to solve this problem, I found out that if one call "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a string with a vtkTextActor, the text is properly rendered with a yellow dot at the anchor point, and with a transparent gray background. - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG - DebugTexturesOff : http://picpaste.com/pics/Not-Blurred.1447669009.PNG Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is a blending problem. When we activate Texture Debugging, a gray background is first drawn, and after that in the method RenderCharacter( ... ) line 1887; we either blend the rendered text with the background or not. Attached is a diff file that solves the problem for me. I do not really understand why, so maybe a developer with more VTK's knowledge can integrate this properly :) Thanks, Simon 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : > Hi All, > > All vtkTextActor are rendered blurred when using with > vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the > new rendering backend. > > Here are some snapshots : > - OpenGL1 > - OpenGL2 > > Attached some code that reproduces the problem, to be used with this > volume. Visible on > OSX and Windows to our knowledge, probably on more OS. > > The text is rendered properly when used with the old backend or when using > a vtkGPUVolumeRayCastMapper instead of the vtkFixedPointVolumeRayCastMapper. > > Shall I feel a bug, is this a known issue ? > > Thanks, > Simon > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- --- a/Rendering/FreeType/vtkFreeTypeTools.cxx Mon Nov 16 12:00:48 2015 +++ b/Rendering/FreeType/vtkFreeTypeTools.cxx Mon Nov 16 11:59:16 2015 @@ -1974,14 +1974,14 @@ } else { - *ptr = fgRGB[0]; - ++ptr; - *ptr = fgRGB[1]; - ++ptr; - *ptr = fgRGB[2]; - ++ptr; - *ptr = static_cast((*glyphPtr) * fgA); - ++ptr; + const float fg_blend = fgA * (*glyphPtr / 255.f); + + ptr[0] = static_cast(fg_blend * fgRGB[0]); + ptr[1] = static_cast(fg_blend * fgRGB[1]); + ptr[2] = static_cast(fg_blend * fgRGB[2]); + ptr[3] = static_cast(fg_blend * 255.f); + + ptr += 4; } ++glyphPtr; } From aashish.chaudhary at kitware.com Mon Nov 16 10:11:41 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 16 Nov 2015 10:11:41 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Simon, Thanks for the report. I will follow up with other developers on this bug. - Aashish On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT wrote: > Hello, > > Trying to solve this problem, I found out that if one call > "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a > string with a vtkTextActor, the text is properly rendered with a yellow dot > at the anchor point, and with a transparent gray background. > - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG > - DebugTexturesOff : http://picpaste.com/pics/Not-Blurred.1447669009.PNG > > Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is a > blending problem. When we activate Texture Debugging, a gray background is > first drawn, and after that in the method RenderCharacter( ... ) line 1887; > we either blend the rendered text with the background or not. > > Attached is a diff file that solves the problem for me. I do not really > understand why, so maybe a developer with more VTK's knowledge can > integrate this properly :) > > Thanks, > Simon > > > > 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : > >> Hi All, >> >> All vtkTextActor are rendered blurred when using with >> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >> new rendering backend. >> >> Here are some snapshots : >> - OpenGL1 >> - OpenGL2 >> >> Attached some code that reproduces the problem, to be used with this >> volume. Visible >> on OSX and Windows to our knowledge, probably on more OS. >> >> The text is rendered properly when used with the old backend or when >> using a vtkGPUVolumeRayCastMapper instead of >> the vtkFixedPointVolumeRayCastMapper. >> >> Shall I feel a bug, is this a known issue ? >> >> Thanks, >> Simon >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From schuyler.kylstra at kitware.com Mon Nov 16 11:11:59 2015 From: schuyler.kylstra at kitware.com (Schuyler Kylstra) Date: Mon, 16 Nov 2015 11:11:59 -0500 Subject: [vtk-developers] MySQL module not exported by v6.3.0 In-Reply-To: References: Message-ID: ping On Tue, Nov 10, 2015 at 3:43 PM, Schuyler Kylstra < schuyler.kylstra at kitware.com> wrote: > Hi developers, > > I'm working on a project that uses vtk as part of a superbuild. I'm > currently pulling the repo at the tag v6.3.0 and I'm running into a > problem. The FindMySQL.cmake file is not getting placed in the install > folder for some reason. I've looked through the build files and I can't > find an option to install the file. Is this a known issue/is there a way to > fix this? > > -- > Schuyler Kylstra > -- Schuyler Kylstra -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Mon Nov 16 11:12:58 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Mon, 16 Nov 2015 17:12:58 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Hello Aashish, Thanks ! After doing some test, I realized the patch I've just sent is not the correct fix at all, because the text is not rendered properly when we don't use a vtkFixedPointVolumeRayCastMapper anymore. I believe the problem is probably larger than this and probably has nothing to do with the freetype text generation, but more with the vtkTexturedActor2D rendering part used together with a vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the texture has some transparent pixel in it ... Attached there is a new example that demonstrate that a vtkTextActor AND a vtkTexturedButtonRepresentation2D are not correctly drawn in that case : - OpenGL1 backend : Transparent pixel in Texture are correctly drawn - OpenGL2 backend : Transparent pixel in Texture are not correctly drawn (clamped to white ?) The example is more simple than the previous one and does not need any additional data. Hope that helps ! -Simon 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary : > Simon, > > Thanks for the report. I will follow up with other developers on this bug. > > - Aashish > > > On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT > wrote: > >> Hello, >> >> Trying to solve this problem, I found out that if one call >> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >> string with a vtkTextActor, the text is properly rendered with a yellow dot >> at the anchor point, and with a transparent gray background. >> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >> - DebugTexturesOff : http://picpaste.com/pics/Not-Blurred.1447669009.PNG >> >> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is a >> blending problem. When we activate Texture Debugging, a gray background is >> first drawn, and after that in the method RenderCharacter( ... ) line 1887; >> we either blend the rendered text with the background or not. >> >> Attached is a diff file that solves the problem for me. I do not really >> understand why, so maybe a developer with more VTK's knowledge can >> integrate this properly :) >> >> Thanks, >> Simon >> >> >> >> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : >> >>> Hi All, >>> >>> All vtkTextActor are rendered blurred when using with >>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>> new rendering backend. >>> >>> Here are some snapshots : >>> - OpenGL1 >>> - OpenGL2 >>> >>> Attached some code that reproduces the problem, to be used with this >>> volume. Visible >>> on OSX and Windows to our knowledge, probably on more OS. >>> >>> The text is rendered properly when used with the old backend or when >>> using a vtkGPUVolumeRayCastMapper instead of >>> the vtkFixedPointVolumeRayCastMapper. >>> >>> Shall I feel a bug, is this a known issue ? >>> >>> Thanks, >>> Simon >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Search the list archives at: http://markmail.org/search/?q=vtkusers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #include "vtkButtonWidget.h" #include "vtkFixedPointVolumeRayCastMapper.h" #include "vtkGPUVolumeRayCastMapper.h" #include "vtkImageCanvasSource2D.h" #include "vtkImageData.h" #include "vtkInteractorStyle.h" #include "vtkPNGReader.h" #include "vtkPNGReader.h" #include "vtkPolyDataMapper2D.h" #include "vtkRenderWindow.h" #include "vtkRenderWindowInteractor.h" #include "vtkRenderer.h" #include "vtkTextActor.h" #include "vtkTextProperty.h" #include "vtkTexture.h" #include "vtkTexturedActor2D.h" #include "vtkTexturedButtonRepresentation2D.h" #include "vtkVolume.h" int main( int argc, char *argv[] ){ // Generate an image data, filled with 0 value int l_image_size = 100; vtkImageData* l_image = vtkImageData::New(); l_image->SetExtent( 0, l_image_size - 1, 0, l_image_size - 1, 0, l_image_size - 1 ); l_image->AllocateScalars( VTK_SHORT, 1 ); memset( l_image->GetScalarPointer(), 0, pow( l_image_size, 3 ) ); // Setup a basic rendering pipeline vtkRenderer* l_renderer = vtkRenderer::New(); l_renderer->SetBackground( 0.3, 0.3, 0.3 ); int l_window_size = 300; vtkRenderWindow* l_render_windows = vtkRenderWindow::New(); l_render_windows->AddRenderer( l_renderer ); l_render_windows->SetSize( l_window_size, l_window_size ); vtkRenderWindowInteractor* l_iren = vtkRenderWindowInteractor::New(); l_iren->SetRenderWindow( l_render_windows ); l_iren->GetInteractorStyle()->SetDefaultRenderer( l_renderer ); // Setup a volume mapper //vtkGPUVolumeRayCastMapper* l_mapper = vtkGPUVolumeRayCastMapper::New(); vtkFixedPointVolumeRayCastMapper* l_mapper = vtkFixedPointVolumeRayCastMapper::New(); l_mapper->SetNumberOfThreads( 1 ); l_mapper->SetInputData( l_image ); // and a volume vtkVolume* l_volume = vtkVolume::New(); l_volume->SetMapper( l_mapper ); // setup a text actor : vtkTextActor* l_text_actor = vtkTextActor::New(); l_text_actor->GetTextProperty()->SetFontSize( 20 ); #ifdef VTK_WAS_BUILT_WITH_OPENGL2 l_text_actor->SetInput( "Some Text, OpenGL2 !??" ); #else l_text_actor->SetInput( "Some Text, OpenGL1 !??" ); #endif // Create a transparent image, with only a red circle int l_texture_size = 100; vtkImageCanvasSource2D* l_2d_image = vtkImageCanvasSource2D::New(); l_2d_image->SetScalarTypeToUnsignedChar(); l_2d_image->SetNumberOfScalarComponents( 4 ); l_2d_image->SetExtent( 0, l_texture_size, 0, l_texture_size, 0, 0 ); l_2d_image->SetDrawColor( 255, 255, 255, 0 ); // <- here with the new backend it does not respect the 0 alpha value, somewhat get clamp to something else l_2d_image->FillBox( 0, l_texture_size, 0, l_texture_size ); l_2d_image->SetDrawColor( 255, 0, 0, 255 ); l_2d_image->DrawCircle( l_texture_size / 2, l_texture_size / 2, l_texture_size / 2 - 3 ); l_2d_image->Update(); // Create the button widget and its representation vtkTexturedButtonRepresentation2D* l_button_rep = vtkTexturedButtonRepresentation2D::New(); l_button_rep->SetNumberOfStates( 2 ); l_button_rep->SetButtonTexture( 0, l_2d_image->GetOutput() ); l_button_rep->SetButtonTexture( 1, l_2d_image->GetOutput() ); vtkButtonWidget* l_button_widget = vtkButtonWidget::New(); l_button_widget->SetInteractor( l_render_windows->GetInteractor() ); l_button_widget->SetRepresentation( l_button_rep ); // place it on top right border, with a small margin double l_bounds[ 6 ]; l_bounds[ 0 ] = l_window_size - l_texture_size - 10; l_bounds[ 1 ] = l_window_size - 10; l_bounds[ 2 ] = l_window_size - l_texture_size - 10; l_bounds[ 3 ] = l_window_size - 10; l_bounds[ 4 ] = l_bounds[ 5 ] = 0.0; l_button_rep->SetPlaceFactor( 1 ); l_button_rep->PlaceWidget( l_bounds ); l_button_widget->On(); l_renderer->AddActor( l_text_actor ); l_renderer->AddVolume( l_volume ); // Render once ! l_render_windows->Render(); // Go rendering ! l_iren->Start(); // Memory cleanup l_image->Delete(); l_renderer->Delete(); l_render_windows->Delete(); l_iren->Delete(); l_mapper->Delete(); l_volume->Delete(); l_text_actor->Delete(); l_2d_image->Delete(); l_button_rep->Delete(); l_button_widget->Delete(); } -------------- next part -------------- cmake_minimum_required( VERSION 2.8.5 FATAL_ERROR ) project( BlurredText ) find_package( VTK REQUIRED ) include( ${VTK_USE_FILE} ) if( VTK_RENDERING_BACKEND STREQUAL "OpenGL2" ) message( STATUS "Using new OpenGL2 backend" ) add_definitions( -DVTK_WAS_BUILT_WITH_OPENGL2 ) else() message( STATUS "Using old OpenGL1 backend" ) endif() add_executable( BlurredText MACOSX_BUNDLE BlurredText.cxx ) target_link_libraries( BlurredText ${VTK_LIBRARIES} ) From aashish.chaudhary at kitware.com Mon Nov 16 11:49:10 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 16 Nov 2015 11:49:10 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: I see so its not just related to volume rendering and it seems to be a vtkTextActor2D problem? In that can probably Ken / David Lonie wants to take a look at it. Nonetheless, we will follow up on this bug. - Aashish On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT wrote: > Hello Aashish, > > Thanks ! > After doing some test, I realized the patch I've just sent is not the > correct fix at all, because the text is not rendered properly when we don't > use a vtkFixedPointVolumeRayCastMapper anymore. > > I believe the problem is probably larger than this and probably has > nothing to do with the freetype text generation, but more with the > vtkTexturedActor2D rendering part used together with a > vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the > texture has some transparent pixel in it ... > > Attached there is a new example that demonstrate that a vtkTextActor AND > a vtkTexturedButtonRepresentation2D are not correctly drawn in that case : > - OpenGL1 backend > : Transparent > pixel in Texture are correctly drawn > - OpenGL2 backend > : > Transparent pixel in Texture are not correctly drawn (clamped to white ?) > > The example is more simple than the previous one and does not need any > additional data. > > Hope that helps ! > -Simon > > 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> Simon, >> >> Thanks for the report. I will follow up with other developers on this >> bug. >> >> - Aashish >> >> >> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT > > wrote: >> >>> Hello, >>> >>> Trying to solve this problem, I found out that if one call >>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>> at the anchor point, and with a transparent gray background. >>> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >>> - DebugTexturesOff : http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>> >>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is a >>> blending problem. When we activate Texture Debugging, a gray background is >>> first drawn, and after that in the method RenderCharacter( ... ) line 1887; >>> we either blend the rendered text with the background or not. >>> >>> Attached is a diff file that solves the problem for me. I do not really >>> understand why, so maybe a developer with more VTK's knowledge can >>> integrate this properly :) >>> >>> Thanks, >>> Simon >>> >>> >>> >>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : >>> >>>> Hi All, >>>> >>>> All vtkTextActor are rendered blurred when using with >>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>> new rendering backend. >>>> >>>> Here are some snapshots : >>>> - OpenGL1 >>>> - OpenGL2 >>>> >>>> Attached some code that reproduces the problem, to be used with this >>>> volume. Visible >>>> on OSX and Windows to our knowledge, probably on more OS. >>>> >>>> The text is rendered properly when used with the old backend or when >>>> using a vtkGPUVolumeRayCastMapper instead of >>>> the vtkFixedPointVolumeRayCastMapper. >>>> >>>> Shall I feel a bug, is this a known issue ? >>>> >>>> Thanks, >>>> Simon >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the VTK FAQ at: >>> http://www.vtk.org/Wiki/VTK_FAQ >>> >>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtkusers >>> >>> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Nov 16 11:59:06 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 16 Nov 2015 11:59:06 -0500 Subject: [vtk-developers] MySQL module not exported by v6.3.0 In-Reply-To: References: Message-ID: <6FAB368F-F654-4128-AF46-3AA61A0FD73D@kitware.com> Hi Schuyler, > I'm working on a project that uses vtk as part of a superbuild. I'm currently pulling the repo at the tag v6.3.0 and I'm running into a problem. The FindMySQL.cmake file is not getting placed in the install folder for some reason. I've looked through the build files and I can't find an option to install the file. Is this a known issue/is there a way to fix this? I don't think VTK installs any of the CMake/FindXXX.cmake scripts from its source directory. I'm not sure how amenable people are to having them installed or not, but your superbuild could patch VTK/CMakeLists.txt to install FindMySQL.cmake, perhaps to VTK_MODULES_DIR. David From sean at rogue-research.com Mon Nov 16 23:35:20 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 16 Nov 2015 23:35:20 -0500 Subject: [vtk-developers] int to bool patch, white space convention? Message-ID: <20151117043520.1487807312@mail.rogue-research.com> Hi all, I'm working on a patch that changes some VTK APIs that use 'int' to instead use 'bool'. I've used a bunch of regexes to find vtkBooleanMacro uses, ex: vtkSetMacro\((.*),int\);\r vtkGetMacro\(\1,int\);\r vtkBooleanMacro\(\1,int\); I've discovered there's a variety of a) whitespace b) ordering, ex: vtkSetMacro(foo, bool); vtkGetMacro(foo, bool); vtkBooleanMacro(foo, bool); vs vtkBooleanMacro(bar,bool); vtkSetMacro(bar,bool); vtkGetMacro(bar,bool); Shall I take this opportunity to make everything uniform? The most common form is: vtkSetMacro(foo,int); vtkGetMacro(foo,int); vtkBooleanMacro(foo,int); The 2nd most common is the same order, but with a space after the comma. The style guide seems to have examples of both. Is one preferred? Here's my WIP: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From simon.esneault at gmail.com Tue Nov 17 03:27:56 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Tue, 17 Nov 2015 09:27:56 +0100 Subject: [vtk-developers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX Message-ID: Hello, After the switch to the new rendering backend, we have a crash on our program after reparenting a QVTKWidget on OSX. The crash is in the method vtkShaderProgram::FindUniform() but we suspect it is about the OpenGL context not being ready on time for the next paintEvent with the new parent. Attached is a program that reproduce the problem, as well as a complete backtrace for this crash. This used to work fine with the previous backend. Hope this little test case helps Thanks Simon -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QVTKWidgetText.zip Type: application/zip Size: 4515 bytes Desc: not available URL: From simon.esneault at gmail.com Tue Nov 17 03:36:09 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Tue, 17 Nov 2015 09:36:09 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Dear Aashish, Yes the root cause is probably located in vtkTexturedActor2D, or in vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible class for loading the texture. Shall I fill a bug ? Thanks Simon 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary : > I see so its not just related to volume rendering and it seems to be a > vtkTextActor2D problem? In that can probably Ken / David Lonie wants to > take a look at it. Nonetheless, we will follow up on this bug. > > - Aashish > > On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT > wrote: > >> Hello Aashish, >> >> Thanks ! >> After doing some test, I realized the patch I've just sent is not the >> correct fix at all, because the text is not rendered properly when we don't >> use a vtkFixedPointVolumeRayCastMapper anymore. >> >> I believe the problem is probably larger than this and probably has >> nothing to do with the freetype text generation, but more with the >> vtkTexturedActor2D rendering part used together with a >> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >> texture has some transparent pixel in it ... >> >> Attached there is a new example that demonstrate that a vtkTextActor AND >> a vtkTexturedButtonRepresentation2D are not correctly drawn in that case : >> - OpenGL1 backend >> : Transparent >> pixel in Texture are correctly drawn >> - OpenGL2 backend >> : >> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >> >> The example is more simple than the previous one and does not need any >> additional data. >> >> Hope that helps ! >> -Simon >> >> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> Simon, >>> >>> Thanks for the report. I will follow up with other developers on this >>> bug. >>> >>> - Aashish >>> >>> >>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> Trying to solve this problem, I found out that if one call >>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>> at the anchor point, and with a transparent gray background. >>>> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >>>> - DebugTexturesOff : >>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>> >>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is a >>>> blending problem. When we activate Texture Debugging, a gray background is >>>> first drawn, and after that in the method RenderCharacter( ... ) line 1887; >>>> we either blend the rendered text with the background or not. >>>> >>>> Attached is a diff file that solves the problem for me. I do not really >>>> understand why, so maybe a developer with more VTK's knowledge can >>>> integrate this properly :) >>>> >>>> Thanks, >>>> Simon >>>> >>>> >>>> >>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : >>>> >>>>> Hi All, >>>>> >>>>> All vtkTextActor are rendered blurred when using with >>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>> new rendering backend. >>>>> >>>>> Here are some snapshots : >>>>> - OpenGL1 >>>>> - OpenGL2 >>>>> >>>>> Attached some code that reproduces the problem, to be used with this >>>>> volume. >>>>> Visible on OSX and Windows to our knowledge, probably on more OS. >>>>> >>>>> The text is rendered properly when used with the old backend or when >>>>> using a vtkGPUVolumeRayCastMapper instead of >>>>> the vtkFixedPointVolumeRayCastMapper. >>>>> >>>>> Shall I feel a bug, is this a known issue ? >>>>> >>>>> Thanks, >>>>> Simon >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Please keep messages on-topic and check the VTK FAQ at: >>>> http://www.vtk.org/Wiki/VTK_FAQ >>>> >>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Tue Nov 17 06:53:09 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 17 Nov 2015 12:53:09 +0100 Subject: [vtk-developers] Gil tests on megas Message-ID: Hi all I'm testing my GIl ensured version of VTK ( https://gitlab.kitware.com/vtk/vtk/merge_requests/582) with the buildbots, and i have only three problematic recurring tests, on a specific build of megas. the error look like : ========================================================= Process id 17931 Caught SIGSEGV at 0x7fdf889e5050 address not mapped to object Program Stack: WARNING: The stack trace will not use advanced capabilities because this is a release build. 0x7fdfc4593b20 : ??? [(???) ???:-1] 0x7fdfc45fd93e : ??? [(???) ???:-1] 0x7fdfc43527f8 : PyVTKObject_FromPointer [(libvtkWrappingPython34Core-6.3.so.1) ???:-1] 0x7fdfc43529cc : PyVTKObject_New [(libvtkWrappingPython34Core-6.3.so.1) ???:-1] 0x7fdfc372a503 : ??? [(???) ???:-1] 0x7fdfc36d4db1 : PyObject_Call [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc3788406 : PyEval_EvalFrameEx [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc378d636 : PyEval_EvalCodeEx [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc378d6db : PyEval_EvalCode [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc3780a8d : ??? [(???) ???:-1] 0x7fdfc378c651 : PyEval_EvalFrameEx [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc378d636 : PyEval_EvalCodeEx [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc378d6db : PyEval_EvalCode [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc37a9954 : ??? [(???) ???:-1] 0x7fdfc37abb95 : PyRun_FileExFlags [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc37acc13 : PyRun_SimpleFileExFlags [(libpython3.4m.so.1.0) ???:-1] 0x7fdfc37c3964 : Py_Main [(libpython3.4m.so.1.0) ???:-1] 0x4023ce : main [(vtkpython) ???:-1] 0x7fdfc457f580 : __libc_start_main [(libc.so.6) ???:-1] 0x402be9 : _start [(vtkpython) ???:-1] ========================================================= So it may be related to my fiddling with python. But i'm unable to reproduce it manually on megas. What I have done so far : - Tests using the buildbots, you can see the last batch here : https://open.cdash.org/index.php?compare1=63&filtercount=2&field1=buildname%2Fstring&project=VTK&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=6d631431&showfeed=0&value2=20151117T044431 - Accessing megas dashboards, checking my branch was checked out, checking it was compiled already (ninja-build), executing the command line visible in the failing test : /home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/build/bin/vtkpython "--enable-bt" "/home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/build/Utilities/vtkTclTest2Py/rtImageTest.py" "/home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/source/Filters/Core/Testing/Python/probeComb.py" "-D" "/home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/build/ExternalData//Testing" "-T" "/home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/build/Testing/Temporary" "-V" "/home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/build/ExternalData/Filters/Core/Testing/Data/Baseline/probeComb.png" "-A" "/home/kitware/dashboards/buildbot/vtk-megas-linux-shared-release_opengl1_python_python3_qt_qt5/build/Utilities/vtkTclTest2Py" Which fails with an Xerror - Executing it with DISPLAY=:0 fail on image size - Executing it with DISPLAY=:1 simple pass the test ! - Repushing on my branch, waiting for the buildbot, same tests still fails ! May be i'm doing something not rigth here, any help apreciated. Mathieu Westphal PS: I unvoluntarly deleted the kitware crontab, but it was pointing on a non existente file, so i supose it's ok. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Tue Nov 17 07:37:28 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Tue, 17 Nov 2015 13:37:28 +0100 Subject: [vtk-developers] Mix of TextMapper color and Actor2d color broken Message-ID: Hi, There is an issue when combining vtkTextMapper->GetTextProperty()->SetColor and vtkActor2D->GetProperty()->SetColor Before digging into what causes the issue, i would like to know what is the expected result? here are different behaviours when setting a vtkTextMapper to a vtkActor2D: with VTK 5.10 : TextProperty RED + ActorProperty WHITE => Text RED TextProperty WHITE + ActorProperty GREEN => Text WHITE TextProperty RED + ActorProperty GREEN => Text RED with VTK 6.3 and master, OpenGL 1&2: TextProperty RED + ActorProperty WHITE => Text RED TextProperty WHITE + ActorProperty GREEN => Text GREEN TextProperty RED + ActorProperty GREEN => Text BLACK with vtk 5.10, the vtkTextProperty has always priority, whereas with newer versions if only one color is set it is taken into acount, with an obvious issue when both of them are set. here is a simple test: #include #include #include #include #include #include #include #include int main ( int argc, char *argv[] ) { vtkSmartPointer renderer = vtkSmartPointer::New(); vtkSmartPointer renderWindow = vtkSmartPointer::New(); renderWindow->AddRenderer(renderer); vtkSmartPointer renderWindowInteractor = vtkSmartPointer::New(); renderWindowInteractor->SetRenderWindow(renderWindow); vtkSmartPointer textmap = vtkSmartPointer::New(); textmap->SetInput("TEST"); textmap->GetTextProperty()->SetColor(1, 0, 0); vtkSmartPointer actor2D = vtkSmartPointer::New(); actor2D->SetMapper(textmap); actor2D->GetProperty()->SetColor(0, 1, 0); renderer->AddActor2D(actor2D); renderWindow->Render(); renderWindowInteractor->Start(); return EXIT_SUCCESS; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Tue Nov 17 08:56:56 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 17 Nov 2015 08:56:56 -0500 Subject: [vtk-developers] int to bool patch, white space convention? In-Reply-To: <20151117043520.1487807312@mail.rogue-research.com> References: <20151117043520.1487807312@mail.rogue-research.com> Message-ID: I commented on the gitlab issue, but I'll reiterate here. I'm worried about backwards incompatibilities this might introduce. In most cases, you should be fine. But I have suspicions things may be more complicated than they first appear. With ITK a few years back, there was a seemingly innocent change of a common parameter from 'int' to 'unsigned int'. In principle this made sense because this parameter represented a number of threads, but it caused numerous problems that were hard to foresee. We'll need to test ParaView build with this change at the very least... Thanks, Cory On Mon, Nov 16, 2015 at 11:35 PM, Sean McBride wrote: > Hi all, > > I'm working on a patch that changes some VTK APIs that use 'int' to > instead use 'bool'. I've used a bunch of regexes to find vtkBooleanMacro > uses, ex: > > vtkSetMacro\((.*),int\);\r vtkGetMacro\(\1,int\);\r > vtkBooleanMacro\(\1,int\); > > I've discovered there's a variety of a) whitespace b) ordering, ex: > > vtkSetMacro(foo, bool); > vtkGetMacro(foo, bool); > vtkBooleanMacro(foo, bool); > > vs > > vtkBooleanMacro(bar,bool); > vtkSetMacro(bar,bool); > vtkGetMacro(bar,bool); > > Shall I take this opportunity to make everything uniform? > > The most common form is: > > vtkSetMacro(foo,int); > vtkGetMacro(foo,int); > vtkBooleanMacro(foo,int); > > The 2nd most common is the same order, but with a space after the comma. > The style guide seems to have examples of both. Is one preferred? > > Here's my WIP: > > > 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 > > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Tue Nov 17 09:28:41 2015 From: david.lonie at kitware.com (David Lonie) Date: Tue, 17 Nov 2015 09:28:41 -0500 Subject: [vtk-developers] Mix of TextMapper color and Actor2d color broken In-Reply-To: References: Message-ID: On Tue, Nov 17, 2015 at 7:37 AM, Xabi Riobe wrote: > Hi, > > There is an issue when > combining vtkTextMapper->GetTextProperty()->SetColor and > vtkActor2D->GetProperty()->SetColor > > Before digging into what causes the issue, i would like to know what is > the expected result? > > here are different behaviours when setting a vtkTextMapper to a vtkActor2D: > > with VTK 5.10 : > > TextProperty RED + ActorProperty WHITE => Text RED > TextProperty WHITE + ActorProperty GREEN => Text WHITE > TextProperty RED + ActorProperty GREEN => Text RED > > with VTK 6.3 and master, OpenGL 1&2: > > TextProperty RED + ActorProperty WHITE => Text RED > TextProperty WHITE + ActorProperty GREEN => Text GREEN > TextProperty RED + ActorProperty GREEN => Text BLACK > > with vtk 5.10, the vtkTextProperty has always priority, whereas with newer > versions if only one color is set it is taken into acount, with an obvious > issue when both of them are set. > I'm not sure this was ever well defined behavior, but someone can correct me if I'm wrong. I've typically followed the rule of always setting the color on the text property and leaving the actor color untouched. This should always yield the intended result of rendering the text property's color. I can't think of a usecase off the top of my head where setting both would have any meaningful utility. If there are any such usages, we should use those to determine what the "correct" behavior would be. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Tue Nov 17 09:56:29 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Tue, 17 Nov 2015 15:56:29 +0100 Subject: [vtk-developers] Mix of TextMapper color and Actor2d color broken In-Reply-To: References: Message-ID: It's ok for me as i now also ensure to set the color only to the text property, but the red+green=black situation seems to be a bug somewhere in the vtk code. A usecase can be: first take a global preference for color text that you apply to the text property, then if the actor is "packaged" with other ones as a group and you change the color of the group, the color is set to all the actors properties without knowing if there are text related or not. In this scenario we can think that the actor property should have the priority, but i am sure we can think of another one that states the opposite. So in my opinion, if anything is to be modified, i would choose what makes more sense according to the implementation of the final coloring... Xabi 2015-11-17 15:28 GMT+01:00 David Lonie : > On Tue, Nov 17, 2015 at 7:37 AM, Xabi Riobe wrote: > >> Hi, >> >> There is an issue when >> combining vtkTextMapper->GetTextProperty()->SetColor and >> vtkActor2D->GetProperty()->SetColor >> >> Before digging into what causes the issue, i would like to know what is >> the expected result? >> >> here are different behaviours when setting a vtkTextMapper to a >> vtkActor2D: >> >> with VTK 5.10 : >> >> TextProperty RED + ActorProperty WHITE => Text RED >> TextProperty WHITE + ActorProperty GREEN => Text WHITE >> TextProperty RED + ActorProperty GREEN => Text RED >> >> with VTK 6.3 and master, OpenGL 1&2: >> >> TextProperty RED + ActorProperty WHITE => Text RED >> TextProperty WHITE + ActorProperty GREEN => Text GREEN >> TextProperty RED + ActorProperty GREEN => Text BLACK >> >> with vtk 5.10, the vtkTextProperty has always priority, whereas with >> newer versions if only one color is set it is taken into acount, with an >> obvious issue when both of them are set. >> > > I'm not sure this was ever well defined behavior, but someone can correct > me if I'm wrong. I've typically followed the rule of always setting the > color on the text property and leaving the actor color untouched. This > should always yield the intended result of rendering the text property's > color. > > I can't think of a usecase off the top of my head where setting both would > have any meaningful utility. If there are any such usages, we should use > those to determine what the "correct" behavior would be. > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Nov 17 10:19:50 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 17 Nov 2015 10:19:50 -0500 Subject: [vtk-developers] int to bool patch, white space convention? In-Reply-To: References: <20151117043520.1487807312@mail.rogue-research.com> Message-ID: <20151117151950.1826518156@mail.rogue-research.com> On Tue, 17 Nov 2015 08:56:56 -0500, Cory Quammen said: >I commented on the gitlab issue, but I'll reiterate here. I'm worried about >backwards incompatibilities this might introduce. In most cases, you should >be fine. But I have suspicions things may be more complicated than they >first appear. Yes, it's a slight backwards compatibility break. The last commit (of 4) shows the kind of compile issues that could result. The biggest example is probably if you override the changed methods, you'd need your overrides to match signature. It's a tradeoff. We gain clearer code, better self-documentation, possibility of better compiler warnings (like SetBoolThing(123) could now warn). >We'll need to test ParaView build with this change at the very least... Thanks! Sean From aashish.chaudhary at kitware.com Tue Nov 17 10:50:58 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 17 Nov 2015 10:50:58 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT wrote: > Dear Aashish, > > Yes the root cause is probably located in vtkTexturedActor2D, or in > vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible > class for loading the texture. > Shall I fill a bug ? > Yes, please. - Aashish > Thanks > Simon > > 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> I see so its not just related to volume rendering and it seems to be a >> vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >> take a look at it. Nonetheless, we will follow up on this bug. >> >> - Aashish >> >> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >> simon.esneault at gmail.com> wrote: >> >>> Hello Aashish, >>> >>> Thanks ! >>> After doing some test, I realized the patch I've just sent is not the >>> correct fix at all, because the text is not rendered properly when we don't >>> use a vtkFixedPointVolumeRayCastMapper anymore. >>> >>> I believe the problem is probably larger than this and probably has >>> nothing to do with the freetype text generation, but more with the >>> vtkTexturedActor2D rendering part used together with a >>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>> texture has some transparent pixel in it ... >>> >>> Attached there is a new example that demonstrate that a vtkTextActor AND >>> a vtkTexturedButtonRepresentation2D are not correctly drawn in that case : >>> - OpenGL1 backend >>> : Transparent >>> pixel in Texture are correctly drawn >>> - OpenGL2 backend >>> : >>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>> >>> The example is more simple than the previous one and does not need any >>> additional data. >>> >>> Hope that helps ! >>> -Simon >>> >>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> Simon, >>>> >>>> Thanks for the report. I will follow up with other developers on this >>>> bug. >>>> >>>> - Aashish >>>> >>>> >>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> Trying to solve this problem, I found out that if one call >>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>> at the anchor point, and with a transparent gray background. >>>>> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >>>>> - DebugTexturesOff : >>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>> >>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is a >>>>> blending problem. When we activate Texture Debugging, a gray background is >>>>> first drawn, and after that in the method RenderCharacter( ... ) line 1887; >>>>> we either blend the rendered text with the background or not. >>>>> >>>>> Attached is a diff file that solves the problem for me. I do not >>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>> integrate this properly :) >>>>> >>>>> Thanks, >>>>> Simon >>>>> >>>>> >>>>> >>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : >>>>> >>>>>> Hi All, >>>>>> >>>>>> All vtkTextActor are rendered blurred when using with >>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>> new rendering backend. >>>>>> >>>>>> Here are some snapshots : >>>>>> - OpenGL1 >>>>>> - OpenGL2 >>>>>> >>>>>> Attached some code that reproduces the problem, to be used with this >>>>>> volume. >>>>>> Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>> >>>>>> The text is rendered properly when used with the old backend or when >>>>>> using a vtkGPUVolumeRayCastMapper instead of >>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>> >>>>>> Shall I feel a bug, is this a known issue ? >>>>>> >>>>>> Thanks, >>>>>> Simon >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>> >>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Nov 17 14:12:31 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Nov 2015 14:12:31 -0500 Subject: [vtk-developers] Gil tests on megas In-Reply-To: References: Message-ID: <20151117191231.GB28343@megas.khq.kitware.com> On Tue, Nov 17, 2015 at 12:53:09 +0100, Mathieu Westphal wrote: > So it may be related to my fiddling with python. So this problem has cropped up occasionally on the builder, seemingly randomly. I don't know the root cause (IIRC, it occurs in Python2 as well, but if we have a reproducer, tracking it down while we have it happening reliably would be good). > But i'm unable to reproduce it manually on megas. I believe it is related to the "_strict" feature megas uses which sets some environment variables: - 'MALLOC_PERTURB_': str(random.randint(1, 255)), - 'MALLOC_CHECK_': '3', - 'MEMCPY_CHECK_': '1', which means that memory is getting junked somewhere. Valgrind should have more information. > Which fails with an Xerror > > - Executing it with DISPLAY=:0 fail on image size > - Executing it with DISPLAY=:1 simple pass the test ! DISPLAY :0 is my user's X (it is my main development machine); :1 is the VNC server the dashboards should be using. > - Repushing on my branch, waiting for the buildbot, same tests still fails ! > > May be i'm doing something not rigth here, any help apreciated. I think valgrind is the next step. > PS: I unvoluntarly deleted the kitware crontab, but it was pointing on a > non existente file, so i supose it's ok. Yeah, the crontab is probably obsolete, thanks. --Ben From simon.esneault at gmail.com Wed Nov 18 03:38:07 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Wed, 18 Nov 2015 09:38:07 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Morning ! http://www.vtk.org/Bug/view.php?id=15838 Let me know if there is anything I can do to solve this. Simon 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary : > > > On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT > wrote: > >> Dear Aashish, >> >> Yes the root cause is probably located in vtkTexturedActor2D, or in >> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >> class for loading the texture. >> Shall I fill a bug ? >> > > Yes, please. > > - Aashish > > >> Thanks >> Simon >> >> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> I see so its not just related to volume rendering and it seems to be a >>> vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >>> take a look at it. Nonetheless, we will follow up on this bug. >>> >>> - Aashish >>> >>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Hello Aashish, >>>> >>>> Thanks ! >>>> After doing some test, I realized the patch I've just sent is not the >>>> correct fix at all, because the text is not rendered properly when we don't >>>> use a vtkFixedPointVolumeRayCastMapper anymore. >>>> >>>> I believe the problem is probably larger than this and probably has >>>> nothing to do with the freetype text generation, but more with the >>>> vtkTexturedActor2D rendering part used together with a >>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>> texture has some transparent pixel in it ... >>>> >>>> Attached there is a new example that demonstrate that a vtkTextActor >>>> AND a vtkTexturedButtonRepresentation2D are not correctly drawn in that >>>> case : >>>> - OpenGL1 backend >>>> : Transparent >>>> pixel in Texture are correctly drawn >>>> - OpenGL2 backend >>>> : >>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>> >>>> The example is more simple than the previous one and does not need any >>>> additional data. >>>> >>>> Hope that helps ! >>>> -Simon >>>> >>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> Simon, >>>>> >>>>> Thanks for the report. I will follow up with other developers on this >>>>> bug. >>>>> >>>>> - Aashish >>>>> >>>>> >>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Trying to solve this problem, I found out that if one call >>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>> at the anchor point, and with a transparent gray background. >>>>>> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>> - DebugTexturesOff : >>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>> >>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is >>>>>> a blending problem. When we activate Texture Debugging, a gray background >>>>>> is first drawn, and after that in the method RenderCharacter( ... ) line >>>>>> 1887; we either blend the rendered text with the background or not. >>>>>> >>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>> integrate this properly :) >>>>>> >>>>>> Thanks, >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT : >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>> new rendering backend. >>>>>>> >>>>>>> Here are some snapshots : >>>>>>> - OpenGL1 >>>>>>> >>>>>>> - OpenGL2 >>>>>>> >>>>>>> Attached some code that reproduces the problem, to be used with this >>>>>>> volume. >>>>>>> Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>> >>>>>>> The text is rendered properly when used with the old backend or when >>>>>>> using a vtkGPUVolumeRayCastMapper instead of >>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>> >>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>> >>>>>>> Thanks, >>>>>>> Simon >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>> >>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Wed Nov 18 04:06:39 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 18 Nov 2015 10:06:39 +0100 Subject: [vtk-developers] Gil tests on megas In-Reply-To: <20151117191231.GB28343@megas.khq.kitware.com> References: <20151117191231.GB28343@megas.khq.kitware.com> Message-ID: Hi I still cannot reproduce the issue with : export DISPLAY=:1 export MALLOC_PERTURB_="str(random.randint(1, 255))" export MALLOC_CHECK_=3 export MEMCPY_CHECK_=1 with or without the malloc/mem export, valgrind find some issue indeed, but valgrind find as much issue with a passing test (eg; .vtkChartsCorePython-TestBarGraph ), so i can't investigate further without being able to reproduce the issue. If you want to have a go, i will not touch my branch for a few days, before merging it anyway, since the bug is not linked to my changes. Mathieu Mathieu Westphal On Tue, Nov 17, 2015 at 8:12 PM, Ben Boeckel wrote: > On Tue, Nov 17, 2015 at 12:53:09 +0100, Mathieu Westphal wrote: > > So it may be related to my fiddling with python. > > So this problem has cropped up occasionally on the builder, seemingly > randomly. I don't know the root cause (IIRC, it occurs in Python2 as > well, but if we have a reproducer, tracking it down while we have it > happening reliably would be good). > > > But i'm unable to reproduce it manually on megas. > > I believe it is related to the "_strict" feature megas uses which sets > some environment variables: > > - 'MALLOC_PERTURB_': str(random.randint(1, 255)), > - 'MALLOC_CHECK_': '3', > - 'MEMCPY_CHECK_': '1', > > which means that memory is getting junked somewhere. Valgrind should > have more information. > > > Which fails with an Xerror > > > > - Executing it with DISPLAY=:0 fail on image size > > - Executing it with DISPLAY=:1 simple pass the test ! > > DISPLAY :0 is my user's X (it is my main development machine); :1 is the > VNC server the dashboards should be using. > > > - Repushing on my branch, waiting for the buildbot, same tests still > fails ! > > > > May be i'm doing something not rigth here, any help apreciated. > > I think valgrind is the next step. > > > PS: I unvoluntarly deleted the kitware crontab, but it was pointing on a > > non existente file, so i supose it's ok. > > Yeah, the crontab is probably obsolete, thanks. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Wed Nov 18 08:55:39 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Wed, 18 Nov 2015 14:55:39 +0100 Subject: [vtk-developers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX In-Reply-To: References: Message-ID: Hello, I've created a bug in Mantis for this http://www.vtk.org/Bug/view.php?id=15840 Looking at the code in QVTKWidget.cxx, here is the part that may be causing the problem, because it handles the reparenting part... */*******************************************************************************/* *if(e->type() == QEvent::ParentAboutToChange)* * {* * this->markCachedImageAsDirty();* * if (this->mRenWin)* * {* * // Finalize the window to remove graphics resources associated with* * // this window* * if(this->mRenWin->GetMapped())* * {* * this->mRenWin->Finalize();* * }* * }* * }* * else if(e->type() == QEvent::ParentChange)* * {* * if(this->mRenWin)* * {* * x11_setup_window();* * // connect to new window* * this->mRenWin->SetWindowId( reinterpret_cast(this->winId()));* * // start up the window to create graphics resources for this window* * if(isVisible())* * {* * this->mRenWin->Start();* * }* * }* * }* */*******************************************************************************/* Were there any significant changes in the methods GetMapped() / Finalize() / Start() of vtkRenderWindow (or children implementation) during the development of the new rendering backend that may lead to such a crash : */*******************************************************************************/* *ERROR: In /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, line 354* *vtkShaderProgram (0x6000001809c0): 1: #version 120* *2: #define highp* *3: #define mediump* *4: #define lowp* *5: * *6: /*=========================================================================* *7: * *8: Program: Visualization Toolkit* *9: Module: vtkPolyDataVS.glsl* *10: * *11: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen* *12: All rights reserved.* *13: See Copyright.txt or http://www.kitware.com/Copyright.htm for details.* *14: * *15: This software is distributed WITHOUT ANY WARRANTY; without even* *16: the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR* *17: PURPOSE. See the above copyright notice for more information.* *18: * *19: =========================================================================*/* *20: * *21: attribute vec4 vertexMC;* *22: * *23: // frag position in VC* *24: varying vec4 vertexVCVSOutput;* *25: * *26: // optional normal declaration* *27: attribute vec3 normalMC;* *28: uniform mat3 normalMatrix;* *29: varying vec3 normalVCVSOutput;* *30: * *31: // extra lighting parameters* *32: //VTK::Light::Dec* *33: * *34: // Texture coordinates* *35: //VTK::TCoord::Dec* *36: * *37: // material property values* *38: //VTK::Color::Dec* *39: * *40: // clipping plane vars* *41: //VTK::Clip::Dec* *42: * *43: // camera and actor matrix values* *44: uniform mat4 MCDCMatrix;* *45: uniform mat4 MCVCMatrix;* *46: * *47: // Apple Bug* *48: //VTK::PrimID::Dec* *49: * *50: void main()* *51: {* *52: //VTK::Color::Impl* *53: * *54: normalVCVSOutput = normalMatrix * normalMC;* *55: * *56: //VTK::TCoord::Impl* *57: * *58: //VTK::Clip::Impl* *59: * *60: //VTK::PrimID::Impl* *61: * *62: vertexVCVSOutput = MCVCMatrix * vertexMC;* *63: gl_Position = MCDCMatrix * vertexMC;* *64: * *65: * *66: //VTK::Light::Impl* *67: }* *68: * *ERROR: In /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, line 355* *vtkShaderProgram (0x6000001809c0): ERROR: 0:1: '' : version '120' is not supported* *ERROR: 0:2: '' : #version required and missing.* *ERROR: 0:21: 'attribute' : syntax error: syntax error* *(lldb) bt* ** thread #1: tid = 0x600e30, 0x0000000100609f1f VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x60)* * * frame #0: 0x0000000100609f1f VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31* * frame #1: 0x00000001006074ab VtkReparentingProblem`vtkShaderProgram::SetUniformi(char const*, int) + 27* * frame #2: 0x00000001005b8c28 VtkReparentingProblem`vtkOpenGLPolyDataMapper::SetMapperShaderParameters(vtkOpenGLHelper&, vtkRenderer*, vtkActor*) + 72* * frame #3: 0x00000001005b8b1b VtkReparentingProblem`vtkOpenGLPolyDataMapper::UpdateShaders(vtkOpenGLHelper&, vtkRenderer*, vtkActor*) + 1211* * frame #4: 0x00000001005bb782 VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPieceDraw(vtkRenderer*, vtkActor*) + 818* * frame #5: 0x00000001005bbbe3 VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, vtkActor*) + 195* * frame #6: 0x00000001004ba1fe VtkReparentingProblem`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 174* * frame #7: 0x0000000100561be0 VtkReparentingProblem`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 144* * frame #8: 0x00000001004667c3 VtkReparentingProblem`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435* * frame #9: 0x00000001005caa87 VtkReparentingProblem`vtkOpenGLRenderer::UpdateGeometry() + 263* * frame #10: 0x00000001005ca945 VtkReparentingProblem`vtkOpenGLRenderer::DeviceRender() + 181* * frame #11: 0x00000001004cb96c VtkReparentingProblem`vtkRenderer::Render() + 604* * frame #12: 0x00000001004d08cc VtkReparentingProblem`vtkRendererCollection::Render() + 92* * frame #13: 0x00000001004c5d1a VtkReparentingProblem`vtkRenderWindow::DoStereoRender() + 138* * frame #14: 0x00000001004c5098 VtkReparentingProblem`vtkRenderWindow::Render() + 328* * frame #15: 0x00000001005c7816 VtkReparentingProblem`vtkOpenGLRenderWindow::Render() + 22* * frame #16: 0x00000001004c8f17 VtkReparentingProblem`vtkRenderWindowInteractor::Render() + 39* * frame #17: 0x00000001006831dd VtkReparentingProblem`QVTKWidget::paintEvent(QPaintEvent*) + 109* * frame #18: 0x0000000100bb73d6 QtWidgets`QWidget::event(QEvent*) + 1958* * frame #19: 0x0000000100683079 VtkReparentingProblem`QVTKWidget::event(QEvent*) + 281* * frame #20: 0x0000000100b7effc QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* * frame #21: 0x0000000100b81abb QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* * frame #22: 0x0000000101902932 QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* * frame #23: 0x0000000100bb2035 QtWidgets`QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 2997* * frame #24: 0x0000000100b8aed0 QtWidgets`QWidgetPrivate::repaint_sys(QRegion const&) + 400* * frame #25: 0x0000000100bd4987 QtWidgets`QWidgetWindow::event(QEvent*) + 423* * frame #26: 0x0000000100b7effc QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* * frame #27: 0x0000000100b81abb QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* * frame #28: 0x0000000101902932 QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* * frame #29: 0x00000001011c4d7a QtGui`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) + 314* * frame #30: 0x00000001011c08a7 QtGui`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) + 951* * frame #31: 0x00000001011af1cb QtGui`QWindowSystemInterface::sendWindowSystemEvents(QFlags) + 315* * frame #32: 0x0000000104a39f0d libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents() + 317* * frame #33: 0x0000000104a3a8a8 libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) + 40* * frame #34: 0x00007fff8f9e3a01 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17* * frame #35: 0x00007fff8f9d5b8d CoreFoundation`__CFRunLoopDoSources0 + 269* * frame #36: 0x00007fff8f9d51bf CoreFoundation`__CFRunLoopRun + 927* * frame #37: 0x00007fff8f9d4bd8 CoreFoundation`CFRunLoopRunSpecific + 296* * frame #38: 0x00007fff8b65f56f HIToolbox`RunCurrentEventLoopInMode + 235* * frame #39: 0x00007fff8b65f2ea HIToolbox`ReceiveNextEventCommon + 431* * frame #40: 0x00007fff8b65f12b HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71* * frame #41: 0x00007fff894cf8ab AppKit`_DPSNextEvent + 978* * frame #42: 0x00007fff894cee58 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346* * frame #43: 0x00007fff894c4af3 AppKit`-[NSApplication run] + 594* * frame #44: 0x0000000104a395e4 libqcocoa.dylib`QCocoaEventDispatcher::processEvents(QFlags) + 2420* * frame #45: 0x00000001018ff9ad QtCore`QEventLoop::exec(QFlags) + 381* * frame #46: 0x0000000101902ee7 QtCore`QCoreApplication::exec() + 359* * frame #47: 0x0000000100005dab VtkReparentingProblem`main + 59* * frame #48: 0x0000000100005d64 VtkReparentingProblem`start + 52* */*******************************************************************************/* Any hints ? Regards, Simon 2015-11-17 9:27 GMT+01:00 Simon ESNEAULT : > Hello, > > After the switch to the new rendering backend, we have a crash on our > program after reparenting a QVTKWidget on OSX. The crash is in the > method vtkShaderProgram::FindUniform() but we suspect it is about the > OpenGL context not being ready on time for the next paintEvent with the new > parent. > > Attached is a program that reproduce the problem, as well as a complete > backtrace for this crash. This used to work fine with the previous backend. > > Hope this little test case helps > > Thanks > Simon > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Nov 18 09:15:08 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 18 Nov 2015 09:15:08 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX In-Reply-To: References: Message-ID: I know zippo about Qt, but the version 120 error means that VTK thinks it has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context On Wed, Nov 18, 2015 at 8:55 AM, Simon ESNEAULT wrote: > Hello, > > I've created a bug in Mantis for this > http://www.vtk.org/Bug/view.php?id=15840 > > Looking at the code in QVTKWidget.cxx, here is the part that may be > causing the problem, because it handles the reparenting part... > > > > */*******************************************************************************/* > *if(e->type() == QEvent::ParentAboutToChange)* > * {* > * this->markCachedImageAsDirty();* > * if (this->mRenWin)* > * {* > * // Finalize the window to remove graphics resources associated with* > * // this window* > * if(this->mRenWin->GetMapped())* > * {* > * this->mRenWin->Finalize();* > * }* > * }* > * }* > * else if(e->type() == QEvent::ParentChange)* > * {* > * if(this->mRenWin)* > * {* > * x11_setup_window();* > * // connect to new window* > * this->mRenWin->SetWindowId( > reinterpret_cast(this->winId()));* > > * // start up the window to create graphics resources for this window* > * if(isVisible())* > * {* > * this->mRenWin->Start();* > * }* > * }* > * }* > > */*******************************************************************************/* > > Were there any significant changes in the methods GetMapped() / Finalize() > / Start() of vtkRenderWindow (or children implementation) during the > development of the new rendering backend that may lead to such a crash : > > > > */*******************************************************************************/* > *ERROR: In > /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, > line 354* > *vtkShaderProgram (0x6000001809c0): 1: #version 120* > *2: #define highp* > *3: #define mediump* > *4: #define lowp* > *5: * > *6: > /*=========================================================================* > *7: * > *8: Program: Visualization Toolkit* > *9: Module: vtkPolyDataVS.glsl* > *10: * > *11: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen* > *12: All rights reserved.* > *13: See Copyright.txt or http://www.kitware.com/Copyright.htm > for details.* > *14: * > *15: This software is distributed WITHOUT ANY WARRANTY; without even* > *16: the implied warranty of MERCHANTABILITY or FITNESS FOR A > PARTICULAR* > *17: PURPOSE. See the above copyright notice for more information.* > *18: * > *19: > =========================================================================*/* > *20: * > *21: attribute vec4 vertexMC;* > *22: * > *23: // frag position in VC* > *24: varying vec4 vertexVCVSOutput;* > *25: * > *26: // optional normal declaration* > *27: attribute vec3 normalMC;* > *28: uniform mat3 normalMatrix;* > *29: varying vec3 normalVCVSOutput;* > *30: * > *31: // extra lighting parameters* > *32: //VTK::Light::Dec* > *33: * > *34: // Texture coordinates* > *35: //VTK::TCoord::Dec* > *36: * > *37: // material property values* > *38: //VTK::Color::Dec* > *39: * > *40: // clipping plane vars* > *41: //VTK::Clip::Dec* > *42: * > *43: // camera and actor matrix values* > *44: uniform mat4 MCDCMatrix;* > *45: uniform mat4 MCVCMatrix;* > *46: * > *47: // Apple Bug* > *48: //VTK::PrimID::Dec* > *49: * > *50: void main()* > *51: {* > *52: //VTK::Color::Impl* > *53: * > *54: normalVCVSOutput = normalMatrix * normalMC;* > *55: * > *56: //VTK::TCoord::Impl* > *57: * > *58: //VTK::Clip::Impl* > *59: * > *60: //VTK::PrimID::Impl* > *61: * > *62: vertexVCVSOutput = MCVCMatrix * vertexMC;* > *63: gl_Position = MCDCMatrix * vertexMC;* > *64: * > *65: * > *66: //VTK::Light::Impl* > *67: }* > *68: * > > > *ERROR: In > /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, > line 355* > *vtkShaderProgram (0x6000001809c0): ERROR: 0:1: '' : version '120' is not > supported* > *ERROR: 0:2: '' : #version required and missing.* > *ERROR: 0:21: 'attribute' : syntax error: syntax error* > > > *(lldb) bt* > ** thread #1: tid = 0x600e30, 0x0000000100609f1f > VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31, > queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, > address=0x60)* > * * frame #0: 0x0000000100609f1f > VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31* > * frame #1: 0x00000001006074ab > VtkReparentingProblem`vtkShaderProgram::SetUniformi(char const*, int) + 27* > * frame #2: 0x00000001005b8c28 > VtkReparentingProblem`vtkOpenGLPolyDataMapper::SetMapperShaderParameters(vtkOpenGLHelper&, > vtkRenderer*, vtkActor*) + 72* > * frame #3: 0x00000001005b8b1b > VtkReparentingProblem`vtkOpenGLPolyDataMapper::UpdateShaders(vtkOpenGLHelper&, > vtkRenderer*, vtkActor*) + 1211* > * frame #4: 0x00000001005bb782 > VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPieceDraw(vtkRenderer*, > vtkActor*) + 818* > * frame #5: 0x00000001005bbbe3 > VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, > vtkActor*) + 195* > * frame #6: 0x00000001004ba1fe > VtkReparentingProblem`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + > 174* > * frame #7: 0x0000000100561be0 > VtkReparentingProblem`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + > 144* > * frame #8: 0x00000001004667c3 > VtkReparentingProblem`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435* > * frame #9: 0x00000001005caa87 > VtkReparentingProblem`vtkOpenGLRenderer::UpdateGeometry() + 263* > * frame #10: 0x00000001005ca945 > VtkReparentingProblem`vtkOpenGLRenderer::DeviceRender() + 181* > * frame #11: 0x00000001004cb96c > VtkReparentingProblem`vtkRenderer::Render() + 604* > * frame #12: 0x00000001004d08cc > VtkReparentingProblem`vtkRendererCollection::Render() + 92* > * frame #13: 0x00000001004c5d1a > VtkReparentingProblem`vtkRenderWindow::DoStereoRender() + 138* > * frame #14: 0x00000001004c5098 > VtkReparentingProblem`vtkRenderWindow::Render() + 328* > * frame #15: 0x00000001005c7816 > VtkReparentingProblem`vtkOpenGLRenderWindow::Render() + 22* > * frame #16: 0x00000001004c8f17 > VtkReparentingProblem`vtkRenderWindowInteractor::Render() + 39* > * frame #17: 0x00000001006831dd > VtkReparentingProblem`QVTKWidget::paintEvent(QPaintEvent*) + 109* > * frame #18: 0x0000000100bb73d6 QtWidgets`QWidget::event(QEvent*) + > 1958* > * frame #19: 0x0000000100683079 > VtkReparentingProblem`QVTKWidget::event(QEvent*) + 281* > * frame #20: 0x0000000100b7effc > QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* > * frame #21: 0x0000000100b81abb > QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* > * frame #22: 0x0000000101902932 > QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* > * frame #23: 0x0000000100bb2035 > QtWidgets`QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint > const&, int, QPainter*, QWidgetBackingStore*) + 2997* > * frame #24: 0x0000000100b8aed0 > QtWidgets`QWidgetPrivate::repaint_sys(QRegion const&) + 400* > * frame #25: 0x0000000100bd4987 QtWidgets`QWidgetWindow::event(QEvent*) > + 423* > * frame #26: 0x0000000100b7effc > QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* > * frame #27: 0x0000000100b81abb > QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* > * frame #28: 0x0000000101902932 > QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* > * frame #29: 0x00000001011c4d7a > QtGui`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) > + 314* > * frame #30: 0x00000001011c08a7 > QtGui`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) > + 951* > * frame #31: 0x00000001011af1cb > QtGui`QWindowSystemInterface::sendWindowSystemEvents(QFlags) > + 315* > * frame #32: 0x0000000104a39f0d > libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents() + 317* > * frame #33: 0x0000000104a3a8a8 > libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) > + 40* > * frame #34: 0x00007fff8f9e3a01 > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + > 17* > * frame #35: 0x00007fff8f9d5b8d CoreFoundation`__CFRunLoopDoSources0 + > 269* > * frame #36: 0x00007fff8f9d51bf CoreFoundation`__CFRunLoopRun + 927* > * frame #37: 0x00007fff8f9d4bd8 CoreFoundation`CFRunLoopRunSpecific + > 296* > * frame #38: 0x00007fff8b65f56f HIToolbox`RunCurrentEventLoopInMode + > 235* > * frame #39: 0x00007fff8b65f2ea HIToolbox`ReceiveNextEventCommon + 431* > * frame #40: 0x00007fff8b65f12b > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71* > * frame #41: 0x00007fff894cf8ab AppKit`_DPSNextEvent + 978* > * frame #42: 0x00007fff894cee58 AppKit`-[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] + 346* > * frame #43: 0x00007fff894c4af3 AppKit`-[NSApplication run] + 594* > * frame #44: 0x0000000104a395e4 > libqcocoa.dylib`QCocoaEventDispatcher::processEvents(QFlags) > + 2420* > * frame #45: 0x00000001018ff9ad > QtCore`QEventLoop::exec(QFlags) + 381* > * frame #46: 0x0000000101902ee7 QtCore`QCoreApplication::exec() + 359* > * frame #47: 0x0000000100005dab VtkReparentingProblem`main + 59* > * frame #48: 0x0000000100005d64 VtkReparentingProblem`start + 52* > > > */*******************************************************************************/* > > Any hints ? > > Regards, > Simon > > 2015-11-17 9:27 GMT+01:00 Simon ESNEAULT : > >> Hello, >> >> After the switch to the new rendering backend, we have a crash on our >> program after reparenting a QVTKWidget on OSX. The crash is in the >> method vtkShaderProgram::FindUniform() but we suspect it is about the >> OpenGL context not being ready on time for the next paintEvent with the new >> parent. >> >> Attached is a program that reproduce the problem, as well as a complete >> backtrace for this crash. This used to work fine with the previous backend. >> >> Hope this little test case helps >> >> Thanks >> Simon >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 Nov 18 09:21:57 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 18 Nov 2015 09:21:57 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX In-Reply-To: References: Message-ID: (sorry for the half written email, switching to the gmail web interface has me messing up) I know zippo about Qt, but the version 120 error means that VTK thinks it has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context // Description:: // Get if the context includes opengl core profile 3.2 support static bool GetContextSupportsOpenGL32(); void SetContextSupportsOpenGL32(bool val); it could be that the vtk Qt class is creating a 3.2 context but not setting the above methods to true? Or maybe somehow not calling void vtkOpenGLRenderWindow::OpenGLInitContext() Just a guess. Thanks Ken On Wed, Nov 18, 2015 at 9:15 AM, Ken Martin wrote: > I know zippo about Qt, but the version 120 error means that VTK thinks it > has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a > setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context > > > On Wed, Nov 18, 2015 at 8:55 AM, Simon ESNEAULT > wrote: > >> Hello, >> >> I've created a bug in Mantis for this >> http://www.vtk.org/Bug/view.php?id=15840 >> >> Looking at the code in QVTKWidget.cxx, here is the part that may be >> causing the problem, because it handles the reparenting part... >> >> >> >> */*******************************************************************************/* >> *if(e->type() == QEvent::ParentAboutToChange)* >> * {* >> * this->markCachedImageAsDirty();* >> * if (this->mRenWin)* >> * {* >> * // Finalize the window to remove graphics resources associated >> with* >> * // this window* >> * if(this->mRenWin->GetMapped())* >> * {* >> * this->mRenWin->Finalize();* >> * }* >> * }* >> * }* >> * else if(e->type() == QEvent::ParentChange)* >> * {* >> * if(this->mRenWin)* >> * {* >> * x11_setup_window();* >> * // connect to new window* >> * this->mRenWin->SetWindowId( >> reinterpret_cast(this->winId()));* >> >> * // start up the window to create graphics resources for this >> window* >> * if(isVisible())* >> * {* >> * this->mRenWin->Start();* >> * }* >> * }* >> * }* >> >> */*******************************************************************************/* >> >> Were there any significant changes in the methods GetMapped() / >> Finalize() / Start() of vtkRenderWindow (or children implementation) during >> the development of the new rendering backend that may lead to such a crash >> : >> >> >> >> */*******************************************************************************/* >> *ERROR: In >> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >> line 354* >> *vtkShaderProgram (0x6000001809c0): 1: #version 120* >> *2: #define highp* >> *3: #define mediump* >> *4: #define lowp* >> *5: * >> *6: >> /*=========================================================================* >> *7: * >> *8: Program: Visualization Toolkit* >> *9: Module: vtkPolyDataVS.glsl* >> *10: * >> *11: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen* >> *12: All rights reserved.* >> *13: See Copyright.txt or http://www.kitware.com/Copyright.htm >> for details.* >> *14: * >> *15: This software is distributed WITHOUT ANY WARRANTY; without even* >> *16: the implied warranty of MERCHANTABILITY or FITNESS FOR A >> PARTICULAR* >> *17: PURPOSE. See the above copyright notice for more information.* >> *18: * >> *19: >> =========================================================================*/* >> *20: * >> *21: attribute vec4 vertexMC;* >> *22: * >> *23: // frag position in VC* >> *24: varying vec4 vertexVCVSOutput;* >> *25: * >> *26: // optional normal declaration* >> *27: attribute vec3 normalMC;* >> *28: uniform mat3 normalMatrix;* >> *29: varying vec3 normalVCVSOutput;* >> *30: * >> *31: // extra lighting parameters* >> *32: //VTK::Light::Dec* >> *33: * >> *34: // Texture coordinates* >> *35: //VTK::TCoord::Dec* >> *36: * >> *37: // material property values* >> *38: //VTK::Color::Dec* >> *39: * >> *40: // clipping plane vars* >> *41: //VTK::Clip::Dec* >> *42: * >> *43: // camera and actor matrix values* >> *44: uniform mat4 MCDCMatrix;* >> *45: uniform mat4 MCVCMatrix;* >> *46: * >> *47: // Apple Bug* >> *48: //VTK::PrimID::Dec* >> *49: * >> *50: void main()* >> *51: {* >> *52: //VTK::Color::Impl* >> *53: * >> *54: normalVCVSOutput = normalMatrix * normalMC;* >> *55: * >> *56: //VTK::TCoord::Impl* >> *57: * >> *58: //VTK::Clip::Impl* >> *59: * >> *60: //VTK::PrimID::Impl* >> *61: * >> *62: vertexVCVSOutput = MCVCMatrix * vertexMC;* >> *63: gl_Position = MCDCMatrix * vertexMC;* >> *64: * >> *65: * >> *66: //VTK::Light::Impl* >> *67: }* >> *68: * >> >> >> *ERROR: In >> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >> line 355* >> *vtkShaderProgram (0x6000001809c0): ERROR: 0:1: '' : version '120' is >> not supported* >> *ERROR: 0:2: '' : #version required and missing.* >> *ERROR: 0:21: 'attribute' : syntax error: syntax error* >> >> >> *(lldb) bt* >> ** thread #1: tid = 0x600e30, 0x0000000100609f1f >> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31, >> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, >> address=0x60)* >> * * frame #0: 0x0000000100609f1f >> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31* >> * frame #1: 0x00000001006074ab >> VtkReparentingProblem`vtkShaderProgram::SetUniformi(char const*, int) + 27* >> * frame #2: 0x00000001005b8c28 >> VtkReparentingProblem`vtkOpenGLPolyDataMapper::SetMapperShaderParameters(vtkOpenGLHelper&, >> vtkRenderer*, vtkActor*) + 72* >> * frame #3: 0x00000001005b8b1b >> VtkReparentingProblem`vtkOpenGLPolyDataMapper::UpdateShaders(vtkOpenGLHelper&, >> vtkRenderer*, vtkActor*) + 1211* >> * frame #4: 0x00000001005bb782 >> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPieceDraw(vtkRenderer*, >> vtkActor*) + 818* >> * frame #5: 0x00000001005bbbe3 >> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, >> vtkActor*) + 195* >> * frame #6: 0x00000001004ba1fe >> VtkReparentingProblem`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + >> 174* >> * frame #7: 0x0000000100561be0 >> VtkReparentingProblem`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + >> 144* >> * frame #8: 0x00000001004667c3 >> VtkReparentingProblem`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435* >> * frame #9: 0x00000001005caa87 >> VtkReparentingProblem`vtkOpenGLRenderer::UpdateGeometry() + 263* >> * frame #10: 0x00000001005ca945 >> VtkReparentingProblem`vtkOpenGLRenderer::DeviceRender() + 181* >> * frame #11: 0x00000001004cb96c >> VtkReparentingProblem`vtkRenderer::Render() + 604* >> * frame #12: 0x00000001004d08cc >> VtkReparentingProblem`vtkRendererCollection::Render() + 92* >> * frame #13: 0x00000001004c5d1a >> VtkReparentingProblem`vtkRenderWindow::DoStereoRender() + 138* >> * frame #14: 0x00000001004c5098 >> VtkReparentingProblem`vtkRenderWindow::Render() + 328* >> * frame #15: 0x00000001005c7816 >> VtkReparentingProblem`vtkOpenGLRenderWindow::Render() + 22* >> * frame #16: 0x00000001004c8f17 >> VtkReparentingProblem`vtkRenderWindowInteractor::Render() + 39* >> * frame #17: 0x00000001006831dd >> VtkReparentingProblem`QVTKWidget::paintEvent(QPaintEvent*) + 109* >> * frame #18: 0x0000000100bb73d6 QtWidgets`QWidget::event(QEvent*) + >> 1958* >> * frame #19: 0x0000000100683079 >> VtkReparentingProblem`QVTKWidget::event(QEvent*) + 281* >> * frame #20: 0x0000000100b7effc >> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >> * frame #21: 0x0000000100b81abb >> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >> * frame #22: 0x0000000101902932 >> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >> * frame #23: 0x0000000100bb2035 >> QtWidgets`QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint >> const&, int, QPainter*, QWidgetBackingStore*) + 2997* >> * frame #24: 0x0000000100b8aed0 >> QtWidgets`QWidgetPrivate::repaint_sys(QRegion const&) + 400* >> * frame #25: 0x0000000100bd4987 >> QtWidgets`QWidgetWindow::event(QEvent*) + 423* >> * frame #26: 0x0000000100b7effc >> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >> * frame #27: 0x0000000100b81abb >> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >> * frame #28: 0x0000000101902932 >> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >> * frame #29: 0x00000001011c4d7a >> QtGui`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) >> + 314* >> * frame #30: 0x00000001011c08a7 >> QtGui`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) >> + 951* >> * frame #31: 0x00000001011af1cb >> QtGui`QWindowSystemInterface::sendWindowSystemEvents(QFlags) >> + 315* >> * frame #32: 0x0000000104a39f0d >> libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents() + 317* >> * frame #33: 0x0000000104a3a8a8 >> libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) >> + 40* >> * frame #34: 0x00007fff8f9e3a01 >> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + >> 17* >> * frame #35: 0x00007fff8f9d5b8d CoreFoundation`__CFRunLoopDoSources0 + >> 269* >> * frame #36: 0x00007fff8f9d51bf CoreFoundation`__CFRunLoopRun + 927* >> * frame #37: 0x00007fff8f9d4bd8 CoreFoundation`CFRunLoopRunSpecific + >> 296* >> * frame #38: 0x00007fff8b65f56f HIToolbox`RunCurrentEventLoopInMode + >> 235* >> * frame #39: 0x00007fff8b65f2ea HIToolbox`ReceiveNextEventCommon + 431* >> * frame #40: 0x00007fff8b65f12b >> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71* >> * frame #41: 0x00007fff894cf8ab AppKit`_DPSNextEvent + 978* >> * frame #42: 0x00007fff894cee58 AppKit`-[NSApplication >> nextEventMatchingMask:untilDate:inMode:dequeue:] + 346* >> * frame #43: 0x00007fff894c4af3 AppKit`-[NSApplication run] + 594* >> * frame #44: 0x0000000104a395e4 >> libqcocoa.dylib`QCocoaEventDispatcher::processEvents(QFlags) >> + 2420* >> * frame #45: 0x00000001018ff9ad >> QtCore`QEventLoop::exec(QFlags) + 381* >> * frame #46: 0x0000000101902ee7 QtCore`QCoreApplication::exec() + 359* >> * frame #47: 0x0000000100005dab VtkReparentingProblem`main + 59* >> * frame #48: 0x0000000100005d64 VtkReparentingProblem`start + 52* >> >> >> */*******************************************************************************/* >> >> Any hints ? >> >> Regards, >> Simon >> >> 2015-11-17 9:27 GMT+01:00 Simon ESNEAULT : >> >>> Hello, >>> >>> After the switch to the new rendering backend, we have a crash on our >>> program after reparenting a QVTKWidget on OSX. The crash is in the >>> method vtkShaderProgram::FindUniform() but we suspect it is about the >>> OpenGL context not being ready on time for the next paintEvent with the new >>> parent. >>> >>> Attached is a program that reproduce the problem, as well as a complete >>> backtrace for this crash. This used to work fine with the previous backend. >>> >>> Hope this little test case helps >>> >>> Thanks >>> Simon >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Search the list archives at: http://markmail.org/search/?q=vtkusers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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 Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 Nov 18 10:55:45 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Nov 2015 10:55:45 -0500 Subject: [vtk-developers] MouseWheel event pending missing on windows wrt X11 In-Reply-To: References: Message-ID: <20151118155545.GA24519@megas.khq.kitware.com> On Mon, Nov 09, 2015 at 13:42:38 +0100, Xabi Riobe wrote: > So before pushing a branch on GitLab, could anyone with access to a X > platform or with good knowledge of this code can confirm this behaviour? I don't have good knowledge, but if I use the mousewheel on on a large dataset after manipulating it, it is still decimated until it completes the zoom. --Ben From david.gobbi at gmail.com Wed Nov 18 11:10:18 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 18 Nov 2015 09:10:18 -0700 Subject: [vtk-developers] FreeType: ftconfig.h appears in source tree and build tree Message-ID: Hi All, I'm not sure if this is something to be concerned about, but I noticed that the header "vtkfreetype/include/freetype/config/ftconfig.h" exists in the source tree even though it is config'd from "vtkfreetype/builds/unix/ftconfig.in". I found this when I accidentally ran "cmake" in my source directory, and then did "git status" as part of my usual "oops, lets clean up this mess" workflow. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Nov 18 11:13:56 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Nov 2015 11:13:56 -0500 Subject: [vtk-developers] Gil tests on megas In-Reply-To: References: <20151117191231.GB28343@megas.khq.kitware.com> Message-ID: <20151118161356.GC24519@megas.khq.kitware.com> On Wed, Nov 18, 2015 at 10:06:39 +0100, Mathieu Westphal wrote: > I still cannot reproduce the issue with : > export DISPLAY=:1 > export MALLOC_PERTURB_="str(random.randint(1, 255))" Ah, it's Python code :) . I doubt this is the cause since this flag makes free do: memset(freed_block, $MALLOC_PERTURB_, sizeof_freed_block) which would make pointers with values like 0xf3f3f3f3 crop up. > export MALLOC_CHECK_=3 > export MEMCPY_CHECK_=1 > > with or without the malloc/mem export, valgrind find some issue indeed, but > valgrind find as much issue with a passing test (eg; > .vtkChartsCorePython-TestBarGraph ), so i can't investigate further without > being able to reproduce the issue. > > If you want to have a go, i will not touch my branch for a few days, before > merging it anyway, since the bug is not linked to my changes. I'll try and take a look today. --Ben From xabivtk at gmail.com Wed Nov 18 11:15:13 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Wed, 18 Nov 2015 17:15:13 +0100 Subject: [vtk-developers] MouseWheel event pending missing on windows wrt X11 In-Reply-To: <20151118155545.GA24519@megas.khq.kitware.com> References: <20151118155545.GA24519@megas.khq.kitware.com> Message-ID: Ok, so the mouse wheel is indeed interupting the rendering, which is not the case with windows without the patch. 2015-11-18 16:55 GMT+01:00 Ben Boeckel : > On Mon, Nov 09, 2015 at 13:42:38 +0100, Xabi Riobe wrote: > > So before pushing a branch on GitLab, could anyone with access to a X > > platform or with good knowledge of this code can confirm this behaviour? > > I don't have good knowledge, but if I use the mousewheel on on a large > dataset after manipulating it, it is still decimated until it completes > the zoom. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Nov 18 11:34:28 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Nov 2015 11:34:28 -0500 Subject: [vtk-developers] FreeType: ftconfig.h appears in source tree and build tree In-Reply-To: References: Message-ID: <20151118163428.GA11391@megas.khq.kitware.com> On Wed, Nov 18, 2015 at 09:10:18 -0700, David Gobbi wrote: > I'm not sure if this is something to be concerned about, but I noticed that > the header "vtkfreetype/include/freetype/config/ftconfig.h" exists in the > source > tree even though it is config'd from "vtkfreetype/builds/unix/ftconfig.in". > > I found this when I accidentally ran "cmake" in my source directory, and > then did "git status" as part of my usual "oops, lets clean up this mess" > workflow. Interesting. That does indeed seem to be a potential problem. Something to look at when updating freetype, but if it's a problem other than that, I guess removing the file would be the first step to see whether it is actually used or not. Thanks, --Ben From simon.esneault at gmail.com Wed Nov 18 11:36:50 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Wed, 18 Nov 2015 17:36:50 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX In-Reply-To: References: Message-ID: Hello Ken, A colleague has just found a solution that prevent the crash. Here is the patch: //---------------------------------------------------------------------------- --- VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm Wed Nov 18 17:25:01 2015 +++ VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm Wed Nov 18 17:29:12 2015 @@ -309,6 +309,7 @@ this->SetRootWindow(NULL); this->WindowCreated = 0; this->ViewCreated = 0; + this->ReleaseGraphicsResources(); } //---------------------------------------------------------------------------- It just add a call to this->ReleaseGraphicsResources() at the end of the DestroyWindow() method in vtkCocoaRenderWindow implementation, which is called by the Finalize() method. He found out this solution because this method is called in the Finalize() method on the WIN32 implementation, and there is no crash in Windows... Do you think it is the correct fix? Or can this cause some unwanted side effects ? Regards Simon 2015-11-18 15:21 GMT+01:00 Ken Martin : > (sorry for the half written email, switching to the gmail web interface > has me messing up) > > I know zippo about Qt, but the version 120 error means that VTK thinks it > has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a > setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context > > > // Description:: > // Get if the context includes opengl core profile 3.2 support > static bool GetContextSupportsOpenGL32(); > void SetContextSupportsOpenGL32(bool val); > > it could be that the vtk Qt class is creating a 3.2 context but not > setting the above methods to true? Or maybe somehow not calling void > vtkOpenGLRenderWindow::OpenGLInitContext() > > Just a guess. > > Thanks > Ken > > > > On Wed, Nov 18, 2015 at 9:15 AM, Ken Martin > wrote: > >> I know zippo about Qt, but the version 120 error means that VTK thinks it >> has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a >> setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context >> >> >> On Wed, Nov 18, 2015 at 8:55 AM, Simon ESNEAULT > > wrote: >> >>> Hello, >>> >>> I've created a bug in Mantis for this >>> http://www.vtk.org/Bug/view.php?id=15840 >>> >>> Looking at the code in QVTKWidget.cxx, here is the part that may be >>> causing the problem, because it handles the reparenting part... >>> >>> >>> >>> */*******************************************************************************/* >>> *if(e->type() == QEvent::ParentAboutToChange)* >>> * {* >>> * this->markCachedImageAsDirty();* >>> * if (this->mRenWin)* >>> * {* >>> * // Finalize the window to remove graphics resources associated >>> with* >>> * // this window* >>> * if(this->mRenWin->GetMapped())* >>> * {* >>> * this->mRenWin->Finalize();* >>> * }* >>> * }* >>> * }* >>> * else if(e->type() == QEvent::ParentChange)* >>> * {* >>> * if(this->mRenWin)* >>> * {* >>> * x11_setup_window();* >>> * // connect to new window* >>> * this->mRenWin->SetWindowId( >>> reinterpret_cast(this->winId()));* >>> >>> * // start up the window to create graphics resources for this >>> window* >>> * if(isVisible())* >>> * {* >>> * this->mRenWin->Start();* >>> * }* >>> * }* >>> * }* >>> >>> */*******************************************************************************/* >>> >>> Were there any significant changes in the methods GetMapped() / >>> Finalize() / Start() of vtkRenderWindow (or children implementation) during >>> the development of the new rendering backend that may lead to such a crash >>> : >>> >>> >>> >>> */*******************************************************************************/* >>> *ERROR: In >>> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >>> line 354* >>> *vtkShaderProgram (0x6000001809c0): 1: #version 120* >>> *2: #define highp* >>> *3: #define mediump* >>> *4: #define lowp* >>> *5: * >>> *6: >>> /*=========================================================================* >>> *7: * >>> *8: Program: Visualization Toolkit* >>> *9: Module: vtkPolyDataVS.glsl* >>> *10: * >>> *11: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen* >>> *12: All rights reserved.* >>> *13: See Copyright.txt or http://www.kitware.com/Copyright.htm >>> for details.* >>> *14: * >>> *15: This software is distributed WITHOUT ANY WARRANTY; without >>> even* >>> *16: the implied warranty of MERCHANTABILITY or FITNESS FOR A >>> PARTICULAR* >>> *17: PURPOSE. See the above copyright notice for more information.* >>> *18: * >>> *19: >>> =========================================================================*/* >>> *20: * >>> *21: attribute vec4 vertexMC;* >>> *22: * >>> *23: // frag position in VC* >>> *24: varying vec4 vertexVCVSOutput;* >>> *25: * >>> *26: // optional normal declaration* >>> *27: attribute vec3 normalMC;* >>> *28: uniform mat3 normalMatrix;* >>> *29: varying vec3 normalVCVSOutput;* >>> *30: * >>> *31: // extra lighting parameters* >>> *32: //VTK::Light::Dec* >>> *33: * >>> *34: // Texture coordinates* >>> *35: //VTK::TCoord::Dec* >>> *36: * >>> *37: // material property values* >>> *38: //VTK::Color::Dec* >>> *39: * >>> *40: // clipping plane vars* >>> *41: //VTK::Clip::Dec* >>> *42: * >>> *43: // camera and actor matrix values* >>> *44: uniform mat4 MCDCMatrix;* >>> *45: uniform mat4 MCVCMatrix;* >>> *46: * >>> *47: // Apple Bug* >>> *48: //VTK::PrimID::Dec* >>> *49: * >>> *50: void main()* >>> *51: {* >>> *52: //VTK::Color::Impl* >>> *53: * >>> *54: normalVCVSOutput = normalMatrix * normalMC;* >>> *55: * >>> *56: //VTK::TCoord::Impl* >>> *57: * >>> *58: //VTK::Clip::Impl* >>> *59: * >>> *60: //VTK::PrimID::Impl* >>> *61: * >>> *62: vertexVCVSOutput = MCVCMatrix * vertexMC;* >>> *63: gl_Position = MCDCMatrix * vertexMC;* >>> *64: * >>> *65: * >>> *66: //VTK::Light::Impl* >>> *67: }* >>> *68: * >>> >>> >>> *ERROR: In >>> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >>> line 355* >>> *vtkShaderProgram (0x6000001809c0): ERROR: 0:1: '' : version '120' is >>> not supported* >>> *ERROR: 0:2: '' : #version required and missing.* >>> *ERROR: 0:21: 'attribute' : syntax error: syntax error* >>> >>> >>> *(lldb) bt* >>> ** thread #1: tid = 0x600e30, 0x0000000100609f1f >>> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31, >>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, >>> address=0x60)* >>> * * frame #0: 0x0000000100609f1f >>> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31* >>> * frame #1: 0x00000001006074ab >>> VtkReparentingProblem`vtkShaderProgram::SetUniformi(char const*, int) + 27* >>> * frame #2: 0x00000001005b8c28 >>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::SetMapperShaderParameters(vtkOpenGLHelper&, >>> vtkRenderer*, vtkActor*) + 72* >>> * frame #3: 0x00000001005b8b1b >>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::UpdateShaders(vtkOpenGLHelper&, >>> vtkRenderer*, vtkActor*) + 1211* >>> * frame #4: 0x00000001005bb782 >>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPieceDraw(vtkRenderer*, >>> vtkActor*) + 818* >>> * frame #5: 0x00000001005bbbe3 >>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, >>> vtkActor*) + 195* >>> * frame #6: 0x00000001004ba1fe >>> VtkReparentingProblem`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + >>> 174* >>> * frame #7: 0x0000000100561be0 >>> VtkReparentingProblem`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + >>> 144* >>> * frame #8: 0x00000001004667c3 >>> VtkReparentingProblem`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435* >>> * frame #9: 0x00000001005caa87 >>> VtkReparentingProblem`vtkOpenGLRenderer::UpdateGeometry() + 263* >>> * frame #10: 0x00000001005ca945 >>> VtkReparentingProblem`vtkOpenGLRenderer::DeviceRender() + 181* >>> * frame #11: 0x00000001004cb96c >>> VtkReparentingProblem`vtkRenderer::Render() + 604* >>> * frame #12: 0x00000001004d08cc >>> VtkReparentingProblem`vtkRendererCollection::Render() + 92* >>> * frame #13: 0x00000001004c5d1a >>> VtkReparentingProblem`vtkRenderWindow::DoStereoRender() + 138* >>> * frame #14: 0x00000001004c5098 >>> VtkReparentingProblem`vtkRenderWindow::Render() + 328* >>> * frame #15: 0x00000001005c7816 >>> VtkReparentingProblem`vtkOpenGLRenderWindow::Render() + 22* >>> * frame #16: 0x00000001004c8f17 >>> VtkReparentingProblem`vtkRenderWindowInteractor::Render() + 39* >>> * frame #17: 0x00000001006831dd >>> VtkReparentingProblem`QVTKWidget::paintEvent(QPaintEvent*) + 109* >>> * frame #18: 0x0000000100bb73d6 QtWidgets`QWidget::event(QEvent*) + >>> 1958* >>> * frame #19: 0x0000000100683079 >>> VtkReparentingProblem`QVTKWidget::event(QEvent*) + 281* >>> * frame #20: 0x0000000100b7effc >>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >>> * frame #21: 0x0000000100b81abb >>> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >>> * frame #22: 0x0000000101902932 >>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >>> * frame #23: 0x0000000100bb2035 >>> QtWidgets`QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint >>> const&, int, QPainter*, QWidgetBackingStore*) + 2997* >>> * frame #24: 0x0000000100b8aed0 >>> QtWidgets`QWidgetPrivate::repaint_sys(QRegion const&) + 400* >>> * frame #25: 0x0000000100bd4987 >>> QtWidgets`QWidgetWindow::event(QEvent*) + 423* >>> * frame #26: 0x0000000100b7effc >>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >>> * frame #27: 0x0000000100b81abb >>> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >>> * frame #28: 0x0000000101902932 >>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >>> * frame #29: 0x00000001011c4d7a >>> QtGui`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) >>> + 314* >>> * frame #30: 0x00000001011c08a7 >>> QtGui`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) >>> + 951* >>> * frame #31: 0x00000001011af1cb >>> QtGui`QWindowSystemInterface::sendWindowSystemEvents(QFlags) >>> + 315* >>> * frame #32: 0x0000000104a39f0d >>> libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents() + 317* >>> * frame #33: 0x0000000104a3a8a8 >>> libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) >>> + 40* >>> * frame #34: 0x00007fff8f9e3a01 >>> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + >>> 17* >>> * frame #35: 0x00007fff8f9d5b8d CoreFoundation`__CFRunLoopDoSources0 >>> + 269* >>> * frame #36: 0x00007fff8f9d51bf CoreFoundation`__CFRunLoopRun + 927* >>> * frame #37: 0x00007fff8f9d4bd8 CoreFoundation`CFRunLoopRunSpecific + >>> 296* >>> * frame #38: 0x00007fff8b65f56f HIToolbox`RunCurrentEventLoopInMode + >>> 235* >>> * frame #39: 0x00007fff8b65f2ea HIToolbox`ReceiveNextEventCommon + >>> 431* >>> * frame #40: 0x00007fff8b65f12b >>> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71* >>> * frame #41: 0x00007fff894cf8ab AppKit`_DPSNextEvent + 978* >>> * frame #42: 0x00007fff894cee58 AppKit`-[NSApplication >>> nextEventMatchingMask:untilDate:inMode:dequeue:] + 346* >>> * frame #43: 0x00007fff894c4af3 AppKit`-[NSApplication run] + 594* >>> * frame #44: 0x0000000104a395e4 >>> libqcocoa.dylib`QCocoaEventDispatcher::processEvents(QFlags) >>> + 2420* >>> * frame #45: 0x00000001018ff9ad >>> QtCore`QEventLoop::exec(QFlags) + 381* >>> * frame #46: 0x0000000101902ee7 QtCore`QCoreApplication::exec() + 359* >>> * frame #47: 0x0000000100005dab VtkReparentingProblem`main + 59* >>> * frame #48: 0x0000000100005d64 VtkReparentingProblem`start + 52* >>> >>> >>> */*******************************************************************************/* >>> >>> Any hints ? >>> >>> Regards, >>> Simon >>> >>> 2015-11-17 9:27 GMT+01:00 Simon ESNEAULT : >>> >>>> Hello, >>>> >>>> After the switch to the new rendering backend, we have a crash on our >>>> program after reparenting a QVTKWidget on OSX. The crash is in the >>>> method vtkShaderProgram::FindUniform() but we suspect it is about the >>>> OpenGL context not being ready on time for the next paintEvent with the new >>>> parent. >>>> >>>> Attached is a program that reproduce the problem, as well as a complete >>>> backtrace for this crash. This used to work fine with the previous backend. >>>> >>>> Hope this little test case helps >>>> >>>> Thanks >>>> Simon >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the VTK FAQ at: >>> http://www.vtk.org/Wiki/VTK_FAQ >>> >>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtkusers >>> >>> >> >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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 > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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. > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Nov 18 11:42:27 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 18 Nov 2015 11:42:27 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX In-Reply-To: References: Message-ID: Yes, if some process is causing the opengl context to be destroyed then we need to release the graphics resources tied to the old context. Sounds like that is the case here and the cocoa window was missing it. On Wed, Nov 18, 2015 at 11:36 AM, Simon ESNEAULT wrote: > Hello Ken, > > A colleague has just found a solution that prevent the crash. Here is the > patch: > > > //---------------------------------------------------------------------------- > > --- VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm Wed Nov 18 17:25:01 2015 > +++ VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm Wed Nov 18 17:29:12 2015 > @@ -309,6 +309,7 @@ > this->SetRootWindow(NULL); > this->WindowCreated = 0; > this->ViewCreated = 0; > + this->ReleaseGraphicsResources(); > } > > > //---------------------------------------------------------------------------- > > It just add a call to this->ReleaseGraphicsResources() at the end of the > DestroyWindow() method in vtkCocoaRenderWindow implementation, which is > called by the Finalize() method. > > He found out this solution because this method is called in the Finalize() > method on the WIN32 implementation, and there is no crash in Windows... > > Do you think it is the correct fix? Or can this cause some unwanted side > effects ? > > Regards > Simon > > > 2015-11-18 15:21 GMT+01:00 Ken Martin : > >> (sorry for the half written email, switching to the gmail web interface >> has me messing up) >> >> I know zippo about Qt, but the version 120 error means that VTK thinks it >> has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a >> setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context >> >> >> // Description:: >> // Get if the context includes opengl core profile 3.2 support >> static bool GetContextSupportsOpenGL32(); >> void SetContextSupportsOpenGL32(bool val); >> >> it could be that the vtk Qt class is creating a 3.2 context but not >> setting the above methods to true? Or maybe somehow not calling void >> vtkOpenGLRenderWindow::OpenGLInitContext() >> >> Just a guess. >> >> Thanks >> Ken >> >> >> >> On Wed, Nov 18, 2015 at 9:15 AM, Ken Martin >> wrote: >> >>> I know zippo about Qt, but the version 120 error means that VTK thinks >>> it has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a >>> setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context >>> >>> >>> On Wed, Nov 18, 2015 at 8:55 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I've created a bug in Mantis for this >>>> http://www.vtk.org/Bug/view.php?id=15840 >>>> >>>> Looking at the code in QVTKWidget.cxx, here is the part that may be >>>> causing the problem, because it handles the reparenting part... >>>> >>>> >>>> >>>> */*******************************************************************************/* >>>> *if(e->type() == QEvent::ParentAboutToChange)* >>>> * {* >>>> * this->markCachedImageAsDirty();* >>>> * if (this->mRenWin)* >>>> * {* >>>> * // Finalize the window to remove graphics resources associated >>>> with* >>>> * // this window* >>>> * if(this->mRenWin->GetMapped())* >>>> * {* >>>> * this->mRenWin->Finalize();* >>>> * }* >>>> * }* >>>> * }* >>>> * else if(e->type() == QEvent::ParentChange)* >>>> * {* >>>> * if(this->mRenWin)* >>>> * {* >>>> * x11_setup_window();* >>>> * // connect to new window* >>>> * this->mRenWin->SetWindowId( >>>> reinterpret_cast(this->winId()));* >>>> >>>> * // start up the window to create graphics resources for this >>>> window* >>>> * if(isVisible())* >>>> * {* >>>> * this->mRenWin->Start();* >>>> * }* >>>> * }* >>>> * }* >>>> >>>> */*******************************************************************************/* >>>> >>>> Were there any significant changes in the methods GetMapped() / >>>> Finalize() / Start() of vtkRenderWindow (or children implementation) during >>>> the development of the new rendering backend that may lead to such a crash >>>> : >>>> >>>> >>>> >>>> */*******************************************************************************/* >>>> *ERROR: In >>>> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >>>> line 354* >>>> *vtkShaderProgram (0x6000001809c0): 1: #version 120* >>>> *2: #define highp* >>>> *3: #define mediump* >>>> *4: #define lowp* >>>> *5: * >>>> *6: >>>> /*=========================================================================* >>>> *7: * >>>> *8: Program: Visualization Toolkit* >>>> *9: Module: vtkPolyDataVS.glsl* >>>> *10: * >>>> *11: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen* >>>> *12: All rights reserved.* >>>> *13: See Copyright.txt or http://www.kitware.com/Copyright.htm >>>> for details.* >>>> *14: * >>>> *15: This software is distributed WITHOUT ANY WARRANTY; without >>>> even* >>>> *16: the implied warranty of MERCHANTABILITY or FITNESS FOR A >>>> PARTICULAR* >>>> *17: PURPOSE. See the above copyright notice for more >>>> information.* >>>> *18: * >>>> *19: >>>> =========================================================================*/* >>>> *20: * >>>> *21: attribute vec4 vertexMC;* >>>> *22: * >>>> *23: // frag position in VC* >>>> *24: varying vec4 vertexVCVSOutput;* >>>> *25: * >>>> *26: // optional normal declaration* >>>> *27: attribute vec3 normalMC;* >>>> *28: uniform mat3 normalMatrix;* >>>> *29: varying vec3 normalVCVSOutput;* >>>> *30: * >>>> *31: // extra lighting parameters* >>>> *32: //VTK::Light::Dec* >>>> *33: * >>>> *34: // Texture coordinates* >>>> *35: //VTK::TCoord::Dec* >>>> *36: * >>>> *37: // material property values* >>>> *38: //VTK::Color::Dec* >>>> *39: * >>>> *40: // clipping plane vars* >>>> *41: //VTK::Clip::Dec* >>>> *42: * >>>> *43: // camera and actor matrix values* >>>> *44: uniform mat4 MCDCMatrix;* >>>> *45: uniform mat4 MCVCMatrix;* >>>> *46: * >>>> *47: // Apple Bug* >>>> *48: //VTK::PrimID::Dec* >>>> *49: * >>>> *50: void main()* >>>> *51: {* >>>> *52: //VTK::Color::Impl* >>>> *53: * >>>> *54: normalVCVSOutput = normalMatrix * normalMC;* >>>> *55: * >>>> *56: //VTK::TCoord::Impl* >>>> *57: * >>>> *58: //VTK::Clip::Impl* >>>> *59: * >>>> *60: //VTK::PrimID::Impl* >>>> *61: * >>>> *62: vertexVCVSOutput = MCVCMatrix * vertexMC;* >>>> *63: gl_Position = MCDCMatrix * vertexMC;* >>>> *64: * >>>> *65: * >>>> *66: //VTK::Light::Impl* >>>> *67: }* >>>> *68: * >>>> >>>> >>>> *ERROR: In >>>> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >>>> line 355* >>>> *vtkShaderProgram (0x6000001809c0): ERROR: 0:1: '' : version '120' is >>>> not supported* >>>> *ERROR: 0:2: '' : #version required and missing.* >>>> *ERROR: 0:21: 'attribute' : syntax error: syntax error* >>>> >>>> >>>> *(lldb) bt* >>>> ** thread #1: tid = 0x600e30, 0x0000000100609f1f >>>> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31, >>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, >>>> address=0x60)* >>>> * * frame #0: 0x0000000100609f1f >>>> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31* >>>> * frame #1: 0x00000001006074ab >>>> VtkReparentingProblem`vtkShaderProgram::SetUniformi(char const*, int) + 27* >>>> * frame #2: 0x00000001005b8c28 >>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::SetMapperShaderParameters(vtkOpenGLHelper&, >>>> vtkRenderer*, vtkActor*) + 72* >>>> * frame #3: 0x00000001005b8b1b >>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::UpdateShaders(vtkOpenGLHelper&, >>>> vtkRenderer*, vtkActor*) + 1211* >>>> * frame #4: 0x00000001005bb782 >>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPieceDraw(vtkRenderer*, >>>> vtkActor*) + 818* >>>> * frame #5: 0x00000001005bbbe3 >>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, >>>> vtkActor*) + 195* >>>> * frame #6: 0x00000001004ba1fe >>>> VtkReparentingProblem`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + >>>> 174* >>>> * frame #7: 0x0000000100561be0 >>>> VtkReparentingProblem`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + >>>> 144* >>>> * frame #8: 0x00000001004667c3 >>>> VtkReparentingProblem`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435* >>>> * frame #9: 0x00000001005caa87 >>>> VtkReparentingProblem`vtkOpenGLRenderer::UpdateGeometry() + 263* >>>> * frame #10: 0x00000001005ca945 >>>> VtkReparentingProblem`vtkOpenGLRenderer::DeviceRender() + 181* >>>> * frame #11: 0x00000001004cb96c >>>> VtkReparentingProblem`vtkRenderer::Render() + 604* >>>> * frame #12: 0x00000001004d08cc >>>> VtkReparentingProblem`vtkRendererCollection::Render() + 92* >>>> * frame #13: 0x00000001004c5d1a >>>> VtkReparentingProblem`vtkRenderWindow::DoStereoRender() + 138* >>>> * frame #14: 0x00000001004c5098 >>>> VtkReparentingProblem`vtkRenderWindow::Render() + 328* >>>> * frame #15: 0x00000001005c7816 >>>> VtkReparentingProblem`vtkOpenGLRenderWindow::Render() + 22* >>>> * frame #16: 0x00000001004c8f17 >>>> VtkReparentingProblem`vtkRenderWindowInteractor::Render() + 39* >>>> * frame #17: 0x00000001006831dd >>>> VtkReparentingProblem`QVTKWidget::paintEvent(QPaintEvent*) + 109* >>>> * frame #18: 0x0000000100bb73d6 QtWidgets`QWidget::event(QEvent*) + >>>> 1958* >>>> * frame #19: 0x0000000100683079 >>>> VtkReparentingProblem`QVTKWidget::event(QEvent*) + 281* >>>> * frame #20: 0x0000000100b7effc >>>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >>>> * frame #21: 0x0000000100b81abb >>>> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >>>> * frame #22: 0x0000000101902932 >>>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >>>> * frame #23: 0x0000000100bb2035 >>>> QtWidgets`QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint >>>> const&, int, QPainter*, QWidgetBackingStore*) + 2997* >>>> * frame #24: 0x0000000100b8aed0 >>>> QtWidgets`QWidgetPrivate::repaint_sys(QRegion const&) + 400* >>>> * frame #25: 0x0000000100bd4987 >>>> QtWidgets`QWidgetWindow::event(QEvent*) + 423* >>>> * frame #26: 0x0000000100b7effc >>>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >>>> * frame #27: 0x0000000100b81abb >>>> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >>>> * frame #28: 0x0000000101902932 >>>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >>>> * frame #29: 0x00000001011c4d7a >>>> QtGui`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) >>>> + 314* >>>> * frame #30: 0x00000001011c08a7 >>>> QtGui`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) >>>> + 951* >>>> * frame #31: 0x00000001011af1cb >>>> QtGui`QWindowSystemInterface::sendWindowSystemEvents(QFlags) >>>> + 315* >>>> * frame #32: 0x0000000104a39f0d >>>> libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents() + 317* >>>> * frame #33: 0x0000000104a3a8a8 >>>> libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) >>>> + 40* >>>> * frame #34: 0x00007fff8f9e3a01 >>>> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + >>>> 17* >>>> * frame #35: 0x00007fff8f9d5b8d CoreFoundation`__CFRunLoopDoSources0 >>>> + 269* >>>> * frame #36: 0x00007fff8f9d51bf CoreFoundation`__CFRunLoopRun + 927* >>>> * frame #37: 0x00007fff8f9d4bd8 CoreFoundation`CFRunLoopRunSpecific >>>> + 296* >>>> * frame #38: 0x00007fff8b65f56f HIToolbox`RunCurrentEventLoopInMode >>>> + 235* >>>> * frame #39: 0x00007fff8b65f2ea HIToolbox`ReceiveNextEventCommon + >>>> 431* >>>> * frame #40: 0x00007fff8b65f12b >>>> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71* >>>> * frame #41: 0x00007fff894cf8ab AppKit`_DPSNextEvent + 978* >>>> * frame #42: 0x00007fff894cee58 AppKit`-[NSApplication >>>> nextEventMatchingMask:untilDate:inMode:dequeue:] + 346* >>>> * frame #43: 0x00007fff894c4af3 AppKit`-[NSApplication run] + 594* >>>> * frame #44: 0x0000000104a395e4 >>>> libqcocoa.dylib`QCocoaEventDispatcher::processEvents(QFlags) >>>> + 2420* >>>> * frame #45: 0x00000001018ff9ad >>>> QtCore`QEventLoop::exec(QFlags) + 381* >>>> * frame #46: 0x0000000101902ee7 QtCore`QCoreApplication::exec() + >>>> 359* >>>> * frame #47: 0x0000000100005dab VtkReparentingProblem`main + 59* >>>> * frame #48: 0x0000000100005d64 VtkReparentingProblem`start + 52* >>>> >>>> >>>> */*******************************************************************************/* >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> Simon >>>> >>>> 2015-11-17 9:27 GMT+01:00 Simon ESNEAULT : >>>> >>>>> Hello, >>>>> >>>>> After the switch to the new rendering backend, we have a crash on our >>>>> program after reparenting a QVTKWidget on OSX. The crash is in the >>>>> method vtkShaderProgram::FindUniform() but we suspect it is about the >>>>> OpenGL context not being ready on time for the next paintEvent with the new >>>>> parent. >>>>> >>>>> Attached is a program that reproduce the problem, as well as a >>>>> complete backtrace for this crash. This used to work fine with the previous >>>>> backend. >>>>> >>>>> Hope this little test case helps >>>>> >>>>> Thanks >>>>> Simon >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Please keep messages on-topic and check the VTK FAQ at: >>>> http://www.vtk.org/Wiki/VTK_FAQ >>>> >>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>> >>>> >>> >>> >>> -- >>> Ken Martin PhD >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 >>> >>> 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 >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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. >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 Nov 18 15:34:46 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Nov 2015 15:34:46 -0500 Subject: [vtk-developers] Gil tests on megas In-Reply-To: References: Message-ID: <20151118203446.GA31837@megas.khq.kitware.com> On Tue, Nov 17, 2015 at 12:53:09 +0100, Mathieu Westphal wrote: > I'm testing my GIl ensured version of VTK ( > https://gitlab.kitware.com/vtk/vtk/merge_requests/582) with the buildbots, > and i have only three problematic recurring tests, on a specific build of > megas. Found it. Here's the code from PyVTKObject_FromPointer: > const char *classname = vtkPythonUtil::StripModule(pytype->tp_name); ... > // Use the vtkname of the supplied class type > PyObject *s = PyObject_GetAttrString((PyObject *)pytype, "__vtkname__"); > if (s) > { > #ifdef VTK_PY3K > PyObject *tmp = PyUnicode_AsUTF8String(s); Python3 uses unicode objects, but we need ASCII... > if (tmp) > { > Py_DECREF(s); > s = tmp; ...so `s` is now a new bytes object... > } > #endif > classname = PyBytes_AsString(s); ...we take a pointer to its data for use later... > if (classname == 0) > { > Py_DECREF(s); > return NULL; > } > } > cls = vtkPythonUtil::FindClass(classname); > if (cls == 0) > { > PyErr_Format(PyExc_ValueError, > "internal error, unknown VTK class %.200s", > classname); > Py_XDECREF(s); > return NULL; > } > Py_XDECREF(s); ...decref the bytes object here (which can now be garbage collected)... > } > > if (!ptr) > { > // Create a new instance of this class since we were not given one. > if (cls->vtk_new) > { > ptr = cls->vtk_new(); > if (!ptr) > { > // The vtk_new() method returns null when a factory class has no > // implementation (i.e. cannot provide a concrete class instance.) > // NotImplementedError indicates a pure virtual method call. > PyErr_SetString( > PyExc_NotImplementedError, > "no concrete implementation exists for this class"); > return 0; > } > created = true; > > // Check the type of the newly-created object > const char *newclassname = ptr->GetClassName(); > if (strcmp(newclassname, classname) != 0) ...and use the pointer to the old object's data here. It only crashes in Python3 and when the garbage collector runs between the Py_XDECREF above and its use here. The test fails because glibc catches the bogus pointer after free() does its thing, so that's why only megas caught it. Branch incoming :) . --Ben From david.gobbi at gmail.com Wed Nov 18 15:49:06 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 18 Nov 2015 13:49:06 -0700 Subject: [vtk-developers] Gil tests on megas In-Reply-To: <20151118203446.GA31837@megas.khq.kitware.com> References: <20151118203446.GA31837@megas.khq.kitware.com> Message-ID: Oops! Thanks for finding this. I can cherry-pick your (pending) fix to my python-py3k branch for VTK 6.3. - David On Wed, Nov 18, 2015 at 1:34 PM, Ben Boeckel wrote: > On Tue, Nov 17, 2015 at 12:53:09 +0100, Mathieu Westphal wrote: > > I'm testing my GIl ensured version of VTK ( > > https://gitlab.kitware.com/vtk/vtk/merge_requests/582) with the > buildbots, > > and i have only three problematic recurring tests, on a specific build of > > megas. > > Found it. Here's the code from PyVTKObject_FromPointer: > > > const char *classname = vtkPythonUtil::StripModule(pytype->tp_name); > > ... > > > // Use the vtkname of the supplied class type > > PyObject *s = PyObject_GetAttrString((PyObject *)pytype, > "__vtkname__"); > > if (s) > > { > > #ifdef VTK_PY3K > > PyObject *tmp = PyUnicode_AsUTF8String(s); > > Python3 uses unicode objects, but we need ASCII... > > > if (tmp) > > { > > Py_DECREF(s); > > s = tmp; > > ...so `s` is now a new bytes object... > > > } > > #endif > > classname = PyBytes_AsString(s); > > ...we take a pointer to its data for use later... > > > if (classname == 0) > > { > > Py_DECREF(s); > > return NULL; > > } > > } > > cls = vtkPythonUtil::FindClass(classname); > > if (cls == 0) > > { > > PyErr_Format(PyExc_ValueError, > > "internal error, unknown VTK class %.200s", > > classname); > > Py_XDECREF(s); > > return NULL; > > } > > Py_XDECREF(s); > > ...decref the bytes object here (which can now be garbage collected)... > > > } > > > > if (!ptr) > > { > > // Create a new instance of this class since we were not given one. > > if (cls->vtk_new) > > { > > ptr = cls->vtk_new(); > > if (!ptr) > > { > > // The vtk_new() method returns null when a factory class has no > > // implementation (i.e. cannot provide a concrete class > instance.) > > // NotImplementedError indicates a pure virtual method call. > > PyErr_SetString( > > PyExc_NotImplementedError, > > "no concrete implementation exists for this class"); > > return 0; > > } > > created = true; > > > > // Check the type of the newly-created object > > const char *newclassname = ptr->GetClassName(); > > if (strcmp(newclassname, classname) != 0) > > ...and use the pointer to the old object's data here. > > It only crashes in Python3 and when the garbage collector runs between > the Py_XDECREF above and its use here. The test fails because glibc > catches the bogus pointer after free() does its thing, so that's why > only megas caught it. > > Branch incoming :) . > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Nov 18 16:26:37 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 18 Nov 2015 16:26:37 -0500 Subject: [vtk-developers] Gil tests on megas In-Reply-To: References: <20151118203446.GA31837@megas.khq.kitware.com> Message-ID: <20151118212637.GA25782@megas.khq.kitware.com> On Wed, Nov 18, 2015 at 13:49:06 -0700, David Gobbi wrote: > Oops! Thanks for finding this. I can cherry-pick your (pending) fix to > my python-py3k branch for VTK 6.3. Yeah, this is that weird bug we saw months ago rearing its head, but it has been consistent lately. At least it's a simple fix :) . --Ben From simon.esneault at gmail.com Thu Nov 19 04:12:53 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Thu, 19 Nov 2015 10:12:53 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3/OGL2/Qt5.3.2 : QVTKWidget regression, crash after "reparenting" a widget on OSX In-Reply-To: References: Message-ID: Hello Ken, I've created a merge request here : https://gitlab.kitware.com/vtk/vtk/merge_requests/925 Can you review it and eventually allow it to master if it is the correct fix ? I've also added Sean McBride as a reviewer. Thanks Simon 2015-11-18 17:42 GMT+01:00 Ken Martin : > Yes, if some process is causing the opengl context to be destroyed then we > need to release the graphics resources tied to the old context. Sounds like > that is the case here and the cocoa window was missing it. > > On Wed, Nov 18, 2015 at 11:36 AM, Simon ESNEAULT > wrote: > >> Hello Ken, >> >> A colleague has just found a solution that prevent the crash. Here is the >> patch: >> >> >> //---------------------------------------------------------------------------- >> >> --- VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm Wed Nov 18 17:25:01 >> 2015 >> +++ VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm Wed Nov 18 17:29:12 >> 2015 >> @@ -309,6 +309,7 @@ >> this->SetRootWindow(NULL); >> this->WindowCreated = 0; >> this->ViewCreated = 0; >> + this->ReleaseGraphicsResources(); >> } >> >> >> //---------------------------------------------------------------------------- >> >> It just add a call to this->ReleaseGraphicsResources() at the end of the >> DestroyWindow() method in vtkCocoaRenderWindow implementation, which is >> called by the Finalize() method. >> >> He found out this solution because this method is called in the >> Finalize() method on the WIN32 implementation, and there is no crash in >> Windows... >> >> Do you think it is the correct fix? Or can this cause some unwanted side >> effects ? >> >> Regards >> Simon >> >> >> 2015-11-18 15:21 GMT+01:00 Ken Martin : >> >>> (sorry for the half written email, switching to the gmail web interface >>> has me messing up) >>> >>> I know zippo about Qt, but the version 120 error means that VTK thinks >>> it has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a >>> setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context >>> >>> >>> // Description:: >>> // Get if the context includes opengl core profile 3.2 support >>> static bool GetContextSupportsOpenGL32(); >>> void SetContextSupportsOpenGL32(bool val); >>> >>> it could be that the vtk Qt class is creating a 3.2 context but not >>> setting the above methods to true? Or maybe somehow not calling void >>> vtkOpenGLRenderWindow::OpenGLInitContext() >>> >>> Just a guess. >>> >>> Thanks >>> Ken >>> >>> >>> >>> On Wed, Nov 18, 2015 at 9:15 AM, Ken Martin >>> wrote: >>> >>>> I know zippo about Qt, but the version 120 error means that VTK thinks >>>> it has an old OpenGL 2.1 context as opposed to a 3.2 context. There is a >>>> setting in vtkOpenGLRenderWindow to indicate that it has a 3.2 context >>>> >>>> >>>> On Wed, Nov 18, 2015 at 8:55 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> I've created a bug in Mantis for this >>>>> http://www.vtk.org/Bug/view.php?id=15840 >>>>> >>>>> Looking at the code in QVTKWidget.cxx, here is the part that may be >>>>> causing the problem, because it handles the reparenting part... >>>>> >>>>> >>>>> >>>>> */*******************************************************************************/* >>>>> *if(e->type() == QEvent::ParentAboutToChange)* >>>>> * {* >>>>> * this->markCachedImageAsDirty();* >>>>> * if (this->mRenWin)* >>>>> * {* >>>>> * // Finalize the window to remove graphics resources associated >>>>> with* >>>>> * // this window* >>>>> * if(this->mRenWin->GetMapped())* >>>>> * {* >>>>> * this->mRenWin->Finalize();* >>>>> * }* >>>>> * }* >>>>> * }* >>>>> * else if(e->type() == QEvent::ParentChange)* >>>>> * {* >>>>> * if(this->mRenWin)* >>>>> * {* >>>>> * x11_setup_window();* >>>>> * // connect to new window* >>>>> * this->mRenWin->SetWindowId( >>>>> reinterpret_cast(this->winId()));* >>>>> >>>>> * // start up the window to create graphics resources for this >>>>> window* >>>>> * if(isVisible())* >>>>> * {* >>>>> * this->mRenWin->Start();* >>>>> * }* >>>>> * }* >>>>> * }* >>>>> >>>>> */*******************************************************************************/* >>>>> >>>>> Were there any significant changes in the methods GetMapped() / >>>>> Finalize() / Start() of vtkRenderWindow (or children implementation) during >>>>> the development of the new rendering backend that may lead to such a crash >>>>> : >>>>> >>>>> >>>>> >>>>> */*******************************************************************************/* >>>>> *ERROR: In >>>>> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >>>>> line 354* >>>>> *vtkShaderProgram (0x6000001809c0): 1: #version 120* >>>>> *2: #define highp* >>>>> *3: #define mediump* >>>>> *4: #define lowp* >>>>> *5: * >>>>> *6: >>>>> /*=========================================================================* >>>>> *7: * >>>>> *8: Program: Visualization Toolkit* >>>>> *9: Module: vtkPolyDataVS.glsl* >>>>> *10: * >>>>> *11: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen* >>>>> *12: All rights reserved.* >>>>> *13: See Copyright.txt or http://www.kitware.com/Copyright.htm >>>>> for details.* >>>>> *14: * >>>>> *15: This software is distributed WITHOUT ANY WARRANTY; without >>>>> even* >>>>> *16: the implied warranty of MERCHANTABILITY or FITNESS FOR A >>>>> PARTICULAR* >>>>> *17: PURPOSE. See the above copyright notice for more >>>>> information.* >>>>> *18: * >>>>> *19: >>>>> =========================================================================*/* >>>>> *20: * >>>>> *21: attribute vec4 vertexMC;* >>>>> *22: * >>>>> *23: // frag position in VC* >>>>> *24: varying vec4 vertexVCVSOutput;* >>>>> *25: * >>>>> *26: // optional normal declaration* >>>>> *27: attribute vec3 normalMC;* >>>>> *28: uniform mat3 normalMatrix;* >>>>> *29: varying vec3 normalVCVSOutput;* >>>>> *30: * >>>>> *31: // extra lighting parameters* >>>>> *32: //VTK::Light::Dec* >>>>> *33: * >>>>> *34: // Texture coordinates* >>>>> *35: //VTK::TCoord::Dec* >>>>> *36: * >>>>> *37: // material property values* >>>>> *38: //VTK::Color::Dec* >>>>> *39: * >>>>> *40: // clipping plane vars* >>>>> *41: //VTK::Clip::Dec* >>>>> *42: * >>>>> *43: // camera and actor matrix values* >>>>> *44: uniform mat4 MCDCMatrix;* >>>>> *45: uniform mat4 MCVCMatrix;* >>>>> *46: * >>>>> *47: // Apple Bug* >>>>> *48: //VTK::PrimID::Dec* >>>>> *49: * >>>>> *50: void main()* >>>>> *51: {* >>>>> *52: //VTK::Color::Impl* >>>>> *53: * >>>>> *54: normalVCVSOutput = normalMatrix * normalMC;* >>>>> *55: * >>>>> *56: //VTK::TCoord::Impl* >>>>> *57: * >>>>> *58: //VTK::Clip::Impl* >>>>> *59: * >>>>> *60: //VTK::PrimID::Impl* >>>>> *61: * >>>>> *62: vertexVCVSOutput = MCVCMatrix * vertexMC;* >>>>> *63: gl_Position = MCDCMatrix * vertexMC;* >>>>> *64: * >>>>> *65: * >>>>> *66: //VTK::Light::Impl* >>>>> *67: }* >>>>> *68: * >>>>> >>>>> >>>>> *ERROR: In >>>>> /Users/th-dev/EndoSize_OGL2/cmake-externals/VTK/src/Rendering/OpenGL2/vtkShaderProgram.cxx, >>>>> line 355* >>>>> *vtkShaderProgram (0x6000001809c0): ERROR: 0:1: '' : version '120' is >>>>> not supported* >>>>> *ERROR: 0:2: '' : #version required and missing.* >>>>> *ERROR: 0:21: 'attribute' : syntax error: syntax error* >>>>> >>>>> >>>>> *(lldb) bt* >>>>> ** thread #1: tid = 0x600e30, 0x0000000100609f1f >>>>> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31, >>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, >>>>> address=0x60)* >>>>> * * frame #0: 0x0000000100609f1f >>>>> VtkReparentingProblem`vtkShaderProgram::FindUniform(char const*) + 31* >>>>> * frame #1: 0x00000001006074ab >>>>> VtkReparentingProblem`vtkShaderProgram::SetUniformi(char const*, int) + 27* >>>>> * frame #2: 0x00000001005b8c28 >>>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::SetMapperShaderParameters(vtkOpenGLHelper&, >>>>> vtkRenderer*, vtkActor*) + 72* >>>>> * frame #3: 0x00000001005b8b1b >>>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::UpdateShaders(vtkOpenGLHelper&, >>>>> vtkRenderer*, vtkActor*) + 1211* >>>>> * frame #4: 0x00000001005bb782 >>>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPieceDraw(vtkRenderer*, >>>>> vtkActor*) + 818* >>>>> * frame #5: 0x00000001005bbbe3 >>>>> VtkReparentingProblem`vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, >>>>> vtkActor*) + 195* >>>>> * frame #6: 0x00000001004ba1fe >>>>> VtkReparentingProblem`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + >>>>> 174* >>>>> * frame #7: 0x0000000100561be0 >>>>> VtkReparentingProblem`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + >>>>> 144* >>>>> * frame #8: 0x00000001004667c3 >>>>> VtkReparentingProblem`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435* >>>>> * frame #9: 0x00000001005caa87 >>>>> VtkReparentingProblem`vtkOpenGLRenderer::UpdateGeometry() + 263* >>>>> * frame #10: 0x00000001005ca945 >>>>> VtkReparentingProblem`vtkOpenGLRenderer::DeviceRender() + 181* >>>>> * frame #11: 0x00000001004cb96c >>>>> VtkReparentingProblem`vtkRenderer::Render() + 604* >>>>> * frame #12: 0x00000001004d08cc >>>>> VtkReparentingProblem`vtkRendererCollection::Render() + 92* >>>>> * frame #13: 0x00000001004c5d1a >>>>> VtkReparentingProblem`vtkRenderWindow::DoStereoRender() + 138* >>>>> * frame #14: 0x00000001004c5098 >>>>> VtkReparentingProblem`vtkRenderWindow::Render() + 328* >>>>> * frame #15: 0x00000001005c7816 >>>>> VtkReparentingProblem`vtkOpenGLRenderWindow::Render() + 22* >>>>> * frame #16: 0x00000001004c8f17 >>>>> VtkReparentingProblem`vtkRenderWindowInteractor::Render() + 39* >>>>> * frame #17: 0x00000001006831dd >>>>> VtkReparentingProblem`QVTKWidget::paintEvent(QPaintEvent*) + 109* >>>>> * frame #18: 0x0000000100bb73d6 QtWidgets`QWidget::event(QEvent*) + >>>>> 1958* >>>>> * frame #19: 0x0000000100683079 >>>>> VtkReparentingProblem`QVTKWidget::event(QEvent*) + 281* >>>>> * frame #20: 0x0000000100b7effc >>>>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >>>>> * frame #21: 0x0000000100b81abb >>>>> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >>>>> * frame #22: 0x0000000101902932 >>>>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >>>>> * frame #23: 0x0000000100bb2035 >>>>> QtWidgets`QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint >>>>> const&, int, QPainter*, QWidgetBackingStore*) + 2997* >>>>> * frame #24: 0x0000000100b8aed0 >>>>> QtWidgets`QWidgetPrivate::repaint_sys(QRegion const&) + 400* >>>>> * frame #25: 0x0000000100bd4987 >>>>> QtWidgets`QWidgetWindow::event(QEvent*) + 423* >>>>> * frame #26: 0x0000000100b7effc >>>>> QtWidgets`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 300* >>>>> * frame #27: 0x0000000100b81abb >>>>> QtWidgets`QApplication::notify(QObject*, QEvent*) + 6187* >>>>> * frame #28: 0x0000000101902932 >>>>> QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 114* >>>>> * frame #29: 0x00000001011c4d7a >>>>> QtGui`QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) >>>>> + 314* >>>>> * frame #30: 0x00000001011c08a7 >>>>> QtGui`QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) >>>>> + 951* >>>>> * frame #31: 0x00000001011af1cb >>>>> QtGui`QWindowSystemInterface::sendWindowSystemEvents(QFlags) >>>>> + 315* >>>>> * frame #32: 0x0000000104a39f0d >>>>> libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents() + 317* >>>>> * frame #33: 0x0000000104a3a8a8 >>>>> libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*) >>>>> + 40* >>>>> * frame #34: 0x00007fff8f9e3a01 >>>>> CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + >>>>> 17* >>>>> * frame #35: 0x00007fff8f9d5b8d >>>>> CoreFoundation`__CFRunLoopDoSources0 + 269* >>>>> * frame #36: 0x00007fff8f9d51bf CoreFoundation`__CFRunLoopRun + 927* >>>>> * frame #37: 0x00007fff8f9d4bd8 CoreFoundation`CFRunLoopRunSpecific >>>>> + 296* >>>>> * frame #38: 0x00007fff8b65f56f HIToolbox`RunCurrentEventLoopInMode >>>>> + 235* >>>>> * frame #39: 0x00007fff8b65f2ea HIToolbox`ReceiveNextEventCommon + >>>>> 431* >>>>> * frame #40: 0x00007fff8b65f12b >>>>> HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71* >>>>> * frame #41: 0x00007fff894cf8ab AppKit`_DPSNextEvent + 978* >>>>> * frame #42: 0x00007fff894cee58 AppKit`-[NSApplication >>>>> nextEventMatchingMask:untilDate:inMode:dequeue:] + 346* >>>>> * frame #43: 0x00007fff894c4af3 AppKit`-[NSApplication run] + 594* >>>>> * frame #44: 0x0000000104a395e4 >>>>> libqcocoa.dylib`QCocoaEventDispatcher::processEvents(QFlags) >>>>> + 2420* >>>>> * frame #45: 0x00000001018ff9ad >>>>> QtCore`QEventLoop::exec(QFlags) + 381* >>>>> * frame #46: 0x0000000101902ee7 QtCore`QCoreApplication::exec() + >>>>> 359* >>>>> * frame #47: 0x0000000100005dab VtkReparentingProblem`main + 59* >>>>> * frame #48: 0x0000000100005d64 VtkReparentingProblem`start + 52* >>>>> >>>>> >>>>> */*******************************************************************************/* >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> Simon >>>>> >>>>> 2015-11-17 9:27 GMT+01:00 Simon ESNEAULT : >>>>> >>>>>> Hello, >>>>>> >>>>>> After the switch to the new rendering backend, we have a crash on our >>>>>> program after reparenting a QVTKWidget on OSX. The crash is in the >>>>>> method vtkShaderProgram::FindUniform() but we suspect it is about the >>>>>> OpenGL context not being ready on time for the next paintEvent with the new >>>>>> parent. >>>>>> >>>>>> Attached is a program that reproduce the problem, as well as a >>>>>> complete backtrace for this crash. This used to work fine with the previous >>>>>> backend. >>>>>> >>>>>> Hope this little test case helps >>>>>> >>>>>> Thanks >>>>>> Simon >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>> >>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Chairman & CFO >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Clifton Park NY 12065 >>>> 518 371 3971 >>>> >>>> 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 >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 >>> >>> 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. >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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. > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Thu Nov 19 04:33:43 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 19 Nov 2015 10:33:43 +0100 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Will- I am pretty sure the weekend is over now ;) Do you think Mathieu's patch make sense? So far it breaks some tests and we need to analyze if the some of the new results are more appropriate or just incorrect... Best, Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-07-15 14:16 GMT+02:00 Mathieu Westphal : > Hello > > I've created a fix for FindCell : > https://gitlab.kitware.com/vtk/vtk/merge_requests/399 > > But they are a dozen of bugs, can I have your advice about my fix and what > would be the correct way to do it ? > > > Mathieu Westphal > > On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> I have no better solution for topological cracks that what is currently >> implemented with the radius. >> Actually i've looking at it too fast, there is no design problem in the >> current implementation, and I understand complettelly why we need to limit >> the walk. >> >> However there is a typo ! >> if(cell->EvaluatePosition(x, closestPoint, subId, >> pcoords, dist2, weights) == 1 >> && (dist2 <= tol2)) >> { >> return cellId; >> } >> >> Should be : >> >> int ret = cell->EvaluatePosition(x, closestPoint, subId, >> pcoords, dist2, weights); >> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >> { >> return cellId; >> } >> >> Doesn't it ? >> >> >> Mathieu Westphal >> >> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> Mathieu- >>> >>> I am going to look this over on the weekend. There are several known >>> issues due to a variety of complex reasons; and if I remember right there >>> are pathological cases with what you propose (walking across neighbors) >>> because if there is topological separation/cracks between neighboring cells >>> it's possible to fail too. >>> >>> Anyway I'll have a chance to look this weekend and we'll talk soon. I >>> think the bottom line is that to 100% guarantee to find the containing cell >>> a cell locator is needed, but for performance/memory reasons a point >>> locator has been used in the past (unfortunately a performance tradeoff >>> that comes back to bite us repeatedly). There may be more intelligent ways >>> to consider the N closest points from FindPoint which may produce better >>> results and don't cost too much in performance/memory. >>> >>> W >>> >>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>> mathieu.westphal at kitware.com> wrote: >>> >>>> There is a bug in vtkPointCell::FindCell >>>> >>>> I copy here my mantis bug and associated notes: >>>> http://www.vtk.org/Bug/view.php?id=15573 >>>> >>>> The current implementation of FindCell/ FindCellWalk is just wrong and >>>> not working in some case : >>>> >>>> See atached image. >>>> In the current implementation there is three pass : >>>> >>>> 1 : FindPoint, Check CellPoint >>>> 2 : Check first neighbor >>>> 3 : Check CellPoint within tolerance >>>> >>>> In the associated image, one can see the the first pass will find red >>>> star and only check Cell 1 >>>> the second pass will only check cell 2 >>>> the third pass will not check anything more >>>> >>>> Cell 3 will never be found. >>>> >>>> I propose a solution based on vtkStreamTracer surface implementation, >>>> which walk among neighbors more smartly using pcoords and cell boundary. >>>> >>>> See : >>>> >>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>> [^ >>>> >>>> ] >>>> >>>> What do you think ? >>>> >>>> Mathieu Westphal >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the 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. >>> 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 mathieu.westphal at kitware.com Thu Nov 19 08:00:16 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 19 Nov 2015 14:00:16 +0100 Subject: [vtk-developers] Gil tests on megas In-Reply-To: <20151118212637.GA25782@megas.khq.kitware.com> References: <20151118203446.GA31837@megas.khq.kitware.com> <20151118212637.GA25782@megas.khq.kitware.com> Message-ID: Nicely done. Mathieu Westphal On Wed, Nov 18, 2015 at 10:26 PM, Ben Boeckel wrote: > On Wed, Nov 18, 2015 at 13:49:06 -0700, David Gobbi wrote: > > Oops! Thanks for finding this. I can cherry-pick your (pending) fix to > > my python-py3k branch for VTK 6.3. > > Yeah, this is that weird bug we saw months ago rearing its head, but it > has been consistent lately. At least it's a simple fix :) . > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Thu Nov 19 08:13:56 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 19 Nov 2015 08:13:56 -0500 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: It was a long weekend :-) So the key section of code is: int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, dist2, weights); if (ret == 1 || ( ret == 0 && dist2 <= tol2)) I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is basically identifying a cell in which to begin further searching, despite the fact that point x is not actually in the cell. So there is more likelihood of finding the containing cell. Does this affect performance significantly? W On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > Will- > > I am pretty sure the weekend is over now ;) > Do you think Mathieu's patch make sense? > So far it breaks some tests and we need to analyze if the some of the new > results are more appropriate or just incorrect... > > Best, > Joachim > > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > > 2015-07-15 14:16 GMT+02:00 Mathieu Westphal > : > >> Hello >> >> I've created a fix for FindCell : >> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >> >> But they are a dozen of bugs, can I have your advice about my fix and >> what would be the correct way to do it ? >> >> >> Mathieu Westphal >> >> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> I have no better solution for topological cracks that what is currently >>> implemented with the radius. >>> Actually i've looking at it too fast, there is no design problem in the >>> current implementation, and I understand complettelly why we need to limit >>> the walk. >>> >>> However there is a typo ! >>> if(cell->EvaluatePosition(x, closestPoint, subId, >>> pcoords, dist2, weights) == 1 >>> && (dist2 <= tol2)) >>> { >>> return cellId; >>> } >>> >>> Should be : >>> >>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>> pcoords, dist2, weights); >>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>> { >>> return cellId; >>> } >>> >>> Doesn't it ? >>> >>> >>> Mathieu Westphal >>> >>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> Mathieu- >>>> >>>> I am going to look this over on the weekend. There are several known >>>> issues due to a variety of complex reasons; and if I remember right there >>>> are pathological cases with what you propose (walking across neighbors) >>>> because if there is topological separation/cracks between neighboring cells >>>> it's possible to fail too. >>>> >>>> Anyway I'll have a chance to look this weekend and we'll talk soon. I >>>> think the bottom line is that to 100% guarantee to find the containing cell >>>> a cell locator is needed, but for performance/memory reasons a point >>>> locator has been used in the past (unfortunately a performance tradeoff >>>> that comes back to bite us repeatedly). There may be more intelligent ways >>>> to consider the N closest points from FindPoint which may produce better >>>> results and don't cost too much in performance/memory. >>>> >>>> W >>>> >>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>> mathieu.westphal at kitware.com> wrote: >>>> >>>>> There is a bug in vtkPointCell::FindCell >>>>> >>>>> I copy here my mantis bug and associated notes: >>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>> >>>>> The current implementation of FindCell/ FindCellWalk is just wrong and >>>>> not working in some case : >>>>> >>>>> See atached image. >>>>> In the current implementation there is three pass : >>>>> >>>>> 1 : FindPoint, Check CellPoint >>>>> 2 : Check first neighbor >>>>> 3 : Check CellPoint within tolerance >>>>> >>>>> In the associated image, one can see the the first pass will find red >>>>> star and only check Cell 1 >>>>> the second pass will only check cell 2 >>>>> the third pass will not check anything more >>>>> >>>>> Cell 3 will never be found. >>>>> >>>>> I propose a solution based on vtkStreamTracer surface implementation, >>>>> which walk among neighbors more smartly using pcoords and cell boundary. >>>>> >>>>> See : >>>>> >>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>> [^ >>>>> >>>>> ] >>>>> >>>>> What do you think ? >>>>> >>>>> Mathieu Westphal >>>>> >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the 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. >>>> 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 >> >> >> > -- William J. Schroeder, PhD Kitware, Inc. 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 mathieu.westphal at kitware.com Thu Nov 19 08:19:14 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 19 Nov 2015 14:19:14 +0100 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Hi I have seen no notable difference of performance with the algorithm i was working on. But it will find more cell , especially in certain cases, so the results of algorithms dependent of FindCell will be different. we need to determine which one is right and which one is wrong. Mathieu Mathieu Westphal On Thu, Nov 19, 2015 at 2:13 PM, Will Schroeder wrote: > It was a long weekend :-) > > So the key section of code is: > > int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, dist2, > weights); > if (ret == 1 || ( ret == 0 && dist2 <= tol2)) > > I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is basically > identifying a cell in which to begin further searching, despite the fact > that point x is not actually in the cell. So there is more likelihood of > finding the containing cell. Does this affect performance significantly? > > W > > > On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < > joachim.pouderoux at kitware.com> wrote: > >> Will- >> >> I am pretty sure the weekend is over now ;) >> Do you think Mathieu's patch make sense? >> So far it breaks some tests and we need to analyze if the some of the new >> results are more appropriate or just incorrect... >> >> Best, >> Joachim >> >> >> *Joachim Pouderoux* >> >> *PhD, Technical Expert* >> *Kitware SAS * >> >> >> 2015-07-15 14:16 GMT+02:00 Mathieu Westphal > >: >> >>> Hello >>> >>> I've created a fix for FindCell : >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >>> >>> But they are a dozen of bugs, can I have your advice about my fix and >>> what would be the correct way to do it ? >>> >>> >>> Mathieu Westphal >>> >>> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >>> mathieu.westphal at kitware.com> wrote: >>> >>>> I have no better solution for topological cracks that what is currently >>>> implemented with the radius. >>>> Actually i've looking at it too fast, there is no design problem in the >>>> current implementation, and I understand complettelly why we need to limit >>>> the walk. >>>> >>>> However there is a typo ! >>>> if(cell->EvaluatePosition(x, closestPoint, subId, >>>> pcoords, dist2, weights) == 1 >>>> && (dist2 <= tol2)) >>>> { >>>> return cellId; >>>> } >>>> >>>> Should be : >>>> >>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>>> pcoords, dist2, weights); >>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>> { >>>> return cellId; >>>> } >>>> >>>> Doesn't it ? >>>> >>>> >>>> Mathieu Westphal >>>> >>>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> Mathieu- >>>>> >>>>> I am going to look this over on the weekend. There are several known >>>>> issues due to a variety of complex reasons; and if I remember right there >>>>> are pathological cases with what you propose (walking across neighbors) >>>>> because if there is topological separation/cracks between neighboring cells >>>>> it's possible to fail too. >>>>> >>>>> Anyway I'll have a chance to look this weekend and we'll talk soon. I >>>>> think the bottom line is that to 100% guarantee to find the containing cell >>>>> a cell locator is needed, but for performance/memory reasons a point >>>>> locator has been used in the past (unfortunately a performance tradeoff >>>>> that comes back to bite us repeatedly). There may be more intelligent ways >>>>> to consider the N closest points from FindPoint which may produce better >>>>> results and don't cost too much in performance/memory. >>>>> >>>>> W >>>>> >>>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>>> mathieu.westphal at kitware.com> wrote: >>>>> >>>>>> There is a bug in vtkPointCell::FindCell >>>>>> >>>>>> I copy here my mantis bug and associated notes: >>>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>>> >>>>>> The current implementation of FindCell/ FindCellWalk is just wrong >>>>>> and not working in some case : >>>>>> >>>>>> See atached image. >>>>>> In the current implementation there is three pass : >>>>>> >>>>>> 1 : FindPoint, Check CellPoint >>>>>> 2 : Check first neighbor >>>>>> 3 : Check CellPoint within tolerance >>>>>> >>>>>> In the associated image, one can see the the first pass will find red >>>>>> star and only check Cell 1 >>>>>> the second pass will only check cell 2 >>>>>> the third pass will not check anything more >>>>>> >>>>>> Cell 3 will never be found. >>>>>> >>>>>> I propose a solution based on vtkStreamTracer surface implementation, >>>>>> which walk among neighbors more smartly using pcoords and cell boundary. >>>>>> >>>>>> See : >>>>>> >>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>>> [^ >>>>>> >>>>>> ] >>>>>> >>>>>> What do you think ? >>>>>> >>>>>> Mathieu Westphal >>>>>> >>>>>> _______________________________________________ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Search the 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. >>>>> 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 >>> >>> >>> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 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 will.schroeder at kitware.com Thu Nov 19 08:45:06 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 19 Nov 2015 08:45:06 -0500 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: I'm thinking there are two basic use cases. First, find the cell that contains the point (x must be in the cell); and second, find a cell very close to the point from which to launch additional searches or other local operations. I'm wondering if we can adjust the design / API / etc. to explicitly control for this. Thoughts? W On Thu, Nov 19, 2015 at 8:19 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hi > > I have seen no notable difference of performance with the algorithm i was > working on. But it will find more cell , especially in certain cases, so > the results of algorithms dependent of FindCell will be different. we need > to determine which one is right and which one is wrong. > > Mathieu > > Mathieu Westphal > > On Thu, Nov 19, 2015 at 2:13 PM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> It was a long weekend :-) >> >> So the key section of code is: >> >> int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, >> dist2, weights); >> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >> >> I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is basically >> identifying a cell in which to begin further searching, despite the fact >> that point x is not actually in the cell. So there is more likelihood of >> finding the containing cell. Does this affect performance significantly? >> >> W >> >> >> On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < >> joachim.pouderoux at kitware.com> wrote: >> >>> Will- >>> >>> I am pretty sure the weekend is over now ;) >>> Do you think Mathieu's patch make sense? >>> So far it breaks some tests and we need to analyze if the some of the >>> new results are more appropriate or just incorrect... >>> >>> Best, >>> Joachim >>> >>> >>> *Joachim Pouderoux* >>> >>> *PhD, Technical Expert* >>> *Kitware SAS * >>> >>> >>> 2015-07-15 14:16 GMT+02:00 Mathieu Westphal < >>> mathieu.westphal at kitware.com>: >>> >>>> Hello >>>> >>>> I've created a fix for FindCell : >>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >>>> >>>> But they are a dozen of bugs, can I have your advice about my fix and >>>> what would be the correct way to do it ? >>>> >>>> >>>> Mathieu Westphal >>>> >>>> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >>>> mathieu.westphal at kitware.com> wrote: >>>> >>>>> I have no better solution for topological cracks that what is >>>>> currently implemented with the radius. >>>>> Actually i've looking at it too fast, there is no design problem in >>>>> the current implementation, and I understand complettelly why we need to >>>>> limit the walk. >>>>> >>>>> However there is a typo ! >>>>> if(cell->EvaluatePosition(x, closestPoint, subId, >>>>> pcoords, dist2, weights) == 1 >>>>> && (dist2 <= tol2)) >>>>> { >>>>> return cellId; >>>>> } >>>>> >>>>> Should be : >>>>> >>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>>>> pcoords, dist2, weights); >>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>> { >>>>> return cellId; >>>>> } >>>>> >>>>> Doesn't it ? >>>>> >>>>> >>>>> Mathieu Westphal >>>>> >>>>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> Mathieu- >>>>>> >>>>>> I am going to look this over on the weekend. There are several known >>>>>> issues due to a variety of complex reasons; and if I remember right there >>>>>> are pathological cases with what you propose (walking across neighbors) >>>>>> because if there is topological separation/cracks between neighboring cells >>>>>> it's possible to fail too. >>>>>> >>>>>> Anyway I'll have a chance to look this weekend and we'll talk soon. I >>>>>> think the bottom line is that to 100% guarantee to find the containing cell >>>>>> a cell locator is needed, but for performance/memory reasons a point >>>>>> locator has been used in the past (unfortunately a performance tradeoff >>>>>> that comes back to bite us repeatedly). There may be more intelligent ways >>>>>> to consider the N closest points from FindPoint which may produce better >>>>>> results and don't cost too much in performance/memory. >>>>>> >>>>>> W >>>>>> >>>>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>>>> mathieu.westphal at kitware.com> wrote: >>>>>> >>>>>>> There is a bug in vtkPointCell::FindCell >>>>>>> >>>>>>> I copy here my mantis bug and associated notes: >>>>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>>>> >>>>>>> The current implementation of FindCell/ FindCellWalk is just wrong >>>>>>> and not working in some case : >>>>>>> >>>>>>> See atached image. >>>>>>> In the current implementation there is three pass : >>>>>>> >>>>>>> 1 : FindPoint, Check CellPoint >>>>>>> 2 : Check first neighbor >>>>>>> 3 : Check CellPoint within tolerance >>>>>>> >>>>>>> In the associated image, one can see the the first pass will find >>>>>>> red star and only check Cell 1 >>>>>>> the second pass will only check cell 2 >>>>>>> the third pass will not check anything more >>>>>>> >>>>>>> Cell 3 will never be found. >>>>>>> >>>>>>> I propose a solution based on vtkStreamTracer surface >>>>>>> implementation, which walk among neighbors more smartly using pcoords and >>>>>>> cell boundary. >>>>>>> >>>>>>> See : >>>>>>> >>>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>>>> [^ >>>>>>> >>>>>>> ] >>>>>>> >>>>>>> What do you think ? >>>>>>> >>>>>>> Mathieu Westphal >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Search the 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. >>>>>> 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 >>>> >>>> >>>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -- William J. Schroeder, PhD Kitware, Inc. 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 mathieu.westphal at kitware.com Thu Nov 19 08:49:28 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 19 Nov 2015 14:49:28 +0100 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Well i supose that's what the tolerance (tol2 param) is for, is it not ? at least that is why i have reimplemented it the way i did. Mathieu Mathieu Westphal On Thu, Nov 19, 2015 at 2:45 PM, Will Schroeder wrote: > I'm thinking there are two basic use cases. First, find the cell that > contains the point (x must be in the cell); and second, find a cell very > close to the point from which to launch additional searches or other local > operations. I'm wondering if we can adjust the design / API / etc. to > explicitly control for this. > > Thoughts? > > W > > On Thu, Nov 19, 2015 at 8:19 AM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> Hi >> >> I have seen no notable difference of performance with the algorithm i was >> working on. But it will find more cell , especially in certain cases, so >> the results of algorithms dependent of FindCell will be different. we need >> to determine which one is right and which one is wrong. >> >> Mathieu >> >> Mathieu Westphal >> >> On Thu, Nov 19, 2015 at 2:13 PM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> It was a long weekend :-) >>> >>> So the key section of code is: >>> >>> int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, >>> dist2, weights); >>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>> >>> I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is basically >>> identifying a cell in which to begin further searching, despite the fact >>> that point x is not actually in the cell. So there is more likelihood of >>> finding the containing cell. Does this affect performance significantly? >>> >>> W >>> >>> >>> On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < >>> joachim.pouderoux at kitware.com> wrote: >>> >>>> Will- >>>> >>>> I am pretty sure the weekend is over now ;) >>>> Do you think Mathieu's patch make sense? >>>> So far it breaks some tests and we need to analyze if the some of the >>>> new results are more appropriate or just incorrect... >>>> >>>> Best, >>>> Joachim >>>> >>>> >>>> *Joachim Pouderoux* >>>> >>>> *PhD, Technical Expert* >>>> *Kitware SAS * >>>> >>>> >>>> 2015-07-15 14:16 GMT+02:00 Mathieu Westphal < >>>> mathieu.westphal at kitware.com>: >>>> >>>>> Hello >>>>> >>>>> I've created a fix for FindCell : >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >>>>> >>>>> But they are a dozen of bugs, can I have your advice about my fix and >>>>> what would be the correct way to do it ? >>>>> >>>>> >>>>> Mathieu Westphal >>>>> >>>>> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >>>>> mathieu.westphal at kitware.com> wrote: >>>>> >>>>>> I have no better solution for topological cracks that what is >>>>>> currently implemented with the radius. >>>>>> Actually i've looking at it too fast, there is no design problem in >>>>>> the current implementation, and I understand complettelly why we need to >>>>>> limit the walk. >>>>>> >>>>>> However there is a typo ! >>>>>> if(cell->EvaluatePosition(x, closestPoint, subId, >>>>>> pcoords, dist2, weights) == 1 >>>>>> && (dist2 <= tol2)) >>>>>> { >>>>>> return cellId; >>>>>> } >>>>>> >>>>>> Should be : >>>>>> >>>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>>>>> pcoords, dist2, weights); >>>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>>> { >>>>>> return cellId; >>>>>> } >>>>>> >>>>>> Doesn't it ? >>>>>> >>>>>> >>>>>> Mathieu Westphal >>>>>> >>>>>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>>>>> will.schroeder at kitware.com> wrote: >>>>>> >>>>>>> Mathieu- >>>>>>> >>>>>>> I am going to look this over on the weekend. There are several known >>>>>>> issues due to a variety of complex reasons; and if I remember right there >>>>>>> are pathological cases with what you propose (walking across neighbors) >>>>>>> because if there is topological separation/cracks between neighboring cells >>>>>>> it's possible to fail too. >>>>>>> >>>>>>> Anyway I'll have a chance to look this weekend and we'll talk soon. >>>>>>> I think the bottom line is that to 100% guarantee to find the containing >>>>>>> cell a cell locator is needed, but for performance/memory reasons a point >>>>>>> locator has been used in the past (unfortunately a performance tradeoff >>>>>>> that comes back to bite us repeatedly). There may be more intelligent ways >>>>>>> to consider the N closest points from FindPoint which may produce better >>>>>>> results and don't cost too much in performance/memory. >>>>>>> >>>>>>> W >>>>>>> >>>>>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>>>>> mathieu.westphal at kitware.com> wrote: >>>>>>> >>>>>>>> There is a bug in vtkPointCell::FindCell >>>>>>>> >>>>>>>> I copy here my mantis bug and associated notes: >>>>>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>>>>> >>>>>>>> The current implementation of FindCell/ FindCellWalk is just wrong >>>>>>>> and not working in some case : >>>>>>>> >>>>>>>> See atached image. >>>>>>>> In the current implementation there is three pass : >>>>>>>> >>>>>>>> 1 : FindPoint, Check CellPoint >>>>>>>> 2 : Check first neighbor >>>>>>>> 3 : Check CellPoint within tolerance >>>>>>>> >>>>>>>> In the associated image, one can see the the first pass will find >>>>>>>> red star and only check Cell 1 >>>>>>>> the second pass will only check cell 2 >>>>>>>> the third pass will not check anything more >>>>>>>> >>>>>>>> Cell 3 will never be found. >>>>>>>> >>>>>>>> I propose a solution based on vtkStreamTracer surface >>>>>>>> implementation, which walk among neighbors more smartly using pcoords and >>>>>>>> cell boundary. >>>>>>>> >>>>>>>> See : >>>>>>>> >>>>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>>>>> [^ >>>>>>>> >>>>>>>> ] >>>>>>>> >>>>>>>> What do you think ? >>>>>>>> >>>>>>>> Mathieu Westphal >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Search the 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. >>>>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >>> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 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 will.schroeder at kitware.com Thu Nov 19 09:00:01 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 19 Nov 2015 09:00:01 -0500 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Yes I was thinking along similar lines. I also checked into the implementations of a few cells like vtkTriangle::EvaluatePosition(). Tolerancing does not seem to be used in the few EvaluatePosition() methods I checked so I think using the tolerance is reasonable. However as I'm sure you well know, a tolerance effectively defines a fuzzy boundary region where a point could lie in more than one cell. In this situation you could conceivably keep track of the minimal dist2 and return the corresponding cell, but I'm guessing that this would complicate the code and affect performance. W On Thu, Nov 19, 2015 at 8:49 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Well i supose that's what the tolerance (tol2 param) is for, is it not ? > at least that is why i have reimplemented it the way i did. > > Mathieu > > > > Mathieu Westphal > > On Thu, Nov 19, 2015 at 2:45 PM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> I'm thinking there are two basic use cases. First, find the cell that >> contains the point (x must be in the cell); and second, find a cell very >> close to the point from which to launch additional searches or other local >> operations. I'm wondering if we can adjust the design / API / etc. to >> explicitly control for this. >> >> Thoughts? >> >> W >> >> On Thu, Nov 19, 2015 at 8:19 AM, Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> Hi >>> >>> I have seen no notable difference of performance with the algorithm i >>> was working on. But it will find more cell , especially in certain cases, >>> so the results of algorithms dependent of FindCell will be different. we >>> need to determine which one is right and which one is wrong. >>> >>> Mathieu >>> >>> Mathieu Westphal >>> >>> On Thu, Nov 19, 2015 at 2:13 PM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> It was a long weekend :-) >>>> >>>> So the key section of code is: >>>> >>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, >>>> dist2, weights); >>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>> >>>> I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is >>>> basically identifying a cell in which to begin further searching, despite >>>> the fact that point x is not actually in the cell. So there is more >>>> likelihood of finding the containing cell. Does this affect performance >>>> significantly? >>>> >>>> W >>>> >>>> >>>> On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < >>>> joachim.pouderoux at kitware.com> wrote: >>>> >>>>> Will- >>>>> >>>>> I am pretty sure the weekend is over now ;) >>>>> Do you think Mathieu's patch make sense? >>>>> So far it breaks some tests and we need to analyze if the some of the >>>>> new results are more appropriate or just incorrect... >>>>> >>>>> Best, >>>>> Joachim >>>>> >>>>> >>>>> *Joachim Pouderoux* >>>>> >>>>> *PhD, Technical Expert* >>>>> *Kitware SAS * >>>>> >>>>> >>>>> 2015-07-15 14:16 GMT+02:00 Mathieu Westphal < >>>>> mathieu.westphal at kitware.com>: >>>>> >>>>>> Hello >>>>>> >>>>>> I've created a fix for FindCell : >>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >>>>>> >>>>>> But they are a dozen of bugs, can I have your advice about my fix and >>>>>> what would be the correct way to do it ? >>>>>> >>>>>> >>>>>> Mathieu Westphal >>>>>> >>>>>> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >>>>>> mathieu.westphal at kitware.com> wrote: >>>>>> >>>>>>> I have no better solution for topological cracks that what is >>>>>>> currently implemented with the radius. >>>>>>> Actually i've looking at it too fast, there is no design problem in >>>>>>> the current implementation, and I understand complettelly why we need to >>>>>>> limit the walk. >>>>>>> >>>>>>> However there is a typo ! >>>>>>> if(cell->EvaluatePosition(x, closestPoint, subId, >>>>>>> pcoords, dist2, weights) == 1 >>>>>>> && (dist2 <= tol2)) >>>>>>> { >>>>>>> return cellId; >>>>>>> } >>>>>>> >>>>>>> Should be : >>>>>>> >>>>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>>>>>> pcoords, dist2, weights); >>>>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>>>> { >>>>>>> return cellId; >>>>>>> } >>>>>>> >>>>>>> Doesn't it ? >>>>>>> >>>>>>> >>>>>>> Mathieu Westphal >>>>>>> >>>>>>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>>>>>> will.schroeder at kitware.com> wrote: >>>>>>> >>>>>>>> Mathieu- >>>>>>>> >>>>>>>> I am going to look this over on the weekend. There are several >>>>>>>> known issues due to a variety of complex reasons; and if I remember right >>>>>>>> there are pathological cases with what you propose (walking across >>>>>>>> neighbors) because if there is topological separation/cracks between >>>>>>>> neighboring cells it's possible to fail too. >>>>>>>> >>>>>>>> Anyway I'll have a chance to look this weekend and we'll talk soon. >>>>>>>> I think the bottom line is that to 100% guarantee to find the containing >>>>>>>> cell a cell locator is needed, but for performance/memory reasons a point >>>>>>>> locator has been used in the past (unfortunately a performance tradeoff >>>>>>>> that comes back to bite us repeatedly). There may be more intelligent ways >>>>>>>> to consider the N closest points from FindPoint which may produce better >>>>>>>> results and don't cost too much in performance/memory. >>>>>>>> >>>>>>>> W >>>>>>>> >>>>>>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>>>>>> mathieu.westphal at kitware.com> wrote: >>>>>>>> >>>>>>>>> There is a bug in vtkPointCell::FindCell >>>>>>>>> >>>>>>>>> I copy here my mantis bug and associated notes: >>>>>>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>>>>>> >>>>>>>>> The current implementation of FindCell/ FindCellWalk is just wrong >>>>>>>>> and not working in some case : >>>>>>>>> >>>>>>>>> See atached image. >>>>>>>>> In the current implementation there is three pass : >>>>>>>>> >>>>>>>>> 1 : FindPoint, Check CellPoint >>>>>>>>> 2 : Check first neighbor >>>>>>>>> 3 : Check CellPoint within tolerance >>>>>>>>> >>>>>>>>> In the associated image, one can see the the first pass will find >>>>>>>>> red star and only check Cell 1 >>>>>>>>> the second pass will only check cell 2 >>>>>>>>> the third pass will not check anything more >>>>>>>>> >>>>>>>>> Cell 3 will never be found. >>>>>>>>> >>>>>>>>> I propose a solution based on vtkStreamTracer surface >>>>>>>>> implementation, which walk among neighbors more smartly using pcoords and >>>>>>>>> cell boundary. >>>>>>>>> >>>>>>>>> See : >>>>>>>>> >>>>>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>>>>>> [^ >>>>>>>>> >>>>>>>>> ] >>>>>>>>> >>>>>>>>> What do you think ? >>>>>>>>> >>>>>>>>> Mathieu Westphal >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Search the 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. >>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> William J. Schroeder, PhD >>>> Kitware, Inc. >>>> 28 Corporate Drive >>>> Clifton Park, NY 12065 >>>> will.schroeder at kitware.com >>>> http://www.kitware.com >>>> (518) 881-4902 >>>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. >> 28 Corporate Drive >> Clifton Park, NY 12065 >> will.schroeder at kitware.com >> http://www.kitware.com >> (518) 881-4902 >> > > -- William J. Schroeder, PhD Kitware, Inc. 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 berk.geveci at kitware.com Thu Nov 19 09:19:43 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 19 Nov 2015 08:19:43 -0600 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: Guys, Please make sure that you are running some good performance tests while making any changes there. Slow-down in FindCell would have a huge impact on VTK's performance. It could be faster as it is... -berk On Thu, Nov 19, 2015 at 8:00 AM, Will Schroeder wrote: > Yes I was thinking along similar lines. I also checked into the > implementations of a few cells like vtkTriangle::EvaluatePosition(). > Tolerancing does not seem to be used in the few EvaluatePosition() methods > I checked so I think using the tolerance is reasonable. However as I'm sure > you well know, a tolerance effectively defines a fuzzy boundary region > where a point could lie in more than one cell. In this situation you could > conceivably keep track of the minimal dist2 and return the corresponding > cell, but I'm guessing that this would complicate the code and affect > performance. > > W > > On Thu, Nov 19, 2015 at 8:49 AM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> Well i supose that's what the tolerance (tol2 param) is for, is it not ? >> at least that is why i have reimplemented it the way i did. >> >> Mathieu >> >> >> >> Mathieu Westphal >> >> On Thu, Nov 19, 2015 at 2:45 PM, Will Schroeder < >> will.schroeder at kitware.com> wrote: >> >>> I'm thinking there are two basic use cases. First, find the cell that >>> contains the point (x must be in the cell); and second, find a cell very >>> close to the point from which to launch additional searches or other local >>> operations. I'm wondering if we can adjust the design / API / etc. to >>> explicitly control for this. >>> >>> Thoughts? >>> >>> W >>> >>> On Thu, Nov 19, 2015 at 8:19 AM, Mathieu Westphal < >>> mathieu.westphal at kitware.com> wrote: >>> >>>> Hi >>>> >>>> I have seen no notable difference of performance with the algorithm i >>>> was working on. But it will find more cell , especially in certain cases, >>>> so the results of algorithms dependent of FindCell will be different. we >>>> need to determine which one is right and which one is wrong. >>>> >>>> Mathieu >>>> >>>> Mathieu Westphal >>>> >>>> On Thu, Nov 19, 2015 at 2:13 PM, Will Schroeder < >>>> will.schroeder at kitware.com> wrote: >>>> >>>>> It was a long weekend :-) >>>>> >>>>> So the key section of code is: >>>>> >>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, >>>>> dist2, weights); >>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>> >>>>> I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is >>>>> basically identifying a cell in which to begin further searching, despite >>>>> the fact that point x is not actually in the cell. So there is more >>>>> likelihood of finding the containing cell. Does this affect performance >>>>> significantly? >>>>> >>>>> W >>>>> >>>>> >>>>> On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < >>>>> joachim.pouderoux at kitware.com> wrote: >>>>> >>>>>> Will- >>>>>> >>>>>> I am pretty sure the weekend is over now ;) >>>>>> Do you think Mathieu's patch make sense? >>>>>> So far it breaks some tests and we need to analyze if the some of the >>>>>> new results are more appropriate or just incorrect... >>>>>> >>>>>> Best, >>>>>> Joachim >>>>>> >>>>>> >>>>>> *Joachim Pouderoux* >>>>>> >>>>>> *PhD, Technical Expert* >>>>>> *Kitware SAS * >>>>>> >>>>>> >>>>>> 2015-07-15 14:16 GMT+02:00 Mathieu Westphal < >>>>>> mathieu.westphal at kitware.com>: >>>>>> >>>>>>> Hello >>>>>>> >>>>>>> I've created a fix for FindCell : >>>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >>>>>>> >>>>>>> But they are a dozen of bugs, can I have your advice about my fix >>>>>>> and what would be the correct way to do it ? >>>>>>> >>>>>>> >>>>>>> Mathieu Westphal >>>>>>> >>>>>>> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >>>>>>> mathieu.westphal at kitware.com> wrote: >>>>>>> >>>>>>>> I have no better solution for topological cracks that what is >>>>>>>> currently implemented with the radius. >>>>>>>> Actually i've looking at it too fast, there is no design problem in >>>>>>>> the current implementation, and I understand complettelly why we need to >>>>>>>> limit the walk. >>>>>>>> >>>>>>>> However there is a typo ! >>>>>>>> if(cell->EvaluatePosition(x, closestPoint, subId, >>>>>>>> pcoords, dist2, weights) == 1 >>>>>>>> && (dist2 <= tol2)) >>>>>>>> { >>>>>>>> return cellId; >>>>>>>> } >>>>>>>> >>>>>>>> Should be : >>>>>>>> >>>>>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>>>>>>> pcoords, dist2, weights); >>>>>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>>>>> { >>>>>>>> return cellId; >>>>>>>> } >>>>>>>> >>>>>>>> Doesn't it ? >>>>>>>> >>>>>>>> >>>>>>>> Mathieu Westphal >>>>>>>> >>>>>>>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>>>>>>> will.schroeder at kitware.com> wrote: >>>>>>>> >>>>>>>>> Mathieu- >>>>>>>>> >>>>>>>>> I am going to look this over on the weekend. There are several >>>>>>>>> known issues due to a variety of complex reasons; and if I remember right >>>>>>>>> there are pathological cases with what you propose (walking across >>>>>>>>> neighbors) because if there is topological separation/cracks between >>>>>>>>> neighboring cells it's possible to fail too. >>>>>>>>> >>>>>>>>> Anyway I'll have a chance to look this weekend and we'll talk >>>>>>>>> soon. I think the bottom line is that to 100% guarantee to find the >>>>>>>>> containing cell a cell locator is needed, but for performance/memory >>>>>>>>> reasons a point locator has been used in the past (unfortunately a >>>>>>>>> performance tradeoff that comes back to bite us repeatedly). There may be >>>>>>>>> more intelligent ways to consider the N closest points from FindPoint which >>>>>>>>> may produce better results and don't cost too much in performance/memory. >>>>>>>>> >>>>>>>>> W >>>>>>>>> >>>>>>>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>>>>>>> mathieu.westphal at kitware.com> wrote: >>>>>>>>> >>>>>>>>>> There is a bug in vtkPointCell::FindCell >>>>>>>>>> >>>>>>>>>> I copy here my mantis bug and associated notes: >>>>>>>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>>>>>>> >>>>>>>>>> The current implementation of FindCell/ FindCellWalk is just >>>>>>>>>> wrong and not working in some case : >>>>>>>>>> >>>>>>>>>> See atached image. >>>>>>>>>> In the current implementation there is three pass : >>>>>>>>>> >>>>>>>>>> 1 : FindPoint, Check CellPoint >>>>>>>>>> 2 : Check first neighbor >>>>>>>>>> 3 : Check CellPoint within tolerance >>>>>>>>>> >>>>>>>>>> In the associated image, one can see the the first pass will find >>>>>>>>>> red star and only check Cell 1 >>>>>>>>>> the second pass will only check cell 2 >>>>>>>>>> the third pass will not check anything more >>>>>>>>>> >>>>>>>>>> Cell 3 will never be found. >>>>>>>>>> >>>>>>>>>> I propose a solution based on vtkStreamTracer surface >>>>>>>>>> implementation, which walk among neighbors more smartly using pcoords and >>>>>>>>>> cell boundary. >>>>>>>>>> >>>>>>>>>> See : >>>>>>>>>> >>>>>>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>>>>>>> [^ >>>>>>>>>> >>>>>>>>>> ] >>>>>>>>>> >>>>>>>>>> What do you think ? >>>>>>>>>> >>>>>>>>>> Mathieu Westphal >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Powered by www.kitware.com >>>>>>>>>> >>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>> >>>>>>>>>> Search the 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. >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> William J. Schroeder, PhD >>>>> Kitware, Inc. >>>>> 28 Corporate Drive >>>>> Clifton Park, NY 12065 >>>>> will.schroeder at kitware.com >>>>> http://www.kitware.com >>>>> (518) 881-4902 >>>>> >>>> >>>> >>> >>> >>> -- >>> William J. Schroeder, PhD >>> Kitware, Inc. >>> 28 Corporate Drive >>> Clifton Park, NY 12065 >>> will.schroeder at kitware.com >>> http://www.kitware.com >>> (518) 881-4902 >>> >> >> > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 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 will.schroeder at kitware.com Thu Nov 19 09:37:11 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 19 Nov 2015 09:37:11 -0500 Subject: [vtk-developers] bug in vtkPointSet::FindCell In-Reply-To: References: Message-ID: ...at some point I'm thinking we step back and rethink this whole algorithm. For example, there's no reason we couldn't parallelize the inside cell checks / EvaluatePosition() and then compare/composite the results. And there may be better spatial search structures to look at.... On Thu, Nov 19, 2015 at 9:19 AM, Berk Geveci wrote: > Guys, > > Please make sure that you are running some good performance tests while > making any changes there. Slow-down in FindCell would have a huge impact on > VTK's performance. It could be faster as it is... > > -berk > > On Thu, Nov 19, 2015 at 8:00 AM, Will Schroeder < > will.schroeder at kitware.com> wrote: > >> Yes I was thinking along similar lines. I also checked into the >> implementations of a few cells like vtkTriangle::EvaluatePosition(). >> Tolerancing does not seem to be used in the few EvaluatePosition() methods >> I checked so I think using the tolerance is reasonable. However as I'm sure >> you well know, a tolerance effectively defines a fuzzy boundary region >> where a point could lie in more than one cell. In this situation you could >> conceivably keep track of the minimal dist2 and return the corresponding >> cell, but I'm guessing that this would complicate the code and affect >> performance. >> >> W >> >> On Thu, Nov 19, 2015 at 8:49 AM, Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> Well i supose that's what the tolerance (tol2 param) is for, is it not ? >>> at least that is why i have reimplemented it the way i did. >>> >>> Mathieu >>> >>> >>> >>> Mathieu Westphal >>> >>> On Thu, Nov 19, 2015 at 2:45 PM, Will Schroeder < >>> will.schroeder at kitware.com> wrote: >>> >>>> I'm thinking there are two basic use cases. First, find the cell that >>>> contains the point (x must be in the cell); and second, find a cell very >>>> close to the point from which to launch additional searches or other local >>>> operations. I'm wondering if we can adjust the design / API / etc. to >>>> explicitly control for this. >>>> >>>> Thoughts? >>>> >>>> W >>>> >>>> On Thu, Nov 19, 2015 at 8:19 AM, Mathieu Westphal < >>>> mathieu.westphal at kitware.com> wrote: >>>> >>>>> Hi >>>>> >>>>> I have seen no notable difference of performance with the algorithm i >>>>> was working on. But it will find more cell , especially in certain cases, >>>>> so the results of algorithms dependent of FindCell will be different. we >>>>> need to determine which one is right and which one is wrong. >>>>> >>>>> Mathieu >>>>> >>>>> Mathieu Westphal >>>>> >>>>> On Thu, Nov 19, 2015 at 2:13 PM, Will Schroeder < >>>>> will.schroeder at kitware.com> wrote: >>>>> >>>>>> It was a long weekend :-) >>>>>> >>>>>> So the key section of code is: >>>>>> >>>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, pcoords, >>>>>> dist2, weights); >>>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>>> >>>>>> I'm guessing that the if clause (ret == 0 && dist2 <= tol2) is >>>>>> basically identifying a cell in which to begin further searching, despite >>>>>> the fact that point x is not actually in the cell. So there is more >>>>>> likelihood of finding the containing cell. Does this affect performance >>>>>> significantly? >>>>>> >>>>>> W >>>>>> >>>>>> >>>>>> On Thu, Nov 19, 2015 at 4:33 AM, Joachim Pouderoux < >>>>>> joachim.pouderoux at kitware.com> wrote: >>>>>> >>>>>>> Will- >>>>>>> >>>>>>> I am pretty sure the weekend is over now ;) >>>>>>> Do you think Mathieu's patch make sense? >>>>>>> So far it breaks some tests and we need to analyze if the some of >>>>>>> the new results are more appropriate or just incorrect... >>>>>>> >>>>>>> Best, >>>>>>> Joachim >>>>>>> >>>>>>> >>>>>>> *Joachim Pouderoux* >>>>>>> >>>>>>> *PhD, Technical Expert* >>>>>>> *Kitware SAS * >>>>>>> >>>>>>> >>>>>>> 2015-07-15 14:16 GMT+02:00 Mathieu Westphal < >>>>>>> mathieu.westphal at kitware.com>: >>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> I've created a fix for FindCell : >>>>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/399 >>>>>>>> >>>>>>>> But they are a dozen of bugs, can I have your advice about my fix >>>>>>>> and what would be the correct way to do it ? >>>>>>>> >>>>>>>> >>>>>>>> Mathieu Westphal >>>>>>>> >>>>>>>> On Thu, Jul 9, 2015 at 5:03 PM, Mathieu Westphal < >>>>>>>> mathieu.westphal at kitware.com> wrote: >>>>>>>> >>>>>>>>> I have no better solution for topological cracks that what is >>>>>>>>> currently implemented with the radius. >>>>>>>>> Actually i've looking at it too fast, there is no design problem >>>>>>>>> in the current implementation, and I understand complettelly why we need to >>>>>>>>> limit the walk. >>>>>>>>> >>>>>>>>> However there is a typo ! >>>>>>>>> if(cell->EvaluatePosition(x, closestPoint, subId, >>>>>>>>> pcoords, dist2, weights) == 1 >>>>>>>>> && (dist2 <= tol2)) >>>>>>>>> { >>>>>>>>> return cellId; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Should be : >>>>>>>>> >>>>>>>>> int ret = cell->EvaluatePosition(x, closestPoint, subId, >>>>>>>>> pcoords, dist2, weights); >>>>>>>>> if (ret == 1 || ( ret == 0 && dist2 <= tol2)) >>>>>>>>> { >>>>>>>>> return cellId; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Doesn't it ? >>>>>>>>> >>>>>>>>> >>>>>>>>> Mathieu Westphal >>>>>>>>> >>>>>>>>> On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder < >>>>>>>>> will.schroeder at kitware.com> wrote: >>>>>>>>> >>>>>>>>>> Mathieu- >>>>>>>>>> >>>>>>>>>> I am going to look this over on the weekend. There are several >>>>>>>>>> known issues due to a variety of complex reasons; and if I remember right >>>>>>>>>> there are pathological cases with what you propose (walking across >>>>>>>>>> neighbors) because if there is topological separation/cracks between >>>>>>>>>> neighboring cells it's possible to fail too. >>>>>>>>>> >>>>>>>>>> Anyway I'll have a chance to look this weekend and we'll talk >>>>>>>>>> soon. I think the bottom line is that to 100% guarantee to find the >>>>>>>>>> containing cell a cell locator is needed, but for performance/memory >>>>>>>>>> reasons a point locator has been used in the past (unfortunately a >>>>>>>>>> performance tradeoff that comes back to bite us repeatedly). There may be >>>>>>>>>> more intelligent ways to consider the N closest points from FindPoint which >>>>>>>>>> may produce better results and don't cost too much in performance/memory. >>>>>>>>>> >>>>>>>>>> W >>>>>>>>>> >>>>>>>>>> On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal < >>>>>>>>>> mathieu.westphal at kitware.com> wrote: >>>>>>>>>> >>>>>>>>>>> There is a bug in vtkPointCell::FindCell >>>>>>>>>>> >>>>>>>>>>> I copy here my mantis bug and associated notes: >>>>>>>>>>> http://www.vtk.org/Bug/view.php?id=15573 >>>>>>>>>>> >>>>>>>>>>> The current implementation of FindCell/ FindCellWalk is just >>>>>>>>>>> wrong and not working in some case : >>>>>>>>>>> >>>>>>>>>>> See atached image. >>>>>>>>>>> In the current implementation there is three pass : >>>>>>>>>>> >>>>>>>>>>> 1 : FindPoint, Check CellPoint >>>>>>>>>>> 2 : Check first neighbor >>>>>>>>>>> 3 : Check CellPoint within tolerance >>>>>>>>>>> >>>>>>>>>>> In the associated image, one can see the the first pass will >>>>>>>>>>> find red star and only check Cell 1 >>>>>>>>>>> the second pass will only check cell 2 >>>>>>>>>>> the third pass will not check anything more >>>>>>>>>>> >>>>>>>>>>> Cell 3 will never be found. >>>>>>>>>>> >>>>>>>>>>> I propose a solution based on vtkStreamTracer surface >>>>>>>>>>> implementation, which walk among neighbors more smartly using pcoords and >>>>>>>>>>> cell boundary. >>>>>>>>>>> >>>>>>>>>>> See : >>>>>>>>>>> >>>>>>>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289 >>>>>>>>>>> [^ >>>>>>>>>>> >>>>>>>>>>> ] >>>>>>>>>>> >>>>>>>>>>> What do you think ? >>>>>>>>>>> >>>>>>>>>>> Mathieu Westphal >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>> >>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>> >>>>>>>>>>> Search the 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. >>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> William J. Schroeder, PhD >>>>>> Kitware, Inc. >>>>>> 28 Corporate Drive >>>>>> Clifton Park, NY 12065 >>>>>> will.schroeder at kitware.com >>>>>> http://www.kitware.com >>>>>> (518) 881-4902 >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> William J. Schroeder, PhD >>>> Kitware, Inc. >>>> 28 Corporate Drive >>>> Clifton Park, NY 12065 >>>> will.schroeder at kitware.com >>>> http://www.kitware.com >>>> (518) 881-4902 >>>> >>> >>> >> >> >> -- >> William J. Schroeder, PhD >> Kitware, Inc. >> 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 >> >> >> > -- William J. Schroeder, PhD Kitware, Inc. 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 aashish.chaudhary at kitware.com Thu Nov 19 13:14:27 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Thu, 19 Nov 2015 13:14:27 -0500 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: Dear Simon, I looked the code carefully and evaluated on mac and Linux (I don't think its a system specific issue). I also looked into your code and here what I found: * In your example code the desired update rate is set to 25 which is actually on a higher side given the data * But the max sampling distance factor is set to 2. 1) These parameters results in some interesting computation. Old mapper would not use your max sampling distance unless some computation it does cross a threshold. 2) The new mapper always uses the max sampling distance for clamping and actually if you look at the documentation it should do that. Given these two situations, the new mapper use higher sampling distance even when you set it to 2 and therefore runs faster as it tries to match your desired update rate. The new mapper tries to match as well but then it get clamped to maximum of 2 which is not enough to keep up with the desired update rate. Now when you take out this constraint, both of these mappers can go as low as 10 times the sampling distance initially chosen as the desired update rate is bit too high for the rendering. I believe that new mapper is doing the right thing vs the old mapper but I am open for suggestions. What I suggest you try these parameters: Max sampling distance factor : 4 Desired update rate: 15 or 20 Thanks On Tue, Nov 17, 2015 at 1:15 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Dear Simon, > > Thanks for your example code and data. I used exactly the same code, got > master of VTK from today, compiled OpenGL1 and OpenGL2 backends on Ubuntu > 14.01 box then for me, the OpenGL2 backend was running much faster and > higher resolution than compare to OpenGL1 backend (20 FPS vs 13 FPS). > Please look at the screenshots attached. I am referring to the number you > are displaying in the program. > > Next, I am going to run the same code on Mac and Windows and see if can > reproduce your issue. May be it is windows/driver specific issue. > > On Fri, Nov 13, 2015 at 11:02 AM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> On Fri, Nov 13, 2015 at 10:57 AM, Simon ESNEAULT < >> simon.esneault at gmail.com> wrote: >> >>> Hello Aashish, >>> >>> I've run some quick tests on my computer, and when disabling the >>> automatic adjustment, both of the volume rendering technique seems to >>> deliver the same performance, with some random Fixed sample distance. I >>> will run some more test on the other computer that we've got here, just to >>> be sure. And also on some mac. And report them to you :) >>> >> >> This is very helpful and sort of confirms my theory the the code in >> question is the reduction factor computation. The logic is changed between >> the old mapper and the new mapper. I will look again to make them >> consistent but it won't be exactly the same since the old mapper code to me >> was not making the the right choices and was broken for the new mapper. >> Actually, initially we had the exact same code and it was running into >> issues since the new mapper was faster and hence breaking some of the >> assumptions the old mapper was making. >> >>> >>> Is there something else that I can do to help on this problem ? >>> >> >> Not at the moment. You helped a lot, the code and the data is really >> helpful. I will report back early next week again and will request you to >> try again. Thanks for your patience. >> >> - Aashish >> >>> >>> >>> Simon >>> >>> >>> 2015-11-12 18:34 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> >>>> >>>> On Thu, Nov 12, 2015 at 12:31 PM, Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Nov 12, 2015 at 12:12 PM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> Hello Aashish, >>>>>> >>>>>> Sorry for the late reply, I was busy last week. >>>>>> >>>>>> Thanks for the update, and your work on this topic. >>>>>> Yes I have seen that your change have been merged concerning the >>>>>> ReductionFactor. Nevertheless, I am still getting a smaller frame rate with >>>>>> the new backend. To highlight this, please find attached a very simple >>>>>> application that loads a volume ( >>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does >>>>>> volume rendering while displaying the frame rate. This is pretty much what >>>>>> we show to the user in our application, and in this condition, on my >>>>>> machine the FPS are around 25 with the opengl1 backend >>>>>> , and 15 with >>>>>> the new backend , >>>>>> from this week VTK master >>>>>> It is very simple to test, just need change the VTK_DIR to an OpenGL1 >>>>>> or OpenGL2 build, and place the volume.mhd and raw in the execution path. >>>>>> Also you will find attached a small text file that summarizes the >>>>>> test that have been done here. >>>>>> >>>>> >>>>> No problem, thanks for the update. Please see my comments below: >>>>> >>>>>> >>>>>> I think the real reason why it appears slower with the OGL2 version >>>>>> is that we try to have control on the "MaximalImageSampleDistance". If I >>>>>> remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get >>>>>> the same frame rate with each backend. BUT, the new backend does decimate a >>>>>> lot more the volume, leading to a very blurred image during rendering, and >>>>>> that's not what we want :/ >>>>>> >>>>> >>>>> Aha, this is very useful since this parameters does affecting the >>>>> reduction factor. I will try your code; one quick question when the new >>>>> backend decimates a lot (by removing the SetMaximumImageSampleDistance), >>>>> does it get any faster than the old version? I am going to try it on my Mac >>>>> and Linux laptop and report back (mostly tomorrow since I am away today). >>>>> >>>>>> >>>>>> >>>> Never mind, I see that you have that in your result file. It seems it >>>> does get faster but more blurry. Would it be possible for you to do one >>>> more test? Can you set a fix sample distance (pick any) for new and the old >>>> mapper and set AutoAdjustSampleDistance to OFF and capture some performance >>>> numbers? In that way we know exactly if something more fundamental is >>>> causing the slowness. The whole reduction factor math is based on >>>> approximate stuff so that will vary between two mappers. >>>> >>>> - Aashish >>>> >>>> >>>>> Again, thanks for paying attention to this problem, I hope this little >>>>>> application and test case can help you to adjust the parameters... >>>>>> >>>>> >>>>> Thanks for your help. I am glad you are testing my latest changes. >>>>> >>>>> - Best, Aashish >>>>> >>>>>> >>>>>> >>>>>> Simon >>>>>> >>>>>> PS : I did not get a chance to check the difference on Paraview, but >>>>>> I believe the result will be the same as the attached example is really >>>>>> simple. >>>>>> >>>>>> 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> the branch has been merged into VTK master. I am not sure when >>>>>>> Paraview is going to update the VTK, but you can do it manually if needed. >>>>>>> We are also going to run our bench marking again to be sure since recently >>>>>>> lot many changes went into the VTK / volume rendering. Please feel free to >>>>>>> ping me again if it does not solve your issue. >>>>>>> >>>>>>> Looking forward to your feedback. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>> >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> I found the reason behind the appeared performance you were >>>>>>>> getting. We have this code in volume rendering that when you interact >>>>>>>> changes the sampling distance and in the newer code we were too >>>>>>>> conservative compare to the last version. That's why you were getting >>>>>>>> better quality when you move your mouse but lower frame rates. I pushed a >>>>>>>> branch in VTK to address the issue. Would it be possible for you to build >>>>>>>> Paraview with VTK master? It may take 3-4 days or longer for Paraview's >>>>>>>> VTK to get updated. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Aashish >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>> >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> I am just finishing up a ParaView5 related parallel volume >>>>>>>>> rendering bug (pushing a branch today to VTK). This is next on my list. >>>>>>>>> >>>>>>>>> - Aashish >>>>>>>>> >>>>>>>>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello Aashish >>>>>>>>>> >>>>>>>>>> Did you get a chance to try to load the dataset on Windows ? >>>>>>>>>> Can I do anything to help you investigate ? Should I feel a bug, >>>>>>>>>> that may act as a reminder ? >>>>>>>>>> Have a nice day >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>> >>>>>>>>>>> Thanks Simon. This is really strange since we are not seeing it >>>>>>>>>>> on Mac and Linux (but both has dedicated cards). >>>>>>>>>>> >>>>>>>>>>> I will look into it soon. >>>>>>>>>>> >>>>>>>>>>> - aashish >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ok, thank you very much fort digging into this. >>>>>>>>>>>> I've done some test and I believe I can see a similar slowdown >>>>>>>>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>>>>>>>> graphics. >>>>>>>>>>>> Good luck in the investigation, I you need more details, do not >>>>>>>>>>>> hesitate to ask >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, thanks. I will get back to you on this since on Linux I >>>>>>>>>>>>> don't any issue so it has to be Windows specific thing. >>>>>>>>>>>>> >>>>>>>>>>>>> - Aashish >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I tried with that one from yesterday and today's version >>>>>>>>>>>>>> (4.4.0-209-gc399648) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Simon >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And when did you download this version? >>>>>>>>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Aashish >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>>>>>>>> version seems even bigger. >>>>>>>>>>>>>>>> I got the version from the nightly build download section >>>>>>>>>>>>>>>> of paraview website (it is still available). And I've just tried with that >>>>>>>>>>>>>>>> one labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>>>>>>>> results. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> About the FPS, it is difficult to give an exact number, >>>>>>>>>>>>>>>> because it depends of the condition (zoomed or not etc...) but yes, this is >>>>>>>>>>>>>>>> the idea. >>>>>>>>>>>>>>>> In our software, I've exposed the frame rate using this >>>>>>>>>>>>>>>> example : >>>>>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>>>>>>>> And the frame rate is around 15/20 for the first backend, >>>>>>>>>>>>>>>> and around 6/8 for the new backend, on the same dataset (the one provided >>>>>>>>>>>>>>>> for example), with the same mapper parameters >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1) Did you try without the shading and see how the >>>>>>>>>>>>>>>>> performance compares? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this >>>>>>>>>>>>>>>>> one from (ParaView download page or did you built yourself?) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, so on your system the old mapper is running 30FPS >>>>>>>>>>>>>>>>> and the new one at 15-20 FPS as per your summary. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>>>>>>>> The two tested version are : >>>>>>>>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 >>>>>>>>>>>>>>>>>> backend. >>>>>>>>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and >>>>>>>>>>>>>>>>>> Nvidia Quadro K420 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>>>>>>>> - Launch both version on the same computer at the same >>>>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>>>>>>>> - Adjust the transfer function data range to [100-750] >>>>>>>>>>>>>>>>>> (the default "Cool to Warm" is fine) >>>>>>>>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> And start interacting ... >>>>>>>>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate >>>>>>>>>>>>>>>>>> in Paraview, but the new version seems really twice slower in these >>>>>>>>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>>>>>>>> interactivity is better. >>>>>>>>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play >>>>>>>>>>>>>>>>>> with this with the old backend to fine tune the interactivity, although >>>>>>>>>>>>>>>>>> what's really inside was never clear to me >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I hope that there is enough information for you to >>>>>>>>>>>>>>>>>> reproduce this, do not hesitate to ask for some more information. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Checking again. Wondering if you can provide some more >>>>>>>>>>>>>>>>>>> detail on the binary you are using and whether or not without shading the >>>>>>>>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I used your dataset on paraview master as of today on >>>>>>>>>>>>>>>>>>>> my Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting >>>>>>>>>>>>>>>>>>>> about 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked >>>>>>>>>>>>>>>>>>>> the shading performance fix was in 4.4 but not in RC's. I don't have access >>>>>>>>>>>>>>>>>>>> to Windows box right away but I will try there too. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> NOTE: You might get multiple emails because of the >>>>>>>>>>>>>>>>>>>> attachment size issue. Sorry about that. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short >>>>>>>>>>>>>>>>>>>>>> element (you can find the dataset here : >>>>>>>>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). >>>>>>>>>>>>>>>>>>>>>> So I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when >>>>>>>>>>>>>>>>>>>>>> compared to the old one, it seems less "low resolution" during interaction >>>>>>>>>>>>>>>>>>>>>> than the old one >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I >>>>>>>>>>>>>>>>>>>>>> believe the GPURenderDemo used with this dataset is enough to highlight the >>>>>>>>>>>>>>>>>>>>>> slow down. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with >>>>>>>>>>>>>>>>>>>>>>> shading that was causing the slow performance a while back. I don't >>>>>>>>>>>>>>>>>>>>>>> remember if that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on >>>>>>>>>>>>>>>>>>>>>>>> the data type you might be using >>>>>>>>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The >>>>>>>>>>>>>>>>>>>>>>>> performance we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the >>>>>>>>>>>>>>>>>>>>>>>> new mapper is bringing low resolution when you interact with the volume >>>>>>>>>>>>>>>>>>>>>>>> (and whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new >>>>>>>>>>>>>>>>>>>>>>>>> OpenGL2 backend for our application, and although the switch was easy >>>>>>>>>>>>>>>>>>>>>>>>> (thanks for not breaking the API ;) ), we can see a significant slowdown on >>>>>>>>>>>>>>>>>>>>>>>>> the GPU volume rendering part, especially during interaction. Typically we >>>>>>>>>>>>>>>>>>>>>>>>> dropped from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia >>>>>>>>>>>>>>>>>>>>>>>>> Quadro K420), with the same code around. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you >>>>>>>>>>>>>>>>>>>>>>>>> compare the latest 4.4 OpenGL2 build with the classic 4.4 build while >>>>>>>>>>>>>>>>>>>>>>>>> volume rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering >>>>>>>>>>>>>>>>>>>>>>>>> implementation should be faster than the old one, is there some more >>>>>>>>>>>>>>>>>>>>>>>>> detailed explanation somewhere ? Are there some important parameters that >>>>>>>>>>>>>>>>>>>>>>>>> can make the difference ? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster >>>>>>>>>>>>>>>>>>>>>>>>> with the new backend ! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>> Inc. * >>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> Simon Esneault >>>>>>>>>>>> Rennes, France >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>> * >>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Nov 19 14:29:47 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Nov 2015 14:29:47 -0500 Subject: [vtk-developers] [ANN] Buildbot updates Message-ID: <20151119192947.GA11791@megas.khq.kitware.com> Hi, I wrote a blog post two weeks ago, but missed announcing it to the lists: http://kitware.com/blog/home/post/984 It covers how to use the --regex-include and --regex-exclude arguments to get more responsive results from buildbot. Since the post, there have been other buildbot changes. This week, I also added shortcuts for those two arguments: -i and -e, respectively. A more disruptive change that has been discussed a bit would be to make the --oneshot argument the default and instead switching around to using --continuous instead to have "rebuild on push" behavior. So by default, every push would need another "Do: test" to trigger a build. This would help reduce the amount of clutter on the buildbots. If no one objects, we'd like to turn off "@buildbot test" by the middle of next week; I haven't seen any new uses of it, so disabling it will only stop builders running when a branch is updated that haven't had a "Do: test" (buildbot marks such instances when it comes across them). The other buildbot comments ("builds have been queued" and the end-of-build report comment) are also going away with another improvement I've been working on. The idea is to use the CI integration of GitLab for the status of builds (kwrobot has also started using it for marking commits in a branch as good or bad as well as the last commit in the branch for the branch itself). The UI looks something like: https://gitlab.com/ben.boeckel/gitlab-ce/commit/80cda39c1bb966ff7aec05cb3b279e95c6ce2515/builds to track the current status of the MR's testing and put a badge at the top of the MR for its build status: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1796 (For those curious, that MR is about allowing buildbot to specify more information to GitLab to use other features such as cancelling builds and restarting them, marking builds as known-to-fail, and other useful information like a direct link to CDash.) To help the process of getting green dashboards, I've also removed most of our experimental builders (there are internal issues to add them back once we work on getting them to pass). Those that are still there are close to being green: https://buildbot.kitware.com/builders/vtk-megas-linux-shared-release%2Bqt%2Bqt5 (an OpenGL2 with Mesa tester; 4 failing tests) and: https://buildbot.kitware.com/builders/paraview-bigmac-osx-shared-debug%2Bclang%2Bgui%2Bopengl2%2Bpython (ParaView + OpenGL2 tester). Thanks, --Ben From david.lonie at kitware.com Thu Nov 19 15:37:47 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 19 Nov 2015 15:37:47 -0500 Subject: [vtk-developers] [Paraview-developers] [ANN] Buildbot updates In-Reply-To: <20151119192947.GA11791@megas.khq.kitware.com> References: <20151119192947.GA11791@megas.khq.kitware.com> Message-ID: On Thu, Nov 19, 2015 at 2:29 PM, Ben Boeckel wrote: > The other buildbot comments ("builds have been queued" and the > end-of-build report comment) are also going away with another > improvement I've been working on. Let's leave the "builds have been queued" comment -- it's handy to have the link to the filtered CDash results page. (or stick the same link somewhere else in the new system) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Nov 19 15:42:48 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Nov 2015 15:42:48 -0500 Subject: [vtk-developers] [Paraview-developers] [ANN] Buildbot updates In-Reply-To: References: <20151119192947.GA11791@megas.khq.kitware.com> Message-ID: <20151119204248.GA13406@megas.khq.kitware.com> On Thu, Nov 19, 2015 at 15:37:47 -0500, David Lonie wrote: > Let's leave the "builds have been queued" comment -- it's handy to have the > link to the filtered CDash results page. > > (or stick the same link somewhere else in the new system) Once the GitLab branch I have there lands, we can put it in the "extra data" field. But, I suppose we could just add a dummy build result line with a link to CDash as the "Build #" link, but maybe that's too opaque. For now, I'll just put the "queued" comment back. Either way, the end-of-build report comments tend to be the noisy ones, so the "queued" comments are less urgent. --Ben From simon.esneault at gmail.com Fri Nov 20 08:26:33 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 20 Nov 2015 14:26:33 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Hello, I've created a merge request for this bug : https://gitlab.kitware.com/vtk/vtk/merge_requests/932 The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend state, but never restores the state as it was before, resulting in some incorrect blend later. I don't know if it's the correct fix, but it certainly look like the reason for this bug, and it solve the bug here. Can someone review this merge ? Regards Simon 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : > Morning ! > > http://www.vtk.org/Bug/view.php?id=15838 > > Let me know if there is anything I can do to solve this. > > Simon > > 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < > aashish.chaudhary at kitware.com>: > >> >> >> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT > > wrote: >> >>> Dear Aashish, >>> >>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>> class for loading the texture. >>> Shall I fill a bug ? >>> >> >> Yes, please. >> >> - Aashish >> >> >>> Thanks >>> Simon >>> >>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> I see so its not just related to volume rendering and it seems to be a >>>> vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >>>> take a look at it. Nonetheless, we will follow up on this bug. >>>> >>>> - Aashish >>>> >>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Hello Aashish, >>>>> >>>>> Thanks ! >>>>> After doing some test, I realized the patch I've just sent is not the >>>>> correct fix at all, because the text is not rendered properly when we don't >>>>> use a vtkFixedPointVolumeRayCastMapper anymore. >>>>> >>>>> I believe the problem is probably larger than this and probably has >>>>> nothing to do with the freetype text generation, but more with the >>>>> vtkTexturedActor2D rendering part used together with a >>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>> texture has some transparent pixel in it ... >>>>> >>>>> Attached there is a new example that demonstrate that a vtkTextActor >>>>> AND a vtkTexturedButtonRepresentation2D are not correctly drawn in that >>>>> case : >>>>> - OpenGL1 backend >>>>> : Transparent >>>>> pixel in Texture are correctly drawn >>>>> - OpenGL2 backend >>>>> : >>>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>> >>>>> The example is more simple than the previous one and does not need any >>>>> additional data. >>>>> >>>>> Hope that helps ! >>>>> -Simon >>>>> >>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> Simon, >>>>>> >>>>>> Thanks for the report. I will follow up with other developers on this >>>>>> bug. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> >>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Trying to solve this problem, I found out that if one call >>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>> at the anchor point, and with a transparent gray background. >>>>>>> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>> - DebugTexturesOff : >>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>> >>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this is >>>>>>> a blending problem. When we activate Texture Debugging, a gray background >>>>>>> is first drawn, and after that in the method RenderCharacter( ... ) line >>>>>>> 1887; we either blend the rendered text with the background or not. >>>>>>> >>>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>>> integrate this properly :) >>>>>>> >>>>>>> Thanks, >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT >>>>>>> : >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>> new rendering backend. >>>>>>>> >>>>>>>> Here are some snapshots : >>>>>>>> - OpenGL1 >>>>>>>> >>>>>>>> - OpenGL2 >>>>>>>> >>>>>>>> Attached some code that reproduces the problem, to be used with >>>>>>>> this >>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>> >>>>>>>> The text is rendered properly when used with the old backend or >>>>>>>> when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>> >>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Simon >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Visit other Kitware open-source projects at >>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>> >>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Nov 20 08:32:35 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 20 Nov 2015 08:32:35 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Hi Simon, Thanks! I am okay with merging this change but in general restoring to previous state is tricky as for that you need to know the previous state. I think restoring to a default state (which you did) makes more sense. Although in VTK we don't have clear guideline on this. I am reviewing your changes.. On Fri, Nov 20, 2015 at 8:26 AM, Simon ESNEAULT wrote: > Hello, > > I've created a merge request for this bug : > https://gitlab.kitware.com/vtk/vtk/merge_requests/932 > > The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend > state, but never restores the state as it was before, resulting in some > incorrect blend later. > I don't know if it's the correct fix, but it certainly look like the > reason for this bug, and it solve the bug here. > Can someone review this merge ? > > Regards > Simon > > > 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : > >> Morning ! >> >> http://www.vtk.org/Bug/view.php?id=15838 >> >> Let me know if there is anything I can do to solve this. >> >> Simon >> >> 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> >>> >>> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Dear Aashish, >>>> >>>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>>> class for loading the texture. >>>> Shall I fill a bug ? >>>> >>> >>> Yes, please. >>> >>> - Aashish >>> >>> >>>> Thanks >>>> Simon >>>> >>>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> I see so its not just related to volume rendering and it seems to be a >>>>> vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >>>>> take a look at it. Nonetheless, we will follow up on this bug. >>>>> >>>>> - Aashish >>>>> >>>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> Hello Aashish, >>>>>> >>>>>> Thanks ! >>>>>> After doing some test, I realized the patch I've just sent is not the >>>>>> correct fix at all, because the text is not rendered properly when we don't >>>>>> use a vtkFixedPointVolumeRayCastMapper anymore. >>>>>> >>>>>> I believe the problem is probably larger than this and probably has >>>>>> nothing to do with the freetype text generation, but more with the >>>>>> vtkTexturedActor2D rendering part used together with a >>>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>>> texture has some transparent pixel in it ... >>>>>> >>>>>> Attached there is a new example that demonstrate that a vtkTextActor >>>>>> AND a vtkTexturedButtonRepresentation2D are not correctly drawn in that >>>>>> case : >>>>>> - OpenGL1 backend >>>>>> : Transparent >>>>>> pixel in Texture are correctly drawn >>>>>> - OpenGL2 backend >>>>>> : >>>>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>>> >>>>>> The example is more simple than the previous one and does not need >>>>>> any additional data. >>>>>> >>>>>> Hope that helps ! >>>>>> -Simon >>>>>> >>>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> Simon, >>>>>>> >>>>>>> Thanks for the report. I will follow up with other developers on >>>>>>> this bug. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Trying to solve this problem, I found out that if one call >>>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>>> at the anchor point, and with a transparent gray background. >>>>>>>> - DebugTexturesOn : http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>>> - DebugTexturesOff : >>>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>>> >>>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this >>>>>>>> is a blending problem. When we activate Texture Debugging, a gray >>>>>>>> background is first drawn, and after that in the method RenderCharacter( >>>>>>>> ... ) line 1887; we either blend the rendered text with the background or >>>>>>>> not. >>>>>>>> >>>>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>>>> integrate this properly :) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT >>>>>>> >: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>>> new rendering backend. >>>>>>>>> >>>>>>>>> Here are some snapshots : >>>>>>>>> - OpenGL1 >>>>>>>>> >>>>>>>>> - OpenGL2 >>>>>>>>> >>>>>>>>> Attached some code that reproduces the problem, to be used with >>>>>>>>> this >>>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>>> >>>>>>>>> The text is rendered properly when used with the old backend or >>>>>>>>> when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>>> >>>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Powered by www.kitware.com >>>>>>>> >>>>>>>> Visit other Kitware open-source projects at >>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>> >>>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>>> >>>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers >>>>>>>> >>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Fri Nov 20 08:35:15 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 20 Nov 2015 08:35:15 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Simon, Just reviewed it. The changes looks good to me, I see that you are actually querying the states and hence previous state. I am going to run the tests and if all looks good, I am going to merge it. - Aashish On Fri, Nov 20, 2015 at 8:32 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Hi Simon, > > Thanks! I am okay with merging this change but in general restoring to > previous state is tricky as for that you need to know the previous state. I > think restoring to a default state (which you did) makes more sense. > Although in VTK we don't have clear guideline on this. I am reviewing your > changes.. > > > On Fri, Nov 20, 2015 at 8:26 AM, Simon ESNEAULT > wrote: > >> Hello, >> >> I've created a merge request for this bug : >> https://gitlab.kitware.com/vtk/vtk/merge_requests/932 >> >> The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend >> state, but never restores the state as it was before, resulting in some >> incorrect blend later. >> I don't know if it's the correct fix, but it certainly look like the >> reason for this bug, and it solve the bug here. >> Can someone review this merge ? >> >> Regards >> Simon >> >> >> 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : >> >>> Morning ! >>> >>> http://www.vtk.org/Bug/view.php?id=15838 >>> >>> Let me know if there is anything I can do to solve this. >>> >>> Simon >>> >>> 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> >>>> >>>> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Dear Aashish, >>>>> >>>>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>>>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>>>> class for loading the texture. >>>>> Shall I fill a bug ? >>>>> >>>> >>>> Yes, please. >>>> >>>> - Aashish >>>> >>>> >>>>> Thanks >>>>> Simon >>>>> >>>>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> I see so its not just related to volume rendering and it seems to be >>>>>> a vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >>>>>> take a look at it. Nonetheless, we will follow up on this bug. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> Hello Aashish, >>>>>>> >>>>>>> Thanks ! >>>>>>> After doing some test, I realized the patch I've just sent is not >>>>>>> the correct fix at all, because the text is not rendered properly when we >>>>>>> don't use a vtkFixedPointVolumeRayCastMapper anymore. >>>>>>> >>>>>>> I believe the problem is probably larger than this and probably has >>>>>>> nothing to do with the freetype text generation, but more with the >>>>>>> vtkTexturedActor2D rendering part used together with a >>>>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>>>> texture has some transparent pixel in it ... >>>>>>> >>>>>>> Attached there is a new example that demonstrate that a vtkTextActor >>>>>>> AND a vtkTexturedButtonRepresentation2D are not correctly drawn in that >>>>>>> case : >>>>>>> - OpenGL1 backend >>>>>>> : Transparent >>>>>>> pixel in Texture are correctly drawn >>>>>>> - OpenGL2 backend >>>>>>> : >>>>>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>>>> >>>>>>> The example is more simple than the previous one and does not need >>>>>>> any additional data. >>>>>>> >>>>>>> Hope that helps ! >>>>>>> -Simon >>>>>>> >>>>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com>: >>>>>>> >>>>>>>> Simon, >>>>>>>> >>>>>>>> Thanks for the report. I will follow up with other developers on >>>>>>>> this bug. >>>>>>>> >>>>>>>> - Aashish >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Trying to solve this problem, I found out that if one call >>>>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>>>> at the anchor point, and with a transparent gray background. >>>>>>>>> - DebugTexturesOn : >>>>>>>>> http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>>>> - DebugTexturesOff : >>>>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>>>> >>>>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this >>>>>>>>> is a blending problem. When we activate Texture Debugging, a gray >>>>>>>>> background is first drawn, and after that in the method RenderCharacter( >>>>>>>>> ... ) line 1887; we either blend the rendered text with the background or >>>>>>>>> not. >>>>>>>>> >>>>>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>>>>> integrate this properly :) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com>: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>>>> new rendering backend. >>>>>>>>>> >>>>>>>>>> Here are some snapshots : >>>>>>>>>> - OpenGL1 >>>>>>>>>> >>>>>>>>>> - OpenGL2 >>>>>>>>>> >>>>>>>>>> Attached some code that reproduces the problem, to be used with >>>>>>>>>> this >>>>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>>>> >>>>>>>>>> The text is rendered properly when used with the old backend or >>>>>>>>>> when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>>>> >>>>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>>>> >>>>>>>>> Search the list archives at: >>>>>>>>> http://markmail.org/search/?q=vtkusers >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Nov 20 09:37:34 2015 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 20 Nov 2015 09:37:34 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: That is the standard blend save/restore code so I think that should do the trick. Thanks for digging into it. On Fri, Nov 20, 2015 at 8:32 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Hi Simon, > > Thanks! I am okay with merging this change but in general restoring to > previous state is tricky as for that you need to know the previous state. I > think restoring to a default state (which you did) makes more sense. > Although in VTK we don't have clear guideline on this. I am reviewing your > changes.. > > > On Fri, Nov 20, 2015 at 8:26 AM, Simon ESNEAULT > wrote: > >> Hello, >> >> I've created a merge request for this bug : >> https://gitlab.kitware.com/vtk/vtk/merge_requests/932 >> >> The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend >> state, but never restores the state as it was before, resulting in some >> incorrect blend later. >> I don't know if it's the correct fix, but it certainly look like the >> reason for this bug, and it solve the bug here. >> Can someone review this merge ? >> >> Regards >> Simon >> >> >> 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : >> >>> Morning ! >>> >>> http://www.vtk.org/Bug/view.php?id=15838 >>> >>> Let me know if there is anything I can do to solve this. >>> >>> Simon >>> >>> 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < >>> aashish.chaudhary at kitware.com>: >>> >>>> >>>> >>>> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Dear Aashish, >>>>> >>>>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>>>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>>>> class for loading the texture. >>>>> Shall I fill a bug ? >>>>> >>>> >>>> Yes, please. >>>> >>>> - Aashish >>>> >>>> >>>>> Thanks >>>>> Simon >>>>> >>>>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> I see so its not just related to volume rendering and it seems to be >>>>>> a vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >>>>>> take a look at it. Nonetheless, we will follow up on this bug. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> Hello Aashish, >>>>>>> >>>>>>> Thanks ! >>>>>>> After doing some test, I realized the patch I've just sent is not >>>>>>> the correct fix at all, because the text is not rendered properly when we >>>>>>> don't use a vtkFixedPointVolumeRayCastMapper anymore. >>>>>>> >>>>>>> I believe the problem is probably larger than this and probably has >>>>>>> nothing to do with the freetype text generation, but more with the >>>>>>> vtkTexturedActor2D rendering part used together with a >>>>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>>>> texture has some transparent pixel in it ... >>>>>>> >>>>>>> Attached there is a new example that demonstrate that a vtkTextActor >>>>>>> AND a vtkTexturedButtonRepresentation2D are not correctly drawn in that >>>>>>> case : >>>>>>> - OpenGL1 backend >>>>>>> : Transparent >>>>>>> pixel in Texture are correctly drawn >>>>>>> - OpenGL2 backend >>>>>>> : >>>>>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>>>> >>>>>>> The example is more simple than the previous one and does not need >>>>>>> any additional data. >>>>>>> >>>>>>> Hope that helps ! >>>>>>> -Simon >>>>>>> >>>>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com>: >>>>>>> >>>>>>>> Simon, >>>>>>>> >>>>>>>> Thanks for the report. I will follow up with other developers on >>>>>>>> this bug. >>>>>>>> >>>>>>>> - Aashish >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Trying to solve this problem, I found out that if one call >>>>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>>>> at the anchor point, and with a transparent gray background. >>>>>>>>> - DebugTexturesOn : >>>>>>>>> http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>>>> - DebugTexturesOff : >>>>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>>>> >>>>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this >>>>>>>>> is a blending problem. When we activate Texture Debugging, a gray >>>>>>>>> background is first drawn, and after that in the method RenderCharacter( >>>>>>>>> ... ) line 1887; we either blend the rendered text with the background or >>>>>>>>> not. >>>>>>>>> >>>>>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>>>>> integrate this properly :) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com>: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>>>> new rendering backend. >>>>>>>>>> >>>>>>>>>> Here are some snapshots : >>>>>>>>>> - OpenGL1 >>>>>>>>>> >>>>>>>>>> - OpenGL2 >>>>>>>>>> >>>>>>>>>> Attached some code that reproduces the problem, to be used with >>>>>>>>>> this >>>>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>>>> >>>>>>>>>> The text is rendered properly when used with the old backend or >>>>>>>>>> when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>>>> >>>>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Powered by www.kitware.com >>>>>>>>> >>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>> >>>>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>>>> >>>>>>>>> Search the list archives at: >>>>>>>>> http://markmail.org/search/?q=vtkusers >>>>>>>>> >>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 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 Fri Nov 20 13:15:05 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 20 Nov 2015 13:15:05 -0500 Subject: [vtk-developers] [ANN] Buildbot updates In-Reply-To: <20151119192947.GA11791@megas.khq.kitware.com> References: <20151119192947.GA11791@megas.khq.kitware.com> Message-ID: <20151120181505.GA13710@megas.khq.kitware.com> On Thu, Nov 19, 2015 at 14:29:47 -0500, Ben Boeckel wrote: > The idea is to use the CI integration > of GitLab for the status of builds So it seems one of the bits involved with this tickles a Python oddity where modules become None on a reload (details are the same as this issue[1]) and is causing exceptions within buildbot and for the failure status to pop up for the build even though the steps all completed successfully. I've fixed it up to be more robust. Trust CDash for builds started today (or look at the step summary on buildbot; the grid will be red due to builds started while the bug was present). Sorry for the inconvenience, --Ben [1]https://stackoverflow.com/questions/17084260/imported-modules-become-none-when-running-a-function From aashish.chaudhary at kitware.com Fri Nov 20 20:39:10 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 20 Nov 2015 20:39:10 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Simon, You branch has been merged: https://gitlab.kitware.com/vtk/vtk/merge_requests/932. Thank for the patch. - Aashish On Fri, Nov 20, 2015 at 9:37 AM, Ken Martin wrote: > That is the standard blend save/restore code so I think that should do the > trick. Thanks for digging into it. > > On Fri, Nov 20, 2015 at 8:32 AM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> Hi Simon, >> >> Thanks! I am okay with merging this change but in general restoring to >> previous state is tricky as for that you need to know the previous state. I >> think restoring to a default state (which you did) makes more sense. >> Although in VTK we don't have clear guideline on this. I am reviewing your >> changes.. >> >> >> On Fri, Nov 20, 2015 at 8:26 AM, Simon ESNEAULT > > wrote: >> >>> Hello, >>> >>> I've created a merge request for this bug : >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/932 >>> >>> The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend >>> state, but never restores the state as it was before, resulting in some >>> incorrect blend later. >>> I don't know if it's the correct fix, but it certainly look like the >>> reason for this bug, and it solve the bug here. >>> Can someone review this merge ? >>> >>> Regards >>> Simon >>> >>> >>> 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : >>> >>>> Morning ! >>>> >>>> http://www.vtk.org/Bug/view.php?id=15838 >>>> >>>> Let me know if there is anything I can do to solve this. >>>> >>>> Simon >>>> >>>> 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < >>>> aashish.chaudhary at kitware.com>: >>>> >>>>> >>>>> >>>>> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT < >>>>> simon.esneault at gmail.com> wrote: >>>>> >>>>>> Dear Aashish, >>>>>> >>>>>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>>>>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>>>>> class for loading the texture. >>>>>> Shall I fill a bug ? >>>>>> >>>>> >>>>> Yes, please. >>>>> >>>>> - Aashish >>>>> >>>>> >>>>>> Thanks >>>>>> Simon >>>>>> >>>>>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> I see so its not just related to volume rendering and it seems to be >>>>>>> a vtkTextActor2D problem? In that can probably Ken / David Lonie wants to >>>>>>> take a look at it. Nonetheless, we will follow up on this bug. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> Hello Aashish, >>>>>>>> >>>>>>>> Thanks ! >>>>>>>> After doing some test, I realized the patch I've just sent is not >>>>>>>> the correct fix at all, because the text is not rendered properly when we >>>>>>>> don't use a vtkFixedPointVolumeRayCastMapper anymore. >>>>>>>> >>>>>>>> I believe the problem is probably larger than this and probably has >>>>>>>> nothing to do with the freetype text generation, but more with the >>>>>>>> vtkTexturedActor2D rendering part used together with a >>>>>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>>>>> texture has some transparent pixel in it ... >>>>>>>> >>>>>>>> Attached there is a new example that demonstrate that a >>>>>>>> vtkTextActor AND a vtkTexturedButtonRepresentation2D are not correctly >>>>>>>> drawn in that case : >>>>>>>> - OpenGL1 backend >>>>>>>> : Transparent >>>>>>>> pixel in Texture are correctly drawn >>>>>>>> - OpenGL2 backend >>>>>>>> : >>>>>>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>>>>> >>>>>>>> The example is more simple than the previous one and does not need >>>>>>>> any additional data. >>>>>>>> >>>>>>>> Hope that helps ! >>>>>>>> -Simon >>>>>>>> >>>>>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>> >>>>>>>>> Simon, >>>>>>>>> >>>>>>>>> Thanks for the report. I will follow up with other developers on >>>>>>>>> this bug. >>>>>>>>> >>>>>>>>> - Aashish >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Trying to solve this problem, I found out that if one call >>>>>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>>>>> at the anchor point, and with a transparent gray background. >>>>>>>>>> - DebugTexturesOn : >>>>>>>>>> http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>>>>> - DebugTexturesOff : >>>>>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>>>>> >>>>>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect this >>>>>>>>>> is a blending problem. When we activate Texture Debugging, a gray >>>>>>>>>> background is first drawn, and after that in the method RenderCharacter( >>>>>>>>>> ... ) line 1887; we either blend the rendered text with the background or >>>>>>>>>> not. >>>>>>>>>> >>>>>>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>>>>>> integrate this properly :) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT < >>>>>>>>>> simon.esneault at gmail.com>: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>>>>> new rendering backend. >>>>>>>>>>> >>>>>>>>>>> Here are some snapshots : >>>>>>>>>>> - OpenGL1 >>>>>>>>>>> >>>>>>>>>>> - OpenGL2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Attached some code that reproduces the problem, to be used with >>>>>>>>>>> this >>>>>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>>>>> >>>>>>>>>>> The text is rendered properly when used with the old backend or >>>>>>>>>>> when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>>>>> >>>>>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> Simon Esneault >>>>>>>>>>> Rennes, France >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Powered by www.kitware.com >>>>>>>>>> >>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>> >>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>>>>> >>>>>>>>>> Search the list archives at: >>>>>>>>>> http://markmail.org/search/?q=vtkusers >>>>>>>>>> >>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>> * >>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>> * >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Simon Esneault >>> Rennes, France >>> ------------------------------------------------------------------ >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > 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. > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Mon Nov 23 04:32:45 2015 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Mon, 23 Nov 2015 10:32:45 +0100 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: Hello, Thanks for merging this. As a side note, I believe the same is true for the old backend, because the function vtkOpenGLRayCastImageDisplayHelper::RenderTextureInternal( ... ) does also modify the blend state without restoring it. But somehow, the 2D texture are correctly drawn with the old backend ... Mantis bugs : http://www.vtk.org/Bug/view.php?id=15838 and http://www.vtk.org/Bug/view.php?id=15812 can now be closed :) Thanks Simon 2015-11-21 2:39 GMT+01:00 Aashish Chaudhary : > Simon, > > You branch has been merged: > https://gitlab.kitware.com/vtk/vtk/merge_requests/932. Thank for the > patch. > > - Aashish > > On Fri, Nov 20, 2015 at 9:37 AM, Ken Martin > wrote: > >> That is the standard blend save/restore code so I think that should do >> the trick. Thanks for digging into it. >> >> On Fri, Nov 20, 2015 at 8:32 AM, Aashish Chaudhary < >> aashish.chaudhary at kitware.com> wrote: >> >>> Hi Simon, >>> >>> Thanks! I am okay with merging this change but in general restoring to >>> previous state is tricky as for that you need to know the previous state. I >>> think restoring to a default state (which you did) makes more sense. >>> Although in VTK we don't have clear guideline on this. I am reviewing your >>> changes.. >>> >>> >>> On Fri, Nov 20, 2015 at 8:26 AM, Simon ESNEAULT < >>> simon.esneault at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I've created a merge request for this bug : >>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/932 >>>> >>>> The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend >>>> state, but never restores the state as it was before, resulting in some >>>> incorrect blend later. >>>> I don't know if it's the correct fix, but it certainly look like the >>>> reason for this bug, and it solve the bug here. >>>> Can someone review this merge ? >>>> >>>> Regards >>>> Simon >>>> >>>> >>>> 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : >>>> >>>>> Morning ! >>>>> >>>>> http://www.vtk.org/Bug/view.php?id=15838 >>>>> >>>>> Let me know if there is anything I can do to solve this. >>>>> >>>>> Simon >>>>> >>>>> 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT < >>>>>> simon.esneault at gmail.com> wrote: >>>>>> >>>>>>> Dear Aashish, >>>>>>> >>>>>>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>>>>>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>>>>>> class for loading the texture. >>>>>>> Shall I fill a bug ? >>>>>>> >>>>>> >>>>>> Yes, please. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Simon >>>>>>> >>>>>>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com>: >>>>>>> >>>>>>>> I see so its not just related to volume rendering and it seems to >>>>>>>> be a vtkTextActor2D problem? In that can probably Ken / David Lonie wants >>>>>>>> to take a look at it. Nonetheless, we will follow up on this bug. >>>>>>>> >>>>>>>> - Aashish >>>>>>>> >>>>>>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello Aashish, >>>>>>>>> >>>>>>>>> Thanks ! >>>>>>>>> After doing some test, I realized the patch I've just sent is not >>>>>>>>> the correct fix at all, because the text is not rendered properly when we >>>>>>>>> don't use a vtkFixedPointVolumeRayCastMapper anymore. >>>>>>>>> >>>>>>>>> I believe the problem is probably larger than this and probably >>>>>>>>> has nothing to do with the freetype text generation, but more with the >>>>>>>>> vtkTexturedActor2D rendering part used together with a >>>>>>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>>>>>> texture has some transparent pixel in it ... >>>>>>>>> >>>>>>>>> Attached there is a new example that demonstrate that a >>>>>>>>> vtkTextActor AND a vtkTexturedButtonRepresentation2D are not correctly >>>>>>>>> drawn in that case : >>>>>>>>> - OpenGL1 backend >>>>>>>>> : Transparent >>>>>>>>> pixel in Texture are correctly drawn >>>>>>>>> - OpenGL2 backend >>>>>>>>> : >>>>>>>>> Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>>>>>> >>>>>>>>> The example is more simple than the previous one and does not need >>>>>>>>> any additional data. >>>>>>>>> >>>>>>>>> Hope that helps ! >>>>>>>>> -Simon >>>>>>>>> >>>>>>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>> >>>>>>>>>> Simon, >>>>>>>>>> >>>>>>>>>> Thanks for the report. I will follow up with other developers on >>>>>>>>>> this bug. >>>>>>>>>> >>>>>>>>>> - Aashish >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Trying to solve this problem, I found out that if one call >>>>>>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>>>>>> at the anchor point, and with a transparent gray background. >>>>>>>>>>> - DebugTexturesOn : >>>>>>>>>>> http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>>>>>> - DebugTexturesOff : >>>>>>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>>>>>> >>>>>>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect >>>>>>>>>>> this is a blending problem. When we activate Texture Debugging, a gray >>>>>>>>>>> background is first drawn, and after that in the method RenderCharacter( >>>>>>>>>>> ... ) line 1887; we either blend the rendered text with the background or >>>>>>>>>>> not. >>>>>>>>>>> >>>>>>>>>>> Attached is a diff file that solves the problem for me. I do not >>>>>>>>>>> really understand why, so maybe a developer with more VTK's knowledge can >>>>>>>>>>> integrate this properly :) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT < >>>>>>>>>>> simon.esneault at gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>>>>>> new rendering backend. >>>>>>>>>>>> >>>>>>>>>>>> Here are some snapshots : >>>>>>>>>>>> - OpenGL1 >>>>>>>>>>>> >>>>>>>>>>>> - OpenGL2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Attached some code that reproduces the problem, to be used with >>>>>>>>>>>> this >>>>>>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>>>>>> >>>>>>>>>>>> The text is rendered properly when used with the old backend or >>>>>>>>>>>> when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>>>>>> >>>>>>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> Simon Esneault >>>>>>>>>>>> Rennes, France >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> Simon Esneault >>>>>>>>>>> Rennes, France >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>> >>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>> >>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>>>>>> >>>>>>>>>>> Search the list archives at: >>>>>>>>>>> http://markmail.org/search/?q=vtkusers >>>>>>>>>>> >>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>> * >>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>> * >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> Simon Esneault >>>>>>> Rennes, France >>>>>>> ------------------------------------------------------------------ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> Simon Esneault >>>> Rennes, France >>>> ------------------------------------------------------------------ >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the 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 >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> 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. >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Mon Nov 23 08:48:53 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 23 Nov 2015 14:48:53 +0100 Subject: [vtk-developers] Adding a GIL ensure call before all call to python In-Reply-To: References: Message-ID: Hi I have a fully tested gil branch, can someone review it and upvote if it's ok ? Thx. https://gitlab.kitware.com/vtk/vtk/merge_requests/582 Mathieu Westphal On Tue, Jul 7, 2015 at 8:30 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Ok, so we may add another option in cmake like : > VTK_PYTHON_GIL_EVERYWHERE, so it will not break anything. > > > > > Mathieu Westphal > > On Fri, Jul 3, 2015 at 3:59 PM, David E DeMarle > wrote: > >> This was the commit I was referring to. >> http://review.source.kitware.com/#/c/11214/ >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Fri, Jul 3, 2015 at 8:47 AM, David E DeMarle > > wrote: >> >>> Careful there. We took something very much like that out at ParaView >>> 4.0. The GIL made ParaView incompatible with many python packages. When I >>> get to my desk I can check my notes and refresh my memory. >>> On Jul 3, 2015 5:56 AM, "Mathieu Westphal" >>> wrote: >>> >>>> A client requesting us to apply a patch to paraview so every single >>>> call to python >>>> (PyRun, Py_Decref, PyImport, PyObject, PyString... ) to be surrounded by >>>> PyGILState_Ensure >>>> PyGILState_Release >>>> >>>> if VTK_NO_PYTHON_THREADS is not defined. >>>> >>>> is this acceptable ? some python calls are already done like that, see >>>> vtkPythonUtil.cxx. >>>> >>>> This option is defined to 1 by default. >>>> >>>> >>>> Mathieu Westphal >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the 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 Mon Nov 23 12:16:16 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 23 Nov 2015 12:16:16 -0500 Subject: [vtk-developers] [vtkusers] VTK 6.3 OpenGL2 - vtkTextActor blurred text when used with vtkFixedPointVolumeRayCastMapper In-Reply-To: References: Message-ID: I believe that might be because of push and pop attributes in older GL. I updated the the mantis (I hope I did it right -:)). Thanks Simon. On Mon, Nov 23, 2015 at 4:32 AM, Simon ESNEAULT wrote: > Hello, > > Thanks for merging this. > > As a side note, I believe the same is true for the old backend, because > the function vtkOpenGLRayCastImageDisplayHelper::RenderTextureInternal( > ... ) does also modify the blend state without restoring it. But somehow, > the 2D texture are correctly drawn with the old backend ... > > Mantis bugs : > http://www.vtk.org/Bug/view.php?id=15838 > and > http://www.vtk.org/Bug/view.php?id=15812 > > can now be closed :) > > Thanks > Simon > > 2015-11-21 2:39 GMT+01:00 Aashish Chaudhary >: > >> Simon, >> >> You branch has been merged: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/932. Thank for the >> patch. >> >> - Aashish >> >> On Fri, Nov 20, 2015 at 9:37 AM, Ken Martin >> wrote: >> >>> That is the standard blend save/restore code so I think that should do >>> the trick. Thanks for digging into it. >>> >>> On Fri, Nov 20, 2015 at 8:32 AM, Aashish Chaudhary < >>> aashish.chaudhary at kitware.com> wrote: >>> >>>> Hi Simon, >>>> >>>> Thanks! I am okay with merging this change but in general restoring to >>>> previous state is tricky as for that you need to know the previous state. I >>>> think restoring to a default state (which you did) makes more sense. >>>> Although in VTK we don't have clear guideline on this. I am reviewing your >>>> changes.. >>>> >>>> >>>> On Fri, Nov 20, 2015 at 8:26 AM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> I've created a merge request for this bug : >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/932 >>>>> >>>>> The class vtkOpenGLRayCastImageDisplayHelper is changing OpenGL blend >>>>> state, but never restores the state as it was before, resulting in some >>>>> incorrect blend later. >>>>> I don't know if it's the correct fix, but it certainly look like the >>>>> reason for this bug, and it solve the bug here. >>>>> Can someone review this merge ? >>>>> >>>>> Regards >>>>> Simon >>>>> >>>>> >>>>> 2015-11-18 9:38 GMT+01:00 Simon ESNEAULT : >>>>> >>>>>> Morning ! >>>>>> >>>>>> http://www.vtk.org/Bug/view.php?id=15838 >>>>>> >>>>>> Let me know if there is anything I can do to solve this. >>>>>> >>>>>> Simon >>>>>> >>>>>> 2015-11-17 16:50 GMT+01:00 Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com>: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 17, 2015 at 3:36 AM, Simon ESNEAULT < >>>>>>> simon.esneault at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Aashish, >>>>>>>> >>>>>>>> Yes the root cause is probably located in vtkTexturedActor2D, or in >>>>>>>> vtkOpenGLTexture::Load( vtkRenderer* ) which looks like the responsible >>>>>>>> class for loading the texture. >>>>>>>> Shall I fill a bug ? >>>>>>>> >>>>>>> >>>>>>> Yes, please. >>>>>>> >>>>>>> - Aashish >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Simon >>>>>>>> >>>>>>>> 2015-11-16 17:49 GMT+01:00 Aashish Chaudhary < >>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>> >>>>>>>>> I see so its not just related to volume rendering and it seems to >>>>>>>>> be a vtkTextActor2D problem? In that can probably Ken / David Lonie wants >>>>>>>>> to take a look at it. Nonetheless, we will follow up on this bug. >>>>>>>>> >>>>>>>>> - Aashish >>>>>>>>> >>>>>>>>> On Mon, Nov 16, 2015 at 11:12 AM, Simon ESNEAULT < >>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello Aashish, >>>>>>>>>> >>>>>>>>>> Thanks ! >>>>>>>>>> After doing some test, I realized the patch I've just sent is not >>>>>>>>>> the correct fix at all, because the text is not rendered properly when we >>>>>>>>>> don't use a vtkFixedPointVolumeRayCastMapper anymore. >>>>>>>>>> >>>>>>>>>> I believe the problem is probably larger than this and probably >>>>>>>>>> has nothing to do with the freetype text generation, but more with the >>>>>>>>>> vtkTexturedActor2D rendering part used together with a >>>>>>>>>> vtkFixedPointVolumeRayCastMapper on the new rendering backend, when the >>>>>>>>>> texture has some transparent pixel in it ... >>>>>>>>>> >>>>>>>>>> Attached there is a new example that demonstrate that a >>>>>>>>>> vtkTextActor AND a vtkTexturedButtonRepresentation2D are not correctly >>>>>>>>>> drawn in that case : >>>>>>>>>> - OpenGL1 backend >>>>>>>>>> : Transparent >>>>>>>>>> pixel in Texture are correctly drawn >>>>>>>>>> - OpenGL2 backend >>>>>>>>>> >>>>>>>>>> : Transparent pixel in Texture are not correctly drawn (clamped to white ?) >>>>>>>>>> >>>>>>>>>> The example is more simple than the previous one and does not >>>>>>>>>> need any additional data. >>>>>>>>>> >>>>>>>>>> Hope that helps ! >>>>>>>>>> -Simon >>>>>>>>>> >>>>>>>>>> 2015-11-16 16:11 GMT+01:00 Aashish Chaudhary < >>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>> >>>>>>>>>>> Simon, >>>>>>>>>>> >>>>>>>>>>> Thanks for the report. I will follow up with other developers on >>>>>>>>>>> this bug. >>>>>>>>>>> >>>>>>>>>>> - Aashish >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 16, 2015 at 6:08 AM, Simon ESNEAULT < >>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Trying to solve this problem, I found out that if one call >>>>>>>>>>>> "vtkFreeTypeTools::GetInstance()->DebugTexturesOn();" before to render a >>>>>>>>>>>> string with a vtkTextActor, the text is properly rendered with a yellow dot >>>>>>>>>>>> at the anchor point, and with a transparent gray background. >>>>>>>>>>>> - DebugTexturesOn : >>>>>>>>>>>> http://picpaste.com/pics/Blurred.1447668943.PNG >>>>>>>>>>>> - DebugTexturesOff : >>>>>>>>>>>> http://picpaste.com/pics/Not-Blurred.1447669009.PNG >>>>>>>>>>>> >>>>>>>>>>>> Now digging into the code in vtkFreeTypeTools.cxx, I suspect >>>>>>>>>>>> this is a blending problem. When we activate Texture Debugging, a gray >>>>>>>>>>>> background is first drawn, and after that in the method RenderCharacter( >>>>>>>>>>>> ... ) line 1887; we either blend the rendered text with the background or >>>>>>>>>>>> not. >>>>>>>>>>>> >>>>>>>>>>>> Attached is a diff file that solves the problem for me. I do >>>>>>>>>>>> not really understand why, so maybe a developer with more VTK's knowledge >>>>>>>>>>>> can integrate this properly :) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Simon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2015-11-13 16:43 GMT+01:00 Simon ESNEAULT < >>>>>>>>>>>> simon.esneault at gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> All vtkTextActor are rendered blurred when using with >>>>>>>>>>>>> vtkFixedPointVolumeRayCastMapper in the same renderer in vtk 6.3 with the >>>>>>>>>>>>> new rendering backend. >>>>>>>>>>>>> >>>>>>>>>>>>> Here are some snapshots : >>>>>>>>>>>>> - OpenGL1 >>>>>>>>>>>>> >>>>>>>>>>>>> - OpenGL2 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Attached some code that reproduces the problem, to be used >>>>>>>>>>>>> with this >>>>>>>>>>>>> >>>>>>>>>>>>> volume. Visible on OSX and Windows to our knowledge, probably on more OS. >>>>>>>>>>>>> >>>>>>>>>>>>> The text is rendered properly when used with the old backend >>>>>>>>>>>>> or when using a vtkGPUVolumeRayCastMapper instead of >>>>>>>>>>>>> the vtkFixedPointVolumeRayCastMapper. >>>>>>>>>>>>> >>>>>>>>>>>>> Shall I feel a bug, is this a known issue ? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Simon >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> Simon Esneault >>>>>>>>>>>> Rennes, France >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>> >>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>> >>>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at: >>>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ >>>>>>>>>>>> >>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>> http://markmail.org/search/?q=vtkusers >>>>>>>>>>>> >>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>> * >>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> Simon Esneault >>>>>>>>>> Rennes, France >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>> * >>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>> * >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> Simon Esneault >>>>>>>> Rennes, France >>>>>>>> ------------------------------------------------------------------ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> Simon Esneault >>>>>> Rennes, France >>>>>> ------------------------------------------------------------------ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the 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 >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 >>> >>> 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. >>> >> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >> * >> *| http://www.kitware.com/company/team/chaudhary.html >> * >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Tue Nov 24 06:04:08 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 24 Nov 2015 12:04:08 +0100 Subject: [vtk-developers] Updated VTK Breaks ParaView tests Message-ID: Hello I am trying to update VTK in ParaView in order to integrate my GIL ensured changes, but a lot of python Tests are failing with paraview, with the following error : Traceback (most recent call last): File "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", line 9, in Show() File "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", line 158, in __getattr__ return getattr(self.SMController, name) AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object has no attribute 'Show' Traceback (most recent call last): File "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", line 9, in Show() File "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", line 158, in __getattr__ return getattr(self.SMController, name) AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object has no attribute 'Show' https://open.cdash.org/index.php?compare1=63&filtercount=2&field1=buildname%2Fstring&project=ParaView&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=dbdbee7a&showfeed=0&value2=20151124T043202 https://gitlab.kitware.com/paraview/paraview/merge_requests/329#note_47210 I Suspect it is because of a VTK commit, and i will try to recreate it locally by only updating VTK and bisecting the commits. But if anyone has an idea about it, that would be nice. Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Nov 24 13:13:06 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 24 Nov 2015 11:13:06 -0700 Subject: [vtk-developers] Updated VTK Breaks ParaView tests In-Reply-To: References: Message-ID: Hi Mathieu, The errors look similar to ones that were fixed by this commit: https://gitlab.kitware.com/paraview/paraview/commit/8a6e6fe9 At the very root, bugs such as the ones fixed by the above commit are caused by type checks of the form "type{x) == y". Such type checks should almost always be replaced by calls to "isinstance()" or "issubclass()". I did a quick grep through the ParaView source code to find places where type() is being used to do type checks, and I found several. I'm pretty sure that at least some of these are bugs: Wrapping/Python/paraview/coprocessing.py:54: if type(frequencies) != dict: Wrapping/Python/paraview/data_exploration.py:204: if type(value) == type("String"): Wrapping/Python/paraview/extract_selection.py:88: (query, type(maskArray)) Wrapping/Python/paraview/servermanager.py:654: if not type(self) is Property: Wrapping/Python/paraview/servermanager.py:671: if type(self) is Property: Wrapping/Python/paraview/servermanager.py:888: if type(value) == str: Wrapping/Python/paraview/servermanager.py:2295: elif type(arg1) is types.IntType: Wrapping/Python/paraview/servermanager.py:3038: if not type(val) == int: Wrapping/Python/paraview/simple.py:740: if type(filename) == list: Wrapping/Python/paraview/smtrace.py:397: if not type(prop) == sm.Property: Wrapping/Python/paraview/smtrace.py:490: assert type(propertyname) == str Wrapping/Python/paraview/smtrace.py:1112: return "'%s'" % x if type(x) == str else x Web/Applications/FileViewer/server/pv_web_file_loader.py:136: if type(files) == list: Web/Python/paraview/web/helper.py:249: if type(data) in allowedTypes: Web/Python/paraview/web/helper.py:272: elif type(prop) == ProxyProperty: Web/Python/paraview/web/helper.py:297: if property.GetDomain('proxy_list') and len(value) == 1 and type(value[0]) == str: Web/Python/paraview/web/helper.py:315: if type(value) == unicode: Web/Python/paraview/web/helper.py:317: if type(value) == list: Web/Python/paraview/web/helper.py:349: if type(proxy.GetProperty(property)) == ProxyProperty: Web/Python/paraview/web/protocols.py:1192: if type(prop) == ProxyProperty or type(prop) == InputProperty: Web/Python/paraview/web/protocols.py:1590: if type(relativePath) == list: Web/Python/paraview/web/protocols.py:1933: if type(relativePath) == list: Web/Python/paraview/web/protocols.py:1962: if type(lut['name']) == unicode: Web/Python/paraview/web/pv_web_catalyst.py:202: if type(files) == list: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:54: elif type(array) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:74: if type(array1) == dsa.VTKCompositeDataArray and type(val2) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:83: elif type(array1) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:112: if type(array) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:132: if type(ds) == dsa.CompositeDataSet: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:176: if type(array) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:341: t = type(array) VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:700: if type(array) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:727: if type(array) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:753: if type(array) == dsa.VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:776: if type(arrayx) == dsa.VTKCompositeDataArray and type(arrayy) == dsa.VTKCompositeDataArray and (type(arrayz) == dsa.VTKCompositeDataArray or arrayz is None): VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:515: if type(index) == VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:534: if type(other) == VTKCompositeDataArray: VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:555: if type(other) == VTKCompositeDataArray: - David On Tue, Nov 24, 2015 at 4:04 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hello > > I am trying to update VTK in ParaView in order to integrate my GIL ensured > changes, but a lot of python Tests are failing with paraview, with the > following error : > > Traceback (most recent call last): File > "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", > line 9, in Show() File > "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", > line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File > "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", > line 158, in __getattr__ return getattr(self.SMController, name) > AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object > has no attribute 'Show' Traceback (most recent call last): File > "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", > line 9, in Show() File > "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", > line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File > "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", > line 158, in __getattr__ return getattr(self.SMController, name) > AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object > has no attribute 'Show' > > > > https://open.cdash.org/index.php?compare1=63&filtercount=2&field1=buildname%2Fstring&project=ParaView&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=dbdbee7a&showfeed=0&value2=20151124T043202 > > https://gitlab.kitware.com/paraview/paraview/merge_requests/329#note_47210 > > > I Suspect it is because of a VTK commit, and i will try to recreate it > locally by only updating VTK and bisecting the commits. > > But if anyone has an idea about it, that would be nice. > > Mathieu Westphal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Wed Nov 25 04:24:53 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 25 Nov 2015 10:24:53 +0100 Subject: [vtk-developers] Updated VTK Breaks ParaView tests In-Reply-To: References: Message-ID: Hi Ben I'e bissecting the commit and found the cullprint, looks like this one breaks it : https://gitlab.kitware.com/vtk/vtk/commit/68c3cc53e47c30e7ef8a74fa2b40ced0f234834c Mathieu Westphal On Tue, Nov 24, 2015 at 7:13 PM, David Gobbi wrote: > Hi Mathieu, > > The errors look similar to ones that were fixed by this commit: > https://gitlab.kitware.com/paraview/paraview/commit/8a6e6fe9 > > At the very root, bugs such as the ones fixed by the above commit > are caused by type checks of the form "type{x) == y". Such type > checks should almost always be replaced by calls to "isinstance()" > or "issubclass()". > > I did a quick grep through the ParaView source code to find places > where type() is being used to do type checks, and I found several. > I'm pretty sure that at least some of these are bugs: > > Wrapping/Python/paraview/coprocessing.py:54: if type(frequencies) > != dict: > Wrapping/Python/paraview/data_exploration.py:204: if > type(value) == type("String"): > Wrapping/Python/paraview/extract_selection.py:88: (query, > type(maskArray)) > Wrapping/Python/paraview/servermanager.py:654: if not type(self) is > Property: > Wrapping/Python/paraview/servermanager.py:671: if type(self) is > Property: > Wrapping/Python/paraview/servermanager.py:888: if type(value) == > str: > Wrapping/Python/paraview/servermanager.py:2295: elif type(arg1) is > types.IntType: > Wrapping/Python/paraview/servermanager.py:3038: if not type(val) == int: > Wrapping/Python/paraview/simple.py:740: if type(filename) == list: > Wrapping/Python/paraview/smtrace.py:397: if not type(prop) == > sm.Property: > Wrapping/Python/paraview/smtrace.py:490: assert type(propertyname) > == str > Wrapping/Python/paraview/smtrace.py:1112: return "'%s'" % x if > type(x) == str else x > Web/Applications/FileViewer/server/pv_web_file_loader.py:136: if > type(files) == list: > Web/Python/paraview/web/helper.py:249: if type(data) in > allowedTypes: > Web/Python/paraview/web/helper.py:272: elif type(prop) == > ProxyProperty: > Web/Python/paraview/web/helper.py:297: if > property.GetDomain('proxy_list') and len(value) == 1 and type(value[0]) == > str: > Web/Python/paraview/web/helper.py:315: if type(value) == unicode: > Web/Python/paraview/web/helper.py:317: if type(value) == list: > Web/Python/paraview/web/helper.py:349: if > type(proxy.GetProperty(property)) == ProxyProperty: > Web/Python/paraview/web/protocols.py:1192: if type(prop) == > ProxyProperty or type(prop) == InputProperty: > Web/Python/paraview/web/protocols.py:1590: if type(relativePath) == > list: > Web/Python/paraview/web/protocols.py:1933: if type(relativePath) == > list: > Web/Python/paraview/web/protocols.py:1962: if > type(lut['name']) == unicode: > Web/Python/paraview/web/pv_web_catalyst.py:202: if type(files) == > list: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:54: elif > type(array) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:74: if > type(array1) == dsa.VTKCompositeDataArray and type(val2) == > dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:83: elif > type(array1) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:112: if > type(array) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:132: if > type(ds) == dsa.CompositeDataSet: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:176: if > type(array) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:341: t = > type(array) > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:700: if > type(array) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:727: if > type(array) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:753: if > type(array) == dsa.VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:776: if > type(arrayx) == dsa.VTKCompositeDataArray and type(arrayy) == > dsa.VTKCompositeDataArray and (type(arrayz) == dsa.VTKCompositeDataArray or > arrayz is None): > VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:515: if > type(index) == VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:534: if > type(other) == VTKCompositeDataArray: > VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:555: if > type(other) == VTKCompositeDataArray: > > - David > > > > > > On Tue, Nov 24, 2015 at 4:04 AM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> Hello >> >> I am trying to update VTK in ParaView in order to integrate my GIL >> ensured changes, but a lot of python Tests are failing with paraview, with >> the following error : >> >> Traceback (most recent call last): File >> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", >> line 9, in Show() File >> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", >> line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File >> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", >> line 158, in __getattr__ return getattr(self.SMController, name) >> AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object >> has no attribute 'Show' Traceback (most recent call last): File >> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", >> line 9, in Show() File >> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", >> line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File >> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", >> line 158, in __getattr__ return getattr(self.SMController, name) >> AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object >> has no attribute 'Show' >> >> >> >> https://open.cdash.org/index.php?compare1=63&filtercount=2&field1=buildname%2Fstring&project=ParaView&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=dbdbee7a&showfeed=0&value2=20151124T043202 >> >> https://gitlab.kitware.com/paraview/paraview/merge_requests/329#note_47210 >> >> >> I Suspect it is because of a VTK commit, and i will try to recreate it >> locally by only updating VTK and bisecting the commits. >> >> But if anyone has an idea about it, that would be nice. >> >> Mathieu Westphal >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Wed Nov 25 05:17:52 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Wed, 25 Nov 2015 11:17:52 +0100 Subject: [vtk-developers] [Paraview-developers] Updated VTK Breaks ParaView tests In-Reply-To: References: Message-ID: We found the bug :) a strcmp != 0 was replaced by a std::string == std::string!!! Ben will be chasten for this! ;) 2015-11-25 10:24 GMT+01:00 Mathieu Westphal : > Hi Ben > > I'e bissecting the commit and found the cullprint, looks like this one > breaks it : > > https://gitlab.kitware.com/vtk/vtk/commit/68c3cc53e47c30e7ef8a74fa2b40ced0f234834c > > > Mathieu Westphal > > On Tue, Nov 24, 2015 at 7:13 PM, David Gobbi > wrote: > >> Hi Mathieu, >> >> The errors look similar to ones that were fixed by this commit: >> https://gitlab.kitware.com/paraview/paraview/commit/8a6e6fe9 >> >> At the very root, bugs such as the ones fixed by the above commit >> are caused by type checks of the form "type{x) == y". Such type >> checks should almost always be replaced by calls to "isinstance()" >> or "issubclass()". >> >> I did a quick grep through the ParaView source code to find places >> where type() is being used to do type checks, and I found several. >> I'm pretty sure that at least some of these are bugs: >> >> Wrapping/Python/paraview/coprocessing.py:54: if type(frequencies) >> != dict: >> Wrapping/Python/paraview/data_exploration.py:204: if >> type(value) == type("String"): >> Wrapping/Python/paraview/extract_selection.py:88: (query, >> type(maskArray)) >> Wrapping/Python/paraview/servermanager.py:654: if not type(self) >> is Property: >> Wrapping/Python/paraview/servermanager.py:671: if type(self) is >> Property: >> Wrapping/Python/paraview/servermanager.py:888: if type(value) == >> str: >> Wrapping/Python/paraview/servermanager.py:2295: elif type(arg1) is >> types.IntType: >> Wrapping/Python/paraview/servermanager.py:3038: if not type(val) == >> int: >> Wrapping/Python/paraview/simple.py:740: if type(filename) == list: >> Wrapping/Python/paraview/smtrace.py:397: if not type(prop) == >> sm.Property: >> Wrapping/Python/paraview/smtrace.py:490: assert type(propertyname) >> == str >> Wrapping/Python/paraview/smtrace.py:1112: return "'%s'" % x if >> type(x) == str else x >> Web/Applications/FileViewer/server/pv_web_file_loader.py:136: if >> type(files) == list: >> Web/Python/paraview/web/helper.py:249: if type(data) in >> allowedTypes: >> Web/Python/paraview/web/helper.py:272: elif type(prop) == >> ProxyProperty: >> Web/Python/paraview/web/helper.py:297: if >> property.GetDomain('proxy_list') and len(value) == 1 and type(value[0]) == >> str: >> Web/Python/paraview/web/helper.py:315: if type(value) == unicode: >> Web/Python/paraview/web/helper.py:317: if type(value) == list: >> Web/Python/paraview/web/helper.py:349: if >> type(proxy.GetProperty(property)) == ProxyProperty: >> Web/Python/paraview/web/protocols.py:1192: if type(prop) >> == ProxyProperty or type(prop) == InputProperty: >> Web/Python/paraview/web/protocols.py:1590: if type(relativePath) >> == list: >> Web/Python/paraview/web/protocols.py:1933: if type(relativePath) >> == list: >> Web/Python/paraview/web/protocols.py:1962: if >> type(lut['name']) == unicode: >> Web/Python/paraview/web/pv_web_catalyst.py:202: if type(files) == >> list: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:54: elif >> type(array) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:74: if >> type(array1) == dsa.VTKCompositeDataArray and type(val2) == >> dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:83: elif >> type(array1) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:112: if >> type(array) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:132: if >> type(ds) == dsa.CompositeDataSet: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:176: if >> type(array) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:341: t = >> type(array) >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:700: if >> type(array) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:727: if >> type(array) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:753: if >> type(array) == dsa.VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/algorithms.py:776: if >> type(arrayx) == dsa.VTKCompositeDataArray and type(arrayy) == >> dsa.VTKCompositeDataArray and (type(arrayz) == dsa.VTKCompositeDataArray or >> arrayz is None): >> VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:515: if >> type(index) == VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:534: if >> type(other) == VTKCompositeDataArray: >> VTK/Wrapping/Python/vtk/numpy_interface/dataset_adapter.py:555: if >> type(other) == VTKCompositeDataArray: >> >> - David >> >> >> >> >> >> On Tue, Nov 24, 2015 at 4:04 AM, Mathieu Westphal < >> mathieu.westphal at kitware.com> wrote: >> >>> Hello >>> >>> I am trying to update VTK in ParaView in order to integrate my GIL >>> ensured changes, but a lot of python Tests are failing with paraview, with >>> the following error : >>> >>> Traceback (most recent call last): File >>> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", >>> line 9, in Show() File >>> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", >>> line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File >>> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", >>> line 158, in __getattr__ return getattr(self.SMController, name) >>> AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object >>> has no attribute 'Show' Traceback (most recent call last): File >>> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/source/ParaViewCore/ServerManager/Default/Testing/Python/MultiView.py", >>> line 9, in Show() File >>> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/simple.py", >>> line 400, in Show rep = controller.Show(proxy, proxy.Port, view) File >>> "/home/kitware/Dashboards/buildslave/paraview-amber8-linux-static-release_mpi_osmesa_python/build/lib/site-packages/paraview/servermanager.py", >>> line 158, in __getattr__ return getattr(self.SMController, name) >>> AttributeError: 'vtkPVServerManagerCorePython.vtkSMParaViewPipeline' object >>> has no attribute 'Show' >>> >>> >>> >>> https://open.cdash.org/index.php?compare1=63&filtercount=2&field1=buildname%2Fstring&project=ParaView&field2=buildstarttime%2Fdate&showfilters=0&limit=100&compare2=83&value1=dbdbee7a&showfeed=0&value2=20151124T043202 >>> >>> >>> https://gitlab.kitware.com/paraview/paraview/merge_requests/329#note_47210 >>> >>> >>> I Suspect it is because of a VTK commit, and i will try to recreate it >>> locally by only updating VTK and bisecting the commits. >>> >>> But if anyone has an idea about it, that would be nice. >>> >>> Mathieu Westphal >>> >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: > http://markmail.org/search/?q=Paraview-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Nov 25 14:07:45 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 25 Nov 2015 14:07:45 -0500 Subject: [vtk-developers] [ANN] Buildbot updates In-Reply-To: <20151119192947.GA11791@megas.khq.kitware.com> References: <20151119192947.GA11791@megas.khq.kitware.com> Message-ID: <20151125190745.GA4433@megas.khq.kitware.com> On Thu, Nov 19, 2015 at 14:29:47 -0500, Ben Boeckel wrote: > If no one objects, we'd like to turn off "@buildbot test" by the middle > of next week; I haven't seen any new uses of it, so disabling it will > only stop builders running when a branch is updated that haven't had a > "Do: test" (buildbot marks such instances when it comes across them). I've turned this off. Any MR using "@buildbot test" will need a "Do: test" to use buildbot. --Ben From sean at rogue-research.com Wed Nov 25 17:03:06 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 25 Nov 2015 17:03:06 -0500 Subject: [vtk-developers] cppcheck of VTK now on dashboard Message-ID: <20151125220306.417462295@mail.rogue-research.com> Hi all, Thanks to my colleague Alex, we now have a nightly cppcheck static analysis of VTK on the dashboard. I'd like to propose creating a 'Static Analysis' section in the dashboard, placed next to the 'Dynamic Analysis' section, and put there anything using cppcheck or clang static analyzer, which I believe currently would be just: Mac10.11-cppcheck-x86_64 Linux-clang3.4-scanbuild If you want to run cppcheck yourself, there's a suppressions file you should use to eliminate some of the noise, located at VTK/CMake/VTKcppcheckSuppressions.txt. (I will have follow up posts asking for help to solve identified issues... :)) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From mathieu.westphal at kitware.com Thu Nov 26 08:21:15 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 26 Nov 2015 14:21:15 +0100 Subject: [vtk-developers] Dashboards down Message-ID: Hi Dashboards are down : https://open.cdash.org/ Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Nov 27 04:11:58 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 27 Nov 2015 10:11:58 +0100 Subject: [vtk-developers] Dashboards down In-Reply-To: References: Message-ID: Hi Again, dashboards are down, any info ? https://open.cdash.org/ Mathieu Mathieu Westphal On Thu, Nov 26, 2015 at 2:21 PM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hi > > Dashboards are down : > https://open.cdash.org/ > > Mathieu Westphal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Mon Nov 30 09:44:06 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Mon, 30 Nov 2015 15:44:06 +0100 Subject: [vtk-developers] OpenGLExtensions not loaded with OffscreenRendering and MultiSamples Message-ID: Hi, I have an issue (master OpenGL1) with OffscreenRendering if vtkRenderWindow::MultiSamples > 1. In vtkOpenGLRenderWindow::CreateHardwareOffScreenWindow there is this test added 10 months ago by David Lonie: // This implementation currently ignores multisampling configurations: if (this->MultiSamples > 1) { vtkDebugMacro(<<"Multisampling is not currently supported by the " "accelerated offscreen rendering backend. Falling back to " "a platform-specific offscreen solution..."); return 0; } and that falls back to the method vtkWin32OpenGLRenderWindow::CreateOffScreenDC. But in this case, when i enter later in vtkOpenGLExtensionManager::ReadOpenGLExtensions, i have only 3 extensions loaded, instead of a lot of them when it is CreateHardwareOffScreenWindow that runs. A workaround is to set MultiSamples to 0 since it is currently not implemented, but i am wondering why the extensions are not loaded, and if something is missing in CreateOffScreenDC. For information, with OpenGL2 this modification has been commented out with this note: "the following code causes tests to fail, commenting it out" Thanks for any information about that. Xabi -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Mon Nov 30 09:54:14 2015 From: david.lonie at kitware.com (David Lonie) Date: Mon, 30 Nov 2015 09:54:14 -0500 Subject: [vtk-developers] OpenGLExtensions not loaded with OffscreenRendering and MultiSamples In-Reply-To: References: Message-ID: On Mon, Nov 30, 2015 at 9:44 AM, Xabi Riobe wrote: > Thanks for any information about that. > > Xabi > I'm not sure why the OpenGL2 version was removed, and it's possible that there are some bits after that check that should still be executed, so feel free to modify this as needed. The reason for the check is that the FBO-based offscreen rendering implementation provided by vtkOpenGLRenderWindow does not support multisampling, and trying to render offscreen with multisampling will not anti-alias the result without that check. So when MSAA is requested, the generic FBO method should fail so that the platform-specific render windows can use their platform-specific offscreen implementations (which do support MSAA). Hope this helps, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Mon Nov 30 10:03:56 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Mon, 30 Nov 2015 16:03:56 +0100 Subject: [vtk-developers] OpenGLExtensions not loaded with OffscreenRendering and MultiSamples In-Reply-To: References: Message-ID: Thanks for the quick answer! Yes i understood the reason for the check, the message in vtkDebugMacro is clear, but what i would like to know is the reason for the extensions failing in that case; probably something missing in vtkWin32OpenGLRenderWindow::CreateOffScreenDC but i don't know what. As for the anti-aliasing, it is not working, probably also because of CreateOffScreenDC... 2015-11-30 15:54 GMT+01:00 David Lonie : > On Mon, Nov 30, 2015 at 9:44 AM, Xabi Riobe wrote: > >> Thanks for any information about that. >> >> Xabi >> > > I'm not sure why the OpenGL2 version was removed, and it's possible that > there are some bits after that check that should still be executed, so feel > free to modify this as needed. > > The reason for the check is that the FBO-based offscreen rendering > implementation provided by vtkOpenGLRenderWindow does not support > multisampling, and trying to render offscreen with multisampling will not > anti-alias the result without that check. > > So when MSAA is requested, the generic FBO method should fail so that the > platform-specific render windows can use their platform-specific offscreen > implementations (which do support MSAA). > > Hope this helps, > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Mon Nov 30 12:38:57 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 30 Nov 2015 10:38:57 -0700 Subject: [vtk-developers] swap interval and mouse input problems Message-ID: <2913027.4XeZvNEaqs@stryke> Hi, On certain platforms with certain Xlib or OpenGL implementations, I'm seeing interaction lags when using VTK in Qt applications. I see this with both QVTKWidget and QVTKWidget2. With a swap interval = 1 to prevent tearing, the SwapBuffers() can stall, which can result in mouse input events being queued by the X server. Here is bug report describing the same issue https://bugreports.qt.io/browse/QTBUG-39370 It appears the best fix is to request a render in response to high frequency mouse input, rather than doing a render immediately. This fixes the queuing of mouse events which can come at a higher frequency than the monitor refresh rate. This will allow consuming multiple mouse events between a render. This requesting of renders makes application behavior consistent regardless of the swap interval setting. However, VTK doesn't appear to have a mechanism for 'requesting' a render. As an experiment, I changed vtkRenderWindowInteractor::Render to request a render rather than do one, and then call vtkRenderWindow::Render when an actual render needs to happen. This fixes the mouse lag problem. This approach to fixing the problem changes the meaning of Render(), and also doesn't fit with vtkRenderView::Render(). It seems vtkRenderView could be changed to rely on vtkRenderWindow's StartEvent event instead of the interactor's RenderEvent. Would it make more sense to propose that a new function be added to request a render? RequestRender()? Thanks, Clint From ben.boeckel at kitware.com Mon Nov 30 13:26:05 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 30 Nov 2015 13:26:05 -0500 Subject: [vtk-developers] swap interval and mouse input problems In-Reply-To: <2913027.4XeZvNEaqs@stryke> References: <2913027.4XeZvNEaqs@stryke> Message-ID: <20151130182605.GA28288@megas.khq.kitware.com> On Mon, Nov 30, 2015 at 10:38:57 -0700, Clinton Stimpson wrote: > On certain platforms with certain Xlib or OpenGL implementations, I'm seeing > interaction lags when using VTK in Qt applications. I see this with both > QVTKWidget and QVTKWidget2. This is a Qt bug; they don't collapse mouse events as they used to. The patch with the fix is in 5.6 (I asked about getting it into 5.5.1, but it was pushed to 5.6.0 anyways). https://codereview.qt-project.org/#/c/115531/ https://codereview.qt-project.org/#/c/126136/ Though if the fix is as simple as tis makes it seem to be? https://codereview.qt-project.org/#/c/90873/4/examples/opengl/hellogl/glwidget.cpp --Ben From clinton at elemtech.com Mon Nov 30 14:33:46 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 30 Nov 2015 12:33:46 -0700 Subject: [vtk-developers] swap interval and mouse input problems In-Reply-To: <20151130182605.GA28288@megas.khq.kitware.com> References: <2913027.4XeZvNEaqs@stryke> <20151130182605.GA28288@megas.khq.kitware.com> Message-ID: <2094175.8lnOgQf9jS@stryke> On Monday, November 30, 2015 01:26:05 PM Ben Boeckel wrote: > On Mon, Nov 30, 2015 at 10:38:57 -0700, Clinton Stimpson wrote: > > On certain platforms with certain Xlib or OpenGL implementations, I'm > > seeing interaction lags when using VTK in Qt applications. I see this > > with both QVTKWidget and QVTKWidget2. > > This is a Qt bug; they don't collapse mouse events as they used to. The > patch with the fix is in 5.6 (I asked about getting it into 5.5.1, but > it was pushed to 5.6.0 anyways). > > https://codereview.qt-project.org/#/c/115531/ > https://codereview.qt-project.org/#/c/126136/ Thanks! I had first expected a compression of mouse events, and was confused when I saw this problem. A fix in Qt would be nice. > > Though if the fix is as simple as tis makes it seem to be? > > > https://codereview.qt-project.org/#/c/90873/4/examples/opengl/hellogl/glwid > get.cpp That fix to hellogl is basically equivalent to what I did in an experiment. Putting a formal fix into VTK is what I'm proposing here. In the past, I expected compression to be a normal thing (and done by the X server), but now I understand this is not how it works on the X level. Compression is implemented by the client, and in this case, compression is being expected of Qt. Here is a request to *not* compress X events. https://bugreports.qt.io/browse/QTBUG-44964 Are we still interested in putting a fix into VTK for this? Clint From ben.boeckel at kitware.com Mon Nov 30 15:25:17 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 30 Nov 2015 15:25:17 -0500 Subject: [vtk-developers] swap interval and mouse input problems In-Reply-To: <2094175.8lnOgQf9jS@stryke> References: <2913027.4XeZvNEaqs@stryke> <20151130182605.GA28288@megas.khq.kitware.com> <2094175.8lnOgQf9jS@stryke> Message-ID: <20151130202517.GA19563@megas.khq.kitware.com> On Mon, Nov 30, 2015 at 12:33:46 -0700, Clinton Stimpson wrote: > Thanks! I had first expected a compression of mouse events, and was confused > when I saw this problem. A fix in Qt would be nice. The patch I tested (#9 or so of the first link), there was a .1s delay still, but nowhere near as bad as it is without the patch. > > Though if the fix is as simple as tis makes it seem to be? > > > > > > https://codereview.qt-project.org/#/c/90873/4/examples/opengl/hellogl/glwid > > get.cpp > > That fix to hellogl is basically equivalent to what I did in an experiment. > Putting a formal fix into VTK is what I'm proposing here. > > In the past, I expected compression to be a normal thing (and done by the X > server), but now I understand this is not how it works on the X level. > Compression is implemented by the client, and in this case, compression is > being expected of Qt. > > Are we still interested in putting a fix into VTK for this? If it doesn't break anything else and allows Qt5 < 5.6.0 to work on X, then I don't see an issue. Otherwise, it will be X+VTK needs Qt5 >= 5.6.0 (something I'd be half a mind to put into the CMake code if 5.6.0 does indeed fix it since the problems are really just too much otherwise). > Here is a request to *not* compress X events. > https://bugreports.qt.io/browse/QTBUG-44964 Well, that can be the non-default behavior (that VTK likely doesn't need to care about). --Ben From aashish.chaudhary at kitware.com Tue Nov 17 01:15:06 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 17 Nov 2015 06:15:06 -0000 Subject: [vtk-developers] [vtk-users] OpenGL2 - GPU Volume Rendering performance In-Reply-To: References: Message-ID: Dear Simon, Thanks for your example code and data. I used exactly the same code, got master of VTK from today, compiled OpenGL1 and OpenGL2 backends on Ubuntu 14.01 box then for me, the OpenGL2 backend was running much faster and higher resolution than compare to OpenGL1 backend (20 FPS vs 13 FPS). Please look at the screenshots attached. I am referring to the number you are displaying in the program. Next, I am going to run the same code on Mac and Windows and see if can reproduce your issue. May be it is windows/driver specific issue. On Fri, Nov 13, 2015 at 11:02 AM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > On Fri, Nov 13, 2015 at 10:57 AM, Simon ESNEAULT > wrote: > >> Hello Aashish, >> >> I've run some quick tests on my computer, and when disabling the >> automatic adjustment, both of the volume rendering technique seems to >> deliver the same performance, with some random Fixed sample distance. I >> will run some more test on the other computer that we've got here, just to >> be sure. And also on some mac. And report them to you :) >> > > This is very helpful and sort of confirms my theory the the code in > question is the reduction factor computation. The logic is changed between > the old mapper and the new mapper. I will look again to make them > consistent but it won't be exactly the same since the old mapper code to me > was not making the the right choices and was broken for the new mapper. > Actually, initially we had the exact same code and it was running into > issues since the new mapper was faster and hence breaking some of the > assumptions the old mapper was making. > >> >> Is there something else that I can do to help on this problem ? >> > > Not at the moment. You helped a lot, the code and the data is really > helpful. I will report back early next week again and will request you to > try again. Thanks for your patience. > > - Aashish > >> >> >> Simon >> >> >> 2015-11-12 18:34 GMT+01:00 Aashish Chaudhary < >> aashish.chaudhary at kitware.com>: >> >>> >>> >>> On Thu, Nov 12, 2015 at 12:31 PM, Aashish Chaudhary < >>> aashish.chaudhary at kitware.com> wrote: >>> >>>> >>>> >>>> On Thu, Nov 12, 2015 at 12:12 PM, Simon ESNEAULT < >>>> simon.esneault at gmail.com> wrote: >>>> >>>>> Hello Aashish, >>>>> >>>>> Sorry for the late reply, I was busy last week. >>>>> >>>>> Thanks for the update, and your work on this topic. >>>>> Yes I have seen that your change have been merged concerning the >>>>> ReductionFactor. Nevertheless, I am still getting a smaller frame rate with >>>>> the new backend. To highlight this, please find attached a very simple >>>>> application that loads a volume ( >>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip) and does volume >>>>> rendering while displaying the frame rate. This is pretty much what we show >>>>> to the user in our application, and in this condition, on my machine the >>>>> FPS are around 25 with the opengl1 backend >>>>> , and 15 with the >>>>> new backend , >>>>> from this week VTK master >>>>> It is very simple to test, just need change the VTK_DIR to an OpenGL1 >>>>> or OpenGL2 build, and place the volume.mhd and raw in the execution path. >>>>> Also you will find attached a small text file that summarizes the test >>>>> that have been done here. >>>>> >>>> >>>> No problem, thanks for the update. Please see my comments below: >>>> >>>>> >>>>> I think the real reason why it appears slower with the OGL2 version is >>>>> that we try to have control on the "MaximalImageSampleDistance". If I >>>>> remove the line l_gpu_mapper->SetMaximumImageSampleDistance( 2. ); I get >>>>> the same frame rate with each backend. BUT, the new backend does decimate a >>>>> lot more the volume, leading to a very blurred image during rendering, and >>>>> that's not what we want :/ >>>>> >>>> >>>> Aha, this is very useful since this parameters does affecting the >>>> reduction factor. I will try your code; one quick question when the new >>>> backend decimates a lot (by removing the SetMaximumImageSampleDistance), >>>> does it get any faster than the old version? I am going to try it on my Mac >>>> and Linux laptop and report back (mostly tomorrow since I am away today). >>>> >>>>> >>>>> >>> Never mind, I see that you have that in your result file. It seems it >>> does get faster but more blurry. Would it be possible for you to do one >>> more test? Can you set a fix sample distance (pick any) for new and the old >>> mapper and set AutoAdjustSampleDistance to OFF and capture some performance >>> numbers? In that way we know exactly if something more fundamental is >>> causing the slowness. The whole reduction factor math is based on >>> approximate stuff so that will vary between two mappers. >>> >>> - Aashish >>> >>> >>>> Again, thanks for paying attention to this problem, I hope this little >>>>> application and test case can help you to adjust the parameters... >>>>> >>>> >>>> Thanks for your help. I am glad you are testing my latest changes. >>>> >>>> - Best, Aashish >>>> >>>>> >>>>> >>>>> Simon >>>>> >>>>> PS : I did not get a chance to check the difference on Paraview, but I >>>>> believe the result will be the same as the attached example is really >>>>> simple. >>>>> >>>>> 2015-11-03 19:44 GMT+01:00 Aashish Chaudhary < >>>>> aashish.chaudhary at kitware.com>: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> the branch has been merged into VTK master. I am not sure when >>>>>> Paraview is going to update the VTK, but you can do it manually if needed. >>>>>> We are also going to run our bench marking again to be sure since recently >>>>>> lot many changes went into the VTK / volume rendering. Please feel free to >>>>>> ping me again if it does not solve your issue. >>>>>> >>>>>> Looking forward to your feedback. >>>>>> >>>>>> - Aashish >>>>>> >>>>>> On Mon, Nov 2, 2015 at 8:02 AM, Aashish Chaudhary < >>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> I found the reason behind the appeared performance you were getting. >>>>>>> We have this code in volume rendering that when you interact changes the >>>>>>> sampling distance and in the newer code we were too conservative compare to >>>>>>> the last version. That's why you were getting better quality when you move >>>>>>> your mouse but lower frame rates. I pushed a branch in VTK to address the >>>>>>> issue. Would it be possible for you to build Paraview with VTK master? It >>>>>>> may take 3-4 days or longer for Paraview's VTK to get updated. >>>>>>> >>>>>>> Thanks, >>>>>>> Aashish >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 11:59 AM, Aashish Chaudhary < >>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>> >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> I am just finishing up a ParaView5 related parallel volume >>>>>>>> rendering bug (pushing a branch today to VTK). This is next on my list. >>>>>>>> >>>>>>>> - Aashish >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 11:57 AM, Simon ESNEAULT < >>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello Aashish >>>>>>>>> >>>>>>>>> Did you get a chance to try to load the dataset on Windows ? >>>>>>>>> Can I do anything to help you investigate ? Should I feel a bug, >>>>>>>>> that may act as a reminder ? >>>>>>>>> Have a nice day >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-10-27 18:26 GMT+01:00 Aashish Chaudhary < >>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>> >>>>>>>>>> Thanks Simon. This is really strange since we are not seeing it >>>>>>>>>> on Mac and Linux (but both has dedicated cards). >>>>>>>>>> >>>>>>>>>> I will look into it soon. >>>>>>>>>> >>>>>>>>>> - aashish >>>>>>>>>> >>>>>>>>>> On Tue, Oct 27, 2015 at 1:03 PM, Simon ESNEAULT < >>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Ok, thank you very much fort digging into this. >>>>>>>>>>> I've done some test and I believe I can see a similar slowdown >>>>>>>>>>> happening on OSX, with a MacBook pro retina 13" from 2013, Intel Iris 5100 >>>>>>>>>>> graphics. >>>>>>>>>>> Good luck in the investigation, I you need more details, do not >>>>>>>>>>> hesitate to ask >>>>>>>>>>> Simon >>>>>>>>>>> >>>>>>>>>>> 2015-10-27 17:37 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>> >>>>>>>>>>>> Ah, thanks. I will get back to you on this since on Linux I >>>>>>>>>>>> don't any issue so it has to be Windows specific thing. >>>>>>>>>>>> >>>>>>>>>>>> - Aashish >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 27, 2015 at 10:36 AM, Simon ESNEAULT < >>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I tried with that one from yesterday and today's version >>>>>>>>>>>>> (4.4.0-209-gc399648) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Simon >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-10-27 15:19 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And when did you download this version? >>>>>>>>>>>>>> ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Aashish >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 10:17 AM, Simon ESNEAULT < >>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, I tried with and without the shading. Without shading >>>>>>>>>>>>>>> enabled, the new Opengl2 is also slower when zoomed in (in the described >>>>>>>>>>>>>>> condition). With shading enabled, the difference in speed between the two >>>>>>>>>>>>>>> version seems even bigger. >>>>>>>>>>>>>>> I got the version from the nightly build download section of >>>>>>>>>>>>>>> paraview website (it is still available). And I've just tried with that one >>>>>>>>>>>>>>> labeled "ParaView-latest-Qt4-OpenGL2-Windows-64bit.exe" with the same >>>>>>>>>>>>>>> results. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> About the FPS, it is difficult to give an exact number, >>>>>>>>>>>>>>> because it depends of the condition (zoomed or not etc...) but yes, this is >>>>>>>>>>>>>>> the idea. >>>>>>>>>>>>>>> In our software, I've exposed the frame rate using this >>>>>>>>>>>>>>> example : >>>>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/FrameRate >>>>>>>>>>>>>>> And the frame rate is around 15/20 for the first backend, >>>>>>>>>>>>>>> and around 6/8 for the new backend, on the same dataset (the one provided >>>>>>>>>>>>>>> for example), with the same mapper parameters >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-10-27 14:48 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is helpful but just missing few more bits: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) Did you try without the shading and see how the >>>>>>>>>>>>>>>> performance compares? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) ParaView 4.4.0-193-gec96423 --> Where did you get this >>>>>>>>>>>>>>>> one from (ParaView download page or did you built yourself?) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, so on your system the old mapper is running 30FPS and >>>>>>>>>>>>>>>> the new one at 15-20 FPS as per your summary. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Oct 27, 2015 at 9:43 AM, Simon ESNEAULT < >>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sorry for the late answer, I was busy this morning. >>>>>>>>>>>>>>>>> Thanks for testing with the DataSet. >>>>>>>>>>>>>>>>> I agree the performance is still quite good with the new >>>>>>>>>>>>>>>>> backend, and I also get something like 15/20 fps on windows on an HD >>>>>>>>>>>>>>>>> screen. But when compared to the old one, and in some condition (when >>>>>>>>>>>>>>>>> zoomed especially), it looks really slower to me >>>>>>>>>>>>>>>>> The two tested version are : >>>>>>>>>>>>>>>>> - ParaView 4.4.0 64 bits final version for the old backend >>>>>>>>>>>>>>>>> - ParaView 4.4.0-193-gec96423 64 bits, for the OpenGL2 >>>>>>>>>>>>>>>>> backend. >>>>>>>>>>>>>>>>> on a windows 7 box, Xeon E3-1220 v3 CPU, 16GB ram and >>>>>>>>>>>>>>>>> Nvidia Quadro K420 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To highlight the difference, here is what I do : >>>>>>>>>>>>>>>>> - Launch both version on the same computer at the same time >>>>>>>>>>>>>>>>> - Load the above dataset on each >>>>>>>>>>>>>>>>> - Select volume rendering >>>>>>>>>>>>>>>>> - Adjust the transfer function data range to [100-750] >>>>>>>>>>>>>>>>> (the default "Cool to Warm" is fine) >>>>>>>>>>>>>>>>> - Set the view direction to +Y >>>>>>>>>>>>>>>>> - Adjust the Y of the camera position to -300 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And start interacting ... >>>>>>>>>>>>>>>>> Dunno if there is an easy way to print out the Frame Rate >>>>>>>>>>>>>>>>> in Paraview, but the new version seems really twice slower in these >>>>>>>>>>>>>>>>> conditions... We can see it does not scale in the same way, the old backend >>>>>>>>>>>>>>>>> seems more aggressive on the image sample reduction, hence the >>>>>>>>>>>>>>>>> interactivity is better. >>>>>>>>>>>>>>>>> Shading enable or not does not change much >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm aware of the DesiredUpdateRate thing, we use to play >>>>>>>>>>>>>>>>> with this with the old backend to fine tune the interactivity, although >>>>>>>>>>>>>>>>> what's really inside was never clear to me >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I hope that there is enough information for you to >>>>>>>>>>>>>>>>> reproduce this, do not hesitate to ask for some more information. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks a lot for your help >>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-10-27 14:10 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Dear Simon, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Checking again. Wondering if you can provide some more >>>>>>>>>>>>>>>>>> detail on the binary you are using and whether or not without shading the >>>>>>>>>>>>>>>>>> rendering performance comparable to older version. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 3:12 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I used your dataset on paraview master as of today on my >>>>>>>>>>>>>>>>>>> Linux box running Ubuntu 14.04 and NVIDA Quadro card and I am getting about >>>>>>>>>>>>>>>>>>> 15-20 FPS with shading on with 1920x1080 resolution. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Are you on the proper 4.4 or using RC1/RC2? I checked >>>>>>>>>>>>>>>>>>> the shading performance fix was in 4.4 but not in RC's. I don't have access >>>>>>>>>>>>>>>>>>> to Windows box right away but I will try there too. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> NOTE: You might get multiple emails because of the >>>>>>>>>>>>>>>>>>> attachment size issue. Sorry about that. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:45 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 2:13 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hello Aashish, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks for the quick answer >>>>>>>>>>>>>>>>>>>>> We are using a vtkImageData, 512x512x591 with short >>>>>>>>>>>>>>>>>>>>> element (you can find the dataset here : >>>>>>>>>>>>>>>>>>>>> https://www.dropbox.com/s/ptqwi0ebv75kt35/volume.zip). >>>>>>>>>>>>>>>>>>>>> So I think it's all about GPU volume raycast mapper. >>>>>>>>>>>>>>>>>>>>> The new mapper does bring low resolution, but when >>>>>>>>>>>>>>>>>>>>> compared to the old one, it seems less "low resolution" during interaction >>>>>>>>>>>>>>>>>>>>> than the old one >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Right, so that's why its not a exact comparison. What >>>>>>>>>>>>>>>>>>>> happens is that depending on what is interactive, (you can set the desired >>>>>>>>>>>>>>>>>>>> update rate in VTK, not exposed in ParaView I believe), it will do >>>>>>>>>>>>>>>>>>>> interactive but with higher resolution (smaller sample distance). If they >>>>>>>>>>>>>>>>>>>> both have the same sample distance, then the new mapper should out perform >>>>>>>>>>>>>>>>>>>> the old one, however, there is another thing we need to consider here which >>>>>>>>>>>>>>>>>>>> is shading. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Shading is enabled, gradient opacity disabled >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Can you disable the shading and see if now they both >>>>>>>>>>>>>>>>>>>> (opengl1 and 2) equally better? We already pushed a fix for it but not sure >>>>>>>>>>>>>>>>>>>> if that you have in your build. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Don't know if you need a minimal example, but I >>>>>>>>>>>>>>>>>>>>> believe the GPURenderDemo used with this dataset is enough to highlight the >>>>>>>>>>>>>>>>>>>>> slow down. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yes, I will use this dataset. Thanks. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2015-10-26 18:57 GMT+01:00 Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com>: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Also, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Do you have shading enabled? We fixed a bug with >>>>>>>>>>>>>>>>>>>>>> shading that was causing the slow performance a while back. I don't >>>>>>>>>>>>>>>>>>>>>> remember if that was included in 4.4 or not ( I can check ). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Aashish >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:53 PM, Aashish Chaudhary < >>>>>>>>>>>>>>>>>>>>>> aashish.chaudhary at kitware.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Simon, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> What kind of dataset you are using? Depending on the >>>>>>>>>>>>>>>>>>>>>>> data type you might be using >>>>>>>>>>>>>>>>>>>>>>> the GPU one or the unstructured renderer. The >>>>>>>>>>>>>>>>>>>>>>> performance we measured is related to the GPU ray cast mapper >>>>>>>>>>>>>>>>>>>>>>> and will apply only to the vtkImageData inputs. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Also, helpful would be is if you can tell if the new >>>>>>>>>>>>>>>>>>>>>>> mapper is bringing low resolution when you interact with the volume (and >>>>>>>>>>>>>>>>>>>>>>> whether or not it happens with old mapper). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 26, 2015 at 1:47 PM, Simon ESNEAULT < >>>>>>>>>>>>>>>>>>>>>>> simon.esneault at gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We are trying to make the switch to the new OpenGL2 >>>>>>>>>>>>>>>>>>>>>>>> backend for our application, and although the switch was easy (thanks for >>>>>>>>>>>>>>>>>>>>>>>> not breaking the API ;) ), we can see a significant slowdown on the GPU >>>>>>>>>>>>>>>>>>>>>>>> volume rendering part, especially during interaction. Typically we dropped >>>>>>>>>>>>>>>>>>>>>>>> from 15/20 fps to 7/8 fps, on the same machine (Win32, Nvidia Quadro K420), >>>>>>>>>>>>>>>>>>>>>>>> with the same code around. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This slow down can be seen in ParaView, if you >>>>>>>>>>>>>>>>>>>>>>>> compare the latest 4.4 OpenGL2 build with the classic 4.4 build while >>>>>>>>>>>>>>>>>>>>>>>> volume rendering a big enough volume (512^3) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The blog post here >>>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/blog/home/post/976 >>>>>>>>>>>>>>>>>>>>>>>> claims that the new GPU volume rendering >>>>>>>>>>>>>>>>>>>>>>>> implementation should be faster than the old one, is there some more >>>>>>>>>>>>>>>>>>>>>>>> detailed explanation somewhere ? Are there some important parameters that >>>>>>>>>>>>>>>>>>>>>>>> can make the difference ? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Simon >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> PS : The polygonal rendering seems a lot faster >>>>>>>>>>>>>>>>>>>>>>>> with the new backend ! >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>> Powered by www.kitware.com >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at >>>>>>>>>>>>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Search the list archives at: >>>>>>>>>>>>>>>>>>>>>>>> http://markmail.org/search/?q=vtk-developers >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | >>>>>>>>>>>>>>>>>>> Kitware Inc. * >>>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware >>>>>>>>>>>>>> Inc. * >>>>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>>>> * >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> Simon Esneault >>>>>>>>>>>>> Rennes, France >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>>>> * >>>>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>>>> * >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> Simon Esneault >>>>>>>>>>> Rennes, France >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>>>> * >>>>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>>>> * >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> Simon Esneault >>>>>>>>> Rennes, France >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>>> * >>>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>>> * >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>>> * >>>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>>> * >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>>>> * >>>>>> *| http://www.kitware.com/company/team/chaudhary.html >>>>>> * >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> Simon Esneault >>>>> Rennes, France >>>>> ------------------------------------------------------------------ >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>>> * >>>> *| http://www.kitware.com/company/team/chaudhary.html >>>> * >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> *| Aashish Chaudhary | Technical Leader | Kitware Inc. >>> * >>> *| http://www.kitware.com/company/team/chaudhary.html >>> * >>> >> >> >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compare.png Type: image/png Size: 928919 bytes Desc: not available URL: